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

• Введение в требования к качеству:

• Кому и когда нужны требования к программной системе?

• Самые полезные атрибуты качества

• Пример требований к внешнему качеству программной системы

• Как определять конкретные значения требований?

  4 важнейших атрибута внешнего качества:

• Производительность, её показатели и примеры требований

• Масштабируемость, её показатели и примеры требований

• Доступность, её показатели и примеры требований

• Надёжность, её показатели и примеры требований

  Профили качества:

• Уровни качества и типовые значения показателей

• Классы программных систем

• Типовые уровни качества для разных классов программных систем

  Применение:

• Допущения и ограничения

• Инструкция по применению

Введение

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

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

Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.

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

При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».

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

Давайте попробуем сделать это хотя бы ремеслом.

---

Кому и когда нужны требования к качеству программной системы?

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

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

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

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

3. Если вы поддерживаете/дорабатываете систему, нужно иметь возможность оценивать её, выявлять зоны развития и слабые места, при необходимости сравнивать с аналогичными продуктами конкурентов.

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

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

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

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

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

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

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

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

Самые полезные атрибуты качества

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

1. Важнейшие характеристики качества при эксплуатации (Run-Time), также называемого внешним качеством (external quality):

• Производительность

• Масштабируемость

• Доступность

• Надёжность

• Информационная безопасность

2. Важнейшие характеристики качества при модернизации (Design-Time), также называемого внутренним качеством (internal quality):

• Безошибочность кода

• Изменяемость кода

• Переносимость кода

3. Специалисты по пользовательским интерфейсам, человеко-машинному взаимодействию также предлагают характеристики качества, называемые «качество в использовании» (Quality in Use).

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

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

• Результативность применения

• Обучаемость

• Эффективность применения

• Точность применения

• Утомляемость при применении

• Удовлетворённость применения

В этой статье дальше мы рассмотрим только формулирование требований к первым 4-м аспектам внешнего качества.

Требования к информационной безопасности заслуживают отдельной статьи.

Про качество в использовании также читайте в отдельной статье.

Пример требований к внешнему качеству программной системы

4.4. Требования к внешнему качеству ПО (External Quality)

Раздел использует терминологию стандарта ГОСТ Р ИСО/МЭК 25010-2015. «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов»

4.4.1. Требования к Производительности

1. Система должна поддерживать одновременную работу не менее 30 пользователей;

2. Система должна исполнять 80% типовых запросов за время не более 1 секунды;

3. Система должна исполнять 95% типовых запросов за время не более 3 секунд.

4.4.2. Требования к Масштабируемости

1. Система должна позволять увеличение производительности за счёт увеличения вычислительной мощности и ресурсов со стороны оборудования.

2. Стоимость десятикратного увеличения производительности системы не должна превышать 900% от стоимости эксплуатации на момент сдачи.

4.4.3. Требования к Надежности

1. Система должна допускать сбои без ущерба безопасности данных не более чем в 5% обращений;

2. Система должна восстанавливаться после сбоя не более чем за 5 минут.

4.4.4. Требования к Доступности

1. Система должна демонстрировать уровень доступности, при котором коэффициент доступности составляет:

   — в рабочее время, с 8 до 18 часов по московскому времени — не менее 96%;
   — в нерабочее время, с 18 до 8 часов по московскому времени — требований не предъявляется;

2. Система должна демонстрировать уровень доступности, при котором допустимое время простоя:
   — в час — не более 5 мин;
   — в день — не более 1 час;
   — в месяц — не более 10 часов.

Как определять конкретные значения требований?

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

Давай рассмотрим несколько вариантов действий по выявлению и формулированию требований к качеству:

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

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

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

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

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

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

2. Второй вариант, идеальный: расчёты

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

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

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

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

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

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

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

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

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

Такой подход называется benchmarking — измерение аналогичных показателей систем-конкурентов, имеющих схожую сферу применения и параметры среды.

Тогда требование можно формулировать как:

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

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

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

6. Вариант шестой: использовать типовые профили качества

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

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

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

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

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

---

Производительность

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

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

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

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

Пропускная способность

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

• Количестве обрабатываемых запросов в единицу времени или

• Количестве одновременно работающих пользователей

Пример требования к пропускной способности:

П-1. Система должна обслуживать одновременно не менее 1 тысячи пользователей.

Это требование можно брать в работу, если сопроводить его допущением, что каждый пользователь производит в среднем не более 1 запроса в 20 секунд (3 запроса в минуту).

Задержка

Задержка обычно измеряется средним временем исполнения запроса.

Пример прагматичного требования к задержке:

П-2. Система должна исполнять 95% запросов типа X в течение 3 секунд.

Объём данных

Кроме того, очень часто бывает важным оговорить не только и не столько количество запросов, но и объём данных, которые хранит или обрабатывает система.

П-3. Система должна сохранять показатели качества при работе с объёмами данных до 1000 видеофайлов записей вебинаров.

---

Масштабируемость

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

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

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

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

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

Принципиальная масштабируемость

Базовым требованием к масштабируемости является принципиальная масштабируемость:

М-1. Система должна позволять увеличение нагрузки (количества одновременно работающих пользователей, количества запросов в секунду, объёма хранимых и перерабатываемых данных) за рамками требований к Производительности с возможным ухудшением показателей (в частности, времени отклика и времени исполнения запросов).

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

Характер масштабируемости

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

Характер падения производительности

М-2. Система должна демонстрировать уровень масштабируемости, при котором зависимость времени отклика системы от нагрузки носит характер не хуже, чем (нужно выбрать только 1):
1) логарифмический;
2) степенной, где показатель степени < 1;
3) линейный;
4) степенной, где показатель степени > 1.

Давайте рассмотрим эти 4 варианта зависимости подробнее:

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

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

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

Степенной характер (где 0 < n < 1 — «график корня») зависимости остаётся идеальным для большинства систем. Он хуже, чем логарифмический, но при этом всё равно очень выгодный для бизнеса, т.к. на обслуживание каждой следующей единицы нагрузки (пользователей, запросов, объёмов данных) бизнес тратит всё меньше и меньше ресурсов. Хорошие архитекторы умеют создавать архитектуру с таким качеством.

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

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

Степенной характер (где n > 1 — «график параболы») зависимости — это самый худший вид масштабируемости (не считая принципиальной немасштабируемости — отказа системы при увеличении нагрузки за рамками плановой).

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

Стоимость масштабирования

Такой вариант описания масштабируемости более понятен представителям бизнеса, т.к. оперирует не математикой, а инвестициями.

Пример такого требования:

М-3. Система должна демонстрировать уровень масштабируемости, при котором стоимость увеличения производительности* системы в 2 (5 / 10 / 50 / 100) раз составляет не более, чем 100% от плановой годовой стоимости эксплуатации системы на момент её сдачи в эксплуатацию.

* — под производительностью здесь понимается количество обрабатываемых запросов в единицу времени

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

---

Доступность

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

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

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

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

Допустимое время простоя

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

Как посчитать допустимое время простоя? Проще всего это делать через расчёт допустимого ущерба. Например, заказчик разработки — интернет-магазин, который продаёт товаров на 1 миллион рублей в месяц.

Если считать грубо, не принимая во внимание распределение заказов во времени, один час простоя магазина может обернуться потерями в 1 млн / (30 дней * 24 часов) = 1 400 рублей в день или 33 тысячи рублей в месяц.

Допустимы ли такие потери? Тут решать заказчику, но чтобы у него было больше фактуры для принятия решения, команда разработки, если она уже известна, может посчитать свои расходы и ежемесячные затраты на снижение времени простоев, например, в 5 раз — с 1 часа в день до 12 минут.

В таком случае заказчик сможет аргументированно принять взвешенное решение — например, стоит ли сокращение риска потери 33 тыс рублей в месяц разовых дополнительных инвестиций в размере 300 тысяч рублей на оптимизацию схемы развёртывания и 10 тыс рублей в месяц на аренду специализированного ПО.

Д-1. Система должна демонстрировать уровень доступности, при котором время простоя в работе системы не превышает 1 часа в сутки.

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

Д-2. Система должна демонстрировать уровень доступности, при котором время простоя в работе системы не превышает 5 минут в час.

Обратите внимание, что требование, которое охватывает более длительный интервал наблюдения — сутки, не является простой суммой допустимого времени простоя за час — 24 * 5 = 120 минут, а более жёстко по характеру, это обычная практика, следующая принципу, что допустимые отклонения от нормы не должны становиться нормой и накапливаться при суммировании.

Таким образом можно дополнить и более длительным по интервалу наблюдения требованием:

Д-3. Система должна демонстрировать уровень доступности, при котором время простоя в работе системы не превышает 3 часов в неделю.

Все 3 требования совместимы и органично дополняют друг друга, задавая прагматичные нормы доступности.

Коэффициент доступности

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

Например, посчитаем для одного часа — 5 минут простоя в час = 55 / 60 = ~92% времени доступности.

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

Д-4. Система должна демонстрировать уровень доступности с коэффициентом доступности не хуже, чем 92% в час.

Для тренировки можете попробовать самостоятельно рассчитать коэффициент доступности для требований Д-1 и Д-3 выше.

---

Надёжность

Надёжность (Н) — это способность системы работать с определённой долей сбоев, и обычно характеризуется 2-мя показателями: 1) вероятность сбоя, и 2) временем восстановления после сбоя.

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

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

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

Вероятность сбоя

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

Н-1. Система должна демонстрировать уровень надёжности, при котором вероятность сбоя при обращении к её функциям не превышает 5%.

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

Н-2. Система должна демонстрировать уровень надёжности, при котором вероятность сбоя при обращении к учётным* функциям не превышает 5%.

Дополнение: Под учётным функциями понимаются функции создания, обновления, удаления объектов учёта системы.

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

Н-3. Система должна демонстрировать уровень надёжности, при котором вероятность сбоя при обращении к функции оплаты (Ф-47) не превышает 0,5%.

Время восстановления после сбоя

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

Этот показатель удобнее всего задавать через benchmarking — измерение аналогичного времени в продуктах-конкурентах и изучение опыта пользователя.

Например, в интернете многие пользователи привыкли, что в случае сбоя в показе страницы пользователь может её обновить принудительно и уже на этот раз страница покажется правильно, иначе это будет уже выглядеть не только как сбой, но и в целом недоступность системы (хоть и для одного пользователя, а не всех). Таким образом ожидаемое время восстановления после сбоя в отображении веб-страницы — 0,5-1 секунды.

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

Пример формулировки требования ко времени восстановления после сбоя:

Н-4. Система должна демонстрировать уровень надёжности, при котором время восстановления после сбоя в работе отдельной функции не превышает 3 секунд в 90% случаев.

---

Профили качества

Уровни качества

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

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

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

• 0 — низкий уровень, посредственное качество

• 1 — средний уровень, обычное, приемлемое качество

• 2 — высокий уровень, повышенное качество

• 3 — исключительный уровень, необычное, редкое качество

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

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

Типовые значения требований для Производительности

Типовые значения требований для Масштабируемости

Типовые значения требований для Доступности

Типовые значения требований для Надёжности

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

Классы программных систем

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

В старых советских стандартах на качество ПО была предложена классификация из 12 категорий систем — см. ГОСТ 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 Enterprise Desktop/Web App — заказное клиентское приложение для бизнеса (требует установки)
4.2. Custom Enterprise Server App — заказное серверное приложение для бизнеса (требует установки)

5. Тиражируемое ПО для компаний:
5.1. Enterprise Desktop App — тиражируемая настольная программа для бизнеса (требует установки)
5.2. Enterprise Server App — тиражируемая серверная программа для бизнеса (требует установки)

6. Отдельные программные компоненты:
6.1. Custom Component — заказной, уникальный компонент
6.2. Serial Component — тиражируемый, распространяемый компонент

7. Массовые облачные интернет-сервисы по подписке:
7.1. B2C SaaS — облачный интернет-сервис для частных лиц, распространяемый по модели подписки (похож на 3.1, но тут пользователь получает собственное пространство для работы, а не просто личный кабинет)
7.2. B2B SaaS — облачный интернет-сервис для компаний, распространяемый по модели подписки (не требует установки)

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

Типовые уровни внешнего качествадля програмнных систем разного класса

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

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

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

Стадии зрелости ПО

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

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

Например, если ваша система является прототипом, понижать уровень качества на 3 пункта и т.д.

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

Учёт допущений

Можно ли подрядчику, исполнителю, команде подписывать требования к внешнему качеству ПО в таком виде (как показано выше)?

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

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

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

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

• скорость и надежность сетевых соединений;

• совместимость с версиями оборудования, ОС и браузеров;

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

• другие ограничения в зависимости от контекста.

Как могут выглядеть типовые допущения об оборудовании, на которые может опираться команда разработки:

Пример допущений и ограничений

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

Пользовательское оборудование:

ПО-1. Персональный компьютер архитектуры IBM PC с доступом в корпоративную сеть Заказчика со следующими характеристиками:

1. Объём оперативной памяти не менее 2 Гб;

2. Объём долговременной памяти не менее 256 Гб;

3. Мощность центрального процессора не менее 40 Гфлопс;

4. Электронный дисплей с разрешением не менее 1024 пикселов по горизонтали;

5. Компьютерная клавиатура;

6. Компьютерная мышь;

7. Сетевая карта со скоростью передачи данных не менее 10 Мбит/с.

БП-1. В помещении Заказчика обеспечено бесперебойное питание персональных компьютеров пользователей системы со временем отключения питания не более 2 минут в день в рабочее время с 9 до 19 часов московского времени.

Серверное оборудование:

СО-1. Серверное вычислительное оборудование архитектуры IBM PC с доступом в интернет со следующими характеристиками:

1. Объём оперативной памяти не менее 128 Гб;

2. Объём долговременной памяти не менее 4 Тб (RAID);

3. Мощность центрального процессора не менее 200 Гфлопс;

4. Сетевая карта со скоростью передачи данных не менее 1 Гбит/с.

БП-2. В помещении Заказчика обеспечено бесперебойное питание серверного вычислительного оборудования системы со временем отключения питания не более 2 минут в неделю в интервале с 6 до 0 часов московского времени.

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

СС-1. Скорость передачи данных в корпоративной сети заказчика не менее 100 Мбит/с;
ДС-1. Доступность сетевого соединения и смежных систем составляет не менее 99,5%.

Инструкция по применению

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

1. Определить существующие ограничения (например, связанные со смежными системами или оборудованием);

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

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

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

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

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

Я не рекомендую вам сразу в ближайшем проекте применять все 4 рассмотренных показателя качества СРАЗУ, начните с 1-2 наиболее важных для вашего проекта, вашей программной системы.

Помогите команде проекта научиться их систематически измерять и обеспечивать, причём здесь будет очень велика роль ваших коллег — специалистов по тестированию и, возможно, DevOps-инженеров.

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

Стандарты в области качества

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

Устаревшие советские стандарты:

1. ГОСТ 28195-89 Оценка качества программных средств. Общие положения

2. ГОСТ 28806-90 Качество программных средств. Термины и определения

Современные международные стандарты:

1. ГОСТ Р ИСО/МЭК 25010-2015. «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов»

2. ГОСТ Р ИСО/МЭК 25021-2014. «Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Элементы показателя качества»

3. ГОСТ 27.002-2015. МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ. НАДЕЖНОСТЬ В ТЕХНИКЕ. Термины и определения

---

Вопросы и ответы

Вопрос:

Какие негативные стороны есть в предложенном подходе определения требований к качеству системы?

Ответ:

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

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

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

Вопрос:

Существуют ли какие-то препятствия для достижения высокого внешнего качества, если внутреннее качество находится на низком уровне?

Ответ:

Внутреннее качество напрямую влияет на внешнее качество.

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

Можно проследить следующую зависимость: внутреннее качество влияет на внешнее качество продукта, а внешнее качество продукта влияет на внешнее качество использования.

Вопрос:

Как варьировать значения показателей для уровней качества 0 и 3 в меньшую и большую сторону соответственно?

Ответ:

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

Вопрос:

Встречалась ли в вашей практике ситуация, при которой рассчитывалась бы надёжность, в частности, вероятность сбоя? Если да, то каким образом производился расчёт?

Ответ:

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

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

Вопрос:

Как задавать надёжность на этапе технического проектирования?

Ответ:

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

Об авторе

• Более 20 лет в индустрии на позициях разработчика баз данных, архитектора, системного аналитика, руководителя отдела анализа (35 человек) и менеджера продуктов

• Основной автор федерального профстандарта «Системный аналитик»

• Вёл учебный курс по анализу требований в МФТИ

• Организатор Летнего Аналитического Фестиваля 2013 и онлайн-марафона «Проектные истории» 2016

• Более 20 выступлений на ИТ-конференциях

• Certified Professional for Requirements Engineering (IREB CPRE)