Обобщённое понятие дефекта
Удобно было бы ввести и использовать для анализа качества некий обобщённый критерий качества вместо нескольких разрозненных критериев. Таким критерием является обобщённое понятие дефекта:
Любое отклонение от «идеального» продукта, от стандартов качества, которые определены (или подразумеваются) для проекта, есть дефект.
Таким образом, будем называть дефектом любое отклонение от стандарта качества для любого вышеперечисленного критерия. Например, недостаток функциональности или лишняя функциональность – дефект. Неудобный интерфейс – дефект. Плохой дизайн или грязный код, который негативно скажется на сопровождаемости – дефект. Неприемлемая производительность – дефект. Некорректная работа программы («баг», ошибочное поведение) – частный случай дефекта. Орфографическая ошибка в документации пользователя – тоже дефект.
Дефекты можно классифицировать по следующим параметрам:
Тип дефекта (определяется фазой разработки или активностью, на которой он был внесён);
Критичность дефекта (насколько критично его наличие в ПП);
Приоритет дефекта (насколько важно его исправить);
Сложность дефекта (насколько трудоёмко его исправить);
и др.
Имея подобный обобщённый обратный показатель качества, становится проще оценивать и анализировать качество разрабатываемого ПП, а также качество нашего процесса разработки вообще. Можно считать количество дефектов или сумму их весов (по какому-либо параметру), можно оценивать плотность дефектов на единицу объёма продукта, анализировать, какие фазы процесса являются наиболее проблемными для нас, и т.д. Теперь борьба за качество есть не что иное, как борьба с дефектами.
Управление качеством программного продукта Традиционный подход к качеству программного продукта
Введя обобщенное понятие дефекта, можно нарисовать график, изображающий изменение количества дефектов в проекте с течением времени (рис. 1). Для простоты рассмотрим водопадную модель жизненного цикла проекта. При традиционном подходе к качеству ПП, где основной упор делается на тщательное тестирование, этот график может выглядеть следующим образом.
Рис. 1. Изменение количества дефектов в проекте с течением времени при традиционном подходе к управлению качеством и при водопадном жизненном цикле.
Здесь верхняя красная линия изображает количество внесённых дефектов на текущий момент времени (следует пояснить, что эта линия является воображаемой, т.к. мы не сможем точно подсчитать полное количество дефектов до тех пор, пока не найдём их все). Нижняя зелёная линия изображает количество найденных и исправленных дефектов на текущий момент времени (здесь мы предполагаем, что дефекты исправляются практически сразу же после того, как были найдены). Разница между красной и зелёной линией в каждый момент времени отображает количество имеющихся на данный момент дефектов. Нас больше всего интересует, какой будет эта разница в конце проекта. Чем она меньше, тем качественнее получился наш продукт. С точки зрения качества жизненный цикл на этом рисунке представляется как соревнование между процессами внесения и исправления дефектов [1, стр. 292-293].