1.4. Модели и метрики оценки качества ПО

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

Таблица 1.3.

Название модели	Формула, обозначение
МЕТРИКИ СЛОЖНОСТИ
Метрики Холстеда -длина программы; - объем программы - оценка ее реализации; - трудность ее понимания; - трудоемкость кодирования; - уровень языка выражения; - информационное содержание; - оптимальная модульность;	N = n1 log1 n1 + n2 log2 n2 V = N log2 n L*= (2 n2 )/ (n1 N2) Ec = V/ L* D = (n1N2) (2n2) = 1/ L* l * = V/ D2 = V/ L* 2 I = V / D M = n2*/6
Метрики Джилба - количество операторов цикла; - количество операторов условия; - число модулей или подсистем; - отношение числа связей между модулями к числу модулей; - отношение числа ненормальных выходов из множества операторов к общему числу операторов;	L1oop L IF L mod f = N4SV / L mod f * = N*SV / L
Метрики Мак-Кейба- цикломатическое число; - цикломатическая сложность;	l(G) = m - n + p n (G) =  l (G) +1 = m - n + 2
Метрика Чепена - мера трудности понимания программ на основе входных и выходных данных;	H = 0.5T+P+2M+3C
Метрика Шнадевида - число путей в управляющем графе	S =  S Pi Ci
Метрика Майерса - интервальная мера;	[n 1  ¸ n 2]
Метрика Хансена - пара (цикломатическое число, число операторов)	{n , N}
Метрика Чена - топологическая мера Чена;	M(G) = (n (G), N, Q0)
Метрика Вудворда - узловая мера (число узлов передач управления);	Y x
Метрика Кулика - нормальное число (число простейших циклов в нормальной схеме программы);	Norm (P)
Метрика Хура - цикломатическое число сети Петри, отражающей управляющую структуру программы;	l(G* р)
Метрики Витворфа, Зулевского -мера сложности потока управления -мера сложности потока данных;	g (Р) W (Р)
Метрика Петерсона - число многовходовых циклов;	Nm 1 0 0 p
Метрики Харрисона, Мэйджела - функциональное число (сумма приведенных сложностей всех вершин управляющего графа); - функциональное отношение (отношение числа вершин графа к функциональному числу); - регулярные выражения (число операндов, операторов и скобок в регулярном выражении управляющего графа программы);	f1 = S c 1 f* = N c 1/ f1 p(G) = N+L+Sk
Метрика Пивоварского - модифицированная цикломатическая мера сложности;	N(G) = n*(G) + S Pi
Метрика Пратта - тестирующая мера;	Test (Pr)
Метрика Кантоне - характеристические числа полиномов, описывающих управляющий граф программы;	PCN*
Метрика Мак-Клура - мера сложности, основанная на числе возможных путей выполнения программы, числе управляющих конструкций и переменных;	C(V) = D(V) ´ J(V) / N
Метрика Кафура - мера на основе концепции информационных потоков;	I(G)
Метрика Схуттса, Моханти - энтропийные меры;	e (G)
Метрика Коллофело - мера логической стабильности программ;	h (G)
Метрика Зольновского, Симмонса, Тейера Взвешенная сумма различных индикаторов: - (структура, взаимодействие, объем, данные); - (сложность интерфейса, вычислительная сложность, сложность ввода/вывода, читабельность);	å (a , b , g , n )   å (c , C , u , p )
Метрика Берлингера - информационная мера;	I(R) = m (F* (R) ´ F-(R))2
Метрика Шумана - сложность с позиции статистической теории языка;	X (Y )
Метрика Янгера - логическая сложность с учетом истории вычислений; Сложность проектирования Насыщенность комментариями Число внешних обращений Число операторов	L (w ) Cc = å log2 (i + 1) [å n Cxy (n)] X = K/C Ci L1
ПРОГНОЗ МОДЕЛИ
Модели Холстеда - прогноз системных ресурсов; - прогноз числа ошибок. Модель фирмы IBM Модель общей сложности Модели связности Сплайн-модель	P=3/8 (Ra - 1) ´ 2Ra B = Nlog2 n / 3000 B = 23M1 + M1 0 B = 21.1 + 0.1 V + COMP (S) Pij = 0.15 (Si + Sj) + 0.7 Cij Pij = ½ å l i (D Zij2 + D Nij2 ) ln (D Zij2 + D Nij2 ) + a + b Zi + g N1
ОЦЕНОЧНЫЕ МОДЕЛИ
Джелински - Моранды	R(t) = e - (Т - 1 + 1) Ft
Вейса-Байеса	R1 (t) = ò ò e - l - (i -1) F )t Y(l, F/t1, ... , ti-1) dl dФ
Шика-Волвертона	R1 (t) = e - F( N - 1 + 1) ti2 / 2
Литтлвуда	R1 (t) = (b+t /b+t +t) - F(N - i + 1) a
Нельсона	Rj (t) = exp { å ln (1 - Pj)}
Халецкого	Rj (t) = Pµ- a(1- g nj ) / nj
Модель отлаженности	Rj (t) =Pµ - r fj (t ,l ,p )
Мозаичная модель	Rj (t) = 1 - b ( a - w j - 1)

В таблице представлены разнообразные метрики сложности ПО для различных форм их представления, модели прогнозирующие ход развития процессов разработки ПО и вероятностные модели по оценке надежности.
Кратко рассмотрим метрики сложности. Одной из основных целей научно-технической поддержки является уменьшение сложности ПО. Именно это позволяет снизить трудоемкость проектирования, разработки, испытаний и сопровождения, обеспечить простоту и надежность производимого ПО. Целенаправленное снижение сложности ПО представляет собой многошаговую процедуру и требует предварительного исследования существующих показателей сложности, проведения их классификации и соотнесения с типами программ и их местоположением в жизненном цикле.
Теория сложности программ ориентирована на управление качеством ПО и контроль ее эталонной сложности в период эксплуатации. В настоящее время многообразие показателей (в той или иной степени описывающих сложность программ) столь велико, что для их употребления требуется предварительное упорядочение. В ряде случаев удовлетворяются тремя категориями метрик сложности. Первая категория определяется как словарная метрика, основанная на метрических соотношениях Холстеда, цикломатических мерах Мак-Кейба и измерениях Тейера. Вторая категория ориентирована на метрики связей, отражающих сложность отношений между компонентами системы - это метрики Уина и Винчестера. Третья категория включает семантические метрики, связанные с архитектурным построением программ и их оформлением.
Согласно другой классификации, показатели сложности делятся на две группы: сложность проектирования и сложность функционирования. Сложность проектирования, которая определяется размерами программы, количеством обрабатываемых переменных, трудоемкостью и длительностью разработки и др. факторами, анализируется на основе трех базовых компонентов: сложность структуры программы, сложность преобразований (алгоритмов), сложность данных. Во вторую группу показателей отнесены временная, программная и информационная сложности, характеризующие эксплуатационные качества ПО.
Существует еще ряд подходов к классификации мер сложности, однако они, фиксируя частные стороны исследуемых программ, не позволяют (пусть с большим допущением) отразить общее, то, чьи замеры могут лечь в основу производственных решений.
Общим, инвариантно присущим любому ПО (и связанной с его корректностью), является его СТРУКТУРА. Важно связать это обстоятельство с определенным значением структурной сложности в совокупности мер сложности ПО. И более того, при анализе структурной сложности целесообразно ограничиться только ее топологическими мерами, т.е. мерами, в основе которых лежат топологические характеристики граф-модели программы. Эти меры удовлетворяют подавляющему большинству требований, предъявляемых к показателям: общность применимости, адекватность рассматриваемому свойству, существенность оценки, состоятельность, количественное выражение, воспроизводимость измерений, малая трудоемкость вычислений, возможность автоматизации оценивания.
Именно топологические меры сложности наиболее часто применяются в фазе исследований, формирующей решения по управлению производством (в процессах проектирования, разработки и испытаний) и составляют доступный и чувствительный эталон готовой продукции, контроль которого необходимо регулярно осуществлять в период ее эксплуатации.
Первой топологической мерой сложности является цикломатическая мера Мак-Кейба. В ее основе лежит идея оценки сложности ПО по числу базисных путей в ее управляющем графе, т.е. таких путей, компонуя которые можно получить всевозможные пути из входа графа в выходы. Цикломатическое число l (G) орграфа G с n-вершинами, m-дугами и p-компонентами связности есть величина l (G) = m - n + p.
Имеет место теорема о том, что число базисных путей в орграфе равно его цикломатическому числу, увеличенному на единицу. При этом, цикломатической сложностью ПО Р с управляющим графом G называется величина n (G) = l (G) +1 = m - n + 2. Практически цикломатическая сложность ПО равна числу предикатов плюс единица, что позволяет вычислять ее без построения управляющего графа простым подсчетом предикатов. Данная мера отражает психологическую сложность ПО.
К достоинствам меры относят простоту ее вычисления и повторяемость результата, а также наглядность и содержательность интерпретации. В качестве недостатков можно отметить: нечувствительность к размеру ПО, нечувствительность к изменению структуры ПО, отсутствие корреляции со структурированностью ПО, отсутствие различия между конструкциями Развилка и Цикл, отсутствие чувствительности к вложенности циклов. Недостатки цикломатической меры привело к появлению ее модификаций, а также принципиально иных мер сложности.
Дж. Майерс предложил в качестве меры сложности интервал [n _1¸ n ₂], где n ₁- цикломатическая мера, а n ₂ - число отдельных условий плюс единица. При этом, оператор DO считается за одно условие, а CASE c n - исходами за n - 1- условий. Введенная мера получила название интервальной мерой.
У. Хансену принадлежит идея брать в качестве меры сложности ПО пару {цикломатической число, число операторов}. Известна топологическая мера Z(G), чувствительная к структурированности ПО. При этом, она Z(G) = V(G) (равна цикломатической сложности) для структурированных программ и Z(G) > V(G) для неструктурированных. К вариантам цикломатической меры сложности относят также меру М(G) = (V(G),C,Q), где С - количество условий, необходимых для покрытия управляющего графа минимальным числом маршрутов, а Q - степень связности структуры графа программы и ее протяженность.
К мерам сложности, учитывающим вложенность управляющих конструкций, относят тестирующую меру М и меру Харрисона-Мейджела, учитывающих уровень вложенности и протяженности ПО, меру Пивоварского - цикломатическую сложность и глубину вложенности, и меру Мак-Клура - сложность схемы разбиения ПО на модули с учетом вложенности модулей и их внутренней сложности.
Функциональная мера сложности Харрисона-Мейджела предусматривает приписывание каждой вершине графа своей собственной сложности (первичной) и разбиение графа на сферы влияния предикатных вершин. Сложность сферы называют приведенной и слагают ее из первичных сложностей вершин, входящих в сферу ее влияния, плюс первичную сложность самой предикатной вершины. Первичные сложности вычисляются всеми возможными способами. Отсюда функциональная мера сложности ПО есть сумма приведенных сложностей всех вершин управляющего графа.
Мера Пивоварского ставит целью учесть в оценке сложности ПО различия не только между последовательными и вложенными управляющими конструкциями, но и между структурированными и неструктурированными программами. Она выражается отношением N(G) = n ^*(G) + S P_i , где n ^*(G) - модифицированная цикломатическая сложность, вычисленная так же, как и V(G), но с одним отличием: оператор CASE с n- выходами рассматривается как один логический оператор, а не как n - 1 операторов. Р_i - глубина вложенности i - той предикатной вершины.
Для подсчета глубины вложенности предикатных вершин используется число сфер влияния. Под глубиной вложенности понимается число всех сфер влияния предикатов, которые либо полностью содержаться в сфере рассматриваемой вершины, либо пересекаются с ней. Глубина вложенности увеличивается за счет вложенности не самих предикатов, а сфер влияния. Сравнительный анализ цикломатических и функциональных мер с обсуждаемой для десятка различных управляющих графов программы показывает, что при нечувствительности прочих мер этого класса, мера Пивоварского возрастает при переходе от последовательных программ к вложенным и далее к неструктурированным.
Мера Мак-Клура предназначена для управления сложностью структурированных программ в процессе проектирования. Она применяется к иерархическим схемам разбиения программ на модули, что позволяет выбрать схему разбиения с меньшей сложностью задолго до написания программы. Метрикой выступает зависимость сложности программы от числа возможных путей исполнения, числа управляющих конструкций и числа переменных (от которых зависит выбор пути). Методика расчета сложности по Мак-Клуру четко ориентирована на хорошо структурированные программы.
Тестирующей мерой М называется мера сложности, удовлетворяющая следующим условиям:
1. Мера сложности простого оператора равна 1;
2. М ({F1; F2; ┘;Fn}) = е_iⁿ M(Fi);
3. М (IF P THEN F1 ELSE F2) = 2 MAX (M (F1), M (F2));
4. М (WHILE P DO F) = 2 M(F).
Мера возрастает с глубиной вложенности и учитывает протяженность программы. К тестирующей мере близко примыкает мера на основе регулярных вложений. Идея этой меры сложности программ состоит в подсчете суммарного числа символов (операндов, операторов, скобок) в регулярном выражении с минимально необходимым числом скобок, описывающим управляющий граф программы. Все меры этой группы чувствительны к вложенности управляющих конструкций и к протяженности программы. Однако возрастает уровень трудоемкости вычислений.
Рассмотрим меры сложности, учитывающие характер разветвлений. В основе узловой меры Вудворда, Хедли лежит идея подсчета топологических характеристик потока управления. При этом, под узловой сложностью понимается число узлов передач управления. Данная мера отслеживает сложность линеаризации программы и чувствительна к структуризации (сложность уменьшается). Она применима для сравнения эквивалентных программ, предпочтительнее меры Холстеда, но по общности уступает мере Мак-Кейба.
Топологическая мера Чена выражает сложность программы числа пересечений границ между областями, образуемыми блок - схемой программы. Этот подход применим только к структурированным программам, допускающим лишь последовательное соединение управляющих конструкций. Для неструктурированных программ мера Чена существенно зависит от условных и безусловных переходов. В этом случае можно указать верхнюю и нижнюю границы меры. Верхняя - есть m+1, где m - число логических операторов при их гнездовой вложенности. Нижняя - равна 2. Когда управляющий граф программы имеет только одну компоненту связности, мера Чена совпадает с цикломатической мерой Мак-Кейба.
Метрики Джилба оценивают сложность графоориентированных модулей программ отношением числа переходов по условию к общему числу исполняемых операторов. Хорошо зарекомендовала себя метрика, относящаяся число межмодульных связей к общему числу модулей. Названные метрики использовались для оценки сложности эквивалентных схем программ, в особенности схем Янова.
Используются также меры сложности, учитывающие историю вычислений, характер взаимодействия модулей и комплексные меры.
Совокупность цикломатических мер пригодна для оценивания сложности первичных формализованных спецификаций, задающих в совокупности исходные данные, цели и условия построения искомого ПО. Оценка этой первичной программы или сравнение нескольких альтернативных ее вариантов позволит изначально гармонизировать процесс разработки ПО и от стартовой точки контролировать и управлять его текущей результирующей сложностью.