@drtvader
Вечный студент

Как рассчитать норму количества багов на проект?

Привет!
У меня есть бюджет на проект, скажем 100000р., есть время на выполнение проекта, 120 часов.
Как можно просчитать ту норму количества багов на любой проект?
  • Вопрос задан
  • 139 просмотров
Пригласить эксперта
Ответы на вопрос 5
@dmshar
А зачем считать "баги на проект"?? Тем более, что любой мало-мальски опытный программист знает главную аксиому программирования: "Любой последний найденный баг в программе/проекте всегда является на самом деле предпоследним".
И это не шутка.
Вот из этого и исходите.
Ответ написан
paran0id
@paran0id
Умный, но ленивый
Думаю, качество продукта нужно выражать не через количество багов, а через достижение готовности (по фичам) и работоспособности (по отсутствию критических багов) продукта за оговоренный срок и бюджет.

Еще добавлю, что следует различать количество существующих багов, количество найденных багов и количество задокументированных багов. А ещё такой системой будут злоупотреблять, как и любым kpi, не имеющим прямого отношения к рабочему процессу. А ещё у багов есть степень критичности.
Ответ написан
Комментировать
vvpoloskin
@vvpoloskin
Инженер связи
Устранение баг в сданном продукте относится к этапу гарантии. Стоимость такого этапа оценивается в диапазоне от 5-20% в год от стоимости создания (лицензии?). Процент в указанном диапазоне максимален для заказной разработки и уменьшается в зависимости от количества повторяющихся инсталляций вашего программного продукта.
Ответ написан
Комментировать
vabka
@vabka
Токсичный шарпист
Никак не посчитать, и тем более никак не получится применять (по причине того что выполнение численной метрики со временем будет превращаться в самоцель)
И тем более не получится это посчитать из бюджета и сроков.

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

Чтобы минимизировать количество багов - пишите понятный код, думайте о том, как код будет работать (что может в теории придти в параметрах и вообще пойти не так), закладывайте время на тестирование.
Ответ написан
Комментировать
@RusGar
Legaltech и управление разработкой продуктов
Если такой расчёт действительно нужен ( возможно, есть требование заказчика к качеству именно в таком виде), то я бы взял выработку в поинтах в этом проекте за 120 часов и предположил бы, что 95% поинтов было бы без багов, в остальных допускаются баги с выявлением и исправлением.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы