Я хотел получить представление о том, как классифицировать ошибки, основываясь на том, насколько легко их устранить и какую пользу это даст мне. например, если есть ошибка, которая займет, скажем, час (двойное закрытие файла и т. д.), чтобы решить другую, которая занимает день (ошибка сегментации). Но если решение первой ошибки не очень важно, то я, вероятно, поработаю над второй.
Существуют ли какие-либо исследовательские работы, которые классифицируют ошибки на основе соотношения затрат и выгод или аналогичного показателя?
Допустим, можно классифицировать ошибки на основе характеристик ошибок, таких как уязвимость безопасности, ошибка памяти, логическая ошибка и т. Д. В другом измерении могут быть такие параметры, как сложность (простая, средняя, сложная). Есть ли другие измерения, которые я должен искать. Чтобы упростить вещи, я могу предположить две вещи:
- Каждый программист в команде одинаково способен решить любую ошибку
- Там нет крайнего срока
источник
Ответы:
Типичная система отслеживания ошибок имеет два, может быть, три поля, определяющих соотношение затрат и выгод:
Как вы заметили, это определяет, какая ошибка является важной для работы.
Система, представленная в PEF / REV: многомерная метрика отслеживания ошибок, добавляет больше информации о бизнес-компонентах и компонентах для разработчиков, чтобы снизить затраты.
Все значения в масштабе 1 .. N (одинаковое верхнее значение для каждого).
PEF определяется бизнесом:
REV исходит от разработчика:
Если, например, у вас редко происходит сбой, который легко обойти (включите автосохранение), это может быть PEF 7,1,1 (оценка 9). Исправление может включать изменение основного модуля и иметь REV 9,3,2 (оценка 14).
С другой стороны, у вас может быть раздражение, которое всегда есть (3,3,9 - оценка 15), которое имеет тривиальное исправление (1,1,3 - оценка 5).
В этом примере раздражение выглядит более выгодно для работы.
источник
Проблема, которую вы описываете, является очень распространенной, и лучшим ответом может быть «использовать свое внутреннее чувство».
Я обычно делю ошибки на три категории: сбои, раздражающие, косметические (их можно назвать 1, 2, 3 - это не имеет значения), а затем записываю общую оценку времени, необходимого для исправления каждой ошибки (все ошибки должны иметь грубую обновленную оценку в любое время).
При решении ошибок Crashing> Annoying> Cosmetic, а затем я просто выполняю «сначала самую короткую работу», чтобы получить как можно большую начальную пропускную способность.
Мне ОЧЕНЬ сложно рассчитать какую-либо прямую финансовую выгоду от решения любой ошибки - если только это не очень ограниченная оплачиваемая работа.
Одно замечание, которое вам может понадобиться, - это то, что вы действительно должны соответствовать пятому пункту в тесте Джоэла - это может зависеть от размера команды и распределения среди различных других «локальных» проблем - но в целом это признак хорошей практики.
источник
Другим соображением может быть тип организации тестирования или тестирования, которая обнаруживает ошибку при попытке определить влияние и стоимость ошибки и ее исправление. Модульное или функциональное тестирование может указывать на что-то в дизайне, которое необходимо изменить, и, следовательно, исправление на ранних этапах будет проще и дешевле, чем на более поздних. Системное или интеграционное тестирование может указывать на то, что затрагивает более широкий круг клиентов. Кроме того, тестирование стандартов, хотя зачастую и не является критичным для большого количества клиентов, может привести к потере сертификации, если не будет исправлено, и оказать негативное влияние на бизнес.
Тем не менее, только потому, что в конкретной тестовой организации произошел сбой теста, это не должно автоматически делать ошибку «критической». Например, может возникнуть соблазн сказать что-то вроде: «все системные тесты должны пройти перед отправкой, поэтому любой системный тест, который не пройден автоматически, приводит к критической ошибке / серьезной ошибке». Надеемся, что ни одна организация не сделает это заявление (хорошие критерии выхода из теста - это другое обсуждение), но дело в том, что об «серьезности» ошибки следует судить по ее влиянию на имидж клиента, продукта или компании, а не где или когда она не раскрывается.
Один из возможных способов решения этой проблемы - провести различие между «серьезностью» и «срочностью». Например, по мере приближения даты выпуска может возникнуть нехватка времени, чтобы определить, может ли ошибка с более низкой серьезностью повлиять на большое подмножество клиентов, придав этой ошибке большую «срочность» и повысив работу над этой ошибкой над (некоторыми) другими в по крайней мере, пока это определение не может быть сделано. Правильный баланс между ними, наряду с опытом и здравым смыслом, помог бы определить, на что тратятся время и усилия.
источник
В дополнение к тому, что другие говорили о классификации ошибок и т. Д., Также рассмотрите возможность использования Afferent Coupling (Ca) для определения уровня критичности, которую может представлять конкретная ошибка. Если у вас есть ошибка в модуле с большим количеством Ca, я мог бы сначала исправить ее, так как это может принести пользу другим компонентам в системе. CA помогает определить уровень ответственности, а ответственные модули с ошибками в них наносят ущерб всему приложению (подробнее о Ca читайте здесь: http://www.ibm.com/developerworks/java/library/j-cq04256/index.html. ).
Имея это в виду, мы склонны классифицировать ошибки и расставлять их по приоритетам в зависимости от их влияния на клиента. Ваш клиент будет отличаться, но его участие в обсуждении в конечном итоге определит, какие ошибки должны быть исправлены по сравнению с другими. Это не совсем научно, но как целая команда, мы склонны прийти к консенсусу в отношении приоритета и классификации ошибок, каждый имеет свой вклад в «большие» (все заинтересованные стороны могут внести свой вклад), и мы собираем и отстаиваем оттуда.
источник
Вы не можете определить фактическую стоимость всех ошибок. Некоторые вы можете, для многих это очень трудно измерить. Например, допустим, у вас есть ошибка, из-за которой весь текст на кнопках слегка смещен. Это делает ваш продукт 1.0 немного небрежным. Это не приводит к сбою вашей программы или потере данных пользователями. Вероятно, довольно дешевая ошибка, верно?
Теперь, что если каждый ваш клиент заметит эту проблему, и каждый рецензент упомянет ее в обзорах вашего продукта. И что, если эта ошибка переносится с версии 1.0 на 1.1 и 1.2. Ваша компания может иметь репутацию немного небрежного в контроле качества. Насколько дорогой может быть эта простая ошибка с точки зрения потенциальных потерянных продаж для вашей компании для будущих продуктов? Или, как это может повлиять на обзор, который получает ваш продукт - ваш продукт может полностью соответствовать потребностям ваших клиентов, но только 9 из 10, потому что выглядит немного неряшливо.
Таким образом, вам нужно не только посмотреть на стоимость конкретной ошибки с точки зрения того, сколько она стоит исправить, и на то, как она напрямую влияет на пользователя, но вы должны рассмотреть ее в более широком контексте того, как она влияет на восприятие вашего продукта. на рынке, и как это восприятие влияет на будущие продажи.
Это может показаться надуманным, но это не так. В то время, когда я пишу это, вы можете перейти на другой сайт в Интернете, где есть статья о том, как Apple переместила «1» на значке календаря на один или два пикселя. Если вы выполните поиск, вы увидите несколько негативных статей об этой крошечной ошибке. Конечно, это напрямую не повлияло на прибыль Apple, но они позиционируют себя как вершину хорошего дизайна, поэтому наличие ошибки дизайна влияет на это восприятие, хотя бы незначительно.
источник