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