Метрика - это количественный масштаб и метод, который может использоваться для измерения.
От себя добавим, что введение и использование метрик необходимо для улучшения контроля над процессом разработки, а в частности над процессом тестирования , который мы и будем рассматривать далее.
Цель контроля тестирования состоит в получении обратной связи и визуализации процесса тестирования . Необходимую для контроля информацию собирают (как в ручную, так и автоматически) и используют для оценки состояния и принятия решений, таких как покрытие (например, покрытие требований или кода тестами) или критерии выхода (например, критерии окончания тестирования). Метрики, также могут быть использованы для оценки прогресса выполнения запланированных работ и освоения бюджета
На наш взгляд, для большей наглядности имеет смысл сгруппировать метрики по типам сущностей, участвующих в обеспечении качества и тестировании программного обеспечения, а именно:
Давайте более детально разберем каждую из них:
Хотим отметить, что метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" хорошо визуализируют степень приближения продукта к достижению критериев качества по багам. Имея требования к количеству открытых багов , после каждой итерации тестирования мы сравниваем их с реальными данными, тем самым видя места, где нам нужно прибавить, для скорейшего достижения цели.
Метрики "Reopened/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования.
Пример первый
:
Допустим, мы имеем ситуацию, когда количество переоткрываемых после починки багов не уменьшается или даже растет. Это является сигналом к тому, что необходимо провести анализ причин, т.к. подобная ситуация может показать, что:
Второй пример
покажет для чего необходима метрика "Rejected/Opened Bugs":
Мы наблюдаем, что процент отклоненных (Rejected) багов очень большой. Это может значить:
Все эти проблемы заметно дестабилизируют обстановку на проекте. Поэтому, при их возникновении, рекомендуется провести короткую беседу с руководителями проектных групп, чтобы в последствии уменьшить количество переоткрытых и отклоненных дефектов.
| Название | Описание |
| Deployment tasks | Метрика показывает количество и результаты установок приложения. Процедура установки приложения была описана в статье Процедура проведения установки новой версии ПО (Deployment WorkFlow) . В случае, если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему. |
| Still Opened Tasks | Метрика показывает количество все еще открытых задач. К окончанию проекта все задачи должны быть закрыты. Под задачами понимаем следующие виды работ: написание документации (архитектура, требования, планы), имплементация новых модули или изменение существующих по запросам на изменения, работы по настройке стендов, различные исследования и многое другое |
Метрики по задачам могут быть разные, мы привели лишь две из них. Также интересна может быть метрика по времени выполнения задач и многие другие.
В заключении хотим отметить, что наличие необходимых метрик и графиков, отражающих изменение состояния проекта в течении времени, позволит вам улучшить не только процесс тестирования, но и разработки в целом, а также облегчит процедуру проведения анализа выполненного проекта , что позволит в дальнейшем не допускать прошлых ошибок.
Кроме SLOC к количественным характеристикам относят также:
Также к группе метрик, основанных на подсчете некоторых единиц в коде программы, относят метрики Холстеда . Данные метрики основаны на следующих показателях:
N1 - число уникальных операторов программы, включая символы-
Разделители, имена процедур и знаки операций (словарь операторов),
N2 - число уникальных операндов программы (словарь операндов),
N1 - общее число операторов в программе,
N2 - общее число операндов в программе,
N1" - теоретическое число уникальных операторов,
N2" - теоретическое число уникальных операндов.
Учитывая введенные обозначения, можно определить:
N=n1+n2 - словарь программы,
N=N1+N2 - длина программы,
N"=n1"+n2" - теоретический словарь программы,
N"= n1*log 2 (n1) + n2*log 2 (n2) - теоретическая длина программы (для стилистически корректных программ отклонение N от N" не превышает 10%)
V=N*log 2 n - объем программы,
V"=N"*log 2 n" - теоретический объем программы, где n* - теоретический словарь программы.
L=V"/V - уровень качества программирования, для идеальной программы L=1
L"= (2 n2)/ (n1*N2) - уровень качества программирования, основанный лишь на параметрах реальной программы без учета теоретических параметров,
E C =V/(L")2 - сложность понимания программы,
D=1/ L" - трудоемкость кодирования программы,
Y" = V/ D2 - уровень языка выражения
I=V/D - информационное содержание программы, данная характеристика позволяет определить умственные затраты на создание программы
E=N" * log 2 (n/L) - оценка необходимых интеллектуальных усилий при разработке программы, характеризующая число требуемых элементарных решений при написании программы
При применении метрик Холстеда частично компенсируются недостатки, связанные с возможностью записи одной и той же функциональности разным количеством строк и операторов.
Еще одним типом метрик ПО, относящихся к количественным, являются метрики Джилба. Они показывают сложность программного обеспечения на основе насыщенности программы условными операторами или операторами цикла. Данная метрика, не смотря на свою простоту, довольно хорошо отражает сложность написания и понимания программы, а при добавлении такого показателя, как максимальный уровень вложенности условных и циклических операторов, эффективность данной метрики значительно возрастает.
Перед тем как непосредственно описывать сами метрики, для лучшего понимания будет описан управляющий граф программы и способ его построения.
Пусть представлена некоторая программа. Для данной программы строится ориентированный граф, содержащий лишь один вход и один выход, при этом вершины графа соотносят с теми участками кода программы, в которых имеются лишь последовательные вычисления, и отсутствуют операторы ветвления и цикла, а дуги соотносят с переходами от блока к блоку и ветвями выполнения программы. Условие при построении данного графа: каждая вершина достижима из начальной, и конечная вершина достижима из любой другой вершины .
Самой распространенной оценкой, основанной на анализе получившегося графа, является цикломатическая сложность программы (цикломатическое число Мак-Кейба) . Она определяется как V(G)=e - n + 2p, где e - количество дуг, n - количество вершин, p - число компонент связности. Число компонентов связности графа можно рассматривать как количество дуг, которые необходимо добавить для преобразования графа в сильно связный. Сильно связным называется граф, любые две вершины которого взаимно достижимы. Для графов корректных программ, т. е. графов, не имеющих недостижимых от точки входа участков и «висячих» точек входа и выхода, сильно связный граф, как правило, получается путем замыкания дугой вершины, обозначающей конец программы, на вершину, обозначающую точку входа в эту программу. По сути V(G) определяет число линейно независимых контуров в сильно связном графе. Так что в корректно написанных программах p=1, и поэтому формула для расчета цикломатической сложности приобретает вид:
V(G)=e - n + 2.
К сожалению, данная оценка не способна различать циклические и условные конструкции. Еще одним существенным недостатком подобного подхода является то, что программы, представленные одними и теми же графами, могут иметь совершенно разные по сложности предикаты (предикат - логическое выражение, содержащее хотя бы одну переменную).
Для исправления данного недостатка Г. Майерсом была разработана новая методика. В качестве оценки он предложил взять интервал (эта оценка еще называется интервальной) , где h для простых предикатов равно нулю, а для n-местных h=n-1. Данный метод позволяет различать разные по сложности предикаты, однако на практике он почти не применяется.
Еще одна модификация метода Мак-Кейба - метод Хансена. Мера сложности программы в данном случае представляется в виде пары (цикломатическая сложность, число операторов). Преимуществом данной меры является ее чувствительность к структурированности ПО.
Топологическая мера Чена выражает сложность программы через число пересечений границ между областями, образуемыми графом программы. Этот подход применим только к структурированным программам, допускающим лишь последовательное соединение управляющих конструкций. Для неструктурированных программ мера Чена существенно зависит от условных и безусловных переходов. В этом случае можно указать верхнюю и нижнюю границы меры. Верхняя - есть m+1, где m - число логических операторов при их взаимной вложенности. Нижняя - равна 2. Когда управляющий граф программы имеет только одну компоненту связности, мера Чена совпадает с цикломатической мерой Мак-Кейба.
Продолжая тему анализа управляющего графа программы, можно выделить еще одну подгруппу метрик - метрики Харрисона, Мейджела.
Данные меры учитывает уровень вложенности и протяженность программы.
Каждой вершине присваивается своя сложность в соответствии с оператором, который она изображает. Эта начальная сложность вершины может вычисляться любым способом, включая использование мер Холстеда. Выделим для каждой предикатной вершины подграф, порожденный вершинами, которые являются концами исходящих из нее дуг, а также вершинами, достижимыми из каждой такой вершины (нижняя граница подграфа), и вершинами, лежащими на путях из предикатной вершины в какую-нибудь нижнюю границу. Этот подграф называется сферой влияния предикатной вершины.
Приведенной сложностью предикатной вершины называется сумма начальных или приведенных сложностей вершин, входящих в ее сферу влияния, плюс первичная сложность самой предикатной вершины.
Функциональная мера (SCOPE) программы - это сумма приведенных сложностей всех вершин управляющего графа.
Функциональным отношением (SCORT) называется отношение числа вершин в управляющем графе к его функциональной сложности, причем из числа вершин исключаются терминальные.
SCORT может принимать разные значения для графов с одинаковым цикломатическим числом.
Метрика Пивоварского - очередная модификация меры цикломатической сложности. Она позволяет отслеживать различия не только между последовательными и вложенными управляющими конструкциями, но и между структурированными и неструктурированными программами. Она выражается отношением N(G) = v *(G) + СУММАPi, где v *(G) - модифицированная цикломатическая сложность, вычисленная так же, как и V(G), но с одним отличием: оператор CASE с n выходами рассматривается как один логический оператор, а не как n - 1 операторов.
Рi - глубина вложенности i-й предикатной вершины. Для подсчета глубины вложенности предикатных вершин используется число «сфер влияния». Под глубиной вложенности понимается число всех «сфер влияния» предикатов, которые либо полностью содержатся в сфере рассматриваемой вершины, либо пересекаются с ней. Глубина вложенности увеличивается за счет вложенности не самих предикатов, а «сфер влияния». Мера Пивоварского возрастает при переходе от последовательных программ к вложенным и далее к неструктурированным, что является ее огромным преимуществом перед многими другими мерами данной группы.
Мера Вудворда - количество пересечений дуг управляющего графа. Так как в хорошо структурированной программе таких ситуаций возникать не должно, то данная метрика применяется в основном в слабо структурированных языках (Ассемблер, Фортран). Точка пересечения возникает при выходе управления за пределы двух вершин, являющихся последовательными операторами.
Метод граничных значений так же основан на анализе управляющего графа программы. Для определения данного метода необходимо ввести несколько дополнительных понятий.
Пусть G - управляющий граф программы с единственной начальной и единственной конечной вершинами.
В этом графе число входящих вершин у дуг называется отрицательной степенью вершины, а число исходящих из вершины дуг - положительной степенью вершины. Тогда набор вершин графа можно разбить на две группы: вершины, у которых положительная степень <=1; вершины, у которых положительная степень >=2.
Вершины первой группы назовем принимающими вершинами, а вершины второй группы - вершинами отбора.
Каждая принимающая вершина имеет приведенную сложность, равную 1, кроме конечной вершины, приведенная сложность которой равна 0. Приведенные сложности всех вершин графа G суммируются, образуя абсолютную граничную сложность программы. После этого определяется относительная граничная сложность программы:
Где S0 - относительная граничная сложность программы, Sa - абсолютная граничная сложность программы, v - общее число вершин графа программы.
Существует метрика Шнейдевинда, выражающаяся через число возможных путей в управляющем графе.
Метрика Чепина: суть метода состоит в оценке информационной прочности отдельно взятого программного модуля с помощью анализа характера использования переменных из списка ввода-вывода.
Все множество переменных, составляющих список ввода-вывода, разбивается на 4 функциональные группы:
1. P - вводимые переменные для расчетов и для обеспечения вывода,
2. M - модифицируемые, или создаваемые внутри программы переменные,
3. C - переменные, участвующие в управлении работой программного модуля (управляющие переменные),
Поскольку каждая переменная может выполнять одновременно несколько функций, необходимо учитывать ее в каждой соответствующей функциональной группе.
Метрика Чепина:
Q = a1*P + a2*M + a3*C + a4*T,
Где a1, a2, a3, a4 - весовые коэффициенты.
Q = P + 2M + 3C + 0.5T
Метрика спена основывается на локализации обращений к данным внутри каждой программной секции. Спен - это число утверждений, содержащих данный идентификатор, между его первым и последним появлением в тексте программы. Следовательно, идентификатор, появившийся n раз, имеет спен, равный n-1. При большом спене усложняется тестирование и отладка.
Еще одна метрика, учитывающая сложность потока данных - это метрика, связывающая сложность программ с обращениями к глобальным переменным.
Пара «модуль-глобальная переменная» обозначается как (p,r), где p - модуль, имеющий доступ к глобальной переменной r. В зависимости от наличия в программе реального обращения к переменной r формируются два типа пар «модуль - глобальная переменная»: фактические и возможные. Возможное обращение к r с помощью p показывает, что область существования r включает в себя p.
Данная характеристика обозначается Aup и говорит о том, сколько раз модули Up действительно получали доступ к глобальным переменным, а число Pup - сколько раз они могли бы получить доступ.
Отношение числа фактических обращений к возможным определяется
Эта формула показывает приближенную вероятность ссылки произвольного модуля на произвольную глобальную переменную. Очевидно, что чем выше эта вероятность, тем выше вероятность «несанкционированного» изменения какой-либо переменной, что может существенно осложнить работы, связанные с модификацией программы.
На основе концепции информационных потоков создана мера Кафура. Для использования данной меры вводятся понятия локального и глобального потока: локальный поток информации из A в B существует, если:
1. Модуль А вызывает модуль В (прямой локальный поток)
2. Модуль В вызывает модуль А и А возвращает В значение, которое используется в В (непрямой локальный поток)
3. Модуль С вызывает модули А, В и передаёт результат выполнения модуля А в В.
Далее следует дать понятие глобального потока информации: глобальный поток информации из А в В через глобальную структуру данных D существует, если модуль А помещает информацию в D, а модуль В использует информацию из D.
На основе этих понятий вводится величина I - информационная сложность процедуры:
I = length * (fan_in * fan_out)2
Здесь:
Length - сложность текста процедуры (меряется через какую-нибудь из метрик объёма, типа метрик Холстеда, Маккейба, LOC и т.п.)
Fan_in - число локальных потоков входящих внутрь процедуры плюс число структур данных, из которых процедура берёт информацию
Fan_out - число локальных потоков исходящих из процедуры плюс число структур данных, которые обновляются процедурой
Можно определить информационную сложность модуля как сумму информационных сложностей входящих в него процедур.
Следующий шаг - рассмотреть информационную сложность модуля относительно некоторой структуры данных. Информационная мера сложности модуля относительно структуры данных:
J = W * R + W * RW + RW *R + RW * (RW - 1)
W - число процедур, которые только обновляют структуру данных;
R - только читают информацию из структуры данных;
RW - и читают, и обновляют информацию в структуре данных.
Еще одна мера данной группы - мера Овиедо. Суть ее состоит в том, что программа разбивается на линейные непересекающиеся участки - лучи операторов, которые образуют управляющий граф программы.
Автор метрики исходит из следующих предположений: программист может найти отношение между определяющими и использующими вхождениями переменной внутри луча более легко, чем между лучами; число различных определяющих вхождений в каждом луче более важно, чем общее число использующих вхождений переменных в каждом луче.
Обозначим через R(i) множество определяющих вхождений переменных, которые расположены в радиусе действия луча i (определяющее вхождение переменной находится в радиусе действия луча, если переменная либо локальна в нём и имеет определяющее вхождение, либо для неё есть определяющее вхождение в некотором предшествующем луче, и нет локального определения по пути). Обозначим через V(i) множество переменных, использующие вхождения которых уже есть в луче i. Тогда мера сложности i-го луча задаётся как:
DF(i)=СУММА(DEF(v j)), j=i...||V(i)||
Где DEF(v j) - число определяющих вхождений переменной v j из множества R(i), а ||V(i)|| - мощность множества V(i).
Первой из таких метрик является тестирующая М-Мера . Тестирующей мерой М называется мера сложности, удовлетворяющая следующим условиям:
Мера возрастает с глубиной вложенности и учитывает протяженность программы. К тестирующей мере близко примыкает мера на основе регулярных вложений. Идея этой меры сложности программ состоит в подсчете суммарного числа символов (операндов, операторов, скобок) в регулярном выражении с минимально необходимым числом скобок, описывающим управляющий граф программы. Все меры этой группы чувствительны к вложенности управляющих конструкций и к протяженности программы. Однако возрастает уровень трудоемкости вычислений.
Также мерой качества программного обеспечения служит связанность модулей программы . Если модули сильно связанны, то программа становится трудномодифицируемой и тяжелой в понимании. Данная мера не выражается численно. Виды связанности модулей:
Связанность по данным - если модули взаимодействуют через передачу параметров и при этом каждый параметр является элементарным информационным объектом. Это наиболее предпочтительный тип связанности (сцепления).
Связанность по структуре данных - если один модуль посылает другому составной информационный объект (структуру) для обмена данными.
Связанность по управлению - если один посылает другому информационный объект - флаг, предназначенный для управления его внутренней логикой.
Модули связаны по общей области в том случае, если они ссылаются на одну и туже область глобальных данных. Связанность (сцепление) по общей области является нежелательным, так как, во-первых, ошибка в модуле, использующем глобальную область, может неожиданно проявиться в любом другом модуле; во-вторых, такие программы трудны для понимания, так как программисту трудно определить какие именно данные используются конкретным модулем.
Связанность по содержимому - если один из модулей ссылается внутрь другого. Это недопустимый тип сцепления, так как полностью противоречит принципу модульности, т.е. представления модуля в виде черного ящика.
Внешняя связанность - два модуля используют внешние данные, например коммуникационный протокол.
Связанность при помощи сообщений - наиболее свободный вид связанности, модули напрямую не связаны друг с другом, о сообщаются через сообщения, не имеющие параметров.
Отсутствие связанности - модули не взаимодействуют между собой.
Подклассовая связанность - отношение между классом-родителем и классом-потомком, причем потомок связан с родителем, а родитель с потомком - нет.
Связанность по времени - два действия сгруппированы в одном модуле лишь потому, что ввиду обстоятельств они происходят в одно время.
Еще одна мера, касающаяся стабильности модуля - мера Колофелло , она может быть определена как количество изменений, которые требуется произвести в модулях, отличных от модуля, стабильность которого проверяется, при этом эти изменения должны касаться проверяемого модуля.
Следующая метрика из данного класса - Метрика Мак-Клура. Выделяются три этапа вычисления данной метрики:
1. Для каждой управляющей переменной i вычисляется значениt её сложностной функции C(i) по формуле: C(i) = (D(i) * J(i))/n.
Где D(i) - величина, измеряющая сферу действия переменной i. J(i) - мера сложности взаимодействия модулей через переменную i, n - число отдельных модулей в схеме разбиения.
2. Для всех модулей, входящих в сферу разбиения, определяется значение их сложностных функций M(P) по формуле M(P) = fp * X(P) + gp * Y(P)
где fp и gp - соответственно, число модулей, непосредственно предшествующих и непосредственно следующих за модулем P, X(P) - сложность обращения к модулю P,
Y(P) - сложность управления вызовом из модуля P других модулей.
3. Общая сложность MP иерархической схемы разбиения программы на модули задаётся формулой:
MP = СУММА(M(P)) по всем возможным значениям P - модулям программы.
Данная метрика ориентирована на программы, хорошо структурированные, составленные из иерархических модулей, задающих функциональную спецификацию и структуру управления. Также подразумевается, что в каждом модуле одна точка входа и одна точка выхода, модуль выполняет ровно одну функцию, а вызов модулей осуществляется в соответствии с иерархической системой управления, которая задаёт отношение вызова на множестве модулей программы.
Также существует метрика, основанная на информационной концепции - мера Берлингера . Мера сложности вычисляется как M=СУММАf i *log 2 p i , где f i - частота появления i-го символа, p i - вероятность его появления.
Недостатком данной метрики является то, что программа, содержащая много уникальных символов, но в малом количестве, будет иметь такую же сложность как программа, содержащая малое количество уникальных символов, но в большом количестве.
Прежде чем начать рассмотрение метрик Мартина необходимо ввести понятие категории классов . В реальности класс может достаточно редко быть повторно использован изолированно от других классов. Практически каждый класс имеет группу классов, с которыми он работает в кооперации, и от которых он не может быть легко отделен. Для повторного использования таких классов необходимо повторно использовать всю группу классов. Такая группа классов сильно связна и называется категорией классов. Для существования категории классов существуют следующие условия:
Классы в пределах категории класса закрыты от любых попыток изменения все вместе. Это означает, что, если один класс должен измениться, все классы в этой категории с большой вероятностью изменятся. Если любой из классов открыт для некоторой разновидности изменений, они все открыты для такой разновидности изменений.
Классы в категории повторно используются только вместе. Они настолько взаимозависимы и не могут быть отделены друг от друга. Таким образом, если делается любая попытка повторного использования одного класса в категории, все другие классы должны повторно использоваться с ним.
Ответственность, независимость и стабильность категории могут быть измерены путем подсчета зависимостей, которые взаимодействуют с этой категорией. Могут быть определены три метрики:
1. Ca: Центростремительное сцепление. Количество классов вне этой категории, которые зависят от классов внутри этой категории.
2. Ce: Центробежное сцепление. Количество классов внутри этой категории, которые зависят от классов вне этой категории.
3. I: Нестабильность: I = Ce / (Ca+Ce). Эта метрика имеет диапазон значений .
I = 0 указывает максимально стабильную категорию.
I = 1 указывает максимально не стабильную категорию.
Можно определять метрику, которая измеряет абстрактность (если категория абстрактна, то она достаточно гибкая и может быть легко расширена) категории следующим образом:
A: Абстрактность: A = nA / nAll.
NA - количество_абстрактных_классов_в_категории.
NAll - oбщее_количество_классов_в_категории.
Значения этой метрики меняются в диапазоне .
Теперь на основе приведенных метрик Мартина можно построить график, на котором отражена зависимость между абстрактностью и нестабильностью. Если на нем построить прямую, задаваемую формулой I+A=1, то на этой прямой будут лежать категории, имеющие наилучшую сбалансированность между абстрактностью и нестабильностью. Эта прямая называется главной последовательностью.
Расстояние до главной последовательности: D=|(A+I-1)/sqrt(2)|
Нормализированной расстояние до главной последовательности: Dn=|A+I-2|
Практически для любых категорий верно то, что чем ближе они находятся к главной последовательности, тем лучше.
Следующая подгруппа метрик - метрики Чидамбера и Кемерера . Эти метрики основаны на анализе методов класса, дерева наследования и т.д.
WMC (Weighted methods per class), суммарная сложность всех методов класса: WMC=СУММАc i , i=1...n, где c i - сложность i-го метода, вычисленная по какой либо из метрик (Холстеда и т.д. в зависимости от интересующего критерия), если у всех методов сложность одинаковая, то WMC=n.
DIT (Depth of Inheritance tree) - глубина дерева наследования (наибольший путь по иерархии классов к данному классу от класса-предка), чем больше, тем лучше, так как при большей глубине увеличивается абстракция данных, уменьшается насыщенность класса методами, однако при достаточно большой глубине сильно возрастает сложность понимания и написания программы.
NOC (Number of children) - количество потомков (непосредственных), чем больше, тем выше абстракция данных.
CBO (Coupling between object classes) - сцепление между классами, показывает количество классов, с которыми связан исходный класс. Для данной метрики справедливы все утверждения, введенные ранее для связанности модулей, то есть при высоком CBO уменьшается абстракция данных и затрудняется повторное использование класса.
RFC (Response for a class) - RFC=|RS|, где RS - ответное множество класса, то есть множество методов, которые могут быть потенциально вызваны методом класса в ответ на данные, полученные объектом класса. То есть RS=(({M}({R i }), i=1...n, где M - все возможные методы класса, R i - все возможные методы, которые могут быть вызваны i-м классом. Тогда RFC будет являться мощностью данного множества. Чем больше RFC, тем сложнее тестирование и отладка.
LCOM (Lack of cohesion in Methods) - недостаток сцепления методов. Для определения этого параметра рассмотрим класс C с n методами M1, M2,… ,Mn, тогда {I1},{I2},...,{In} - множества переменных, используемых в данных методах. Теперь определим P - множество пар методов, не имеющих общих переменных; Q - множество пар методов, имеющих общие переменные. Тогда LCOM=|P|-|Q|. Недостаток сцепления может быть сигналом того, что класс можно разбить на несколько других классов или подклассов, так что для повышения инкапсуляции данных и уменьшения сложности классов и методов лучше повышать сцепление.
H_M = (M + R1 * M(M1) +… + Rn * M(Mn)/(1 + R1 +… + Rn)
Где M - базовая метрика, Mi - другие интересные меры, Ri - корректно подобранные коэффициенты, M(Mi) - функции.
Функции M(Mi) и коэффициенты Ri вычисляются с помощью регрессионного анализа или анализа задачи для конкретной программы.
Метрика Зольновского, Симмонса, Тейера также представляет собой взвешенную сумму различных индикаторов. Существуют два варианта данной метрики:
(структура, взаимодействие, объем, данные) СУММА(a, b, c, d).
(сложность интерфейса, вычислительная сложность, сложность ввода/вывода, читабельность) СУММА(x, y, z, p).
Используемые метрики в каждом варианте выбираются в зависимости от конкретной задачи, коэффициенты - в зависимости от значения метрики для принятия решения в данном случае.
С учетом новых методик, таких как экстремальное программирование или Scrum, разработка может осуществляться быстрее, а наличие новых платформ и абстрагирование от нижних уровней позволяют избегать многих ошибок. Тем не менее контроль качества должен осуществляться на самых различных уровнях – начиная с методологического и заканчивая технологическим уровнем, когда процессы контроля качества протекают в автоматическом режиме, например при автоматических сборках проекта. Однако любой контроль предполагает наличие метрик, которые позволяют оценить достижение того или иного уровня качества программного проекта.
Метрики кода
Метрика программного обеспечения (software metric) – численная мера, позволяющая оценить определенные свойства конкретного участка программного кода. Для каждой метрики обычно существуют ее эталонные показатели, указывающие, при каких крайних значениях стоит обратить внимание на данный участок кода. Метрики кода разделяются на категории и могут оценивать совершенно различные аспекты программной системы: сложность и структурированность программного кода, связность компонентов, относительный объем программных компонентов и др. Наиболее простая для понимания метрика – количество строк кода в программной системе, – хотя и элементарно вычисляется, но в совокупности с другими метриками может служить для получения формализованных данных для оценки кода. Например, можно построить соотношение между количеством строк кода в классе и количеством методов/свойств в классе, получив характеристику, показывающую, насколько методы данного класса являются объемными. Кроме того, такие оценки можно использовать в совокупности с метриками сложности (например, цикломатической сложностью Мак-Кейба) для определения наиболее сложных участков в программном коде и принятия соответствующих мер.
Метрики кода могут служить также для выявления архитектурных особенностей. Наибольший эффект применение таких метрик дает при анализе больших программных систем, когда ручной анализ и просмотр исходного кода может занимать значительное время. Например, можно различным образом визуализировать метрики, как указано на рис. 1, где каждый программный блок представляется в виде прямоугольника, при этом длина каждой стороны прямоугольника отражает значение какой-либо из метрик (например, сложность, структурированность и т.д.). Подобное представление можно строить как для высокоуровневых программных сущностей (сборки, библиотеки, пространства имен), так и для более частных элементов (свойства, методы). При этом при анализе высокоуровневой диаграммы можно быстро выявить проблемные библиотеки и спуститься на уровень ниже, чтобы исследовать проблемные сущности.
Метрики программного кода являются важным инструментом и уже сегодня используются многими производителями ПО. Так, при сертификации на более высокие уровни по моделям ISO/IEC или CMM/CMMI использование метрик кода является обязательным, что позволяет в определенной степени достичь контролируемости процесса разработки.
Существует множество различных классификаций метрик программного обеспечения, трактующих метрики с различных позиций и ранжирующих одни и те же характеристики по различным критериям. Одной из таких классификаций может служить разделение метрик на группы по субъектам оценки:
размер – сравнительная оценка размеров ПО;
сложность – оценка архитектуры и алгоритмов программной системы (отрицательные показатели этой группы метрик говорят о проблемах, с которыми можно столкнуться при развитии, поддержке и отладке программного кода);
поддерживаемость – оценка потенциала программной системы для последующей модификации.
Безусловно, существуют и другие группы, которые не вошли в эту классификацию, например, метрики удовлетворенности пользователя или показатели соответствия исходным требованиям, но в данном случае нас будет интересовать качество программного обеспечения с точки зрения именно технической реализации.
Имеет ли значение размер?
Метрика SLOC (source lines of code) отражает количество строк исходного кода. Данный показатель не всегда может использоваться для объективной оценки объемов программной системы – его числовое значение зависит от множества случайных факторов, например стиля кодирования. Сравнивать две программные системы лишь по этому критерию вряд ли правомерно, поэтому для SLOC появилось множество производных показателей: количество пустых строк; количество строк, содержащих комментарии; процентное соотношение комментариев; количество строк кода, содержащихся в методах/функциях; среднее количество строк кода на метод/функцию; среднее количество строк кода на класс/пакет; среднее количество строк кода на модуль и т.д.
Кроме SLOC, при оценке размера часто используют показатель «логических» строк кода LSI (logical source instructions), вычисляемый после нормализации (приведения исходного кода к надлежащему виду) листинга: устранение размещения нескольких инструкций на одной строке, пустых строк, очистка от комментариев, форматирование строк кода для инициализации данных и т.д. Такой показатель может служить для более объективной оценки объема системы (показатель с применением нормализации выглядит так же, как и SLOC, – количество строк, но не физических, а логических). У LSI также существуют производные, например метрика, вычисляемая не как физическое количество строк кода на исходном языке программирования, а как количество инструкций на языке более низкого уровня (язык Ассемблера, MSIL и др.), что устраняет необходимость в нормализации.
Другие метрики этого типа базируются на сущностях, относящихся к конкретной парадигме программирования. Наиболее популярной на сегодняшний день является парадигма объектно-ориентированного программирования, однако для функционального и процедурного подхода к программированию также имеется свой специфический набор метрик. С точки зрения объектно-ориентированного подхода размер системы можно вычислять как количество содержащихся в ней классов. Показатель количества классов является одной из основных метрик в данном подходе, однако в зависимости от используемого языка программирования могут применяться такие метрики, как количество пространств имен в проекте, количество структур, перечислений, количество методов и др. Кроме того, можно вычислить «плотность» этих показателей, определив соотношение значений этих метрик. Например, можно вычислить соотношение количества классов к количеству методов и понять, сколько методов в среднем содержится в одном классе. Однако для определения пороговых значений для такого типа метрик требуются дополнительные исследования. Наиболее простым способом определения граничных величин может быть эксперимент, в котором значения этих метрик вычисляются для уже существующих систем. Вычисление подобных соотношений позволит скорректировать представление о системе, которое сложилось на основе количественных метрик.
Напрямую качество системы не зависит от использования данных показателей, однако опытные разработчики со временем могут примерно прогнозировать объем системы на заданный функционал, необходимый заказчику. В этом случае при заметном отклонении от заданных показателей (например, существенном увеличении количества классов при низком количестве методов на класс) стоит задуматься о том, что в системе может присутствовать избыточное количество объектов, и на более ранней стадии выполнить рефакторинг кода.
Сложность
Для оценки и контроля качества кода могут непосредственно использоваться метрики сложности: цикломатическая сложность, связность кода, глубина наследования и др.
Метрика цикломатической сложности (cyclomatic complexity) показывает количество ветвлений управляющего потока программы, увеличенное на единицу. Для вычисления данной метрики на основе исходного кода строится ориентированный граф, содержащий один вход и один выход. При этом вершины графа соотносят с теми участками кода программы, в которых содержатся лишь последовательные вычисления и отсутствуют операторы ветвления и цикла. Дуги в этом случае соотносят с переходами от блока к блоку. При этом каждая вершина графа достижима из начальной, а конечная точка достижима из любой другой. В этом случае цикломатическую сложность можно вычислить как разницу количества дуг и количества вершин, увеличенную на два. Такой показатель может отразить сложность управляющего потока программы и дать сигнал о возможном наличии некачественного участка кода. К сожалению, несмотря на очевидную практическую полезность, эта метрика не способна различать циклические операторы. Кроме того, программные коды, представленные одними и теми же графами, могут иметь совершенно различные по сложности предикаты (логические выражения, содержащие переменную). По этой причине иногда цикломатическую сложность используют одновременно с другими метриками, например с метрикой числа операторов.
Метрика связности классов позволяет определить степень зависимости программных компонентов системы друг от друга. Повышенные значения данной метрики относительно пороговых значений могут говорить о чрезмерной связанности системы, которая появляется из-за слабой модульной инкапсуляции. Такое свойство программной системы может привести к трудностям при повторном использовании кода. На данную метрику можно ориентироваться при построении и переработке архитектуры программной системы. Основными способами уменьшения связности объектов является более строгая инкапсуляция логики в объекты, пересмотр работы алгоритмов с концептуальной точки зрения и структурная декомпозиция. При этом используются фабрики объектов, которые позволяют избежать лишней связности в момент создания экземпляров классов. Благодаря применению сырых значений данной метрики удается снизить связность программной системы, а следовательно, и сложность кода.
Иногда используют вариацию метрики, отражающей связность кода, – количество вызовов операции. Эта метрика позволяет определить количественный показатель связности системы в виде вызовов методов. Метрика подсчитывает вызовы только тех операций, которые определены пользователем. Например, если метод A() вызывает метод B() три раза, то значение этой метрики будет равно единице; если же метод B() вызывается по одному разу из методов A(), C() и D(), то значение метрики будет равняться трем. Однако абсолютное значение данной метрики может существенно изменяться от проекта к проекту в зависимости от подходов к проектированию и кодированию программных систем. Даже в рамках одной и той же команды разработчиков на идентичных проектах значение данной метрики может отличаться в силу субъективных факторов (например, стиля конкретного разработчика при выделении логики в отдельные методы), которые оказывали влияние при построении программной системы.
Прямой результат вычисления этой метрики имеет сомнительное практическое значение, однако в совокупности с суммарным значением метрики количество методов в классе может дать объективную оценку связности системы. Например, если использовать эту метрику наряду с метрикой сложности, а также объемными характеристиками, то по совокупности значений этих метрик можно обнаружить недостаточно качественный код.
Еще одной важной метрикой оценки сложности является средняя глубина наследования, которая вычисляется как среднее значение глубины наследования для всех классов системы, определенных пользователем. При этом не учитываются классы, стоящие не на самом нижнем уровне иерархии наследования. Высокие значения метрики могут сигнализировать о том, что архитекторы программной системы слишком увлеклись приемами объектно-ориентированного программирования, а это может негативно сказываться на дальнейшем развитии системы. Наследование существенно повышает связность, которая при этом может не отражаться остальными метриками оценки системы. Зачастую при построении программного кода можно избежать применения наследования, заменив его равноценными приемами. Например, вместо этого можно использовать инъекцию зависимостей и IoC-контейнеры. Результат вычисления данной метрики, как правило, используется в сыром виде в практических задачах построения архитектуры и рефакторинга. Полученные показатели метрики также можно использовать в более сложных комплексных метриках. Иначе говоря, если значение этой метрики велико, то можно сразу выявить аномалию. Кроме того, эту метрику можно использовать в совокупности с другими, например подсчитать сложность системы по Мак-Кейбу и ее объем, чтобы точнее измерить программную систему.
В целом метрики сложности могут оказать существенную помощь производителям программного обеспечения в процессе контроля и управления качеством программного обеспечения.
Поддерживаемость
Метрики данного типа показывают трудоемкость процесса поддержки и развития программного кода и, как правило, тесно связаны с метриками сложности, но имеют свои особенности, отражающие возможности поддержки системы.
Одной из основных метрик этой категории является метрика Холстеда, в рамках которой определяют четыре измеряемые характеристики программы: число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов); число уникальных операндов программы (словарь операндов); общее число операторов в программе; общее число операндов в программе. На основании этих характеристик производятся базовые оценки: составляется словарь программы; определяется длина программы, ее объем и сложность. Далее предлагается вычислить различные меры, которые позволяют оценить программный код. Например, выражение для вычисления качества программирования, сложности понимания программы, умственные затраты на создание программы и др.
Метрика Холстеда носит исключительно информационный характер, тем не менее она остается одной из немногих, которые позволяют количественно оценить показатель поддерживаемости системы в будущем, при этом данный показатель имеет прямую корреляцию с качеством выпускаемого продукта.
Разработчики на платформе Microsoft могут воспользоваться версией Visual Studio 2008, которая позволяет вычислять базовый набор основных метрик и отслеживать их в режиме реального времени (рис. 2). Тем не менее основной сценарий использования метрик – это информирование менеджеров разработки о том, что качество продукта, возможно, понизилось или повысилось. Поэтому имеет смысл вычислять такие метрики в процессе сборки проекта.
Visual Stuido 2008 и Microsoft Build не позволяют выстроить серьезную иерархию метрик, и для этого следует воспользоваться другими инструментами, например NDepend, позволяющим для платформы.NETрассчитывать различные типы связности, наследования и абстрактности, интегрируясь в процесс создания программ в соответствии с требованиями конкретной команды разработчиков.
Проблемы при использовании метрик кода
Несмотря на то что метрики позволяют контролировать процесс разработки, работа с ними сопряжена с рядом проблем.
Во-первых, все известные на сегодняшний день метрики кода недостаточно значимы и точны. Они не способны обеспечить получение объективной картины о состоянии программной системы, а лишь выдают показатели, которые вычислены по заданному алгоритму. Во-вторых, процесс измерения может быть искусственно искажен за счет того, что сотрудники будут «оптимизировать» свой программный код так, чтобы метрики выдавали лучшие результаты. Кроме того, формальное использовании метрик не учитывает опыт сотрудников, уровень компании и может принести не только пользу, но и вред.
Тем не менее метрики являются достаточно полезным инструментом в руках разработчиков и менеджеров проектов, позволяющим выявить моменты ухода разработки на более низкий качественный уровень и распознать наиболее сложные участки в системе. Определение числовых показателей может дать новые сведения о разрабатываемом продукте и помочь более грамотно планировать расходы на его дальнейшее развитие.
Сергей Звездин ([email protected]) – аспирант Южно-Уральского государственного университета (Челябинск).
В МГУ открыт портал дистанционного обучения
Школа дистанционного образования Московского государственного университета им. М.В. Ломоносова открыла собственный Internet-портал . На нем предлагается доступ к совместной открытой электронной библиотеке МГУ и Российской академии наук, учебникам и курсам, аудио- и видеоматериалам, а также к образовательным программам с применением дистанционных образовательных технологий. Часть ресурсов портала доступна только слушателям дистанционных программ, оплатившим обучение согласно договору с университетом. Видеоматериалы МГУ теперь доступны на канале университета в YouTube. Образовательный канал содержит записи лекций, а также мероприятий университета.
eLearning только для 17% российских компаний
Исследовательский центр портала SuperJob.ru представил результаты опроса, посвященного онлайн-обучению персонала российских компаний. Среди отечественных работодателей использование электронного обучения в работе с персоналом не слишком распространено. Только 17% компаний предлагают персоналу подобную форму обучения. В основном эти технологии применяют в крупных компаниях со штатом от 5 тыс. человек (50%). Вообще не применяют подобную практику 79% работодателей. Причины кроются либо в отсутствии необходимого технического оборудования, либо в нежелании руководства применять такой вид обучения. В целом опыт дистанционного обучения имеют лишь 11% россиян. Из этого числа 9% респондентов остались довольны результатом, а 2% – недоучились и бросили. Среди тех, кто прошел обучение, мужчин оказалось почти вдвое больше, чем женщин (11% и 6% соответственно). При этом россияне в возрасте от 35 до 55 лет учатся через Internet чаще, чем молодежь. Успешным опытом дистанционного обучения может похвастаться 12% респондентов в возрасте от 40-50 лет и лишь 9% россиян в возрасте до 23 лет.
Итоги конкурса «Максимальная масштабируемость 2009»
Конкурс проектов по высокопроизводительным вычислениям «Максимальная масштабируемость», как и в прошлом году, был приурочен к международному форуму по нанотехнологиям. На победу в нем претендовали ученые из двадцати городов России, однако организаторы, компания Intel и «Российская корпорация нанотехнологий», отдали все призовые места столичным проектам. Гран-при получил Владимир Боченков с химического факультета МГУ им. Ломоносова за проект «Разработка и реализация параллельного алгоритма температурно-ускоренной динамики». Предложенная автором система позволяет исследовать конденсацию наноструктур, молекулярно-лучевую эпитаксию и взаимодействие биологических молекул.
Стартовал чемпионат мира по программированию
В финале 34-го ежегодного командного чемпионата мира по программированию (International Collegiate Programming Contest, ICPC), который проводится ассоциацией Association for Computing Machinery (ACM) и спонсируется IBM, встретятся сто победивших в региональных соревнованиях студенческих команд. Перед ними будут поставлены как минимум восемь задач, которые потребуется решить за 5 часов. Финал пройдет 5 февраля 2010 года в Харбинском инженерном университете (Китай). Среди задач прошлых лет были, например, такие как поиск потерянного в море корабля, триангуляция местоположения испорченного радиопередатчика, вычисление препятствий при игре в гольф, кодирование и декодирование сообщений, печать шрифтом Брайля, поиск выхода из лабиринта. В прошлом году три из четырех золотых медалей завоевали российские команды. На стадии отборочных соревнований в чемпионате участвовало 7109 команд из 1838 университетов 88 стран мира. Второй год подряд чемпионом мира стала команда Санкт-Петербургского государственного университета информационных технологий, механики и оптики.
Подход к определению метрик изначально разрабатывался исключительно для целей управления проектом и для достижения соответствия требованиям контракта. После того как поставленные цели были достигнуты, они стали практическим примером для изучения. Выполнение проекта CCPDS-R никогда даже не приближалось к оптимальному; в процессе выполнения постоянно совершалось большое количество ошибок. Подобное утверждение справедливо и для программы по определению метрик: иногда измерялось не то, что надо, иногда измерялось не так, как надо. Она не способствовала ранней интерпретации, и в ней применялись ручные методы там, где была необходима автоматизация. Тем не менее работа с метриками привела к улучшению командного труда, к улучшению процессов, к лучшему пониманию рисков и, безусловно, к созданию более эффективного продукта. На ранних стадиях проекта существовало сопротивление со стороны управления, со стороны практических разработчиков и даже со стороны наблюдателей за ходом выполнения.
контракта. По истечении первого года, после нескольких усовершенствований в интерпретации, автоматизации, представлении и определении ощущалась практически единодушная поддержка. Все стороны использовали объективные данные из программы по определению метрик для обоснования своих планов, рисков, направлений разработок и результатов.
Все представленные метрики Подсистемы общего назначения извлекались непосредственно из ежемесячных обзоров по управлению проектом. Ни одно из этих значений не создавалось постфактум. Хотя программа по определению метрик и являлась требованием, содержащимся в контракте, правительство не определило, какие именно метрики должны использоваться. Это было оставлено на усмотрение подрядчика с тем, чтобы команда, выполняющая проект, самостоятельно приняла на себя ответственность за выбранную программу по определению метрик.
Компания TRW сформулировала четыре задачи программы по определению метрик:.
Обеспечение данными для оценки текущих тенденций выполнения проекта и определения того, на что следует обратить внимание при управлении проектом.
Обеспечение данными для планирования последующих этапов и создания других подсистем.
Обеспечение данными для оценки относительной сложности достижения соответствия окончательным требованиям по качеству.
Обеспечение данными, позволяющими определить, какие требуются усовершенствования процесса, и обосновать их необходимость.
Ниже приводятся конкретные примеры метрик, рекомендованных в главе 13. Дается несколько примеров метрик для определения прогресса, а также качественных показателей дефектов, доработок и завершенности. Описываются основы, необходимые для автоматизации; они требуют некоторых интересных технических подходов, которые заключены непосредственно внутри рабочих продуктов, связанных с проектированием и кодированием.
D.7.1 Прогресс разработки.
Точное измерение прогресса разработки при наличии нескольких параллельных видов деятельности, находящихся на различных стадиях, являлось сложной проблемой для команды, управляющей созданием Подсистемы общего назначения. Значительные усилия пришлось затратить на формирование согласованного подхода, который предоставил бы точную информацию относительно состояния на уровне подсистем и состояния версий. Целью было получение взвешенной оценки, в которую включалось бы следующее:.
■ Метрики Ada/ADL. Позволяли довольно точно определять непосредственные показатели технического прогресса. Сами по себе эти метрики абсолютно точно отражали прогресс в разработке и реализации. Однако они плохо подходили для описания завершенных частей контракта и финансового состояния.
■ Метрики добавленной стоимости. Позволяли довольно точно определять финансовое состояние и готовые к поставке заказчику части контракта. Вообще говоря, они являются плохими показателями реального технического прогресса.
Как и в случае большинства других метрик ПО, оба эти подхода изначально давали неточные оценки абсолютного прогресса. Однако они являлись превосходными оценками относительного прогресса, если отслеживались регулярно (в нашем случае - ежемесячно). По мере накопления опыта работы с этими метриками абсолютные оценки постепенно настраивались для предсказания успеха или риска. Общие оценки сводились в единую диаграмму. На рис. D.9 показан итоговый прогресс на самом верхнем уровне для каждой отдельной версии и для Подсистемы общего назначения в целом. Длина заштрихованного участка внутри каждой версии относительно пунктирной линии (относящейся к текущему месяцу) определяет, опережает ли выполнение существующее расписание или отстает от него. Например, на рисунке изображено состояние после 17 месяца: НТ-тестирование версии 2 отстает от графика на один месяц, разработка версии 3 опережает график на один месяц, разработка
Рис. D.9. Общий прогресс разработки.
Подсистемы общего назначения соответствует расписанию, а НТ-тестирование Подсистемы общего назначения отстает от графика на один месяц. Заштрихованные области - это оценка главного разработчика, который объединял ежемесячные значения метрик прогресса с ежемесячными значениями метрик финансового состояния в некую обобщенную (а потому, в некотором смысле, субъективную) оценку.
Ежемесячный сбор значений метрик обеспечивал необходимое для управления детальное понимание прогресса, увеличения объема кода и других показателей, достигнутых на каждой из версий. Метрики собираются по каждой версии и по CSCI с тем, чтобы иметь возможность рассмотрения под различными углами зрения. Менеджеры*каждого отдельного CSCI собирали и оценивали свои метрики, прежде чем они сводились воедино для проекта в целом. Этот процесс являлся объективным, эффективным и осмысленным. Самый нижний уровень оценок TBD_Statements был, конечно, субъективным, однако они определялись наиболее осведомленными людьми: непосредственными разработчиками. Оценки хранились в формате исходного кода. В этом случае возрастала вероятность того, что в данном виде рабочих продуктов будет храниться самая последняя информация. Такой процесс позволял также непротиворечиво и единообразно сравнивать прогресс по различным направлениям проекта.
На рис. D.10 представлены ежемесячные оценки прогресса для Подсистемы общего назначения и для каждой версии. Планируемый объем изменений основывался на грубом средневзвешенном подсчете для каждой версии, выполнявшемся согласно указаниям, данным в разделе D.5.3: 30% объема создается к моменту ПСКП и 70% объема - к моменту КСКП. В целом Подсистема общего назначения практически полностью соответствовала своему плану за одним исключением. Прогресс, достигнутый к моменту ППОП (намного опережая график), отразил неожиданное позитивное влияние инструментария, генерирующего исходный код. С его помощью для САПО было сгенерировано более 50 ООО SLOC.
Соответствие работы планам менялось в зависимости от конкретной версии. Прогресс, достигнутый для Подсистемы и для каждой версии, оценивался ежемесячно внутренним руководством и заказчиком в процессе обзоров управления проектом. Метрики прогресса являлись объективным механизмом и согласованным языком для описания изменений, вносимых в планы и архитектуру, проблем, возникающих при разработке, рисков при составлении графиков и других связанных с управлением аспектов. Объективность такого подхода являлась основной составляющей неантагонистических отношений, установившихся между всеми заинтересованными сторонами.
Все понимали, что, хотя значения метрик были не точны на ранних стадиях жизненного цикла, они были верны. Абсолютные значения редко когда оказывались важными. Более важными являлись относительные тенденции, и по мере развития процесса точность всех метрик возрастала. К моменту ПОП значения метрик стали краеугольным камнем при обмене информацией в рамках проекта.
Рис. D.10. Прогресс в разработке Подсистемы общего назначения D.7.2 Прогресс в тестировании.
Организация, осуществлявшая тестирование, должна была создать тесты интеграции версий и тесты на соответствие требованиям (некоторые НТ-, ФТ- и ОКТ-тесты). Тестирование интеграции версий оказалось менее эффективным с точки зрения выявления проблем, чем ожидалось. ИТВ-тесты должны были содержать полный набор процедур тестирования интеграции - от базовых возможностей до особых граничных условий. Большая часть этой работы, в частности основные потоки, перекрывалась с работами по интеграции для демонстрации. Соответственно, ИТВ-тесты зачастую дублировали подготовку к демонстрациям, что было менее эффективно по стоимости, чем если бы деятельность по подготовке к демонстрациям была совмещена с ИТВ, а ответственность за нее.
возложена на организацию, выполняющую тестирование. В таблице D.6 представлены результаты ИТВ этапа 2, которые отражают интегрированное состояние продукта. Однако на планирование, подготовку и проведение ИТВ было затрачено больше усилий, чем требовалось. Совмещение подготовки к демонстрациям с деятельностью по проведению ИТВ позволило бы меньшему числу сотрудников сделать работу лучше. Такой подход позволил бы увеличить степень интеграции (являясь составной частью работ по подготовке демонстраций) перед проведением повторной проверки и более эффективно выполнить обратное тестирование после проведения повторной проверки с целью убедиться в том, что все предыдущие проблемы разрешены.
<.>
Таблица D.6.
Характеристики SCO для ИТВ-тестирования версии 2
Источник проблем | Умеренный ( | Большой 0 1 дня) | ||
Интерпретация требований | ||||
Проблемы при независимом тестировании | ||||
Проблемы с интерфейсами | ||||
Неправильное выполнение | ||||
Желательное расширение (это не проблема) | ||||
Несовместимая конфигурация | ||||
Таблица D.7 и рис. D.11 позволяют взглянуть на метрики прогресса с различных точек зрения, которые применялись при планировании и отслеживании программы тестирования в проекте CCPDS-R. На рисунке изображен график зависимости прогресса относительно планируемого для тестирования соответствия требованиям. НТ-, ФТ- и ОКТ-тесты являлись источниками вариантов тестирования, использовавшимися организацией-разработчиком ПО. За НТ отвечали команды разработчиков, но оно должно было проводиться в формальной среде управления конфигурацией и под контролем (визуальным наблюдением) персонала, ответственного за тестирование. ФТ состояло из функционально связанных между собой групп сценариев, которые демонстрировали соответствие требованиям, охватывающим сразу несколько компонентов. ОКТ-тесты позволяли определять такие аспекты соответствия требованиям, которые не могли быть показаны до полного создания системы. Количественные требования к производительности (КТП) охватывали все CSCI.
Формальное НТ-тестирование (проверка на соответствие требованиям, выполняемая в форме независимого тестирования) оказалось более трудным, чем планировалось. Это произошло прежде всего из-за того, что спецификации требований и обзоры проекта оказались перегружены деталями, касающимися разработки, а также процедурами согласования.
Проведение формального НТ-тестирования тщательно контролировалось правительством и заняло чрезвычайно много времени на подготовку обзора. Правительство потребовало использовать подробнейшие процедуры тестирования для множества отдельных деталей проекта, которые на самом деле не следовало рассматривать как требования. В горячке разработки выполнение НТ-процедур редко когда оказывалось доступным за 30 - 60 дней до повторной проверки, как это предусматривал контракт для любых видов тестирования на соответствие требованиям. Процесс формального НТ-тестирования явился одной из основных причин того, что повторные рассмотрения постоянно завершались позже, чем было запланировано.
Таблица D.7.
Работа по проверке соответствия требованиям с помощью различных типов тестов для различных CSCI
Рис. D.11. Прогресс тестирования Подсистемы общего назначения
Тип теста | ||||||||
Версия 0/1 НТ | ||||||||
Версия 2 НТ | ||||||||
Версия 3/4/5 НТ | ||||||||
D.7.3 Стабильность.
На рис. D.12 приводится общий уровень изменений базовой конфигурации. Он показывает суммарное количество SLOC, признанных негодными (изъятых из базовой версии для доработки из-за обнаруженного дефекта, для расширения или для внесения другого вида изменений), и число восстановленных SLOC (тех, что были вновь включены в базовую версию с исправлениями, расширениями или какими-то другими изменениями). Скорость выявления дефектов, отличающаяся от скорости их исправления, приводила в результате к пристальному вниманию руководства, к изменению приоритетов при распределении ресурсов и к корректирующим мероприятиям, предпринимавшимся с целью убедиться в том, что отвечающая за тестирование организация (выявляющая дефекты) и организация-разработчик (выполняющая восстановление) находятся в относительном равновесии. В целом ситуация, изображенная на рисунке, относится к чрезвычайно благополучному проекту.
D.7.4 Коэффициент дефектности.
На рис. D.13 общее количество дефектов определяется относительно программной подсистемы в целом. Эта метрика оценивает суммарную дефектность, выявленную в процессе разработки Подсистемы общего назначения, приблизительно как 25% от объема всего продукта. В среднем в индустрии по созданию ПО средний объем дефектов колеблется в диапазоне от 40% до 60%. Начальная базовая конфигурация была создана к моменту ПОП, на 14 месяце. После этого в нее было внесено 1600 отдельных изменений.
Месяц выполнения контракта Рис. D.13. Коэффициент дефектности в Подсистеме общего назначения.
D.7.5 Адаптируемость
Для Подсистемы общего назначения в целом на доработку базовой версии ПО было затрачено около 5% от всего объема работ. Средняя стоимость внесения одного изменения составляла около 24 ч на один SCO. Эти значения позволяют оценить ту легкость, с которой могли вноситься изменения в базовую версию ПО. Уровень адаптируемости, достигнутый в рамках проекта CCPDS-R, был примерно в четыре раза выше, чем для обычных проектов, в которых затраты на доработки на протяжении жизненного цикла обычно превышают 20% от общего уровня затрат.
На рис. D.14 показана средняя стоимость одного изменения в процессе создания Подсистемы общего назначения. К моменту ОКТ было обработано 1600 SCO, касающихся изменения основ конфигурации, что привело к стабильной стоимости одного изменения. Проект CCPDS-R оказался одним из немногих контрпримеров утверждения: «чем более поздние стадии жизненного цикла вы проходите, тем больше дорогостоящих проблем обнаруживаете».
Большинство SCO на ранних этапах (на рис. D.14 они изображены в прямоугольнике с надписью «Изменения в проекте») являлись изменениями, затрагивающими большое число сотрудников и большое количество компонентов (изменения в интерфейсах и архитектуре). Более поздние SCO (обозначены как «Изменения в реализации») обычно касались одного человека и одного компонента. Последний участок кривой отражает нетипичное возрастание дефектов, что стало результатом большого технического предложения о полном изменении набора входящих сообщений для Подсистемы общего назначения. Эта область являлась одной из тех областей, внесение изменений в которые было не таким простым делом, как хотелось бы. Хотя проект был устойчивым и приспособленным к большому числу предусмотренных заранее сценариев внесения изменений, пересмотр всего набора входных сообщений никогда не предполагался, да и проект не был для этого приспособлен.
Рис. D.14. Адаптируемость Подсистемы общего назначения.
D.7.6 Завершенность.
К проекту CCPDS-R предъявлялись особенные требования по надежности, в связи с чем ПО было распределено особым образом. Выполняющая тестирование независимая команда создала автоматизированный набор тестов. Он проводился в неурочное время и испытывал базовую версию ПО по сценариям случайных сообщений. Такая стратегия привела к проведению широкого тестирования в условиях, близких к реальным на протяжении длительного времени. По результатам удалось определить значение MTBF для ПО. Критичные по надежности компоненты, принудительно перенесенные в плане итераций на самые ранние стадии, подвергались наиболее жесткому тестированию на надежность. Результаты показаны на рис. D.15.
Для современных распределенных архитектур такой способ статистического тестирования с одной стороны необходим для обеспечения максимального тестового покрытия, а с другой ~ полезен для обнаружения проблем, связанных с борьбой за ресурсы, тупиками, перегрузкой ресурсов, утечкой памяти и другими ошибками Гейзенберга. Выполнение случайных и ускоренных сценариев в течение длительных интервалов времени (на протяжении всей ночи или выходных) позволяет получить на ранних стадиях понимание общей целостности ресурсов системы.
Рис. D.15. Завершенность Подсистемы общего назначения.
D.7.7 Затраты финансов/работы на отдельные виды деятельности.
В таблице D.8 рассматривается общая подробная структура затрат на Подсистему общего назначения в проекте CCPDS-R. Эти данные были получены из окончательного WBS-набора затрат и структурированы в соответствии с рекомендациями, приведенными в разделе 10.1. Элементы более низкого уровня описываются в таблице D.9.
■ Проценты, указанные в таблице D.8, приблизительно соответствуют процентам, приведенным в главе 10. Однако некоторые из элементов таблицы D.9, касающихся управления, были распределены по нескольким элементам таблицы D.8 для выделения видов деятельности, находящихся на уровне управления проектом.
■ Общие трудозатраты команды, осуществлявшей тестирование, оказались относительно низкими по сравнению с затратами в проектах, использующих традиционный процесс. Основная причина такого положения дел заключается в том, что команда по разработке архитектуры передавала интегрированный программный продукт команде, которая выполняла тестирование и оценку и отвечала прежде всего за тестирование интегрированного продукта.
Таблица D.8.
Финансовые затраты на Подсистему общего назначения по WBS-элементам самого верхнего уровня
WBS-элемент |
Берг О.Ю.
МЕТРИКИ ОЦЕНКИ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Поскольку обработка данных затрагивает нашу жизнь всё в большей степени, ошибки ЭВМ могут теперь иметь такие последствия, как нанесение материального ущерба, нарушение секретности и многие другие, включая смерть. Надёжность программного обеспечения (ПО) есть вероятность его работы без отказов в течение определённого периода времени, рассчитанная с учётом стоимости для пользователя каждого отказа. Следовательно, необходимо иметь возможность измерять качество ПО на протяжении всего цикла разработки. Качество ПО целесообразно оценивать на основе критериев качества , которые должны:
Численно характеризовать основную целевую функцию программы;
Обеспечивать возможность определения затрат, необходимых для достижения требуемого уровня качества, а также степени влияния на показатель качества различных внешних факторов;
Быть по возможности простым, хорошо измеримым и иметь малую дисперсию.
Для измерения характеристик и критериев качества используют метрики. В настоящее время известно большое количество метрик, оценивающих отдельные производственные и эксплуатационные свойства ПО . Однако погоня за их универсальностью, игнорирование области применения разрабатываемого ПО, этапов жизненного цикла существенно снижает эффективность их использования.
Метрика качества программ - система измерений качества программ. Эти измерения могут проводиться на уровне критериев качества программ или на уровне отдельных характеристик качества. В первом случае система измерений позволяет непосредственно сравнивать программы по качеству. При этом сами измерения не могут быть проведены без субъективных оценок свойств программ. Во втором случае измерения характеристик можно выполнить объективно и достоверно, но оценка качества ПО в целом будет связана с субъективной интерпретацией получаемых оценок.
В исследовании метрик ПО различают два основных направления:
Поиск метрик, характеризующих наиболее специфические свойства программ, т.е. метрик оценки самого ПО;
Использование метрик для оценки технических характеристик и факторов разработки программ, т.е. метрик оценки условий разработки программ.
По виду информации, получаемой при оценке качества ПО метрики можно разбить на три группы :
Метрики, оценивающие отклонение от нормы характеристик исходных проектных материалов. Они устанавливают полноту заданных технических характеристик исходного кода.
Метрики, позволяющие прогнозировать качество разрабатываемого ПО. Они заданы на множестве
возможных вариантов решений поставленной задачи и их реализации и определяют качество ПО, которое
будет достигнуто в итоге.
Метрики, по которым принимается решение о соответствии конечного ПО заданным требованиям. Они позволяют оценить соответствие разработки заданным требованиям.
В настоящее время в мировой практике используется несколько сотен метрик программ. Существующие качественные оценки программ можно сгруппировать по шести направлениям:
Оценки топологической и информационной сложности программ;
Оценки надежности программных систем, позволяющие прогнозировать отказовые ситуации;
Оценки производительности ПО и повышения его эффективности путем выявления ошибок проектирования;
Оценки уровня языковых средств и их применения;
Оценки трудности восприятия и понимания программных текстов, ориентированные на
психологические факторы, существенные для сопровождения и модификации программ;
Оценки производительности труда программистов для прогнозирования сроков разработки программ и планирования работ по созданию программных комплексов.
В зависимости от характеристик и особенностей применяемых метрик им ставятся в соответствие различные измерительные шкалы:
Номинальной шкале соответствуют метрики, классифицирующие программы на типы по признаку наличия или отсутствия некоторой характеристики без учета градаций;
Порядковой шкале соответствуют метрики, позволяющие ранжировать некоторое характеристики путем сравнения с опорными значениями, т.е. измерение по этой шкале фактически определяет взаимное положение конкретных программ;
Интервальной шкале соответствуют метрики, которые показывают не только относительное положение программ, но и то, как далеко они отстоят друг от друга;
Относительной шкале соответствуют метрики, позволяющие не только расположить программы определенным образом и оценить их положение относительно друг друга, но и определить, как далеко оценки отстоят от границы, начиная с которой характеристика может быть измерена.
Анализ технологического опыта лидеров производства ПО показывает, насколько дорого обходится несовершенство ненаучного прогноза разрешимости и трудозатрат, сложности программ, негибкость контроля и управления их разработкой и многое другое, указывающее на отсутствие сквозной методической поддержки и приводящее в конечном итоге к его несоответствию требованиям пользователя, требуемому стандарту и к последующей болезненной и трудоемкой его переделке. Эти обстоятельства, требуют тщательного отбора методик, моделей, методов оценки качества ПО, учета ограничений их пригодности для различных жизненных циклов, установления порядка их совместного использования, применения избыточного разномодельного исследования одних и тех же показателей для повышения достоверности текущих оценок, накопления и интеграции разнородной метрической информации для принятия своевременных производственных решений и заключительной сертификации продукции.
В заключение, необходимо отметить, что при выборе метрик оценки качества ПО необходимо руководствоваться следующими правилами :
метрика должна иметь смысл, как для заказчика, так и для исполнителя;
метрика должна быть объективна и ее определение недвусмысленно;
метрика должна давать возможность отслеживать тенденцию изменений;
метрика может быть автоматизирована.
Тщательно проведенный метрический анализ качества в соответствии с целями разработки создает основу для корректного планирования и контроля затрат на качество для достижения требуемых показателей и эффективности использования ресурсов.
ЛИТЕРАТУРА
1. Liu K., Zhou S. Yang H., Quality Metrics of Object Oriented Design for Software Development and Re-development,- Proceedings of the First Asia-Pacific Conference on Quality Software, 2000 IEEE
2. Boehm B. W., Brown J. R., Lipow M. QUANTITATIVE EVALUATION OF SOFTWARE QUALITY Proceedings of the 2nd International Conference on Software Engineering on International conference on software engineering October 1976
3. Houdek F., Kempter H. Quality patterns - An approach to packaging software engineering experience ACM SIGSOFT Software Engineering Notes , Proceedings of the 1997 symposium on Symposium on software reusability May 1997
4. У. Ройс Управление проектами по созданию программного обеспечения, Москва, ЛОРИ
