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

Далее вводится значение метрики Чепина:

(10)

где - весовые коэффициенты.

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

 (11)

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

Метрика Кафура

Метрика также основанная на учёте потока данных программы. Вводятся понятия локального и глобального потока:

Локальный поток информации из A в B существует, если:

· Модуль А вызывает модуль В (прямой локальный поток)

· Модуль В вызывает модуль А и А возвращает В значение, которое используется в В (непрямой локальный поток)

· Модуль С вызывает модули А, В и передаёт результат выполнения модуля А в В

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

I = length * (fan_in * fan_out)^2

Здесь:

· length - сложность текста процедуры (меряется через какую-нибудь из метрик объёма, типа метрик Холстеда, Маккейба, LOC и т.п.)

· fan_in - число локальных потоков внутрь процедуры плюс число структур данных, из которых процедура берёт информацию

· fan_out - число локальных потоков из процедуры плюс число структур данных, которые обновляются процедурой

Можно определить информационную сложность модуля как сумму информационных сложностей входящих в него процедур. Следующий шаг - рассмотреть информационную сложность модуля относительно некоторой структуры данных. Информационная мера сложности модуля относительно структуры данных:

J = W * R + W * WrRd + WrRd x R + WrRd * (WrRd - 1)

Здесь:

· W - число процедур, которые только обновляют структуру данных;

· R - Только читают информацию из структуры данных;

· WrRd - и читают, и обновляют информацию в структуре данных

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

(12)

где - количество комментариев в программе; - количество строк или операторов исходного текста.

Таким образом, метрика отражает насыщенность программы комментариями.

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

Более удачен вариант, когда вся программа разбивается на n равных сегментов и для каждого из них определяется :

- (13)

при этом:

(14)

Уровень комментированности программы считается нормальным, если выполняется условие: . В противном случае какой-либо фрагмент программы дополняется комментариями до номинального уровня.

Следующая метрика Холстеда измеряет теоретическую длину программы используя аппроксимирующую формулу:

(15)

где - словарь операторов; - словарь операндов программы.

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

a) последующая операция уничтожает результаты предыдущей без их использования;

b) присутствуют тождественные выражения, решающие совершенно одинаковые задачи;

c) одной и той же переменной назначаются различные имена и т.п.

Подобные ситуации приводят к изменению без изменения .

Для стилистически корректных программ отклонение в оценке теоретической длины от реальной N не превышает 10%.

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

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

Вариант 1

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

Вариант 2

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

Вариант 3.

Оценить сложность программы, используя метрику сложности потока данных программ - спен.

Вариант 4

Оценить сложность программы, используя метрику сложности потока данных программ - метрику Чепина.

Вариант 5

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

Вариант 6

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

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

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

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

3. Дать определение спена программы.

4. В чем состоит суть метрики Чепина?

5. Определить метрику Кафура, основанную на учете потока данных программы.

6. Какие программы являются потенциально корректными?

7. Какие ситуации в программе можно считать несовершенствами (стилистическими ошибками)?

8. Какой уровень комментированности программы принято считать достаточным?

9. Что такое теоретическая длина программы?

6. Разработка программ оценки сложности по на базе отдельных метрик сложности программ - метрик стилистики, и понятности программ

Лабораторная работа № 6

Цель работы: Изучить метрики стилистики и понятности программ.

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

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

 (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 с коэффициентом пропорциональности .

В принципе импульсное изменение длины документа присутствует и при aibi. Поэтому с учетом (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

...