Аналіз переваг та недоліків застосування каскадної моделі
Каскадна модель набула дуже широкого поширення і використовується на практиці вже більш ніж 30 років. За всі ці роки використання дана модель здобула багато прихильників і багато противників.
Проаналізуємо дану модуль та виділимо її основні слабкі та сильні сторони.
Основні переваги даної систем:
дана модель є простою та зрозумілою, вимогою для успішного завершення програмного продукту є виконання запланованих дій; фази моделі гарно визначені;
каскадна модель дозволяє учасникам проекту, що закінчили своїх фази, брати участь в інших проектах;
зручна для використання менеджером проекту: сприяє здійсненню строго контролю над перебігом проекту, полегшує роботу над розробкою проектного плану;
забезпечує гарний контроль над якістю проекту. Усі закінчені фази та отримані дані підлягають огляду. Ця процедура забезпечує визначення якості програмної системи.
Розглянемо тепер основні недоліки даної моделі:
значене збільшення затрат та значні зміни в плануванні при необхідності виправити помилку в одній з попередніх фаз. Оскільки дана модель має лінійну структуру, то при бажанні повернутися на якусь з попередній фаз для виправлення знайдених помилок, необхідно буде пройти всі ці фази ще раз;
модель не розрахована на динамічну адаптацію до потреб ринку та клієнту. Всі нові вимоги для проекту повинні бути сформовані на початку, а це унеможливлює додання нових вимог під час розробки продукту;
замовник не має можливості ознайомитися з системою до стадії її запуску в експлуатацію. Оскільки розробка системи цільним шматком, користувач не має можливості скористатися проміжними результатами та надати розробникам всім відгук про розроблену систему. Тестування системи замовником відбувається лише і кінці проекту, а це збільшує вартість внесення модифікацій основаних на відгуку користувача;
неможливість випустити програмний продукт вчасно при виникненні певних проблем з плануванням. При виникненні затримок з розробкою програмного продукту (наприклад реальний час необхідний на розробку вимог перевищує в 2 рази запланований на початку проекту), неможливо адаптуватися до даної ситуації без зміни дати випуску програмного продукту. Інформація про можливі проблеми з'являється занадто пізно.
Отже, дана модель є простою, зручно для використання, контролю якості розроблюваної системи. Але при використанні її для непідходящих проектів може викликати певні проблеми з адаптацією до ринку, збільшенню незапланованих витрат та не передбачуваних змін у графіку розробки.
Інкрементна модель життєвого циклу
При використанні інкрементної моделі, яку називаються також запланованим удосконаленням продукту, розробка здійснюється як поетапний процес послідовного наближення системи до її остаточного виду. В даній моделі зменшення витрат, які були до моменту створення повної версії, досягається за рахунок поетапного нарощування функціональних можливостей або продуктивності системи. При цьому кожна наступна версія системи збагачує попередню певними функціональними можливостями до тих пір, поки не будуть реалізовані всі вимоги до системи.
Інкрементна модель передбачає розбиття життєвого циклу проекту на послідовність ітерацій, кожна з яких ж невеликим проектом, включаючи всі стадії життєвого циклу в застосуванні до створення менших фрагментів функціональності, в порівнянні з проектом в цілому. Ціль кожної ітерації - отримання працюючої версії програмної системи, включаючи функціональність всіх попередніх та поточної ітерації. Схематично Інкрементна модель життєвого циклу зображена на рис 3.1.
Рис. 3.1
– Інкрементна модель
життєвого циклу
З точки зору структури життєвого циклу таку модуль називають ітераційною, а з точки зору розвитку продукту - інкрементною.
Такий підхід дозволяє зменшити затрати, понесені до моменту досягнення рівня необхідної продуктивності. За допомогою цієї системи прискорюється процес створення функціонуючої системи. Цьому сприяє застосований принцип компонування зі стандартних блоків, завдяки чому забезпечується контроль над процесом розробки змінний вимог.
Інкрементна модель діє за принципом каскадної моделі, завдяки чому функціональні можливості продукту, придатні для застосування , формуються раніше. Для цього може знадобитися повний завчасно сформований набір вимог, які виконуватимуться у вигляді послідовних, невеликих за розміром, або виконання проекту можу початися з формування загальних цілей, які потім уточнюються і реалізуються групами розробників.
Інкремента модель описує процес при виконанні якого першочергова уваги приділяється системним вимогам, а потім їх реалізація групах розробників. Як правило, з часом тривалість інкрементів з часом зменшується. Кожна наступна версія системи додає до попередньої системи нові функціональні можливості до тих пір поки не будуть реалізовані усі заплановані можливості. На рис. 3.2 схематично зображено процес розширення функціоналу в інкремнентній моделі.
Рис. 3.2 – Зниження невизначеності та інкрементне розширення функціональності при ітеративній організації життєвого циклу
Передбачається, що на початкових етапах життєвого циклу відбувається конструювання системи в цілому. На цих етапах визначаються інкременти та функції. Кожен інкремент потім проходить через інші фази життєвого циклу (кодування, тестування та поставка).
Спочатку виконується конструювання, тестування та реалізація набору функцій, що формують основу продукту, чи найбільш пріоритетні вимоги, що грають основну роль для успішного виконання проекту. Наступні ітерації поширюються на ядро системи, поступово покращуючи її функціональні можливості чи робочі характеристики.