Краткие теоретические сведения и методические указания к выполнению работы

Другой характеристикой, принадлежащей к метрикам корректности программ, по М.Холстеду, является уровень качества программирования (уровень программы):

(16)

где и определяются соответственно выражениями (3) и (5).

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

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

(17)

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

Располагая характеристикой , Холстед вводит характеристику , которую рассматривает как интеллектуальное содержание конкретного алгоритма, инвариантное по отношению к используемым языкам реализации:

(18)

Термин интеллектуальность не совсем удачен. Преобразуя выражение (8) с учётом (16), получаем

=V*V/V=V*.

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

Стабильность информативности программы проверялась при реализации одних и тех же алгоритмов на месте – семи языках программирования. При этом отклонение от среднего не превышало 10%.

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

1) осмысление предложения известного алгоритма;

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

Используя эту формализацию в методике Холстеда, можно сказать, что написание программы по заранее известному алгоритму есть Ň- кратная выборка операторов и операндов из словаря программы η, причем число сравнений (по аналогии с алгоритмами сортировки) составит ~ log2η.

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

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

E=λlog2η/L.

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

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

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

E’=Νlog2η/L.

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

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

Е=V2/V*. (21)

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

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

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

Предположим, что документация изменяется в декретные моменты времени ti, i=1,2,…,n. Тогда в любой момент ti текущая длина документа li может быть определена как

li=li-1+ai-bi ; l0=0. (22)

где li-1 – длина документа в предыдущий момент времени; ai – добавляемая часть документа; bi – исключаемая часть документа.

Далее вводится di, представляющее собой отклонение текущей длины документа li от оконечного значения ln:

di=ln-li. (23)

Затем рассчитывается интервал по модулю этого отклонения на интервале от ti до tn, представленный в виде суммы

= (24)

Значение Hn представляет собой оценку переходного процесса для интервала времени от t1 до tn. Однако Hn не учитывает изменений типа ai = bi, хотя они, бесспорно, влияют на ход дальнейшего процесса.

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

Рис.6 Пример импульсного изменения длины программного документа

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

(25)

Таким образом, оценка длины документа пропорциональна значению импульсного изменения длины ai=bi с коэффициентом пропорциональности .

В принципе импульсное изменение длины документа присутствует и при ai bi. Поэтому с учетом (25) автор метрики преобразует выражение (24) к виду

(26)

причем

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

Тогда сi =0, и выражение (26) вырождается в (24).

Используя конечное значение длины документа, можно записать

(24)

Уточним некоторые моменты, существенные для применения этой метрики на практике.

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

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

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

Выводы

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

2. Исторически сначала были выделены ряд универсальных и неполных метрик на основе следующих шагов:

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

· Выделение кандидатов в метрики, которые измеряют степень удовлетворения указанным характеристикам.

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

· Исследование корреляции между метриками, степени перекрытия, зависимости и недостатков.

· Рафинирование множества метрик в целом во множество метрик, которые в совокупности адекватно отражают качество программного обеспечения.

· Корректировка каждой метрики в итоговом множестве в контексте зафиксированных множеств характеристик и метрик.

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

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

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

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

Задание по работе:

Вариант 1

Посчитать метрику корректности программ, т.е. уровень качества программирования (уровень программы).

Вариант 2

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

Вариант 3

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

Вариант 4

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

Вариант 5

Посчитать оценку Е для определения целесообразности разбиения программы на отдельные модули.

Вариант 6

Рассчитать метрику измерения флуктуации длин программной документации.

Контрольные вопросы

1. Какие метрики можно отнести к метрикам стилистики и понятности программ?

2. Что такое уровень качества программирования?

3. В чем суть метрики корректности программ по М. Холстеду?

4. Привести аппроксимирующую формулу для определения уровня программы.

5. Определить характеристику интеллектуального содержания конкретного алгоритма.

6. Определить характеристику информативности программы.

7. Как можно измерить оценку необходимых интеллектуальных усилий по написанию программы?

Размещено на Allbest.ru