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

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

Робочі продукти проектування оцінюються і вимірюються комбінацією таких чинників:

- внутрішня несуперечність і якість проектної моделі;

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

- перехід у комплект реалізації і впровадження у відповідні нотації (наприклад, трасування, генерація початкового коду, компіляція, редагування зв'язків);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.4.2. Робочі продукти, пов'язані з тестуванням

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

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

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

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

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

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

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

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

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

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

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

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