Каскадна модель життєвого циклу інформаційної системи

Це класичний підхід до розробки різноманітних інформаційних систем в будь-яких прикладних предметних областях, що широко використовувався в 70-х – 80-х роках. На основі каскадної моделі розроблені промислові методики та стандарти.

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

Основні етапи розробки згідно каскадної моделі. На протязі застосування цієї моделі розбиття робіт на стадії і самі назви стадій змінювалися. Крім того, найбільш розумні методики та стандарти уникали жорсткого та однозначного припису конкретних робіт до конкретних етапів. Але є ряд стійких етапів розробки, практично незалежних від предметної області (мал.7):

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

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

· розробка;

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

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

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

Мал. 7. Каскадна модель розробки

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

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

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

Останній етап – здача готового проекту інформаційної системи у промислову експлу­атацію. Головне завдання цього етапу – запевнити замовника, що всі його вимоги реалізовані в повній мірі.

Етапи робіт в рамках каскадної моделі часто називають частинами “проектного цик­лу” інформаційних систем, тому що вони складаються з ітераційних процедур уточнення вимог до системи і варіантів проектних рішень. Життєвий цикл самої інформаційної системи суттєво довший і складніший. Він може включати в себе довільне число циклів уточнення, змін та доповнень вже прийнятих і реалізованих проектних рішень, за допомогою яких і відбувається розвиток інформаційної системи і модернізація окремих її елементів.

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

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

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

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

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

Недоліки каскадної моделі напряму пов¢язані з якістю виконання кожного етапу, особливо початкового. Перелічимо їх, а потім розглянемо їх подробиці:

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

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

· складність розбиття проекту на паралельні роботи;

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

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

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

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

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

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

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

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

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

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

Мал. 8. Реальна модель каскадної моделі розробки

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

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

Поиск по сайту: