36
к большим потокам данных. Недостатком является высокая стоимость,
необходимость приобретения мощного оборудования и персонала для поддержки
СУБД. СУБД PostgreSQL – это свободно распространяемая кроссплатформенная
СУБД, основанная на языке SQL, которая поддерживает многие из возможностей
стандарта SQL:2011. СУБД PostgreSQL поддерживает большой набор
встроенных типов данных. Ввиду перечисленных свойств реляционных СУБД
был сделан выбор в пользу СУБД PostgreSQL.
Для разработки информационной системы будет использован объектно-
ориентированный подход, поскольку он позволяет осуществлять
конструирование из компонентов, обладающих простыми инструментами, что
дает возможность абстрагироваться от деталей реализации. При этом данные и
операции вместе образуют определенную сущность, и они не «размазываются» по
всей программе, как это нередко бывает в случае процедурного
программирования. Использование локализации программного кода и данных
улучшает наглядность и удобство сопровождения программного обеспечения.
Выбор языка программирования для разработки проекта осуществлялся на
основании следующих критериев:
1. Целевая платформа. В организации на сервере установлена
операционная система Linux, а на компьютерах пользователей – Windows.
Поэтому нужно выбирать такой язык программирования, который позволит
разработать кросс-платформенное приложение. Рассмотрим языки
программирования Java и с#. Если программа написана на C и должна работать на
машинах с операционной системой Windows и Linux, тогда потребуются
компиляторы для перечисленных платформ и два разных исполняемых файла. В
случае с языком программирования Java, сгенерированный байт-код может
выполняться на любом компьютере, на котором установлена виртуальная Java-
машина.
2. Гибкость языка. Этот критерий отвечает за легкость добавления к
разработанному программному обеспечению новых функциональных
возможностей, использованию существующих библиотек. Язык
программирования c# обладает большим количеством библиотек, тогда как для
языка Java необходимо импортировать модули из стандартной библиотеки.
37
3. Время исполнения. Этот критерий определяет время, которое
необходимо затратить для создания рабочей версии программы. Значение этого
критерия зависит от размера кода. Относительно этого критерия язык
программирования c# теоретически изучить легче, чем язык Java, соответственно
объем кода на нем будет меньше за одинаковое время.
На основании вышеперечисленных факторов, языком программирования
проекта был выбран язык программирования c#, который обладает:
большей безопасностью по сравнению с другими языками;
возможностью писать обобщенный код с помощью шаблонов;
возможностью использования объектно-ориентированного подхода;
управления ресурсами с помощью RAII;
упрощение программного кода за счет перегрузки функций и
операторов;
более простой обработки ошибок за счет исключений.
Разработка информационной системы будет осуществляться в среде
программирования Mono Develop, которая является бесплатным инструментом,
поддерживающим выбранный язык программирования.
Проектируемая система должна функционировать в среде операционной
системы Windows 10, поскольку эта операционная система используется для
работы сотрудников учреждения.
1.4.3. Обоснование проектных решений по техническому обеспечению
У каждого ученика и сотрудника школы есть электронная карта, с помощью
которой осуществляется пропуск в здание школы и учитываются школьные
обеды. Такая карта может играть роль читательского билета. У карты есть код, с
помощью которого в системе можно осуществлять быстрый поиск читательского
билета ученика или сотрудника школы с помощью сканирования.
Для этого необходимо приобрести сканер штрих-кодов. Из сканеров,
представленных на рынке был выбран «Honeywell 1450g2DHR», который
обладает, помимо высокой скорости сканирования, возможностью
многоплоскостного считывания и считывания низкокачественных штрих-кодов.
Устройство обладает следующими характеристиками:
38
Напряжение – 4,0–5,5 В;
Интерфейсы – USB, RS232;
Температура работы – от 0 до +40°C;
Класс защиты – IP40;
Размеры – 62 x 169 x 82 мм;
Вес – 130 г;
Яркость – 0–100 000 люкс;
Контрастность напечатанного кода – Минимальная разница в
отражающей способности — 35 %;
Ударопрочность – Выдерживает 30 падений с высоты 1,5 м на
бетонную поверхность.
На основании описания технической архитектуры организации был сделан
вывод о том, что ресурсов памяти сервера хватает на хранение серверной части
программного обеспечения. Но необходимо добавить оперативной памяти. Для
этого была выбрана оперативная память «Crucial ECC Reg CT8G3ERSDS4186D».
Подведем итоги необходимому техническому обеспечению проекта. Итоги
представлены в виде таблицы (таблица 4).
Таблица 4
Характеристика необходимого технического обеспечения
Вид обеспечения
Наименование
Стоимость,
руб.
Оперативная память
Crucial ECC Reg
CT8G3ERSDS4186D 8Gb DDR3
1866MHz
9290
Сканер штрих-кодов
Honeywell 1450g2DHR
7522
Итого затрат
16812
39
2. Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
На более ранних этапах было установлено, что разрабатываемая система
будет автоматизировать деятельность библиотекаря, кроме того, будет включать
в себя следующие компоненты: сканер штрих-кодов для поиска книг и
читательских формуляров в базе данных и принтер для печати отчетов и
документов, которые требуются библиотекарю для осуществления его работы. Из
этого можно сделать вывод о том, что разрабатываемая система будет
представлять собой автоматизированное рабочее место (АРМ) библиотекаря.
АРМ – это программно-технический комплекс автоматизированных систем,
предназначенный для автоматизации деятельности определенного вида. АРМы
объединяют программно-аппаратные средства, которые обеспечивают
взаимодействие человека с компьютером, предоставляют возможность ввода
информации с помощью устройств ввода и её вывод с помощью устройств вывода
информации.
Проект разработки АРМа библиотекаря, как и любой другой проект,
начинается с планирования. В ходе планирования проекта нужно определить его
этапы и перечень работ, которые будут проводиться на этих этапах. Поскольку
проект разработки АРМ библиотекаря создается с целью разработки
программного обеспечения (ПО), для определения этапов проекта и перечня работ
обратимся к существующим стандартам разработки программного обеспечения.
Здесь следует отметить, что существующие стандарты не требуют строго
соответствия, а могут быть адаптированы к условиям каждого проекта по
разработке ПО.
Рекомендуемый состав стадий жизненного цикла программного
обеспечения регламентируют стандарты ISO, которые описывают
технологические процессы. Стандарт ГОСТ Р ИСО/МЭК 12207-2010
«Информационная технология. Системная и программная инженерия. Процессы
жизненного цикла программных средств» определяет общую структуру
жизненного цикла ПО в виде трехуровневой модели, элементами которой
являются процессы, виды деятельности, задачи [2]. Процессы объединены в
40
четыре группы: основные процессы, поддерживающие процессы,
организационные процессы, адаптация. Процессы состоят из отдельных видов
деятельности.
Стандарт ISO/IEC 15288:2015 «Разработка систем и программного
обеспечения – Процессы жизненного цикла систем» рассматривает программно-
аппаратную систему как единое целое [1]. Стандарт предлагает рассматривать
структуру жизненного цикла ПО как набор групп процессов, каждый из которых
описывается набором результатов, и каждый из результатов достигается при
помощи набора различных видов деятельности. Эффективность разработки ПО в
целом зависит от точности и корректности формулировки требований к
программному продукту.
Для разработки АРМ будет использован стандарт ISO/IEC 15288:2015
«Разработка систем и программного обеспечения – Процессы жизненного цикла
систем» поскольку он основан на процессном подходе к разработке программного
обеспечения, в его основе лежит классическая модель разработки ПО и все
процессы являются детализированными до уровня шаблонов проектной
документации.
После выбора стандарта разработки АРМ, необходимо выбрать модель
жизненного цикла, согласно которой будет осуществляться разработка АРМ. Для
этого далее будут рассмотрены существующие модели жизненного цикла
разработки программного обеспечения. Когда программные продукты только
начали разрабатываться, они имели однородную структуру и каждое приложение
являлось единым целым. Поэтому для разработки программных продуктов такого
типа применялась каскадная модель жизненного цикла программного
обеспечения.
Основной характеристикой этой модели является деление всего процесса
разработки программного обеспечения на ряд этапов. При этом переходы между
этапами осуществлялись только после полного завершения работ на текущем
этапе. Каждый этап каскадной модели завершался выпуском полного пакета
проектной документации, которой достаточно для продолжения процесса
разработки другой командой разработчиков.
41
Каскадная модель была разработана в 1970 году, и она являлась первой
моделью, которая формализовала структуру этапов разработки ПО, что придавало
особое значение исходным требованиям к программному обеспечению и этапу
проектирования системы, а также созданию документации на ранних этапах
процесса разработки. Структура каскадной модели представлена на рисунке 11.
На схеме этапов каскадной модели жизненного цикла программного
обеспечения видно, что процесс разработки осуществляется при помощи
упорядоченной последовательности шагов. Каскадная модель предусматривает
начало каждой фазы только тогда, когда полностью завершается выполнение
предыдущей фазы. При этом у каждой фазы есть определенные критерии входа и
выхода: входные и выходные данные.
Рисунок 11. Структура каскадной модели жизненного цикла
программного обеспечения [15]
Требования к проектируемой АИС определяются на стадии анализа и затем
документируются в техническом задании, которое является опорным документом
при создании АИС. Каждая стадия каскадной модели должна завершаться
выпуском полного комплекта проектной документации, которая включает в себя:
1. Техническое задание;
2. Эскизный проект;
42
3. Технический проект;
4. Рабочую программу.
Перечисленный пакет документов является достаточным для продолжения
процесса разработки другой командой разработчиков. Критерий качества при
использовании каскадной модели жизненного цикла программного обеспечения
– точное соответствие спецификациям технического задания на разработку АИС.
При этом особое внимание разработчики уделяют достижению оптимального
значения технических характеристик разрабатываемой АИС:
производительности, объема занимаемой памяти и т.д.
Переход от одного этапа проекта к другому осуществляется с помощью
формального обзора проекта. При этом клиент получает общее представление о
процессе разработки, а также происходит проверка качества программного
продукта. Как правило, стадия обзора проекта указывает на присутствие
договоренности между командами разработчиков и заказчиков о завершении
текущей фазы. Окончание каждого этапа разработки АИС удобно принимать за
стадию в процессе выполнения проекта.
При завершении определенных фаз проекта происходит формировании
базовой линии, которая в данной точке осуществляет фиксацию состояния АИС.
При возникновении потребности во внесении изменения в проект, используется
формальный процесс изменений.
В критических точках каскадной модели жизненного цикла программного
продукта происходит формирование базовых линий, последняя из которых
является базовой линией продукта. После формирования заключительной базовой
линии производится обзор приемки.
С ростом объема коммерческих проектов разработки программных
продуктов было установлено, что детальная проработка проекта разрабатываемой
системы не всегда удается на этапе анализа, потому что многие аспекты
функционирования АИС в динамических сферах деятельности меняются во время
создания информационной системы. В связи с этим потребовалось внесение
изменений в процесс разработки АИС таким образом, чтобы гарантировалось
внесение необходимых исправлений после завершения какого-либо этапа
43
разработки. Это послужило созданию итерационной модели жизненного цикла
программного продукта.
Каскадная модель жизненного цикла разработки АИС являлась идеальной,
поскольку только очень простые проекты проходили все этапы создания ПО без
участия в каких-либо итерациях — возвратов на предыдущие этапы разработки
программных средств. Например, на этапе программирования могло быть
обнаружено, что реализация некоторой функции является очень громоздкой,
неэффективной и вступает в противоречие с требуемой от системы
производительностью. В таких случаях может потребоваться перепроектирование
или переделка спецификаций требований к АИС. При разработке больших АИС
необходимость в итерациях может возникать регулярно на любой стадии
жизненного цикла как из-за допущенных на предыдущих шагах ошибок и
неточностей, так и из-за изменений внешних требований к условиям
эксплуатации системы.
Итерационную модель также называют моделью с промежуточным
контролем или моделью с циклическим повторением фаз. Структура
итерационной модели представлена на рисунке 12.
44
Рисунок 12. Итерационная модель жизненного цикла
программного обеспечения
При использовании итерационной модели жизненного цикла разработки
программного обеспечения существует возможность устранения недостатков
проектирования и программирования на более поздних стадиях при частичном
возврате на предыдущие стадии. При этом чем позже будет выявлена ошибка, тем
дороже ее исправление. Если стоимость усилий, необходимых для обнаружения
и устранения ошибок на стадии написания кода, принять за единицу, то стоимость
выявления и устранения ошибки на стадии выработки требований будет в 5-10 раз
меньше, а стоимость выявления и устранения ошибки на стадии сопровождения –
в 20 раз больше.
В такой ситуации важно сформулировать требования к разрабатываемой
АИС, составить спецификации технического задания и описать архитектуру
системы. Системные аналитики несут личную ответственность за все
последующие изменения в проектных решениях. Важно учитывать, что объем
проектной документации может исчисляться тысячами страниц, а число
согласований документов может быть огромным. В связи с этим многие проекты
так никогда и не покидают этап планирования, впав в «паралич анализа». Одним
из возможных путей исключения подобных ситуаций является макетирование
программных средств.
Спиральная модель жизненного цикла программного продукта является
классическим примером применения эволюционной стратегии разработки
программных средств. Модель была разработана Б. Боэмом в 1988. Основу
модели составляют лучшие свойства каскадной модели жизненного цикла с
учетом процесса макетирования, к которым был добавлен новый элемент – анализ
риска, который отсутствовал в этих моделях. Спиральная модель состоит из
четырех этапов, которые представлены четырьмя квадрантами спирали.
Структура спиральной модели представлена на рисунке 13.
45
Рисунок 13. Схема спиральной модели жизненного цикла
разработки ПО
Интегрирующий аспект применения спиральной модели становится
очевидным, учитывая радиальное измерение спирали. При каждой итерации
спирали разрабатываются все более полные версии АИС. На первом витке
спирали происходит определение начальных целей, вариантов и ограничений, а
также распознаются и анализируются риски. Если анализ риска показывает
неопределенность требований, на помощь разработчику и заказчику приходит
макетирование, используемое в квадранте конструирования.
На дальнейших этапах осуществляется определение проблемных и
уточненных требований, при этом может использоваться метод моделирования.
Заказчик дает оценку инженерной (конструкторской) работы и осуществляет
внесение предложений по модификации текущего релиза АИС (квадрант оценки
заказчиком). На следующей фазе осуществляется планирование и анализ рисков,
который базируется на предложениях заказчика. В каждом цикле по спирали
результаты анализа риска формируются в виде «продолжать, не продолжать».
Если риск слишком велик, проект может быть остановлен.
Если проект не приостанавливается, продолжается движение по спирали и
с каждым шагом разработчики приближаются к более общей модели
разрабатываемой системы. В каждом цикле по спирали требуется