Недоліки каскадної моделі

Перелік недоліків каскадної моделі при її використанні для розробки інформаційних систем досить великий:

· суттєва затримка отримання результатів;

· помилки і недоробки на будь-якому з етапів з'ясовуються, як правило, на наступних етапах робіт, що призводить до необхідності повернення на попередні стадії;

· складність розпаралелювання робіт за проектом;

· надмірна інформаційна перенасиченість кожного з етапів;

· складність управління проектом;

· високий рівень ризику і ненадійність інвестицій.

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

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

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

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

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

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

5) Складність управління проектом при використанні каскадної схеми в основному обумовлена ​​строгою послідовністю стадій розробки та наявністю складних взаємозв'язків між різними частинами проекту.

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

У разі ж виявлення помилок у виконаній роботі необхідне повернення до попередніх етапів виконання проекту. Це призводить до додаткових складностей в управлінні проектом. Розробники, які допустили прорахунок або помилку, вимушені перервати поточну роботу (над новим проектом) і зайнятися виправленням помилок. Наслідком цього зазвичай є зрив термінів виконання як виправляється, так і нового проектів. Вимагати ж від команди розробників очікування закінчення наступної стадії розробки нераціонально, так як призводить до істотних втрат робочого часу.

Спростити взаємодію між групами розробників і зменшити інформаційну перенасиченість документації можна, зменшуючи кількість зв'язків між окремими частинами проекту. Однак це зазвичай вельми непросто. Далеко не кожну інформаційну систему можна розділити на кілька слабко пов'язаних підсистем.

6) Високий рівень ризику. Чим складніше проект, тим більше тривалість кожного з етапів розробки і тим складніше взаємозв'язку між окремими частинами проекту, кількість яких також збільшується. Причому результати розробки можна реально побачити і оцінити лише на етапі тестування, тобто після завершення аналізу, проектування і розробки - етапів, виконання яких вимагає значного часу та коштів. Як вже було зазначено вище, запізніла оцінка створює значні проблеми при виявленні помилок аналізу і проектування - потрібно повернення проекту на попередні стадії і повторення процесу розробки.

Проте повернення на попередні стадії може бути пов'язаний не тільки з помилками, але і з змінами, що відбулися за час виконання розробки в предметній області або у вимогах замовника. Причому повернення проекту внаслідок цих причин на доопрацювання не гарантує, що предметна область знову не зміниться до того моменту, коли буде готова наступна версія проекту. Фактично це означає, що існує ймовірність того, що процес розробки «зациклиться» і ніколи не дійде до здачі в експлуатацію. Витрати на проект будуть постійно рости, а терміни здачі готового продукту - постійно відкладатися.

Тому можна стверджувати, що складні проекти, що розробляються по каскадної схемою, мають підвищений рівень ризику. Цей висновок підтверджується практикою: за відомостями консалтингової компанії The Standish Group, в США більше 31% проектів корпоративних інформаційних систем (IT-проектів) закінчується неуспіхом; майже 53% IT-проектів завершується з перевитратою бюджету (в середньому на 189%, тобто майже в два рази); та тільки 16,2% проектів укладається і в термін, і в бюджет.

Дата добавления: 2015-07-12