Лекція 3. Тема: еволюція моделей життєвого циклу програмного забезпечення

Модель життєвого циклу проекту (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). Відповідно до даної схеми програмне забезпечення створюється не відразу, а ітераційно з використанням методу прототипування, що базується на створенні прототипів. Саме поява прототипування привела до того, що процес модифікації програмного забезпечення перестав сприйматися, як «необхідне зле», а почав сприйматися як окремий важливий процес.

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

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

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

• скоротити час до появи перших версій програмного продукту;

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

• прискорити формування і уточнення специфікацій за рахунок появи практики використання продукту;

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

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

Зміна життєвого циклу програмного забезпечення при використанні CASE- технологій. CASE-технології є сукупністю методологій аналізу, проектування, розробки і супроводу складних програмних систем, заснованих як на структурному, так і на об'єктному підходах, які підтримуються комплексом взаємозв'язаних засобів автоматизації. У основі будь-якої CASE-технології лежить парадигма методологія/метод/нотація/засіб [11].

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

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

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

• CASE-засоби аналізу вимог, проектування специфікацій і структури, редагування інтерфейсів (перше покоління CASE-I);

• CASE-засоби генерації початкових текстів і реалізації інтегрованого оточення підтримки повного життєвого циклу розробки програмного забезпечення (друге покоління CASE-II).

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

Автоматизовуючи трудомісткі операції, сучасні CASE-засоби істотно підвищують продуктивність праці програмістів і покращують якість створюваного програмного забезпечення. Вони:

• забезпечують автоматизований контроль сумісності специфікацій проекту;

• зменшують час створення прототипу системи;

• прискорюють процес проектування і розробки;

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

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

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

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

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

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

Використання CASE-засобів дозволяє істотно понизити трудовитрати на розробку складного програмного забезпечення (табл. 1.2 [32]) в основному за рахунок автоматизації процесів документування і контролю. Проте слід мати на увазі, що сучасні CASE-засоби дорогі, а їх використання вимагає вищої кваліфікації розробників. Отже, їх має сенс використовувати в складних проектах, причому, чим складніше програмне забезпечення, яке розробляють, тим більший виграш від використання CASE-технологій. На сьогоднішній день практично все складне ПЗ розробляється з використанням CASE-засобів.

Таблиця 1.1

Порівняння процесів розробки ПЗ

Традиційна розробка	Розробка з використанням CASE - засобів
Основні зусилля на кодування і тестування «Паперові» специфікації Ручне кодування Ручне документування Тестування коду Супровід коду	Основні зусилля на аналіз і проектування Швидке ітераційне прототипування Автоматична генерація коду Автоматична генерація документації Автоматичний контроль проекту Супровід специфікацій проектування

Таблиця 1.2

Порівняння трудовитрат на розробку складного ПЗ

з використанням різних способів розробки

Спосіб розробки	Трудовитрати етапу розробки %
	Аналіз	Проектування	Кодування	Тестування
Традиційна розробка Структурний підхід CASE-технології	20 30 40	15 30 40	20 15 5	45 25 15