М. Сидоров - Вступ до інженерії програмного забезпечення

- продукти - супроводжуване програмне забезпечення;

- ресурси - засоби програмування, програмісти, інженери з супроводу.

Ліквідація. Компоненти цієї фази такі:

- процеси - відновлення, переробка, повторне використання І знищення програмного забезпечення. Відновлення - це віднов­лення працездатності програмною забезпечення. Переробка - це реінженерія або міграція програмного забезпечення. Повторне використання - це виділення з програмного забезпечення частин компонентів, які можна використовувати знову в розробці нового програмного забезпечення.

Знищення - це знищення неутилізованих залишків програмного забезпечення;

- продукти - повторно використані компоненти;

- ресурси — екстрактори, програмісти, експерти.

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).

Виконання процесів супроводу програмного забезпечення і ви­ділення з нього програмних компонентів призвело до необхідності реконструювання програм і розробки відповідного розділу про­грамної інженерії, який називається реверсивною (reverse) або оберненою ( backward) інженерією. Традиційний, низхідний підхід до розробки програмного забезпечення (від вимог до коду) назива­ється прямим або інженерією вперед ( forward).

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

Загалом, обернена інженерія забезпечує два такі процеси:

- ідентифікацію системних компонентів і відношень між ними;

- створення високорівневих представлень компонентів і програмного продукту в цілому.

- Тому в оберненій інженерії доводиться вирішувати два завдання;

- вибір відповідного рівня представлення абстракцій, стандартів і уявлень дня інформації про програмну інженерію;

- створення інструментів, що полегшують розпізнавання відповідної інформації в існуючому початковому коді.

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

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