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