Инкрементальная модель жизненного цикла

UR – требования пользователей

SR – системные требования

AD – проектирование архитектуры

DD – детальное проектирование

TR – передача пользователю

OM – эксплуатация и обслуживание

Преимущества инкрементной модели: в результате выполнения каждого инкремента получается функциональный продукт, заказчик располагает возможностью высказаться по поводу каждой разработанной версии системы; сокращается время и снижаются затраты на первоначальную поставку программного продукта, снижается риск неудачи и изменения требований; заказчики могут распознавать самые важные и полезные функциональные возможности продукта на ранних этапах разработки; улучшается понимание требований для более поздних инкрементов, что обеспечивается благодаря возможности пользователя получить представление о ранее полученных инкрементах на практическом уровне; использование последовательных инкрементов позволяет объединить полученный пользователями опыт в виде усовершенствованного продукта, затратив при этом намного меньше средств, чем требуется для выполнения повторной разработки; Недостатки инкрементной модели: выделение инкрементов, определение требований и полной функциональной системы должно осуществляться в начале жц; поскольку создание некоторых модулей завершается значительно раньше других, возникает необходимость в четко определенных интерфейсах; использование на этапе анализа общих целей вместо полностью сформулированных требований может оказаться неудобным для руководства; для использования инкрементной модели необходимо тщательное планирование работ и подробное архитектурное проектирование; Инкрементные модели целесообразно использовать при наличии следующих предпосылок: 1) если большинство требований и функционал можно сформулировать заранее, но их появление ожидается через определенный период времени; 2) если рыночное окно слишком «узкое» и есть потребность в быстрой поставке на рынок продукта, имеющего функциональные базовые свойства; 3) для проектов, на выполнение которых предусмотрен большой период времени разработки, как правило, более одного года; 4) при разработке программ, связанных с низкой или средней степенью риска;Востребована при разработке веб-приложений и продуктов компаний-брендов.

V-образная модель

V-образная модель представляет собой итерационную разновидность каскадной модели и предполагает уже на ранних этапах жц планирование работ по тестированию пп. Основные преимущества V-образной модели заключаются в следм:особое значение придается верификации и аттестации ПП, планированию всех действий, начиная с ранних стадий его разработки; предполагается аттестация и верификация не только самого ПП, но и всех полученных внутренних и внешних данных; ход выполнения работы может легко отслеживаться, так как завершение каждой фазы является контрольной точкой. При использовании V-образной модели в работе над проектом, для к-го она не является в достаточной степени приемлемой, становятся очевидными ее недостатки: в модели не предусмотрено внесение требования динамических изменений на разных этапах жц; тестирование требований в жц происходит слишком поздно, вследствие чего невозможно внести изменения, не повлияв при этом на график выполнения проекта; в модель не входят действия, направленные на анализ и управление рисками. Данную модель целесообразно использовать при разработке ПП, главным требованием для к-х является высокая надежность, когда доступной является инф-я о методах решения функциональных задач и технологии их реализации, а персонал владеет необ-ми умениями и опытом работы с данной технологией. Подобно своей предшественнице, каскадной модели, V-образная модель лучше всего срабатывает в случаях, когда вся информация о требованиях доступна заранее