Тема 1.4 Життєвий цикл програмного забезпечення.

У процесі створення ПЗ можна виділити 4 базових етапи/стадії:

 

Рисунок 2 – Схема життя програмного забезпечення

• Специфікація – визначення основних вимог.
• Розроблення – створення ПЗ відповідно до специфікацій. Тестування – перевірка ПЗ на відповідність вимогам клієнта.
• Супровід/Модернізація – розвитокПЗвідповіднодозмін потреб замовника.

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

Оскільки розроблення та супровід ПЗ фактично є проектною діяльністю, частина ключових понять управління проектів знайшла широке застосування у програмній інженерії. Таким є і поняття життєвого циклу проекту (Project Lifecycle Management, PLM), що в програмній інженерії трансформувалось у поняття життєвого циклу програмного забезпечення.

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

ГОСТ 34.601-90 [7] визначає життєвий цикл автоматизованої системи (АС) як сукупність взаємозв’язаних процесів створення та послідовної зміни стану АС, від формування вхідних вимог до неї до закінчення експлуатації та утилізації комплексу засобів автоматизації.

Як і будь-що модель, модель ЖЦ є абстракцією реального процесу, в якій відсутні деталі, несуттєві з точки зору призначення моделі. Поняття ЖЦ виникло під впливом потреби у систематизації робіт у процесі розроблення ПЗ. Систематизація була першим етапом на шляху до автоматизації процесу розроблення ПЗ. Наступними кроками переходу до автоматизації процесу розроблення ПЗ були такі: встановлення технологічних маршрутів діяльності розробників ПЗ, визначення можливості їх автоматизації та виявлення ризиків, розроблення інструментів для автоматизації. Спочатку з’явилися інструменти підтримки розроблення програмного коду та налагодження програм (60-ті рр. ХХ ст.). Після усвідомлення недостатності таких засобів для істотного підвищення якості програм та створення інструментів керування процесом розроблення виникло поняття життєвого циклу ПЗ. Виявлення закономірностей розвитку програмного забезпечення одразу показало нерозвиненість методик конструювання ПЗ та недостатність тестування для визначення якості програмних продуктів. Також на цьому етапі стало зрозуміло, що нечіткість завдання на створення ПЗ викликає більшість проблем розроблення та перевірки програм. У результаті виникли вимоги до постановки завдання, сформувалися підходи до управління вимогами на етапі аналізу та інструменти зв’язку вимог на етапах аналізу та реалізації. Використання поняття життєвого циклу дозволяє обрати підходи, які найбільш ефективні для завдань певного етапу життя ПЗ. Залежно від особливостей процесів розроблення та супровіду програм існують різні моделі ЖЦ. Використання певної моделі ЖЦ дозволяє визначитися з основними моментами процесу замовлення, розроблення та супроводу ПЗ навіть недосвідченому програмісту. Також використання моделей дозволяє чітко зрозуміти, в який період переходити від версії до версії, які дії з удосконалення виконувати, на якому етапі. Знання про закономірності розвитку програмного продукту, які відбиваються в обраній моделі ЖЦ, дозволяють отримати надійні орієнтири для планування процесу розроблення та супроводу ПЗ, економно витрачати ресурси та підвищувати якість управління усіма процесами. Також моделі життєвого циклу є основою знань технологій програмування та інструментарію, що їх підтримує. Будь-що технологія базується на певних уявленнях про життєвий цикл та організує свої методи та інструменти навколо фаз та етапів ЖЦ. Розвиток методологій програмування у 70-х рр. XХ ст. привів до формування потреби вивчення життєвого циклу ПЗ. До цього часу моделі ЖЦ розвиваються і модифікуються, уточнюючи та доповнюючи дві базові моделі – каскадну та ітеративну. Ці зміни обумовлені потребою організаційної та технологічної підтримки проектів з розроблення ПЗ.

Каскадна модель (waterflow model)

Каскадна модель ЖЦ ПЗ виникла для задоволення потреби у систематизації робіт ще на ранніх етапах розроблення програм. Згідно з цією моделлю програмні системи проходять в своєму розвитку дві фази: розроблення; супровід.

Фази розбиваються на ряд етапів (рис. 3).

Рисунок 3 – Каскадна модель ЖЦ

 

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

Розроблення починається з ідентифікації потреби в новому додатку, а закінчується передачею продукту розроблення в експлуатацію. Усі етапи розроблення програмного забезпечення регламентуються стандартами підприємства та державним стандартом ГОСТ 34.601-90 [7].

Першим етапом фази розроблення є специфікація (Requirements Speсification) – постановка завдання і визначення вимог. На етапі постановки завдання замовник спільно з розробниками приймають рішення про створення системи. Визначення вимог включає опис загального контексту задачі, очікуваних функцій системи та її обмежень. Особливо важливим є цей етап для нетрадиційних додатків. У разі позитивного рішення починається аналіз системи відповідно до вимог. Розробники програмного забезпечення намагаються осмислити висунуті замовником вимоги і зафіксувати їх у вигляді специфікацій системи. Призначення специфікацій – описувати зовнішню поведінку системи, а не її внутрішню організацію.

Перш ніж розпочати створювати проект за специфікаціями, вимоги повинні бути ретельно перевірені на відповідність вихідним цілям, повноту, сумісність (несуперечність) та однозначність. Завдання етапу аналізу полягає в тому, щоб вибудувати опис програми у вигляді логічної системи, зрозумілої як для замовника, майбутніх користувачів, так і для виконавців проекту. На етапі специфікації обов’язково формується технічне завдання на розроблення ПЗ [8]. Розроблення проектних рішень, що відповідають на питання, як повинна бути реалізована система, щоб вона могла задовольняти визначені вимоги, виконується на етапі проектування (Design). Оскільки складність системи в цілому може бути дуже великою, головним завданням цього етапу є послідовна декомпозиція системи до рівня очевидно реалізованих модулів або процедур. Результати виконання цього етапу оформлюютья як технічний проект, вимоги до документів якого встановлені стандартом ГОСТ 34.201-89 [9].

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

У каскадній моделі фаза розроблення закінчується етапом тестування (Testing and debugging), автономного і комплексного, та передачею системи в експлуатацію (Installation).

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

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

Стисла характеристика:

• фіксований набір стадій;
• кожна стадія закінчується документованим результатом;
• наступна стадія починається лише після закінчення попередньої.

Недоліки:

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

Використання: там, де вимоги добре зрозумілі та стабільні.

Ітеративна модель (Iterative and incremental development)

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

Класична ітераційна модель абсолютизує можливість повернень на попередні етапи (рис.4). Ця обставина відбиває істотний аспект програмних розробок: прагнення заздалегідь передбачати всі ситуації використання системи та неможливість у переважній більшості випадків досягти цього. Усі традиційні технології програмування спрямовані лише на те, щоб мінімізувати повернення. Але суть від цього не змінюється: при поверненні завжди доводиться повторювати побудову того, що вже вважалося готовим. Мета кожної ітерації в розробленні ПЗ – отримання працюючої   версії   програмної   системи,   що   включає функціональність, визначену інтегрованим змістом усіх попередніх і поточної ітерації. Результат фінальної ітерації містить усю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт розвивається інкрементально (нарощує функціональність).

Рисунок 4 – Класична ітеративна модель

З точки зору структури життєвого циклу та процесу розроблення така модель є ітеративною (iterative) (рис.5). З точки зору розвитку продукту – інкрементальною (incremental). Досвід індустрії розроблення ПЗ показує, що неможливо розглядати кожен з цих поглядів ізольовано [10]. Тому цю модель часто називають моделлю ітеративного та інкрементного розроблення (Iterative and incremental development, IID) [11].

Рисунок 5 – Ітеративне та інкрементне розроблення програм

Різні варіанти ітераційного підходу реалізовані в більшості сучасних методологій розроблення (RUP, MSF, XP).

Стисла характеристика:

стадії повторюються неодноразаво.

Недоліки:

• система часто погано структурована, проект «не прозорий»;
• після уточнення вимог відкидається частина раніше виконаної роботи;
• потрібні засоби для швидкого розроблення.

Використання:      підходить    для    малих    та    середніх проектів.

Спіральна модель

Найбільш відомим і поширеним варіантом ітераційної моделі є спіральна модель (рис.6), що була вперше сформульована Баррі Боемом (Barry Boehm) у 1986 році [12]. Відмінною особливістю цієї моделі є спеціальна увага ризикам, що впливає на організацію життєвого циклу.

Рисунок 6 – Спіральна модель ЖЦ

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

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

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

Спіральна модель розроблення ПЗ вимагає визначення ключових контрольних точок проекту – milestones. Виділяють такі основні контрольні точки [12]:

• Concept of Operations (COO) – концепція використання системи;
• Life Cycle Objectives (LCO) – цілі та зміст життєвого циклу;
• Life Cycle Architecture (LCA) – архітектура життєвого циклу;
• Initial Operational Capability (IOC) – перша версія ПЗ, що перевіряється у ході дослідницької експлуатації;
• Final Operational Capability (FOC) – готове ПЗ, що експлуатується в реальних умовах.

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

Стисла характеристика:

• проект має контрольні точки – milestones;
• на кожному витку спіралі створюється прототип На виході – продукт, що відповідає вимогам користувачів.

Переваги:

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

Недоліки:

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

Використання: підходить для малих та середніх проектів.

Незважаючи на розвиток теоретичної бази, стадія комплексної автоматизації технологій програмування стала можливою лише при відповідному рівні розвитку техніки. Істотно вплинуло на перехід до комплексної автоматизації усвідомлення того, що не можна розвивати промислове програмування без підтримки технологічних функцій на всіх етапах життя програм. На початку 90-х рр. ХХ ст. з’явилася CASE-технологія (Computer Added Software Engineering – сукупність інструментів та методів програмної інженерії проектування ПЗ для забезпечення високої якості, мінімальної кількості помилок та спрощення проектування), що об’єднувала системи комплексної автоматизації підтримки розроблення і супроводу програм.

Аналіз моделей ЖЦ ПЗ показує, що саме програмування не є основним видом діяльності колективу, зайнятого промисловими розробленнями. Багато досліджень віддають на фазу програмування не більше 15-20% часу, витраченого на розроблення (супровід може бути нескінченним).

---