Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».
Создаем отчет. В метриках выбираем, «Достижение целей» – «Цель, на которую у вас настроена конверсия». Обычно это страница «Спасибо за покупку».
В итоге получим данные о том, сколько по каждой РК было покупок и сколько было потрачено на привлечение пользователей, их совершивших. Количество конверсий делим на стоимость кликов, получаем стоимость одного лида. Если у вас настроена , можно добавить столбец «Доход», чтобы оценить полученную прибыль.
Сегменты для ретаргетинга и корректировки ставок: новый уровень отношений с потенциальными покупателями
В этом разделе мы создадим и сохраним Яндекс.Метрики, определим корректировки, чтобы использовать их при настройке кампаний в Директе.
Не забывайте выставлять период времени так, чтобы выборка была репрезентативна. Нужно, чтобы данные строились на основе поведения большой группы посетителей.
Пол и возраст – корректировка
После создания этого отчета мы сможем увидеть, кто лучше покупает у нас на сайте, мужчины или женщины, и каков возраст таких покупателей. После этого ничто не помешает нам установить корректировку ставок на данный сегмент.
Выбираем: «Отчеты» – «Посетители» – «Пол» (1).
В итоге делаем корректировку на женщин. При этом полученные данные помогли нам увидеть, что представители сильного пола тоже проводят время на нашем сайте. С этой информацией нужно работать. Например, написать соответствующие объявления.
Время и часы – корректировка
У ваших посетителей может быть разная активность в течение дня или недели, поэтому в данном пункте мы выявим наиболее конверсионные дни и часы для вашего ресурса, после чего можно будет установить корректировки по времени в Директе.
«Отчеты» – «Посетители» – «Посещаемость по времени суток».
В группировках добавляем: Поведение: дата и время – «Фрагменты даты/времени» – «День недели визита»(2). Выбираем цель – сортируем по конверсии. Получаем отчет, в котором показано, в какой день и в каком часу она (конверсия) максимальна.
География
«Отчеты» – «Посетители» – «География».
Отчет поможет сайтам определить регионы, в которых продажи идут лучше, чем в других. Обычно для многих ниш львиную долю продаж приносят Москва или Петербург и их области. Поэтому основная масса рекламодателей разделяет свои РК на города федерального значения и остальную Россию.
Отчет по географии поможет вам найти курс для дальнейшего дробления кампаний в Директе или выявить региональные РК со слабой отдачей.
Сегмент «Забытая корзина»
Создаем: «Отчеты» – «Посетители» – «Время с первого визита».
В целях выберем макроцель – покупка, запись на консультацию в офисе и т. д. Сортируем по конверсии. Выбираем первые 2 строки для построения графика. В итоге получим информацию о том, сколько времени наши клиенты тратят на обдумывание решения о покупке. Кроме того, мы сможем использовать данные в интерфейсе Директа, чтобы не показывать рекламу тем, кто уже не нуждается в нашем предложении.
Из отчета видим, что в основном цель достигается в день визита, но и на протяжении месяца пользователи возвращаются и конвертируются.
Теперь сам сегмент. Создадим его для тех, кто оставил товар в корзине, но так и не купил.
Зайдем в уже знакомый отчет «Источники» – «Сводка», оставляем галочку только в графе «Переходы с рекламы», нажимаем + и в меню выбираем: «Поведение» – «Достижение целей» – «Цель: добавил в корзину» (цель javascript должна быть настроена на кнопки «Добавить в корзину»). Сохраняем и называем сегмент, теперь переходим в Директ.
Находим объявление, которое хотим показать этому сегменту, щелкаем в «Условия подбора аудитории», затем – в «Добавить условие».
Отчеты для анализа сайта: изучаем и улучшаем
Вебвизор
Его данные помогут нам выявить слабые места сайта, понять, какие трудности возникают у пользователей.
Рассмотрим сегменты Вебвизора для визитов, в которых была достигнута наша макроцель.
Сделаем выборку и посмотрим, как пользователи достигали ее. Возможно, мы поймем поведенческие паттерны наших покупателей, о которых мы и не догадывались. Вдруг перед отправкой заказа большинство из них просматривало альбом с фото или взаимодействовало с интерактивными элементами на сайте, а, может быть, долго останавливалось на отзывах? Такие данные помогут решить, как правильно расположить и оформить блоки на сайте.
Второй сегмент – пользователи, которые провели достаточно времени на нашем сайте, чтобы совершить покупку, но так и не совершили. Анализ подобных визитов даст понимание основных сложностей, с которыми сталкиваются посетители.
Карты скроллинга / кликов
Карта скроллинга поможет понять, на каком экране посетители проводят больше времени. Возможно, какая-то нужная информация, которая поможет принять решение о покупке, находится в «холодной зоне» и ее нужно перенести в другое место. Например, клиент рекламируется только по запросам с указанием станции метро, а карта с адресом и схемой проезда расположена внизу страницы.
Результат – большой процент отказов, потому что клиентам, приходящим по таким запросам, важно местоположение офиса организации.
Кроме 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) - оценка необходимых интеллектуальных усилий при разработке программы, характеризующая число требуемых элементарных решений при написании программы
При применении метрик Холстеда частично компенсируются недостатки, связанные с возможностью записи одной и той же функциональности разным количеством строк и операторов.
Еще одним типом метрик ПО, относящихся к количественным, являются метрики Джилба. Они показывают сложность программного обеспечения на основе насыщенности программы условными операторами или операторами цикла. Данная метрика, не смотря на свою простоту, довольно хорошо отражает сложность написания и понимания программы, а при добавлении такого показателя, как максимальный уровень вложенности условных и циклических операторов, эффективность данной метрики значительно возрастает.
2. Метрики сложности потока управления программы
Следующий большой класс метрик, основанный уже не на количественных показателях, а на анализе управляющего графа программы, называется метрики сложности потока управления программ.Перед тем как непосредственно описывать сами метрики, для лучшего понимания будет описан управляющий граф программы и способ его построения.
Пусть представлена некоторая программа. Для данной программы строится ориентированный граф, содержащий лишь один вход и один выход, при этом вершины графа соотносят с теми участками кода программы, в которых имеются лишь последовательные вычисления, и отсутствуют операторы ветвления и цикла, а дуги соотносят с переходами от блока к блоку и ветвями выполнения программы. Условие при построении данного графа: каждая вершина достижима из начальной, и конечная вершина достижима из любой другой вершины .
Самой распространенной оценкой, основанной на анализе получившегося графа, является цикломатическая сложность программы (цикломатическое число Мак-Кейба) . Она определяется как 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 - общее число вершин графа программы.
Существует метрика Шнейдевинда, выражающаяся через число возможных путей в управляющем графе.
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(v j)), j=i...||V(i)||
Где DEF(v j) - число определяющих вхождений переменной v j из множества 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=СУММАf i *log 2 p i , где f i - частота появления i-го символа, p i - вероятность его появления.
Недостатком данной метрики является то, что программа, содержащая много уникальных символов, но в малом количестве, будет иметь такую же сложность как программа, содержащая малое количество уникальных символов, но в большом количестве.
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=СУММА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|. Недостаток сцепления может быть сигналом того, что класс можно разбить на несколько других классов или подклассов, так что для повышения инкапсуляции данных и уменьшения сложности классов и методов лучше повышать сцепление.
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).
Используемые метрики в каждом варианте выбираются в зависимости от конкретной задачи, коэффициенты - в зависимости от значения метрики для принятия решения в данном случае.
Заключение
Подводя итог, хотелось бы отметить, что ни одной универсальной метрики не существует. Любые контролируемые метрические характеристики программы должны контролироваться либо в зависимости друг от друга, либо в зависимости от конкретной задачи, кроме того, можно применять гибридные меры, однако они так же зависят от более простых метрик и также не могут быть универсальными. Строго говоря, любая метрика - это лишь показатель, который сильно зависит от языка и стиля программирования, поэтому ни одну меру нельзя возводить в абсолют и принимать какие-либо решения, основываясь только на ней.Черников Алексей
1. Введение
В отличие от большинства отраслей материального производства, в вопросах проектов создания ПО недопустимы простые подходы, основанные на умножении трудоемкости на среднюю производительность труда. Это вызвано, прежде всего, тем, что экономические показатели проекта нелинейно зависят от объема работ, а при вычислении трудоемкости допускается большая погрешность.
Поэтому для решения этой задачи используются комплексные и достаточно сложные методики, которые требуют высокой ответственности в применении и определенного времени на адаптацию (настройку коэффициентов).
Современные комплексные системы оценки характеристик проектов создания ПО могут быть использованы для решения следующих задач:
- предварительная, постоянная и итоговая оценка экономических параметров проекта: трудоемкость, длительность, стоимость;
- оценка рисков по проекту: риск нарушения сроков и невыполнения проекта, риск увеличения трудоемкости на этапах отладки и сопровождения проекта и пр.;
- принятие оперативных управленческих решений – на основе отслеживания определенных метрик проекта можно своевременно предупредить возникновение нежелательных ситуаций и устранить последствия непродуманных проектных решений.
1 Введение
2 Метрики
2.1 Размерно-ориентированные метрики (показатели оценки объема)
2.1.1 LOC-оценка (Lines Of Code)
2.1.1.1 Метрика стилистики и понятности программ
2.1.2 Итого по SLOC
2.2 Метрики сложности
2.2.2 Метрики Холстеда
2.2.4 Метрики Чепина
2.4 Общий списочный состав метрик
2.4 Подведение итогов
6 Ресурсы интернет
2. Метрики
Метрики сложности программ принято разделять на три основные группы:
- метрики размера программ;
- метрики сложности потока управления программ;
- метрики сложности потока данных программ.
Метрики первой группы базируются на определении количественных характеристик, связанных с размером программы, и отличаются относительной простотой. К наиболее известным метрикам данной группы относятся число операторов программы, количество строк исходного текста, набор метрик Холстеда. Метрики этой группы ориентированы на анализ исходного текста программ. Поэтому они могут использоваться для оценки сложности промежуточных продуктов разработки.
Метрики второй группы базируются на анализе управляющего графа программы. Представителем данной группы является метрика Маккейба.
Управляющий граф программы, который используют метрики данной группы, может быть построен на основе алгоритмов модулей. Поэтому метрики второй группы могут применяться для оценки сложности промежуточных продуктов разработки.
Метрики третьей группы базируются на оценке использования, конфигурации и размещения данных в программе. В первую очередь это касается глобальных переменных. К данной группе относятся метрики Чепина.
2.1 Размерно - ориентированные метрики (показатели оценки объема)
2.1.1 LOC-оценка (Lines Of Code)
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках.
Этот вид метрик косвенно измеряет программный продукт и процесс его разработки. Вместо подсчета LOC-оценок при этом рассматривается не размер, а функциональность или полезность продукта.
Наибольшее распространение в практике создания программного обеспечения получили размерно-ориентированные метрики. В организациях, занятых разработкой программной продукции для каждого проекта принято регистрировать следующие показатели:
- общие трудозатраты (в человеко-месяцах, человеко-часах);
- объем программы (в тысячах строках исходного кода -LOC);
- стоимость разработки;
- объем документации;
- ошибки, обнаруженные в течение года эксплуатации;
- количество людей, работавших над изделием;
- срок разработки.
На основе этих данных обычно подсчитываются простые метрики для оценки производительности труда (KLOC/человеко-месяц) и качества изделия.
Эти метрики не универсальны и спорны, особенно это относится к такому показателю как LOC, который существенно зависит от используемого языка программирования.
Количество строк исходного кода (Lines of Code – LOC, Source Lines of Code – SLOC) является наиболее простым и распространенным способом оценки объема работ по проекту.
Изначально данный показатель возник как способ оценки объема работы по проекту, в котором применялись языки программирования, обладающие достаточно простой структурой: «одна строка кода = одна команда языка». Также давно известно, что одну и ту же функциональность можно написать разным количеством строк, а если возьмем язык высокого уровня (С++, Java), то возможно и в одной строке написать функционал 5-6 строк – это не проблема. И это было бы полбеды: современные средства программирования сами генерируют тысячи строк кода на пустяковую операцию.
Потому метод LOC является только оценочным методом (который надо принимать к сведению, но не опираться в оценках) и никак не обязательным.
В зависимости от того, каким образом учитывается сходный код , выделяют два основных показателя SLOC:
- количество «физических» строк кода – SLOC (используемые аббревиатуры LOC, SLOC, KLOC, KSLOC, DSLOC) – определяется как общее число строк исходного кода, включая комментарии и пустые строки (при измерении показателя на количество пустых строк, как правило, вводится ограничение – при подсчете учитывается число пустых строк, которое не превышает 25% общего числа строк в измеряемом блоке кода).
- Количество «логических» строк кода – SLOC (используемые аббревиатуры LSI, DSI, KDSI, где «SI» - source instructions) – определяется как количество команд и зависит от используемого языка программирования. В том случае, если язык не допускает размещение нескольких команд на одной строке, то количество «логических» SLOC будет соответствовать числу «физических», за исключением числа пустых строк и строк комментариев. В том случае, если язык программирования поддерживает размещение нескольких команд на одной строке, то одна физическая строка должна быть учтена как несколько логических, если она содержит более одной команды языка.
Для метрики SLOC существует большое число производных, призванных получить отдельные показатели проекта, основными среди которых являются:
- число пустых строк;
- число строк, содержащих комментарии;
- процент комментариев (отношение строк кода к строкам комментария, производная метрика стилистики);
- среднее число строк для функций (классов, файлов);
- среднее число строк, содержащих исходный код для функций (классов, файлов);
- среднее число строк для модулей.
2.1.1.1 Метрика стилистики и понятности программ
Иногда важно не просто посчитать количество строк комментариев в коде и просто соотнести с логическими строчками кода, а узнать плотность комментариев. То есть код сначала был документирован хорошо, затем – плохо. Или такой вариант: шапка функции или класса документирована и комментирована, а код нет.
Fi = SIGN (Nкомм. i / Ni – 0,1)
Суть метрики проста: код разбивается на n-равные куски и для каждого из них определяется Fi
2.1.2 Итого по SLOC
Потенциальные недостатки SLOC, на которые нацелена критика:
- некрасиво и неправильно сводить оценку работы человека к нескольким числовым параметрам и по ним судить о производительности. Менеджер может назначить наиболее талантливых программистов на сложнейший участок работы; это означает, что разработка этого участка займёт наибольшее время и породит наибольшее количество ошибок, из-за сложности задачи. Не зная об этих трудностях, другой менеджер по полученным показателям может решить, что программист сделал свою работу плохо.
- Метрика не учитывает опыт сотрудников и их другие качества
- Искажение: процесс измерения может быть искажён за счёт того, что сотрудники знают об измеряемых показателях и стремятся оптимизировать эти показатели, а не свою работу. Например, если количество строк исходного кода является важным показателем, то программисты будут стремиться писать как можно больше строк и не будут использовать способы упрощения кода, сокращающие количество строк (см. врезку про Индию).
- Неточность: нет метрик, которые были бы одновременно и значимы и достаточно точны. Количество строк кода - это просто количество строк, этот показатель не даёт представления о сложности решаемой проблемы. Анализ функциональных точек был разработан с целью лучшего измерения сложности кода и спецификации, но он использует личные оценки измеряющего, поэтому разные люди получат разные результаты.
И главное помнить: метрика SLOC не отражает трудоемкости по созданию программы
.
| Пример из жизни
: В одной из компаний при внедрении мы применили данную метрику – считали строки кода. Руководитель организации был в отпуске, но по возвращении из него решил воспользоваться прозрачностью и трассируемостью изменений и посмотреть, как же идут дела в проектах у его менеджеров. И чтоб полностью войти в курс , опустился на самый низкий уровень (то есть не стал оценивать плотность дефектов, количество исправленных багов) – на уровень исходных текстов. Решил посчитать, кто и сколько строк написал. А чтоб было совсем весело – соотнести количество рабочих дней в неделю и количество написанного кода (логика проста: человек работал 40 часов в неделю, значит, должен много чего написать). Естественно, нашелся человек, который за неделю написал всего одну строку, даже не написал, а только откорректировал существующую… Гневу руководителя не было предела – нашел бездельника! И плохо было бы программисту, если бы менеджер проекта не объяснил, что: была найдена ошибка в программе, нашел ее VIP- клиент, ошибка влияет на бизнес клиента и ее нужно было срочно устранить, для этого был выбран вот этот конкретный исполнитель, который развернул стенд, залил среду клиента, подтвердил проявление ошибки и начал ее искать и устранять. Естественно, в конце концов, он поменял фрагмент кода, в котором было неправильное условие и все заработало. |
Согласитесь, считать трудозатраты по данной метрике глупо – необходима комплексная оценка…
2.2 Метрики сложности
Помимо показателей оценки объема работ по проекту очень важными для получения объективных оценок по проекту являются показатели оценки его сложности. Как правило, данные показатели не могут быть вычислены на самых ранних стадиях работы над проектом, поскольку требуют, как минимум, детального проектирования. Однако эти показатели очень важны для получения прогнозных оценок длительности и стоимости проекта, поскольку непосредственно определяют его трудоемкость.
2.2.1 Объектно-ориентированные метрики
В современных условиях большинство программных проектов создается на основе ОО подхода, в связи с чем существует значительное количество метрик, позволяющих получить оценку сложности объектно-ориентированных проектов.
|
Метрика |
Описание |
| Взвешенная насыщенность класса 1 (Weighted Methods Per Class (WMC) | Отражает относительную меру сложности класса на основе цикломатической сложности каждого его метода. Класс с более сложными методами и большим количеством методов считается более сложным. При вычислении метрики родительские классы не учитываются. |
| Взвешенная насыщенность класса 2 (Weighted Methods Per Class (WMC2)) |
Мера сложности класса, основанная на том, что класс с большим числом методов, является более сложным, и что метод с большим количеством параметров также является более сложным. При вычислении метрики родительские классы не учитываются. |
| Глубина дерева наследования (Depth of inheritance tree) | Длина самого длинного пути наследования, заканчивающегося на данном модуле. Чем глубже дерево наследования модуля, тем может оказаться сложнее предсказать его поведение. С другой стороны, увеличение глубины даёт больший потенциал повторного использования данным модулем поведения, определённого для классов-предков.
|
| Количество детей (Number of children) | Число модулей, непосредственно наследующих данный модуль.Большие значения этой метрики указывают на широкие возможности повторного использования; при этом слишком большое значение может свидетельствовать о плохо выбранной абстракции . |
|
Связность объектов (Coupling between objects) |
Количество модулей, связанных с данным модулем в роли клиента или поставщика. Чрезмерная связность говорит о слабости модульной инкапсуляции и может препятствовать повторному использованию кода. |
| Отклик на класс (Response For Class) | Количество методов, которые могут вызываться экземплярами класса; вычисляется как сумма количества локальных методов, так и количества удаленных методов |
2.2.2 Метрики Холстеда
Метрика Холстеда относится к метрикам, вычисляемым на основании анализа числа строк и синтаксических элементов исходного кода программы.
Основу метрики Холстеда составляют четыре измеряемые характеристики программы:
- NUOprtr (Number of Unique Operators) - число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов);
- NUOprnd (Number of Unique Operands) - число уникальных операндов программы (словарь операндов);
- Noprtr (Number of Operators) - общее число операторов в программе;
- Noprnd (Number of Operands) - общее число операндов в программе.
На основании этих характеристик рассчитываются оценки:
- Словарь программы
(Halstead Program Vocabulary, HPVoc): HPVoc = NUOprtr + NUOprnd; - Длина программы
(Halstead Program Length, HPLen): HPLen = Noprtr + Noprnd; - Объем программы
(Halstead Program Volume, HPVol): HPVol = HPLen log2 HPVoc; - Сложность программы
(Halstead Difficulty, HDiff): HDiff = (NUOprtr/2) × (NOprnd / NUOprnd); - На основе показателя HDiff предлагается оценивать усилия программиста при разработке при помощи показателя HEff (Halstead Effort)
: HEff = HDiff × HPVol.
2.2.3 Метрики цикломатической сложности по Мак-Кейбу
Показатель цикломатической сложности является одним из наиболее распространенных показателей оценки сложности программных проектов. Данный показатель был разработан ученым Мак-Кейбом в 1976 г., относится к группе показателей оценки сложности потока управления программой и вычисляется на основе графа управляющей логики программы (control flow graph). Данный граф строится в виде ориентированного графа, в котором вычислительные операторы или выражения представляются в виде узлов, а передача управления между узлами – в виде дуг.
Показатель цикломатической сложности позволяет не только произвести оценку трудоемкости реализации отдельных элементов программного проекта и скорректировать общие показатели оценки длительности и стоимости проекта, но и оценить связанные риски и принять необходимые управленческие решения.
Упрощенная формула вычисления цикломатической сложности представляется следующим образом:
C = e – n + 2,
где e –
число ребер, а n –
число узлов
на графе управляющей логики.
Как правило, при вычислении цикломатической сложности логические операторы не учитываются.
В процессе автоматизированного вычисления показателя цикломатической сложности, как правило, применяется упрощенный подход, в соответствии с которым построение графа не осуществляется, а вычисление показателя производится на основании подсчета числа операторов управляющей логики (if, switch и т.д.) и возможного количества путей исполнения программы.
Цикломатическое число Мак-Кейба показывает требуемое количество проходов для покрытия всех контуров сильносвязанного графа или количества тестовых прогонов программы, необходимых для исчерпывающего тестирования по принципу «работает каждая ветвь».
Показатель цикломатической сложности может быть рассчитан для модуля, метода и других структурных единиц программы.
Существует значительное количество модификаций показателя цикломатической сложности.
- «Модифицированная» цикломатическая сложность – рассматривает не каждое ветвление оператора множественного выбора (switch), а весь оператор как единое целое.
- «Строгая» цикломатическая сложность – включает логические операторы.
- «Упрощенное» вычисление цикломатической сложности – предусматривает вычисление не на основе графа, а на основе подсчета управляющих операторов.
2.2.4 Метрики Чепина
Существует несколько ее модификаций. Рассмотрим более простой, а с точки зрения практического использования – достаточно эффективный вариант этой метрики.
Суть метода состоит в оценке информационной прочности отдельно взятого программного модуля с помощью анализа характера использования переменных из списка ввода-вывода.
Все множество переменных, составляющих список ввода-вывода, разбивается на четыре функциональные группы.
Q = a1P + a2M + a3C + a4T, где a1, a2, a3, a4 – весовые коэффициенты.
Q = P + 2M + 3C + 0.5T.
2.3 Предварительная оценка на основе статистических методов в зависимости от этапов разработки программы
При использовании интегрированных инструментальных средств у компаний, разрабатывающих типовые решения (под эту категорию попадают так называемые «инхаузеры» – компании, занимающиеся обслуживанием основного бизнеса) появляется возможность строить прогнозы сложности программ, основываясь на собранной статистике. Статистический метод хорошо подходит для решения подобных типовых задач и практически не подходит для прогноза уникальных проектов. В случае уникальных проектов применяются иные подходы, обсуждение которых находится за рамками данного материала.
Типовые задачи как из рога изобилия падают на отделы разработки из бизнеса, потому предварительная оценка сложности могла бы сильно упростить задачи планирования и управления, тем более что есть накопленная база по проектам, в которой сохранены не только окончательные результаты, но и все начальные и промежуточные.
Выделим типовые этапы в разработке программ:
- разработка спецификации требований к программе;
- определение архитектуры;
- проработка модульной структуры программы, разработка интерфейсов между модулями. Проработка алгоритмов;
- разработка кода и тестирование.
Теперь попробуем рассмотреть ряд метрик, часто используемых для предварительной оценки на первых двух этапах.
2.3.1 Предварительная оценка сложности программы на этапе разработки спецификации требований к программе
Для оценки по результатам работы данного этапа может быть использована метрика прогнозируемого числа операторов Nпрогн программы:
Nпрогн =NF*Nед
Где: NF – количество функций или требований в спецификации требований к разрабатываемой программе;
Nед – единичное значение количества операторов (среднее число операторов, приходящихся на одну среднюю функцию или требование). Значение Nед - статистическое.
2.3.2 Предварительная оценка сложности на этапе определения архитектуры
Си = NI / (NF * NIед * Ксл)
Где:
NI – общее количество переменных, передаваемых по интерфейсам между компонентами программы (также является статистической);
NIед–единичное значение количества переменных, передаваемых по интерфейсам между компонентами (среднее число передаваемых по интерфейсам переменных, приходящихся на одну среднюю функцию или требование);
Ксл – коэффициент сложности разрабатываемой программы, учитывает рост единичной сложности программы (сложности, приходящейся на одну функцию или требование спецификации требований к программе) для больших и сложных программ по сравнению со средним ПС.
2.4 Общий списочный состав метрик
Таблица 1 содержит краткое описание метрик, не вошедших в детальное описание выше, но тем не менее даные метрики нужны и важны, просто по статистике они встречаются гораздо реже.
Также отметим, что цель этой статьи показать принцип, а не описать все возможные метрики во множестве комбинаций.
Поскольку количественные методы хорошо зарекомендовали себя в других областях, многие теоретики и практики информатики пытались перенести данный подход и в разработку программного обеспечения . Как сказал Том ДеМарко, «вы не можете контролировать то, что не можете измерить».
Метрики
Набор используемых метрик включает:
- порядок роста (имеется в виду анализ алгоритмов в терминах асимптотического анализа и O-нотации),
- анализ функциональных точек,
- количество ошибок на 1000 строк кода,
- степень покрытия кода тестированием,
- количество классов и интерфейсов ,
- метрики программного пакета от Роберта Сесиль Мартина,
Критика
Потенциальные недостатки подхода, на которые нацелена критика:
- Неэтичность: Утверждается, что неэтично судить о производительности программиста по метрикам, введенным для оценки эффективности программного кода. Такие известные метрики, как количество строк кода и цикломатическая сложность, часто дают поверхностное представление об "удачности" выбора того или иного подхода при решении поставленных задач, однако, нередко они рассматриваются, как инструмент оценки качества работы разработчика. Такой подход достаточно часто приводит к обратному эффекту, приводя к появлению в коде более длинных конструкций и избыточных необязательных методов.
- Замещение «управления людьми» на «управление цифрами», которое не учитывает опыт сотрудников и их другие качества
- Искажение: Процесс измерения может быть искажён за счёт того, что сотрудники знают об измеряемых показателях и стремятся оптимизировать эти показатели, а не свою работу. Например, если количество строк исходного кода является важным показателем, то программисты будут стремиться писать как можно больше строк и не будут использовать способы упрощения кода, сокращающие количество строк.
- Неточность: Нет метрик, которые были бы одновременно и значимы и достаточно точны. Количество строк кода - это просто количество строк, этот показатель не даёт представление о сложности решаемой проблемы. Анализ функциональных точек был разработан с целью лучшего измерения сложности кода и спецификации, но он использует личные оценки измеряющего, поэтому разные люди получат разные результаты.
См. также
- Основные метрики кода: LOC, SLOC, Джилб, Маккейб, Холстед, ООП и другие
Wikimedia Foundation . 2010 .
- Одометр
- Стетоскоп
Смотреть что такое "Метрика программного обеспечения" в других словарях:
Качество программного обеспечения
Оценка затрат на разработку программного обеспечения - При разработке программного обеспечения очень важной является проблема оценки материальных затрат и/или затрат времени на успешное завершение проекта. Существует множество методов для выполнения такой оценки, среди которых можно выделить общие… … Википедия
Метрика - имеет несколько значений: В математике Метрика функция, определяющая расстояния в метрическом пространстве. Метрика альтернативное название метрического тензора, в частности Метрика пространства времени 4 тензор, который… … Википедия
Покрытие кода - У этого термина существуют и другие значения, см. Покрытие. Покрытие кода мера, используемая при тестировании программного обеспечения. Она показывает процент, насколько исходный код программы был протестирован. Техника покрытия кода была… … Википедия
Количество строк кода - См. также: Объем кода Количество строк кода (англ. Source Lines of Code SLOC) это метрика программного обеспечения, используемая для измерения его объёма с помощью подсчёта количества строк в тексте исходного кода. Как правило,… … Википедия
Нагрузочное тестирование - (англ. Load Testing) определение или сбор показателей производительности и времени отклика программно технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе … Википедия
Тестирование производительности - В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия
Scrum - Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия
Цикломатическая сложность - программы (англ. Cyclomatic complexity of a program) структурная (или топологическая) мера сложности программ, используемая для измерения качества программного обеспечения, основанная на методах статического анализа кода. ЦСП равна… … Википедия
Zabbix - 1.1 alpha 6 running under GNU/Linux … Википедия
Приветствую вас, друзья. После длительного этапа разработки и еще более длительного бета-тестирования, новая Яндекс Метрика 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* (операторы-звездочки обозначают любой набор символов с двух сторон от этого слова).
Итого: графики и таблица с информацией перестроятся нужным нам образом, готовым к выгрузке или анализу. На лету можно изменять, убирать или добавлять новые уровни уточнения - выводимая информация будет обновляться «на лету».
Тут же мы можем сравнить полученный сегмент с другим, воспользовавшись инструментом «Сравнить сегменты» - «Заданным вручную». Впрочем, мы можем не менять состав сегмента, а просто сравнить несколько периодов одного среза через опцию «Предыдущим периодом».
Здесь же не остались забыты и старые добрые «Цели», которые мы можем использовать в качестве еще одного уточняющего параметра для построения сегмента.
Количество вариантов построения сегментов практически не ограничено. Далее мы можем проанализировать полученную информацию и забыть про выборку, либо же сохранить её и получать доступ к ней в дальнейшем из меню «Отчеты» - «Мои отчеты», ну или просто выгрузить данные.
Вебвизор Яндекс Метрики
Вышеописанный процесс сегментации пришелся очень кстати для этого инструмента. Отбор записей посещений интересующих групп пользователей стал еще проще. Порядок тот же - переходим в «Вебвизор», настраиваем сегмент (или подгружаем его из сохраненных), смотрим.
На этом я заканчиваю этот обзор-инструкцию, и как обычно жду ваших вопросов в комментариях.
