Застосовність каскадної моделі

Каскадна модель вперше описана в 1970 році автором її був У.Ройс. На початку каскадна модель була методом регулярної розробки складного ПЗ. У 70х-80х років 20 століття каскадна модель була стандартом міністерства оборони США. Згодом недоліки КМ (каскадної моделі) проявляються все більше ; часто приходили до висновку, що каскадна модель безнадійно застаріла. КМ не втратила до сих пір своєї актуальності коли вимоги і їх реалізація чітко визначені та зрозумілі; коли цілком зрозумілі та прості технології та методики розробки ПЗ. Приклади завдань такого типу:

1. Пакети та бібліотеки програм науково обчислювального характеру.

2. Операційні системи та компілятори.

КМ є ефективною в умовах:

1. Повторна розробка типового продукту.

2. Перенесення існуючого продукту на нову платформу (Нова версія існуючого ПЗ, коли вимоги до змін цілком визначені та керовані) .

3. Використання КМ, як елементу моделей змішаного типу.

На практиці розробка ПЗ має циклічний характер. Тобто після виконання деяких етапів, потрібно повертатися на попередній.

Основні причини таких повернень:

1. Помилки розробників, виявлені на пізніших етапах.

2. «Помилка» замовника (неготовий сформулювати вимоги, неготовність сформулювати вимоги. Також можуть відбуватися зміни вимог викликані змінами ринку, змінами на ринку, новими технологіями).

Спіральна модель

Циклічних характер розробки ПЗ враховано в спіральній моделі, описаній в 1988 році автором Б.Боем. Спіральна модель пропонувалася, як альтернатива каскадні моделі.

Пояснення схеми

Розробка варіантів продукту представляється набором циклів спіралі, яка розкручується. Початкові фази ЖЦ пов‘язані з аналізом та плануванням, представлено детально, додано нові елементи. У кожному циклі виділено 4 базові фази. Перша фаза – «Визначення цілей, альтернатив, обмежень»; друга фаза – «Перевірка альтернатив, виявлення і вирішення ризиків»; третя фаза – «Розробка наступного рівня»; четверта фаза – «Планування наступних фаз».

1. Перший цикл

1. Розкрутка проекту (Аналіз загальної постановки завдання. Визначаються загальні цілі проекту, попередні обмеження, розглядаються можливі альтернативні підходи до вирішення завдання).

2. Проводиться оцінка альтернативних методів вирішення завдання, для кожного з них встановлюються ризики.

3. На фазі розробки створюється концепція ( загальне бачення майбутнього програмного продукту та вибираються методи розробки.

2. Другий цикл

1. Плануються вимоги та оцінюються витрати

2. Встановлюються альтернативні варіанти вимог пов‘язані з впорядкуванням вимог за важливістю та вартістю їх реалізації.

3. Оцінюються ризики для різних варіантів вимог.

4. На фазі розробки створюється специфікація вимог з вказівкою ризику та вартості вимог, готується демо версія програмного забезпечення для аналізу вимог замовника.

3. Третій цикл (розробка проекту)

   1. Планування розробки

   2. Визначаються обмеження проекту за термінами, обсягом фінансування, ресурсами. Визначаються альтернативні методи проектування пов‘язані із застосуванням з різними технологіями.

   3. Встановлюються ризики різних варіантів, вибираються оптимальні варіанти.

   4. Виконується проектування та створюється чергова демо версія.

4. Четвертий цикл (завершальний цикл)

   1. Планування. Альтернативні варіанти реалізації визначаються різними технологіями та ресурсами.

   2. Оцінка ризиків визначається ступенем відпрацьованості технологій та ресурсів.

   3. Фаза розробки виконується за каскадною моделлю; на виході діючий варіант ( прототип продукту)