50
технических характеристик разрабатываемой АИС: производительности, объема
занимаемой памяти и т.д.
Переход от одного этапа проекта к другому осуществляется с помощью
формального обзора проекта. При этом клиент получает общее представление о
процессе разработки, а также происходит проверка качества программного
продукта. Окончание каждого этапа разработки АИС удобно принимать за стадию в
процессе выполнения проекта.
С ростом объема коммерческих проектов разработки программных продуктов
было установлено, что детальная проработка проекта разрабатываемой системы не
всегда удается на этапе анализа, потому что многие аспекты функционирования
АИС в динамических сферах деятельности меняются во время создания
информационной системы. В связи с этим потребовалось внесение изменений в
процесс разработки АИС таким образом, чтобы гарантировалось внесение
необходимых исправлений после завершения какого-либо этапа разработки. Это
послужило созданию итерационной модели жизненного цикла программного
продукта.
Каскадная модель жизненного цикла разработки АИС являлась идеальной,
поскольку только очень простые проекты проходили все этапы создания ПО без
участия в каких-либо итерациях — возвратов на предыдущие этапы разработки
программных средств. Например, на этапе программирования могло быть
обнаружено, что реализация некоторой функции является очень громоздкой,
неэффективной и вступает в противоречие с требуемой от системы
производительностью. В таких случаях может потребоваться перепроектирование
или переделка спецификаций требований к АИС. При разработке больших АИС
необходимость в итерациях может возникать регулярно на любой стадии
жизненного цикла как из-за допущенных на предыдущих шагах ошибок и
неточностей, так и из-за изменений внешних требований к условиям эксплуатации
системы.
Итерационную модель также называют моделью с промежуточным
контролем или моделью с циклическим повторением фаз. Структура итерационной
модели представлена на рисунке 13.
51
Рисунок 13. Итерационная модель жизненного цикла
При использовании итерационной модели жизненного цикла разработки
программного обеспечения существует возможность устранения недостатков
проектирования и программирования на более поздних стадиях при частичном
возврате на предыдущие стадии. При этом чем позже будет выявлена ошибка, тем
дороже ее исправление. Если стоимость усилий, необходимых для обнаружения и
устранения ошибок на стадии написания кода, принять за единицу, то стоимость
выявления и устранения ошибки на стадии выработки требований будет в 5-10 раз
меньше, а стоимость выявления и устранения ошибки на стадии сопровождения – в
20 раз больше.
В такой ситуации важным становится этап формулирования требований в
разрабатываемой АИС, составление спецификаций технического задания и создание
архитектуры системы. Системные аналитики несут личную ответственность за все
последующие изменения в проектных решениях. Важно учитывать, что объем
проектной документации может исчисляться тысячами страниц, а число
согласований документов может быть огромным. В связи с этим многие проекты так
никогда и не покидают этап планирования, впав в «паралич анализа». Одним из
возможных путей исключения подобных ситуаций является макетирование
(прототипирование) программных средств.
Спиральная модель жизненного цикла программного продукта является
классическим примером применения эволюционной стратегии разработки
программных средств. Модель была разработана Б. Боэмом в 1988. Основу модели
составляют лучшие свойства каскадной модели жизненного цикла с учетом процесса
52
макетирования, к которым был добавлен новый элемент – анализ риска, который
отсутствовал в этих моделях. Спиральная модель состоит из четырех этапов,
которые представлены четырьмя квадрантами спирали. Структура спиральной
модели представлена на рисунке 14.
Рисунок 14. Схема спиральной модели жизненного цикла
Интегрирующий аспект применения спиральной модели становится
очевидным, учитывая радиальное измерение спирали. При каждой итерации
спирали разрабатываются все более полные версии АИС. На первом витке спирали
происходит определение начальных целей, вариантов и ограничений, а также
распознаются и анализируются риски. Если анализ риска показывает
неопределенность требований, на помощь разработчику и заказчику приходит
макетирование, используемое в квадранте конструирования.
На дальнейших этапах осуществляется определение проблемных и
уточненных требований, при этом может использоваться метод моделирования.
Заказчик дает оценку инженерной (конструкторской) работы и осуществляет
внесение предложений по модификации текущего релиза АИС (квадрант оценки
заказчиком). На следующей фазе осуществляется планирование и анализ рисков,
который базируется на предложениях заказчика. В каждом цикле по спирали
результаты анализа риска формируются в виде «продолжать, не продолжать». Если
риск слишком велик, проект может быть остановлен.
53
Если проект не приостанавливается, продолжается движение по спирали и с
каждым шагом разработчики приближаются к более общей модели разрабатываемой
системы. В каждом цикле по спирали требуется конструирование, которое может
быть реализовано классическим жизненным циклом или макетированием. Заметим,
что количество действий по разработке (происходящих в правом нижнем квадранте)
возрастает по мере продвижения от центра спирали.
Из рассматриваемых моделей жизненного цикла программных систем
наиболее подходящей моделью для проектируемой системы является итерационная
модель, потому что она позволяет заказчикам оказывать большее влияние на
процесс разработки и оперативно вносить изменения в систему, что гарантирует по
завершении создания системы получить максимально удовлетворяющий
требованиям заказчика проект.
После того как был сделан выбор стандарта разработки программного
продукта и модели жизненного цикла, необходимо осуществить выбор стратегии
внедрения. Выделяют 4 стратегии внедрения программного обеспечения [20]:
«Параллельная стратегия» - когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему.
«Скачок». Эта стратегия представляет собой резкий переход от
использования старой информационной системы к новой без каких-либо
дополнительных проверок и с полным отказом от старой системы.
«Пилотный проект». Это наиболее часто используемая стратегия.
«Пилотный проект» - это тактика «скачка», но применяемая к ограниченному числу
процессов. Область применения стратегии - небольшой участок деятельности. Такой
подход снижает риск и наиболее надежен. Практически все предприятия применяют
эту тактику сегодня.
«Узкое место». «Узкое место» - это малая часть производственного
процесса. При использовании похода «узкое место» план внедрения выполняется
только для «узкого места» и для людей, работающих в нем. Точность данных
повышается только для изделий в этом «узком месте»; переподготовка - только для
людей, работающих в нем; анализ эффект-затрат делается только для него и т.д.
54
Для рассматриваемой задачи наиболее подходящей является параллельная
стратегия, потому что прием почтовых отправлений будет осуществляться
отправителями самостоятельно с помощью терминала, но также отправления могут
быть принятыми операторами.
Проектируемая система, автоматизирующая процесс приема регистрируемых
почтовых отправлений, будет разрабатываться согласно стандарту «ГОСТ Р
ИСО/МЭК 15288», итерационной модели жизненного цикла и параллельной
стратегии внедрения программного обеспечения.
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
Нормативно-справочная информация включает в себя:
1. Перечень стран.
2. Перечень областей.
3. Перечень населенных пунктов.
4. Перечень улиц.
5. Перечень домов.
6. Перечень индексов.
7. Перечень расстояний между населенными пунктами.
Справочник стран включает в себя перечень стран, в которые могут быть
отправлены почтовые отправления. У каждой страны есть код и название. Форма
справочника должна содержать:
список стран;
поля для ввода данных кода страны и названия;
поля для поиска страны по коду или названию;
кнопки для манипулирования данными (удаление, сохранение,
добавление).
На основании перечисленных элементов создадим макет формы справочника
«Страны» в среде программирования MS Visual Studio 2017 (рисунок 15).
55
Рисунок 15. Макет формы справочника «Страны»
Форма справочника «Область» должна содержать те же элементы, что и
форма справочника «Страны», только с добавлением кода региона, а именно:
Код страны;
Код региона;
Название области;
Поле поиска по коду или названию области;
Кнопки для манипулирования данными (удаление, сохранение,
добавление).
Макет формы справочника «Область» представлен на рисунке 16.
Рисунок 16. Макет формы справочника «Область»
Каждый город находится в какой-либо области. Поэтому форма справочника
«Города» будет содержать следующие элементы
Код региона;
56
Код города;
Название города;
Поле поиска по коду или названию города;
Кнопки для манипулирования данными (удаление, сохранение,
добавление).
Макет формы справочника «Города» представлен на рисунке 17.
Рисунок 17. Макет формы справочника «Города»
В каждом городе есть улицы, которые указываются в адресе отправителя и
получателя. Поэтому макет формы справочника «Улицы» должен включать к себя
следующие поля:
Код города;
Название улицы;
Поле поиска по названию улицы;
Кнопки для манипулирования данными (удаление, сохранение,
добавление).
Макет формы справочника «Улицы» представлен на рисунке 18.
Рисунок 18. Макет формы справочника «Улицы»
57
На каждой улице расположены здания, которым присвоены номера. Поэтому
макет формы справочника «Дома» должен включать к себя следующие поля:
Название улицы;
Номер дома;
Номер корпуса;
Поле поиска по названию улицы;
Кнопки для манипулирования данными (удаление, сохранение,
добавление).
Макет формы справочника «Дома» представлен на рисунке 19.
Рисунок 19. Макет формы справочника «Дома»
Улицы и дома, расположенные на ней, сгруппированы индексами. Поэтому
макет формы справочника «Индекс» должен включать к себя следующие поля:
Номер индекса;
Название улицы;
Номер дома;
Номер корпуса;
Поле поиска по индексу, названию улицы или номеру дома;
Кнопки для манипулирования данными (удаление, сохранение,
добавление).
Макет формы справочника «Индексы» представлен на рисунке 20.
Для расчета стоимости отправления используются расстояния между
населенными пунктами. Форма справочника «Расстояние между населенными
пунктами» должна содержать следующие поля:
58
Наименование пункта 1;
Наименование пункта 2;
Расстояние между пунктами;
Поле поиска по индексу, названию улицы или номеру дома;
Кнопки для манипулирования данными (удаление, сохранение,
добавление).
Макет формы справочника «Расстояние» представлен на рисунке 21.
Рисунок 20. Макет формы справочника «Индекс»
Рисунок 21. Макет формы справочника «Расстояние»
Входным документом задачи является паспорт отправителя, на основании
которого заполняются данные отправителя. Поэтому макет формы справочника
должен содержать следующие элементы:
Поля для ввода данных об отправителе (ФИО);
Поля для ввода данных о паспорте отправителя;
Поля для ввода данных об адресе отправителя;
59
Кнопки для манипулирования данными (удаление, сохранение,
добавление).
Макет формы «Отправитель» представлен на рисунке 22.
Рисунок 22. Макет формы справочника «Отправитель»
К оперативной информации системы относятся:
Данные о получателе;
Тарифы «Посты России»;
Стоимость отправления.
Разработаем макеты форм для ввода перечисленной информации. Данные о
получателе содержат следующую информацию:
ФИО получателя;
Адрес.
Макет формы «Получатель» представлен на рисунке 23.
Для расчета стоимости доставки отправления необходимы данные о тарифах
«Почты России». К этим данным относятся:
Расстояние.
Стоимость.
Для того, чтобы можно было изменять данные о тарифах при их изменении
необходимо создать форму ввода данных о тарифах, на которой будет указано
расстояние и стоимость отправления. Макет формы «Тариф» представлен на
рисунке 24.