Оцінювання програмних продуктів для того, щоб задовольнити потреби в частині якості програмного забезпечення, є одним із процесів у життєвому циклі розроблення програмного забезпечення. Якість програмного продукту може оцінюватися за допомогою вимірювання внутрішніх атрибутів (зазвичай статичних вимірювань проміжних продуктів), або за допомогою вимірювання зовнішніх атрибутів (зазвичай за допомогою вимірювання поведінки виконуваного коду), або за допомогою вимірювання атрибутів якості під час використовування. Ціль полягає в тому, щоб продукт давав потрібний результат у певному контексті його використовування (рисунок 2).
Якість процесу (якість будь-якого з процесів життєвого циклу, визначених в ISO/IEC 12207) покращує якість продукту, а якість продукту сприяє підвищенню якості під час використовування. Таким чином, оцінювання і вдосконалювання процесу є засобами для покращування якості продукту, а оцінювання й покращування якості продукту — одним із засобів поліпшення якості під час використовування. Так само, оцінювання якості під час використовування може забезпечити зворотний зв’язок для покращування продукту, а оцінювання продукту може надати зворотний зв'язок для вдосконалювання процесу.
Відповідні внутрішні атрибути програмного забезпечення — це передумова для досягнення потрібної зовнішньої поведінки, а відповідна зовнішня поведінка — передумова для досягнення якості під час використовування (див. рисунок 2).
Вимоги для якості програмного продукту загалом охоплюватимуть критерії оцінювання внутрішньої якості, зовнішньої якості та якості під час використовування, для того щоб задовольнити потреби розробників, супроводжувачів, покупців і кінцевих користувачів (див. розділ 8 ISO/IEC 14598-1:1999).
Якість продукту і життєвий цикл
Погляди на внутрішню якість, зовнішню якість і якість під час використовування змінюються протягом життєвого циклу програмного забезпечення. Наприклад, якість, специфікована як вимоги до якості на початку життєвого циклу, переважно відбиває погляди на продукт ззовні, з боку користувачів, і відрізняється від якості проміжного продукту, як-от якість проекту, яку здебільшого бачать ізсередини, з позицій розробників. Технології, використовувані для досягнення потрібного рівня якості, як, наприклад специфікація й оцінювання якості, потрібні для підтримування цих різних точок зору. Для того щоб керувати якістю належним чином на кожній стадії життєвого циклу, треба визначати'ці перспективи і відповідні технології забезпечування якості.Ціллю є досягнення потрібної й достатньої якості, яка б відповідала справжнім потребам користувачів. ISO 8402 визначає якість у термінах здатності задовольнити заявлені та передбачу-' вані потреби. Проте потреби, заявлені користувачем, не завжди відбивають реальні потреби користувача, оскільки: (1) користувач часто не обізнаний стосовно своїх дійсних потреб, (2) потреби можуть змінюватися після того, як їх заявлено, (3) різні користувачі можуть мати різні операційні середовища і (4) може бути неможливо врахувати всі доречні типи користувачів, особливо для готового програмного забезпечення «з полиці». Отже, вимоги до якості не можуть бути цілком визначені перед початком проектування. Проте треба розуміти справжні потреби користувача настільки точно, наскільки можливо, і подавати їх у вимогах. Ціль — необов’язково досягнути бездоганну якість, але потрібно й достатньо якості для кожного визначеного контексту використовування, коли продукт поставляють і фактично використовують користувачі.
Шкали вимірювання для метрик, застосовуваних під час встановлення вимог до якості, можуть бути поділені на категорії, які відповідають різним ступеням задоволення вимог. Наприклад, шкалу можна було б поділити на дві категорії: незадовільна та задовільна, або на чотири категорії: перевершує вимоги, відповідає цілям, мінімально прийнятна та неприйнятна (див. ISO/IEC 14598-1). Категорії має бути специфіковано так, щоб і користувач, і розробник могли уникнути непотрібного перевищення вартості й графіка.
Є різні погляди на якість продукту і відповідні метрики на різних стадіях життєвого циклу програмного забезпечення (рисунок 3).
Роблять внесок Використання і зворотний зв’язок
Показує
.у специфікування
Верифікація
Примітка. Цей рисунок є спрощеною версією ISO/IEC 14598-1:1999, змодифікованою задля узгодженості з ISO/IEC 9126-1.
Рисунок 3 — Якість у життєвому циклі програмного забезпечення
Національна примітка
1SO/IEC 14598-1:1999 в Україні впроваджено як ДСТУ ISO/IEC 14598-1:2004 Інформаційні технології. Оцінювання програмного продукту. Частина 1. Загальний огляд
ISO/IEC 13407 в Україні впроваджено як ДСТУ EN ISO 13407:2007 Людиноцентричні процеси проектування діалогових систем (EN ISO 13407:1999, IDT)
Потреби користувача в якості може бути специфіковано як вимоги до якості за допомогою метрик під час використовування, зовнішніх метрик й, іноді, внутрішніх метрик. Ці вимоги, специфіковані метриками, треба використовувати як критерії лід час затверджування (валідування) продукту. Досягнення такої якості продукту, яка б задовольняла потреби користувача, зазвичай вимагає ітеративного підходу до розробляння програмного забезпечення з неперервним зворотним зв'язком до позицій користувача.
Примітка. Настанову щодо процесів проектування для діалогових систем наведено в ISO 13407.
Вимоги до зовнішньої якості специфікують' потрібний рівень якості з зовнішнього погляду. Вони вміщують вимоги, що випливають із потреб користувача, охоплюючи вимоги до якості під час використовування. Вимоги до зовнішньої якості використовують як цільові для валідацїі на різних етапах розробляння. Вимоги до зовнішньої якості для всіх характеристик якості, визначених у цьому стандарті, мають бути заявлені в специфікації вимог до якості, використовуючи зовнішні метрики, трансформовані у внутрішні вимоги до якості й застосовані як критерії під час оцінювання продукту.
Вимоги до внутрішньої якості конкретизують рівень потрібної якості з внутрішнього погляду на продукт. Вимоги до внутрішньої якості використовують для специфікування властивостей проміжних продуктів. Вони можуть охоплювати статичні й динамічні моделі, інші документи та початковий код. Вимоги до внутрішньої якості можна.використовувати як цільові для валідації на різних етапах розробляння. їх можна також використовувати для визначання стратегій розробляння та як критерії для оцінювання та перевіряння (верифікації) під час розробляння. Вони можуть допускати використання додаткових метрик (наприклад, у частині повторного використання), які перебувають поза сферою застосування ISO/IEC 9126. Спеціальні вимоги до внутрішньої якості мають бути специфіковані кількісно, використовуючи внутрішні метрики..
Внутрішня якість — це множина характеристик програмного продукту з внутрішнього погляду. Внутрішню якість вимірюють і оцінюють на відповідність вимогам до внутрішньої якості. Якість програмного продукту за окремими аспектами може бути поліпшена для реалізації коду, переглядання й тестування, але принциповий характер якості програмного продукту, поданий внутрішньою якістю, залишається незмінним до перепроектування.
Оцінювана .(або прогнозована) зовнішня якість — це якість, яку оцінюють або прогнозують для кінцевого програмного продукту на кожному етапі розробляння для кожної характеристики якості, базуючись на знанні внутрішньої якості.
Зовнішня якість — це множина характеристик програмного продукту з зовнішнього погляду. Це якість працюючого програмного забезпечення, яку зазвичай вимірюють і оцінюють під час тестування в імітованому середовищі на імітованих даних, використовуючи зовнішні метрики. Протягом тестування більшість дефектів має бути виявлено й усунено. Однак деякі дефекти можуть все ще залишатися після тестування. Оскільки важко відкоригувати архітектуру програмного забезпечення або інші основні аспекти проекту програмного забезпечення, основа проекту зазвичай залишається незмінною протягом тестування.
Оцінювана (або прогнозована) якість під час використовування — це якість, яку оцінюють або прогнозують для кінцевого програмного продукту на кожному етапі розробляння для кожної характеристики якості під час використовування, і вона основана на знанні внутрішньої та зовнішньої якості.
Примітка. Зовнішню якість і якість під час використовування можна оцінювати та прогнозувати впродовж розробляння за кожною характеристикою якості, визначеною в цьому стандарті, якщо розроблюють належні технології. Однак, якщо поточний стан справ не забезпечує необхідне о підтримування для прогнозування, досконалішу технологію має бути розроблено для того, щоб показати кореляцію між внутрішньою якістю,'зовнішньою якістю і якістю під час використовування.
Якість під час використовузання — це характеристика, що відображає погляд користувача на якість програмного продукту, застосовуваного в конкретному середовищі і.визначеному контексті використовування. Вона виміряє ступінь, у якому користувачі можуть досягти своїх цілей у певному' середовищі, а не властивості власне програмного забезпечення (якість під час використовування- визначено в розділі 7).
Примітка. Поняття «Користувачі» стосується будь-якого типу передбачених користувачів, охоплюючи як операторів, так і супроводжувачів, їхні вимоги можуть бути різними.
Рівень якості в середовищі, призначеному для користувачів, може відрізнятися від отриманого в сгредовищі для розробників через, відмінності між потребами й можливостями різних- користувачів та через різницю в апаратних засобах і підтримувальних середовищах. Користувач оцінює лише ті атрибути програмного забезпечення, які використовують для його завдань. Іноді атрибути програмного забезпечення, специфіковані кінцевим користувачем упродовж фази аналізування вимог, більше не відповідають вимогам користувача, в процесі використовування продукту, через зміну вимог користувача і складність конкретизації потреб, які мають на увазі.
Оцінювані елементи
Елементи можуть оцінювати безпосередньо вимірюванням або побічно за допомогою вимірювання їхніх проявів. Наприклад, процес може бути оцінено побічно за допомогою вимірювання й оцінювання його продукту, а продукт може бути оцінено побічно за допомогою вимірювання ефективності виконання завдання користувача (використовуючи метрики якості під час використовування).
Програмне забезпечення ніколи не працює самостійно, а завжди як частина більшої системи, що зазвичай складається з інших програмних продуктів, з якими воно має інтерфейси, апаратного забезпечення, персоналу операторів і потоків роботи. Завершений програмний продукт можуть оцінювати'за рівнями вибраних зовнішніх метрик. Такі метрики описують його взаємодію з власним середовищем і це оцінюють за допомогою спостерігання за програмним забезпеченням у дії. Якість під час використовування можуть вимірювати як ступінь, у якому продукт, застосовуваний конкретними користувачами,, відповідає їхнім, потребам у частині досягнення встановлених цілей стосовно результативності, продуктивності,, безпечності й задоволеності. Її було б природно доповнити вимірами конкретніших характеристик якості програмного продукту, які також можливо визначити якнайраніше в процесі розробляння.
На найранніх етапах розробляння можна вимірювати лише ресурси і процес. Коли проміжні продукти (специфікації, початковий код тощо) стають доступними, їх може бути оцінено за рівнями вибраних внутрішніх метрик. Ці метрики можна використовувати для прогнозування значень зовнішніх метрик. їх можна також виміряти самостійно, як дуже важливі передумови зовнішньої якості.
Подальше розрізнювання можна виконувати між оцінюванням програмного продукту й оцінюванням системи, у якій він працює.
Примітка 1. Наприклад, надійність Системи оцінюють спостереженням усіх відмов за будь-якої причини (апаратного забезпечення, програмного забезпечення, помилок людей тощо), тоді як надійність програмного продукту оцінюють екстрагуванням лише тих із спостережених відмов, що зумовлені дефектами (витоками яких є вимоги, проект або реалізація) у програмному забезпеченні.
До того ж те, де саме проходитиме межа оцінюваної системи, залежить від призначеності оцінювання і від того, хто є користувачами.
Примітка 2. Наприклад, якщо користувачами літака з комп’ютеризованою системою контролювання польоту вважають пасажирів, тоді система, від якої вони залежать, охоплює екіпаж, корпус літака й апаратне та програмне забезпечення системи контролювання польоту, а якщо користувачами вважають екіпаж, тоді система, від якої вони залежать, складається лише з корпусу літака і системи контролювання польоту.
Використання моделі якості
Якість програмного продукту треба оцінювати за допомогою визначеної моделі якості. Модель якості треба використовувати для встановлення цілей якості програмних продуктів і проміжних продуктів. Якість програмного продукту має бути ієрархічно розкладено до моделі якості, утвореної характеристиками і підхаракіеристиками, які можна використовувати як таблицю контрольних перевірянь щодо проблем, пов’язаних з якістю. Розділи 6 і 7 визначають ієрархічну модель якості (хоча' за певних обставин прийнятнішими можуть бути інші способи категоризації якості).
Практично неможливо виміряти всі внутрішні й зовнішні підхарактеристики для всіх частин великого програмного продукту. Так само, зазвичай непрактично вимірювати якість під час використовування для всіх можливих сценаріїв виконання завдання користувача. Ресурси для оцінювання треба розподіляти між різними видами вимірювання, залежно від цільових показників бізнесу і природи продукту та процесів проектування.
