Класичний життєвий цикл

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

Частіше класичний життєвий цикл називають КАСКАДНОЮ або ВОДОСПАДНОЮ моделлю, підкреслюючи, що розробка розглядається як послідовність етапів, причому перехід на наступний ієрархічно нижній етап відбувається тільки після повного завершення робіт на поточному етапі і повернення до пройдених етапів не передбачається. (див. мал. нижче)

М алюнок - Класичний життєвий цикл розробки ПО.

Приведемо короткий опис основних етапів. Розробка починається на системному рівні і проходить через

- аналіз

- проектування

- кодування (реалізація)

- тестування

- супровід

При цьому моделюються дії стандартного інженерного циклу.

Системний аналіз визначає роль кожного елементу в комп'ютерній системі, взаємодію елементів один з одним.

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

На цьому етапі починається рішення задачі планування проекту ПО.

В ході планування проекту визначаються:

- об'єм проектних робіт

- ризик проектних робіт

- необхідні трудовитрати

- формуються робочі завдання

- формується план-графік робіт.

Аналіз вимог, що відноситься до програмного елементу, тобто до програмного забезпечення (ПЗ), уточнює і деталізує:

- функції ПЗ

- характеристики ПЗ

- інтерфейс ПЗ.

Усі визначення документуються в специфікації аналізу.

Проектування створює представлення:

- архітектура ПЗ

- модульної структури ПЗ

- алгоритмічної структури ПЗ

- структури даних

- вхідного і вихідного інтерфейсу (вхідних і вихідних форм даних).

Кодування (реалізація) полягає в перекладі результатів проектування в текст на мові програмування.

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

Супровід - це внесення змін до експлуатованого ПЗ.

Цілі змін :

- виправлення помилок

- адаптація до змін зовнішньої для ПЗ середовища

- удосконалення ПЗ на вимогу замовника.

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

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

Достоїнствами класичного життєвого циклу є:

- отримання плану і тимчасового графіку по усіх етапах проекту

- впорядкування ходу розробки.

До недоліків класичного життєвого циклу відносяться:

- часте відхилення реальних проектів від стандартної послідовності кроків

- основанность циклу на точному формулюванні початкових вимог до ПЗ, тоді як реально на початку проекту вимоги замовника визначені лише частково

- доступність результатів проекту замовникові лише у кінці роботи.

Макетування (прототипирование)

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

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

Модель може приймати одну з трьох форм :

- паперовий макет або макет на основі ПК (зображує або малює человеко - машинний діалог)

- працюючий макет (виконує деяку частину необхідних функцій)

- існує програма, характеристики якої потім мають бути поліпшені.

Макетування грунтується на багатократному повторенні ітерацій, в

яких беруть участь замовник і розробник.

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

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

Гідністю макетування є забезпечення визначення повних вимог до ПЗ.

До недоліків макетування відносяться:

- можливість прийняття замовником макету за продукт

- можливість прийняття розробником макету за продукт

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