Метрика MMC введена B.Харрисоном и К.Куком и вычисляется по следующей формуле:

MMC = сумма i=1 до n( SC(i) *V(G)(i))

где n- число подпрограмм, SC(i) – макрометрика подпрограммы i, определяемая по следующей формуле

SC(i) = G(i) *(n-1) + P(i)* (1-DI(i))

Здесь G(i) и P(i) показывают, сколько раз глобальные переменные или параметры используются в подпрограмме i; DI(i) – индекс документированности для пподпрограммы i,который находится по формуле

DI(i) = число строк комментариев (i) /общее число строк в (i)
.V(G)(i) — мера Мак-Гейна.

ВОПРОС:

Покритикуйте данную меру или может быть вы ей пользуетесь?

Здравствуйте, Аноним, Вы писали:

А>Метрика MMC введена B.Харрисоном и К.Куком и вычисляется по следующей формуле:
/* поскипано */
А> Покритикуйте данную меру или может быть вы ей пользуетесь?

ИМХО бред какой-то. Какой вообще смысл в этих механистических примитивных оценках?

K>ИМХО бред какой-то. Какой вообще смысл в этих механистических примитивных оценках?

http://www.iis.nsk.su/preprints/AUTOREF/chern/AUTOREF/node2.html

Здравствуйте, Kluev, Вы писали:

K>Здравствуйте, Аноним, Вы писали:

А>>Метрика MMC введена B.Харрисоном и К.Куком и вычисляется по следующей формуле:
K>/* поскипано */
А>> Покритикуйте данную меру или может быть вы ей пользуетесь?

K>ИМХО бред какой-то. Какой вообще смысл в этих механистических примитивных оценках?

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

А>которая все говорит о качестве программы и ее надежности...

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

Хотя конечно вы правы, говоря о том, что это только один из критериев определения качества. Можно посмотреть книги Липаева по оценки качества программного обеспечения он указывает более 20 критериев и используя методы принятия решений при многих критериях можно классифицировать программу.

Здравствуйте, Аноним, Вы писали:


А>>которая все говорит о качестве программы и ее надежности...

А>ну это как проинтерпретировать. Можно говорить по этой цифире о числе тестов необходимых для тестирования программы.

А>Хотя конечно вы правы, говоря о том, что это только один из критериев определения качества. Можно посмотреть книги Липаева по оценки качества программного обеспечения он указывает более 20 критериев и используя методы принятия решений при многих критериях можно классифицировать программу.

Спасибо за наводку!
Вопрос только один. Что конкретно меряется у Липаева?
Т.е. вопрос не в том, как, а именно что (текст программы или еще что).

А>Т.е. вопрос не в том, как, а именно что (текст программы или еще что).

не только текст. например наработка на отказ при отсутствие рестарта, время отклика и т.д

А>ВОПРОС:

А> Покритикуйте данную меру или может быть вы ей пользуетесь?

у меня у самого такие вопросы к ней

1)Чем больше глобальных переменных использует подпрограмма тем выходит хуже.

ну вроде согласен

2) Если использует одну глобальную переменную, то срузу почему-то V(G)(i) умножается аж на (n-1) может надо избавится от (n-1):
SC'(i) = G(i)+ P(i)* (1-DI(i))


3) Чем больше параметров использует продпрограмма тем выходит хуже

как-то не понятно.


4) Почему-то индекс документированности влияет на коэффицент при параметрах, а не например при числе вхождений глобальных переменных

Здравствуйте, Аноним, Вы писали:

А>>Т.е. вопрос не в том, как, а именно что (текст программы или еще что).

А>не только текст. например наработка на отказ при отсутствие рестарта, время отклика и т.д

Т.е. только конечный продукт?
Если да, то это как раз то, о чем я говорил.
Качество — это не только отсутсвие отказов.
Если программа не вешается, быстро реагирует и исходный текст программы
прекрасно структурирован, то это мало что говорит о качестве.
В общем мерять нужно не продут, а процессы создания продукта.
Мерять продукт в реальной жизни уже часто просто поздно.

А>Мерять продукт в реальной жизни уже часто просто поздно.

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


Липаев в своей работе конечно пищет и про этот подход и Поттосин пишет. Тот же Липаев рассматривает среди критериев и функциональности и никто незапрещает ввести в критерии удовлетворенность пользователей.

Но все это звенья одной цепи. при оценка/ cертификация того же процесса разработка возникает необходимость в оценке и что наверное еще более важно контроле качества программного продукта.

Здравствуйте, Аноним, Вы писали:

А>>Мерять продукт в реальной жизни уже часто просто поздно.

А>вообщем-то понятно к чему вы клоните...

Я практик
Моя личная практика показывает, что если метрики продукта мне показывают
слошные сбои и проблемы, то ситуация уже практически неисправимая.
Все баги закладываются на этапе планирования и опредения продукта (специфицирование).

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


P.S. Я не против метрик вообще.
Просто значение их не стоит преувеличивать.

Здравствуйте, Аноним, Вы писали:

А>P.S. Я не против метрик вообще.
А>Просто значение их не стоит преувеличивать.

Могу предложить свои метрики:
супер_метрика_1 = (доход-расход)/число_строк
супер_метрика_2 = (доход-расход)/число_девелоперов
супер_метрика_3 = количество_оплаченных_апгрейдов/общее_число_проданных_копий

А все эти (глобальные_переменные/функций + прочее_академическое_мракобесие) это фуфел

Здравствуйте, Kluev, Вы писали:

K>Здравствуйте, Аноним, Вы писали:

А>>P.S. Я не против метрик вообще.
А>>Просто значение их не стоит преувеличивать.

K>Могу предложить свои метрики:

Ну в общем ты прав
Деньги — вот универсальная метрика.
А другие направлены как раз на то, чтобы сделать больше денег
или не потерять их слишком много

Хотелось бы классифицировать модули по этому критерию сложности:
1) простой
2) нормальной сложности
3) сложный

Видится мне это так. Число подпрограмм должно быть 7 +-2. Мера V(G) если > 10 то считается сложной. Параметров -1. Поэтому

1) Простой: < 10*5 = 50
2) Нормальной сложности < 10* 9 = 90
3) Сложный > 10*9 = 90

Хотя нет. простой сложности — это когда до 5 функций в модуле в каждой до 5 параметров. И сложность функции по Мак-Гейну до 10 путей.

Итого 5*10* 5 = 250

Нормальной сложности — это когда до 9 функций в каждой до 9 параметров. и сложность до 10 путей

Итого 9 * 9* 10 = 810

Cложный — это когда добле > 810