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

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

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

До теперішнього часу найбільшого поширення набули наступні основні моделі ЖЦ: каскадна модель (1970-1980 рр.); поетапна модель с проміжним контролем (1980-1990 рр.); спіральна модель (1990-2000 рр.); спірально-віхова модель (2000 - …).

Каскадна модель ЖЦ ІС (“waterfall ” - водоспад) – 1970-1980 роки.

Базується на послідовній організації робіт. Використовувалась для розробки однорідних ІС.

Головні характеристики:

- розбиття всієї розробки на етапи (аналіз, проектування, реалізація, впровадження, супровід);

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

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

Позитивні сторони вживання каскадного підходу:

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

- виконання етапів робіт в логічній послідовності дозволяє планувати терміни завершення всіх робіт і відповідні витрати;

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

Поетапна модель з проміжним контролем.

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

Недоліки:

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

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

· кожна ланка відповідає лише за свій результат,

· суттєве запізнення отримання результату,

· тривалі терміни розробки,

· великі трудовитрати людських ресурсів,

· система в цілому не розглядається,

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

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

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

Недоліки каскадної моделі, що перераховано, призводять до необґрунтованого зростання термінів розробки та вартості проекту.

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

Спіральна модель (1990-2000 рр.).

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

Переваги спіральної моделі:

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

- елементи ІС інтегруються послідовно (економія до 40% часу);

- зменшення проектних ризиків;

- підвищення гнучкості в управлінні проектами;

- спрощення подальшого використання компонент;

- підвищення надійності та стійкості ПЗ;

- можливість розвинення процесів розробка-аналіз.

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

Проте спіральна модель також має суттєві недоліки:

- важко визначити момент переходу до наступного етапу;

- слабка документованість етапів та ітерацій.

Поява спірально-віхової моделі з проміжним контролем (2000 р.) розпочало вирішення раніше зазначених проблем.

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

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