Сообщений в теме: 44

[ray]

Привет,

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

RR

[Case]

Расскажите по результатам проработки этого вопроса что у вас получилось, пожалуйста.

[Clauster]

А сколько у вас будет строк кода в проекте?

[ray]

Хорошо, но пока что ничего не получилось.

Строк кода неизвестно сколько будет. У нас применяется оценка по временным затратам, если она интересует, то цифры примерно такие-

Requirements: 450
Design: 450
Build: 2000
Test: 2000
Manage: 500

RR

[Clauster]

Тогда так. Сколько ошибок допускает ваш разработчик на 10 000 строк кода?

[Clauster]

В общем, мне кажется, это нереально оценить без метрик.

[ray]

А как можно оценить с наличием метрик? Предположим вообще все метрики.

RR

[Clauster]

А как можно оценить с наличием метрик? Предположим вообще все метрики.

RR

Тогда надо ещё предположить что у вас примерно 4-й уровень CMMI. Как оценивать? Собираете в кучу необходимые данные (метрики) и оцениваете. "Вообще все метрики" это примерно как "вообще все книги" или "вообще все фильмы" ну, или, "вообще все деньги". Нужные вам метрики вы наверное можете получить из результатов уже выполненых похожих проектов. Оценка - задачка по математике уровня 6 класса, сложение умножение и деление и т.д.
Количество ошибок на 10000 строк кода - может быть одной из метрик. А может и не быть.
Я сам никогда количество багов не предсказывал, но думаю, можно попытаться вычислить таким способом.

[SALar]

127 ошибок на 1000 кода. Где то была такая оценка. Только вот для какого проекта это справедливо?

А на общий вопрос: "Сколько ошибок будет в проекте?", - отвечаем так же обще: "Столько, каков пробег у автомобиля." У какого автомобиля, выражено в дюймах или парсеках - это уже не важно. Общий вопрос - общий ответ.

Ну или оцените так: каждые Х часов программист будет делать 1 ошибку. Х находится в пределах от 0.1 до 100.

[ray]

Нужные вам метрики вы наверное можете получить из результатов уже выполненых похожих проектов. Оценка - задачка по математике уровня 6 класса, сложение умножение и деление и т.д.

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

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

RR

[Imbecile]

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

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

RR

Берёте метрику: среднее количество ошибок за час написания кода и умножаете на запланированное количество часов кодописания.

[Inevitable]

127 ошибок на 1000 кода. Где то была такая оценка. Только вот для какого проекта это справедливо?

А на общий вопрос: "Сколько ошибок будет в проекте?", - отвечаем так же обще: "Столько, каков пробег у автомобиля." У какого автомобиля, выражено в дюймах или парсеках - это уже не важно. Общий вопрос - общий ответ.

Ну или оцените так: каждые Х часов программист будет делать 1 ошибку. Х находится в пределах от 0.1 до 100.

Мне кажется вот это еще куда не шло Ну или оцените так: каждые Х часов программист будет делать 1 ошибку. Х находится в пределах от 0.1 до 100.

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

Мне кажется, наиболее логичный выход - это аналитическая оценка.

[SALar]

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

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

RR

Берёте метрику: среднее количество ошибок за час написания кода и умножаете на запланированное количество часов кодописания.

Если чуть чуть усложнить, то

где
N - число разработчиков
k - среднее количество ошибок за час написания кода для i-того разработчика на проекте денного типа
t - время кодирования i-того разработчика на проекте

Прикрепленные файлы

•  errorV.bmp   13,94К   135 Количество загрузок:

[Imbecile]

Мне кажется вот это еще куда не шло Ну или оцените так: каждые Х часов программист будет делать 1 ошибку. Х находится в пределах от 0.1 до 100.

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

Мне кажется, наиболее логичный выход - это аналитическая оценка.

А что такое аналитическая оценка? Как её проводить?

[Inevitable]

Мне кажется вот это еще куда не шло Ну или оцените так: каждые Х часов программист будет делать 1 ошибку. Х находится в пределах от 0.1 до 100.

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

Мне кажется, наиболее логичный выход - это аналитическая оценка.

А что такое аналитическая оценка? Как её проводить?

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

[Imbecile]

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

Тогда встаёт вопрос второй. Где взять взять критерий "схожести" модулей? Модуль - модулю рознь. Я уже молчу про то, что предыдущие проекты и, соответственно, модули могли быть выполнены на разных платформах. Например, старые проекты на php, а новый на ASP.NET. Как соотнести модуль на php с аналогичным на ASP.NET? Те десять процентов, что вы указали, могут быть и больше, и меньше, и вообще со знаком минус.
Проще всё-таки привязываться к качетвенному уровню разработчика. Сколько он "позволяет себе" допустить ошибок в еденицу времени нормального рабочего процесса написания кода.

[Imbecile]

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

[Yury]

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

А Вам оно надо?
А зачем?

Я бы поступил так:
1) Написал бы какие нибудь числа "от фонаря" (я имею в виду с использованием одного из уже приведённых методов) не тратя на это много времени
2) Послал бы на согласование разработчикам, менеджерам и т.п.

[Clauster]

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

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

Ещё раз повторюсь, какие именно метрики, коэффициенты использовать - не знаю, никогда не считал, могу предложить лишь методику.

[Clauster]

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

А Вам оно надо?
А зачем?

Я бы поступил так:
1) Написал бы какие нибудь числа "от фонаря" (я имею в виду с использованием одного из уже приведённых методов) не тратя на это много времени
2) Послал бы на согласование разработчикам, менеджерам и т.п.

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