На головну

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

  1.  HTM моделює світ шляхом побудови уявлень причин, включаючи встановлене моторне поведінку
  2.  V2: Математичні моделі та оптимізація в економіці
  3.  VI. Моделі макроекономічної рівноваги.
  4.  Z - моделі
  5.  Алгоритм побудови прогнозної моделі
  6.  Алгоритм статистичного моделювання
  7.  алгоритмічні моделі

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

- Істотна затримка в отриманні результатів;

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

- Складність паралельного ведення робіт по проекту;

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

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

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

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

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

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

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

Мал. 2.3. Реальний процес розробки по каскадної схемою.


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

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

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

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

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

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

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

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

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

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

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

Примітка.

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




 Фактори, що впливають на розвиток корпоративних інформаційних систем |  Розвиток підходів до технічної та програмної реалізації елементів інформаційних систем |  Основні складові корпоративних інформаційних систем |  Співвідношення між складовими інформаційної системи |  Класифікація за масштабом |  Класифікація по сфері застосування |  Класифікація за способом організації |  Архітектура файл-сервер. |  Архітектура клієнт-сервер. |  Багаторівнева архітектура. |

© um.co.ua - учбові матеріали та реферати