Глазов 2011

Кафедра информатики, теории и методики обучения информатике

Курсовая работа по информатике

М.С. Ситникова

студентка 4 курса факультета информатики, физики и математики

специальность 010503.65 - «Математическое обеспечение и

администрирование информационных систем»

Тема: Метрики качества программного обеспечения

Научный руководитель – кандидат

технических наук, доцент

А.Г. Шкляев

Работа защищена "____"__________________2011г.

с оценкой ___________________

Глазов 2011

Оглавление

Введение……………………………………………………………….3

1. Качество программного обеспечения……………………………….5

1.1 Понятие качества ПО……………………………………………..5

1.2 Стандартизация характеристик качества……………………….7

1.3 Выбор показателей качества……………………………………..8

1.4 Оценка качества…………………………………………………...8

1.5 Модель качества программного обеспечения………………….11

2. Метрики качества программного обеспечения…………………….12

2.1 Основные направления применения метрик…………………...12

2.2 Метрические шкалы……………………………………………...13

2.3 Модели оценки надежности……………………………………...14

2.4 Классификация моделей надежности……………………………16

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

Метрика Мак-Кейба……………………………………………….18

Метрика Джилба…………………………………………………..19

Метрика граничных значений……………………………………19

Модель Нельсона………………………………………………….21

Простая интуитивная модель…………………………………….21

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

Модель Коркорэна………………………………………………..24

Модель Шумана…………………………………………………..25

2.5 Марковские и пуассоновские модели надежности……………..30

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

Модель Шика-Вулвертона……………………………………….33

Модель Гоело-Окумото…………………………………………..34

Заключение……………………………………………………………36

Литература……………………………………………………………37

Введение

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

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

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

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

Для обеспечения качества программного обеспечения существует ГОСТ 9126-93. Настоящий стандарт определяет шесть характеристик, которые с минимальным дублированием описывают качество программного обеспечения. Данные характеристики образуют основу для дальнейшего уточнения и описания качества программного обеспечения. Руководства описывают использование характеристик качества для оценки качества программного обеспечения.

Стандарт не определяет подхарактеристики (комплексные показатели) и показатели, а также методы измерения, ранжирования и оценки. Данный стандарт придерживается определения качества по ИСО 8402.

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

Предметом исследования данной работы являются метрики качества программного обеспечения, а объектом – качество программных средств.

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

Поэтому в процессе выполнения работы необходимо было решить следующие задачи:

1. Дать определение качества программного обеспечения;

2. Описать характеристики и назначения основных метрик качества ПО;

3. Привести примеры задач, используя данные метрики;

4. Сделать выводы по курсовой работе.

Основное содержание курсовой работы изложено в двух пунктах.

Все выводы по проделанной работе сформулированы в «Заключении».

1. Качество программного обеспечения

1.1 Понятие качества ПО

Очень часто люди, работающие с компьютером, сталкиваемся с достаточно абстрактным понятием «качество программного обеспечения» и если задать вопрос тестировщику или программисту – «что такое качество?», то у каждого найдется своё толкование. В контексте международных стандартов определение "качества программного обеспечения" тоже рассматривается по-разному:

[1061-1998 IEEE Standard for Software Quality Metrics Methodology]

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

[ISO 8402:1994 Quality management and quality assurance]

Качество программного обеспечения - это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

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

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

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

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

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

1.2 Стандартизация характеристик качества

Одной из важнейших проблем обеспечения качества программных средств является формализация характеристик качества и методология их оценки. Для определения адекватности качества функционирования, наличия технических возможностей программных средств к взаимодействию, совершенствованию и развитию необходимо использовать стандарты в области оценки характеристик их качества. Основой регламентирования показателей качества программных средств ранее являлся международный стандарт ISO 9126:1991 (ГОСТ Р ИСО / МЭК 9126-93) "Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению".

Первая часть стандарта - ISO 9126-1 - распределяет атрибуты качества программных средств по шести характеристикам, используемым в остальных частях стандарта. Так же даются определения с уточнениями из остальных его частей для каждой характеристики программного средства.

Вторая и третья части стандарта - ISO 9126-2 и ISO 9126-3 - посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных программных средств. Все таблицы содержат унифицированную рубрикацию, где отражены имя и назначение метрики; метод ее применения; способ измерения, тип шкалы метрики; тип измеряемой величины; исходные данные для измерения и сравнения; а также этапы жизненного цикла программного средства (по ISO 12207), к которым применима метрика.

Четвертая часть стандарта - ISO 9126-4 - предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества программных средств. В ней обосновываются и комментируются выделенные показатели сферы использования программных средств и группы выбранных метрик для пользователей.

1.3 Выбор показателей качества

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

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

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

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

1.4 Оценка качества

На основании ГОСТ 9126-1 существует шесть показателей качества ПО: функциональность, надежность, эффективность, практичность, сопроводимость, мобильность.

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

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

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

Оценка защищенности программных средств включает определение полноты использования доступных методов и средств защиты программного средства от потенциальных угроз и достигнутой при этом безопасности функционирования информационной системы. Наиболее широко и детально методологические и системные задачи оценки комплексной защиты информационных систем изложены в трех частях стандарта ISO 15408:1999-1--3 "Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий".

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

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

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

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

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

1.5 Модель качества программного обеспечения

На данный момент наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO 9126. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки (рис.1).

Рис.1 – Модель качества программного обеспечения (ISO 9126-1)

2. Метрики качества программного обеспечения

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

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

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

1. поиск метрик, характеризующих наиболее специфические свойства программ, т.е. метрик оценки самого ПО;

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

По виду информации, получаемой при оценке качества ПО метрики можно разбить на три группы:

1. метрики, оценивающие отклонение от нормы характеристик исходных проектных материалов. Они устанавливают полноту заданных технических характеристик исходного кода;

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

3. метрики, по которым принимается решение о соответствии конечного ПО заданным требованиям. Они позволяют оценить соответствие разработки заданным требованиям.

2.1. Основные направления применения метрик.

В настоящее время в мировой практике используется несколько сотен метрик программ. Существующие качественные оценки программ можно сгруппировать по шести направлениям [1]:

1. оценки топологической и информационной сложности программ;

2. оценки надежности программных систем, позволяющие прогнозировать отказовые ситуации;

3. оценки производительности ПО и повышения его эффективности путем выявления ошибок проектирования;

4. оценки уровня языковых средств и их применения;

5. оценки трудности восприятия и понимания программных текстов, ориентированные на психологические факторы, существенные для сопровождения и модификации программ;

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

2.2. Метрические шкалы

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

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

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

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

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

2.3. Модели оценки надежности

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

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

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

Для многих систем (программ и данных) надежность - главная целевая функция реализации. К некоторым типам систем (реального времени, радарные системы, системы безопасности, медицинское оборудование со встроенными программами и др.) предъявляются высокие требования к надежности, такие, как отсутствие ошибок, достоверность, безопасность и др.

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

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

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

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

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

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

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

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

2.4. Классификация моделей надежности

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

Ввиду большого разнообразия моделей надежности разработано несколько подходов к классификации этих моделей [3]. Такие подходы в целом основываются на истории ошибок в проверяемой и тестируемой ПС на этапах ЖЦ. Одной из классификаций моделей надежности ПО является классификация Хетча. В ней предлагается разделение моделей на прогнозирующие, измерительные и оценочные (рис. 2).

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

Например, модель Мотли-Брукса основывается на длине и сложности структуры программы (количество ветвей, циклов, вложенность циклов), количестве и типах переменных, а также интерфейсов. В этих моделях длина программы служит для прогнозирования количества ошибок, например, для 100 операторов программы можно смоделировать интенсивность отказов.

Рис. 10.4. Классификация моделей надежности

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

Модель Холстеда прогнозирует количество ошибок в программе в зависимости от ее объема и таких данных, как число операций и операндов, а также их общее число [2].

n1 - число уникальных операторов программы, включая символы-

разделители, имена процедур и знаки операций (словарь операторов);

n2 - число уникальных операндов программы (словарь операндов);

N1 - общее число операторов в программе;

N2 - общее число операндов в программе.

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

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

n=n1+n2, (1)

длину программы

N=N1+N2, (2)

объем программы

V=N*log2(n) (бит). (3)

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

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

Используя n*, Холстед вводит оценку V*:

V* = n* * log2 n*, (4) с помощью которой описывается потенциальный объем программы, соответствующий максимально компактному тексту программы, реализующей данный алгоритм.

Время программирования программы предлагается вычислять по следующей формуле:

(5),

где S - число Страуда (Холстед принял равным 18 - число умственных операций в единицу времени).

Метрика Мак-Кейба.

Том Мак-Кейб заметил, качество программ зависит от сложности ее потока управления, а не от операторов и операндов как в теории Холстеда.

У Мак-Кейба показатель сложности определяется двумя показателями: цикломатическим числом Z(G) и цикломатической сложностью D(G).

Z(G)=e-V+2p (6), где е – число дуг (переходов) ориентированного графа; V – число вершин (узлов) соответствуют операторам; р – число компонент связности графа (обычно 1).

Цикломатическое число определяет количество линейно-независимых путей в программе (на основании теории графов).

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

Сильно связным называют граф, любые две вершины которого взаимнодостижимы.

Цикломатическая сложность – D(G)=e-V+p (7).

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

Мак-Кейб утверждает, что хорошо структурированные модули имеют цикломатическое число в диапазоне от 3 до 7, а цикломатическое число, равное 10, - разумный верхний предел сложности отдельного модуля, что подтверждается эмпирическими данными.

Если программисты переступают эту границу, им следует или переделать программу, или разбить ее на модули.

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

Пример 1.

Z(G)=e-V+2p; e=8; V=7; p=1; Z(G)=3.