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

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

До теперішнього часу найбільше поширення набули наступні основні моделі життєвого циклу:

1. задачна модель;

2. каскадна модель (або системна) (70-85 г.г.);

3. спіральна модель (теперішній час).

Задачна модель

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

Крайня терміновість (треба щоб хоч якось задачі розв'язувалися; потім доведеться все зробити наново);

Експеримент і адаптація замовника (не ясні алгоритми, рішення нащупуються методом проб і помилок).

Загальний висновок: достатньо велику ефективну інформаційної системи у такий спосіб створити неможливо.

Каскадна модель

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

Позитивні сторони застосування каскадного підходу полягають в наступному:

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

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

Мал. 2. Реальний процес розробки ПО по каскадній схемі

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

Спіральна модель

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

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

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

Мал. 3. Спіральна модель ЖЦ ІС

Одним з можливих підходів до розробки програмного забезпечення в рамках спіральної моделі життєвого циклу є що одержала останнім часом широке розповсюдження методологія швидкої розробки додатків RAD (Rapid Application Development). Під цим терміном звичайно розуміється процес розробки програмного забезпечення, що містить 3 елементи:

невелику команду програмістів (від 2 до 10 чоловік);

короткий, але ретельно пропрацює виробничий графік (від 2 до 6 міс.);

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

Життєвий цикл програмного забезпечення за методологією RAD складається з чотирьох фаз:

1. фаза визначення вимог і аналізу;

2. фаза проектування;

3. фаза реалізації;

4. фаза упровадження.