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