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

Подписаться

Создаем отчет. В метриках выбираем, «Достижение целей» – «Цель, на которую у вас настроена конверсия». Обычно это страница «Спасибо за покупку».

В итоге получим данные о том, сколько по каждой РК было покупок и сколько было потрачено на привлечение пользователей, их совершивших. Количество конверсий делим на стоимость кликов, получаем стоимость одного лида. Если у вас настроена , можно добавить столбец «Доход», чтобы оценить полученную прибыль.

Сегменты для ретаргетинга и корректировки ставок: новый уровень отношений с потенциальными покупателями

В этом разделе мы создадим и сохраним Яндекс.Метрики, определим корректировки, чтобы использовать их при настройке кампаний в Директе.

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

Пол и возраст – корректировка

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

Выбираем: «Отчеты» – «Посетители» – «Пол» (1).

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

Время и часы – корректировка

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

«Отчеты» – «Посетители» – «Посещаемость по времени суток».

В группировках добавляем: Поведение: дата и время – «Фрагменты даты/времени» – «День недели визита»(2). Выбираем цель – сортируем по конверсии. Получаем отчет, в котором показано, в какой день и в каком часу она (конверсия) максимальна.

География

«Отчеты» – «Посетители» – «География».

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

Отчет по географии поможет вам найти курс для дальнейшего дробления кампаний в Директе или выявить региональные РК со слабой отдачей.

Сегмент «Забытая корзина»

Создаем: «Отчеты» – «Посетители» – «Время с первого визита».

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

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

Теперь сам сегмент. Создадим его для тех, кто оставил товар в корзине, но так и не купил.

Зайдем в уже знакомый отчет «Источники» – «Сводка», оставляем галочку только в графе «Переходы с рекламы», нажимаем + и в меню выбираем: «Поведение» – «Достижение целей» – «Цель: добавил в корзину» (цель javascript должна быть настроена на кнопки «Добавить в корзину»). Сохраняем и называем сегмент, теперь переходим в Директ.

Находим объявление, которое хотим показать этому сегменту, щелкаем в «Условия подбора аудитории», затем – в «Добавить условие».

Отчеты для анализа сайта: изучаем и улучшаем

Вебвизор

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

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

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

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

Карты скроллинга / кликов

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

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

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

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

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

Создание, использование и анализ метрик

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

1. Метрики по тестовым случаям (Test Cases)
2. Метрики по багам / дефектам
3. Метрики по задачам

Давайте более детально разберем каждую из них:

Метрики по тест кейсам

Метрики по багам

Хотим отметить, что метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" хорошо визуализируют степень приближения продукта к достижению критериев качества по багам. Имея требования к количеству открытых багов , после каждой итерации тестирования мы сравниваем их с реальными данными, тем самым видя места, где нам нужно прибавить, для скорейшего достижения цели.

Метрики "Reopened/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования.

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

1. Некачественное поверхностное решение проблемы (фикс бага)

Второй пример покажет для чего необходима метрика "Rejected/Opened Bugs":
Мы наблюдаем, что процент отклоненных (Rejected) багов очень большой. Это может значить:

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

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

Метрики по задачам

Название	Описание
Deployment tasks	Метрика показывает количество и результаты установок приложения. Процедура установки приложения была описана в статье Процедура проведения установки новой версии ПО (Deployment WorkFlow) . В случае, если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему.
Still Opened Tasks	Метрика показывает количество все еще открытых задач. К окончанию проекта все задачи должны быть закрыты. Под задачами понимаем следующие виды работ: написание документации (архитектура, требования, планы), имплементация новых модули или изменение существующих по запросам на изменения, работы по настройке стендов, различные исследования и многое другое

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

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

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

Метрики

Набор используемых метрик включает:

• порядок роста (имеется в виду анализ алгоритмов в терминах асимптотического анализа и 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 … Википедия

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

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

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

Компания TRW сформулировала четыре задачи программы по определению метрик:.

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

Обеспечение данными для планирования последующих этапов и создания других подсистем.

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

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

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

D.7.1 Прогресс разработки.

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

■ Метрики Ada/ADL. Позволяли довольно точно определять непосредственные показатели технического прогресса. Сами по себе эти метрики абсолютно точно отражали прогресс в разработке и реализации. Однако они плохо подходили для описания завершенных частей контракта и финансового состояния.

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

Как и в случае большинства других метрик ПО, оба эти подхода изначально давали неточные оценки абсолютного прогресса. Однако они являлись превосходными оценками относительного прогресса, если отслеживались регулярно (в нашем случае - ежемесячно). По мере накопления опыта работы с этими метриками абсолютные оценки постепенно настраивались для предсказания успеха или риска. Общие оценки сводились в единую диаграмму. На рис. D.9 показан итоговый прогресс на самом верхнем уровне для каждой отдельной версии и для Подсистемы общего назначения в целом. Длина заштрихованного участка внутри каждой версии относительно пунктирной линии (относящейся к текущему месяцу) определяет, опережает ли выполнение существующее расписание или отстает от него. Например, на рисунке изображено состояние после 17 месяца: НТ-тестирование версии 2 отстает от графика на один месяц, разработка версии 3 опережает график на один месяц, разработка

Рис. D.9. Общий прогресс разработки.

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

Ежемесячный сбор значений метрик обеспечивал необходимое для управления детальное понимание прогресса, увеличения объема кода и других показателей, достигнутых на каждой из версий. Метрики собираются по каждой версии и по CSCI с тем, чтобы иметь возможность рассмотрения под различными углами зрения. Менеджеры*каждого отдельного CSCI собирали и оценивали свои метрики, прежде чем они сводились воедино для проекта в целом. Этот процесс являлся объективным, эффективным и осмысленным. Самый нижний уровень оценок TBD_Statements был, конечно, субъективным, однако они определялись наиболее осведомленными людьми: непосредственными разработчиками. Оценки хранились в формате исходного кода. В этом случае возрастала вероятность того, что в данном виде рабочих продуктов будет храниться самая последняя информация. Такой процесс позволял также непротиворечиво и единообразно сравнивать прогресс по различным направлениям проекта.

На рис. D.10 представлены ежемесячные оценки прогресса для Подсистемы общего назначения и для каждой версии. Планируемый объем изменений основывался на грубом средневзвешенном подсчете для каждой версии, выполнявшемся согласно указаниям, данным в разделе D.5.3: 30% объема создается к моменту ПСКП и 70% объема - к моменту КСКП. В целом Подсистема общего назначения практически полностью соответствовала своему плану за одним исключением. Прогресс, достигнутый к моменту ППОП (намного опережая график), отразил неожиданное позитивное влияние инструментария, генерирующего исходный код. С его помощью для САПО было сгенерировано более 50 ООО SLOC.

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

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

Рис. D.10. Прогресс в разработке Подсистемы общего назначения D.7.2 Прогресс в тестировании.

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

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

<.>

Таблица D.6.

Характеристики SCO для ИТВ-тестирования версии 2

Источник проблем		Умеренный (	Большой 0 1 дня)
Интерпретация требований
Проблемы при независимом тестировании
Проблемы с интерфейсами
Неправильное выполнение
Желательное расширение (это не проблема)
Несовместимая конфигурация

Таблица D.7 и рис. D.11 позволяют взглянуть на метрики прогресса с различных точек зрения, которые применялись при планировании и отслеживании программы тестирования в проекте CCPDS-R. На рисунке изображен график зависимости прогресса относительно планируемого для тестирования соответствия требованиям. НТ-, ФТ- и ОКТ-тесты являлись источниками вариантов тестирования, использовавшимися организацией-разработчиком ПО. За НТ отвечали команды разработчиков, но оно должно было проводиться в формальной среде управления конфигурацией и под контролем (визуальным наблюдением) персонала, ответственного за тестирование. ФТ состояло из функционально связанных между собой групп сценариев, которые демонстрировали соответствие требованиям, охватывающим сразу несколько компонентов. ОКТ-тесты позволяли определять такие аспекты соответствия требованиям, которые не могли быть показаны до полного создания системы. Количественные требования к производительности (КТП) охватывали все CSCI.

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

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

Таблица D.7.

Работа по проверке соответствия требованиям с помощью различных типов тестов для различных CSCI

Рис. D.11. Прогресс тестирования Подсистемы общего назначения

Тип теста
Версия 0/1 НТ
Версия 2 НТ
Версия 3/4/5 НТ

D.7.3 Стабильность.

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

D.7.4 Коэффициент дефектности.

На рис. D.13 общее количество дефектов определяется относительно программной подсистемы в целом. Эта метрика оценивает суммарную дефектность, выявленную в процессе разработки Подсистемы общего назначения, приблизительно как 25% от объема всего продукта. В среднем в индустрии по созданию ПО средний объем дефектов колеблется в диапазоне от 40% до 60%. Начальная базовая конфигурация была создана к моменту ПОП, на 14 месяце. После этого в нее было внесено 1600 отдельных изменений.

Месяц выполнения контракта Рис. D.13. Коэффициент дефектности в Подсистеме общего назначения.

D.7.5 Адаптируемость

Для Подсистемы общего назначения в целом на доработку базовой версии ПО было затрачено около 5% от всего объема работ. Средняя стоимость внесения одного изменения составляла около 24 ч на один SCO. Эти значения позволяют оценить ту легкость, с которой могли вноситься изменения в базовую версию ПО. Уровень адаптируемости, достигнутый в рамках проекта CCPDS-R, был примерно в четыре раза выше, чем для обычных проектов, в которых затраты на доработки на протяжении жизненного цикла обычно превышают 20% от общего уровня затрат.

На рис. D.14 показана средняя стоимость одного изменения в процессе создания Подсистемы общего назначения. К моменту ОКТ было обработано 1600 SCO, касающихся изменения основ конфигурации, что привело к стабильной стоимости одного изменения. Проект CCPDS-R оказался одним из немногих контрпримеров утверждения: «чем более поздние стадии жизненного цикла вы проходите, тем больше дорогостоящих проблем обнаруживаете».

Большинство SCO на ранних этапах (на рис. D.14 они изображены в прямоугольнике с надписью «Изменения в проекте») являлись изменениями, затрагивающими большое число сотрудников и большое количество компонентов (изменения в интерфейсах и архитектуре). Более поздние SCO (обозначены как «Изменения в реализации») обычно касались одного человека и одного компонента. Последний участок кривой отражает нетипичное возрастание дефектов, что стало результатом большого технического предложения о полном изменении набора входящих сообщений для Подсистемы общего назначения. Эта область являлась одной из тех областей, внесение изменений в которые было не таким простым делом, как хотелось бы. Хотя проект был устойчивым и приспособленным к большому числу предусмотренных заранее сценариев внесения изменений, пересмотр всего набора входных сообщений никогда не предполагался, да и проект не был для этого приспособлен.

Рис. D.14. Адаптируемость Подсистемы общего назначения.

D.7.6 Завершенность.

К проекту CCPDS-R предъявлялись особенные требования по надежности, в связи с чем ПО было распределено особым образом. Выполняющая тестирование независимая команда создала автоматизированный набор тестов. Он проводился в неурочное время и испытывал базовую версию ПО по сценариям случайных сообщений. Такая стратегия привела к проведению широкого тестирования в условиях, близких к реальным на протяжении длительного времени. По результатам удалось определить значение MTBF для ПО. Критичные по надежности компоненты, принудительно перенесенные в плане итераций на самые ранние стадии, подвергались наиболее жесткому тестированию на надежность. Результаты показаны на рис. D.15.

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

Рис. D.15. Завершенность Подсистемы общего назначения.

D.7.7 Затраты финансов/работы на отдельные виды деятельности.

В таблице D.8 рассматривается общая подробная структура затрат на Подсистему общего назначения в проекте CCPDS-R. Эти данные были получены из окончательного WBS-набора затрат и структурированы в соответствии с рекомендациями, приведенными в разделе 10.1. Элементы более низкого уровня описываются в таблице D.9.

■ Проценты, указанные в таблице D.8, приблизительно соответствуют процентам, приведенным в главе 10. Однако некоторые из элементов таблицы D.9, касающихся управления, были распределены по нескольким элементам таблицы D.8 для выделения видов деятельности, находящихся на уровне управления проектом.

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

Таблица D.8.

Финансовые затраты на Подсистему общего назначения по WBS-элементам самого верхнего уровня

WBS-элемент

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

Группа 1 - Требования к разрабатываемому ПО

Эта группа метрик позволит оценить, насколько мы проработали требования (user story) к ПО, определить уязвимые места и наиболее сложные, потенциально проблемные фичи ПО, понять, где требуется особый контроль:

1. Тестовое покрытие требования

Иными словами, это количество тестов на 1 требование.

Назначение метрики: выявить слабые места в тестовом покрытии, подсветить риски.

• Конечно, данная метрика будет работать, только если требования хорошо декомпозированы и более или менее равнозначные. Разумеется это не всегда возможно, но если получается сделать требования достаточно атомарными, то данная метрика покажет отклонение покрытия каждого требования от среднего уровня. Чем больше значение отличается от 1, тем меньше\больше тестов написано для одного требования, чем обычно.
• Важнее всего обратить внимание на требования, для которых коэффициент будет равен или близок к 0. Для них нужно рассмотреть возможность добавления тестов.
• Если требования не атомарные, то данная метрика позволит убедиться только в том, что для каждого требования есть хотя бы 1 тест. Для этого коэффициент всегда должен быть больше 0.

2. Степень взаимосвязанности требований

Метрика вычисляется как среднее количество связей каждого требования с остальными требованиями.

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

• Значение этой метрики будет находиться от 0 до 1. 1 означает, что каждое требование связано с каждым, а 0 – что взаимосвязей нет.
• Тут сложно вводить какие-то ограничения для значений данного коэффициента, многое зависит от специфики функционала, архитектуры, технологий. Однако, по своему опыту могу сказать, что хорошо, когда степень связанности не превышает 0,2-0,3. В противном случае доработка в рамках одного из требований будет вести к цепочке изменений, а значит и возможных ошибок, в значительной части продукта.

3. Коэффициент стабильности требований

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

• Разумеется, полностью изолированного функционала не существует, но количество новых требований должно преобладать над изменяемыми а коэффициент желательно должен быть меньше 0,5. В этом случае мы внедряем новых фич в 2 раза больше, чем переделываем существующих.
• Если коэффициент выше 0,5, особенно если больше 1, то это скорее всего значит, что ранее мы сделали то, что оказалось ненужным. Команда фокусируется не на создании новых ценностей для бизнеса, а на переделывании ранее выпущенных фич.
• Также метрика дает представление о том, насколько легко масштабируется функционал системы, добавляются новые возможности.

Группа 2 - Качество разрабатываемого продукта

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

1. Плотность дефектов

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

Назначение метрики: подсветить, какая часть ПО является наиболее проблемной. Эта информация поможет при оценке и планировании работ с данным модулем а также при анализе рисков.

• Причины большого количества дефектов к каком-то одном конкретном модуле (коэффициент больше 0,3) могут быть различны: некачественные требования, квалификация разработчика, техническая сложность и т.д. В любом случае данная метрика сразу обратит наше внимание на проблемную зону.

2. Коэффициент регрессии

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

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

3. Коэффициент повторно открытых дефектов

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

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

4. Средняя стоимость исправления дефекта

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

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

• Каких-либо правильных значений тут конечно нет, все будет определяться спецификой конкретной ситуации

5. Количество дефектов в коде конкретного разработчика

Назначение метрики: подсветить возможные сложности в команде разработки, кому из специалистов не хватает опыта, знаний или времени, нужна помощь.

• Если, например, 50% всех дефектов приходиться на 1 разработчика, а всего в команде их 5, то тут явно есть проблема. Из этого не следует, что данный программист плохо работает, но сигнализирует обязательно разобраться в причинах подобной ситуации.
• Метрика помимо прочего может быть индикатором особенно сложного для разработки и поддержки модуля\функционала\системы.

Группа 3 – Возможности и эффективность команды QA

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

1. Скорость работы (velocity) команды QA

Рассчитывается как отношение реализованных story points (или требований, или user stories) за несколько, например, 4-5 итераций (Sprint) к количеству выбранных итераций.

Назначение метрики: численно выразить возможности, скорость работы команды для дальнейшего планирования объема работ и анализа трендов развития

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

2. Среднее время жизни дефекта

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

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

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

Группа 4 - Качество работы команды тестирования

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

1. Эффективность тестов и тестовых наборов

Назначение метрики: показать как много ошибок в среднем позволяют обнаружить наши кейсы. Эта метрика отражает качество тест дизайна и помогает следить за тенденцией его изменения.

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

2. Коэффициент ошибок, пропущенных на продуктив

Кол-во ошибок обнаруженных после выпуска релиза \ общее кол-во ошибок в ПО обнаруженных в процессе тестирования и после выпуска

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

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

3. Реальное время работы команды QA

Отношение времени потраченного командой непосредственно на QA активности к общему кололичеству часов.

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

• Целевые активности, это анализ, дизайн, оценки, тестирование, рабочие встречи и многое другое. Возможные побочные вещи - это простой из-за блокеров, проблемы в коммуникациях, недоступность ресурсов и т.п.
• Естественно, данный коэффициент никогда не будет равен 1. Практика показывает, что для эффективных команд он может составлять 0,5-0,6.

4. Точность оценки времени по областям\видам\типам работ

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

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

5. Доля неподтвержденных (отклоненных) дефектов

Назначение метрики: показать сколько дефектов были заведены «вхолостую».

• Если доля дефектов, которые были отклонены превышает 20%, то в команде может наблюдаться рассинхронизация в понимании, что является дефектом, а что нет

Группа 5 - Обратная связь и удовлетворенность пользователей

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

1. Удовлетворенность пользователей ИТ сервисом

Регулярный опрос удовлетворенности пользователей сервисом ИТ с выставлением баллов.

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

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

2. Удовлетворенность пользователей продуктом

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

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

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

3. Вовлеченность стейкхолдеров

Количество инициатив и предложений по улучшению процесса и продукта, поступивших в течение итерации (релиза) со стороны стейкхолдеров

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