Модели ЖЦ программных средств.
Модель ЖЦ – это структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение ПП, охватывающая жизнь системы от установления требований к ней до прекращения ее использования.
Наибольшее распространение получили 2 модели:
- каскадная (70-80 г. 20 в.);
- спиральная (80-90 г. 20 в.).
Каскадная модель. Разработка ПС разбивается на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем. Каждый этап завершается выпуском полного комплекта документов с тем, чтобы разработка могла быть продолжена другой командой разработчиков.
 |
Положительные стороны каскадного подхода:
- на каждом этапе формируется законченный набор проектной документации, отвечающей критериям полноты и согласованности;
- выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения и затраты.
Способ хорошо зарекомендовал себя при построении ИС, для которых в начале разработки можно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения. Это сложные расчетные системы, системы реального времени.
Отрицательные стороны:
- реальный процесс создания ПС никогда полностью не укладывался в такую жесткую схему, постоянно возникала потребность к возврату к предыдущим этапам, уточнении и пересмотре ранее принятых решений.
- существенное запаздывание с получением результатов. Согласование результатов с пользователями проводится только после завершения каждого этапа работ, требования к ИС «заморожены» в виде технического задания на все время ее создания. А пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменений при создании ПС пользователи в результате получают систему, не удовлетворяющую их потребностям. Модели автоматизированного объекта могут устареть одновременно с их утверждением.
Для преодоления этих недостатков была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ – анализ и проектирование. На этом этапе реализуемость технического решения проверяется созданием прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПС, на нем уточняются цели и характеристики проекта, определяется качество и планируются работы следующего витка. Таким образом, углубляются и последовательно конкретизируются детали проекта, в результате выбирается обоснованный вариант, который доводится до реализации.
Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работ на текущем. Это – разработка итерациями. Главная задача – как можно скорее показать работоспособный продукт пользователям, с тем, чтобы уточнить и дополнить требования.
Определение целей,
альтернатив Идентификация
и ограничений и разрешение
рисков, оценка альтернатив
|
| |||
|
Планирование следующей
итерации Разработка продукта
на очередной итерации
Достоинствами спиральной модели являются:
– Ускорение разработки (раннее получение результата за счет прототипирования);
– Постоянное участие заказчика в процессе разработки;
– Разбиение большого объема работы на небольшие части;
– Снижение риска (повышение вероятности предсказуемого поведения системы).
Спиральная модель не исключает использование каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными.
К недостаткам спиральной модели можно отнести:
– Сложность планирования (определения количества и длительности итераций, оценки затрат и рисков);
– Сложность применения модели с точки зрения менеджеров и заказчиков (из-за привычки к строгому и детальному планированию);
– Напряженный режим работы для разработчиков (при краткосрочных итерациях).
Основная проблема спирального цикла – определение момента перехода на следующий этап. Для этого необходимо ввести временные ограничения на каждый из этапов ЖЦ. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.