Сколько времени нужно потратить на ошибки по сравнению с оригинальной разработкой? [закрыто]

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

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

Например, если для завершения проекта А требуется 40 часов и дополнительно 10 исправлений ошибок, этот проект будет иметь соотношение 4: 1.

Если для завершения другого проекта (B) потребуется 10 часов, а для ошибок - еще 8, то соотношение будет 5: 4.

Это документированная / исследованная концепция?

ОБНОВИТЬ

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

Равновесный процент от общей емкости, выделенной для устранения дефектов, равен скорости ввода дефектов .

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

Что касается команды B, если они создают в среднем 8 единиц переделок на каждые 10 единиц работы, которые они выполняют, то при работе с этими 8 единицами создаются новые 6,4 единиц переделок. Мы можем оценить общее усилие, которое им в конечном итоге придется потратить, как сумму геометрической прогрессии:

10 + 8 + 6,4 + 5,12 + ...

Количество ошибок будет экспоненциально уменьшаться со временем, но у команды B коэффициент экспоненты такой, что она очень медленно стремится к нулю. На самом деле, сумма первых трех слагаемых в вышеуказанной серии составляет всего 24,4; из первых пяти - 33,6; из первых 10, 45; из всей серии, 50. Итак, команда B резюме: скорость впрыска дефектов, 0,8; разработка функций, 10/50 = 20%; исправление дефектов, 80%. 20/80 - это их устойчивое распределение мощностей.

Команда А, напротив, находится в гораздо лучшей форме. Их прогрессия выглядит так:

40 + 10 + 2,5 + 0,625 + ...

Сумма этой серии составляет 53 1/3, поэтому распределение разработки функции в команде A составляет 40 / (53 1/3) = 75%, а распределение исправлений дефектов - 25%, что соответствует коэффициенту внедрения дефектов 10/40 = 0,25. ,

На самом деле, все термины в серии команды А после первых трех ничтожно малы. С практической точки зрения это означает, что команда A, вероятно, может устранить все свои ошибки с помощью пары выпусков поддержки, второй выпуск довольно мал по объему. Это также создает иллюзию, что любая команда может сделать это. Но не команда Б.

Я думал об этой эквивалентности, читая новую книгу Дэвида Андерсона «Канбан» . (Книга посвящена другой теме, но также затрагивает вопросы качества.) При обсуждении качества программного обеспечения Андерсон цитирует эту книгу Каперса Джонса «Оценка программного обеспечения, тесты и лучшие практики» :

«... в 2000 году ... измеренное качество программного обеспечения для североамериканских групп ... варьировалось от 6 дефектов на функциональную точку до менее 3 на 100 функциональных точек, диапазон от 200 до 1. Средняя точка составляет примерно 1 дефект на От 0,6 до 1,0 функциональных баллов. Это означает, что команды обычно тратят более 90 процентов своих усилий на устранение дефектов ». Он приводит пример, предоставленный одним из его коллег из компании, которая тратит 90% времени на устранение ошибок ,

Беглость, с которой Андерсон переходит от скорости внедрения дефекта к распределению емкости для исправления дефектов ( требование отказа - это термин для этого), предполагает, что эквивалентность этих двух вещей хорошо известна исследователям качества программного обеспечения и, вероятно, известна в течение некоторого времени ,

Ключевыми словами в цепочке рассуждений, которые я пытаюсь представить здесь, являются «equlibrium» и «устойчивый». Если мы уберем устойчивость, то есть очевидный способ обмануть эти числа: вы делаете начальное кодирование, затем переходите к коду где-то еще и оставляете обслуживание другим. Или вы увеличиваете техническую задолженность и выгружаете ее у нового владельца.

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

Математика, которую я здесь использовал, упрощена. Я пренебрег такими вещами, как трансакционные издержки (встречи по планированию и оценке, посмертные и т. Д.), Которые несколько повлияли бы на проценты. Я также опустил уравнения, имитирующие поддержку одного продукта и разработку другого одновременно. Но вывод все еще остается в силе. Делайте то, что вы можете, с точки зрения технических приемов, таких как модульное тестирование, непрерывная интеграция, проверка кода и т. Д., Чтобы снизить уровень внедрения дефектов и, следовательно, потребность в сбоях. Если вы можете создать только одну ошибку для каждых 10 функций, у вас будет много свободного времени для разработки новых функций и удовлетворения ваших клиентов.

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

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

Используйте матрицу, подобную следующей (по горизонтали - время, необходимое для исправления ошибки, по вертикали - тип ошибки - влияние на пользователей)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Пример проблемы:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

Матрица может быть более сложной с различными уровнями серьезности, усилий, рисков и т. Д.

Вы даже можете создать рейтинг для каждой ошибки и исправить их на основе рейтинга. Что-то типа:

Bug priority = Risk x Severity x Effort

* Может быть (1-x) для некоторых операндов, в зависимости от масштаба, который вы выбираете :)

Итак, чтобы ответить на ваш вопрос: зависит от типа ошибок, доступного времени / бюджета и т. Д.

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

Например, в модели водопада вы можете точно установить первую ошибку на первом этапе тестирования, но в гибкой среде может быть трудно поднять строку, говорящую «с этого момента мы исправляем ошибки», так как функции могут изменяться ( и мне нечестно считать изменение функции ошибкой)

Исходя из опыта, я говорю, что это то, что ВСЕГДА недооценивается, и очень легко может потратить столько же часов, сколько «оригинальный проект».

По-настоящему правильным ответом будет исправление ошибок в ноль часов, потому что ваш код идеален. :-)

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

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

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

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

На критическом программном обеспечении соотношение 1: 1 не является необычным. Только для модульного тестирования я видел показатели, указывающие на 1 день модульного тестирования на каждые 10 строк кода.

Я думаю, что этот вопрос необъективен: он исходит из того, что исправление ошибок - это этап, похожий на разработку новых функций . Это не вариант.

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

Обратите внимание, что разработчики должны самостоятельно тестировать свой собственный код. В их обязанности входит поставлять код без ошибок. Поэтому трудно отделить кодирование от отладки.

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

Таким образом, вместо того, чтобы говорить о «времени, потраченном на ошибки», вы должны говорить о «времени, потраченном на тесты» (интеграционные тесты, пользовательские приемочные тесты ...)

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

Если это поможет, я могу сказать вам, что проекты, над которыми я работаю (корпоративное пространство, большие сложные системы, много интеграции с другими системами), имеют соотношение около 3: 2. Большинство из них не являются ошибками с кодом - чаще всего ошибки с интерфейсами. Например, системы A и B общаются друг с другом через интерфейс X. Разработчики системы A интерпретируют интерфейс X немного иначе, чем разработчики системы B. Комедия следует.

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

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