Вам бонус- начислено 1 монета за дневную активность. Сейчас у вас 1 монета

Планирование и управление обеспечением качества и надежности, метрики качества программного обеспечения

Лекция



Привет, Вы узнаете о том , что такое управление качеством программного обеспечения, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое управление качеством программного обеспечения, надежность программного обеспечения, pum, метрики качества программного обеспечения , настоятельно рекомендую прочитать все из категории Надёжность программного обеспечения.

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

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

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

  • Software Quality Assurance — Software Quality Assurance (SQA) — это комплекс мероприятий, направленных на обеспечение качества процессов разработки программного обеспечения, которые в конечном итоге приводят к качественным программным продуктам. Деятельность устанавливает и оценивает процессы, которые производят продукты. Это включает процессно-ориентированные действия.

  • Контроль качества программного обеспеченияКонтроль качества программного обеспечения (SQC) — это комплекс мероприятий по обеспечению качества программных продуктов. Эти действия направлены на выявление дефектов в фактической продукции. Это включает в себя действия, ориентированные на продукт.

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

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

Software Quality Assurance — Software Quality Assurance (SQA) — это комплекс мероприятий, направленных на обеспечение качества процессов разработки программного обеспечения, которые в конечном итоге приводят к качественным программным продуктам. Деятельность устанавливает и оценивает процессы, которые производят продукты. Это включает процессно-ориентированные действия.

Контроль качества программного обеспеченияКонтроль качества программного обеспечения (SQC) — это комплекс мероприятий по обеспечению качества программных продуктов. Эти действия направлены на выявление дефектов в фактической продукции. Это включает в себя действия, ориентированные на продукт.

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

1). специалисты 1-й категории, управляющие обеспечением качества должны знать стандарты, и методики поддерживающие регистрацию, контроль, документирование, и управляющие воздействием на показатели качества на всех этапах создания программного обеспечения. Они должны обеспечивать выявление всех отклонений от заданных показателей качества и анализировать возможные последствия выявленных отклонений.

2). Специалисты 2-й категории непосредственно создают компоненты и ПС заданным показателям качества и надежности, а также формируют исходящие и отчетные документы.
Разделение специалистов обеспечивающих независимый контроль качества результатов разработки и эффективное достижение заданных характеристик надежности и безопасности.
В спецификации должны формализоваться показатели качества, а в плане обеспечения качеством методы и средства их достижения. Чтобы контроль характеристик ПС на промежуточных этапах был целенаправленным, необходимы эталонные данные, к достижению которых должны стремиться разработчики. Такие данные могут быть получены путем декомпозиции исходных требований на ПС, полученных от заказчика. В процессе взаимодействия заказчика и разработчика показатели качества ПР могут корректироваться с учетом объективно изменяющихся характеристик проекта.


Организационной основой управления качеством ПС является план обеспечения заданных показателей качества на всех этапах разработки. Руководством по планированию обеспечения качества ПС является стандарт ANSI/IEEE 983. Этот стандарт предлагает план обеспечения и управления качеством и надежности функционирования ПС. В нем должно быть отражено:

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

2. Методы управления и достижения заданных значений качества.

3. Базовые документы и стандарты, исполнения для обеспечения качеством на всех этапах разработки.

4. Средства автоматизации разработки, обеспечивающие достижение и измерение заданых значений показателей качества.

5. Структура и содержание отчетных доходов, удостоверяющих достижение определения качества и надежности функционирования ПС.
Наличие плана обеспечения качества ПС еще не гарантирует достижение заданных характеристик качества. Об этом говорит сайт https://intellect.icu . Ограничение ресурсов используемых в процессе разработки, изменение внешней среды и требование заказчика могут привести к отклонениям в реализации плана. Эти отклонения должны отражаться в специальном документе и доводится до сведения всех специалистов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Планирование и управление обеспечением качества и надежности, метрики качества программного обеспечения
Куда,
 Планирование и управление обеспечением качества и надежности, метрики качества программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DRE= fracДефектудаленвовремяadevelopmentphaseДефектыскрытыйintheproduct times100%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PercentDelinquentFixes=

fracNumberof исправляет что превышено ответ время критерии поc everity level Number of исправлено доставлено ina указано время times 100%

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

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

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

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

Вау!! 😲 Ты еще не читал? Это зря!

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

создано: 2018-02-02
обновлено: 2021-04-06
132265



Рейтиг 9 of 10. count vote: 2
Вы довольны ?:


Найди готовое или заработай

С нашими удобными сервисами без комиссии*

Как это работает? | Узнать цену?

Найти исполнителя
$0 / весь год.
  • У вас есть задание, но нет времени его делать
  • Вы хотите найти профессионала для выплнения задания
  • Возможно примерение функции гаранта на сделку
  • Приорететная поддержка
  • идеально подходит для студентов, у которых нет времени для решения заданий
Готовое решение
$0 / весь год.
  • Вы можите продать(исполнителем) или купить(заказчиком) готовое решение
  • Вам предоставят готовое решение
  • Будет предоставлено в минимальные сроки т.к. задание уже готовое
  • Вы получите базовую гарантию 8 дней
  • Вы можете заработать на материалах
  • подходит как для студентов так и для преподавателей
Я исполнитель
$0 / весь год.
  • Вы профессионал своего дела
  • У вас есть опыт и желание зарабатывать
  • Вы хотите помочь в решении задач или написании работ
  • Возможно примерение функции гаранта на сделку
  • подходит для опытных студентов так и для преподавателей



Комментарии


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

Надёжность программного обеспечения

Термины: Надёжность программного обеспечения