---

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

Примітка 2. Множину внутрішніх метрик наведено в ISO/IEC 9126-3.

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

Використання показників якості дає змогу розробнику програмного засобу своєчасно іденти­фікувати можливі проблеми в ході розробляння, пов’язані з якістю, і своєчасно виконати кори­гувальні дії. . .

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

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

Примітка 1. Загальний процес оцінювання наведено в ISO/IEC 14598-1.

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

Процес оцінювання охоплює п’ять дій, перелічених нижче:

• встановлення вимог до оцінювання, яке полягає в ідентифікації загальних вимог до якості відповідно до узгодженої моделі якості. Цю дію описано в 6.2;

• специфікація оцінювання, яка полягає у визначанні зовнішніх метрик і цільових значень вимірювання (критеріїв оцінювання). Цей захід описаний у 6.3.1. Крім того, специфікація поля­гає у визначанні внутрішніх метрик і цільових значень вимірювання (критеріїв оцінювання). Цей захід описаний у 6.3.2;

• проектування оцінювання, яке полягає в плануванні дій зі збирання даних. Цей захід описаний у 6.4.1 і 6.4.2; .

• виконання оцінювання, яке полягає в накопичуванні внутрішніх виміряних значень протя­гом розробляння та їх порівнювання з цільовими значеннями (оцінювання під час розробляння). Значення внутрішніх атрибутів (показники якості) використовують для отримування оцінки якості кінцевого продукту. Це описано в 6.5.1. Захід з виконання оцінювання охоплює також збирання зовнішніх виміряних значень, коли вони стають доступними, та їх порівняння з цільовими зна­ченнями (оцінювання якості продукту). Цей захід описаний у 6.5.2;

• зворотний зв’язок з організацією, заснований на огляді результатів оцінювання. Цей захід описаний у 6.6.

Оцінювання програмного продукту можна виконувати в контексті будь-якого процесу жит­тєвого циклу.

Примітка 1. Процеси життєвого циклу програмного забезпечування визначені в ISO/IEC 12207:1995.

Цей стандарт стосується, перш за все, процесів розробляння.

Примітка 2. Процеси розробляння наведені у 5.3 ISO/IEC 12207. Як стверджується в ISO/IEC 12207, може також виникнути потреба розглянути процес супроводження (5.5), а також процеси підтримування життєвого циклу (розділ 6) і організаційні процеси життєвого циклу (розділ 7). Коли цей стандарт використовують у ситуації розробляння програмного засобу для аутсорсингу, він також застосовний для процесу замовляння і процесу постачання, наведених у ISO/IEC 12207, підрозділи 5.1 і 5.2.

6. ВИМОГИ ДО ПРОЦЕСУ ОЦІНЮВАННЯ

   1. Загальні вимоги

Цей розділ визначає загальні вимоги до організації і спеціальні вимоги до проекту.

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

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

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

Примітка 1. Процеси життєвого циклу наведено в ISO/IEC 12207. Розробляння описано в підрозділі 5.3.

Примітка 2. Короткий огляд оцінювання програмного продукту можна знайти в ISO/IEC 14598-1.

Розробник повинен координувати заходи щодо оцінювання з процесами і заходами підтри­мування.

Примітка 3. Процеси підтримування наведено в ISO/IEC 12207, зокрема, процес забезпечування гарантії якості (6.3), процес верифікації (6.4), процес валідацїі (6.5) і процес аудиту (6.7).

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

Цей підрозділ стосується встановлювання загальних вимог до якості та аналізування їх здійсненності.

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

Примітка 1. Рівні цілісності програмних засобів описані в ISO/IEC 15026.

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

Примітка 2. Модель якості описана в ISO/IEC 9126-1.

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

Примітка 3. Увагу слід зосередити на зовнішніх атрибутах продукту.

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

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

Ідентифіковані вимоги до якості можуть конфліктувати або перетинатися. Конфлікти між вимогами повинні бути розв’язані. Крім того, якщо вибір вимог до якості перебуває у конфлікті з вартістю, термінами або функційністю системи, ці або інші вимоги потрібно змінити.

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

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

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

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

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

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

Примітка 1. Вимірювання та оцінювання зовнішніх атрибутів зазвичай виконують після завершення розробляння.

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

Примітка 2. Зазвичай ці сутності є частиною кінцевого продукту (наприклад, система, яка працює, або настанова користувача).

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

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

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

Примітка 3. Цільові значення дають кількісне подання вимог до якості.

Примітка 4. Цільові значення використовують як критерії оцінювання.

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

Розробник повинен виконувати ретельне аналізування здійсненності вимог до якості. Вар­то врахувати досвід попередніх проектів організацій-розробників з досягнення подібних вимог до якості.

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

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

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

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

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

Примітка 2. Відібрані сутності зазвичай бувають проміжними продуктами і діями.

Розробник повинен визначити, які внутрішні атрибути потрібно вимірювати.

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

Розробник повинен ідентифікувати метрики для кожної можливої комбінації атрибутів і сут- ностей.

Розробник повинен визначити набір внутрішніх атрибутів, який:

• охоплює кожний доречний проміжний продукт і сутність;

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

• охоплює ідентифіковані ризики продукту і розробляння.

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

Повинні бути долучені придатні виміри тенденцій.

Примітка 5. У разі періодичного застосування, деякі метрики корисні для ідентифікації тенденцій в процесі розробляння програмного засобу. Приклади таких вимірів-тенденцій — Кількість завершених модулів, Кількість вирішених проблем, Кількість змінених вимог тощо.

Розробник повинен визначити набір внутрішніх атрибутів, які стосуються всіх зовнішніх ат­рибутів, тобто всіх вимог до якості. Ці атрибути використовують як показники якості.

Примітка 6. Потрібно проаналізувати придатні проміжні продукти і збирати дані внутрішнього вимірювання з дво­ма цілями:

• оцінити якість проміжних продуктів, щоб визначити показники виконання (або невиконання) вимог до їх якості;

• одержати прогноз якості кінцевого продукту.

Примітка 7. ISO/IEC 9126-3 можна використовувати як настанову щодо вибору показників.

Розробник повинен описати прогнозну модель для певного показника якості, тобто взає­мозв’язок між показниками і зовнішніми атрибутами якості.

Примітка 8. Показник необов'язково повинен мати відношення до атрибуту якості, для вимірювання якого він вибраний. Проте, зв’язок між показником(-ами) і відповідним атрибутом(-ами) якості повинен бути чітко визначений.

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

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

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

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

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

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