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

Внезапные сюрпризы

Случается, что в ходе сдачи программной системы в эксплуатацию или уже в ходе эксплуатации всплывают неприятные сюрпризы:

  • Программа тормозит
  • Программа даёт сбои
  • Программа неудобна в работе

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

Если в проекте было формальное ТЗ как приложение к договору, то чаще всего оказывается, что про такого рода поведение или свойства программы в нём ничего не сказано или сказаны какие-то абстрактные, непроверяемые вещи, типа «интерфейс приложения должен быть интуитивно понятным».

В результате Заказчик недоволен, просит или требует Исполнителя доработать программу.

Исполнитель или отказывается и запускает конфликт или пытается доработать за свой счёт или выставляет Заказчику счёт на дополнительные, как он считает, работы.

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

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

Почему так происходит и что делать?

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

Ситуация с формулированием требований к качеству в малых и средних проектах

Если требования к софту формулировались главным образом со стороны Заказчика, то легко может статься, что:

  • Заказчик считает качество бесплатным, автоматическим приложением к фичам и ожидает его как должного — «ну вы же профессионалы?!». (И нельзя сказать, что он совсем не прав.)
  • Если Заказчик попытается обратиться к международным стандартам на документы требований и требования к качеству ПО в частности, на него обрушится сонм терминов без каких-либор доступных объяснений, как с ними работать. Например, в наиболее свежем стандарте ISO 25010 можно увидеть 8 групп и 45 атрибутов качества ПО и систем.
  • Если Заказчик попытается искать готовые шаблоны и примеры требований, то обнаружит те же бездумные копипасты-заклинания на маркетинговом языке вида «Система должна быть доступна 365 дней в году x 24 часа в сутки».

Если к требованиям или ТЗ приложил руку Исполнитель, то требований к качеству в них не оказалось, т.к.:

  • Исполнитель сознательно не стал их включать, чтобы не ставить себе жёстких ограничений и иметь свободу манёвра в духе «Этого не было в ТЗ».
  • Исполнитель понимает, что не может гарантировать выполнение достаточно точных (но излишне идеалистичных) требований вида «Приложение должно иметь время отклика не более 3 секунд», а как сформулировать иначе, он не знает.
  • Проектировщики Исполнителя («архитекторы», проектировщики интерфейсов, проектировщики баз данных) не могут предсказать выполнение тех или иных требований, т.к. не обладают достаточным для этого опытом и компетентностью.

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

Эволюция стандартов в области качества ПО

Е

 

Сколько вешать в граммах?

 

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