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

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

  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 минут, полчаса, час?
*Под учетными сценариями подразумеваются сценарии, при которых пользователю необходимо работать не более чем с 2 экранами и осуществить ввод данных не более чем в 20 полей.
**Под сложными сценариями подразумеваются сценарии, при которых пользователю необходимо работать не более чем с 7 экранами и осуществить ввод данных не более чем в 100 полей.
Процент случаев намеренно не принимается равным 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. Определить уровень качества: для этого посмотреть рекомендованный уровень качества разных атрибутов для систем выбранного класса. При необходимости учесть уровень зрелости системы и снизить уровень качества в соответствии с ним
В зависимости от ситуации либо включить рекомендуемые значения уровня качества в требования/обсудить с заказчиком (для проектируемой системы), либо оценить их реальный уровень и предпринять необходимые действия (если система уже в разработке или эксплуатации).
Также можно адаптировать конкретные значения под свою ситуацию и вести их в аналогичной таблице, что поможет систематизировать требования.
Выявление отдельных атрибутов и конкретные числовые значения для характеристик помогут вести более конструктивный диалог с архитекторами, заказчиками и другими участниками проекта. А понимание того, что и как влияет на качество системы делает вашу работу как аналитика более ценной.
Научиться описывать требования к качеству ПО вы можете на нашем курсе «Системный анализ и Разработка требований в ИТ-проектах».
Стандарты в области качества
Вопросы и ответы
Вопрос:
Какие негативные стороны есть в предложенном подходе определения требований к качеству системы?
Ответ:
Предложенный в статье подход направлен на то, чтобы максимально защитить заказчика. В большинстве заказных проектов подрядчику невыгодно прописывать требования к внешнему качеству системы. Это связано с тем, что при ограничении системы не только по функциональности, но и по качеству, подрядчику становится сложнее обеспечивать треугольник “сроки-качество-функциональность”. Подрядчик понимает, что обеспечить все предъявляемые требования к качеству может быть проблематично.

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

Можно проследить следующую зависимость: внутреннее качество влияет на внешнее качество продукта, а внешнее качество продукта влияет на внешнее качество использования.
Вопрос:
Как варьировать значения показателей для уровней качества 0 и 3 в меньшую и большую сторону соответственно?
Ответ:
Для своей системы вы можете устанавливать значения показателей выше или ниже, в предложенной таблице указаны именно рекомендуемые значения. Но при занижении или завышении значений показателей необходимо быть аккуратными и четко понимать, зачем вы это делаете.
Вопрос:
Встречалась ли в вашей практике ситуация, при которой рассчитывалась бы надежность, в частности, вероятность сбоя? Если да, то каким образом производился расчет?
Ответ:
Если говорить именно о вероятности сбоя, можно осуществить расчет с помощью циклических тестовых прогонов при изменении конфигурации внешней среды.
Вопрос:
Как задавать надежность на этапе технического проектирования?
Ответ:
Задавать надежность необходимо еще на стадии формулирования требований. На этапе технического проектирования происходит выбор решения (архитектура, технологии, оборудование), которое способно обеспечить требуемую надежность. Для того, чтобы убедиться, что выбранное решение может обеспечить требуемую надежность, необходимо разработать прототип системы.
Об авторе
Денис Бесков — основатель и руководитель школы системного анализа и проектирования Systems Education. Автор курсов, ИТ-предприниматель и методист.

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