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

Введение

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

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

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

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

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

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (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 — мобильное

© Habrahabr.ru