Вы здесь:

Продолжительность устранения дефекта

Вопрос: Сколько времени требуется проекту для устранения дефектов после того, как о них было сообщено и зафиксировано?

Обзор

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

Хотите знать больше?

Нажмите, чтобы узнать больше об этом показателе.

Стратегии сбора данных

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

Фильтры

  • Устранение дефекта, связанное с изменением кода, или запросы на изменение
  • Скорость устранения дефекта измеряется, чтобы указать совокупное (среднее, среднее, медиана) время, которое проходит между выявлением дефекта и его закрытием путем слияния запросы на изменение.
  • Любая проблема, помеченная как устранение дефекта, когда код объединяется с версией, доступной для пользователей (метки зависят от репозитория).
  • Ярлыки в GitHub, GitLab, Bugzilla, SourceForge или любой другой системе отслеживания проблем, которые указывают, что «проблема» представляет собой дефект программного обеспечения.
  • Связанные проблемы, связанные с запросы на изменениеили указание на то, что проблема не связана с некоторым процентом запросы на изменение.

Визуализация

Команда Проект «Четыре ключа» можно модифицировать, чтобы сосредоточиться на устранении дефектов и воздействии.

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

Гримуарлаб


Рекомендации

  1. Реагирование на проблему
  2. Время закрыть
  3. https://ieeexplore.ieee.org/document/8285884

Соавторы

  • Дуэйн О'Брайан
  • Дэвид Уилер
  • Кейт Стюарт
  • Рениша Неллумс
  • Винод Ахуджа
  • Шон Гоггинс
  • София Варгас
  • Своеобразный C Умех

Дополнительная информация

Чтобы изменить эту метрику, пожалуйста Подайте запрос на изменение здесь

Чтобы ссылаться на этот показатель в программном обеспечении или публикациях, используйте этот стабильный URL-адрес: https://chaoss.community/?p=4727

Использование и распространение показателей работоспособности может привести к нарушению конфиденциальности. Организации могут быть подвержены рискам. Эти риски могут проистекать из соблюдения GDPR в ЕС, законодательства штата в США или других законов. Также могут быть контрактные риски, вытекающие из условий обслуживания для поставщиков данных, таких как GitHub и GitLab. Использование метрик должно быть проверено на предмет рисков и потенциальных проблем с этикой данных. Посмотри пожалуйста Документ по этике данных CHAOSS для дополнительных указаний.

Теги:
Была ли эта статья полезна?
нелюбовь 0