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

[Yury]

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

Но менеджер же попросил!
Так ведь надо его уважить
И займёт это всего минут пять.

[Inevitable]

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

компания, выпускающая софт, обычно специлизируется на одном-нескольких продуктах, и для каждого разного проекта меянется набор стандартных модулей и добавляются различные специфичные feature для данного продукта. Например, если это workflow, то для каждого проекта хоть оно и отличается, но ядро одно и то же. Я имею ввиду, что наврядли компания автора разрабатывает целиком и полностью новый продукт. Поэтому и следует ориентироваться на предыдущий опыт.
По поводу Change Request: при формулировки требований, всегда есть такой пункт, как RISK (то есть возможность изменения требований). И если он равен 100%, то увеличить цифры вдвое, если 50 - то в половину..
По поводу, 10% - вдруг больше, вдруг меньше - естесственно такое может быть.
Но как я предполагаю, этот документ - филькина граммота, никакой официальной "юридической силы", по большому счету, он нести не будет, это и понятно, потому что вероятность точного определения количество багов в системе такая же как вероятность в казино выграть джек-пот.

[Angela]

На самом деле это нормальная практика использовать коэффициенты типа плотности дефектов (Количество дефектов на строки кода), производительности тестирования (количество дефектов за время тестирования) и т.п. Кстати предложенной проиводительности "генерации дефектов" :) т.е. количество дефектов за время разработки нигде не видела. Ведь их найти надо еще... Можно предсказать только количество обнаруженных дефектов, а не количество дефектов в приложении.

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

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

[Rost]

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

Но менеджер же попросил!
Так ведь надо его уважить
И займёт это всего минут пять.

Еслы Вы так будете "уваживать" менджеров, Вы много не сделаете.
Надо более профессионально относится к своим обязанностям. Либо не делать, если Вы уверены в абсолютной потере времени без какого-либо результата, либо делать правильно. А с Вашим подходом и продукт выйдет такой, что бы только "уважить" менеджера.

[Clauster]

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

Но менеджер же попросил!
Так ведь надо его уважить
И займёт это всего минут пять.

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

[SALar]

Еслы Вы так будете "уваживать" менджеров, Вы много не сделаете. 
Надо более профессионально относится к своим обязанностям. Либо не делать, если Вы уверены в абсолютной потере времени без какого-либо результата, либо делать правильно. А с Вашим подходом и продукт выйдет такой, что бы только "уважить" менеджера. 

Если вы готовы с легкостью сменить место работы, то поступайте как считаете нужным.
Как я уже писал ранее: "Тестер ошибается дважды. Второй раз, когда находит ошибку в работе своего руководителя."

[Rost]

Если вы готовы с легкостью сменить место работы, то поступайте как считаете нужным.
Как я уже писал ранее: "Тестер ошибается дважды. Второй раз, когда находит ошибку в работе своего руководителя."

Если, после того как у руководителя была найдена ошибка тестером, этот тестер должен уходить (его увольняют или просто выживают), то в таком случае надо самому тестеру БЕГОМ БЕЖАТЬ от такого горе-руководителя.
Если человек не может признать свои ошибки - это не специалист, а диктатор. :-) И делу он больше мешает чем помогает...
Кстати можно еще и с руководителем руководителя поговорить. Если и там то же - то это клиника (где-то я уже это писал :-))

[Yury]

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

Мой не очень большой опыт говорит как раз об обратном.

Напомню, кстати, с чего началась эта дискуссия:

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

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

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

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

[Rost]

Напомню, кстати, с чего началась эта дискуссия:

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

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

Может и не понимал. А может ему и не надо понимать. :-) Если все всем объяснять, можно только этим и заниматься. Я согласен, что четкая постановка задачи - это очень много, однако задача "написание estimate на прогнозируемое количество багов в проекте" - по моему вполне конкретна и выполнима.

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

Постеснялся... Простите не сдержался.
Мне интересно, эти гипотетические менеджеры, они там в пасочки играют? Что значит менеджер постеснялся...
Это только характеризует самого менеджера.

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

Вот это правильно, только я не очень понимаю как это соотносится с Вашим предыдущими постами:

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

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

Как-то непонятно. Так все таки "делать" или "какие нибудь числа"? :-)

[Yury]

Как-то непонятно. Так все таки "делать" или "какие нибудь числа"? :-)

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

[Rost]

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

А с чего Вы взяли что только для проформы? Зачем тогда делать такую работу? И какой здравый менеджер будет просить своих подчиненных терять время на проформу. :-) Менеджер и сам может сказать "300".
"На любой вопрос, даю любой ответ". :-)

[Clauster]

А с чего Вы взяли что только для проформы? Зачем тогда делать такую работу? И какой здравый менеджер будет просить своих подчиненных терять время на проформу. :-) Менеджер и сам может сказать "300".
"На любой вопрос, даю любой ответ". :-)

Какой-то вы невыносимый прямо стали в последнее время. Зачем вы передёргиваете всё? Читайте внимательно! Вдумывайтесь в то, что вам хотят донести!

Если эти числа...

[Rost]

Какой-то вы невыносимый прямо стали в последнее время. Зачем вы передёргиваете всё? Читайте внимательно! Вдумывайтесь в то, что вам хотят донести!

Будьте любезны передерги в студию.

Если эти числа...

На счет "Если" - человек предположил. Я в ответ тоже предположил что в таком случае менеджер и сам может ответить и не опускать глупости вниз.

Что не так?

[Clauster]

проехали...
вам бы в прокуроры идти.

[Rost]

проехали...
вам бы в прокуроры идти.

Почему, я ведь никого не обвинял...

[ray]

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

Как очень верно заметила Angela 10-15 defects per SLOС это т.н. industry average. 127 per LOC это очень много.

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

Данный подход был одним из самых первых предложеных в для оценки количесва дефектов в далеких 70х, да и то они уже тогда пытались добавлять в формулы functional points или цикломатическию сложность. В результате искомой линейной зависимости так и не нашли.

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

Может и не понимал. А может ему и не надо понимать. :-)

Браво! "Основы форумного флейма": правило #4.

На самом деле это нормальная практика использовать коэффициенты типа плотности дефектов (Количество дефектов на строки кода), производительности тестирования (количество дефектов за время тестирования) и т.п. Кстати предложенной проиводительности "генерации дефектов" :) т.е. количество дефектов за время разработки нигде не видела. Ведь их найти надо еще... Можно предсказать только количество обнаруженных дефектов, а не количество дефектов в приложении.

Defect density (плотность дефектов) очень хорошая метрика, более того имеющая применение и без предсказания количеста дефектов.

Разница между найдеными и всеми дефектами это так называемые остаточные (residual) дефекты. Но это вообще немного отдельная тема, со своими методиками расчета. Наиболее существенная разница в том остаточные дефекты достаточно просто и довольно точно считаются в процессе разработки\тестирования, например как апроксимация кривой removal'а; искуственным внедрением в программу дефектов и оценки их нахождения; наконец как %% от общего количества уже обнаруженых дефектов.

Как заключение - спасибо всем отозвавшимся. Я постараюсь закончить этот типа стади и написать какое то саммари.

RR

[Diogen]

Привет,

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

RR

С таким количеством неизвестных решения данной задачи не существует. Многое зависит от того какой проект, процесс, люди в нем учавствующие. Реально предсказать сколько будет багов в будущем проекте можно лишь на основании прошлого опыта, сравнив проект с уже прошедшими, и учтя разницу между ними. Оценивать кол-во багов пользуясь метриками других проектов и cases studies так же нелепо как пытаться примерять на А.Шварценеггера свадебное платье ;)

Из метрик наиболее точный результат мне дают нормализованные по человекочасам и по кол-ву требований (если они пишуться единообразно от релиза к релизу). Предпочитаю использовать обе и анализировать если получается разница.

----
Best Wishes,
Vladimir

[DrVal]

Меня больше интересует, зачем оценивать количество дефектов в проекте?
О чем скажет это магическое число?

Т.е. сначала мы по неким метрикам проекта оцениваем количестов дефектов.
Потом по другим неким другим метрикам, оценивам время и ресурсы на баг-фиксинг (мне кажется, что цель именно в этом).
Почему бы не оценивать риски проекта напрямую?

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

[dimasoft]

На мой взгляд количество обнаруженных дефектов зависит от 3-х параметров:
1. Качество ПО.
2. Качество тестирования.
3. Объем выполняемого тестирования.

В своих проектах я оцениваю количество обнарженных дефектов как отношение к количеству тестовых сценариев. При этом 3 параметр учитывается автоматически. Качество тестирования я принимаю за постоянное в разных проектах, т.к. обеспечиваю его я. А вот качество ПО бывает разным. Но обычно количество дефектов находится в пределах от 15% до 30% от числа сценариев.

[dimasoft]

Меня больше интересует, зачем оценивать количество дефектов в проекте?
О чем скажет это магическое число?

Т.е. сначала мы по неким метрикам проекта оцениваем количестов дефектов.
Потом по другим неким другим метрикам, оценивам время и ресурсы на баг-фиксинг (мне кажется, что цель именно в этом).
Почему бы не оценивать риски проекта напрямую?

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

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