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

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

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

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

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

В современных условиях большинство программных проектов создается на основе ОО подхода, в связи с чем существует значительное количество метрик, позволяющих получить оценку сложности объектно-ориентированных проектов. [10]

Таблица 2

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

Метрика	Описание
1	2
Взвешенная насыщенность класса 1 (Weighted Methods Per Class (WMC))	Отражает относительную меру сложности класса на основе цикломатической сложности каждого его метода. Класс с более сложными методами и большим количеством методов считается более сложным. При вычислении метрики родительские классы не учитываются.
Взвешенная насыщенность	Мера сложности класса, основанная на том, что класс с большим числом методов, является более сложным, и что
класса 2 (Weighted Methods Per Class (WMC2))	метод с большим количеством параметров также является более сложным. При вычислении метрики родительские классы не учитываются.
Глубина дерева наследования (Depth of inheritance tree)	Длина самого длинного пути наследования, заканчивающегося на данном модуле. Чем глубже дерево наследования модуля, тем может оказаться сложнее предсказать его поведение. С другой стороны, увеличение глубины даёт больший потенциал повторного использования данным модулем поведения, определённого для классов-предков.
Количество детей (Number of children)	Число модулей, непосредственно наследующих данный модуль. Большие значения этой метрики указывают на широкие возможности повторного использования; при этом слишком большое значение может свидетельствовать о плохо выбранной абстракции.
Связность объектов (Coupling between objects)	Количество модулей, связанных с данным модулем в роли клиента или поставщика. Чрезмерная связность говорит о слабости модульной инкапсуляции и может препятствовать повторному использованию кода.
Отклик на класс (Response For Class)	Количество методов, которые могут вызываться экземплярами класса; вычисляется как сумма количества локальных методов, так и количества удаленных методов

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 - общее количество операндов программы.

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

· словарь программы (в условных единицах)

n = n1+n2, (1)

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

n^* = n1^* + n2^*

· длина программы (в условных единицах)

N = N1+N2 (2)

· теоретическая длина программы (в условных единицах)

С = (n1 log₂ n1)+(n2log₂ n2), (3)

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

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

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

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

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

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

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

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

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

· объем программы (в битах, определение объема программы предполагает, что обозначение операндов и операторов требует не более одного символа).

V = N log₂(n) (4)

· потенциальный объем программы (полагая, что в программах, идеальных с точки зрения экономии затрат памяти, во-первых: операторы и операнды не повторяются, во-вторых: все операнды являются либо входными, либо выходными параметрами и в-третьих: для записи текста программы достаточно двух операторов (описания заголовка процедуры-функции и присваивания значения))

V^* = n^* log₂ n^* (5)

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

· уровень качества программы (в условных единицах, если n2*=2)

L = V^*/ V (6)

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

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

L^* = 2 n2 / (n1 N2)

· уровень языка - это коэффициент пропорциональности изменения объема программы при переводе с одного языка на другой так, что обеспечивается постоянство произведения уровня программы на потенциальный объем.

=L V^* (7)

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

I=L^* V (8)

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

I = L^* V = LV = V^*V/V = V^*.

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

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

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

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

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

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

· оценка интеллектуальных усилий (в условных единицах)

E = N^* log₂ (n / L) (9)

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

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

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

E^* = N log₂ (n / L)

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

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

E = V V / V^*

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

· время на программирование (в условных единицах)

T = E/S, (10)

или Т(n1N2log2n(n1log2n1+n2log2n2))/(2n2S), (11)

где S - число Страуда (5<S<20).

Число Страуда Холстед принял равным 18 - число умственных операций в единицу времени.

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

Используя выражение для потенциального объема программы, Холстедом получены следующие метрики:

Число Страуда S определяется как число «страудовских моментов» в секунду. «Страудовский момент» - это время, необходимое человеку для выполнения элементарного различения объектов, подобно различению кадров фильма. Страуд обнаружил, что человек способен различать от 5 до 20 объектов в секунду.

Уровень программы L1 характеризует эффективность реализации алгоритма относительно затрат памяти. Только для наиболее сжатой формы реализации алгоритма (V=V*) уровень программы имеет значение 1. Всем другим вариантам реализации соответствуют значения L<1.

Интеллектуальное содержание характеризует меру «сказанного» в программе, или ее «информативность». Интеллектуальное содержание (уровень) программы сильно коррелирует с потенциальным объемом (LV*) и тоже не зависит от языка реализации.

Работа по программированию (уравнение мысленной работы) характеризует величину умственной работы, связанной с написанием программного кода. Так как сумма квадратов двух величин всегда меньше квадрата их суммы, уравнение работы дает основание для разбиения программы на составные части - модули. Модульность снижает работу по программированию. Исследования возможностей оперативного мышления человека дают основания считать, что наиболее продуктивна ситуация, при которой для получения одного результата используется не более пяти объектов. В прикладном отношении этот результат называют гипотезой о «шести объектах». Для определения количества модулей M в программе Холстед рекомендует использовать выражение

M= n2*/6, (12)

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

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

B=LE/E0, (13)

где В - количество ошибок в программе,

Е0 - среднее число элементарных отличий между возможными ошибками программирования.

Используя преобразованное уравнение работы

Е= (V*)3/2, (14)

значение уровня английского языка (=2,16) в качестве аналога языка программирования и гипотезу о «шести объектах» идеальной по затратам памяти программы (n1=n1*=2, n2=n2*=6), Холстед вывел следующее уравнение для прогноза количества ошибок в программе:

В=Е 2/3 /3000, (15)

Или

В=V/3000, (16)

где V - объем программы.

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

1. Наличие последовательности дополняющих друг друга операторов к одному и тому же операнду, например, А+C-А.

2. Наличие неоднозначных операндов, например, A=D и A=С.

3. Наличие синонимичных операндов, например, А=В и Т=В.

4. Наличие общих подвыражений, например (А+В)С+D(А+В).

5. Ненужное присваивание, например С=А+В, если переменная С используется в программе только один раз.

6. Наличие выражений, которые не представлены в свернутом виде как произведение множителей, например XX+2XY+YY не представлено как (X+Y)(X+Y).

7. Длину реализации N (2) можно использовать для прогноза числа фактических машинных команд P с помощью выражения

(17)

или более грубо, с помощью неравенства

2P N 4P. (18)

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

Уровень программы 0L1 можно использовать для оценки сложности вариантов реализации заданного алгоритма D (чем меньше затрат памяти, тем сложнее вариант программы):

(19)

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

L V = V^* = const. (20)

Вместе с тем, если язык не меняется, а меняется только алгоритм, то для любого языка произведение потенциального объема на уровень программы остается постоянной величиной, равной уровню языка [14]

L V = = const. (21)

1.3.6 Метрики цикломатической сложности по Мак-Кейбу

Показатель цикломатической сложности является одним из наиболее распространенных показателей оценки сложности программных проектов. Данный показатель был разработан ученым Мак-Кейбом в 1976 г., относится к группе показателей оценки сложности потока управления программой и вычисляется на основе графа управляющей логики программы (control flow graph). Данный граф строится в виде ориентированного графа, в котором вычислительные операторы или выражения представляются в виде узлов, а передача управления между узлами - в виде дуг.

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

Для вычисления цикломатического числа Мак-Кейба ?(G) применяется формула:

(G) = m - n + 2p,

где m - число дуг ориентированного графа G;

n - число вершин;

p - число компонентов связности графа.

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

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

Упрощенная формула вычисления цикломатической сложности представляется следующим образом:

(G) = m - n + 2

Как правило, при вычислении цикломатической сложности логические операторы не учитываются.

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

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

В физическом смысле цикломатическое число для каждой дуги m=(v, u)| mM графа управления первая вершина (v) является исходной, а вторая (u) - конечной. Путь от одной вершины к другой вершине графа, если он состоит более чем из одной дуги, описывают последовательностью вершин соответствующих дуг (v, а,…, u) так, что исходная вершина будет первой в перечислении, а конечная - последней. Контур - это плоскость, ограниченная циклическим путем, в котором начальная и конечная вершина графа совпадают. Каждому контуру соответствует ограничивающий его путь, ведущий из начальной вершины графа в конечную.

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

В практическом аспекте цикломатическое число является мерой сложности программы и определяет количество тестов, достаточных для тестирования по критерию покрытия всех ветвей программы.

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

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

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

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

Рассмотрим пример. Пусть имеется программа, которая считывает из входного потока символы до тех пор, пока не будет обнаружен символ «#». Текст программы на языке Паскаль представлен на рис 6. Соответствующий граф управления программы показан на рис 7.



Размещено на http://www.allbest.ru/

Рис 6 Программа ввода данных

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



Размещено на http://www.allbest.ru/

Рис 7 Граф управления программы ввода данных

Размещено на http://www.allbest.ru/

Рис 8 Преобразование графа управления программы ввода данных в полносвязный граф

Определим цикломатическое число Маккейба для графа управления программы, изображенного на рис 7. Количество ребер графа равно пяти, количество вершин тоже равно пяти, поэтому цикломатическое число равно:

(G)=5-5+2=2

Программа организации ввода данных, имеющая граф управления с цикломатическим числом, равным 2, не обладает излишней сложностью и для ее тестирования достаточно подобрать два теста, покрывающие ветви (а, b, с) и (а, u) (рис 4). Заметим, что вершины v и а графа управления программы можно объединить, что не приведет к изменению цикломатического числа. Цикломатическое число зависит только от количества управляющих операторов, содержащих условные выражения (предикаты). При этом сложность предиката не учитывается. Если в операторе цикла while программы организации ввода данных (рис 4) усложнить условное выражение (предикат), изменив заголовок

while(s<>'#') на while(s<>'#' or s<>'*') граф управления и цикломатическое число останутся прежними.

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

M=u+1,

где u - количество операторов ветвления.

При необходимости операторы выбора или переключения с n ветвями, можно рассматривать как n операторов ветвления.

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

Модификации показателя цикломатической сложности:

· «Модифицированная» цикломатическая сложность - рассматривает не каждое ветвление оператора множественного выбора (switch), а весь оператор как единое целое.

· «Строгая» цикломатическая сложность - включает логические операторы.

· «Упрощенная» вычисление цикломатической сложности - предусматривает вычисление не на основе графа, а на основе подсчета управляющих операторов.

· «актуальная» сложность - определяется как число независимых путей, которые проходит программа при тестировании;

· метрика сложности глобальных данных - вычисляется как цикломатическая сложность модуля и увеличивается на количество взаимосвязей с глобальными данными.

1.3.7 Метрики Чепина

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

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

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

1. Множество «Р» - вводимые переменные для расчетов и для обеспечения вывода. Примером может служить используемая в программах лексического анализатора переменная, содержащая строку исходного текста программы, то есть сама переменная не модифицируется, а только содержит исходную информацию.

2. Множество «М» - модифицируемые или создаваемые внутри программы переменные.

3. Множество «C» - переменные, участвующие в управлении работой программного модуля (управляющие переменные).

4. Множество «Т» - не используемые в программе (“паразитные”) переменные. Поскольку каждая переменная может выполнять одновременно несколько функций, необходимо учитывать ее в каждой соответствующей функциональной группе.

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

Q = a1P + a2M + a3C + a4T

где a1, a2, a3, a4 - весовые коэффициенты.

Весовые коэффициенты использованы для отражения различного влияния на сложность программы каждой функциональной группы. По мнению автора метрики наибольший вес, равный трем, имеет функциональная группа С, так как она влияет на поток управления программы. Весовые коэффициенты остальных групп распределяются следующим образом: a1=1; a2=2; a4=0.5. Весовой коэффициент группы T не равен нулю, поскольку “паразитные” переменные не увеличивают сложности потока данных программы, но иногда затрудняют ее понимание. С учетом весовых коэффициентов выражение примет вид:

Q = P + 2M + 3C + 0.5T.

1.3.8 Размерно-ориентированные метрики (показатели оценки объема)

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

1.3.8.1 SLOC - оценка (Source Lines Of Code)

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

· количество «физических» SLOC (используемые аббревиатуры: LOC, SLOC, KLOC, KSLOC, DSLOC) - определяется как общее число строк исходного кода, включая комментарии и пустые строки (при измерении показателя на число пустых строк, как правило, вводится ограничение - учитывается их количество, которое не превышает 25% общего числа строк в измеряемом блоке кода);

· количество «логических» SLOC (используемые аббревиатуры: LSI, DSI, KDSI, где SI - Source Instructions) - определяется как число команд и зависит от используемого языка программирования. В том случае, если язык не допускает размещения на одной строке нескольких команд, количество «логических» SLOC будет соответствовать числу «физических» за исключением пустых строк и строк комментариев. Если же язык программирования поддерживает размещение нескольких команд на одной строке, то одна «физическая» строка должна быть учтена как несколько «логических», если она содержит более одной команды языка.

Литера «D» (Delivered) означает «поставленный» код, т. е. только вошедший в законченный программный продукт. Очень часто возникает необходимость учитывать не только поставленный код, но и вспомогательный или промежуточный, который не входит в законченный продукт, но нужен для реализации проекта и требует определенных затрат труда.

Что касается вычисления показателя SLOC, то здесь следует отметить, что не существует единственного общепризнанного подхода, приемлемого для различных языков программирования и ориентированного на универсальное применение. Чаще всего SLOC определяется как общее число строк кода за исключением пустых строк и комментариев. В большинстве случаев подсчитывается именно число «физических» SLOC, и наличие нескольких операторов на одной строке не учитывается. Также отметим, что если в контексте SLOC конкретный язык программирования не называется, это обычно означает, что речь идет о величине, выраженной в базовых единицах, - количестве строк кода языка Basic Assembler. Для сопоставления значений показателя для различных языков программирования применяются специальные таблицы преобразования.

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

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

· оценка показателя SLOC «снизу-вверх» экспертным методом. Этой методикой предусмотрено разбиение проекта на иерархическую структуру задач (Work Breakdown Structure, WBS), на основании которых производится экспертная оценка показателя, в итоге суммируемая для всего проекта. Как правило, экспертами предоставляются три оценки (наиболее вероятная, максимальная и минимальная), а далее они усредняются с помощью бета - распределения (рассчитывается сумма минимальной, максимальной и четырехкратной наиболее вероятной оценок, которая затем делится на шесть).

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

· число пустых строк (Blank Lines Of Code, BLOC);

· число строк, содержащих комментарии (Comment Lines Of Code, CLOC);

· число строк, содержащих исходный код и комментарии (Lines with Both Code and Comments, C&SLOC);

· число строк, содержащих декларативный исходный код;

· число строк, содержащих императивный исходный код;

· процент комментариев (число строк комментариев, умноженное на 100 и деленное на число строк кода);

· среднее число строк для функций (методов);

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

· среднее число строк для модулей;

· среднее число строк для классов.

Также наряду со SLOC применяются другие показатели, отражающие количественную оценку отдельных составляющих проекта: число модулей, функций / методов, классов, страниц документации и пр. Однако помимо метрик, подсчитывающих число элементов проекта, к метрикам размера следует отнести также функциональные точки (Function Points, FP), их производные и разновидности, вычисляемые на базе не исходного кода, а пользовательских требований, спецификаций, описаний прецедентов (например, точки прецедентов, Use Case Points, UCP) и пр. В большинстве случаев главное предназначение этой группы метрик, независимо от способа их вычисления, состоит в том, чтобы оценить объем работ по проекту, и, соответственно, быть основой для таких показателей, как стоимость и длительность его реализации.

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

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

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

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

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

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

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

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

Fi = SIGN (Nкомм. i / Ni - 0,1)

Суть метрики проста: код разбивается на n-равные куски и для каждого из них определяется Fi [5]

1.4 Альтернативные подходы к измерению качества

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

Если попросить группу людей высказать свое мнение по поводу того, что такое качественное ПО, можно получить следующие варианты ответов:

· Легко использовать.

· Хорошая производительность.

· Нет ошибок.

· Не портит пользовательские данные при сбоях.

· Можно использовать на разных платформах.

· Может работать 24 часа в сутки и 7 дней в неделю.

· Легко добавлять новые возможности.

· Удовлетворяет потребности пользователей.

· Хорошо документировано.

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

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

Что делает программу высококачественной:

Шломи Фиш (Shlomi Fish) проанализировал факторы определяющие высокое качество программного обеспечения:

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

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

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

· Программа не должна требовать существенной настройки или дополнительного обучения (изменения привычек).

· Программа должна иметь качественную веб-страницу, где легко найти всю необходимую информацию.

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

· Должны быть легко доступны готовые собранные пакеты или должно быть легко их собрать.

· Программа должна быть хорошо документирована.

· Программа должна быть переносимой (работать на как можно большем количестве распространенных платформ).

· Высококачественная программа должна быть безопасна - это означает что должно быть немного проблем с безопасностью и баги должны исправляться быстро.

· При выходе новых версий должна сохраняться совместимость со старыми.

· Высококачественная программа имеет хорошие пути поддержки пользователей - почтовые рассылки, IRC, техподдержку по email, форумы, wiki.

· Программа должна быть быстрой и не должна потреблять много ресурсов.

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

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

· Код программы должен быть модульным и хорошо написанным.

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

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

· Релизы должны быть частыми.

· Управление проектом должно быть объективным и дальновидным.

· Слишком навязчивая реклама вредна, и совершенно недопустима неправдивая реклама.

· И последнее: хорошее название программы важно.

Качество ПО по МакКолу

Первой широко известной моделью качества ПО стала предложенная в 1977 МакКолом.

В ней характеристики качества разделены на три группы

· Факторы (factors), описывающие ПО с позиций пользователя и задаваемые требованиями.

· Критерии (criteria), описывающие ПО с позиций разработчика и задаваемые как цели.

· Метрики (metrics), используемые для количественного описания и измерения качества.

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

Рис. 9 Треугольник МакКола

Критерии качества - это числовые уровни факторов, поставленные в качестве целей при разработке.

Объективно оценить или измерить факторы качества непосредственно довольно трудно. Поэтому, МакКол ввел метрики качества, которые с его точки зрения легче измерять и оценивать. Оценки в его шкале принимают значения от 0 до 10. Вот эти метрики качества:

· Удобство проверки на соответствие стандартам (auditability)

· Точность управления и вычислений (accuracy)

· Степень стандартности интерфейсов (communication commonality)

· Функциональная полнота (completeness)

· Однородность используемых правил проектирования и документации (consistency)

· Степень стандартности форматов данных (data commonality)

· Устойчивость к ошибкам (error tolerance)

· Эффективность работы (execution efficiency)

· Расширяемость (expandability)

· Широта области потенциального использования (generality)

· Независимость от аппаратной платформы (hardware independence)

· Полнота протоколирования ошибок и других событий (instrumentation)

· Модульность (modularity)

· Удобство работы (operability)

· Защищенность (security)

· Самодокументированность (selfdocumentation)

· Простота работы (simplicity)

· Независимость от программной платформы (software system independence)

· Возможность соотнесения проекта с требованиями (traceability)

· Удобство обучения (training)

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

Качество ПО по Боему

В 1978 Боем предложил свою модель, по существу представляющую собой расширение модели МакКола.

Атрибуты качества подразделяются по способу использования ПО (primary use).

Определено 19 промежуточных атрибутов (intermediate construct), включающих все 11 факторов качества по МакКолу. Промежуточные атрибуты разделяются на примитивные (primitive construct), которые, в свою очередь, могут быть оценены на основе метрик.

В дополнение к факторам МакКола атрибуты качества по Боему включают следующие: ясность (clarity), удобство внесения изменений (modifiability), документированность (documentation), способность к восстановлению функций (resilience), понятность (understandability), адекватность (validity), функциональность (functionality), универсальность (generality), экономическая эффективность (economy). [13]

1.5 Оценка результата

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

1.5.1 Линейный подход

В простейшем случае определить стоимость разработки ПО можно исходя из количественной оценки трудозатрат Т (в неких единицах, например человеко-месяцах или человеко-часах) и их удельной стоимости Ц:

С = Т Ч Ц.

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

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

Т = Р Ч П,

где Р - размер исходного кода ПО; П - временная производительность.

Эта примитивная формула активно применяется и по сей день, хотя ее несостоятельность была установлена довольно давно. Пожалуй, самой известной работой, в которой критикуется данный подход, является выдержавшая более двадцати изданий по-настоящему классическая книга Фредерика Брукса (Frederick Brooks) «Мифический человеко-месяц, или Как создаются программные системы», впервые увидевшая свет еще в 1977 г.

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

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

1.5.2 Оценка с использованием эмпирических данных

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

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

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

Вероятно, первой нелинейной моделью, использующей эмпирические данные и нашедшей практическое применение при оценке стоимости ПО, стала SLIM (Software Life-cycle Model), предложенная в 1978 г. Лоуренсом Патнамом (Lawrence Putnam). Согласно ей трудоемкость вычисляется по следующей формуле:

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

SLIM была создана на базе реальных данных, собранных в Министерстве обороны США, и ориентирована в первую очередь на крупные проекты. Несмотря на возможность калибровки модели на основе хронологической информации, что несколько повышает качество результатов, она не приобрела широкой популярности, хотя существуют организации, успешно использующие ее в проектном менеджменте и сегодня (qsm.com).

COCOMO. Пожалуй, самой популярной моделью для оценки стоимости разработки ПО, которая стала стандартом, является COCOMO (COnstructive COst MOdel). Она была представлена в 1981 г. Барри Боэмом (Barry Boehm), известным ученым, внесшим огромный вклад в развитие научных подходов к управлению программными проектами - им разработаны спиральная модель проектирования ПО и Wideband Delphi, кроме того, когда-то именно он предсказал, что в будущем стоимость ПО превысит стоимость оборудования.

COCOMO создана на основе анализа статистических данных 63 проектов различных типов. Фактически под общим названием скрываются три уровня детализации: базовый, промежуточный и подробный. Также предусмотрено три режима использования модели в зависимости от размеров команды и проекта (табл. 1).

Таблица 3

Режимы модели COCOMO

Название режима	Размер проекта	Описание
Органичный	До 50 KLOC	Некрупный проект разрабатывается небольшой командой, для которой нехарактерны нововведения, и среда остается стабильной
Сблокированный	50 - 300 KLOC	Относительно небольшая команда занимается проектом среднего размера, в процессе разработки необходимы определенные инновации, среда характеризуется незначительной нестабильностью
Внедренный	Более 300 KLOC	Большая команда разработчиков трудится над крупным проектом, необходим значительный объем инноваций, среда состоит из множества элементов, которые не характеризуются стабильностью

Для оценки трудозатрат на базовом уровне модели COCOMO применяется следующая формула:

Т = a Ч Р b,

где a и b - константы, которые зависят от режима использования модели.

В соответствии с этой формулой трудозатраты вообще нелинейно зависят от размера проекта и скачкообразно изменяются при смене режима (табл. 2). Другая интересная особенность COCOMO - рост трудозатрат при переходе к более высокому режиму не означает безусловного увеличения длительности (F) выполнения проекта, которая вычисляется по формуле:

F = 2,5 Ч Т k,

поскольку при этом изменяется значение константы k.

Значения коэффициентов модели COCOMO в зависимости от режима использования

Таблица 4

Название режима	Значение коэффициента a	Значение коэффициента b	Значение коэффициента k
Органичный	2,4	1,05	0,38
Сблокированный	3,0	1,12	0,35
Внедренный	3,6	1,20	0,32

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

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

При построении COCOMO II для обработки статистических данных использовался Байесовский анализ, который дает лучшие результаты для программных проектов, характеризующихся неполнотой и неоднозначностью, в отличие от многофакторного регрессионного, примененного в COCOMO. Также в ней допускается измерять размер проекта не только числом строк кода, но и более современными функциональными и объектными точками. Помимо прочего, при расчете показателей COCOMO II учитывает уровень зрелости процесса разработки в соответствии с моделями SEI CMM/CMMI.

Как и COCOMO, COCOMO II также имеет несколько вариантов использования, однако они отличаются не столько детализацией, сколько характером - фактически это разные модели для решения разных (хотя и схожих) задач, объединенные под одним общим названием. При этом формулы для вычисления различных показателей значительно усложнились. При сохранении основных принципов модель стала намного гибче и учитывает гораздо большее число факторов, влияющих на выполнение программного проекта. [15]

...