Способ подсчета коэффициента, отражающего качество выпущенного программного продукта

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

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

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

Традиционно ошибки в системах учета ( bug track system ) делятся на категории:
Critical
Ошибка которая не позволяет использовать некоторую функциональность системы и не может быть нивелирована с помощью изменения настроек или других действий пользователя
Major
Ошибка которая затрудняет использование системы но которая может быть нивелирована путем изменения настроек или использования альтернативного сценария работы
Minor
Ошибка которая затрудняет использование системы но фактически не влияет на способ работы
Trivial
Ошибка которая фактически не влияет на использование функции системы но отражается на общем качестве. Например орфографические ошибки или ошибки оформления.

На первый взгляд кажется возможным для подсчета QS просто подсчитать количество всех найденных ошибок. Но используя такой метод мы рискуем получить устрашающие цифры для в целом достаточно хорошего продукта. Это может произойти в силу того что большинство ошибок ( даже имещих статус Critical и Major ) не будут мешать повседневному использованию продукта большинством пользователей.

Как пример можно посмотреть на публичный bug tracker Skype ( jira.skype.com ). На момент написания там была следующая картина:
Critical — 242
Major — 151
То есть в целом при устрашающих цифрах мы имеем вполне работоспособный продукт который без особых проблем используют миллионы людей.
С другой стороны возможна ситуация когда наличие даже одной ошибки со статусом Critical ( например сбой в процессе инсталляции ) сделает использование системы полностью не возможным.

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

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

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

Каждому типу варианта использования и каждой категории ошибки присваивается определенный коэффициент.
Базовый сценарий
Стандартный 12
Не стандартный 4
Второстепенный сценарий
Стандартный 11
Не стандартный 3
Редкий сценарий
Стандартный 10
Не стандартный 2
Сценарий не нормального
использования
1

Critical 20
Major 10
Minor 5
Trivial 2

Коэффициент для конкретного дефекта подсчитывается как коэффициент категории сценария в котором произошла ошибка на коэффициент серьезности ошибки.

Результирующий коэффициент считается как сумма коэффициентов для всех ошибок.

Как результат мы имеем QS определяющий качество системы. Меньшие значения — большее качество. Идеально качество — 0.

Пример:
— Система с 2 Crtitical дефектами в стандартных базовых сценариях использования и 2
Major дефектами в ненормальніх вариантах использования будет иметь
QS = 500 ( 2 * 20 * 12 + 2* 10 * 1 )
— Система с 1 Major дефктом в нестандартном второстепенном варианте использования и 2 Trivial дефектами в стандартных редких вариантах использования будет иметь QS = 70 ( 1 * 10 * 3 + 2 * 2 * 10 )
Поделиться публикацией

Похожие публикации

Комментарии 16

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

    Упомянутые сценарии есть use cases, которые в какой-то мере относятся к требованиям.

    Severity, присваиваемые багам, должны в первую очередь отражать важность их устранения. Наличие critical и major в успешно используемом продукте показывает что критерии для установки severity не соответствуют действительности.
      +2
      Вообще все это похоже не на то что называется «оценка качества ПО», самостоятельная дисциплина смежная с метрологией и стандартизацией, а на оценку только лишь одной составляющей — ошибок (дефектов). Оценка качества преподносится обычно значительно шире и включает всё от реализации до документации и поддержки.
        0
        извиняюсь, хотел отдельный коммент.
      0
      Как то размыто ваша формула указана
        +1
        Идея веса для сценариев использования очень интересная.
        Но часто натыкается на пользовательское недовольство, ибо клиент который приобрел продукт для использования по редкому не стандартному сценарию будет почти в любом случае недоволен, и объяснить что он некорректно использует продукт часто бывает довольно сложной задачей. Ошибка есть — продукт не качественный. Соотвественно имидж продукта падает.

        Мы кстати оцениваем качество продукта только на основании учета ошибок поступивших от клиентов, а внутренние ошибки обнаруженные внутри компании не учитываются, если конечно до их устранения их не обнаружат клиенты.
          +1
          А что именно вы подразумеваете под «некорректным» использованием продукта? Возможности продукта, мне кажется, должны быть строго регламентированы, в том числе интерфейсом. Если интерфейс позволяет осуществлять коммуникацию с продуктом, которая приводит к нежелательным последствиям, наверное, какие-то проблемы в самом программном продукте.
          Или я вас не понял?
            0
            Да, разумеется это так. Но в реальности все возможные сенарии работы с продуктом не предусмотреть. Вот для этого случая в классификацию и добавлена категория «Сценарий не нормального использования».
            В результате когда при каком-то не предусмотренном варианте клиент получает ошибку, то эта ошибка будет классифицирована как менее серьезная чем та же ошибка в одном из основных сценариев.
            Разумеется тут мы исходим из того что сценарии использования согласованны с заказчиком и наличие не предусмотренного, но возможно сценария является не только нашим собственным просчетом.
              0
              Да ситуация именно такая. Так же в крупных проектах бывает функционал который современем просто забывается, но прежде чем его успею вырезать найдется клиент который.

              P.S. для любопытствующих да я понимаю что «функционал который забывается» — это не правильно.
            0
            клиент который приобрел продукт для использования по редкому не стандартному сценарию


            Насколько я понимаю, продукт разрабатывается под клиента (исключение составляют серийные продукты). В этом случае сценарий, который нужен клиенту, является базовым, и никак не может быть отнесен к редким и нестандартным.
              0
              Да, конечно любой баг в продукте сказывается на имидже продукта и разработчика.
              Но в реальности продуктов без ошибок не бывает. Как пример, тот же баг трекер скайпа с 200 Critical errors ( jira.skype.com )
              Данная система была создана для того чтобы и заказчик продукта и комманда разработчиков смогла более детально увидеть общую картину.
              Возвращаясь к примеру со скайпом. Зайдя на трекер и увидя что там достаточное большое количество ошибок с очень серьезными статусами может создасться впечатление что продукт совершенно не работоспособный, что конечно не соотвествует общей картине.
              0
              Традиционно ошибки в системах учета ( bug track system ) делятся на категории
              Обычно делятся на priority и severity. Но часто их путают и тупо severity не используют.
                0
                Тем временем, в далёком 1986 году Моторола придумала шесть сигма.
                  0
                  Извиняюсь, ссылка не вставилась: ru.wikipedia.org/wiki/Шесть_сигма
                    0
                    Возможно что я ошибаюсь, но ведь эта методология применима в первую очередь к серийному производственному процессу. Я с трудом себе представляю как ее можно применить в случае когда продукт существет в единственном экземпляре.
                      0
                      Программный продукт — это не одна единая и неделимая сущность. Это — куча строк кода, и производятся они серийно на протяжении длительного времени. Поэтому считается количество ошибок на миллион строк кода (хотя в точном количестве могу и ошибаться).
                      ЗЫ
                      Я не фантазирую, это действительно так и используется.
                        0
                        Ну и если интересно узнать более подробно можно попробовать погуглить Digital Six Sigma. Это развитие шесть сигма, которое сейчас применяют в мотороле (как минимум в софтверных подразделениях)

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

                Самое читаемое