Господа, не подскажете ли какие существуют системы, предназначенные для измерения размера программного продукта. Облазил web, но пока не нашел ):
Хотелось бы чтоб утилитка умела считать кол-во строк для проектов, написанных на разл языках. Умела различать строчки созданные программистом и компиляторомю.
И конечно, умела бы генерировать отчеты.
Здравствуйте, Orin.i9, Вы писали:
OI>Господа, не подскажете ли какие существуют системы, предназначенные для измерения размера программного продукта. Облазил web, но пока не нашел ): OI>Хотелось бы чтоб утилитка умела считать кол-во строк для проектов, написанных на разл языках. Умела различать строчки созданные программистом и компиляторомю. OI>И конечно, умела бы генерировать отчеты.
Глянь по поиску, тему поднимали эту неделю назад
Здравствуйте, slavdon, Вы писали:
SS> Глянь по поиску, тему поднимали эту неделю назад
К сожалению я не смог найти информации именно по тулам обеспечивающим измерение кода Возможно сказался фактор моего первого посещения rsdn.ru
Что странно — думал что проблем с поиском подобной утилиты не возникнет.
Здравствуйте, Orin.i9, Вы писали:
OI>К сожалению я не смог найти информации именно по тулам обеспечивающим измерение кода Возможно сказался фактор моего первого посещения rsdn.ru OI>Что странно — думал что проблем с поиском подобной утилиты не возникнет.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Подсчет "строк кода" — идиотизм. Идет из времен ассемблера и Фортрана эдак на PDP-11.
MSS>Измерение размера кода в килобайтах — намного разумнее.
1) А как же метрики количества дефектов на KSLOC. Пытаться предсказать кол-во дефектов по "весу продукта в километрах" мне не представляется более разумным.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Измерение размера кода в килобайтах — намного разумнее.
А почему бы не в сантиметрах: суммарная длина исходников по вертикали на листах, составленных по короткой стороне? Или в граммах: общий вес бумаги после распечатывания всех исходников?
Здравствуйте, A.Lokotkov, Вы писали:
AL>А почему бы не в сантиметрах: суммарная длина исходников по вертикали на листах, составленных по короткой стороне? Или в граммах: общий вес бумаги после распечатывания всех исходников?
Ага! Дальше предлагаю внедрить метрику успешности проекта:
1) Из базы bug-tracking распечатать общий отчет по дефектам.
2) Посредством новейшей методики "Refiting Fire II" через сожжение привести код проекта и отчет по дефектам к единому состоянию для упрощения дальнейшего анализа.
3) Сравнить количество дефектов и написанного кода взвесив на чашах весов полученный пепел.
4) Интерпретировать полученный результат — качество проекта налицо (в переносном смысле, не стоит сразу кидаться в пепел, еще не все потеряно. ведь можно и тестеров уговорить более кратко излагать свои мысли, для этого предлагаю дефекты описывать исключительно на буркиноафасовском языке).
5) Ввести дополнительные коэффиценты, н/п степень перевешивания
Спасибо за помощь. Продукты посмотрел,
но к сожалению так и нашел программ которые бы работали с различными версионными хранилищами, такими как VSS и ClearCase.
Здравствуйте, Orin.i9, Вы писали:
OI>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>Подсчет "строк кода" — идиотизм. Идет из времен ассемблера и Фортрана эдак на PDP-11.
MSS>>Измерение размера кода в килобайтах — намного разумнее.
OI>1) А как же метрики количества дефектов на KSLOC. Пытаться предсказать кол-во дефектов по "весу продукта в километрах" мне не представляется более разумным.
Значит, дурацкие метрики, опять же тех самых фортрановских времен.
Вот смотрите сами:
if() {
expression
}
и
if()
{
expression
}
— то же самое, а в одном из примеров на 1 строку кода больше, чем во втором.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>Подсчет "строк кода" — идиотизм. Идет из времен ассемблера и Фортрана эдак на PDP-11.
B>Подобные заявления — вот это в самом деле не умно.
Я чуть выше ответил (ответ был адресован Orin.i9) — почему сия метрика есть маразм, и почему покилобайтная метрика лучше.
MSS>>Измерение размера кода в килобайтах — намного разумнее.
AL>А почему бы не в сантиметрах: суммарная длина исходников по вертикали на листах, составленных по короткой стороне? Или в граммах: общий вес бумаги после распечатывания всех исходников?
Потому что метрика в виде "размер исходного кода" — вообще говоря, есть маразм в любом ее виде. непонятно, чему разумному может служить эта метрика. Расчету условных показателей в абстрактно-теоретических книжках?
А уж разновидность этой метрики под названием "строки кода" — есть особо маразматичная ее разновидность. Приведу пример еще раз:
if() {
}
if()
{
}
В современных языках она просто не годится. Зато годится в Фортране и ассемблерах, где строго по одному оператору в строке.
Скажите, где, как, когда и чему полезному может служить метрика "размер исходного кода". Буду очень рад. Сам я этого понять не могу.
Это что — показатель, который предполагается стимулировать? т.е. стимулировать овердизайн и очень длинные комментарии? или — в случае "строк кода" — стимулировать принцип "новая лексема с новой строки"?
Ни качество продукта, ни соблюдение сроков не имеют никакого отношения к этой метрике.
OI>Ага! Дальше предлагаю внедрить метрику успешности проекта: OI>1) Из базы bug-tracking распечатать общий отчет по дефектам.
Аааа!
Так вот зачем в PMных книжках используется метрика "строки кода"!. Для получения показателя под названием "баги на строку кода"!
Умно до блеска. Сторонники такой метрики — скажите, а вы хоть раз реальный bugtracker видели?
Дело в том, что issues там разные. Очень много там, например, неполного взаимопонимания заказчика и постановщика задачи. Очень много там, например, ситуаций, когда продукт должен уметь "еще и вот это", а девелоперы об этом забыли — просто проглядели.
Или возьмем понятие "степень серьезности бага". Это понятие совершенно разное в глазах тестеров/заказчиков/начальства — и в глазах девелоперов.
Например, баг уровня серьезности crash (высший уровень, продукт сам не работает как надо и валит всю ОС) — зачастую правится без исследования и воспроизведения, просто по тестерскому описанию уже ясно, и первый взгляд на реальный код уже дает понять, где и как править. Один час работы.
А баг уровня серьезности minor (interop с другим продуктом, редко наблюдаемый, ничего не валится, просто часть фич не работает) — зачастую требует целых исследований для своего затыкания. Дня три работы.
В свете всего это метрика "количество багов на единицу размера исходника" — выглядит маразмом. Независимо от того, как этот размер мерять.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Здравствуйте, Orin.i9, Вы писали:
OI>>Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>>Подсчет "строк кода" — идиотизм. Идет из времен ассемблера и Фортрана эдак на PDP-11.
MSS>>>Измерение размера кода в килобайтах — намного разумнее.
OI>>1) А как же метрики количества дефектов на KSLOC. Пытаться предсказать кол-во дефектов по "весу продукта в километрах" мне не представляется более разумным.
MSS>Значит, дурацкие метрики, опять же тех самых фортрановских времен.
MSS>Вот смотрите сами:
MSS>if() { MSS> expression MSS>}
MSS>и
MSS>if() MSS>{ MSS> expression MSS>}
MSS>- то же самое, а в одном из примеров на 1 строку кода больше, чем во втором.
MSS>Покилобайтный счетчик так не обманешь.
Нормальные тулы это учитывают.
Тупо строки никто и не считает.
Впрочем с идеей покилобайтных счетчиков можешь обраться в какой-нибудь SEI.
Может они тот же COCOMO под него адаптируют
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Скажите, где, как, когда и чему полезному может служить метрика "размер исходного кода". Буду очень рад. Сам я этого понять не могу.
А чем тебе не нравится метрика "количество дефектов на 1000 логических строк кода",
Где дефект — это то, что нашли юзеры после выпуска продукта?
Вполне неплохая метрика, которая характеризует процесс разработки в целом.
Реально применяется в фирмах, которые пытаются управлять своим качеством.
Только прежде чем критиковать, подумай о проблеме в целом.
У нас же форум "управление проектами"...
Здравствуйте, Maxim S. Shatskih, Вы писали:
OI>>Ага! Дальше предлагаю внедрить метрику успешности проекта: OI>>1) Из базы bug-tracking распечатать общий отчет по дефектам.
MSS>Аааа!
MSS>Так вот зачем в PMных книжках используется метрика "строки кода"!. Для получения показателя под названием "баги на строку кода"!
MSS>Умно до блеска. Сторонники такой метрики — скажите, а вы хоть раз реальный bugtracker видели?
Угу... Мы еще ими и пользуемся
MSS>Очень много там, например, ситуаций, когда продукт должен уметь "еще и вот это", а девелоперы об этом забыли — просто проглядели.
"Девелоперы забыли" — это кстати серьезный дефект, который не повышает оценку процесса в целом.
Такие дефекты обязательно надо учитывать.
Метрики, кстати, не должны показывать где зарыта проблема.
По метрикам можно судить о процессе в целом и в случае чего начать разборки.
Уже по результам разборок выясниться что означает "Девелоперы забыли".
Может быть тестры нашли это, а потом девелоперы просто похерили.
Или какой-то аналитик проигнорировал пожелание заказчика и оно в итоге не попало в SRS.
Вот ты большой босс, отвечающий за качество в не маленькой конторе.
Как ты без обобщенных метрик будет оценивать ситуацию в целом?
Будешь код читать и записи в bugtrack системах просматривать?
MSS>Потому что метрика в виде "размер исходного кода" — вообще говоря, есть маразм в любом ее виде. непонятно, чему разумному может служить эта метрика. Расчету условных показателей в абстрактно-теоретических книжках?
MSS>В современных языках она просто не годится. Зато годится в Фортране и ассемблерах, где строго по одному оператору в строке.
Годится, если существует единый стиль кодирования в команде/конторе.
MSS>Скажите, где, как, когда и чему полезному может служить метрика "размер исходного кода". Буду очень рад. Сам я этого понять не могу.
На мой взгляд прежде всего планированию следующих проектов. См. например COCOMO
MSS>Это что — показатель, который предполагается стимулировать? т.е. стимулировать овердизайн и очень длинные комментарии? или — в случае "строк кода" — стимулировать принцип "новая лексема с новой строки"?
Я вас умоляю. В любой книжке/статье в которой встречается слово "SLOC" встречается также предупреждение о том что не стоит оценивать работу девелоперов по этой метрике.
В общем "учите матчасть" (С) фидо.
начать можно с wiki а дальше по ссылкам и книжкам.
MSS>Ни качество продукта, ни соблюдение сроков не имеют никакого отношения к этой метрике.
см. выше.
Возможно сказался фактор моего первого посещения rsdn.ru 
