Атрибуты качества программного обеспечения · Конспекты по бизнес-анализу

Главные идеи#

Атрибуты качества — ещё не все нефункциональные требования#

Нефункциональные требования включают атрибуты качества (quality attributes), проектные ограничения и требования к внешним интерфейсам. Атрибуты качества — самая большая их часть. Глава начинается с истории о системе отопления учебного класса: она выполняла записанные требования, но шумела так, что вести урок было невозможно. Функциональность без заданного качества — это полпродукта.

Внешние и внутренние атрибуты#

Вслед за Бассом, Клементсом и Кацманом (Bass, Clements, Kazman) авторы делят атрибуты на внешние — они проявляются при работе системы и важны в первую очередь пользователям — и внутренние, важные разработчикам и тем, кто сопровождает систему; до пользователей они доходят косвенно.

Внешние (10)	Что означает	Типичная мера
Доступность	Доля запланированного времени, когда системой можно пользоваться	% времени работы в оговорённые часы; MTTF / (MTTF + MTTR), где MTTF — среднее время до отказа, а MTTR — среднее время восстановления
Удобство установки	Простота установки, обновления, отката, удаления	Среднее время установки неподготовленным пользователем
Целостность	Защита данных от потери или повреждения	Пройдено / не пройдено: атомарные обновления, резервное копирование и восстановление
Совместимость	Обмен данными с другими системами и устройствами	Поддерживаемые форматы и системы
Производительность	Время отклика, пропускная способность, ёмкость данных, число одновременных пользователей, предсказуемость, поведение при перегрузке	Секунды, транзакции в час, число пользователей
Надёжность	Работа без сбоев в течение периода	Среднее время между отказами (MTBF), % успешных операций
Устойчивость	Разумное поведение при неверном вводе, отказе компонентов, необычных условиях	Наблюдаемый результат после сбоя
Защита (safety)	Предотвращение вреда людям или имуществу	Предотвращённые опасности; часто регулируется нормативами
Безопасность (security)	Блокирование несанкционированного доступа и вредоносного кода	Пройдено / не пройдено по каждой угрозе
Удобство использования	Лёгкость освоения и эффективность работы	Время выполнения задачи, % задач без посторонней помощи, число ошибок, число шагов

Внутренние (6): эффективность (экономное использование процессора, памяти и хранилища), возможность модификации (простота понимания, исправления, расширения и адаптации), переносимость, возможность повторного использования, масштабируемость и проверяемость (тестируемость).

Какие атрибуты важны, зависит от системы. Во встроенных системах на первом месте производительность, эффективность, надёжность, устойчивость, защита и удобство использования; в веб- и корпоративных приложениях — доступность, целостность, совместимость, производительность, масштабируемость, безопасность и удобство использования.

Три предостережения из книги. Очень высокая доступность стоит очень дорого: авторы описывают систему управления воздушным движением, где для неё понадобилось полное резервирование оборудования. Надёжность — запаздывающий показатель: достигнута ли цель, вы узнаете, только когда период закончится. И формулируйте наблюдаемый результат, а не механизм: «использовать пароли» — это проектное решение, а «менять цены могут только уполномоченные пользователи» — требование.

Пять шагов выявления атрибутов качества#

Подход, который Вигерс и Битти приписывают Джиму Броссо (Jim Brosseau):

Начните с полного списка из шестнадцати атрибутов, чтобы ничего не забыть.
Сократите список. Пройдитесь по заинтересованным сторонам и решите, какие атрибуты применимы. Запишите, почему каждый атрибут включён или исключён.
Приоритизируйте попарно. Для каждой пары спросите: «Если бы существовали только эти два, какой важнее?» Итоговые суммы ранжируют атрибуты. Это фокусирует дальнейшее выявление и заранее решает будущие компромиссы. Привлеките разработчиков и сотрудников поддержки: их приоритеты часто отличаются.
Выявите конкретные ожидания. На вопрос «Насколько надёжной она должна быть?» пользователи редко отвечают что-то полезное. Задавайте прицельные вопросы и спрашивайте, что было бы неприемлемо: пределы часто назвать проще, чем цели.
Запишите измеримые требования. Для каждого нужны единица измерения, минимально приемлемый уровень и целевое значение.

Planguage: точные целевые значения#

Planguage Тома Гилба заменяет одно предложение набором ключевых слов. TAG задаёт уникальный идентификатор; AMBITION описывает намерение; SCALE называет единицу измерения; METER точно указывает, как измерять; MUST — минимально приемлемый уровень; GOAL — целевое значение с указанием источника; STRETCH и WISH фиксируют более высокие ожидания; FAIL описывает провал вместо успеха; DEFINED поясняет специальные термины. METER прекращает споры о том, как было измерено значение, а одни только SCALE и METER уже убирают большую часть неоднозначности.

Компромиссы и ограничения#

Улучшение одного атрибута сказывается на других, причём несимметрично. Усиление безопасности обычно стоит производительности, а ускорение почти не влияет на безопасность. Рост производительности, как правило, вредит возможности модификации и переносимости; лучшая переносимость, как правило, помогает совместимости, повторному использованию и тестируемости. Ваше попарное ранжирование подскажет, чем поступиться.

Ограничения сужают выбор разработчиков: обязательные технологии, пределы платформы, стандарты кодирования заказчика, обратная совместимость, нормативные требования, пределы оборудования, существующий пользовательский интерфейс, внешние интерфейсы. Следите, не выдают ли пользователи решение за требование («платежи должны проходить через провайдера X»). Спрашивайте «зачем?», пока не дойдёте до потребности. Если предложенное решение действительно верное, оставьте ограничение, но сначала проверьте его.

Пример#

«Мастерская», вымышленная сеть веломастерских, оставляет в коротком списке доступность, производительность, удобство использования, безопасность, целостность и совместимость (с поставщиком запчастей). Попарное сравнение ставит на первое место удобство использования и целостность. Поэтому если более богатый экран записи угрожает времени отклика, в согласованных пределах побеждает удобство использования.

Текст

TAG:      Performance.Booking.SlotSearch
AMBITION: Клиенты видят свободные окна для ремонта почти мгновенно.
SCALE:    Секунды от нажатия «Найти окна» до полного отображения списка окон.
METER:    50 поисков с замером времени на телефоне среднего класса в часы работы.
MUST:     не более 4 секунд для 95% поисков.
GOAL:     не более 2 секунд для 95% поисков <- владелец
STRETCH:  не более 1 секунды для 95% поисков.
DEFINED:  Телефон среднего класса: модель, которую команда считает типичной для клиентов.

Подводные камни#

«Удобный» или «быстрый» без единицы измерения → добавьте SCALE, METER и уровень MUST.
Указан механизм (автосохранение, пароли) → укажите наблюдаемый результат.
Прямо спрашивать у пользователей цифры → спрашивайте о задачах и о том, что было бы неприемлемо.
Забыты внутренние атрибуты → спросите разработчиков и поддержку о возможности модификации и тестируемости.
Требовать предельной доступности, не оценив её стоимость → покажите цену, прежде чем согласовывать целевое значение.

Источники и что почитать#

K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 14 (атрибуты качества, шаги выявления по Броссо, Planguage, компромиссы между атрибутами, ограничения).