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

[Green]

Есть желание получить желтый пояс по BPI (Business Process Improvment). Для этого нужно реализовать некоторые улучшения процесса и посчитать их экономическую эффективность. В качестве проекта хочу представить имплементацию юнит тестирования в компании.

Если представить идеальную ситуацию, что можно получить любую информацию по проекту то, что бы следовало запросить и как этими данными распорядиться?

Предполагаю, что экономическая эффективность - это сумма сэкономленных долларов в расчете на исправление одного дефекта.
Если дефект обнаруживается на стадии эксплуатации, то его устранение стоит С1.
Если на стадии тестирования, то - С2.
Если на стадии разработки, то - С3.

Необходимо получить статистику по найденым дефектам. Другими словами, узнать сколько дефектов на 1000 строк кода обнаруживается на стадии эксплуатации V1 и тестирования V2. По окончании проекта посчитать сколько дефектов (на 1000 строк кода) было выявлено и устранено в результате юнит тестирования V3.

Получаем пропорции.

Процентное сотношение багов, найденных на стадии эксплуатации:
S = V1*100/(V1+V2)

Пропорциональное количество багов юнит тестирования:
VS1 = V3*S/100
VS2 = V3*(100-S)/100

Вычисляем эффективность:
F1 = C1*VS1-C3*VS1
F2 = C2*VS1-C3*VS1

Суммируем сэкономленные средства:
F = F1+F2

Умножаем на количество строк кода:
FS = F*L

Уффф...
Как давно я учил математику!
B)
Может чего напутал?
:unsure:

[barancev]

Мне кажется, что основным достоинством unit-тестирования является возможность его применения не для тестирования, а в разработке. На этом TDD стоит. Поэтому нужно учитывать также изменения в эффективности разработки (возможно, она замедляется?)

[Xam&LOX]

Ваш способ под счета эффективности юнит тестирования больше подходит для технарей, а не для бизнеса. :( :( :(

Сергей, как бы делал я обоснования для начальства об использование данного метода тестирования (разработки ПО).

1.Улучшение профессиональных навыков программистов.
2.Сокращения числа смарт-манки ( ручных тестировшиков ).
3.Создание стабильного фрейм-ворка с применением автоматического тестирования
( юнит тестирования без автоматического тестирования это как пиво без водки). :D :D :P B)
4.Введения методики FPA анализа ПО позволяющие сделать более понятный процесс разработки ПО (что не противоречит XP) для заказчика.
5.Повышения уровня по CMMI.
6.Т.п.

Резюме:
Бизнес все равно, сколько ошибок на строку кода :( . Бизнесу главной, сколько времени надо для устранения ошибки :D . Надо упор делать на сокращения числа сотрудников и уменьшения общего времени на разработку («разработка + тестирования» или числа интеракций между подразделениями т.п.). Типа того

P.S.
Извините пока формулы нет, но так через недельку что-нибудь придумаю ;) :ph34r:

[barancev]

Повышения уровня по CMMI.

Сергей, действительно, просто так заниматься BPI это как-то скучно и приземлённо, нет желания побороться за шестой уровень CMMI? :P

[Green]

Повышения уровня по CMMI.

Сергей, действительно, просто так заниматься BPI это как-то скучно и приземлённо, нет желания побороться за шестой уровень CMMI? :P

На самом деле не все так скучно.
B)

Речь идет о вознаграждении (премии) в размере 2-5% от сэкономленных средств за год. В масштабах софтверной компнии это могут быть не очень скучные деньги.

В качестве примера могу привести упаковщицу ноутбуков на заводе в Ирландии. Она предложила унифицировать упаковку для ноутбуков разных категорий, что дало экономию где-то около пол миллиона долларов. Размер ее премии не знаю, но можно посчитать варианты.
:rolleyes:

В Делле, как и в ряде других продвинутых компаний, существует программа по улучшению процесса. Одно лишь условие, все должно быть оформлено в виде проекта по BPI. Мне это тоже подходит.

Существует три пояса по BPI: желтый (начальный), зеленый и черный. Цвет пояса зависит от масштабов проекта (суммы экономии). Для его получения (пояса) нужно выполнить хотя бы один проект. Если проект по Юнит Тестированию будет признан масштабным, то есть шанс получить зеленый пояс (2-я ступень). На рынке труда обладатель желтого пояса может расчитывать на зарплату на 10-15% выше, чем у такого же претендента, но без пояса. Зеленый пояс дает возможность получать зарплату на 30% выше. Про черный и говорить нечего. Таких специалистов не много и за ними охотятся рекрутеры.

А с CMM работают и без меня. Там народу хватает.
;)

[Green]

Ваш способ под счета эффективности юнит тестирования больше подходит для технарей, а не для бизнеса. :( :( :(

Полностью согласен, что применение юнит тестирование может дать многогранную выгоду. Так же оно имеет и недостатки. В рамках BPI это расходы или убытки, уменьшающие экономию.

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

Но интересует только те показатели, которые могут быть классифицированы, посчитаны и оценены в экономических еденицах. Иначе, это будет не проект по BPI, а гадание на кофейной гуще.

Да, кстати, BPI - это business process improvement.
Но это так, на всякий случай.
B)

[Xam&LOX]

Про гадания на кофейной гуще и мне не надо :D

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

Вы подытожили мою мысль. Что в ДЕЛЛ программистам зарплату платят за количество качественного кода? :D Или же за количество им написанного строк кода? :D Думаю, что нет!! :D Как и во всех компаниях, оплата почасовая. Так и эффективность надо показывать в этих единицах (я не думаю, что это противоречит BPI, я думаю, что это будет более понятие руководству). Вы описываете статический показать эффективности (который использует для расчета уже готово продукта «например в радио электроники сравнивают новый продукт со старыми аналогами »), а вам надо описать динамику. B) :(

[dlg99]

Как и во всех компаниях, оплата почасовая.

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

[Xam&LOX]

мысли, знаете ли, нехорошие появляются.

dlg99 А чем вы? :angry:
Пишите по подробнее, пожалуйста

[Green]

Про  гадания  на кофейной гуще  и мне не надо :D

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

Вы подытожили мою мысль. Что в ДЕЛЛ программистам зарплату платят за количество качественного кода? :D Или же за количество им написанного строк кода? :D Думаю, что нет!! :D Как и во всех компаниях, оплата почасовая. Так и эффективность надо показывать в этих единицах (я не думаю, что это противоречит BPI, я думаю, что это будет более понятие руководству). Вы описываете статический показать эффективности (который использует для расчета уже готово продукта «например в радио электроники сравнивают новый продукт со старыми аналогами »), а вам надо описать динамику. B) :(

Отличная мысль!
Спасибо.

За основу предыдущих расчетов принималась стоимости бага, точнее его устранения. Но, по сути, эта стоимость есть время затраченное заказчиком/тестировщиком/программистом на обнаружение и исправление бага. Другими словами, чем позже обнаружен дефект, тем длинее его жизненный цикл и тем дороже он стоит. Что бы вычислить стоимость бага необходимо рассмотреть три вида ЖЦ: разработчик, разработчик - тестировщик, разработчик - тестировщик - заказчик. В каждом из этих случаев почасовая ставка оплаты труда разная и это сказывается на стоимости бага.

[Xam&LOX]

5 - балов :D :D :D

[SALar]

IMHO
Есть еще важный показатель - скорость выпуска продукта. В некоторых случаях можно пойти на удорожание тестирования ради увеличения скорости выпуска продукта "купить время за деньги". В актив здесь надо заносить несколько лишних дней / недель / месяцев продажи продукта. А это очень большие деньги.

На 2% от выгоды продажи WXP на месяц раньше можно неплохо жить всю оставшуюся жизнь. :D