Серія міжнародних стандартів ISO/IEC 25000, також відомих як Системні та програмні вимоги якості і оцінка (System and Software Quality Requirements and Evaluation), визначає характеристики, якими оцінюється якість програмного продукту.
Стандарт ISO/IEC 25010 містить термінологію для визначення, вимірювання та оцінки якості систем та програмних продуктів. Він визначає вісім характеристик якості програмного забезпечення, серед яких: функціональна придатність, рівень продуктивності, сумісність, зручність використання, надійність, безпека, зручність супроводу, портативність.
Стандарт ISO/IEC 25010 є ґрунтовним переглядом стандарту ISO/IEC 9126. У новий стандарт додано додаткові характеристики та підхарактеристики, які детальніше описують процес якості програмного продукту, а також введені уточнення та перегрупування характеристик для більш ясного їх розуміння.
Якість програмного забезпечення – це здатність програмного продукту, згідно з вказаними умовами, задовольняти встановлені потреби. (ISO 25000:2014).
Функціональна придатність (Functional Suitability)
Функціональна придатність (Functional Suitability) включає функціональну повноту, функціональну правильність, функціональну відповідність.
Функціональна повнота (Functional completeness) — ступінь покриття сукупності функцій всіх визначених завдань і цілей користувача.
Функціональна коректність (Functional correctness) — ступінь забезпечення продуктом чи системою необхідного рівня правильних результатів.
Функціональна відповідність (Functional appropriateness) — ступінь, з яким функції сприяють виконанню завдань і досягненню цілей.
Ефектиність продуктивності (Performance efficiency)
Ефектиність продуктивності (Performance efficiency) включає часові характеристики, використання ресурсів, місткість.
Часові характеристики (Time behaviour) — ступінь відповідності вимогам про час відповіді, час обробки і показники пропускної здатності продукта або системи.
Використання ресурсів (Resource utilization) — ступінь задоволення вимог про споживання обсягів і видів ресурсів продуктом або системою при виконанні їх функцій.
Місткість (Capacity) — ступінь відповідності вимогам граничних значень параметрів продукта або системи.
Сумісність (Compatibility)
Сумісність (Compatibility) включає співіснування та функціональну сумісність.
Співіснування (Co-existence) — здатність продукта сумісно функціонувати з іншими незалежними продуктами у спільній середі з розділенням спільних ресурсів і без негативного впливу на будь-який інший продукт.
Функціональна сумісність (Interoperability) — здатність двох або більше систем, продуктів або компонентів обмінюватис даними і використовувати такі дані.
Зручність використання (Usability)
Зручність використання (Usability) включає можливість визначення придатності, можливість вивчення, керованість, захист від помилок користувача, естетика користувацкого інтерфейсу, доступність.
Можливість визначення придатності (Appropriateness recognizability) — можливість користувача зрозуміти чи підходить продукт або система для їхніх потреб.
Можливість вивчення (Learnability) — можливість використання продукта або системи певними користувачами для досягнення конкретних цілей навчання для експлуатації продукта або системи з ефективність, результативністю, без ризику і у відповідності з вимогами у вказаному контексті використання.
Керованість (Operability) — наявність в продукті або системі атрибутів, які забезпечують просте управління та контроль.
Захист від помилок користувача (User error protection) — рівень системного захисту користувачів від помилок.
Естетика користувацького інтерфейсу (User interface aesthetics) — ступінь задоволеності користувача інтерфейсом взаємодії.
Доступність (Accessibility) — можливість викорситання продукту або системи для досягнення певної мети у вказаному контексті використання широким колом осіб з різними можливостями.
Надійність (Reliability)
Надійність (Reliability) включає зрілість, готовність, відмовостійкісь, відновлюваність.
Зрілість (Maturity) — ступінь відповідності системи, продукта або компонента при нормальній роботі вимогам надійності.
Готовність (Availability) — ступінь працездатності і доступності системи, продукта або компонента.
Відмовостійкість (Fault tolerance) — здатність системи, продукта або компонента працювати як призначено, не дивлячись на наявність дефектів програмного забезпечення або апаратниї засобів.
Відновлюваність (Revoverability) — здатність продукта або системи відновити дані та необхідний стан системи у випадку переривання або збою.
Безпека (Security)
Безпека (Security) включає неможливість заперечення, цілісність, конфіденційність, відстежуваність, автентичність.
Неможливість заперечувати (Non-repudiation) — впевненість, що хтось не може заперечувати дійсність чогось. Себто можливісь беззаперечно довести факт події або дії таким чином, що цей факт не можна заперечити.
Цілісність (Integrity) — ступінь запобігання системою, продуктом або компонентом несанкціоноваго доступу до модифікацій даних.
Конфіденційність (Confidentiality) — забезпечення продуктом або системою обмеження доступу до даних тільки для тих, кому доступ довзволено.
Відстежуваність (Accountability) — ступінь, до якої дії об’єкта можуть бути відстежені однозначно.
Автентичність (Authenticity) — ступінь достовірності, відповідності об’єкта або ресурса необхідному об’єкту або ресурсу.
Зручність супроводу (Maintainability)
Зручність супроводу (Maintainability) включає модульність, можливість багаторазового використання, можливість аналізу, можливість модифікацій, можливість тестування.
Модульність (Modularity) — ступінь представлення системи або програми у вигляді окремих блоків таким чином, щоб зміна одного компонента здійснювала мінімальний вплив на інші компоненти.
Можливість багаторазового використання (Reusability) — ступінь, в якій актив може бути використаний в декількох системах чи при створенні інших активів.
Можливість аналізу (Analysability) — ступінь простоти оцінки впливу змін однієї або більше частин на продукт або систему або простоти діагностики продукта для виявлення недоліків та причин відмов, або простоти ідетифікації частин, які порібно змінювати.
Можливість модифікацій (Modifiability) — ступінь простоти ефективної та раціональної зміни продукту або системи без додавання дефектів та зниження якості продукта.
Можливість тестування (Testability) — ступінь простоти ефективного та раціонального визначення для системи, продукта або компонента критеріїв тестування, а також простоти виконання тестування з метою визначення відповідності цим критеріям.
Портативність (Portability)
Портативність (Portability) включає можливість адаптації, можливість встановлення, можливість заміни.
Можливість адаптації (Adаptability) — ступінь простоти ефективної та раціональної адаптації для удосконалених апаратних засобів, програмного забезпечення, інших операційних середовищ або умов використання.
Можливість встановлення (Installability) — ступінь простоти ефективного, раціонального, успішного встановлення або видалення продукта або системи в заданому середовищі.
Можливість заміни (Replaceability) — здатність продукта замінити інший конкретний програмний продукт для досягнення тих самих цілей в тих же умовах.
Вимоги до програмного забезпечення
Вимоги до програмного забезпечення – це опис характеристик і функцій цільової системи. Вимоги передають очікування користувачів від програмного продукту. Вимоги можуть бути очевидними або прихованими, відомими або невідомими, очікуваними або неочікуваними з точки зору клієнта.
Розробка вимог
Процес збору вимог до програмного забезпечення від клієнта, їх аналізу та документування відомий як розробка вимог.
Метою розробки вимог є розробка та підтримка складного, описового документа “Специфікація системних вимог”.
Процес розробки вимог включає наступні стадії:
- Техніко-економічне обґрунтування
- Збір вимог
- Специфікація вимог до програмного забезпечення
- Перевірка вимог програмного забезпечення
ТЕО (техніко-економічне обґрунтування)
Коли клієнт звертається до організації за розробкою бажаного продукту, у нього виникає приблизне уявлення про те, які функції має виконувати програмне забезпечення та які функції очікуються від програмного забезпечення.
Посилаючись на цю інформацію, аналітики детально вивчають, чи можливо розробити бажану систему та її функціональність.
Це техніко-економічне обґрунтування спрямоване на досягнення мети організації. У цьому дослідженні аналізується, чи можна практично матеріалізувати програмний продукт з точки зору впровадження. Досліджуються технічні аспекти проєкту та продукту, такі як зручність використання, ремонтопридатність, продуктивність та здатність до інтеграції.
Результатом цього етапу має бути звіт про техніко-економічне обґрунтування, який повинен містити адекватні коментарі та рекомендації для керівництва щодо того, чи слід розпочинати проєкт.
Збір вимог
Якщо техніко-економічний звіт є позитивним для реалізації проєкту, наступний етап починається зі збору вимог від користувача. Аналітики та інженери спілкуються з клієнтом і кінцевими користувачами, щоб дізнатися їхні ідеї щодо того, що має надавати програмне забезпечення та які функції вони хочуть включати в програмне забезпечення.
Специфікація вимог до програмного забезпечення
SRS — це документ, створений системним аналітиком після збору вимог від різних зацікавлених сторін.
SRS визначає, як передбачене програмне забезпечення взаємодіятиме з апаратним забезпеченням, зовнішніми інтерфейсами, швидкістю роботи, часом відгуку системи, переносимістю програмного забезпечення на різні платформи, зручністю обслуговування, швидкістю відновлення після збою, безпекою, якістю, обмеженнями тощо.
Вимоги, отримані від клієнта, написані природною мовою. Системний аналітик відповідає за документування вимог технічною мовою, щоб вони могли бути зрозумілими та корисними групі розробників програмного забезпечення.
Перевірка вимог програмного забезпечення
Після розробки специфікацій вимог, починається перевірка цих вимог. Користувач може попросити незаконне, непрактичне рішення або експерти можуть неправильно витлумачити вимоги. Це призвести до суттєвих збитків, якщо не внести виправлення. Вимоги можна перевірити на такі умови:
- Чи можливо їх практично реалізувати
- Чи вони коректні та відповідають функціям і домену програмного забезпечення
- Чи є якісь неясності
- Чи вони повні
- Чи можна їх продемонструвати
Процес виявлення вимог
Процес виявлення вимоги містить наступні фази:
- Збір вимог – розробники обговорюють їх із клієнтом і кінцевими користувачами та знають їхні очікування від програмного забезпечення.
- Організація вимог – розробники встановлюють пріоритети та впорядковують вимоги в порядку важливості, терміновості та зручності.
- Обговорення. Якщо вимоги є неоднозначними або є деякі конфлікти у вимогах різних зацікавлених сторін, якщо вони є, тоді це обговорюється із зацікавленими сторонами. Щоб усунути двозначність і конфлікти, вони обговорюються для ясності та коректності. Нереалістичні вимоги доцільно відхилити чи модифікувати.
- Документація. Усі формальні та неофіційні, функціональні та нефункціональні вимоги систематизуються та документуються.
Методи виявлення вимог
Виявлення вимог — це процес з’ясування вимог до системи програмного забезпечення шляхом спілкування з клієнтом, кінцевими користувачами, користувачами системи та іншими, хто зацікавлений у розробці системи програмного забезпечення.
Існують різні способи виявити вимоги: інтерв’ю (співбесіди), опитування, анкетування, розбір задачі, аналіз домену, мозковий штурм, прототипування, спостереження.
Інтерв’ю (співбесіди)
Співбесіди є сильним засобом збору вимог. Організація може проводити кілька типів співбесід, таких як:
- Структуровані (закриті) інтерв’ю, де кожна окрема інформація, яку потрібно зібрати, вирішується заздалегідь, вони чітко слідують шаблону та предмету обговорення.
- Неструктуровані (відкриті) інтерв’ю, де інформація для збору не вирішується заздалегідь, більш гнучкі та менш упереджені.
- Усні опитування
- Письмові інтерв’ю
- Індивідуальні співбесіди, які проводяться між двома людьми за столом.
- Групові інтерв’ю, які проводяться між групами учасників. Вони допомагають виявити будь-які відсутні вимоги, оскільки задіяно багато людей.
Опитування
Організація може проводити опитування серед різних зацікавлених сторін, запитуючи про їхні очікування та вимоги щодо майбутньої системи.
Анкети
Документ із заздалегідь визначеним набором об’єктивних запитань і відповідних варіантів передається всім зацікавленим сторонам для відповіді.
Розбір задачі
Команда інженерів і розробників може проаналізувати роботу, для якої потрібна нова система. Якщо у клієнта вже є програмне забезпечення для виконання певної операції, воно вивчається та збираються вимоги до запропонованої системи.
Аналіз домену
Кожне програмне забезпечення належить до певної категорії домену. Експерти у цій галузі можуть надати велику допомогу для аналізу загальних і конкретних вимог.
Мозковий штурм
Між різними зацікавленими сторонами проводяться неформальні дебати, і всі їхні внески записуються для подальшого аналізу вимог.
Прототипування
Прототипування — це створення користувальницького інтерфейсу без додавання детальної функціональності, щоб користувач міг інтерпретувати особливості запланованого програмного продукту. Це допомагає краще уявити вимоги. Відгуки клієнтів служать вхідними даними для збору вимог.
Спостереження
Команда експертів відвідує організацію або робоче місце клієнта. Вони спостерігають за фактичною роботою існуючих встановлених систем. Вони спостерігають за робочим процесом у клієнта та за тим, як вирішуються проблеми виконання. Команда сама робить деякі висновки, які допомагають сформувати вимоги, які очікуються від програмного забезпечення.
Характеристики вимог до програмного забезпечення
Збір вимог до програмного забезпечення є основою всього проєкту розробки програмного забезпечення. Тому вони мають бути чіткими, правильними та чітко визначеними.
Повна специфікація вимог до програмного забезпечення має бути:
- Ясною
- Правильною
- Послідовною
- Зрозумілою
- Можливою для внесення модифікацій, змін
- Можливою для перевірки
- Пріоритизованою
- Однозначною
- Відстежуваною
Функціональні та нефункціональні вимоги
Функціональні вимоги. До цієї категорії належать вимоги, пов’язані з функціональним аспектом програмного забезпечення.
Нефункціональні вимоги. До цієї категорії відносяться вимоги, не пов’язані з функціональним аспектом програмного забезпечення. Це неявні або очікувані характеристики програмного забезпечення, про які користувачі роблять припущення (сумісність, продуктивність, портативність, безпека, зручність використання тощо).
В цьому відео поговоримо про якість ПЗ та вимоги
00:06 Якість ПЗ
06:17 Функціональна придатність
07:34 Ефектиність продуктивності
08:32 Сумісність
09:40 Зручність використання
12:21 Надійність
13:37 Безпека
17:25 Зручність супроводу
19:43 Портативність
20:45 Вимоги до ПЗ
22:11 Розробка вимог
23:18 Техніко-економічне обґрунтування
24:44 Збір вимог
25:10 Специфікація вимог до ПЗ
26:31 Перевірка вимог до ПЗ
27:48 Процес виявлення вимог
29:25 Методи виявлення вимог
33:22 Функціональні і нефункціональні вимоги