Каскадна модель
Стандарт ISO/IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ (під моделлю ЖЦ розуміється структура, що визначає послідовність виконання й взаємозв'язки процесів, дій і завдань, виконуваних протягом ЖЦ. Модель ЖЦ залежить від специфіки ИС і специфіки умов, у яких остання створюється й функціонує). Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO/IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії й завдання, включені в ці процеси.
До теперішнього часу найбільше поширення одержали наступні дві основні моделі ЖЦ:
каскадна модель ( 70-85 р.);
спіральна модель ( 86-90 р.).
У споконвічно існуючих однорідних ИС кожний додаток являло собою єдине ціле. Для розробки такого типу додатків застосовувався каскадний спосіб. Його основною характеристикою є розбивка всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному (рис). Кожний етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розроблювачів.
Позитивні сторони застосування каскадного підходу полягають у наступному:
на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти й погодженості;
виконувані в логічній послідовності етапи робіт дозволяють планувати строки завершення всіх робіт і відповідні витрати.
Каскадна схема розробки ПЗ.
Каскадний підхід добре зарекомендував себе при побудові ИС, для яких на самому початку розробки можна досить точно й повно сформулювати всі вимоги, для того щоб надати розроблювачам волю реалізувати їх якнайкраще з технічної точки зору. У цю категорію попадають складні розрахункові системи, системи реального часу й інші подібні завдання. Однак, у процесі використання цього підходу виявився ряд його недоліків, викликаних насамперед тим, що реальний процес створення ПЗ ніколи повністю не укладався в таку тверду схему. У процесі створення ПЗ постійно виникала потреба в поверненні до попередніх етапів і уточненні або перегляді раніше ухвалених рішень. У результаті реальний процес створення ПЗ приймав наступний вид (мал.):
. Реальний процес розробки ПЗ за каскадною схемою
Основним недоліком каскадного підходу є істотне запізнювання з одержанням результатів. Узгодження результатів з користувачами виробляється тільки в крапках, планованих після завершення кожного етапу робіт, вимоги до ИС "заморожені" у вигляді технічного завдання на увесь час її створення. Таким чином, користувачі можуть внести свої зауваження тільки після того, як робота над системою буде повністю завершена. У випадку неточного викладу вимог або їхньої зміни протягом тривалого періоду створення ПЗ, користувачі одержують систему, що не задовольняє їхнім потребам. Моделі (як функціональні, так і інформаційні) об'єкта можуть застаріти одночасно з їхнім твердженням.
2. V – модель
Дану модель також можна представити у вигляді спадного проектування й висхідної реалізації:
Переваги цієї моделі:
це дискретний (у часі) технологічний процес із зупинками по завершенню кожного етапу з можливістю контролю й повторення етапу при незадовільних результатах (тобто, ітерацій розробки);
розподіл на рівні абстракції дозволяє формувати документацію різного ступеня деталізації й формулювати критерії перевірки правильності прийнятих розв'язків до реалізації проекту, що сприяє попередженню помилок проектування;
концепція вимагає не переходити до чергового етапу до повного завершення попереднього – сильна вимога.
Недоліки моделі:
чим раніше допущена помилка, тем пізніше вона може бути виявлена. Чим пізніше виявлена помилка, тем дорожче її виправлення - більше етапів повернення. Тому ціль гарної технології - можливо більш раннє виявлення й попередження помилок, що досягається ретельним проектуванням.
Приклад (Mайерс, «Надійність ПЗ», 1986 р.) - команда ціною в 110 тис.$: у готовому софті бортового винищувача на стадії літних випробувань була виявлена помилка, для виправлення якої було змінено 9 команд, а заплатили за цю роботу 1 млн. $.
нав'язується стратегія проектування зверху вниз, що підходить тільки для добре специфікованих невеликих проектів, в основному прикладним. Складні системи або створюються вроздріб (як місто) або ростуть (еволюціонують), як природні об'єкти;
велика тривалість повного циклу розробки: замовники/користувачі можуть побачити перші результати дуже пізно, тільки по завершенню всього проекту й побажати радикально змінити вимоги. Вимоги конкурентного ринку змушують максимально скорочувати цикл розробки;
модель, створена на початку 70-х, розрахована на проектування "за столом", не враховує прискорення циклу кодування-налагодження в епоху персональних комп'ютерів;
психологічна причина: розробляти проектну документацію нудно.