11. Еволюційна модель розробки програмного забезпечення. Переваги та недоліки.

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

Розрізняють два підходи до реалізації еволюційного методу розробки.

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

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

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

Більш докладно підходи до еволюційної розробці розглядаються в розділі 8, де описані різні технології прототипування систем.

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

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

2. Система часто виходить погано структурованою. Постійні зміни у вимогах призводять до помилок і упущень в структурі ПЗ. З часом внесення змін до системи стає все більш складним і витратним.

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

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

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