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

Question

[drtvader]

Привет!
У меня есть бюджет на проект, скажем 100000р., есть время на выполнение проекта, 120 часов.
Как можно просчитать ту норму количества багов на любой проект?

Comments

[cssfish]

напомнило задачки на курсе по экологии... типа "посчитать сколько такого-то вещества еще можно влить в речку чтобы не превысить ПДК" :(

[Валентин]

vilinyh,

Для чего вам эта цифра? Как вы хотите ее использовать? Для решения какой проблемы?

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

[Валентин]

vilinyh,

ноль рублей ноль копеек

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

чтобы кто-то кому-то что-то заплатил после подписания актов

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

По сути вопроса ответить нечего?

[Валентин]

vilinyh,

Принимаешь любое мало-мальски работающее г, и просто выписываешь штрафы пачками.

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

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

Не уходите в сторону
Есть четкое определение гарантийного случая и что к нему относится. А именно действия со стороны ПОСТАВЩИКА. Экспертиза, способная это подтвердить, стоит не так уж дорого.

Вы спросили "зачем эта информация". Отвечаю - сколько раз платить за экспертизу=)

[Валентин]

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

Answer 1

[dmshar]

А зачем считать "баги на проект"?? Тем более, что любой мало-мальски опытный программист знает главную аксиому программирования: "Любой последний найденный баг в программе/проекте всегда является на самом деле предпоследним".
И это не шутка.
Вот из этого и исходите.

Comments

[Валентин]

Любой последний найденный баг в программе/проекте всегда является на самом деле предпоследним

Ну вы это директору своему объясняйте, когда с вас спросят, почему компания за полугодие в минус ушла да ещё и Штрафы от заказчиков висят.

[dmshar]

Валентин,
А вы ему вот это покажите:
https://habr.com/ru/post/428734/

Answer 2

[paran0id]

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

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

Answer 3

[Валентин]

Устранение баг в сданном продукте относится к этапу гарантии. Стоимость такого этапа оценивается в диапазоне от 5-20% в год от стоимости создания (лицензии?). Процент в указанном диапазоне максимален для заказной разработки и уменьшается в зависимости от количества повторяющихся инсталляций вашего программного продукта.

Answer 4

[Василий Банников]

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

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

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

Answer 5

[Руслан Гареев]

Если такой расчёт действительно нужен ( возможно, есть требование заказчика к качеству именно в таком виде), то я бы взял выработку в поинтах в этом проекте за 120 часов и предположил бы, что 95% поинтов было бы без багов, в остальных допускаются баги с выявлением и исправлением.