М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Ступінь автоматизації аналізу проектних моделей натепер є обмеженим, тому слід покладатися на аналіз, що виконується фахівцем.
Комплект реалізації включає початковий код, який є реалізацією компонентів (їх форму, інтерфейс і залежність), та всі потрібні для автономного тестування компонентів виконувані файли. Виконувані файли є простими складовими частинами, необхідними для створення кінцевого продукту, включаючи компоненти, створені на замовлення (COTS), програмні інтерфейси (АРІ) комерційних компонентів, а також АРІ компонентів повторного використання або компонентів, наявних у початковій мові програмування. Робочі продукти комплекту також можна транслювати в підмножину комплекту впровадження (виконувані файли в остаточному вигляді). Конкретні робочі продукти включають самодокументований початковий код продукту і пов'язані з ним файли (сценарії компіляції, інфраструктура для управління конфігурацією, файл з даними), самодокументований тестовий початковий код і пов'язані з ним файли (файли з вхідними даними для тестування, файли з результатами тестування), виконувані файли для незалежного запуску компонентів і файли для проведення тестування компонентів.
Комплекти реалізації мають формати, придатні для читання людиною і оцінюються та вимірюються комбінацією таких чинників:
- несуперечність стосовно до проектних моделей;
- несуперечність і повнота різних комплектів робочих продуктів;
- оцінювання початкових або виконуваних файлів компонентів на відповідність певним критеріям за допомогою перевірок, аналізу, демонстрації або тестування;
- виконання тестових варіантів для незалежних компонентів з автоматичним порівнянням очікуваних результатів з отриманими;
- аналіз зміни в поточній версії компонента реалізації порівняно з попередніми версіями (тенденції до зменшення кількості дефектів і доопрацювань).
Комплект упровадження містить файли, що поставляються користувачеві, записи машинною мовою, сценарії збірки, сценарії інсталяції і дані, необхідні для використання продукту в тому середовищі, для якого він призначений. Записи машинними мовами Представляють компоненти продукту в кінцевому вигляді, службовцеві для розповсюдження серед користувачів. Уміст комплекту впровадження може бути інстальованим, виконаним відповідно до сценаріїв використання (протестовано) і динамічно переналаштовує для підтримки тих властивостей, які повинні бути в кінцевому продукті. Конкретні робочі продукти, які можуть бути потрібними в період виконання, оцінюються і вимірюються такою комбінацією:
- тестування сценаріїв використання і характеристик якості, визначених у комплекті вимог для оцінювання несуперечності, повноти і смислової відповідності між інформацією, що міститься в комплектах вимог і впровадженням;
- тестування стратегій розподілу, реплікації і розміщення сценаріїв використання, таких як: інсталяція, динамічна зміна конфігурації, основне застосування і управління в аномальних ситуаціях;
- тестування на відповідність описаних у керівництві користувача сценаріїв використання, таких як: інсталяція, динамічна зміна конфігурації, основне застосування і управління в аномальних ситуаціях;
- аналіз змін у поточній версії комплекту впровадження порівняно з попередніми версіями (тенденціями зменшення кількості дефектів, зміни в продуктивності).
4.4.2. Робочі продукти, пов'язані з тестуваннямТестуючи, керуються підходом, у якому визначальним є документація. Команди розробників складають документацію з вимог, проектну документацію верхнього рівня і детальну проектну документацію до того, як починають створюватися початкові або виконувані файли. Команди розробників, провідні тестування складають документацію щодо планів тестування процедур тестування, планів інтеграційного тестування, планів тестування модулів і процедур, тестування модулів до початку Створення яких-небудь тестуючих драйверів, заглушок або інструментів. Для такого підходу, з попереджуючим створенням документації, характерні ті ж проблеми тестування, що і при Проведенні розробки.
Одним з визначальних принципів сучасного процесу є застосування тих же комплектів, нотацій і робочих продуктів для продуктів тестування, які використовуються під час розробки самого продукту. Фактично лише визначається інфраструктура, потрібна для виконання тестування, як одна з обов'язкових підмножин кінцевого продукту. У процесі тестування виконуються певні правила, властиві періоду розробки:
- робочі продукти тестування повинні створюватися паралельно з продуктом від початку до впровадження, оскільки тестування - це діяльність, властива всьому життєвому циклу, а не тільки його пізнім етапам;
- робочі продукти тестування узгоджуються і створюються в рамках тих же комплектів, що і сам продукт;
- робочі продукти тестування реалізуються в програмованому і відтворюваному форматах;
- робочі продукти тестування документуються тим же чином, що і сам продукт;
- розробники тестів використовують ті ж інструменти, методи і процес навчання, що і розробники, котрі створюють основний продукт.
Модуль ІІ
МОДЕЛІ ЖИТТЄВОГО ЦИКЛУ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ. ПРОЦЕСИ, ПРОДУКТИ, РЕСУРСИ
Розділ 5. ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Розглядаються основні положення трьох інженерій програмного забезпечення - прямої, оберненої і емпіричної; показується взаємо зв'язок двох інженерій програмного забезпечення, які нині часто використовуються разом. Розглядаються основні методи і засоби, які використовує пряма, обернена і емпірична інженерії.
5.1. Пряма інженерія
Пряма інженерія забезпечує процеси розробки програмного забезпечення з високорівневих абстракцій у вигляді специфікацій вимог і закінчуючи реалізацією програмного продукту у вигляді виконуваного коду. Як найповніше процеси прямої інженерії представлені в життєвому циклі програмного забезпечення (рис. 5.1).
Рис. 5.1. життєвий цикл програмного забезпечення
Доменний аналіз. Компоненти цієї фази життєвого циклу такі:
- процеси - орієнтовані на аналіз існуючого досвіду, нагромадженого в домені рішень з метою виділення елементів архітектури, коду, типів для подальшого використання їх у розробці;
- продукти - архітектура, код, тести, методи;
- ресурси - інструменти доменного аналізу, доменні експерти, доменні інженери.
Специфікування вимог. Компоненти цієї фази життєвого циклу такі:
- процеси - дії зі складання вимог до програмного забезпечення;
- продукти - специфікації вимог;
- ресурси - мови специфікацій, інженери вимог, комунікатори із з замовником.
Архітектурне і детальне проектування. Компоненти цієї фази такі:
- процеси - орієнтовані на створений архітектури І детального проекту;
- продукти - архітектура і детальний проект програмного забезпечення;
- ресурси - CASE, архітектура і системні програмісти. Кодування і тестування. Компоненти цієї фази такі:
- процеси - кодування і тестування програм;
- продукти - програми;
- ресурси - засоби програмування, програмісти і тестери. Супровід. Компоненти цієї фази такі:
- процеси - що коригують, адаптують, удосконалюють і оновлюють супровід. Коригуючий супровід - зміна програмного забезпечення з мстою виправлення помилок, допущених на попередніх фазах життєвого циклу. Адаптуючий супровід - зміна програмного забезпечення у відповідь на зміни навколишнього середовища. Вдосконалюючий супровід - зміна програмного забезпечення задля вдосконалення його властивостей. Відновлюючий супровід - зміна програмного забезпечення задля відновлення його працездатності;
- продукти - супроводжуване програмне забезпечення;
- ресурси - засоби програмування, програмісти, інженери з супроводу.
Ліквідація. Компоненти цієї фази такі:
- процеси - відновлення, переробка, повторне використання І знищення програмного забезпечення. Відновлення - це відновлення працездатності програмною забезпечення. Переробка - це реінженерія або міграція програмного забезпечення. Повторне використання - це виділення з програмного забезпечення частин компонентів, які можна використовувати знову в розробці нового програмного забезпечення.
Знищення - це знищення неутилізованих залишків програмного забезпечення;
- продукти - повторно використані компоненти;
- ресурси — екстрактори, програмісти, експерти.