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

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

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

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

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

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

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

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

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

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

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

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

1) метрики размера программ;

2) метрики сложности потока управления программ;

3) метрики сложности потока данных программ.

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

Оценки первой группы наиболее просты и, очевидно, получили наибольшее распространение. Традиционной характеристикой размера программ является количество строк исходного текста. Однако при этом возникает ряд проблем. Одна из них – что считать строкой? 1) функциональные операторы? 2) операторы объявления переменных и функциональные операторы? 3) все операторы, включая комментарии? В дальнейшем под строкой понимается любой оператор программы, поскольку реально при оценке размера программы используется информация именно о количестве операторов. Это правильно, так как именно оператор, а не отдельно взятая строка является тем интеллектуальным "квантом" программы, опираясь на который можно строить метрики сложности её создания.

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

Размерно – ориентированные метрики (показатели оценки объема) LOC-оценка (Lines Of Code)

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

· общие трудозатраты (в человеко-месяцах, человеко-часах);

· объем программы (в тысячах строках исходного кода -LOC);

· стоимость разработки;

· объем документации;

· ошибки, обнаруженные в течение года эксплуатации;

· количество людей, работавших над изделием;

· срок разработки.

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

Эти метрики не универсальны и спорны, особенно это относится к такому показателю как LOC, который существенно зависит от используемого языка программирования.

Пример:

На наш взгляд оценка по количеству строк в коде влечёт за собой соблазн написать побольше строк, дабы взять побольше денег. Разумеется, об оптимизации в таком продукте никто уже думать не станет. Вспомним историю о том, как планетарный центр аутсорсинга – Индия, после того, как заказчики вменили им метрику LOC, на второй день показал удвоение и утроение строк кода.

Количество строк исходного кода (Lines of Code – LOC, Source Lines of Code – SLOC) является наиболее простым и распространенным способом оценки объема работ по проекту.

Изначально данный показатель возник как способ оценки объема работы по проекту, в котором применялись языки программирования, обладающие достаточно простой структурой: "одна строка кода = одна команда языка". Также давно известно, что одну и ту же функциональность можно написать разным количеством строк, а если возьмем язык высокого уровня (С++, Java), то возможно и в одной строке написать функционал 5-6 строк – это не проблема. И это было бы полбеды: современные средства программирования сами генерируют тысячи строк кода на пустяковую операцию.

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

В зависимости от того, каким образом учитывается сходный код, выделяют два основных показателя SLOC:

1) количество "физических" строк кода – SLOC (используемые аббревиатуры LOC, SLOC, KLOC, KSLOC, DSLOC) – определяется как общее число строк исходного кода, включая комментарии и пустые строки (при измерении показателя на количество пустых строк, как правило, вводится ограничение – при подсчете учитывается число пустых строк, которое не превышает 25% общего числа строк в измеряемом блоке кода).

2) количество "логических" строк кода – SLOC (используемые аббревиатуры LSI, DSI, KDSI, где "SI" – source instructions) – определяется как количество команд и зависит от используемого языка программирования. В том случае, если язык не допускает размещение нескольких команд на одной строке, то количество "логических" SLOC будет соответствовать числу "физических", за исключением числа пустых строк и строк комментариев. В том случае, если язык программирования поддерживает размещение нескольких команд на одной строке, то одна физическая строка должна быть учтена как несколько логических, если она содержит более одной команды языка. Для метрики SLOC существует большое число производных, призванных получить отдельные показатели проекта, основными среди которых являются:

1. число пустых строк;

2. число строк, содержащих комментарии;

3. процент комментариев (отношение строк кода к строкам комментария, производная метрика стилистики);

4. среднее число строк для функций (классов, файлов);

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

6. среднее число строк для модулей.

Итого по SLOC

Потенциальные недостатки SLOC, на которые нацелена критика:

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

· метрика не учитывает опыт сотрудников и их другие качества;

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

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

И главное помнить: метрика SLOC не отражает трудоемкости по созданию программы.

Пример:

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

Гневу руководителя не было предела – нашел бездельника! И плохо было бы программисту, если бы менеджер проекта не объяснил, что была найдена ошибка в программе, нашел ее VIP- клиент, ошибка влияет на бизнес клиента и ее нужно было срочно устранить, для этого был выбран вот этот конкретный исполнитель, который развернул стенд, залил среду клиента, подтвердил проявление ошибки и начал ее искать и устранять. Естественно, в конце концов, он поменял фрагмент кода, в котором было неправильное условие и все заработало.

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

К группе оценок размера программ можно отнести также и метрику Холстеда. За базу принят подсчёт количества операторов и операндов, используемых в программе, то есть определение размера программы.

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

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

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

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

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

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

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

 

(1)

 

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

 

(2)

 

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

 

(3)

 

Смысл оценок и очевиден, поэтому рассмотрим .

Количество символов, используемых при реализации некоего алгоритма, определяется в числе прочих параметров и словарём программы , представляющим собой минимально необходимое число символов, обеспечивающих реализацию алгоритма. Рассматривая эту оценку, некоторые авторы утверждают, что объём программы, выраженной формулой (3), характеризует "число двоичных разрядов, то есть бит, необходимых для записи программы". При этом речь идёт о физической длине программы в битах. Холстед не конкретизирует, что именно понимается под термином бит: логическая единица информации или физическая. Однако из последующих выводов относительно метрических характеристик понятности и уровня программы, в которых М. Холстед оперирует измерением объёма программ, можно сделать вывод, что под битом подразумевается логическая единица информации – символ, оператор, операнд, то есть то, чем непосредственно оперирует программист при создании программ.

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

 

CALL SIMPLE(x,y),

 

где y – массив численных значений, содержащий искомое число х.

Теоретический словарь в этом случае будет состоять из

:{CALL, SIMPLE(…)}, =2

:{x,y}, =2,

 

а его длина, определяемая как

 

, (4)

 

будет равняться 4.

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

 

, (5)

 

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

На основании этих оценок вводятся "производные" характеристики, определяющие уже не размер программы, а её структуру и стилистику.

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

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

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

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

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

В графе программы, где каждому оператору соответствует вершина, то есть не исключены линейные участки, при передаче управления от вершины a и b номер оператора a равен , а номер оператора b – . Точка пересечения дуг появляется, если

 

& |

& . (6)

 

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

 

Рис. 2. Пример точки пересечения дуг графа программы

 

Количество точек пересечения дуг графа программы дает характеристику неструктурированности программы. Эта характеристика хорошо согласуется с определением Маккейба для отклонений от структурного построения программ.

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

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

Вариант 1

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

Вариант 2

Определить размер программы используя метрику Холстеда (за базу принять подсчёт количества операторов и операндов, используемых в программе).

Вариант 3

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

Вариант 4

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

Вариант 5

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

Вариант 6

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

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

1. Что такое метрика программного обеспечения?

2. Дать определение понятия "качество ПО".

3. Дать определение характеристики качества программ.

4. Что такое критерий качества программы?

5. Перечислить характеристики критериев качества ПО?

6. Два основных направления в исследовании метрик ПО.

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

8. Назвать существующие качественные оценки программ.

9. Три основные группы метрик сложности программ.

10. Размерно-ориентированные метрики.

11. Дать понятие метрики М. Холстеда.

12. Дать понятие метрики Т. Джилба.

13. Определить метрику, получившую название "подсчет точек пересечения".