3. Моделі життєвого циклу пз

Всі стандарти життєвого циклу ПЗ так чи інакше намагаються описати, як повинен виглядати будь-який процес розробки ПЗ. При цьому вони вимушені вводити дуже загальні моделі життєвого циклу ПЗ, які важко використовувати при організації конкретного проекту.

В рамках специфічних моделей життєвого циклу, які наказують правила організації розробки ПЗ в рамках даної галузі або організації, визначаються конкретніші процеси розробки. Відрізняються вони від стандартів, перш за все, більш детальним і чітким описом зв'язків між окремими видами діяльності, визначенням потоків даних (документів і артефактів) в ході життєвого циклу. Таких моделей досить багато, адже фактично кожного разу, коли деяка організація визначає власний процес розробки, як основа цього процесу розробляється деяка модель життєвого циклу ПЗ. В рамках даної лекції ми розглянемо лише декілька моделей. На жаль, дуже важко вибрати критерії, по яких можна було б дати хоч скільки-небудь корисну класифікацію відомих моделей життєвого циклу.

Найбільш широко відомою і вживаною довгий час залишалася так звана каскадна або водопад (waterfall) модель життєвого циклу, яка, як вважається, була вперше чітко сформульована в роботі [16] і згодом відображена в стандартах міністерства оборони США в 70-80-х роках XX століття. Ця модель припускає послідовне виконання різних видів діяльності, починаючи з вироблення вимог і закінчуючи супроводом, з чітким визначенням меж між етапами, на яких набір документів, створений на попередній стадії, передається як вхідні дані для наступної. Таким чином, кожен вид діяльності виконується на якійсь одній фазі життєвого циклу. Пропонована в статті [16] послідовність кроків розробки показана на рис. 2.2. "Класична" каскадна модель припускає тільки рух вперед по цій схемі: все необхідне для проведення чергової діяльності повинно бути підготовлено в ході попередніх робіт.

Позитивні сторони застосування каскадного підходу полягають в наступному:

• на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти і узгодженості;

• виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.

Мал. 2.2. Послідовність розробки згідно "класичної" каскадної моделі

Каскадний підхід добре зарекомендував себе при побудові ІС, для яких на самому початку розробки можна достатньо точно і повно сформулювати всі вимоги, з тим щоб надати розробникам свободу реалізувати їх якнайкраще з технічної точки зору. У цю категорію потрапляють складні розрахункові системи, системи реального часу і інші подібні завдання.

При реальній роботі відповідно до моделі, що допускає рух тільки в один бік, зазвичай виникають проблеми при виявленні недоробок і помилок, зроблених на ранніх етапах. Але ще важче мати справу із змінами оточення, в якому розробляється ПЗ (це можуть бути зміни вимог, зміна підрядчиків, зміни політик розробляючої або експлуатуючої організації, зміни галузевих стандартів, поява конкуруючих продуктів і ін.).

Працювати відповідно до цієї моделі можна, тільки якщо вдається передбачати наперед можливі перипетії ходу проекту і ретельно збирати і інтегрувати інформацію на перших етапах, з тим щоб згодом можна було користуватися їх результатами не оглядаючись на можливі зміни.