---

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

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

Примітка. Якщо організація-розробник визначила набір модулів оцінювання, діяльність з планування охоплює та­кож вибирання модулів оцінювання. Документація модулів оцінювання описана в ISO/IEC 14598-6.

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

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

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

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

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

Примітка 2. Якщо організація-розробник визначила набір модулів оцінювання, ця діяльність охоплює також вибір мо­дулів оцінювання. Документацію модулів оцінювання описано в ISO/IEC 14598-6.

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

Моніторинг і контроль якості здійснюють протягом розробляння. Збирають фактичні значен­ня для внутрішніх атрибутів. У разі небажаних значень причину аналізують, даючи змогу, таким чином, розробнику розуміти і реагувати на проблеми.

Розробник повинен зібрати фактичні значення вимірювання для визначених внутрішніх атрибутів відповідно до визначених дій щодо збирання даних. У разі зміни вимог до якості роз­робник повинен переглянути специфікацію оцінювання (6.3) і проект оцінювання (6.4).

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

Розробник повинен порівняти фактичні значення з цільовими значеннями, якщо такі призначені.

Розробник повинен використовувати фактичні значення визначених показників для оціню­вання якості кінцевого продукту. Слід враховувати досвід минулих проектів організації-розробника з виконання подібних вимог до якості.

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

Розробник повинен використовувати фактичні значення для моніторингу тенденцій, щоб ідентифікувати ризики розробляння.

Розробнику потрібно проаналізувати фактичні значення для того, щоб ідентифікувати відхили. Ці відхили часто вказують на проблеми або на незвичайні умови. Завжди потрібно шукати пояс­нення появі відхилів. Іноді існують обґрунтовані причини для появи відхилів. У такому разі немає підстав для коригувальних дій.

За потреби слід виконувати дії, заплановані на випадок непередбачених ситуацій.

Оцінювання якості програмного продукту має місце, коли розробляння завершене. Збира­ють фактичні значення для зовнішніх атрибутів.

Примітка 1. Якщо можливо, компоненти програмного засобу можуть бути виміряні перед тим, як розробляння за­вершене.

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

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

Розробник повинен порівняти фактичні значення з цільовими значеннями (критерієм оціню­вання).

Примітка 2. Процес оцінювання, описаний у цьому стандарті, проводить розробник. ISO/IEC 14598-5 описує неза­лежний процес оцінювання.

Розробник повинен оцінити результати оцінювання. Фактичні значення необхідно підсумо­вувати і порівнювати з іншими значеннями, як, наприклад, часом і вартістю, для того, щоб прийняти обґрунтоване рішення про результат розробляння (як-от, удосконалення продукту, перегляд вимог тощо).

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

Розробник повинен зробити зібрані дані доступними в організації для їх використовування в інших проектах розробляння.

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

Примітка. Огляд оцінювання якості та зворотний зв'язок описані в ISO/IEC 14598-2.

ДОДАТОК А
(довідковий)

ВИЗНАЧЕННЯ ПОНЯТЬ З ІНШИХ СТАНДАРТІВ

У цьому додатку наведені визначення понять з ISO/IEC 14598-1, якщо не зазначено інше.

А.1 замовник (acquirer)

Організація, яка вирішила придбати чи замовляє систему, програмний продукт або програмну послугу у постачальника. [ISO/IEC 12207:1995]

А.2 атрибут (attribute)

Вимірна фізична або абстрактна властивість сутності.

Примітка. Атрибути можуть бути внутрішніми або зовнішніми

А.З розробник (developer)

Організація, яка виконує дії з розробляння в ході життєвого циклу програмного засобу (зокре­ма аналізування вимог, проектування, тестування тощо до приймання). [ISO/IEC 12207:1995]

А.4 безпосередній вимір (direct measure)

Вимір атрибута, який не залежить від вимірювання будь-якого іншого атрибута

А.5 модуль оцінювання (evaluation module)

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

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

A.6 зовнішній вимір (external measure)

Опосередкований вимір продукту, отриманий на основі вимірів поведінки системи, части­ною якої є продукт.

Примітка 1. Система охоплює будь-які пов’язані з нею апаратні засоби, програмні засоби (замовний програмний продукт або готовий програмний продукт) і користувачів.

Примітка 2. Кількість відмов, отриманих під час тестування, — це зовнішній вимір кількості помилок в програмі, оскільки кількість відмов підраховують під час експлуатування комп’ютерної системи, яка виконує програму.

Примітка 3. Зовнішні виміри можна використовувати для оцінювання атрибутів якості на завершальних стадіях проекту

А.7 зовнішня якість (external quality)

Ступінь, в якому продукт задовольняє специфіковані і здогадні потреби під час використо­вування у визначених умовах

А.8 відмова (failure)

Припинення здатності продукту виконувати необхідну функцію або його нездатність виконувати її в раніше заданих межах

А.9 помилка (fault)

Неправильний крок, процес або визначання даних в комп’ютерній програмі.

Примітка. Це визначення взяте з IEEE 610.12-1990.

А.10 здогадні потреби (implied needs)

Потреби, які можуть не бути встановлені, але є реальними потребами, що виникають під час використовування сутності в певних умовах.

Примітка. Здогадні потреби є реальними потребами, які можуть бути незадокументовані

А. 11 показник (indicator)

Вимір, який можна використовувати для оцінювання або прогнозування іншого виміру.

Примітка 1. Прогнозований вимір може бути виміром тієї самої або іншої характеристики якості програмного засобу.

Примітка 2. Показники можна використовувати як для оцінювання атрибутів якості програмного засобу, так і для оцінювання процесів розробляння. Вони є приблизними опосердкованими вимірами атрибутів

А.12 опосередкований вимір (indirect measure)

Вимір атрибута, отриманий на основі вимірів одного чи декількох інших атрибутів.

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

А.13 проміжний програмний продукт (intermediate software product)

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

Примітка. В деяких випадках проміжний продукт може бути також кінцевим продуктом

А.14 внутрішній вимір (internal measure)

Вимір самого продукту, безпосередній або опосередкований.

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

А.15 внутрішня якість (internal quality)

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

Примітка 1. Термін внутрішня якість, використовуваний в ISO/IEC 14598 на відміну від терміна зовнішня якість, означає те саме, що і якість за стандартом ISO 8402.

Примітка 2. Термін атрибут використовують у тому самому сенсі, що і термін характеристика у 4.21, тоді як у ISO/IEC 9126 термін характеристика використано в чіткішому значенні

А.16 супроводжувач (maintainer)

Організація, що здійснює діяльність із супроводу. [ISO/IEC 12207:1995]

А.17 вимірювати (measure)

Виконувати вимірювання

A.18 вимір (measure)

Число або категорія, присвоєні атрибуту сутності через виконання вимірювання

А.19 вимірювання (measurement)

Застосування метрики для присвоєння значення (яке може бути числом або категорією) з множини значень (шкали) атрибуту сутності.

Примітка. Використовуючи категорії, вимірювання може носити якісний характер. Наприклад, такий важливий ат­рибут програмного продукту як мова програмування початкової програми (АДА, С, КОБОЛ тощо) стосується якісної категорії

А,20 метрика (metric)

Метод вимірювання і шкала вимірювання.

Примітка 1. Метрики можуть бути внутрішніми або зовнішніми, а також безпосередніми або опосередкованими.

Примітка 2. Метрики містять методи для розподіляння якісних даних за категоріями

А.21 якість (quality)

Сукупність характеристик сутності, пов’язана з її здатністю задовольняти специфіковані та здогадні потреби.

Примітка 1. За умов укладання контракту або за регламентованих умов, як, наприклад, у сфері ядерної безпеки, потреби чітко специфіковані, але за інших умов здогадні потреби повинні бути ідентифіковані й визначені (ISO 8402:1994, примітка 1).

Примітка 2. В ISO/IEC 14598 відповідною сутністю є програмний продукт.

[ISO 8402:1994]

А.22 оцінювання якості (quality evaluation)

Систематичне визначання ступеня, в якому сутність здатна задовольняти встановлені вимоги.

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