Тема 2. Життєвий цикл програмного забезпечення
В основі діяльності з створення і використання програмного забезпечення лежить поняття життєвого циклу. Життєвий цикл є моделлю створення і використання програмного забезпечення, яка зображає його різні стани, починаючи з моменту виникнення необхідності в даній програмі і закінчуючи моментом її повного виходу з використання у користувачів.
Модель життєвого циклу включає в себе набір етапів і зв'язків між ними. Дається детальний опис дій, моделей і результатів кожного етапу. Може бути запропоновано декілька моделей життєвого циклу, кожна з яких визначає різну методологію створення систем.
Стандартні моделі життєвого циклу
Життєвий цикл програми можна представити як ряд подій, які відбуваються з програмною системою в процесі її створення і використання.
Модель життєвого циклу зображає різні стани системи, починаючи з моменту виникнення необхідності в даній системі і закінчуючи моментом її повного виходу з використання. Модель життєвого циклу - структура, яка містить процеси, дії і задачі, які виконуються в ході розробки, функціонування і супроводу програмного продукту на протязі всього життя системи, від визначення вимог до завершення її використання.
У відповідності з базовим міжнародним стандартом ІБО/ІБС 12207 всі процеси життєвого циклу поділяються на три групи:
- Основні процеси — купівля, поставка, розробка, експлуатація, супровід;
- Допоміжні процеси — документування, управління конфігурацією, забезпечення якості, вирішення проблем, аудит, атестація, сумісна оцінка, верифікація;
- Організаційні процеси — створення інфраструктури, управління, навчання, удосконалення.
Традиційно, у всіх стандартних моделях, виділяють наступні основні етапи життєвого циклу:
- Стратегічне планування;
- Аналіз вимог;
- Проектування (попереднє і детальне);
- Кодування (програмування);
- Тестування і наладка;
- Експлуатація і супровід.
Кожному етапу відповідають певний результат і набір документації, які є вихідними даними для наступного етапу. На завершенні кожного етапу проводиться верифікація документів і вирішень з метою перевірки їх відповідності першочерговим вимогам замовника.
Розглянемо детальніше окремі етапи життєвого циклу.
Етапи стратегічного планування і аналізу використовуються для визначення самих загальних вимог до програмної системи. Дані етапи передбачають вирішення наступних задач:
- Визначення доцільності розробки і порівняння з аналогами;
- Визначення необхідних ресурсів для вирішення задачі;
- Специфікація вимог до системи у виді "що вона повинна робити", але не у виді "як це реалізувати";
- Перевірка коректності і реалізованості вимог.
На етапі проектування створюється структура майбутньої програмної системи. Можна визначити наступні фази проектування:
- Проектування архітектури, включає в себе визначення складу підсистем;
- Специфікація підсистем, яка визначає специфікацію кожної підсистеми;
- Проектування інтерфейсу, визначає інтерфейс кожної підсистеми, тобто метод взаємодії даної підсистеми з іншими;
- Проектування компонентів, кожна підсистема поділяється на компоненти;
- Проектування структур даних, визначає де і як зберігаються дані;
- Проектування алгоритмів, визначаються алгоритми обробки даних.
Реалізація передбачає вибір мови програмування і складання тексту
Програми (кодування), а також, можливо, виконання тестування і наладки окремих фрагментів.
Етап тестування і наладки включає виконання комплексного тестування всієї програмної системи спеціальною групою і виправлення помилок.
На етапі супроводу і експлуатації програмна система здається в експлуатацію, проиходить обслуговування користувачів, можливе виявлення незначних помилок.
Історично, в ході еволюційного розвитку теорії проектування програмного забезпечення і в міру його ускладнення, склалося три основні моделі життєвого циклу. Ці моделі виражають послідовність етапів життєвого циклу програмного забезпечення.
Першою, за часом появи, і самою розповсюдженою є каскадна модель.
Модель передбачає наступні властивості взаємодії етапів:
- Модель складається з послідовно розміщених етапів;
- Кожен етап повністю закінчується до того як починається наступний;
- Етапи не перекриваються в часі;
- Повернення до попереднього етапу не передбачається або обиежений;
- Результат з'являється тільки в кінці розробки.
Виявлення і усунення помилок в такій моделі проводиться тільки на стадії тестування, яка може розтягнутися в часі, або, взагалі не завершитися.
Можна виділити наступні позитивні сторони застосування каскадного
Підходу:
- На кожному етапі формується закінчений набір проектної документації, яка відповідає критеріям повноти і узгодженості;
- Виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні затрати.
Каскадний підхід добре зарекомендував себе при побудові відносно простих систем, коли на самому початку розробки можна достатньо точно і повно сформулювати всі вимоги до системи. Основним недоліком цього підходу є те, що реальний процес створення системи ніколи повністю не вкладається в таку жорстку схему, постійно виникає потреба у поверненні до попередніх етапів і уточненні або перегляді раніше прийнятих рішень. У результаті реальний процес створення систем виявляється відповідним поетапній моделі з проміжним контролем.
Це модель розробки програмного забезпечення зі зворотніми зв'язками між етапами. Перевірки і коригування розроблюваної системи проводяться на кожному з етапів, що дозволяє суттєво знизити трудомісткість наладки у порівнянні з каскадною моделлю. Ітераційність моделі проявляється в обробці помилок виявлених проміжним контролем. Якщо на якомусь з етапів в ході проміжної перевірки виявилась помилка, що допущена на більш ранній стадії розробки, роботи етапу, який викликав помилку, необхідно провести повторно. При цьому аналізуються причини помилки і коригуються, при необхідності, вихідні дані етапу або перелік виконуваних робіт.
В ході робіт над системою можуть змінитися початкові вимоги, і у цьому випадку ітераційна модель може виявитися неефективною. Узгодження результатів розробки з користувачами відбувається тільки в точках, запланованих після завершення кожного етапу робіт, а загальні вимоги до системи зафіксовані в виді технічного завдання на весь час її створення. Таким чином, користувачі часто отримують систему, яка не задовольняє їх реальних вимог.
Спіральна модель була запропонована для подолання перерахованих проблем. На етапах аналізу і проектування реалізованість технічних рішень і міра задоволення потреб замовника перевіряється шляхом створення прототипів. Ця модель підтримує ітерації поетапної моделі, але особлива увага приділяється початковим етапам проектування: аналізу вимог, проектуванню специфікацій, попередньому проектуванню і детальному проектуванню. Кожен виток спіралі відповідає поетапній моделі створення фрагменту або версії програмного забезпечення, уточнюються цілі і вимоги до програми, оцінюється якість розробленого фрагменту або версії і плануються роботи наступного витка. Таким чином, поглиблюються і конкретизуються всі деталі проектованої програми і в результаті отримують варіант, який задовольняє всі вимоги замовника.
Ітеративна розробка зображає об'єктивно існуючий спіральний цикл створення складних систем. Вона дозволяє переходити на наступний етап, не очікуючи повного завершення роботи на поточному і вирішити головну задачу - як можна швидше показати користувачам системи працездатний продукт, тим
Самим активізувати процес уточнення і доповнення вимог.
Основна проблема спірального циклу - визначення моменту переходу на наступний етап. Для її вирішення вводяться часові обмеження на кожен із етапів життєвого циклу, і перехід здійснюється у відповідності з планом, навіть якщо не вся запланована робота завершена.
Об'єктно-орієнтовані моделі життєвого циклу
Спочатку з'явилось об'єктно-орієнтоване програмування і тільки потім об'єктно-орієнтоване проектування. Таким чином застосування методології почалося з етапу кодування. Ранні етапи опису предметної області і розробки архітектури системи не підтримувались. Перші варіанти застосування об'єктно- орієнтованої методології в більшій мірі були чистим повторенням принципів об'єктно-орієнтованого програмування. Такі питання як декомпозиція предметної області, специфікація вимог, інтерфейс з користувачем не розглядались. Але успіхи об'єктно-орієнтованого програмування заставили поширити нову технологію на весь життєвий цикл.
Об'єктно-орієнтована методологія повинна покривати весь життєвий цикл для того щоб використовувати всі переваги підходу не тільки на етапі кодування, але й на більше ранніх етапах. Таким чином це повинна бути методологія, які включає в себе наступні компоненти:
- Модель життєвого циклу;
- Дії;
- Нотація мови. Життєвий цикл UML.
Фірма Rational Software, яка розробила мову UML, запропонувала також і свою модель життєвого циклу, яка називається Rational Objectory Process.
Можна перерахувати наступні основні властивості даної технології:
- Процес ітеративний, тобто проходить послідовне уточнення результатів;
- Дії процесу направлені на створення моделей, а не інших елементів проекту;
- Дії життєвого циклу визначаються в першу чергу блоками використання.
Життєвий цикл поділений на цикли, результатом кожного з яких є власна версія програмної системи. Кожен цикл складається з чотирьох фаз:
- Початок;
- Удосконалення;
- Побудова;
- Перехі.