Метрики анализа программного обеспечения

ПРАКТИЧЕСКОЕ ЗАНЯТИЕ №3

 

МЕТРИКИ АНАЛИЗА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

 

Выполнил:		Студент(-ка) группы №________   ____________________________ подпись, дата
Проверил:		ФИО

  ___________________________

     подпись, дата

 

 

Минск 2020

 

 

ПРАКТИЧЕСКОЕ ЗАНЯТИЕ №3

МОДЕЛИ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Пользователи программного обеспечения испытывают потребности в создании мо­делей качества программного обеспечения для оценки качества как качественно, так и количественно. Модели качества, которые имеются в настоящее время, в большинстве случаев являются иерархическими моделями на основе критериев качества и связанных с ними показателей (метрик). Все модели качества могут быть разделены на три кате­гории в соответствии с методами, на основе которых они были созданы. К первому ви­ду можно отнести теоретические модели, основанные на гипотезе отношений между переменными качества. Ко второму виду относятся модели «управления данными», ос­нованные на статистическом анализе. И наконец, комбинированная модель, в которой интуиция исследователя используется для определения нужного вида модели, а анализ данных используется для определения констант модели качества.

Модель МакКола

Первая модель качества была предложена МакКолом [4-6]. Предложенная модель была в основном предназначена для определения полной характеристики качества про­граммного продукта через его различные характеристики. Модель качества МакКола (см. рис. 1) имеет три главных направления для определения и идентификации качества программного обеспечения:

•  использование (корректность, надежность, эффективность, целостность, практич­ность);

• модификация (тестируемость, гибкость, сопровождаемость - факторы качества важные для разработки новой версии программного обеспечения);

•  переносимость (мобильность, возможность многократного использования, функ­циональная совместимость - факторы качества важные для переносимости про­граммного продукта на другие аппаратные и программные платформы).

3.1.2. Модель Боэма

Второй из основополагающих моделей качества является модель качества Боэма [7]. Модель Боэма имеет недостатки современных моделей, которые автоматически и качественно оценивают качество программного обеспечения. В сущности, модель Бо­эма пытается качественно определить качество программного обеспечения заданным набором показателей и метрик. Модель качества Боэма представляет характеристики программного обеспечения в более крупном масштабе, чем модель МакКола. Модель Боэма похожа на модель качества МакКола тем, что она также является иерархической моделью качества, структурированную вокруг высокоуровневых, промежуточных и примитивных характеристик, каждая из которых вносит свой вклад в уровень качества программного обеспечения.

Рисунок 1. Модель качества программного обещания МакКола

 

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

 

Рисунок 2. Модель качества программного продукта Боэма

 

3.1.2. Модель FURPS/FURPS+

Акроним FURPS, используемый в обозначении модели, обозначает следующие ка­тегории требований к качеству ПО:

• Functionality (Функциональность) /особенности, возможности, безопасность/;

•  Usability (Практичность) /человеческий фактор, эргономичность, пользовательская документация/;

•  Reliability (Надежность) /частота отказов, восстановление информации, прогнози- руемость/;

•  Performance (Производительность) /время отклика, пропускная способность, точ­ность, доступность, использование ресурсов/;

•  Supportability (Эксплуатационная пригодность) /тестируемость, расширяемость, адаптируемость, сопровождаемость, совместимость, конфигурируемость, обслужи­ваемость, требования к установке, локализуемость/.

• Символ «+» расширяет FURPS модель, добавляя к ней:

•  ограничения проекта (ограничения по ресурсам, требования к языкам и средствам разработки, требования к аппаратному обеспечению);

• интерфейс (ограничения накладываемые на взаимодействие с внешними система­ми);

• требования к выполнению,

• физические требования,

• требования к лицензированию.

FURPS модель качества [8], предложенная Грейди и Hewlett Packard, построена схожим образом с моделями МакКола и Боэма, но в отличие от них состоит из двух слоев, первый определяет характеристики, а второй связанные с ними атрибуты. Ос­новной концепцией, лежащей в основе FURPS модели качества, является декомпозиция характеристик программного обеспечения на две категории требований, а именно, функциональные (F) и нефункциональные (URPS) требования. Эти выделенные катего­рии могут быть использованы как в качестве требований к программному продукту, так и в оценке качества НИ. В настоящее время модель FURPS+ широко используется в разработке программного обеспечения и при идентификации требований к разрабаты­ваемой системе целесообразно использование FURPS+ модели в качестве универсаль­ного контрольного перечня характеристик НО.

Модель Гецци

Карло Гецци и соавторы [9] различают качество продукта и процесса. Согласно модели Гецци к качеству программного обеспечения относят следующие характери­стики программного обеспечения: целостность, надежность и устойчивость, произво­дительность, практичность, верифицируемость, сопровождаемость, возможность мно­гократного использования, мобильность, понятность, возможность взаимодействия, эффективность, своевременность реагирования, видимость процесса разработки.

Модель качества Дроми

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

Модель качества SATC

В Центре обеспечения качества программного обеспечения NASA (Software Assur­ance Technology Center, SATC) была разработана программа метрик [11], обеспечи­вающая оценку рисков проекта, качества продукции и эффективности процессов. Нро- грамма SATC рекомендует отдельно отслеживать качество требований, качество про­граммного обеспечения и других продуктов (документации), качество тестирования и качество выполнения процессов. Модель качества SATC определяет набор целей, свя­занных с программным продуктом и атрибуты процессов в соответствии со структурой модели качества программного обеспечения ISO 9126-1.

 

Модель качества ISO 9126

Качество программного обеспечения определяется в стандарте ISO 9126-1 [2] как всякая совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц.

Модель качества ISO 9126-1 различает понятия внутреннего качества, связанного с характеристиками ПО самого по себе, без учета его поведения; внешнего качества, ха­рактеризующего ПО с точки зрения его поведения; и качества ПО при использовании в различных контекстах - того качества, которое ощущается пользователями при кон­кретных сценариях работы ПО. Для всех этих аспектов качества введены метрики, по­зволяющие оценить их. Кроме того, для создания надежного ПО существенно качество технологических процессов его разработки. Взаимоотношения между этими аспектами качества по схеме, принятой ISO/IEC 9126 (ISO/IEC 9126-1:2001 [2]; ISO/IEC TR 9126­2:2003 [12], ISO/IEC TR 9126-3:2003 [13], ISO/IEC TR 9126-4:2004 [14]), показано на Рис 3.

 

Рисунок 3. Основные аспекты качества программного обеспечения

 

На рис. 4 представлены факторы и атрибуты внешнего и внутреннего качества программного обес­печения в соответствии с ISO/IEC 9126.

Рисунок 4. Факторы и атрибуты внешнего и внутреннего качества программного обеспечения

 

На рис. 5 приведена модель оценивания согласно ISO/IEC 9126.

Рисунок 5. Модель оценивания надежности программного обеспечения согласно стандарта ISO / IEC 9126

 

Модель качества QMOOD

Джагдиш Банзия и Карл Дэвис [15] предложили иерархическую модель качества для объектно-ориентированного проектирования (QMOOD), которая расширяет мето­дологию модели качества Дроми и включает в себя четыре уровня:

1) Определение показателей качества проекта: набор атрибутов качества проекта, которые используются в QMOOD для описания характеристик объектно­ориентированных систем включат: функциональность, эффективность, понятность, расширяемость, возможность многократного использования и гибкость.

2) Определение объектно-ориентированных свойств проекта: свойства проекта мо­гут быть определены в процессе исследования внутренней и внешней структуры, функциональности компонент проекта, атрибутов, методов и классов. Структур­ным и объектно-ориентированным множеством свойств проекта, которые исполь­зуются в QMOOD, являются: размер проекта, иерархическая структура, инкапсуля­ция, связанность, состав проекта, наследование, полиморфизм, обмен информаци­ей, сложность.

3) Определение объектно-ориентированных метрик проекта: различные объектно­ориентированные метрики проекта.

4)   Определение объектно-ориентированных свойств проекта: Компоненты проекта были определены для определения архитектуры объектно-ориентированного про­екта. Эта модель определяет парадигму, а также вводит ряд новых объектно­ориентированных метрик.

 

 

Другие модели качества

Модель качества, описанная в [16], представила два различных подхода к показате­лям качества на протяжении всего жизненного цикла программного обеспечения. Ха­рактеристики качества могут быть сведены к двум группам:

1) эффективность, безопасность, доступность и функциональность;

2)  модифицируемость, мобильность, возможность многократного использования, на­следуемость и тестируемость.

Согласно модели качества Хосрави К. и др. [18] процесс оценки качества состоит из двух задач:

1) выбор глобальной характеристики;

2) выбор подхарактеристик, связанных с глобальной характеристикой.

Эта модель качества основана на многократном использовании программного обеспе­чения в качестве глобальной характеристики и акценте на возможности многократного использования, понятности, гибкости, модульности, надежности, масштабируемости и удобстве использования. Модель качества Хосрави и др. связала показатели качества и подхарактеристики, используя определения IEEE, ISO/IEC и некоторых других моделей качества.

Для оценки качества программного обеспечения на основе теории нечетких мно­жеств и метода анализа иерархий, Чанг и др. [18] были определены руководящие прин­ципы и это подход ими был применен к модели качества ISO 9126-1. Оценки качества программного обеспечения основаны на характеристиках и подхарактеристиках модели ISO 9126-1.

Шармой А. и др. [19] была предложена компонентно-ориентированная модель ка­чества разработки программного обеспечения, которая включает все характеристики и подхарактеристики модели качества ISO 9126-1, а также предлагает новые подхаракте­ристики, такие как пригодность к повторному использованию, гибкость, сложность, прослеживаемость, масштабируемость. Метод анализа иерархий в этой модели исполь­зуется для оценки качества проекта.

4. МНОГОУРОВНЕВЫЙ ПОДХОД К МОДЕЛЯМ КАЧЕСТВА [2]

На рисунке 6 представлены характеристики качества программных средств (по ГОСТ 28195–89. ГОСТ 28195-89 Оценка качества программных средств. Общие положения).

В основе моделей качества лежит многоуровневый подход (количество слоев мо­жет быть 2 /модели МакКола и Боэма/ или 3 слоя /включая метрики/).

Сравнительный анализ характеристик различных моделей качества программного обеспечения приве­ден в таблице 2.1.

 

 

 

 

Рисунок 6. Характеристики качества программных средств

(по ГОСТ 28195–89. ГОСТ 28195-89 Оценка качества программных средств. Общие положения).

 

Таблица 2.1. Сравнительный анализ моделей качества программного обеспечения

Характеристики качества	МакКол	Боэм	FURPS/ FURPS+	Гецци	Дроми	ISO 9126	Казман	Хосрави	Шармоа
Корректность				+
Надежность	+	+	+	+	+	+	+		+
Корректность	+
Эффективность	+	+	+	+	+	+	+		+
Гибкость	+			+			+	+
Функциональность			+		+	+	+		+
Эргономичность проетирования		+
Целостность				+
Функциональная совместимость	+
Сопровождаемость	+	+	+	+	+	+	+		+
Модифицируемость		+
Производительность			+
Мобильность	+	+		+	+	+			+
Зрелость процесса					+
Возможность многократного использования	+			+				+
Устойчивость								+
Масштабируемость								+
Безопасность			+				+
Эксплуатационная пригодность			+
Тестируемость	+	+					+
Понятность		+	+
Практичность	+		+	+	+	+	+	+	+

 

 

5. ОПИСАНИЕ МОДЕЛЕЙ ОЦЕНКИ НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ [3]

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

Рисунок 7. Классификационная схема модели надежности программных средств

 

Требования к технологии и средствам автоматизации разработки сложных программных средств

   Для обеспечения качества и надежности ПС стандартами рекомендуется формулировать требования:

u к объекту разработки на данном этапе — к его программным и информационным компонентам, а также к интерфейсу между ними и внешней средой;

u к процессу, технологии и организации выполнения совокупности работ и документов каждого этапа;

u к методам и характеристикам средств автоматизации выполнения работ, обеспечивающим необходимую надежность функционирования и качество ПС;

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

 

   Требования к инструментальным средствам автоматизации разработки надежных ПС наиболее полно изложены в стандарте IEEE 1209-1992.

Рисунок 8 График соотношения между обнаруженными и необнаруженными ошибками

Модель Шумана

 

Модель Шумана строится на основе нескольких критериев:

¾ общее число команд в программе на машинном языке постоянно;

¾  в начале компоновочных испытаний число ошибок равно некоторой постоянной величине, и по мере исправления ошибок их становится меньше. В ходе испытаний программы новые ошибки не вносятся;

¾  ошибки изначально различимы, по суммарному числу исправленных ошибок можно судить об оставшихся;

¾  интенсивность отказов программы пропорциональна числу остаточных ошибок.

Предполагается, что до начала тестирования (т.е. в момент t=0) имеется M ошибок. В течение времени тестирования τ обнаруживается ε₁(t) ошибок в расчете на одну команду в машинном языке.

Тогда удельное число ошибок на одну машинную команду, оставшихся в системе после времени тестирования τ, равно:

 

(1)

 

где I -- общее число машинных команд, которое предполагается постоянным в рамках этапа тестирования.

Предполагается, что значение функции количества ошибок Z(t) пропорционально числу ошибок, оставшихся в программе после израсходованного на тестирование времени τ.

 

Z (t) = C * ε₂ (τ),

 

где С -- некоторая постоянная, t - время работы программы без отказов.

Тогда, если время работы программы без отказа t отсчитывается от точки t = 0, а τ остается фиксированным, функция надежности, или вероятность безотказной работы на интервале от 0 до t, равна

 

(2)

(3)

Нам необходимо найти начальное значение ошибок M и коэффициент пропорциональности С. Эти неизвестные оцениваются путем пропуска функционального теста в двух точках переменной оси отладки t_a и t_в, выбранных так, что ε₁(t_a)<ε₁(t_d).

В процессе тестирования собирается информация о времени и количестве ошибок на каждом прогоне, т.е. общее время тестирования τ складывается из времени каждого прогона:

 

τ = τ₁ + τ₂ + τ₃ + … + τ_n.

 

Предполагая, что интенсивность появления ошибок постоянна и равна λ, можно вычислить ее как число ошибок в единицу времени,

 

(4)

 

где A_i - количество ошибок на i - ом прогоне

Тогда .(5)

 

Имея данные для двух различных моментов тестирования t_a и t_в, можно сопоставить уравнения (3) при τ_a и τ_b:

 

(6)

(7)

 

Из соотношений (6) и (7) найдем неизвестный параметр С и М:

 

(8)

(9)

 

Получив неизвестные M^* и C^*, можно рассчитать надежность программы по формуле (2).

Пример 1.

Программа содержит 2 000 командных строк, из них, до начала эксплуатации (после периода отладки), 15 командных строк содержат ошибки. После 20 дней работы обнаружена 1 ошибка. Найти среднее время безошибочной работы программы и интенсивность отказов программы при коэффициенте пропорциональности, равном 0,7.

I=	2000
M=	15
t=	20
x=	1
C=	0,7

 

E1(t)=	0,0005
E2(t)=	0,007
P(t)=	0,906649
tср=	204,0816
λ=	0,0049	-- интенсивность отказов

 

Пример 2.

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

I=	2000
M=	15
t=	90
x=	1
C=	0,7
P(t)= 0,643393

 

Пример 3.

Определить первоначальное количество возможных ошибок в программе, содержащей 2 000 командных строк, если в течение первых 60 суток эксплуатации было обнаружено 2 ошибки, а за последующие 40 суток была обнаружена одна ошибка. Определить T₀ – среднее время безошибочной работы, соответствующее первому и второму периоду эксплуатации программы и коэффициент пропорциональности.

I=	2000
t1=	60 суток
t2=	100 суток
x1=	2 ошибок
x2=	3 ошибок
T0=	30,333333
λ1= 0,033333
λ2=	0,03
C=	6,666667
E1(t1)=	0,001
E2(t2)=	0,0015
M=	12
Л2/Л1=	0,9

 

 

Модель Миллса

 

Использование этой модели предполагает необходимость перед началом тестирования искусственно «засорять» программу, т.е вносить в нее некоторое количество известных ошибок. Ошибки вносятся случайным образом и фиксируются в протоколе искусственных ошибок. Специалист, проводящий тестирование, не знает ни количества, ни характера внесенных ошибок до момента оценки показателей надежности по модели Миллса. Предполагается, что все ошибки (как естественные, так и искусственно внесенные) имеют равную вероятность быть найденными в процессе тестирования.

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

N =

Дает возможность оценить первоначальное число ошибок в программе N. Здесь S – количество искусственно внесенных ошибок; n – число найденных собственных ошибок; V – число обнаруженных к моменту оценки искусственных ошибок.

 

Модель Джелински-Моранды

 

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

Функция плотности распределения времени обнаружения i-й ошибки, отсчитываемого от момента выявления (i – 1)-й ошибки, имеет вид

 

)

 

Где  – интенсивность отказов, которая пропорциональна числу еще не выявленных ошибок в программе:

 

 

Где N – число ошибок, первоначально присутствующих в программе; С – коэффициент пропорциональности.

Наиболее вероятные значения величин N и С определяются на основе данных, полученных при тестировании. Для этого фиксируют время выполнения программы до очередного отказа t1,t2,t3,…,tk. Значения N и С можно получить, решив систему уравнений

Где Q = ; A = ; B = .

Чтобы получить числовые значения λ, нужно подставить вместо N и С их возможные значения N и C. Рассчитав К значений по формуле (5) и подставив их в выражение (4), можно определить вероятность безотказной работы на различных временных интервалах.

 

Модель Липова

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

Где m – количество используемых тестов, q – вероятность обнаружения ошибки в каждом из m тестов, рассчитанная по формуле ; S – общее количество искусственно внесенных ошибок; N – количество собственных ошибок, имеющихся в ПО до начала тестирования.

 

6. МЕТРИКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ [4]

 

Критерий должен

· численно характеризовать основную целевую функцию программы;

· обеспечивать возможность определения затрат, необходимых для достижения требуемого уровня качества, а также степени влияния на показатель качества различных внешних факторов;

· быть по возможности простым, хорошо измеримым и иметь малую дисперсию.

Для измерения характеристик и критериев качества используют метрики.

Метрика качества программ - система измерений качества программ. Эти измерения могут проводиться на уровне критериев качества программ или на уровне отдельных характеристик качества. В первом случае система измерений позволяет непосредственно сравнивать программы по качеству. При этом сами измерения не могут быть проведены без субъективных оценок свойств программ. Во втором случае измерения характеристик можно выполнить объективно и достоверно, но оценка качества ПО в целом будет связана с субъективной интерпретацией получаемых оценок.

 

 

МЕТРИЧЕСКИЕ ШКАЛЫ

В зависимости от характеристик и особенностей применяемых метрик им ставятся в соответствие различные измерительные шкалы.

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

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

Интервальной шкале соответствуют метрики, которые показывают не только относительное положение программ, но и то, как далеко они отстоят друг от друга.

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

 

 

МЕТРИКИ СЛОЖНОСТИ ПРОГРАММ

При оценке сложности программ, как правило, выделяют три основные группы метрик:

· метрики размера программ · метрики сложности потока управления программ · метрики сложности потока данных программ

.

 

МЕТРИКИ РАЗМЕРА ПРОГРАММ

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

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

К группе оценок размера программ можно отнести также и метрику Холстеда.

 

Метрика Холстеда

Основу метрики Холстеда составляют четыре измеряемых характеристики программы:

n1 - число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов);n2 - число уникальных операндов программы (словарь операндов);N1 - общее число операторов в программе;N2 - общее число операндов в программе.

Опираясь на эти характеристики, получаемые непосредственно при анализе исходных текстов программ, М. Холстед вводит следующие оценки:

словарь программы

n1=n1+n2,длину программыN=N1+N2,                                                                              (1)объем программыV=N*log2(n) (бит).                                                                             (2)

Под битом подразумевается логическая единица информации - символ, оператор, операнд.

Далее М. Холстед вводит n* - теоретический словарь программы, т.е. словарный запас, необходимый для написания программы, с учетом того, что необходимая функция уже реализована в данном языке и, следовательно, программа сводится к вызову этой функции. Например, согласно М. Холстеду, возможное осуществление процедуры выделения простого числа могло бы выглядеть так:

CALL SIMPLE (X,Y),где Y - массив численных значений, содержащий искомое число X.Теоретический словарь в этом случае будет состоять изn1*: {CALL, SIMPLE (...)},n1*=2; n2*: {X, Y},n2*=2,а его длина, определяемая какn* = n1* + n2*,будет равняться 4.Используя n*, Холстед вводит оценку V*:V* = n* * log2 n*, (3)

с помощью которой описывается потенциальный объем программы, соответствующий максимально компактному тексту программы, реализующей данный алгоритм.

 

 

Метрика Маккейба

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

Для вычисления цикломатического числа Маккейба Z(G) применяется формула

              Z(G)=e-v+2p,где e - число дуг ориентированного графа G;v - число вершин;p - число компонентов связности графа.

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

По сути Z(G) определяет число линейно независимых контуров в Сильно связном графе. Иначе говоря, цикломатическое число Маккейба показывает требуемое количество проходов для покрытия всех контуров сильно связного графа или количество тестовых прогонов программы, необходимых для исчерпывающего тестирования по критерию "работает каждая ветвь".

Для программы, граф которой изображен на рис.1, цикломатическое число при e=10, v=8, p=1 определится как Z(G)=10-8+2=4.

Цикломатическое число зависит только от количества предикатов, сложность которых при этом не учитывается. Например, имеется два оператора условия:

IF X>0THEN X=A;ELSE;иIF (X>0 & FLAG='1'B)!(X=0 & FLAG='0'B)THEN X=A;ELSE;

Оба оператора предполагают единственное ветвление и могут быть представлены одним и тем же графом (рис. 2). Очевидно, цикломатическое число будет для обоих операторов одинаковым, не отражающим сложности предикатов, что весьма существенно при оценке программ.

 

 

Метрика Майерса

Исходя из этого Г. Майерс предложил расширение этой метрики. Суть подхода Г. Майерса состоит в представлении метрики сложности программ в виде интервала [Z(G), Z(G)+h]. Для простого предиката h=0, а для n-местных предикатов h=n-1. Таким образом, первому оператору соответствует интервал [2,2], а второму - [2,6].

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

 

 

Метрика Джилба

Одной из наиболее простых, но, как показывает практика, достаточно эффективных оценок сложности программ является метрика Т. Джилба, в которой логическая сложность программы определяется как насыщенность программы выражениями типа IF-THEN-ELSE. При этом вводятся две характеристики: CL - абсолютная сложность программы, характеризующаяся количеством операторов условия; cl - относительная сложность программы, характеризующаяся насыщенностью программы операторами условия, т. е. cl определяется как отношение CL к общему числу операторов.