М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Страница 12

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

Комплект реалізації включає початковий код, який є реалізацією компонентів (їх форму, інтерфейс і залежність), та всі потрібні для автономного тестування компонентів виконувані файли. Виконувані файли є простими складовими частинами, необхідними для створення кінцевого продукту, включаючи компоненти, створені на замовлення (COTS), програмні інтерфейси (АРІ) комерційних компонентів, а також АРІ компонентів повторного використання або компонентів, наявних у початковій мові програмування. Робочі продукти комплекту також можна транслювати в підмножину комплекту впровадження (виконувані файли в остаточному вигляді). Конкретні робочі продукти включають самодокументований початковий код продукту і пов'язані з ним файли (сценарії компіляції, інфраструктура для управління конфігурацією, файл з даними), самодокументований тестовий початковий код і пов'язані з ним файли (файли з вхідними даними для тестування, файли з результатами тестування), виконувані файли для незалежного запуску компонентів і файли для проведення тестування компонентів.

Комплекти реалізації мають формати, придатні для читання людиною і оцінюються та вимірюються комбінацією таких чинників:

- несуперечність стосовно до проектних моделей;

- несуперечність і повнота різних комплектів робочих продуктів;

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

- виконання тестових варіантів для незалежних компонентів з автоматичним порівнянням очікуваних результатів з отриманими;

- аналіз зміни в поточній версії компонента реалізації порівняно з попередніми версіями (тенденції до зменшення кількості дефектів і доопрацювань).

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

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

- тестування стратегій розподілу, реплікації і розміщення сценаріїв використання, таких як: інсталяція, динамічна зміна конфігурації, основне застосування і управління в аномальних ситуаціях;

- тестування на відповідність описаних у керівництві користу­вача сценаріїв використання, таких як: інсталяція, динамічна зміна конфігурації, основне застосування і управління в аномальних ситуаціях;

- аналіз змін у поточній версії комплекту впровадження порівняно з попередніми версіями (тенденціями зменшення кількості дефектів, зміни в продуктивності).

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

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

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

- робочі продукти тестування узгоджуються і створюються в рамках тих же комплектів, що і сам продукт;

- робочі продукти тестування реалізуються в програмованому і відтворюваному форматах;

- робочі продукти тестування документуються тим же чином, що і сам продукт;

- розробники тестів використовують ті ж інструменти, методи і процес навчання, що і розробники, котрі створюють основний продукт.

Модуль ІІ

МОДЕЛІ ЖИТТЄВОГО ЦИКЛУ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ. ПРОЦЕСИ, ПРОДУКТИ, РЕСУРСИ

Розділ 5. ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Розглядаються основні положення трьох інженерій програмного забезпечення - прямої, оберненої і емпіричної; показується взаємо­ зв'язок двох інженерій програмного забезпечення, які нині часто використовуються разом. Розглядаються основні методи і засоби, які використовує пряма, обернена і емпірична інженерії.

5.1. Пряма інженерія

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

Рис. 5.1. життєвий цикл програмного забезпечення

Доменний аналіз. Компоненти цієї фази життєвого циклу такі:

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

- продукти - архітектура, код, тести, методи;

- ресурси - інструменти доменного аналізу, доменні експерти, доменні інженери.

Специфікування вимог. Компоненти цієї фази життєвого циклу такі:

- процеси - дії зі складання вимог до програмного забезпе­чення;

- продукти - специфікації вимог;

- ресурси - мови специфікацій, інженери вимог, комунікатори із з замовником.

Архітектурне і детальне проектування. Компоненти цієї фази такі:

- процеси - орієнтовані на створений архітектури І детального проекту;

- продукти - архітектура і детальний проект програмного забезпечення;

- ресурси - CASE, архітектура і системні програмісти. Кодування і тестування. Компоненти цієї фази такі:

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

- продукти - програми;

- ресурси - засоби програмування, програмісти і тестери. Супровід. Компоненти цієї фази такі:

- процеси - що коригують, адаптують, удосконалюють і онов­люють супровід. Коригуючий супровід - зміна програмного забезпечення з мстою виправлення помилок, допущених на попередніх фазах життєвого циклу. Адаптуючий супровід - зміна програмного забезпечення у відповідь на зміни навколишнього середовища. Вдосконалюючий супровід - зміна програмного забез­печення задля вдосконалення його властивостей. Відновлюючий супровід - зміна програмного забезпечення задля відновлення його працездатності;

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

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

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

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

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

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

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