Інформаційні системи і технології на підприємствах - Плескач В.Л. - Моделі життєвого циклу ПЗ

Модель ЖЦ ПЗ залежить від специфіки, масштабу і складності проекту та особливостей умов, за яких система створюється та функціонує.

Модель ЖЦ ПЗ - це структура, що визначає послідовність виконання і взаємозв'язок процесів, дій, задач протягом ЖЦ.

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

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

Найбільшого поширення набули дві моделі: каскадна (водоспадна), створена в 1970-1985 pp., та спіральна, створена в 1986-1990 рр.

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

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

Основна увага розробників зосереджується на досягненні найкращих значень технічних характеристик ПЗ, а саме: продуктивності, обсягу пам'яті тощо.

Переваги застосування каскадної моделі:

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

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

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

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

Рис. 3.3. Каскадна модель життєвого циклу 1С

виникає потреба в поверненні до попередніх стадій і уточненні або перегляді раніше прийнятих рішень.

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

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

Для подолання перерахованих проблем у середині 1980-х років була запропонована спіральна модель ЖЦ ПЗ (рис. 3.4).

Рис. 3.4. Модель спірального процесу розроблення 1С

Спіральна модель (spiral model) була розроблена у середині 1980-х років Барі Боемом. Вона ґрунтується на класичному циклі Демінга PDCA (plan-do-check-act). При використанні цієї моделі ІС створюється в кілька ітерацій (витків спіралі) методом прототипування.

Нині ця модель досить поширена. Найвідоміші приклади її реалізації - це RUP (Rational Unified Process) фірми Rational і MSF (Microsoft Solution Framework). Створення 1С за такої моделі має ітераційниЙ характер і рухається по спіралі, проходячи стадії, де на кожному витку уточнюються характеристики майбутнього інформаційного продукту.

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

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

Спіральна модель не виключає використання каскадного підходу на кінцевих стадіях проекту в тих випадках, коли вимоги до системи стають цілком чіткими.

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

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