Можливо ви розумієте функціональні вимоги до свого продукту, але чи вивчили ви необхідні атрибути якості? Вони також неймовірно важливі.
Я закладаюся, що ви використовували програмні системи, які робили те, що від них вимагалося, але ви все одно їх ненавиділи. Можливо, вони були занадто повільними, часто зависали або їх юзер-інтерфейс був незручним. Це приклади продуктів, які задовольняли функціональні вимоги, але не задовольняли очікуванням щодо їх якості.
Не дивно, що майже всі набори вимог до програмного забезпечення зосереджені на функціональності, тих речах, які продукт повинен уміти робити або дозволяти робити користувачеві. Уважні аналітики та дизайнери також повинні вивчити різні типи нефункціональних вимог. Більшість з них відноситься до категорії вимог до атрибутів якості, які також називають факторами якості або вимогами до якості обслуговування. Іноді англійською їх називають «ilities», оскільки багато з них закінчуються на «-ility» (наприклад, scalability, reliability і тому подібне). Ми вирішили це не перекладати, так як не знайшли відповідного терміну в українській мові.
Ця стаття містить короткий вступ до поняття атрибутів якості, та вказує на компромісні рішення, які вам так чи інакше доведеться прийняти, обираючи між різними атрибутами. Неможливо оптимізувати всі фактори якості одночасно. Вам потрібно визначити, які з них є найважливішими для успіху клієнтів, і максимізувати їх.
Вимоги до атрибутів якості
Ретельне визначення атрибутів якості дає змогу створювати продукт, який приносить задоволення користувачам, а не просто робить те, що повинен робити. Дійсно класні продукти відображають оптимальний баланс конкуруючих якісних характеристик. Якщо ви не досліджуєте очікування клієнтів щодо якості під час виявлення потреб, вам просто пощастило, якщо продукт їх задовольняє. Більш вірогідним результатом є розчаровані користувачі та не менш розчаровані розробники.
Ви безпосередньо не реалізуєте вимоги щодо безпеки, надійності, мобільності, чи інших характеристик. Натомість ці атрибути якості служать джерелом багатьох функціональних вимог. Вони також керують архітектурними та дизайнерськими рішеннями.
Виправлення вже готової системи для досягнення суттєвих цілей якості коштує набагато більше, ніж їх розробка на самому початку. Тільки подумайте про незліченну кількість оновлень безпеки, які ми всі отримуємо для операційних систем і звичайних програм. Хіба не було б краще, якби розробники витрачали більше часу на розробку безпеки в першу чергу?
Термін «атрибути якості» (“quality attributes”) охоплює кілька десятків продуктових характеристик. Я бачив списки з 50 або більше атрибутами. Більшість проектних команд повинні враховувати лише кілька з них. Якщо розробники знають, які характеристики є найважливішими для успіху, вони можуть вибрати відповідні підходи до проектування та розробки для досягнення якості продукту.
Внутрішні та зовнішні атрибути якості
Один із способів класифікації атрибутів якості розрізняє характеристики, які видимі під час виконання програмного забезпечення (зовнішня якість), від тих, які не є видимими (внутрішня якість). Для користувачів насамперед важливі зовнішні фактори якості; внутрішні якості більш важливі для розробників і тих, хто буде відповідати за саппорт продукту потім. Внутрішні атрибути якості опосередковано сприяють задоволенню клієнтів, роблять простійшим вдосконалення, тестування та міграції продукту на нові платформи.
Таблиця 1 коротко визначає кілька внутрішніх і зовнішніх аспектів якості, які повинен враховувати кожен проект. Певні атрибути особливо важливі для конкретних типів проектів:
- Інтернет і корпоративні програми: доступність, цілісність, сумісність, продуктивність, масштабованість, безпека, зручність використання
- Вбудовані системи: продуктивність, ефективність, надійність, міцність, безпека, секьюрність, зручність використання
- Настільні та мобільні системи: продуктивність, безпека, зручність використання
Таблиця 1. Деякі атрибути якості програмного забезпечення
Вам може знадобитися підкреслити різні атрибути якості для різних компонентів системи. Продуктивність може бути критичною для певних компонентів, тоді як зручність використання чи безпека є найважливішими для інших. Крім того, ваші продукти можуть мати інші унікальні якості, які я тут не перерахував. Ігрові компанії, наприклад, можуть захотіти врахувати емоційні вимоги до свого програмного забезпечення.
Компроміси атрибутів якості
Деякі комбінації атрибутів одразу предстають як неминучі компроміси. Клієнти та розробники повинні вирішити, які атрибути важливіші за інші, і цих пріоритетів треба дотримуватися надалі, коли приймаються компромісні рішення щодо дизайну.
Малюнок 1 ілюструє деякі типові взаємозв’язки між атрибутами якості з Таблиці 1, хоча є винятки. Знак “+” у головному горизонтальному рядку вказує на те, що збільшення атрибута у відповідному рядку зазвичай позитивно впливає на атрибут у стовпці. Наприклад, підходи до проектування, які підвищують портативність програмного компонента, також спрощують підключення програмного забезпечення до інших програмних компонентів (сумісність), його повторне використання (reusability) і тестування (перевіряємість).
Малюнок 1. Деякі компромісні співвідношення між атрибутами якості.
Знак “-” у клітинці означає, що збільшення атрибута в цьому рядку загалом негативно впливає на атрибут у стовпці. Порожня клітинка означає, що атрибут у рядку мало впливає на атрибут у стовпці.
Продуктивність і ефективність негативно впливають на більшість інших атрибутів. Якщо ви пишете максимально жорсткий і швидкий код, який тільки можете, використовуючи всі прийоми кодування та покладаючись на побічні ефекти виконання, щоб заощадити кілька мілісекунд, ваш код, ймовірно, буде важче підтримувати та покращувати. Також можуть з’явитися складнощі з перенесенням програми на інші платформи, якщо ви налаштували код для певного операційного середовища.
До теми – Нефункціональні вимоги: про що забувають навіть досвідчені BA?
Системи, які оптимізують простоту використання, а також ті, які призначені для багаторазового використання та сумісності з іншими програмними чи апаратними компонентами, часто уповільнюють продуктивність. Одного разу я очолював проект зі створення компонента мейнфрейму загального призначення, який могли б викликати багато інших програм для створення графічних графіків X-Y. Ця програма працювала чудово та заощадила значний час розробки, але вона працювала повільніше, ніж програми, які включали власний графічний код для малювання. Ви повинні збалансувати можливу продуктивність (або інший атрибут) та очікувані переваги вашого рішення, щоб переконатися, що ви йдете на розумний компроміс.
Зверніть увагу, що матриця на Малюнку 1 не є симетричною. Тобто ефект збільшення атрибута A на атрибут B не обов’язково такий самий, як ефект збільшення B на атрибут A. Наприклад, на Малюнку 1 показано, що проектування системи для підвищення продуктивності не обов’язково впливає на безпеку: клітинка з рядком = Продуктивність із стовпцем = Безпека порожня. Однак клітинка з рядком = Безпека та стовпцем = Продуктивність містить знак мінус. Підвищення безпеки може знизити продуктивність, оскільки система повинна проходити більше рівнів автентифікації користувачів, шифрування та сканування зловмисного програмного забезпечення.
Щоб досягти оптимального балансу характеристик продукту, ви повинні розпізнати, визначити та пріоретизувати відповідні атрибути якості під час виявлення вимог. Коли ви визначаєте важливі атрибути якості для вашого проекту, використовуйте Малюнок 1, щоб уникнути цілей, які будуть конфліктувати. Нижче наведено кілька прикладів:
- Не очікуйте максимізації зручності використання, якщо програмне забезпечення має працювати на кількох платформах з мінімальними модифікаціями (portability). Різні платформи та операційні системи накладають різні обмеження та дають різні характеристики зручності використання.
- Важко повністю перевірити вимоги до цілісності високозахищених систем. Повторне використання загальних компонентів може порушити механізми безпеки.
- Дуже надійний код може демонструвати знижену продуктивність через перевірку даних і перевірку помилок, які він виконує.
Будьте обережні, щоб уникнути непотрібних обмежень і суперечливих вимог. Для розробників це може унеможливлювати повне задоволення вимог. Від такого ніхто не виграє.
Нехтуйте якістю на свій страх і ризик!
Вимоги до атрибутів якості – це не шматочки бажаної функціональності, які можна записати в Jira-тікет і застосувати, коли настане час. Вам потрібно заздалегідь виявити й проаналізувати такі нефункціональні вимоги, щоб ваша команда з самого початку могла зберегти бажаний баланс характеристик продукту.
Атрибути якості пронизують систему; це не просто доповнення, яке має бути пріоритетним для інших ваших функціональних історій. Продуманий підхід може позбавити вас від багатьох дорогих проблем пізніше, коли користувачі можуть скаржитися на продуктивність, взаємодію з користувачем, надійність або інші важливі характеристики якості.
Якість — у всіх її вимірах і значеннях — має бути вбудована в систему програмного забезпечення із самого початку, а не покладена на неї в кінці, як крем на торт лише для краси.
Оригінальна стаття – Those Other Requirements: Quality Attributes and Their Inescapable Trade-Offs, переклад Серебрянська Олександра (Business Analysis Community Kyiv), редактор – Марина Красовська, адаптована графіка з сайту Pixabay.