77
Рисунок №13 Обобщенная схема процесса
Рисунок №14 ЖЦ каскадной модели
78
Основные положительные моменты применения каскадной модели
заключаются в следующем: модель проста, понятна заказчикам; каждая
последующая фаза начинается лишь тогда, когда полностью завершено
выполнение предыдущей фазы; на каждом этапе формируется законченный отбор
проектной документации, отвечающий критериям полноты, согласованности;
переход ввиду одной фазы к другой осуществляется впоследствии приемки-сдачи
работ с участием заказчика; выполняемые в логичной последовательности этапы
работ позволяют планировать сроки завершения всех работ, соответствующие
затраты. Каскадные модели на протяжении всего времени их существования
используются в выполнении больших проектов, в которых задействовано
несколько больших команд разработки ПП. Недостатки каскадной модели особо
остро проявляются в случае, когда трудно (или невозможно) четко сформулировать
условия а то и условия должны меняться в процессе разработки продукта.
Кроме того, любая попытка вернуться на одну а то и две фазы назад, чтобы
исправить какую-либо ошибку, приведет к значительному увеличению затрат,
нарушению сроков разработки; интеграция программных компонентов, на которой
обычно выявляется большая часть ошибок, выполняется в конце разработки, как
сильно увеличивает цена устранения ошибок; большое запаздывание с получением,
оценкой качества разрабатываемого ПП. В этом условии разработка ПП имеет
циклический характер, когда результаты очередного этапа часто вызывают
изменения в проектных решениях, выработанных на ранних стадиях.
Эти изменения связаны, как правило, с ошибками разработчиков,
допущенными на ранних стадиях разработки, выявленными на стадии
тестирования, изменениями требований в процессе разработки, связанными либо с
неготовностью заказчиков правильно сформулировать условия, либо с
изменениями требований, вызванными изменениями бизнес-процессов предметной
области. Таким образом, постоянно возникает потребность в возврате к
предыдущим этапам, уточнении а то и пересмотре ранее принятых решений. В
результате реальный процесс разработки принимает другой вид (рисунок №15).
79
Рисунок №15 Реальный процесс разработки на базе каскадной модели
Модифицированная версия каскадной модели является в значительной
степени менее жесткой, чем ее первоначальная форма. Здесь включаются итерации
промеж фазами, параллельные фазы, менеджмент изменений. Обратные стрелки
предполагают возможность существования итераций промеж действиями в рамках
фаз. Несмотря на то, как модифицированная каскадная модель является
значительно гибкой, чем классическая модель, она все же не является наилучшим
выбором в угоду исполнения проектов по причине ускоренной разработке.
Попытки оптимизации каскадной модели привели к возникновению других
типов моделей разработки ПП. Прототипирование программ позволяет обеспечить
полное понимание требований, в то время в свою очередьнкрементные,
спиральные модели позволяют повторно возвращаться к фазам, соотнесенным с
классической каскадной моделью, прежде чем полученный продукт будет признан
окончательным.
V-образная модель
V-образная модель была создана с целью помочь работающей над проектом
команде в планировании с обеспечением дальнейшей возможности тестирования
системы. В этой модели особое значение придается действиям, направленным на
верификацию, аттестацию продукта. Она демонстрирует, как тестирование
80
продукта обсуждается, проектируется, планируется на ранних этапах жизненного
цикла разработки. План испытания приемки заказчиком разрабатывается на этапе
планирования, а компоновочного испытания системы — на фазах анализа,
разработки проекта, т. д. Этот процесс разработки планов испытания обозначен
пунктирной линией промеж прямоугольниками V-образной модели (рисунок №16).
ввиду каскадной модели V-образная модель унаследовала последовательную
структуру, в соответствии с которой каждая последующая фаза начинается лишь
впоследствии успешного завершения предыдущей фазы. Модель включает в себя
следующие фазы:
составление требований к проекту, планирование — определяются системные
условия, выполняется планирование работ;
анализ требований к продукту, их спецификация — составляется полная
спецификация требований к программному продукту;
проектирование системной архитектуры (высокоуровневое проектирование) —
определяется структура программного продукта, взаимосвязи промеж основными
его компонентами, реализуемые ими функции;
детальное (техническое) проектирование— определяется алгоритм работы
каждого компонента;
разработка программного кода (кодирование) — выполняется преобразование
алгоритмов в готовый ПП;
модульное тестирование — выполняется проверка каждого компонента а то и
модуля программного продукта;
интеграционное тестирование — осуществляются интеграция модулей
программного продукта, его тестирование;
системное тестирование — выполняется проверка функционирования
программного продукта впоследствии установки его в соответствии со
спецификацией нефункциональных требований на программно-аппаратную
платформу заказчика;
эксплуатация, сопровождение — запуск программного продукта в производство.
На этой фазе в программный продукт должны вноситься поправки, может
выполняться его модернизация.
81
Рисунок №16 ЖЦ V-образной модели
Основные преимущества V-образной модели заключаются в следующем:
большая роль придается верификации, аттестации программного продукта,
начиная с ранних стадий его разработки, все действия планируются;
предполагаются аттестация, верификация не лишь самого программного продукта,
но, всех полученных внутренних, внешних данных;
ход исполнения работы может легко отслеживаться, так как завершение любой
фазы является контрольной точкой. В использовании V-образной модели в работе
над проектом, в угоду которого она не является в достаточной степени
приемлемой, становятся очевидными ее недостатки:
в модели не предусмотрено внесение условия динамических изменений на разных
этапах жизненного цикла;
тестирование требований в жизненном цикле происходит слишком поздно,
вследствие чего невозможно внести изменения, не повлияв в этом на график
исполнения проекта;
в модель не входят действия, направленные на анализ, управление рисками.
Данную модель целесообразно использовать в разработке программных продуктов,
главным требованием в угоду которых является высокая надежность, когда
82
доступными являются информация о методах решения функциональных задач,
технологии их реализации, а персонал владеет необходимыми умениями, опытом в
работе с данной технологией. Подобно своей предшественнице, каскадной модели,
V-образная модель лучше всего срабатывает тогда, когда вся информация о
условиях доступна заранее.
Модель прототипирования
Основной идеей модели прототипирования является максимальное
вовлечение пользователя в процесс разработки в угоду извлечения, описания,
корректировки реальных требований к будущему ПП. Согласно определению
Джона Коннэлла, Линда Шафера эволюционным ускоренным прототипом является
«легко поддающаяся модификации, расширению рабочая модель предполагаемой
системы, не обязательно представляющая собой все свойства системы, благодаря
которой пользователи данного приложения получают физическое представление о
ключевых частях системы до ее непосредственной реализации; это — легко
создаваемая, без труда поддающаяся модификации, максимально расширяемая,
частично заданная рабочая модель основных аспектов предполагаемой системы».
Использование модели прототипирования позволяет уже на этапе разработки
требований создавать работающий программный компонент, реализующий
отдельные функции, внешние интерфейсы разрабатываемого программного
продукта. Потенциальные пользователи работают с этим прототипом, определяя
его сильные, слабые стороны, о результатах сообщают разработчикам
программного продукта. Таким образом, обеспечивается обратная связь промеж
пользователями, разработчиками, которая используется в угоду изменения а то и
корректировки спецификации требований к программному продукту. В результате
такой работы продукт будет отражать реальные потребности пользователей. Схема
ЖЦ модели прототипирования приведена на рисунке №17. Начало жизненного
цикла разработки помещено в центре эллипса. Жизненный цикл разработки
программного продукта начинается с совместной разработки конечными
пользователями, разработчиками плана проекта, затем выполняется быстрый
анализ предметной области, формулируются предварительные условия,
проектируются база данных, пользовательский интерфейс, функционал будущего
прототипа программного продукта. В результате этой работы создается в свою
83
очередь документ, содержащий частичную спецификацию требований к
программному продукту, который в дальнейшем является основой в угоду
итерационного цикла быстрого прототипирования.
Рисунок №17 ЖЦ модели прототипирования
Следующий уровень — создание на базе разработанного документа
исходного прототипа будущего программного продукта. Далее на любой итерации
прототипирования разработчик демонстрирует пользователям вариант прототипа, а
пользователи оценивают его функциональные возможности, определяют
проблемы. Этот процесс продолжается до тех пор, пока пользователи не будут
удовлетворены степенью соответствия прототипа программного продукта
поставленным перед ним условиям. Готовый прототип демонстрируют
пользователям, он утверждается,, на его базе выполняется разработка
программного продукта. Именно на этом этапе ускоренный прототип становится
промышленным ПП, удовлетворяющим условиям заказчика. В разработке
производственной версии может понадобиться высокий уровень реализации
функциональных возможностей, подключение всевозможных системных сервисов,
необходимых, в том числе,, в угоду исполнения нефункциональных требований.
впоследствии этого следуют тестирование в предельных режимах, а затем, как
обычно, техническая поддержка процессов функционирования, сопровождения.
Модель протипирования обладает целым рядом преимуществ:
84
ознакомление заказчика с разрабатываемым ПП начинается на раннем этапе ЖЦ,
поэтому снижается вероятность возникновения путаницы, искажения данных а то и
недоразумений в определении требований к программному продукту;
в процессе разработки всегда возможно учесть новые, даже неожиданные условия
заказчика, как приводит к созданию качественного программного продукта;
прототип представляет собой формальную спецификацию, воплощенную в
программный продукт,, прототип позволяет гибко выполнять проектирование,
разработку, включая несколько итераций на всех фазах жизненного цикла
разработки; уменьшается число доработок, как снижает цена разработки:
возникающие проблемы решаются на ранних стадиях ЖЦ, как резко сокращает
расходы на их устранение; заказчики принимают участие в процессе разработки на
протяжении всего жизненного цикла и, в конечном итоге, несут ответственность за
результаты работы наравне с разработчиками. Основные недостатки модели
прототипирования заключаются в следующем:
прототипирование может продолжаться слишком долго, разработчики должны
попасть в так называемый цикл «кодирование — устранение ошибок», как
приводит к дорогостоящим незапланированным итерациям прототипирования;
разработчики, пользователи не всегда понимают, как когда прототип превращается
в конечный продукт, существует необходимость в традиционном
документировании процесса;
на очередной итерации заказчики должны быть удовлетворены качеством
прототипа, требуют его немедленной поставки, вместо того, чтобы ждать
появления полной, хорошо продуманной версии;
на разработку системы может быть потрачено слишком много времени, так в
свою очередьтерационный процесс демонстрации прототипа, его пересмотр
должны продолжаться бесконечно долго, на заказчиков может оказать негативное
влияние тот факт, как они не располагают информацией о точном количестве
итераций, которые будут необходимы;
в выборе инструментальных средств прототипирования (операционные системы,
технологии проектирования, языки программирования, алгоритмы решения
функциональных задач) разработчики должны остановить свой отбор на
неэффективных решениях, лишь чтобы продемонстрировать свои способности.
85
Модель прототипирования рекомендуется применять в случаях когда:
выполняется новая, не имеющая аналогов разработка;
заказчик неохотно соглашается на фиксированный отбор требований, условия к
программному продукту заранее неизвестны, должны уточняться в процессе
разработки;
разработчики не уверены, какие решения относительно пользовательского
интерфейса, функционала следует выбрать, какую оптимальную архитектуру а то и
алгоритмы следует применять.
2.1.2. Ожидаемые риски на этапах жизненного цикла, их описание
Ниже приводится краткое представление характеристик, требований к
команде разработчиков, коллективу пользователей, типу проекта. В таблице № 1
приведен отбор матриц, предназначенных в угоду выбора модели жизненного
цикла.
Условия. Категория требований (таблица №3) состоит из вопросов относительно
требований, которые предъявляет пользователь к проекту. В терминологии их
иногда называют свойствами системы, которая будет поддерживаться записям
проектом. [10]
86
Таблица №3.
Отбор модели жизненного цикла на базе характеристик требований