Інформаційні технології та моделювання бізнес-процесів – Томашевський О. М. – 17.2. Моделі життєвого циклу програмного забезпечення ІС
Одним з ключових понять проектування інформаційних систем є життєвий цикл проекту – Project Life Cycle Management (PLCM). В загальному випадку, життєвий цикл визначається моделлю й описується у формі методології (методу). Модель або парадигма життєвого циклу визначає загальну організацію ЖЦ і, як правило, основні його фази та принципи переходу між ними. Методологія (метод) визначає комплекс робіт, їх детальний зміст і рольову відповідальність спеціалістів на всіх етапах вибраної моделі ЖЦ; рекомендує практики (best practices), які дозволяють максимально ефективно використовувати відповідну методологію та її модель.
Наведемо означення моделі життєвого циклу програмної системи:
Модель життєвого циклу – структура, що складається із процесів, робіт та задач, які включають в себе розробку, експлуатацію і супровід програмного продукту; охоплює життя системи від визначення вимог до неї до припинення її використання
З другого боку, автор концепцій та практик гнучкого моделювання (Agile Modeling), Скот Амблер (Scott W. Ambler), пропонує наступні рівні ЖЦ, що визначаються відповідним вмістом робіт:
O програмне забезпечення – проектна діяльність з розробки і розгортання програмних систем;
O програмна система – включає розробку, розгортання, підтримку і супровід;
O інформаційні технології – вся діяльність ІТ-відділу;
O організація/бізнес – охоплює діяльність організації в цілому.
Архітектура життєвого циклу. У стандарті ISO/IEC 12207 визначено область застосування ІС, дано ряд важливих визначень (таких, як замовник, розробник, договір, оцінка, випуск – реліз, програмний продукт, атестація і т. п.), процеси життєвого циклу і включено ряд приміток щодо процесу і питанням адаптації стандарту. Стандарт описує 17 процесів ЖЦ, розподілених за групами процесів:
Основні процеси життєвого циклу – Primary Processes
O замовлення – Acqusition;
O поставка – Supply;
O розробка – Development;
O експлуатація – Operation;
O супровід – Maintenance.
S Допоміжні процеси життєвого циклу – Supporting Processes
O документування – Documentation;
O управління конфігурацією – Configuration Management;
O верифікація – Verification;
O атестація – Validation;
O сумісний аналіз – Joint Review;
O рішення проблем – Problem Resolution.
^ Організаційні процеси життєвого циклу – Organizational Processes
O управління – Management;
O створення інфраструктури – Infrastructure;
O вдосконалення – Improvement;
O навчання – Training.
Стандарт визначає високорівневу архітектуру життєвого циклу. Архітектура будується як набір процесів і взаємних зв’язків між ними. Наприклад, основні процеси життєвого циклу звертаються до допоміжних процесів, в той час, як організаційні процеси діють впродовж цілого ЖЦ і пов’язані з основними процесами.
Дерево процесів життєвого циклу є структурою декомпозиції життєвого циклу на відповідні процеси (групи процесів). Декомпозиція процесів будується на двох найважливіших принципах, що визначають правила розбиття (partitioning) ЖЦ на складові процеси:
Принцип модульності
O задачі в процесі є функціонально зв’язаними;
O зв’ язок між процесами – мінімальний;
O якщо функція використовується більше, ніж одним процесом, вона сама є процесом;
O якщо процес Y використовується процесом X і лише ним, то процес Y належить (є його частиною або його задачею) процесу X, за винятком випадків потенційного використання процесу Y іншими процесами в майбутньому;
Принцип відповідальності
O за кожний процес несе відповідальність особа (що керує і/або контролює його), визначена для заданого життєвого циклу, наприклад, у вигляді ролі в проектній команді;
O функція, частини якої знаходяться в компетенції різних осіб, не може розглядатися як самостійний процес.
Загальна ієрархія (декомпозиція) складових елементів життєвого циклу представлена на рис.17.2.
В загальному випадку, розбиття процесу базується на поширеному PDCA-циклі:
O “P” (Plan) – планування;
O “D” (Do) – виконання;
O “C” (Check) – перевірка;
O “A” (Act) – реакція (дія).
Рис.17.2. Структурна схема загальної ієрархії складових елементів ЖЦ
Найбільш часто використовують наступні моделі життєвого циклу:
Каскадна (або послідовна) модель. Передбачає строго послідовне в часі і однократне виконання всіх фаз проекту з детальним попереднім плануванням і визначеними вимогами (рис.17.3).
Основною особливістю цієї моделі є розбиття всієї розробки на етапи. Перехід від одного етапу до іншого відбувається лише при умові повного завершення робіт на попередньому етапі. Кожен етап завершується випуском документації, достатньої для того, щоб обробка могла бути продовжена іншою командою розробників.
Каскадна модель добре себе зарекомендувала при розробці систем, для яких можна повністю сформулювати всі необхідні вимоги і критерії. Серед недоліків цієї моделі можна назвати: істотну затримку в отриманні кінцевих результатів, виявлення помилок, як правило на останньому етапі розробки, високий ступінь ризику. Послідовна модель характеризується жорсткою структурою, що ускладнює її застосування на практиці. Проте, більшість ІТ-розробників використовують саме каскадну модель.
Рис.17.3. Каскадна модель життєвого циклу
Еволюційна (ітераційна) модель. Дозволяє знизити ступень невизначеності із завершенням кожної ітерації циклу. Тестування продукту можна починати вже на ранніх стадіях життєвого циклу.
Спіральна модель. На відміну від каскадної, передбачає ітераційний процес розробки інформаційної системи. Кожна ітерація є завершеним циклом розробки кінцевого продукту. На кожному витку (ітерації) спіралі створюється фрагмент або версія програмного продукту, уточнюється кінцева ціль і характеристики проекту, визначається його якість, плануються роботи для наступного витка. Особливу увагу приділяється аналізу ризиків, що впливають на організацію ЖЦ – аспектам взаємодії спеціалістів в проектній команді.
Використання спіральної моделі дозволяє здійснювати перехід на наступний етап виконання проекту, не дочекавшись повного завершення робіт на попередньому – недороблену роботу можна буде завершити на наступній ітерації. Головна мета кожної ітерації – якнайшвидше створити працездатний продукт, який можна показати замовнику.
Серед переваг спіральної моделі слід відмітити спрощення внесення змін в проект при зміні вимог замовника, елементи системи інтегруються один в одного поступово. Основна проблема спіральної моделі – визначення моменту переходу на наступний етап.
(2 votes, average: 2,50 out of 5)