Вступ до інженерії програмного забезпечення

4.4. Продукти

У загальному випадку продуктом може бути будь-який компонент (артефакт) або документи, що з'явилися в результаті виконання процесу.

Продуктами як складовими фаз життєвого циклу разом з кінцевим продуктом с результати кожної окремої фази життєвого циклу (вимоги, проект, реалізація, тести). Так само, як процеси, продукти поділяють на вертикальні і горизонтальні. До останніх належать результати виконання горизонтальних процесів.

В уніфікованому процесі продукти як результати виконання процесів називаються робочими продуктами і утворюють комплек­ти. Розрізняються такі комплекти: вимог, проектування, реалізації, впровадження, управління (планування та експлуатації).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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