Моделі життєвого циклу АІС

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

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

• стадії;

• результати виконання робіт на кожній стадії;

• ключові події або точки завершення робіт і прийняття рішень.

Відповідно до відомих моделей ЖЦ ПЗ визначають моделі ЖЦ АІС - каскадну, ітераційну, спіральну. Нижче коротко розглянута кожна з них.

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

Періодично назви стадій розробки в каскадній моделі мінялися; крім того, у кожний період часу регламент приписування певних робіт до конкретних етапів ніколи не був твердим і однозначним. Проте виділяють п'ять стійких етапів розробки, що практично не залежать від предметної області (Рис. 5).

Рис. 5 Каскадна модель ЖЦ АІС

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

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

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

На четвертому етапі проводиться перевірка отриманого програмного забезпечення на предмет відповідності вимогам, заявленим у технічному завданні. Експериментальна експлуатація дозволяє виявити різного роду сховані недоліки, що проявляються в реальних умовах роботи АІС.

Останній етап - здача готового проекту, і головне тут - переконати замовника в тім, що всі його вимоги виконані повною мірою.

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

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

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

2) послідовне виконання етапів робіт дозволяє планувати строки завершення й відповідні витрати.

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

Проте модель має ряд недоліків, що обмежують її застосування:

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

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

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

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

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

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

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

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

Рис. 6 Ітераційна модель ЖЦ АІС

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

Недоліки ітераційної моделі:

• час життя кожного етапу розтягується на весь період розробки;

• внаслідок великої кількості ітерацій виникають неузгодженості виконання проектних рішень і документації;

• заплутаність архітектури;

• труднощі використання проектної документації на стадіях впровадження й експлуатації викликають необхідність перепроектування всієї системи.

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

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

Рис. 7 Спіральна модельЖЦ АІС

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

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

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

Переваги спірального ітераційного підходу:

• ітераційна розробка істотно спрощує внесення змін у проект при зміні вимог замовника;

• при використанні спіральної моделі окремі елементи АІС інтегруються в єдине ціле поступово. Оскільки інтеграція починається з меншої кількості елементів, то виникає набагато менше проблем при її проведенні (при використанні каскадної моделі інтеграція займає до 40 % всіх витрат наприкінці проекту);

• зниження рівня ризиків (наслідок попередньої переваги, тому що ризики виявляються саме під час інтеграції).

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

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

• ітераційний підхід дозволяє вдосконалювати процес розробки - у результаті аналізу наприкінці кожної ітерації проводиться оцінка змін в організації розробки; на наступній ітерації вона поліпшується.

Основна проблема спірального циклу - труднощі визначення моменту переходу на наступний етап. Для її рішення необхідно ввести тимчасові обмеження на кожний з етапів життєвого циклу. Інакше процес розробки може перетворитися в нескінченне вдосконалювання вже зробленого. При ітераційному підході корисно додержуватися принципу «краще - ворог гарного». Тому завершення ітерації повинне провадитися строго відповідно до плану, навіть якщо не вся запланована робота закінчена [3, 16].