Анализ основных отчетов Яндекс.Метрики: предупреждён и вооружён. Главные метрики

23.05.2019

Что можно отслеживать с помощью Метрики

Привлечение посетителей

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

Например, вы можете улучшить фразы: добавить ключевые фразы из релевантных поисковых запросов и минус-слова из нерелевантных запросов - это поможет привлечь более заинтересованных посетителей и повысить CTR.

Аудитория сайта

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

Достижение целей и конверсии

Важно не просто привести на свой сайт посетителей, а понять, становятся ли они реальными клиентами. Для этого в Метрике нужно настроить цели - то есть определить ключевые действия, которые должны выполнить посетители сайта.

Например, вашим покупателем может стать посетитель, который:

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

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

Выручка

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

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

Целевые звонки

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

Как начать собирать статистику

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

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

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

Как работает разметка ссылок

Внимание. Если в параметрах кампании не заполнено поле Счетчики Метрики , и при этом выключена опция Размечать ссылки для Метрики , то данные о кликах по объявлениям не будут попадать в Метрику, а данные из Метрики не будут попадать в статистику Директа.

Вопросы и ответы

Как быстро обновляются данные в отчетах Метрики?

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

Как быстро в Директ попадают данные о достижении целей?

Данные о достижении конкретной цели попадают в Директ в течение суток.

Почему отличаются данные в статистике Директа и в Метрике?

Аннотация

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

Введение

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

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

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

1. Количественные метрики

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

Кроме SLOC к количественным характеристикам относят также:

количество пустых строк,

количество комментариев,

процент комментариев (отношение числа строк, содержащих комментарии к общему количеству строк, выраженное в процентах),

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

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

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

Иногда дополнительно различают оценку стилистики программы (F). Она заключается в разбиении программы на n равных фрагментов и вычислении оценки для каждого фрагмента по формуле Fi = SIGN (Nкомм.i / Ni - 0,1), где Nкомм.i - количество комментариев в i-м фрагменте, Ni - общее количество строк кода в i-м фрагменте. Тогда общая оценка для всей программы будет определяться следующим образом: F = СУММАFi .

Также к группе метрик, основанных на подсчете некоторых единиц в коде программы, относят метрики Холстеда . Данные метрики основаны на следующих показателях:

n1 - число уникальных операторов программы, включая символы-

разделители, имена процедур и знаки операций (словарь операторов),

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

N1 - общее число операторов в программе,

N2 - общее число операндов в программе,

n1" - теоретическое число уникальных операторов,

n2" - теоретическое число уникальных операндов.

Учитывая введенные обозначения, можно определить:

n=n1+n2 - словарь программы,

N=N1+N2 - длина программы,

n"=n1"+n2" - теоретический словарь программы,

N"= n1*log2 (n1) + n2*log2 (n2) - теоретическая длина программы (для стилистически корректных программ отклонение N от N" не превышает 10%)

V=N*log2 n - объем программы,

V"=N"*log2 n" - теоретический объем программы, где n* - теоретический словарь программы.

L=V"/V - уровень качества программирования, для идеальной программы L=1

L"= (2 n2)/ (n1*N2) - уровень качества программирования, основанный лишь на параметрах реальной программы без учета теоретических параметров,

EC =V/(L")2 - сложность понимания программы,

D=1/ L" - трудоемкость кодирования программы,

y" = V/ D2 - уровень языка выражения

I=V/D - информационное содержание программы, данная характеристика позволяет определить умственные затраты на создание программы

E=N" * log2 (n/L) - оценка необходимых интеллектуальных усилий при разработке программы, характеризующая число требуемых элементарных решений при написании программы

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

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

2. Метрики сложности потока управления программы

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

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

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

Самой распространенной оценкой, основанной на анализе получившегося графа, является цикломатическая сложность программы (цикломатическое число Мак-Кейба) . Она определяется как V(G)=e - n + 2p , где e - количество дуг, n - количество вершин, p - число компонент связности. Число компонентов связности графа можно рассматривать как количество дуг, которые необходимо добавить для преобразования графа в сильно связный. Сильно связным называется граф, любые две вершины которого взаимно достижимы. Для графов корректных программ, т. е. графов, не имеющих недостижимых от точки входа участков и "висячих" точек входа и выхода, сильно связный граф, как правило, получается путем замыкания дугой вершины, обозначающей конец программы, на вершину, обозначающую точку входа в эту программу. По сути V(G) определяет число линейно независимых контуров в сильно связном графе. Так что в корректно написанных программах p=1, и поэтому формула для расчета цикломатической сложности приобретает вид:

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

Для исправления данного недостатка Г. Майерсом была разработана новая методика. В качестве оценки он предложил взять интервал (эта оценка еще называется интервальной) , где 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 - общее число вершин графа программы.

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

3. Метрики сложности потока управления данными

Следующий класс метрик - метрики сложности потока управления данных.

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

Все множество переменных, составляющих список ввода-вывода, разбивается на 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(vj )), j=i...||V(i)||

где DEF(vj ) - число определяющих вхождений переменной vj из множества R(i), а ||V(i)|| - мощность множества V(i).

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

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

Первой из таких метрик является тестирующая М-Мера . Тестирующей мерой М называется мера сложности, удовлетворяющая следующим условиям:

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

Также мерой качества программного обеспечения служит связанность модулей программы . Если модули сильно связанны, то программа становится трудномодифицируемой и тяжелой в понимании. Данная мера не выражается численно. Виды связанности модулей:

Связанность по данным - если модули взаимодействуют через передачу параметров и при этом каждый параметр является элементарным информационным объектом. Это наиболее предпочтительный тип связанности (сцепления).

Связанность по структуре данных - если один модуль посылает другому составной информационный объект (структуру) для обмена данными.

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

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

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

Внешняя связанность - два модуля используют внешние данные, например коммуникационный протокол.

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

Отсутствие связанности - модули не взаимодействуют между собой.

Подклассовая связанность - отношение между классом-родителем и классом-потомком, причем потомок связан с родителем, а родитель с потомком - нет.

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

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

Следующая метрика из данного класса - Метрика Мак-Клура. Выделяются три этапа вычисления данной метрики:

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=СУММАfi *log2 pi , где fi - частота появления i-го символа, pi - вероятность его появления.

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

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

В связи с развитием объектно-ориентированных языков программирования появился новый класс метрик, также называемый объектно-ориентированными метриками. В данной группе наиболее часто используемыми являются наборы метрик Мартина и набор метрик Чидамбера и Кемерера. Для начала рассмотрим первую подгруппу.

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

Классы в пределах категории класса закрыты от любых попыток изменения все вместе. Это означает, что, если один класс должен измениться, все классы в этой категории с большой вероятностью изменятся. Если любой из классов открыт для некоторой разновидности изменений, они все открыты для такой разновидности изменений.

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

Ответственность, независимость и стабильность категории могут быть измерены путем подсчета зависимостей, которые взаимодействуют с этой категорией. Могут быть определены три метрики:

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=СУММАci , i=1...n, где ci - сложность 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}({Ri }), i=1...n , где M - все возможные методы класса, Ri - все возможные методы, которые могут быть вызваны i-м классом. Тогда RFC будет являться мощностью данного множества. Чем больше RFC, тем сложнее тестирование и отладка.

LCOM (Lack of cohesion in Methods) - недостаток сцепления методов. Для определения этого параметра рассмотрим класс C с n методами M1, M2, ... ,Mn, тогда {I1},{I2},...,{In} - множества переменных, используемых в данных методах. Теперь определим P - множество пар методов, не имеющих общих переменных; Q - множество пар методов, имеющих общие переменные. Тогда LCOM=|P|-|Q|. Недостаток сцепления может быть сигналом того, что класс можно разбить на несколько других классов или подклассов, так что для повышения инкапсуляции данных и уменьшения сложности классов и методов лучше повышать сцепление.

6. Метрики надежности

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

7. Гибридные метрики

В завершении необходимо упомянуть еще один класс метрик, называемых гибридными. Метрики данного класса основываются на более простых метриках и представляют собой их взвешенную сумму. Первым представителем данного класса является метрика Кокола. Она определяется следующим образом:

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).

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

Заключение

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

Библиографический список

Запись в блоге компании СиПроВер: "Наши практические исследования в области расчета метрик".
Понятие метрики. Направления применения метрик.
Метрические шкалы. Метрики сложности. Метрики стилистики. http://www.met-rix.narod.ru/
T.J. McCabe, "A complexity measure," IEEE Transactions on Software Engineering, vol. SE-2, no. 4, pp. 308-320, December, 1976.
Богданов Д.В., "Стандартизация жизненного цикла программных средств", СПб - 2000, 210 с.
Г.Н. Калянов. Консалтинг при автоматизации предприятий: Научно-практическое издание. Серия "Информатизация России на пороге XXI века". - М.: СИНТЕГ, 1997. - 320 с.
Черноножкин С.К., "Методы и инструменты метрической поддержки разработки качественных программ", автореферат, Новосибирск - 1998
Curtis R. Cook, "Information Theory Metric for Assembly Language"
Shyam R. Chidamber, Chris F. Kemerer, "A Metrics Suite for Object Oriented Design", 1994

Кроме SLOC к количественным характеристикам относят также:

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

Иногда дополнительно различают оценку стилистики программы (F). Она заключается в разбиении программы на n равных фрагментов и вычислении оценки для каждого фрагмента по формуле F i = SIGN (Nкомм. i / N i - 0,1), где Nкомм. i - количество комментариев в i-м фрагменте, N i - общее количество строк кода в i-м фрагменте. Тогда общая оценка для всей программы будет определяться следующим образом: F = СУММА F i .

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

E C =V/(L")2 - сложность понимания программы,

D=1/ L" - трудоемкость кодирования программы,

Y" = V/ D2 - уровень языка выражения

E=N" * log 2 (n/L) - оценка необходимых интеллектуальных усилий при разработке программы, характеризующая число требуемых элементарных решений при написании программы

2. Метрики сложности потока управления программы

Самой распространенной оценкой, основанной на анализе получившегося графа, является цикломатическая сложность программы (цикломатическое число Мак-Кейба) . Она определяется как V(G)=e - n + 2p, где e - количество дуг, n - количество вершин, p - число компонент связности. Число компонентов связности графа можно рассматривать как количество дуг, которые необходимо добавить для преобразования графа в сильно связный. Сильно связным называется граф, любые две вершины которого взаимно достижимы. Для графов корректных программ, т. е. графов, не имеющих недостижимых от точки входа участков и «висячих» точек входа и выхода, сильно связный граф, как правило, получается путем замыкания дугой вершины, обозначающей конец программы, на вершину, обозначающую точку входа в эту программу. По сути V(G) определяет число линейно независимых контуров в сильно связном графе. Так что в корректно написанных программах p=1, и поэтому формула для расчета цикломатической сложности приобретает вид:

V(G)=e - n + 2.

Данные меры учитывает уровень вложенности и протяженность программы.

Функциональная мера (SCOPE) программы - это сумма приведенных сложностей всех вершин управляющего графа.

SCORT может принимать разные значения для графов с одинаковым цикломатическим числом.

Метрика Пивоварского - очередная модификация меры цикломатической сложности. Она позволяет отслеживать различия не только между последовательными и вложенными управляющими конструкциями, но и между структурированными и неструктурированными программами. Она выражается отношением N(G) = v *(G) + СУММАPi, где v *(G) - модифицированная цикломатическая сложность, вычисленная так же, как и V(G), но с одним отличием: оператор CASE с n выходами рассматривается как один логический оператор, а не как n - 1 операторов.

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

Пусть G - управляющий граф программы с единственной начальной и единственной конечной вершинами.

Вершины первой группы назовем принимающими вершинами, а вершины второй группы - вершинами отбора.

Где S0 - относительная граничная сложность программы, Sa - абсолютная граничная сложность программы, v - общее число вершин графа программы.

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

3. Метрики сложности потока управления данными

Следующий класс метрик - метрики сложности потока управления данных.

Все множество переменных, составляющих список ввода-вывода, разбивается на 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

Пара «модуль-глобальная переменная» обозначается как (p,r), где p - модуль, имеющий доступ к глобальной переменной r. В зависимости от наличия в программе реального обращения к переменной r формируются два типа пар «модуль - глобальная переменная»: фактические и возможные. Возможное обращение к r с помощью p показывает, что область существования r включает в себя p.

Отношение числа фактических обращений к возможным определяется

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

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

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

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

На основе этих понятий вводится величина 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 - и читают, и обновляют информацию в структуре данных.

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

DF(i)=СУММА(DEF(v j)), j=i...||V(i)||

Где DEF(v j) - число определяющих вхождений переменной v j из множества R(i), а ||V(i)|| - мощность множества V(i).

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

Внешняя связанность - два модуля используют внешние данные, например коммуникационный протокол.

Отсутствие связанности - модули не взаимодействуют между собой.

Следующая метрика из данного класса - Метрика Мак-Клура. Выделяются три этапа вычисления данной метрики:

Y(P) - сложность управления вызовом из модуля P других модулей.

3. Общая сложность MP иерархической схемы разбиения программы на модули задаётся формулой:

MP = СУММА(M(P)) по всем возможным значениям P - модулям программы.

Также существует метрика, основанная на информационной концепции - мера Берлингера . Мера сложности вычисляется как M=СУММАf i *log 2 p i , где f i - частота появления i-го символа, p i - вероятность его появления.

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

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

1. Ca: Центростремительное сцепление. Количество классов вне этой категории, которые зависят от классов внутри этой категории.

3. I: Нестабильность: I = Ce / (Ca+Ce). Эта метрика имеет диапазон значений .

I = 0 указывает максимально стабильную категорию.

I = 1 указывает максимально не стабильную категорию.

A: Абстрактность: A = nA / nAll.

NA - количество_абстрактных_классов_в_категории.

NAll - oбщее_количество_классов_в_категории.

Значения этой метрики меняются в диапазоне .

Расстояние до главной последовательности: 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.

NOC (Number of children) - количество потомков (непосредственных), чем больше, тем выше абстракция данных.

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|. Недостаток сцепления может быть сигналом того, что класс можно разбить на несколько других классов или подклассов, так что для повышения инкапсуляции данных и уменьшения сложности классов и методов лучше повышать сцепление.

6. Метрики надежности

7. Гибридные метрики

H_M = (M + R1 * M(M1) +… + Rn * M(Mn)/(1 + R1 +… + Rn)

Где M - базовая метрика, Mi - другие интересные меры, Ri - корректно подобранные коэффициенты, M(Mi) - функции.

(структура, взаимодействие, объем, данные) СУММА(a, b, c, d).

(сложность интерфейса, вычислительная сложность, сложность ввода/вывода, читабельность) СУММА(x, y, z, p).

Заключение

Приветствую вас, друзья. После длительного этапа разработки и еще более длительного бета-тестирования, новая Яндекс Метрика 2.0 выходит из тени. С 22 июня она станет основным инструментом для сбора и анализа статистики, в то время как старая версия будет перенесена на поддомен old.metrika.yandex.ru, где будет доживать свои последние месяцы.

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

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

- Так посмотри через бета-метрику.
- Не хочу, боюсь я её.

Разговор со знакомым SEO-специалистом.

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

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

А теперь по порядку

На данный момент бета всё еще находится по адресу https://beta.metrika.yandex.ru/ и вид списка сайтов не претерпел кардинальных изменений за исключением нескольких дополнений и отображаемого процента прироста трафика относительно прошлого дня, который сейчас так заботливо убран из старой версии (мол, давайте, переходите-привыкайте).

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

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

Меню нового интерфейса Yandex Metrika

Пункты верхнего меню в представлении не нуждаются, а структура и некоторые пункты левого меню - да. Прежде всего, то, что нам известно:

Сводка - главная страница счетчика сайта.
Карты - карты кликов, скроллинга, ссылок и аналитики форм. В общем, большая часть содержимого пункта «Поведение» старой версии.
Настройка - собственно, настройки текущего счетчика Яндекс Метрики.

А вот последний пункт - «Отчеты» - краеугольный камень обновленного инструмента.

Мои отчеты - все созданные и сохраненные вами срезы.
Избранные - то же самое, только избранные (wake-up, Neo).
Стандартные отчет - вот здесь и обосновались все старые и до боли знакомые разделы. К ним мы еще вернемся дальше по материалу.

Интерфейс главной страницы счетчика

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

Можно выбрать готовый виджет из библиотеки или создать новый: показатель, круговую диаграмму, график или таблицу данных. Настроить срез выводимой в них информации и закрепить в нужной части экрана сводки путем простого drug&drop.

Работа с сегментами в Яндекс Метрике

Итак, мы подошли к главному - описанию схемы формирования отчетов. Первым делом мы переходим к упомянутым ранее стандартным отчетам («Отчеты» - «Стандартные отчет») и выбираем ту информацию, которую затем будем сегментировать. Например «Источники» - «Источники, сводка».

А теперь начинаем отбирать только те визиты, которые хотим анализировать. Например, мы хотим узнать количество людей, посетивших сайт с планшета из поисковой системы Яндекс по запросу, в составе которого есть слово «SEO». Для этого мы, соответственно, настраиваем три уровня сегментации:

«Сегментировать» - «Технологии» - «Устройства» - в открывшемся окне опций выбираем «Планшеты».
«Сегментировать» - «Источники» - «Последний источник» - «Поиск» - «Поисковая система» - в открывшемся окне опций выбираем «Яндекс».
«Сегментировать» - «Источники» - «Последний источник» - «Поиск» - «Поисковая фраза» - в открывшемся окне прописываем *SEO* (операторы-звездочки обозначают любой набор символов с двух сторон от этого слова).

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

Тут же мы можем сравнить полученный сегмент с другим, воспользовавшись инструментом «Сравнить сегменты» - «Заданным вручную». Впрочем, мы можем не менять состав сегмента, а просто сравнить несколько периодов одного среза через опцию «Предыдущим периодом».

Здесь же не остались забыты и старые добрые «Цели», которые мы можем использовать в качестве еще одного уточняющего параметра для построения сегмента.

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

Вебвизор Яндекс Метрики

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

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

5). Сопровождаемость

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

Cопровождаемость включает подхарактеристики:

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

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

– стабильность – атрибут, указывающие на риск модификации;

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

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

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

Переносимость включает подхарактеристики:

– адаптивность – атрибут, определяющий усилия, затрачиваемые на адаптацию к различным средам;

– настраиваемость (простота инсталлирования) – атрибут, который определяет на необходимые усилия для запуска или инсталляции данного ПО в специальной среде;

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

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

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

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

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

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

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

Согласно стандарта метрики определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика) и особенно на этапе тестирования или функционирования (внешние метрики) продукта.

Остановимся на классификации метрик ПО, правилах для проведения метрического анализа и процесса их измерения.

Типы метрик . Существует три типа метрик:

– метрики программного продукта, которые используются при измерении его характеристик – свойств;

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

– метрики использования.

Метрики программного продукта включают:

– внешние метрики, обозначающие свойства продукта, видимые пользователю;

– внутренние метрики, обозначающие свойства, видимые только команде разработчиков.

Внешние метрики продукта включают такие метрики:

– надежности продукта, которые служат для определения числа дефектов;

– функциональности, с помощью которых устанавливается наличие и правильность реализации функций в продукте;

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

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

– стоимости, которыми определяется стоимость созданного продукта.

Внутренние метрики продукта включают метрики:

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

– сложности, необходимые для определения сложности продукта;

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

Внутренние метрики позволяют определить производительность продукта и они являются релевантными по отношению к внешним метрикам.

Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования способов достижения качества конечного программного продукта.

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

– требований;

– сценариев и действующих лиц;

– объектов, включенных в сценарий, и локализация требований к каждому сценарию;

– параметров и операций объекта и др.

Стандарт ISO/IEC 9126–2 определяет следующие типы мер:

– мера размера ПО в разных единицах измерения (число функций, строк в программе, размер дисковой памяти и др.);

– мера времени (функционирования системы, выполнения компонента и др.);

– мера усилий (производительность труда, трудоемкость и др.);

– меры учета (количество ошибок, число отказов, ответов системы и др.).

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

– общее число объектов и число повторно используемых;

– общее число операций, повторно используемых и новых операций;

– число классов, наследующих специфические операции;

– число классов, от которых зависит данный класс;

– число пользователей класса или операций и др.

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

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

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

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

Метрики процессов включают метрики:

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

– оценки стоимости работ специалистов за человека–дни либо месяцы;

– ненадежности процесса – число не обнаруженных дефектов при проектировании;

– повторяемости, которые устанавливают степень использования повторных компонентов.

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

– общее время разработки и отдельно время для каждой стадии;

– время модификации моделей;

– время выполнения работ на процессе;

– число найденных ошибок при инспектировании;

– стоимость проверки качества;

– стоимость процесса разработки.

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

9.1.2. Стандартный метод оценки значений показателей качества

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

По определению стандарта ISO/IES 9126–2 метрика качества ПО представляет собой “модель измерения атрибута, связываемого с показателем его качества”. Для пользования метриками при измерения показателей качества данный стандарт позволяет определять следующие типы мер:

– меры размера в разных единицах измерения (количество функций, размер программы, объем ресурсов и др.);

– меры времени – периоды реального, процессорного или календарного времени (время функционирования системы, время выполнения компонента, время использования и др.);

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

– меры интервалов между событиями, например, время между последовательными отказами;

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

Метрики качества используются при оценки степени тестируемости после проведения испытаний ПО на множестве тестов (безотказная работа, выполнимость функций, удобство применения интерфейсов пользователей, БД и т.п.).

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

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

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

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

Т.е. при проведении оценки отдельного показателя с помощью оценочных элементов просчитывается весомый коэффициент k – метрика, j – показатель, i – атрибут. Например, в качестве j – показателя возьмем переносимость. Этот показатель будет вычисляться по пяти атрибутам (i = 1, ..., 5 ), причем каждый из них будет умножаться на соответствующий коэффициент k i .

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

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

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

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

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

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

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

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

– метрическая (1.1 – абсолютная, 1.2 – относительная, 1.3 – интегральная);

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

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

Показатели, вычисляемые с помощью метрических шкал, называются количественными, а с помощью порядковых и классификационных – качественными.

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

– номинальная шкала отражает категории свойств оцениваемого объекта без их упорядочения;

– порядковая шкала служит для упорядочивания характеристики по возрастанию или убыванию путем сравнения их с базовыми значениями;

– интервальная шкала задает существенные свойства объекта (например, календарная дата);

– относительная шкала задает некоторое значение относительно выбранной единицы;

– абсолютная шкала указывает на фактическое значение величины (например, число ошибок в программе равно 10).

9.1.3. Управление качеством ПС

Под управлением качества понимается совокупность организационной структуры и ответственных лиц, а также процедур, процессов и ресурсов для планирования и управления достижением качества ПС. Управление качеством – SQM (Software Quality Management) базируется на применении стандартных положений по гарантии качества – SQA(Software Quality Assurance) .

Цель процесса SQA состоит в гарантировании того, что продукты и процессы согласуются с требованиями, соответствуют планам и включает следующие виды деятельности:

– внедрение стандартов и соответствующих процедур разработки ПС на этапах ЖЦ;

– оценка соблюдения положений этих стандартов и процедур.

Гарантия качества состоит в следующем:

– проверка непротиворечивости и выполнимости планов;

– согласование промежуточных рабочих продуктов с плановыми показателями;

– проверка изготовленных продуктов заданным требованиям;

– анализ применяемых процессов на соответствие договору и планам;

– среда и методы разработки согласуются с заказом на разработку;

– проверка принятых метрик продуктов, процессов и приемов их измерения в соответствии с утвержденным стандартом и процедурами измерения.

Цель процесса управления SQM состоит в том, чтобы провести мониторинг (систематический контроль) качества для гарантии, что продукт будет удовлетворять потребителю и предполагает выполнение следующих видов деятельности:

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

– управление реализацией поставленных целей для достижения качества.

SQM основывается на гарантии того, что:

– цели достижения требуемого качества установлены для всех рабочих продуктов в контрольных точках продукта;

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

– определены и выполняются действия, связанные с предоставлением продуктам свойств качества;

– проводится контроль качества (SQA, верификация и валидация) и целей, если они не достигнуты, то проводится регулирование процессов;

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

Основные стандартные положения по созданию качественного продукта и оценки уровня достигнутого выделяют два процесса обеспечения качества на этапах ЖЦ ПС:

– гарантия (подтверждение) качества ПС, как результат определенной деятельности на каждом этапе ЖЦ с проверкой соответствия системы стандартам и процедурам, ориентированным на достижении качества;

– инженерия качества, как процесс предоставления продуктам ПО свойств функциональности, надежности, сопровождения и других характеристик качества.

Процессы достижения качества предназначены для:

а) управления, разработки и обеспечения гарантий в соответствии с указанными стандартами и процедурами;

б) управления конфигурацией (идентификация, учет состояния и действий по аутентификации), риском и проектом в соответствии со стандартами и процедурами;

в) контроль базовой версии ПС и реализованных в ней характеристик качества.

Выполнение указанных процессов включает такие действия:

– оценка стандартов и процедур, которые выполняются при разработке программ;

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

– контроль проведения формальных инспекций и просмотров;

– анализ и контроль проведения приемочного тестирования (испытания) ПС.

Для организации, которая занимается разработкой ПС в том числе из компонентов, инженерия качества ПС должна поддерживаться системой качества, управлением качеством (планирование, учет и контроль).

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

Система качества (Quality systems – QS) - это набор организационных структур, методик, мероприятий, процессов и ресурсов для осуществления управления качеством. Для обеспечения требуемого уровня качества ПО применяются два подхода. Один из них ориентирован на конечный программный продукт, а второй - на процесс создания продукта.

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

При втором подходе предусматриваются и принимаются меры по предотвращению, оперативному выявлению и устранению ошибок, начиная с начальных этапов ЖЦ в соответствии с планом и процедурами обеспечения качества разрабатываемой ПС. Этот подход представлен в серии стандартов ISO 9000 и 9000-1,2,3. Цель стандарта 9000–3 состоит в выдаче рекомендаций организациям-разработчикам создать систему качества по схеме, приведенной на рис.9.3.

Совместная

Система контроль Руководитель работа Ответственный

Качества от исполнителя от заказчика

Общая политика

Ответственность

и полномочия

Средства контроля

План достижения

качества ПС

Рис.9.3. Требования стандарта к организации системы качества

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

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

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

Обеспечение качества заключается в выполнении и проверки того, что объект разработки выполняет указанные требования к качеству. Цели обеспечения качества могут быть внутренние и внешние. Внутренние цели - создание уверенности у руководителя проекта, что качество обеспечивается. Внешние цели - это создание уверенности у пользователя, что требуемое качество достигнуто и результатом является качественное программное обеспечение.

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

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

9.2. Модели оценки надежности

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

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

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

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

ПрограммноеДокумент

Т.д. Цветная паутина, предлагаемая в учебниках , сложна для восприятия и понимания... его использования. М.М. Петрухин ГОУ ВПО « ... средства . На сегодняшний день в программной инженерии можно выделить два основных подхода к разработке программного обеспечения ...