Метрики. Работа проверена рецензент

Метрики. Работа проверена рецензент

Метрики. Работа проверена рецензент

Метрики. Работа проверена рецензент

Метрики. Работа проверена рецензент

Метрики. Работа проверена рецензент

ЛАБОРАТОРНАЯ РАБОТА №1

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

тема: «Метрика Холстеда»

1МЕТРИКА ХОЛСТЕДА ДЛЯ ОЦЕНКИ СЛОЖНОСТИ ПРОГРАММ 3

2ПРОЦЕСС РАСЧЁТА МЕТРИКИ 4

3АНАЛИЗ ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ 8

1 МЕТРИКА ХОЛСТЕДА ДЛЯ ОЦЕНКИ СЛОЖНОСТИ ПРОГРАММ 4

2 ПРОЦЕСС РАСЧЁТА МЕТРИКИ 5

3 АНАЛИЗ ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ 9

ГБ19-03Б, Миникаев А.Н., Лабораторная работа 2.docx5 лабораторная работа.docxИнф. техн. в экономике лабораторная — 2 семестр мму.docxИнформатика и программирование. Лабораторная работа 1.docxАлгоритмы и структуры данных лабораторная 1.docxИТ лабораторная №3 отчёт-2.docxЦифровая культура. Лабораторная работа №1.docxГБ19-03Б, Миникаев А.Н., Лабораторная работа 4.docx1 лабораторная работа (английская) (1).pdf1 лабораторная.docx

Лабораторная № 6. Метрики Холстеда В общем случае применение метрик позволяет руководителям проектов и предприятий изучить сложность разработанного или даже разрабатываемого проекта, оценить объем работ, стилистику разрабатываемой программы и усилия, потраченные каждым разработчиком для реализации того или иного решения. Однако метрики могут служить лишь рекомендательными характеристиками, ими нельзя полностью руководствоваться, так как при разработке ПО программисты, стремясь минимизировать или максимизировать ту или иную меру для своей программы, могут прибегать к хитростям вплоть до снижения эффективности работы программы. Кроме того, если, к примеру, программист написал малое количество строк кода или внес небольшое число структурных изменений, это вовсе не значит, что он ничего не делал, а может означать, что дефект программы было очень сложно отыскать. Последняя проблема, однако, частично может быть решена при использовании метрик сложности, т.к. в более сложной программе ошибку найти сложнее. Метрика Холстеда относится к метрикам, вычисляемым на основании анализа числа строк и синтаксических элементов исходного кода программы. Основу метрики Холстеда составляют четыре измеряемые характеристики программы: • NUOprtr (Number of Unique Operators) — число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов); • NUOprnd (Number of Unique Operands) — число уникальных операндов программы (словарь операндов); • Noprtr (Number of Operators) — общее число операторов в программе; • Noprnd (Number of Operands) — общее число операндов в программе. На основании этих характеристик рассчитываются оценки: (Halstead Program Vocabulary, HPVoc): HPVoc = NUOprtr + NUOprnd; Длина программы (Halstead Program Length, HPLen): HPLen = Noprtr + Noprnd; Объем программы (Halstead Program Volume, HPVol): HPVol = HPLen log2 HPVoc;

(Halstead Difficulty, HDiff): HDiff = (NUOprtr/2) × (NOprnd / NUOprnd); На основе показателя HDiff предлагается оценивать усилия программиста при разработке при помощи показателя HEff (Halstead Effort): HEff = HDiff × HPVol. Задание Сравнить все 3 программы на 5 языках по метрике Холстеда.

ЦЕЛЬ РАБОТЫ И ЗАДАНИЕ

Для выполнения лабораторной работы № 1 студент должен изучить приведённый ниже теоретический материал на тему «Метрика Холстеда». Для вычисления параметров метрики Холстеда необходимо подсчитать число используемых в программе операторов и операндов (общее число и число различных). Далее в соответствии с формулами из теоретического материала рассчитать все метрические параметры. Отчёт сдаётся в электронном (файл Word) виде.

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

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

– общее число операторов в программе

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

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

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

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

Программа 1.Найти наименьшее число2222

Таблица 1 – Операторы и операнды программы 1

Таблица 2 – Операторы и операнды программы 2

Таблица 3 – Операторы и операнды программы 3

Таблица 4 – Сводная таблица характеристик метрики Холстеда

Теоретический словарь программы

Потенциальный объем программы

Теоретическая длина программы

Уровень качества программирования

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

Интеллектуальное содержание алгоритма

Средний коэффициент сложности

Количество элементарных решений

Рисунок 1 – Сравнение характеристик метрики Холстеда между 3 программами

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

Практическая работа к разделу 2.1.docxКурсовая работа.docxпрактическая работа 3.docxКурсовая работа Лариса.odtПрактическая работа.docxКонтрольная работа ОТК.docxСамостоятельная работа по теме 2.3.docxСамостоятельная работа 3.1.docxПрактическая работа.docxСамостоятельная работа 1.2.docx

Метрики программного продукта включают:

  • внешние метрики, обозначающие свойства продукта, видимые пользователю;
  • внутренние метрики, обозначающие свойства, видимые только команде разработчиков.

Внешние метрики продукта — это метрики:

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

Внутренние метрики продукта включают:

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

Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования и управления достижением качества конечного программного продукта.

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

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

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

Читать также:  DLL-Files Fixer3.3.91

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

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

  • общее время разработки и отдельно время для каждой стадии;
  • время модификации моделей;
  • время выполнения работ на процессе;
  • число найденных ошибок при инспектировании;
  • стоимость проверки качества;
  • стоимость процесса разработки.

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

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

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

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

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

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

1.3.3 Метрики сложности программ

Теория сложности программ ориентирована на управление качеством ПО и контроль ее эталонной сложности в период эксплуатации. В настоящее время многообразие показателей (в той или иной степени описывающих сложность программ) столь велико, что для их употребления требуется предварительное упорядочение. В ряде случаев удовлетворяются тремя категориями метрик сложности. Первая категория определяется как словарная метрика, основанная на метрических соотношениях Холстеда, цикломатических мерах Мак-Кейба и измерениях Тейера. Вторая категория ориентирована на метрики связей, отражающих сложность отношений между компонентами системы — это метрики Уина и Винчестера. Третья категория включает семантические метрики, связанные с архитектурным построением программ и их оформлением.

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

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

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

Метрики второй группы базируются на анализе управляющего графа программы. Представителем данной группы является метрика Мак-Кейба.

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

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

1 112 2 22 * 2 12c *12 2**2* 22*

1 0 0 p

— (Т — 1 + 1) t

1-l — (i-1) )t1i-1

1- F( N — 1 + 1) ti2 / 2

1+++-(N — i + 1) a

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

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

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

Первой топологической мерой сложности является цикломатическая мера Мак-Кейба. В ее основе лежит идея оценки сложности ПО по числу базисных путей в ее управляющем графе, т.е. таких путей, компонуя которые можно получить всевозможные пути из входа графа в выходы. Цикломатическое число (G) орграфа G с n-вершинами, m-дугами и p-компонентами связности есть величина (G) = m — n + p. Практически цикломатическая сложность ПО равна числу предикатов плюс единица, что позволяет вычислять ее без построения управляющего графа простым подсчетом предикатов. Данная мера отражает психологическую сложность ПО.

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

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

Мера Пивоварского ставит целью учесть в оценке сложности ПО различия не только между последовательными и вложенными управляющими конструкциями, но и между структурированными и неструктурированными программами. Она выражается отношением N(G) = *(G) +  Pi , где  *(G) — модифицированная цикломатическая сложность, вычисленная так же, как и V(G), но с одним отличием: оператор CASE с n- выходами рассматривается как один логический оператор, а не как n-1 операторов. Рi — глубина вложенности i — той предикатной вершины.

Читать также:  Аникеева О. А, Чернолецкая Анна К

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

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

Тестирующей мерой М называется мера сложности, удовлетворяющая следующим условиям:

  • М (if P then F1 else F2) = 2 MAX (M (F1), M (F2));
  • М (while P do F) = 2 M(F).

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

Топологическая мера Чена выражает сложность программы числа пересечений границ между областями, образуемыми блок — схемой программы. Этот подход применим только к структурированным программам, допускающим лишь последовательное соединение управляющих конструкций. Для неструктурированных программ мера Чена существенно зависит от условных и безусловных переходов. В этом случае можно указать верхнюю и нижнюю границы меры. Верхняя — есть m+1, где m — число логических операторов при их гнездовой вложенности. Нижняя — равна 2. Когда управляющий граф программы имеет только одну компоненту связности, мера Чена совпадает с цикломатической мерой Мак-Кейба.

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

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

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

1.3.4 Объектно-ориентированные метрики

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

  • NUOprtr (Number of Unique Operators) — число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов);
  • NUOprnd (Number of Unique Operands) — число уникальных операндов программы (словарь операндов);
  • Noprtr (Number of Operators) — общее число операторов в программе;
  • Noprnd (Number of Operands) — общее число операндов в программе.

n1 — количество различных операторов программы;

n2 — количество различных операндов программы;

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

N2 — общее количество операндов программы.

На их основе Холстед определяет следующие метрики:

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

Несовершенствами можно считать следующие ситуации:

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

Предлагается использовать Ñ как эталонное значение длины программы со словарем n. Длина корректно составленной программы N, т. е. программы, свободной от избыточности и имеющей словарь n, не должна отклоняться от теоретической длины программы Ñ более чем на 10%. Таким образом, измеряя n1, n2, N1 и N2 и сопоставляя значения N и Ñ для некоторой программы, при более чем 10%-ном отклонении можно говорить о наличии в программе стилистических ошибок, т. е. несовершенств.

На практике N и Ñ часто существенно различаются.

где n2* — общее число входных и выходных параметров.

Исходным для введения этой характеристики является предположение о том, что при снижении стилистического качества программирования уменьшается содержательная нагрузка на каждый компонент программы и, как следствие, расширяется объем реализации исходного алгоритма. Учитывая это, можно оценить качество программирования на основании степени расширения текста относительно потенциального объема V*. Очевидно, для идеальной программы L=1, а для реальной — всегда L<1.

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

L* = 2  n2 / (n1  N2)

Преобразуя выражение (8) с учетом (6), получаем

I = L*  V = LV = V*V/V = V*.

Эквивалентность I и V* свидетельствует о том, что мы имеем дело с характеристикой информативности программы.

Введение характеристики I позволяет определить умственные затраты на создание программы. Процесс создания программы условно можно представить как ряд операций:

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

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

E характеризует число требуемых элементарных решений при написании программы.

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

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

Читать также:  Ответы что делать если пишет ''Прекращена работа программы ''pythonw.exe'' ''?

E* = N  log2 (n / L)

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

Преобразуя формулу (9) с учетом выражений (4) и (6), получаем

E = V  V / V*

Такое представление E’, а соответственно и E, так как E=E’, наглядно иллюстрирует целесообразность разбиения программ на отдельные модули, поскольку интеллектуальные затраты оказываются пропорциональными квадрату объема программы, который всегда больше суммы квадратов объемов отдельных модулей.

или Т(n1N2log2n(n1log2n1+n2log2n2))/(2n2S), (11)

где S — число Страуда (5

Модели надежности программных комплексов

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

Одна из моделей основана на следующих допущениях:

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

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

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

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

На основе этих допущений получаем:

где t – продолжительность отладки программы, отсчитываемая от момента начала компоновки системы программного обеспечения;

– отношение числа ошибок E0, имеющихся в программе в момент t = 0, к общему числу команд на машинном языке I, т. е.

– суммарное число ошибок, исправленных к моменту времени t, отнесённое к общему числу команд I.

Используя последнее допущение, имеем:

где t –время работы системы;

– интенсивность отказов в течение интервалов времени t;

Ks – коэффициент пропорциональности,

Определив с помощью формулы (5.2) интенсивность отказов программы (частоту появления ошибок), найдём выражение для вероятности безошибочной работы:

Поскольку в данной модели частота появления ошибок считается независящей от времени t, она принимается постоянной и, следовательно, среднее время безошибочной работы программы равно:

Для оценки параметров модели подставим соотношение (5.1) в формулу (5.4), получим следующие выражение для среднего времени безошибочной работы:

Выражение (5.5) содержит два неизвестных параметра – Кs и Ео, которые можно оценить, используя метод согласования моментов. Рассматривая два периода откладки программы t1 и t2, такие, что t1 < t2, получаем:

где t1 и t2 – продолжительность работы системы;

m1 и m2 – число ошибок в программном обеспечении, обнаруженных соответственно в периодах t1 и t2.

Из отношений (5.6) и (5.7) следует, что

T0i – среднее время безошибочной работы, соответствующее периоду откладки программы и определяемое как T0i = ti / mi.

на T1 в формуле (5.6), найдем Ks:

Другим методом оценивания параметров E0 и Ks является использование оценок максимального правдоподобия.

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

В соответствии с выражением (5.2), найдем интенсивность отказов программы

= 0,7∙(15/2000 – 1/2000) = 0,0049 1/сут.

В соответствии с выражением (5.4), найдем среднее время безошибочной работы программы.

= 1/0,0049 = 200 сут.

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

Вероятность безошибочной работы программы в течение 90 суток, в соответствии с выражением (5.3), равно

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

В соответствии с выражением (5.8), находим первоначальное количество возможных ошибок в программе:

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

Коэффициент пропорциональности находится по формуле (5.9):

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

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

– коэффициент пропорциональности;

t – интервал времени между i -й и (i -1)-й обнаруженными ошибками.

С помощью формулы (5.10) можно найти вероятность безошибочной работы:

и среднее время безошибочной работы:

Интервал времени между 3-й и 4-й обнаруженными ошибками в программе, состоящей из 2 000 командных строк, был равен 50 суткам. Коэффициент пропорциональности равен 0,005. Общее количество ошибок в начале эксплуатации составляет 15 штук. Определить частоту появления ошибок, вероятность безошибочной работы и среднее время безошибочной работы.

Частота появления ошибок определяется из выражения (5.10):

Вероятность безошибочной работы можно найти из выражения (5.11):

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

где t1 –промежуток времени между(i-1)-й и i -й ошибками.

Вероятность безошибочной работы равна:

Среднее время безошибочной работы определяется по формуле:

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

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

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

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

Не забудь поделиться страницей с друзьями:

ЗАКЛЮЧЕНИЕ

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *