Каскадная модель. Реализация стратегий разработки ПС в различных моделях проектирования

Реализация стратегий разработки ПС в различных моделях проектирования

Стратегии разработки программных средств

В проектировании ПС используются три стратегии конструирования ПО - классическая линейная, инкрементная и спиральная

Классическая стратегия (называемая иногда «водопадной») характеризуется линейной последовательностью этапов конструирования.

Инкрементная стратегия предполагает, что в начале процесса разработки определяются все пользовательские и системные требования, а конструирование выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и так до тех пор, пока не будет получена полная система.

Эволюционная стратегия также предлагает построение системы в виде набора версий, но в начале процесса разработки могут быть определены не все требования, они уточняются в процессе разработки версий.

Характеристики стратегий конструирования ПО в соответствии с требованиями стандарта IEEE/EIA 12207.2 приведены в таблице 2.

Таблица 2.2

Старейшей парадигмой процесса разработки ПО является классический жизненный цикл, реализованный в каскадной модели проектирования (автор Уинстон Ройс, 1970).

В этой модели разработка рассматривается как последовательность этапов, причем переход на следующий, иерархически нижний этап происходит только после полного завершения работ на текущем этапе (рис. 2.2).

Рис.2.2. Каскадная модель разработки

Содержание основных этапов может быть охарактеризовано следующим образом.

Разработка начинается на системном уровне и проходит через анализ, проектирование, кодирование, тестирование и сопровождение. При этом моделируются действия стандартного инженерного цикла.

Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Поскольку ПО является лишь частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, базами данных). На этом же этапе начинается решение задачи планирования проекта ПО. В ходе планирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.

Анализ требований относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Проектирование состоит в создании представлений:

· архитектуры ПО;

· модульной структуры ПО;

· алгоритмической структуры ПО;

· структуры данных;

· входного и выходного интерфейса (входных и выходных форм данных).

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

Кодирование состоит в переводе результатов проектирования в текст на языке программирования.

Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение — это внесение изменений в эксплуатируемое ПО со следующими целями:

· исправление ошибок;

· адаптация к изменениям внешней для ПО среды;

· усовершенствование ПО по требованиям заказчика.

Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла к существующей программе, но не в разработке новой программы.

Как и любая инженерная схема, каскадная модель разработки имеет достоинства и недостатки. Достоинствами является наличие плана и временного графика по всем этапам проекта, упорядоченность хода конструирования.

Недостатки классического подхода также существенны:

· реальные проекты часто требуют отклонения от стандартной последовательности шагов;

· цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);

· результаты проекта доступны заказчику только в конце работы.