- продукти - супроводжуване програмне забезпечення;
- ресурси - засоби програмування, програмісти, інженери з супроводу.
Ліквідація. Компоненти цієї фази такі:
- процеси - відновлення, переробка, повторне використання І знищення програмного забезпечення. Відновлення - це відновлення працездатності програмною забезпечення. Переробка - це реінженерія або міграція програмного забезпечення. Повторне використання - це виділення з програмного забезпечення частин компонентів, які можна використовувати знову в розробці нового програмного забезпечення.
Знищення - це знищення неутилізованих залишків програмного забезпечення;
- продукти - повторно використані компоненти;
- ресурси — екстрактори, програмісти, експерти.
Computer Aided Software Environment (CASE) - це інструментарій, призначений для автоматизації виконання процесів життєвого циклу програмного забезпечення. CASE відіграє, таку ж роль у програмному забезпеченні, як CAD/САМ в інженерії фізичних систем. Функціонування CASE ґрунтується на моделі процесів життєвого циклу (рис. 5.2).
Рис. 5.2. Зв'язок CASE моделі процесів ;життєвого циклу
До того ж, використання CASE в організації може розглядатися як шлях до отримання несуперечливих, повторюваних і визначуваних процесів. Це веде до того, що визначення CASE може виводити організацію на другий (повторюваний) або третій (визначуваний) рівень зрілості по моделі CMML
Таким чином, CASE повніша орієнтуватися на виконання всіх процесів життєвого циклу, що задаються відповідною моделлю (рис. 5.3.)
Рис. 5.3. Процеси, що автоматизують CASE
Крім моделі процесів розробки програмного забезпечення CASE повинна включати інструменти розробки і модель програмного продукту (рис. 5.4).
Рис. 5.4. Модель основи CASE
Очевидно, що CASE належать до інструментів горизонтального типу. Прикладами CASE є IBM Rational, Doors (Telelogic).
5.2. Обернена інженерія
Виконання процесів супроводу програмного забезпечення і виділення з нього програмних компонентів призвело до необхідності реконструювання програм і розробки відповідного розділу програмної інженерії, який називається реверсивною (reverse) або оберненою (backward) інженерією. Традиційний, низхідний підхід до розробки програмного забезпечення (від вимог до коду) називається прямим або інженерією вперед (forward).
Завдання оберненої інженерії протилежне прямій і полягає в забезпеченні процесів низькорівневого представлення програмного забезпечення (частіше початкового і рідше об'єктного коду), високо рівневого його уявлення, наприклад, проектної інформації або специфікацій вимог
Загалом, обернена інженерія забезпечує два такі процеси:
- ідентифікацію системних компонентів і відношень між ними;
- створення високорівневих представлень компонентів і програмного продукту в цілому.
- Тому в оберненій інженерії доводиться вирішувати два завдання;
- вибір відповідного рівня представлення абстракцій, стандартів і уявлень дня інформації про програмну інженерію;
- створення інструментів, що полегшують розпізнавання відповідної інформації в існуючому початковому коді.
Досвід показує, що тієї інформації, яка є в низькорівневому представленні програмного забезпечення, як правило, недостатньо для побудови високорівневого опису, тому процеси оберненої інженерії складні і потребують значного інформаційного і інструментального забезпечення,
На рис. 5.5 показано принципову відмінність процесів прямої і оберненої інженерії. Якщо для процесів прямої інженерії в разі створення програмного забезпечення характерне цілеспрямоване звуження області ухвалюваних рішень, то для процесів оберненої інженерії характерне розширення області рішень, що виводяться, яку постійно доводиться звужувати для того, щоб вийти на такс високорівневе уявлення програмного забезпечення.
Рис. 5.5. Відмінність прямої та оберненої інженерії
Потреба в оберненій інженерії натепер виникає в трьох випадках:
- у разі створення компонентів з існуючого програмного забезпечення;