Как задавать требования к качеству ПО в цифрах?

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

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

1. Если вы работаете на стороне заказчика, нужно обезопасить себя от того, что система формально выполняет все необходимые функции, но работает слишком медленно, слишком неудобна для пользователя, теряются данные или, например, планировалась одновременная работа 1000 пользователей, а система может поддерживать максимум 100.
2. Если вы работаете на стороне подрядчика, требуется аргументировано объяснить заказчику, почему при выборе определённого решения (более безопасного или более отказоустойчивого) стоимость или сроки разработки увеличиваются, какие плюсы заказчик получит в случае выбора этого решения, а также, нужно ли вообще для требуемой системы такое улучшение.
3. Если вы поддерживаете/дорабатываете систему, нужно иметь возможность оценивать её, выявлять зоны развития и слабые места, при необходимости сравнивать с аналогичными продуктами конкурентов.
4. В любом случае, если вы делаете требования к системе, нужно подчеркнуть необходимые моменты в спецификации для разработчика и поставить задачи так, чтобы быть уверенным, что ПО действительно будет отвечать поставленной цели, а не просто формально соответствовать спецификации.
5. И заказчику, и подрядчику нужен список чётких, проверяемых, известных заранее критериев, которым должна соответствовать система, чтобы избежать споров при сдаче.

Вот несколько примеров того, как недостаточное внимание к качеству системы может привести к плачевным последствиям.

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

Примерно через год возникла необходимость переиспользовать разработанные сервисы, немного доработав их уже силами компании-заказчика. Однако выяснилось, что требования к масштабируемости не были зафиксированы, не обсуждались и, соответственно, не тестировались. Чтобы переиспользовать сервисы, пришлось практически полностью переписать систему, что заняло почти столько же времени, сколько первоначальная разработка.

В качестве ответа на этот вопрос в голову приходит несколько стандартных ответов.

1. Вариант первый: напрямую спросить заказчика, какую систему он хочет получить

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

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

Требования, полученные таким образом и не проработанные аналитиком дополнительно, будет невозможно протестировать при сдаче ПО заказчику, либо их будет очень сложно реализовать.

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

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

2. Вариант второй: сформировать требования к качеству своей системы на основе имеющихся стандартов

Однако, предлагаемые в различных стандартах (например в семействе стандартов ISO/IEC) и литературе (например в The Quest for Software Requirements, Roxanne E. Miller) списки критериев качества часто оказываются слишком громоздкими или их тяжело использовать на практике. Приводимая в них классификация систем может быть устаревшей или не актуальной для вашей области, а предлагаемые характеристики качества часто тяжело «переводить» на язык заказчика для обсуждения.

Чтобы требования получились жизнеспособными, требуется потратить много усилий на адаптацию такого стандарта под свою ситуацию. Заглядывать в специальную литературу полезно, но брать решения as is получается не всегда.

3. Вариант третий: привлечь отдельных специалистов (например, эксперта в области информационной безопасности)

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

Формулируя требования к качеству, он по сути пишет требования сам для себя и может быть не объективен. Иногда архитектор может схалтурить, а иногда (в погоне за действительно крутой системой) написать требования, реализация которых слишком сильно увеличит стоимость и сроки разработки.

4. Вариант четвертый: проанализировать показатели качества в аналогичных системах


Такой подход называется benchmarking — сопоставительный анализ на основе эталонных показателей. Опираясь на полученные значения, вы можете сделать свою систему лучше, или хотя бы не хуже систем-конкурентов.

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

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

Эта статья поможет ответить на три ключевых вопроса.

1. Что такое качество программного обеспечения?
2. С помощью каких характеристик предъявлять требования к качеству системы?
3. Как выбрать конкретные значения этих характеристик?

Согласно ГОСТ Р ИСО 9000-2015 (пункт 3.6.2), качество — степень соответствия совокупности присущих характеристик объекта требованиям.

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

Актуальный стандарт в области качества программного обеспечения (ISO/IEC 25010:2011, русскоязычный аналог — ГОСТ Р ИСО/МЭК 25010-2015).

Качество продукта — совокупность характеристик системы, влияющих на ее функционирование. Эти характеристики могут быть объективно измерены техническими средствами и пользователями (например, производительность или надежность).

Стандарты качество ПО предлагают 2 основные категории качества ПО:

1 — Качество, наблюдаемое в ходе эксплуатации программной системы (Run-Time Quality), называемое внешнее качество продукта (external product quality) — характеристики, объективно измеряемые как автоматическими тестами, так и наблюдаемые пользователями.

2 — Качество, наблюдаемое в ходе разработки или модернизации программной системы (Design-Time Quality) — внутреннее качество продукта (internal product quality).

Именно с внутренним качеством ПО чаще всего сталкиваются в своей работе разработчики, именно оно влияет на сложность доработки и поддержки системы, а значит и стоимость. При этом внутреннее качество ПО не обязательно сразу влияет на качество её работы, примером тому может служить «спагетти код» или сильная связанность компонентов системы.

В этой статье мы не будем подробно останавливаться на внутреннем качестве ПО, так как обычно оно находится в зоне ответственности архитектора или разработчика, а не аналитика.

Стандарты по человеко-машинному взаимодействию (human-computer interaction) предлагают ещё одну, третью категорию качества — качество в использовании (quality in use).

Согласно системной инженерии, предметом такого качества является уже не только ПО, но в целом надсистема, состоящая из пользователей и ПО.

Качество использования характеризует воздействие системы или программного продукта на заинтересованную сторону. То есть, качество в использовании характеризует не саму систему технически, а именно взаимодействие человека как пользователя с системой. По факту мы говорим о требованиях, касающихся эргономики.

Данная категория качества никак не может быть измерена без участия человека. Характеристики качества в использовании проверяются только путем проверки результатов взаимодействия пользователей с системой.

Эта категория качества помогает описывать и измерять качество пользовательских интерфейсов. Мы рассмотрим её в отдельной статье.

Для указания внешнего качества ПО используется понятие атрибута качества. Давайте рассмотрим несколько наиболее часто используемых атрибутов качества. Для удобства будем рассматривать по четыре атрибута качества продукта и качества использования.

Каждый из перечисленных в таблице атрибутов можно представить в виде набора показателей. Например, надежность может быть представлена в виде двух показателей: вероятность сбоя и время восстановления после сбоя. Чуть позже мы поговорим об этом подробнее.

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

Можно условно выделить четыре уровня качества, на котором может находиться система:

• 0 — низкий уровень, система не соответствует ожиданиям
• 1 — средний уровень, система соответствует ожиданиям
• 2 — высокий уровень, система превосходит ожидания
• 3 — исключительный, система многократно превосходит ожидания

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

Перед тем, как перейти к описанию атрибутов качества и измерению их уровня, хочется отметить, что и заказчику, и команде разработки важно помнить: помимо качества системы, есть еще некоторые допущения и ограничения, которые важно обсудить (и зафиксировать!) до начала разработки, иначе может оказаться, что требования и сама разработка не имела смысла.

К таким ограничениям относятся:

• скорость и надежность сетевых соединений
• совместимость с версиями оборудования, ОС и браузеров
• ограничения, связанные со смежными системами, с которыми взаимодействует наша система (ограничения на протоколы взаимодействия, показатели доступности и производительности смежных систем и тд)
• другие ограничения в зависимости от контекста

Пример ограничений можно посмотреть здесь.

Какие же конкретные значения должны принимать атрибуты качества, чтобы соответствовать тому или иному уровню?

Производительность (П) — характеристика, которая отвечает за то, какое количество каких операций и как быстро может выполняться в системе, насколько система подходит для одновременной работы нескольких пользователей (или взаимодействия с несколькими системами).

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

Например, если вы проектируете портал, на котором будут доступны результаты экзамена, вы должны учесть не только общее количество пользователей, но и тот факт, что почти все они одновременно зайдут на портал, чтобы посмотреть свои результаты и он должен выдержать такой пик нагрузки.

Дополнительно можно разделить атрибут Производительность на два под атрибута: Пропускная способность и Задержка.

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

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

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

Если нужно увеличить мощность системы в десять раз, придется заплатить в десять, сто или всего в два раза больше? Ответ на этот вопрос показывает, насколько хорошо масштабируется система.

Бизнес-заказчику не всегда интересны точные величины, однако важно иметь возможность оценить выполнение требований к качеству системы. Величины в таблицах приведены примерные, их можно адаптировать под текущий контекст.

Для удобства можно использовать шаблон типовых требований к внешнему качеству системы.

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

Скорость обучения (СО) отражает, сколько требуется времени на обучение, чтобы пользователь мог выйти на приемлемый уровень результативности. Здесь все зависит от типа системы: для больших систем (например, SAP-систем) допустимо увеличение значения этого показателя. Если это мобильное приложение или необходимо быстро увлечь пользователя, скорость обучения необходимо снижать.

Скорость работы (СР) показывает, как быстро обученный пользователь может достичь свой цели при работе с системой при выполнении того или иного сценария.
Типовые сценарии работы с системой легко можно придумать. Например, один из сценариев — покупка авиабилета. Необходимо задаться вопросом: нормально ли для пользователя потратить на покупку билета 10 минут, полчаса, час?

Процент случаев намеренно не принимается равным 100%. Это сделано для того, чтобы предусмотреть ситуацию, при которой один из пользователей по каким-либо причинам выполняет сценарий в несколько раз медленнее, чем остальные. Учет скорости работы такого пользователя может “смазать” результаты измерений и оценка требований по скорости работы может быть необъективной.

Удовлетворенность (УД) — высокоуровневая качественная оценка субъективных ощущений пользователя от взаимодействия с системой. Удовлетворенность может пригодиться как дополнительный атрибут: если вы понимаете, что по количественным показателям система находится на высоком уровне качества, можно собрать отзывы пользователей с точки зрения соответствия их ожиданиям. Удовлетворенность особенно актуальна для систем массового использования.

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

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

В СССР была распространена классификация систем, предложенная в стандарте ГОСТ 28195-89. Данный стандарт уже потерял актуальность, поэтому рассмотрим менее формальную классификацию ПО и систем, соответствующую реалиям нашего времени.

1. Обычные сайты:
1.1. Home Site
1.2. Business Site

2. Мобильные приложения:
2.1. Consumer Mobile App
2.2. Enterprise Mobile App

3. Интернет-сервисы и настольные приложения:
3.1. Consumer Web Service
3.2. Consumer Desktop App

4. Компоненты:
4.1. Custom Component
4.2. Serial Component

5. Заказное ПО:
5.1. Custom Enterprise Desktop/Web App
5.2. Custom Enterprise Server App

6. ПО для компаний:
6.1. Enterprise Desktop App
6.2. Enterprise Server App

7. Интернет-сервисы:
7.1. B2C SaaS
7.2. B2B SaaS

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

Как пользоваться этой таблицей? Необходимо найти класс, к которому относится ваша система (первый столбец) и посмотреть, какому уровню качества должны соответствовать ее атрибуты (столбцы со 2 по 9). Разумеется, в вашей работе могут быть какие-то нюансы, влияющие на требования к качеству, но в таблице приведена некоторые ориентировочные значения, которые можно брать за основу. Все характеристики можно вычислить уникальным образом, основываясь на вашем знании о том, какой проект, какой заказчик, какие есть ограничения по срокам, стоимости и чему-то еще.

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

Как учитывать эти коэффициенты? Прибавлять к ориентировочному уровню качества из большой таблицы выше значение понижающего коэффициента. Например, если ваша система является прототипом, понижать уровень качества на 3 пункта и т.д. Соответственно, для промышленной версии ничего понижать не надо и можно смело ориентироваться на предложенную таблицу.

Как аналитику в повседневной работе использовать материалы этой статьи? Вот примерный план действий.

1. Определить существующие ограничения (например, связанные со смежными системами или оборудованием).
2. Определить класс своей системы или понять, к какому классу она ближе и чем от него отличается (если не получается найти систему в приведенном выше списке классов).
3. Определить уровень качества: для этого посмотреть рекомендованный уровень качества разных атрибутов для систем выбранного класса. При необходимости учесть уровень зрелости системы и снизить уровень качества в соответствии с ним

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

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

Научиться описывать требования к качеству ПО вы можете на нашем курсе «Системный анализ и Разработка требований в ИТ-проектах».

Некоторые отраслевые стандарты, которые использовались при подготовке статьи.

1. ГОСТ 28195-89 Оценка качества программных средств. Общие положения
2. ГОСТ 28806-90 Качество программных средств. Термины и определения
3. ISO/IEC 25010:2011, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models
4. ISO/IEC 25030:2019 Systems and software engineering — Systems and software quality requirements and evaluation (SQuaRE) — Quality requirements framework

Денис Бесков — основатель и руководитель школы системного анализа и проектирования Systems Education. Автор курсов, ИТ-предприниматель и методист.


• Более 20 лет в индустрии на позициях разработчика баз данных, архитектора, системного аналитика, руководителя отдела анализа (35 человек) и менеджера продуктов
• Основной автор федерального профстандарта «Системный аналитик»
• Вёл учебный курс по анализу требований в МФТИ
• Организатор Летнего Аналитического Фестиваля 2013 и онлайн-марафона «Проектные истории» 2016
• Более 20 выступлений на ИТ-конференциях
• Certified Professional for Requirements Engineering (IREB CPRE)