Основні етапи розробки по каскадній моделі

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

розробки, практично не залежних від предметної області:

· аналіз вимог замовника;

· проектування;

· розробка;

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

· здача готового продукту

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

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

Третій етап - реалізація проекту. Тут здійснюється розробка программ-ного забезпечення (кодування) відповідно до проектних рішень, полу-ченными на попередньому етапі. Методи, використовувані для реалізації, не мають принципового значення. Результатом виконання цього етапу є го-товый програмний продукт.

На четвертому етапі проводиться перевірка отриманого програмного забезпечення на предмет відповідності вимогам, заявленим в технічному завданні. Опыт-ная експлуатація дозволяє виявити різного роду приховані недоліки, про-являющиеся в реальних умовах роботи інформаційної системи. Останній етап - здача го нового проекту. Головне завдання цього етапу - переконати замовника, що усі його вимоги реалізовані повною мірою. Етапи робіт у рамках каскадної моделі часто також називають частинами "проектно-го циклу" системи. Така назва виникла тому, що етапи складаються з багатьох ітераційних процедур уточнення вимог до системи і варіантів проектних рішенні. Життєвий цикл самої системи істотно складніший за неї і більший. Він мо-жет включати довільне число циклів уточнення, зміни і дополне-ния вже прийнятих і реалізованих проектних рішень. У цих циклах відбувається розвиток інформаційної системи і модернізація окремих її компонентів.

Лекція 10

Основні достоїнства каскадної моделі

Каскадна модель має ряд позитивних сторін, завдяки яким вона хо-рошо зарекомендувала себе при виконанні різного роду інженерних разра-боток і набула широкого поширення. Розглянемо основні достоїнства моделі "водоспад":

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

· виконувані в логічній послідовності етапи робіт дозволяють плани-ровать терміни завершення і відповідні витрати.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примітка

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

Лекція 11