Модели ЖЦ ПСКаскадная стратегия представляет собой однократный проход этапов разработки. Данная стратегия основана на полном определении всех требований к разрабатываемому программному средству или системе в начале процесса разработки. Каждый этап разработки начинается после завершения предыдущего этапа. Возврат к уже выполненным этапам не предусматривается. Промежуточные продукты разработки в качестве версии программного средства (системы) не распространяются. Представителями моделей, реализующих каскадную стратегию, являются каскадная и V-образная модели. Каскадные (водопадные) модели реализуют каскадную стратегию однократного прохода этапов разработки ПС(Рис.41.1). Каждый последующий шаг разработки начинается после полного завершения выполнения предыдущего шага. На всех шагах модели по необходимости выполняются вспомогательные и организационные процессы, например, управление проектом, обеспечение качества, верификация, аттестация, управление конфигурацией, документирование. Результатами завершения шагов модели являются промежуточные продукты разработки, которые не могут изменяться на последующих шагах и не могут сдаваться заказчику в качестве версий программного средства.
Классическая каскадная модель Разработаны варианты каскадной модели с обратными связями между ее отдельными шагами. Возможна организация обратных связей между любыми шагами каскадной модели. Это позволяет выполнять исправление промежуточных продуктов предыдущих шагов процесса разработки. При этом возрастает сложность планирования и финансирования проекта, достаточно высок риск нарушения графика разработки. V-образная модель поддерживает каскадную стратегию разработки. В ней выделены связи между шагами, предшествующими программированию, и соответствующими видами тестирования и испытаний. Данные связи увязывают деятельность по разработке планов испытаний и тестирования с деятельностью по подтверждению результатов соответствующих этапов. В V-образной модели возможна организация обратных связей между этапами модели. Связи между деятельностью по разработке планов испытаний и тестирования и деятельностью по подтверждению результатов соответствующих этапов на рис. 41.3 обозначены пунктирными линиями.
V-образная модель жизненного цикла Инкрементная стратегия представляет собой многократный проход этапов разработки с запланированным улучшением результата. Данная стратегия основана на полном определении всех требований к разрабатываемому программному средству или системе в начале процесса разработки. Однако полный набор требований реализуется постепенно в соответствии с планом в последовательных циклах разработки. При инкрементной стратегии часто используется прототипирование. Под прототипом понимается легко поддающаяся модификации и расширению рабочая модель разрабатываемого программного средства (или системы), позволяющая пользователю получить представление о его ключевых свойствах до полной реализации. Современной реализацией инкрементной стратегии является экстремальное программирование. В классических вариантах инкрементная модель основана на использовании полного заранее сформированного набора требований, реализуемых последовательно в виде небольших проектов. Существуют варианты инкрементной модели, начинающиеся с формулирования общих целей, которые постепенно уточняются в процессе разработки прототипов.
Инкрементная модель жизненного цикла Существуют варианты модели, начинающиеся с формулирования общих требований. Требования постепенно уточняются в процессе разработки прототипов. Данные варианты инкрементных моделей похожи на эволюционные модели. Однако от последних они отличаются существенно большим количеством инкрементов при гораздо меньших различиях между соседними инкрементами. К таким вариантам моделей относится, например, модель ЖЦ, реализующая современную реализацию инкрементной стратегии – экстремальное программирование. Данная модель может использоваться в том случае, когда требования заказчика неопределенны или постоянно изменяются. Модель отличается гибкостью, поскольку она ориентирована на высокую степень неопределенности спецификации требований. В модели выполняется однократная разработка архитектуры системы и ПС. Реализация каждого требования заказчика выполняется с учетом его стоимости и целесообразности. Каждая версия системы реализуется итерационно.
Вариант инкрементной модели экстремального программирования Эволюционная стратегия представляет собой многократный проход этапов разработки. Данная стратегия основана на частичном определении требований к разрабатываемому программному средству или системе в начале процесса разработки. Требования постепенно уточняются в последовательных циклах разработки. Результат каждого цикла разработки обычно представляет собой очередную поставляемую версию программного средства или системы. Для эволюционной стратегии характерно существенно меньшее количество циклов разработки при большей продолжительности цикла по сравнению с инкрементной стратегией. При этом результат каждого цикла разработки (очередная версия программного средства или системы) гораздо сильнее отличается от результата предыдущего цикла. При эволюционной стратегии часто используется прототипирование. В данном случае основной целью прототипирования является обеспечение полного понимания требований. Оно позволяет итеративно уточнять требования к продукту при достижении предельно высокой производительности разработки проекта и одновременном снижении затрат. Представителями моделей, реализующих эволюционную стратегию, являются, например, спиральные модели. Спиральная Модель Института Управления проектами PMI
Модель Института управления проектами PMI,адаптированная к требованиям стандарта СТБ ИСО/МЭК 12207–2003 Модель базируется на применении четырех итерационных циклов: -цикл доказательства концепции (внутренний виток спирали); - цикл первой версии (второй виток спирали); - цикл очередной версии (третий виток спирали); - цикл конечной версии (внешний виток спирали). В цикле доказательства концепции выполняются следующие этапы работ: 1 – анализ начальных требований (требований заказчика); 2 – концептуальное проектирование; 3 – конструирование концептуального прототипа; 4 – анализ рисков. В цикле первой версии выполняются следующие этапы работ: 5 – анализ требований к системе; 6 – проектирование системы; 7 – конструирование первой версии; 8 – квалификационные испытания и оценка. В цикле очередной версии выполняются следующие этапы работ: 9 – анализ требований к ПС системы; 10 – проектирование ПС; 11 – конструирование очередной версии, а также этап 8 квалификационных испытаний и оценки. В цикле конечной версии выполняются следующие этапы работ: 12 – анализ требований к программным модулям; 13 – проектирование программных модулей; 14 – конструирование конечной версии,а также этап 8 квалификационных испытаний и оценки. 15 – ввод в действие и обеспечение приемки; 16 – эксплуатация и сопровождение. Этапы заказной разработки: Этап 0. Технико-коммерческое предложение - документ, в котором кратко перечислены требования заказчика и предложения по разработке программной системы в соответствии с этими требованиями. В этом документе также приблизительно оценивается трудоемкость работ по проекту и его стоимость (окончательная стоимость работ может быть определена только после разработки технического задания. см. далее). Этап 1. Обследование и разработка технического задания - документ, состоящий, как правило, из требований к составу и требований к функционированию системы. В большинстве случаев ТЗ так же описывает интерфейсы взаимодействия, схемы данных, логику действий программы. Этап 2. Проектирование и разработка программы - осуществляется создание ПО согласно утвержденному ранее техническому заданию и смете. Этап 3. Тестирование - процесс выполнения программы при различных тестовых наборах данных с целью обнаружения ошибок. Этап 4. Внедрение в опытную эксплуатацию – передача ПС заказчику, установка его на ПК заказчика.
|
