Метрики качества программного обеспечения

Метрики программного обеспечения можно разделить на три категории —

• Метрики продукта — описывает характеристики продукта, такие как размер, сложность, особенности дизайна, производительность и уровень качества.

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

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

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

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

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

Некоторые показатели относятся к нескольким категориям. Например, показатели качества процесса в проекте являются как показателями процесса, так и показателями проекта.

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

Метрики качества программного обеспечения можно разделить на три категории:

• Метрики качества продукции
• Показатели качества в процессе
• Метрики качества обслуживания

Метрики качества продукции

Эти показатели включают в себя следующее —

• Среднее время до отказа
• Плотность дефектов
• Проблемы с клиентами
• Удовлетворенность клиентов

Среднее время до отказа

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

Плотность дефектов

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

Проблемы с клиентами

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

Метрика проблем обычно выражается в виде проблем за месяц пользователя (PUM) .

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Куда,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

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

Удовлетворенность клиентов

Удовлетворенность клиентов часто измеряется данными опросов клиентов по пятибалльной шкале —

• Очень доволен
• Довольный
• нейтральный
• неудовлетворенный
• Очень Недовольный

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

• Процент полностью удовлетворенных клиентов
• Процент довольных клиентов
• Процент недовольных клиентов
• Процент неудовлетворенных клиентов

Обычно этот процент удовлетворения используется.

Показатели качества в процессе

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

• Плотность дефектов при машинном тестировании
• Схема прибытия дефекта во время машинного тестирования
• Схема устранения дефектов на основе фазы
• Эффективность устранения дефектов

Плотность дефектов при машинном тестировании

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

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

Схема прибытия дефекта во время машинного тестирования

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

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

• Образец действительных дефектов прибывает, когда определение проблемы сделано на сообщенных проблемах. Это истинный образец дефекта.

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

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

Образец действительных дефектов прибывает, когда определение проблемы сделано на сообщенных проблемах. Это истинный образец дефекта.

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

Схема устранения дефектов на основе фазы

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

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

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

Эффективность устранения дефектов

Это можно определить следующим образом:

DRE= fracДефектудаленвовремяadevelopmentphaseДефектыскрытыйintheproduct times100% $$DRE = \ frac {Дефект \: удален \: во время \: a \: development \: phase} {Дефекты \: скрытый \: in \: the \: product} \ times 100 \%$$

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

Метрики качества обслуживания

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

• Исправить отставание и индекс управления отставанием
• Исправьте время отклика и исправьте реакцию
• Проценты по просроченным платежам
• Исправить качество

Исправить отставание и индекс управления отставанием

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

Индекс управления отставанием (BMI) используется для управления отставанием от открытых и нерешенных проблем.

BMI= fracЧислоofпроблемызакрытовтечениемесяцЧислоизпроблемприбыловтечениемесяц раз100% $$BMI = \ frac {Число \: of \: проблемы \: закрыто \: в течение \: \: месяц} {Число \: из \: проблем \: прибыло \: в течение \: \: месяц} \ раз 100 \%$$

Если ИМТ больше 100, это означает, что отставание уменьшается. Если ИМТ меньше 100, то отставание увеличивается.

Исправьте время отклика и исправьте реакцию

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

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

Проценты по просроченным платежам

Он рассчитывается следующим образом —

PercentDelinquentFixes=$Percent \: Delinquent \: Fixes =$

 fracNumberofисправляетчтопревышеноответвремякритериипоceveritylevelNumberofисправленодоставленоinaуказановремя times100%$\ frac {Number \: of \: исправляет \: что \: превышено \: \: ответ \: время \: критерии \: по \: ceverity \: level} {Number \: of \: исправлено \: доставлено \: in \: a \: указано \: время} \ times 100 \%$

Исправить качество

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

Дефектное исправление может быть записано двумя способами: запишите его в том месяце, в котором оно было обнаружено, или запишите его в том месяце, когда оно было доставлено. Первый — это мера клиента; вторая — это процессная мера. Разница между двумя датами заключается в скрытом периоде дефектного исправления.

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