Тема: ЕВОЛЮЦІЯ МОДЕЛЕЙ ЖИТТЄВОГО ЦИКЛУ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Модель життєвого циклу проекту (Software life cycle model (SLM) – це структура, що визначає послідовність виконання та взаємозв’язку процесів, дій та задач на протязі виконання проекту. Модель ЖЦ залежить від специфіки програмного продукту, а також від специфіки умов, в яких даний продукт створюється та функціонує [31].

Існує два основних типи моделей ЖЦ:

1) Прогнозовані моделі ЖЦ – в основі цих моделей лежить чітке планування усіх стадій процесу розробки ПЗ;

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

На сьогоднішній момент найбільшого поширення серед прогнозованих набули такі моделі:

· каскадна;

· V-подібна модель;

· модель еволюційного прототипування;

· модель швидкої розробки;

· інкрементна модель;

· спіральна модель.

Адаптивні моделі ЖЦ з’явилися недавно, але здобули вже досить широке поширення особливо серед західних компаній. Найвідомішими є:

· Scrum;

· Extreme programming, XP;

· Adaptive Software development, ASD;

· Dynamic System Development Model, DSDM;

· Feature Driven Development, FDD.

Адаптивні моделі ЖЦ включають не тільки опис структури фаз, та їх пояснення, але і рекомендації, підходи з їх ефективного використання.

Впродовж останніх тридцяти років в програмуванні змінилися три моделі життєвого циклу програмного забезпечення: каскадна, модель з проміжним контролем і спіральна [31].

Каскадна модель. Спочатку (1970-1985 років) була запропонована і використовувалася каскадна схема розробки програмного забезпечення (рис. 1.10), яка припускала, що перехід на наступну стадію здійснюється після того, як повністю будуть завершені проектні операції попередньої стадії і отримані всі початкові дані для наступної стадії. Розроблена була Вінстоном Ройсом в 1970 році та вперше представлена в його книзі «Управління розробкою великих програмних систем».

Перевагами такої схеми є:

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

• простота планування процесу розробки.

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

Існує необхідність повернень на попередні стадії з метою уточнення чи перегляду раніше прийнятих рішень і це обумовлено наступними причинами:

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

• зміна вимог замовника безпосередньо в процесі розробки;

• швидке моральне старіння технічних і програмних засобів;

• відсутність задовільних засобів опису розробки на стадіях постановки завдання, аналізу і проектування.

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

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

Основна небезпека використання такої схеми пов'язана з тим, що розробка ніколи не буде завершена, постійно знаходячись в стані уточнення і удосконалення.

Примітка. Народна мудрість в подібних випадках говорить «краще - ворог хорошого». Залишилося тільки зрозуміти, що можна вважати «хорошим» і як все-таки добитися кращого...

Спіральна модель (spiral model). Для подолання перерахованих проблем в середині 80-х років XX в, була запропонована Баррі Боемом спіральна схема (рис. 1.12). Відповідно до даної схеми програмне забезпечення створюється не відразу, а ітераційно з використанням методу прототипування, що базується на створенні прототипів. Саме поява прототипування привела до того, що процес модифікації програмного забезпечення перестав сприйматися, як «необхідне зле», а почав сприйматися як окремий важливий процес.