Приоритизация требований к качеству программного обеспечения

Невозможно иметь максимальное значение для всех качественных характеристик. Вот как решить, какие из них являются наиболее важными.

Изображение от Creativeart на Freepik

В идеальном мире каждый программный продукт должен иметь максимальное значение всех атрибутов качества. Система всегда будет доступна, никогда не выйдет из строя, мгновенно выдаст всегда правильные результаты, блокирует весь несанкционированный доступ и никогда не будет сбивать с толку пользователя. Разве это не было бы здорово?

Однако в действительности компромиссы и конфликты между определенными атрибутами не позволяют оптимизировать их все одновременно. Вы должны определить, какие атрибуты наиболее важны для успеха вашего проекта, а затем сформулировать для них конкретные цели, чтобы дизайнеры могли сделать соответствующий выбор. В этой статье описывается подход к выявлению и определению наиболее важных показателей качества вашего проекта, адаптированный консультантом. Метод Джима Бросо.

Шаг 1. Начните с широкой таксономии

Начните с рассмотрения богатого набора показателей качества, например, перечисленных в Таблице 1. многие другиено именно эти атрибуты чаще всего применяются к продуктам, содержащим программное обеспечение. Такая широкая отправная точка снижает вероятность упустить из виду важный аспект качества.

Таблица 1. Некоторые общие атрибуты качества программного обеспечения

Атрибут	Краткое описание
Доступность	Степень, в которой услуги системы доступны, когда и где они необходимы.
Эффективность	Насколько эффективно система использует ресурсы компьютера
Возможность установки	Насколько легко правильно установить, удалить и переустановить приложение
Честность	Степень защиты системы от неточности и потери данных.
Совместимость	Насколько легко система может соединяться и обмениваться данными с другими системами или компонентами.
Модифицируемость	Насколько легко поддерживать, изменять, улучшать и реструктурировать систему
Производительность	Насколько быстро и предсказуемо система реагирует на действия пользователя или другие события.
Портативность	Насколько легко можно заставить систему работать в других операционных средах
Надежность	Как долго работает система, прежде чем произойдет сбой
Многоразовое использование	Насколько компоненты могут использоваться в других системах
Надежность	Насколько хорошо система реагирует на непредвиденные условия эксплуатации
Безопасность	Насколько хорошо система защищает от травм или повреждений
Масштабируемость	Насколько легко система может вырасти, чтобы обрабатывать больше пользователей, транзакций, серверов или других расширений.
Безопасность	Насколько хорошо система защищает от несанкционированного доступа к приложению и его данным
Удобство использования	Насколько легко людям изучать, запоминать и использовать систему
проверяемость	Насколько легко разработчики и тестировщики могут подтвердить, что программное обеспечение было реализовано правильно.

Шаг 2. Сократите список

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

Шаг 3. Расставьте приоритеты для атрибутов

Расстановка приоритетов соответствующих атрибутов устанавливает фокус для будущих дискуссий по сбору информации. Парные сравнения ранжирования могут эффективно работать с небольшим списком таких элементов. На рисунке 1 показано, как использовать Таблица Джима Броссо для оценки показателей качества киоска регистрации в аэропорту.

Рисунок 1. Пример определения приоритетов атрибутов качества для киоска регистрации в аэропорту.

Для каждой ячейки на пересечении двух атрибутов спросите себя: «Если бы у меня был только один из этих атрибутов, какой бы я взял?» Ввод знака «меньше» (<) в ячейку указывает на то, что атрибут в строке более важен; символ каретки (^) указывает на атрибут в верхней части столбца как на более важный.

Например, сравнивая доступность и целостность, я делаю вывод, что целостность важнее. Пассажир может зарегистрироваться у агента на стойке регистрации, если киоск недоступен, но пассажиры будут очень недовольны, если киоск не отображает правильную информацию. Я поставил курсор в ячейку на пересечении доступности и целостности, указывая на то, что целостность является более важной.

В электронной таблице рассчитывается относительная оценка для каждого атрибута, показанного во втором столбце. На этом рисунке наиболее важным является безопасность (7 баллов), за ней следуют целостность (6 баллов) и удобство использования (5 баллов). Хотя другие факторы действительно способствуют успеху — нехорошо, если киоск выйдет из строя на полпути регистрации, поэтому надежность имеет значение — факт в том, что не все атрибуты качества могут иметь высший приоритет.

Расстановка приоритетов помогает сосредоточить усилия по выявлению ключевых атрибутов и помогает узнать, как реагировать, когда вы сталкиваетесь с противоречивыми требованиями. В этом примере выявление может выявить желание достичь конкретных целей производительности, а также некоторых конкретных целей безопасности. Эти два атрибута могут конфликтовать, поскольку добавление уровней безопасности может замедлить транзакции. Поскольку расстановка приоритетов показала, что безопасность важнее (с оценкой 7), чем производительность (с оценкой 4), вам следует смещать разрешение любых таких конфликтов в пользу безопасности.

Шаг 4. Выясните конкретные ожидания по каждому атрибуту

Пользователи не будут знать, как отвечать на такие вопросы, как «Каковы ваши требования к совместимости?» или «Насколько надежным должно быть программное обеспечение?» Бизнес-аналитик должен задавать вопросы, которые изучают ожидания пользователей и приводят к конкретным требованиям к качеству, которые помогают разработчикам создавать восхитительный продукт.

Например, ниже приведены несколько вопросов, которые может задать бакалавр, чтобы понять ожидания пользователей относительно производительности информационной системы, которая управляет патентными заявками, поданными изобретателями:

1. Каким будет разумное время ответа для получения типичной патентной заявки в ответ на запрос?
2. Какое время ответа на типичный запрос пользователи сочтут неприемлемым?
3. Сколько в среднем одновременных пользователей вы ожидаете?
4. Какое максимальное количество одновременных пользователей вы ожидаете?
5. В какое время дня, недели, месяца или года использование устройства происходит более интенсивно, чем обычно?

Рассмотрите возможность спросить пользователей, что будет считаться неприемлемой производительностью, безопасностью или надежностью. То есть укажите системные свойства, которые могут нарушить ожидания пользователя в отношении качества, например разрешение несанкционированному пользователю изменять файл. Определение неприемлемых характеристик позволяет разработать тесты, которые попытаются заставить систему продемонстрировать эти характеристики. Если вы не можете их заставить, вы, вероятно, достигли своих целей в области качества.

Шаг 5. Определите четко структурированные требования к качеству

Упрощенные требования к качеству, такие как «Система должна быть удобной для пользователя» или «Система должна быть полностью доступна круглосуточно и без выходных», бесполезны. Первое слишком субъективно и расплывчато; последнее редко бывает реалистичным или необходимым. Ни то, ни другое не поддается измерению. Таким образом, последним шагом в этом процессе является выработка конкретных и поддающихся проверке требований на основе информации, полученной относительно каждого атрибута качества.

При написании требований к качеству помните о мнемонике SMART: сделайте их конкретными, измеримыми, достижимыми, релевантными и чувствительными ко времени. Если требование к качеству невозможно измерить, вы никогда не сможете определить, достигли ли вы его. Нотация под названием Planguage — отличный инструмент для облегчения точная спецификация требований к атрибутам качества.

Удовлетворение ожиданий пользователя в отношении качества является важным фактором успеха программного проекта. Мудрые бизнес-аналитики будут исследовать атрибуты качества так же старательно, как и выявлять функциональные требования системы.

---

Авторы: Карл Вигерс и Джой Битти

Эта статья адаптирована из Требования к программному обеспечению, 3-е издание Карл Вигерс и Джой Битти. Карл является автором множества других книг, в том числе Основные требования к программному обеспечению (совместно с Кандасе Хокансон), Жемчужины разработки программного обеспечения, Бездумный дизайн повседневных вещей, и Успешный консалтинг по бизнес-анализу. Карл благодарит Джима Броссо за то, что он поделился своими инструментами для определения приоритетов качества.