Особливості водоспадної моделі проектування іс

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

Позитивні чинники застосування водоспадної схеми є наступними:

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

Основні етапи стали також називати частинами «проектного цик­лу» системи. Така назва виникла тому, що в етапи включалися ба­гато ітераційних процедур уточнення вимог до системи та варіантів проектних рішень.

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

Негативні чинники послідовної схеми проектування спостерігалися постійно, описані в літературі і добре відомі на практиці. Найчасті­ше в якості основного недоліку називалося істотне запізнення з отриманням результатів, що виникало внаслідок наступних особли­востей процесу проектування: погодження результатів з користувачем відбувалося лише в момен­ти після завершення кожного етапу робіт; це призводило до того, що розробники проектували не ту ІС, яку бажав (уявляв) замовник і тим більше користувачі, а ту, яку уявили собі проекту в альники-аналітики, після цього — програмісти; моделі об'єкта, що автоматизується, які відповідали критеріям внутрішньої погодженості і повноти, застарівали для більш-менш великого проекту ІС (тобто переставали відповідати реальним зов­нішнім вимогам) незабаром після їхнього затвердження, а інколи і водночас з ним; це стосується і функціональної, і інформаційної мо­делі, і проектів інтерфейсу користувача, і інструкцій персоналу; спроби довести до впровадження проект, що виконувався таким способом, змушували або викривляти вимоги до ІС, або перевищува­ти терміни і кошторис розроблення, або робити і те, й інше. З розвитком апаратних та програмних засобів основна причина (складність та розмір задач) значно втратила у важливості, і най­більш актуальною причиною є динаміка змін у вимогах до бази да­них (БД) і ІС загалом.

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

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

ВДОСКОНАЛЕННЯ КЛАСИЧНИХ СХЕМ ПРОЕКТУВАННЯ

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

Схема неперервного розроблення

Прикладом вдосконалення класичного проектування може слу­жити підхід, який керівники великих проектів фірми IBM в 70-х — 80-х роках називали «Розробкою, що триває (продовжується)». Ха­рактерною особливістю такого підходу став неперервний процес розроблення і розвитку великої ІС з визначеними плановими мо­ментами передачі до експлуатації нових версій та нових функціо­нальних блоків (підсистем, задач) та вбудованими у процес проек­тування постійно здійснюваними процедурами експертизи якості, дієздатності та ін.

Велика увага приділялася організації процесу проектування. Вбу­довані у процес експертизи служили тим засобом зворотного зв'яз­ку, ґрунтуючись на якому можна було одержувати підтвердження користувача, і удосконалювати процес розроблення.

Рис. 15.4. Вдосконалення класичної схеми проектування

Змістовно цей підхід описаний Дж. Фоксом. Схема проектного циклу при проектуванні, що триває, співпадає з циклом життя сис­теми (рис.15.4).