46
компании. Согласно этому стандарту при разработке программного обеспече-
ния применяется классическая модель жизненного цикла программного про-
дукта.
• стандарт «Rational Unified Process» (RUP) представляет разработку
программного обеспечения в виде итеративной модели жизненного цикла, ко-
торый включает следующие фазы: начало, исследование, построение и внедре-
ние [18, стр. 98]. Каждая фаза жизненного цикла АИС может разбиваться на
этапы, называемые итерациями. В результате осуществления этих этапов про-
исходит выпуск версий программного продукта для внутреннего или внешнего
использования. Прохождение процесса разработки через четыре этапа называ-
ют циклом разработки. Каждый цикл разработки завершается генерацией вер-
сии системы. Если после версия системы не удовлетворяет требованиям поль-
зователя, то разработанный продукт продолжает свое развитие и проходит те
же этапы разработки.
• стандарт «Microsoft Solution Framework» (MSF) похож на стандарт
«RUP» тем, что делит разработку программного обеспечения на четыре фазы:
анализ, проектирование, разработка, стабилизация [16, стр. 54]. Эта модель яв-
ляется итерационной, что предполагает использование объектно-
ориентированного подхода при моделировании системы. Стандарт «MSF» в
сравнении со стандартом «RUP» больше ориентирован для разработки бизнес-
приложений.
• стандарт «Extreme Programming» (XP) был создан в 1996 году и явля-
ется самым новым среди рассмотренных стандартов [19, стр. 93]. Основу этого
стандарта составляет командная работа, с организацией эффективной коммуни-
кацией между заказчиком и разработчиков во время всей разработки АИС. При
этом разработка АИС проводится с использованием последовательно разраба-
тываемых прототипов АИС.
Для разработки системы был выбран стандарт ГОСТ Р ИСО/МЭК 12207-
2010, потому что его основу составляет классическая модель разработки ПО и
47
все процессы являются детализированными до уровня шаблонов проектной до-
кументации.
Рассмотрим модели жизненного цикла программного продукта. Когда
программные продукты только начали разрабатываться, они имели однородную
структуру и каждое приложение являлось единым целым. Поэтому для разра-
ботки программных продуктов такого типа применялась каскадная модель
жизненного цикла программного обеспечения.
Основной характеристикой этой модели является деление всего процесса
разработки программного обеспечения на ряд этапов. При этом переходы меж-
ду этапами осуществлялись только после полного завершения работ на теку-
щем этапе. Каждый этап каскадной модели завершался выпуском полного па-
кета проектной документации, которой достаточно для продолжения процесса
разработки другой командой разработчиков.
Каскадная модель была разработана в 1970 году, и она являлась первой
моделью, которая формализовала структуру этапов разработки ПО, что прида-
вало особое значение исходным требованиям к программному обеспечению и
этапу проектирования системы, а также созданию документации на ранних эта-
пах процесса разработки. Структура каскадной модели представлена на рисун-
ке 9.
Рисунок 9. Структура каскадной модели жизненного цикла про-
граммного обеспечения.
На схеме этапов каскадной модели жизненного цикла программного
обеспечения видно, что процесс разработки осуществляется при помощи упо-
48
рядоченной последовательности шагов. Каскадная модель предусматривает
начало каждой фазы только тогда, когда полностью завершается выполнение
предыдущей фазы. При этом у каждой фазы есть определенные критерии входа
и выхода: входные и выходные данные.
Требования к проектируемой АИС определяются на стадии анализа и за-
тем документируются в техническом задании, которое является опорным доку-
ментом при создании АИС. Каждая стадия каскадной модели должна завер-
шаться выпуском полного комплекта проектной документации, которая вклю-
чает в себя:
1. Техническое задание.
2. Эскизный проект.
3. Технический проект.
4. Рабочую программу.
Перечисленный пакет документов является достаточным для продолже-
ния процесса разработки другой командой разработчиков. Критерий качества
при использовании каскадной модели жизненного цикла программного обеспе-
чения – точное соответствие спецификациям технического задания на разра-
ботку АИС. При этом особое внимание разработчики уделяют достижению оп-
тимального значения технических характеристик разрабатываемой АИС: про-
изводительности, объема занимаемой памяти и т.д.
Переход от одного этапа проекта к другому осуществляется с помощью
формального обзора проекта. При этом клиент получает общее представление о
процессе разработки, а также происходит проверка качества программного
продукта. Как правило, стадия обзора проекта указывает на присутствие дого-
воренности между командами разработчиков и заказчиков о завершении теку-
щей фазы. Окончание каждого этапа разработки АИС удобно принимать за ста-
дию в процессе выполнения проекта.
При завершении определенных фаз проекта происходит формировании
базовой линии, которая в данной точке осуществляет фиксацию состояния
49
АИС. При возникновении потребности во внесении изменения в проект, ис-
пользуется формальный процесс изменений.
В критических точках каскадной модели жизненного цикла программного
продукта происходит формирование базовых линий, последняя из которых яв-
ляется базовой линией продукта. После формирования заключительной базовой
линии производится обзор приемки.
С ростом объема коммерческих проектов разработки программных про-
дуктов было установлено, что детальная проработка проекта разрабатываемой
системы не всегда удается на этапе анализа, потому что многие аспекты функ-
ционирования АИС в динамических сферах деятельности меняются во время
создания информационной системы. В связи с этим потребовалось внесение
изменений в процесс разработки АИС таким образом, чтобы гарантировалось
внесение необходимых исправлений после завершения какого-либо этапа раз-
работки. Это послужило созданию итерационной модели жизненного цикла
программного продукта.
Каскадная модель жизненного цикла разработки АИС являлась идеаль-
ной, поскольку только очень простые проекты проходили все этапы создания
ПО без участия в каких-либо итерациях — возвратов на предыдущие этапы
разработки программных средств. Например, на этапе программирования могло
быть обнаружено, что реализация некоторой функции является очень громозд-
кой, неэффективной и вступает в противоречие с требуемой от системы произ-
водительностью. В таких случаях может потребоваться перепроектирование
или переделка спецификаций требований к АИС. При разработке больших АИС
необходимость в итерациях может возникать регулярно на любой стадии жиз-
ненного цикла как из-за допущенных на предыдущих шагах ошибок и неточно-
стей, так и из-за изменений внешних требований к условиям эксплуатации си-
стемы.
Итерационную модель также называют моделью с промежуточным кон-
тролем или моделью с циклическим повторением фаз. Структура итерационной
модели представлена на рисунке 10.
50
Рисунок 10. Итерационная модель жизненного цикла
программного обеспечения.
При использовании итерационной модели жизненного цикла разработки
программного обеспечения существует возможность устранения недостатков
проектирования и программирования на более поздних стадиях при частичном
возврате на предыдущие стадии. Чем позже будет выявлена ошибка, тем доро-
же обойдется ее исправление. Если стоимость усилий, необходимых для обна-
ружения и устранения ошибок на стадии написания кода, принять за единицу,
то стоимость выявления и устранения ошибки на стадии выработки требований
будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на ста-
дии сопровождения – в 20 раз больше.
В такой ситуации важным становится этап формулирования требований к
разрабатываемой АИС, составление спецификаций технического задания и со-
здание архитектуры системы. Системные аналитики несут личную ответствен-
ность за все последующие изменения в проектных решениях. Важно учитывать,
что объем проектной документации может исчисляться тысячами страниц, а
число согласований документов может быть огромным. В связи с этим многие
проекты так никогда и не покидают этап планирования, впав в «паралич анали-
за». Одним из возможных путей исключения подобных ситуаций является ма-
кетирование (прототипирование) программных средств.
51
Спиральная модель жизненного цикла программного продукта является
классическим примером применения эволюционной стратегии разработки про-
граммных средств. Модель была разработана Б. Боэмом в 1988. Основу модели
составляют лучшие свойства каскадной модели жизненного цикла с учетом
процесса макетирования, к которым был добавлен новый элемент – анализ рис-
ка, который отсутствовал в этих моделях. Спиральная модель состоит из четы-
рех этапов, которые представлены четырьмя квадрантами спирали. Структура
спиральной модели представлена на рисунке 11.
Рассмотрим этапы спиральной модели:
1. На этапе планирования осуществляется определение целей, вариантов
и ограничений проекта.
2. На этапе анализа риска осуществляется анализ вариантов и распозна-
вание/выбор риска проекта.
3. На этапе конструирования осуществляется разработка программного
продукта следующего уровня.
4. На этапе оценивания происходит оценка текущих результатов разра-
ботки заказчиком.
Рисунок 11. Схема спиральной модели жизненного
цикла разработки ПО.
52
Интегрирующий аспект применения спиральной модели становится оче-
видным, учитывая радиальное измерение спирали. При каждой итерации спи-
рали разрабатываются все более полные версии АИС. На первом витке спирали
происходит определение начальных целей, вариантов и ограничений, а также
распознаются и анализируются риски. Если анализ риска показывает неопреде-
ленность требований, на помощь разработчику и заказчику приходит макетиро-
вание, используемое в квадранте конструирования.
На дальнейших этапах осуществляется определение проблемных и уточ-
ненных требований, при этом может использоваться метод моделирования. За-
казчик дает оценку инженерной (конструкторской) работы и осуществляет вне-
сение предложений по модификации текущего релиза АИС (квадрант оценки
заказчиком). На следующей фазе осуществляется планирование и анализ рис-
ков, который базируется на предложениях заказчика. В каждом цикле по спи-
рали результаты анализа риска формируются в виде «продолжать, не продол-
жать». Если риск слишком велик, проект может быть остановлен.
Если проект не приостанавливается, продолжается движение по спирали
и с каждым шагом разработчики приближаются к более общей модели разраба-
тываемой системы. В каждом цикле по спирали требуется конструирование
(нижний правый квадрант), которое может быть реализовано классическим
жизненным циклом или макетированием. Заметим, что количество действий по
разработке (происходящих в правом нижнем квадранте) возрастает по мере
продвижения от центра спирали.
Эти действия пронумерованы на рисунке 11 и имеют следующее содер-
жание:
1. Осуществление начального сбора требований и планирования проек-
та.
2. Осуществление начального сбора требований и планирования проекта
на основании рекомендаций заказчика.
3. Осуществление анализа риска на основании начальных требований.
4. Осуществление анализа риска на основе реакции заказчика.
53
5. Переход к комплексной системе.
6. Разработка начального макета системы.
7. Разработка следующего уровня макета.
8. Сборка сконструированной системы.
9. Оценка работы заказчиком.
Из рассматриваемых моделей жизненного цикла программных систем
наиболее подходящей моделью для проектируемой системы является спираль-
ная модель жизненного цикла, поскольку она обладает рядом достоинств по
сравнению с другими моделями:
1. Заказчик может оценить системные требования в процессе их сбора
командой разработчиков, поэтому взаимодействие заказчика с АИС начинается
на ранних этапах разработки.
2. Оценивая реакцию заказчика при демонстрации разрабатываемого
продукта, разработчики получают сведения об одном или нескольких аспектах
поведения системы, благодаря чему сводится к минимуму количество неточно-
стей в требованиях.
3. Снижение возможности возникновения ошибок или искажений ин-
формации при разработке системных требований, что приводит к созданию бо-
лее качественного конечного продукта.
4. Возможность внесения в процесс разработки новых или неожиданных
требований пользователей, что является необходимым, поскольку реальное по-
ложение дел может отличаться концептуальной модели предметной области.
5. Модель представляет собой формальную спецификацию, воплощен-
ную в рабочую модель жизненного цикла предметной области.
6. Модель позволяет выполнить гибкое проектирование и разработку,
включая несколько итераций на всех фазах жизненного цикла.
7. Использование модели способствует созданию постоянных видимых
признаков прогресса в выполнении проекта, что способствует укреплению от-
ношений с заказчиком.
54
8. Возможность возникновения разногласий при общении заказчика с
разработчиками минимизирована.
9. Качество программного продукта определяется при активном участии
пользователя в процессе разработки на ранних фазах проекта.
10. Возможность наблюдения той или иной функции в действии пробуж-
дает очевидную необходимость в разработке дополнительных функциональных
возможностей.
11. Низкий объем доработок уменьшает затраты на разработку АИС.
12. Благодаря раннему сроку выявления проблем, происходит сокраще-
ние общих затрат проекта.
13. Легкость управления рисками.
14. Содержание проектной документации концентрируется на конечном
продукте, а не на процессе разработки.
15. Увеличение лояльности конечных пользователей к программному
продукту в связи с тем, что они принимают участие в процессе разработки на
протяжении всего жизненного цикла [23, стр. 151].
После того как был сделан выбор стандарта разработки программного
продукта и модели жизненного цикла, необходимо осуществить выбор страте-
гии внедрения. Выделяют 4 стратегии внедрения программного обеспечения:
• «Параллельная стратегия» - когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему.
• «Скачок». Эта стратегия представляет собой резкий переход от ис-
пользования старой информационной системы к новой без каких-либо допол-
нительных проверок и с полным отказом от старой системы.
• «Пилотный проект». Это наиболее часто используемая стратегия.
«Пилотный проект» - это тактика «скачка», но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок деятель-
ности. Такой подход снижает риск и наиболее надежен. Практически все пред-
приятия применяют эту тактику сегодня.
55
• «Узкое место». Это малая часть производственного процесса. При ис-
пользовании данного похода план внедрения выполняется только для «узкого
места» и для людей, работающих в нем. Точность данных повышается только
для изделий в этом «узком месте»; переподготовка - только для людей, работа-
ющих в нем; анализ эффект-затрат делается только для него и т.д.
Для проектируемой системы была выбрана стратегия «пилотный проект»
поскольку система будет автоматизировать только процесс учет обращений
пользователей. В качестве модели жизненного цикла была выбрана каскадная.
Стандартом разработки программного обеспечения будет ГОСТ Р ИСО/МЭК
12207-2010.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
В процессе планирования проекта по разработке системы необходимо
проанализировать риски и разработать план реагирования на риски. Определим
риски, которые могут быть выявлены на этапах жизненного цикла системы.
Рисками этапа разработки стратегии автоматизации являются:
• недостаточное определение свойств проектируемой системы, которые
требуются для решения задачи.
• неверный выбор процессов автоматизации.
Последствиями этих рисков может стать необходимость доработки си-
стемы, выявленная на этапе опытной эксплуатации, что повлечет за собой до-
полнительные финансовые затраты.
Предотвратить перечисленные риски возможно с помощью применения
CASE-средств при моделировании бизнес-процессов на этапе выявления требо-
ваний пользователей.
Основным риском этапа анализа предметной области является непра-
вильное определение функций системы. Вследствие этого может возникнуть
риск неправильного выбора способа приобретения системы. Предотвращение