Комментарии 20
МЧМ — это исповедь Брукса перед человечеством. В конце концов он сам приходит к выводам, что не раз и неслабо сфейлил, поэтому его оценка количества ошибок завышена априори.
Но вот парная модель * коэффициент сложности проекта может работать, и вполне успешно.
Но вот парная модель * коэффициент сложности проекта может работать, и вполне успешно.
и что, эти 10 оставшихся ошибок потом нашли?
Я взял произвольный пример, чтобы показать как с помощью модели можно оценить количество оставшихся ошибок. Поиск и отладка — это уже выходит за рамки данных моделей.
тогда, собственно, в чем практическая польза такой оценки?
Я рассматривал модели в ознакомительных целях, чтобы показать какие вообще есть средства оценки количества ошибок. Я не знаю когда была разработана модель парной оценки, но миллсова модель и исторический опыт — были разработаны достаточно давно (конец 60х, начало 70х), так что в наше время вряд ли можно найти им практическое применение.
Я уже спрашивал в коментарии к предыдущей статье (возможно немного припозднившись). Повторю вопрос: зачем нам нужно знать величину N?
Величина N — это предположительное количество ошибок в программе. Суть таких моделей — это оценить количество ошибок (то есть не узнать наверняка сколько их, а лишь прикинуть).
Что такое N мне понятно. Также понятно, что любой здравомысляший человек понимает, что точное число тут не получить.
На всякий случай опять спрошу.
Зачем кому-то нужна эта величина?
На всякий случай опять спрошу.
Зачем кому-то нужна эта величина?
Если у вас на руках проект сложность которого вы представляете и команда, возможности которой вы понимаете, данная оценка помогает понять, сколько еще фич вы сможете внедрить до того, как придется идти в HR-ню и иметь мозг по поводу нового человека.
Кроме того, интуитивно понимая, с каким критическим N вы еще сможете справляться своевременно, можно планировать роадмап не только на ближайшую неделю, а на год вперед.
Ну, или если число N уже превысило все допустимые пределы, то пора подумывать о выпуске версии 2.0 :)
В любом случае, это — интуитивная величина, и нужен некоторый опыт, чтобы понимать ее ценность, и это позволит вам чувствовать жопу еще до того, как дурно запахнет.
Кроме того, интуитивно понимая, с каким критическим N вы еще сможете справляться своевременно, можно планировать роадмап не только на ближайшую неделю, а на год вперед.
Ну, или если число N уже превысило все допустимые пределы, то пора подумывать о выпуске версии 2.0 :)
В любом случае, это — интуитивная величина, и нужен некоторый опыт, чтобы понимать ее ценность, и это позволит вам чувствовать жопу еще до того, как дурно запахнет.
как уже было отмечено автором поста, практическая ценность этих оценок очень сомнительна.
Они бы имели хоть какой-то смысл, если бы включали в себя как минимум severity искомых ошибок.
Они бы имели хоть какой-то смысл, если бы включали в себя как минимум severity искомых ошибок.
Честно говоря я не вижу связи, как предположение о всеобщем количестве ошибок может повлиять на количество фич.
Число N не может превысить какие-либо пределы по двум причинам. Первая — это величина предположительная. Во-вторых, я не вижу никакой метрики, которая могла бы как-то поставить пределы для N.
Поясню на примере: N=300 полохо или хорошо? А N=500?
А теперь представьте, что в процессе разработки находят K багов, чинят М из них. Пусть К=100, М=80. Есть ли мне дело до того, что N=300 или 500? Да никакого абсолютно. Мне вообще его знать не надо. Если К станет 200, а М останется 80 — вот тут стоит задуматься о том месте где вы сейчас находитесь и тенденции движения вглубь этого места.
Число N не может превысить какие-либо пределы по двум причинам. Первая — это величина предположительная. Во-вторых, я не вижу никакой метрики, которая могла бы как-то поставить пределы для N.
Поясню на примере: N=300 полохо или хорошо? А N=500?
А теперь представьте, что в процессе разработки находят K багов, чинят М из них. Пусть К=100, М=80. Есть ли мне дело до того, что N=300 или 500? Да никакого абсолютно. Мне вообще его знать не надо. Если К станет 200, а М останется 80 — вот тут стоит задуматься о том месте где вы сейчас находитесь и тенденции движения вглубь этого места.
И еще пример.
Пусть это абстрактное N=500.
Ситуация №1
В процессе разработки нашли 200 багов. По показателям ужас-ужас, нашли менее 50% потенциально присутствующих багов. По факту, основательно протестировали основные вещи. Пользователи почти не находят ошибки в ПО после поставки, хотя там реально могут быть еще 3 сотни ненайденных дефектов.
Ситуация №2
В процессе разработки нашли 450 багов. Отлично, показатель на высоте — найдено 90% потенциально возможных ошибок. Но при тестировании бестолково протестили пару новых ключевых фич в которых 5-6 серьезных дефектов не дают жизни пользователям.
Итого — абсолютно неинтересная это величина. Никчемная. Может поэтому и забили придумывать всякие модели еще в 70-е годы?
Пусть это абстрактное N=500.
Ситуация №1
В процессе разработки нашли 200 багов. По показателям ужас-ужас, нашли менее 50% потенциально присутствующих багов. По факту, основательно протестировали основные вещи. Пользователи почти не находят ошибки в ПО после поставки, хотя там реально могут быть еще 3 сотни ненайденных дефектов.
Ситуация №2
В процессе разработки нашли 450 багов. Отлично, показатель на высоте — найдено 90% потенциально возможных ошибок. Но при тестировании бестолково протестили пару новых ключевых фич в которых 5-6 серьезных дефектов не дают жизни пользователям.
Итого — абсолютно неинтересная это величина. Никчемная. Может поэтому и забили придумывать всякие модели еще в 70-е годы?
Я думаю как вариант: для оценки стоимости поддержки продукта, для принятия решения о продолжении тестирования пока показатель найденных к общему числа не превысит определенного числа (к примеру когда он составит 90%).
Предположил интуитивно — в тестировании не разбираюсь.
Предположил интуитивно — в тестировании не разбираюсь.
А я не согласен, что у данных методов нет практического применения. Мне как заказчику работ неплохо было бы знать сколько в готовом продукте багов. А то получается так: сделали работу — «Все там хорошо!» — «Точно?» — «Точно!».
Сажусь тестировать. Раз баг, два баг, три баг. Спрашиваю: «Это все?» — «Да, да! Больше нету!». А верится уже с трудом.
Доверить ли этим людям дальнейшую работу над проектом? Какова вероятность, что там внутри столько всего, что все заново писать придется? Может лучше их всех разогнать и новых людей нанять, пока не слишком поздно?
На эти вопросы и помогает ответить данная статья. Конечно, эта методика лишь часть общей картины, но чем больше таких «частей» сигналит о проблемах, тем ближе я к верному решению. Так что автору спасибо.
Сажусь тестировать. Раз баг, два баг, три баг. Спрашиваю: «Это все?» — «Да, да! Больше нету!». А верится уже с трудом.
Доверить ли этим людям дальнейшую работу над проектом? Какова вероятность, что там внутри столько всего, что все заново писать придется? Может лучше их всех разогнать и новых людей нанять, пока не слишком поздно?
На эти вопросы и помогает ответить данная статья. Конечно, эта методика лишь часть общей картины, но чем больше таких «частей» сигналит о проблемах, тем ближе я к верному решению. Так что автору спасибо.
Вам, как заказчику, никто об этом не скажет. Причин много и основная, что число N никто точно не может высчитать. И еще, что из этого числа никаких выводов сделать нельзя.
А еще, вы как заказчик готовы оплатить паралельное независимое тестирование продукта двумя командами, чтобы использовать приведённый метод?
И еще, на вопрос «Есть ли в программе еще баги?» есть только один правильный ответ — «Да, есть».
А еще, вы как заказчик готовы оплатить паралельное независимое тестирование продукта двумя командами, чтобы использовать приведённый метод?
И еще, на вопрос «Есть ли в программе еще баги?» есть только один правильный ответ — «Да, есть».
Точного значения для N обычно и не нужно, нужна оценка с некоторой допустимой погрешностью.
Зачем это нужно? Мне кажется, что это может пригодиться для оценки полного времени работы над изменениями.
Чтобы не говорить «Мы закладываем один день на баги для каждой фичи», а более-менее оценивать, сколько работы еще предстоит. Сделать подобную оценку не так уж сложно (самая серьезная часть — это организовать независимое тестирование двумя командами), для крупного проекта это может быть вполне приемлемо.
Зачем это нужно? Мне кажется, что это может пригодиться для оценки полного времени работы над изменениями.
Чтобы не говорить «Мы закладываем один день на баги для каждой фичи», а более-менее оценивать, сколько работы еще предстоит. Сделать подобную оценку не так уж сложно (самая серьезная часть — это организовать независимое тестирование двумя командами), для крупного проекта это может быть вполне приемлемо.
Кстати, объясните откуда взялось равенство
N1/N == N12/N2
N1/N == N12/N2
В статье все есть, но продублирую и поясню, так как это основная идея данного метода:
То есть, первая команда из N ошибок находит N1, это ее «продуктивность».
Предполагаем, что «продуктивность» этой команды одинакова для любого тестирования. В частности, они тестировали то же, что и вторая команда. То есть, они нашли из N2 ошибок, которые там точно есть, N12 штук.
Получаем указанную пропорцию: N1/N = N12/N2.
Это основная идея. Конечно, это очень грубая оценка. А дальше можно варьировать и уточнять в зависимости от задачи и отклонению показателей в разных раундах тестирования. В конце статьи есть пример из IBM, посмотрите.
… в силу равновероятности нахождения любой из ошибок, любое случайным образом выбранное подмножество из N можно рассматривать как аппроксимацию всего множества N. Это значит, что если первая группа обнаружила 10% всех ошибок, она должна обнаружить примерно 10% из любого случайным образом выбранного подмножества.
В качестве такого случайным образом выбранного подмножества возьмём множество ошибок, найденных второй группой. Доля всех ошибок, найденных первой группой, равна N1/N. Доля ошибок, найденных первой группой среди тех ошибок, которые были найденны второй группой, равна N12/N2.
То есть, первая команда из N ошибок находит N1, это ее «продуктивность».
Предполагаем, что «продуктивность» этой команды одинакова для любого тестирования. В частности, они тестировали то же, что и вторая команда. То есть, они нашли из N2 ошибок, которые там точно есть, N12 штук.
Получаем указанную пропорцию: N1/N = N12/N2.
Это основная идея. Конечно, это очень грубая оценка. А дальше можно варьировать и уточнять в зависимости от задачи и отклонению показателей в разных раундах тестирования. В конце статьи есть пример из IBM, посмотрите.
Спасибо. Это теперь понятно.
А с IBM там совсем другое все. И даже можно сказать, что конкртено для этого проекта и этих людей они получат что-то более менее вразумительное. Походу они пытаются предсказать сколько они примерно _найдут_ багов, основываясь на том, сколько они находили раньше.
Хотя дальнейшие выкладки там мне тоже не понятны: В 18 из 20 новых модулей придется внести хотя бы одно исправление, в 3 модуля — не менее десятка. Из старых модулей хотя бы один раз придется исправить 21 модуль, а 8 или 9 модулей — не менее 10 раз.
А с IBM там совсем другое все. И даже можно сказать, что конкртено для этого проекта и этих людей они получат что-то более менее вразумительное. Походу они пытаются предсказать сколько они примерно _найдут_ багов, основываясь на том, сколько они находили раньше.
Хотя дальнейшие выкладки там мне тоже не понятны: В 18 из 20 новых модулей придется внести хотя бы одно исправление, в 3 модуля — не менее десятка. Из старых модулей хотя бы один раз придется исправить 21 модуль, а 8 или 9 модулей — не менее 10 раз.
Насчет IBM — да, видимо, они используют свои оценки для процента мало/много исправляемых модулей. И их коэффициенты будут работать для данного проекта и данной команды разработчиков/тестеров.
Насчет выкладок. Смотрим статью, внимание — ключ к пониманию :)
Да, тут мы по собранным ранее коэффициентам угадываем, сколько и каких исправлений нужно будет сделать.
Насчет выкладок. Смотрим статью, внимание — ключ к пониманию :)
Nиспр = 2*( 0.9*Nнов. мод. + 0.15*Nстар. мод.) + 23*( 0.15*Nнов. мод. + 0.06*Nстар. мод.)
340.2 = 2*( 0.9*20 + 0.15*140 ) + 23*( 0.15*20 + 0.06*140 )
= 2*( 18 + 21 ) + 23*( 3 + 8.4 )
Да, тут мы по собранным ранее коэффициентам угадываем, сколько и каких исправлений нужно будет сделать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оценка количества ошибок в программе. Парная оценка, Исторический опыт