Lektsia_3

1.

Метрики, направления
применения метрик.
Метрики сложности.
Метрики стилистики.

2.

Уровни системы показателей
качества

3.

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

4.

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

5.

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

6.

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

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

13.

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

14.

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

15.

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

16.

Метрика Холстеда
Опираясь на эти характеристики, получаемые
непосредственно при анализе исходных текстов
программ, М. Холстедом введены следующие
оценки:
словарь программы
n=n1+n2,
длина программы
N=N1+N2,
объем программы
V=N*log2(n) (бит).
Под битом подразумевается логическая
единица информации - символ, оператор,
операнд.

17.

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

18.

Метрики сложности потока
управления программ
С помощью этих оценок оперируют либо
плотностью управляющих переходов внутри
программ, либо взаимосвязями этих переходов.
Традиционное представление программ в
виде управляющего ориентированного графа
G=(V,E),
где V - вершины, соответствующие
операторам, а E - дуги, соответствующие
переходам.

19.

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

20.

Метрика Маккейба
Впервые графическое представление программ
было предложено Маккейбом.
Основная метрика сложности - цикломатическая
сложность графа программы или цикломатическое
число Маккейба, характеризующее трудоемкость
тестирования программы.
Z(G)=e-v+2p,
где e - число дуг ориентированного графа G;
v - число вершин;
p - число компонентов связности графа.

21.

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

22.

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

23.

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

24.

Метрика обращения к
глобальным переменным
Пара “модуль – глобальная переменная”
обозначается как (p,r), где p – модуль, имеющий
доступ к глобальной переменной r.
В зависимости от наличия в программе
реального обращения к переменной r формируются
два типа пар “модуль – глобальная переменная” :
фактические и возможные.
Характеристика Aup говорит о том, сколько раз
модули Up действительно получили доступ к
глобальным переменным, а число Pup – сколько
раз они могли бы получить доступ.
Отношение числа фактических обращений к
возможным определяется формулой
Rup=Aup/Pup

25.

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

26.

Метрика обращения к
глобальным переменным
Пример расчета метрики “модуль –
глобальная переменная”.
Пусть в программе имеются 3 глобальные
переменные и 3 подпрограммы. Если
предположить, что каждая подпрограмма имеет
доступ к каждой из переменных, то получается
девять возможных пар, то есть Pup=9.
Пусть первая подпрограмма обращается к
одной переменной, вторая – двум, а третья не
обращается ни к одной переменной.
Тогда Aup=3,
Rup=3/9.

27.

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

28.

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

29.

Метрики стилистики и
понятности программ
• Метрика уровня комментированности
программ
• Метрики Холстеда
• Метрика изменения длины программной
документации

30.

Метрика уровня
комментированности программ
Наиболее простой метрикой стилистики и
понятности программ является оценка уровня
комментированности программы F:
F=Nком/Nстр,
где
Nком - количество комментариев в
программе;
Nстр - количество строк или операторов
исходного текста.
Таким образом, метрика F отражает
насыщенность программы комментариями.

31.

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

32.

Метрики Холстеда
1. Для измерения теоретической длины
программы N^ М. Холстед вводит
аппроксимирующую формулу:
N^ = n1*log2(n1) + n2*log2(n2),
где n1 - словарь операторов;
n2 - словарь операндов программы.

33.

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

34.

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

35.

Метрики Холстеда
2.Другой характеристикой, принадлежащей
к метрикам корректности программ, по
М.Холстеду, является уровень качества
программирования L (уровень программы).
где V и V* определяются
V= N* log2(n) (бит)
V* = n* * log2 n*,

36.

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

37.

Метрики Холстеда
3. Нередко целесообразно определить уровень
программы, не прибегая к оценке ее теоретического
объема, поскольку список параметров программы
часто зависит от реализации и может быть
искусственно расширен.
Это приводит к увеличению метрической
характеристики качества программирования.
Можно аппроксимировать эту оценку выражением,
включающим только фактические параметры, т. е.
параметры реальной программы:
L^ = 2*n2 / (n1*N2).

38.

Метрики Холстеда
4. Располагая характеристикой L^, Холстед
вводит характеристику I, которую
рассматривает как интеллектуальное
содержание конкретного алгоритма,
инвариантное по отношению к используемым
языкам реализации:
I = L^ * V.
Эквивалентность I и V* свидетельствует о
том, что мы имеем дело с характеристикой
информативности программы.

39.

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

40.

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