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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совместная

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

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

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

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

и полномочия

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

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

качества ПС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

География

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

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

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

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

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

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

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

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

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

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

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

Вебвизор

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

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

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

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

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

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

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

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

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

Таким образом, для оценки качества процесса разработки в собственной организации или в организации подрядчиков могут использоваться требования руководства ISO 9000-3. В настоящее время повсеместно вводится в использование версия стандарта 2000 года, в котором во главу угла ставится управление процессом, однако в данной версии стандарта специфика, связанная с разработкой ПО отсутствует.

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

Среди разработчиков программного обеспечения в особенности за рубежом (в первую очередь в США) большим рейтингом пользуется альтернативная модель качества: СММ - SEI. Указанная модель качества разработана в институте инженерии программного обеспечения (Software Engineering Institute) при спонсорстве министерства обороны США. Первоначально данная модель качества использовалась государственными, в частности военными, организациями при размещении заказов на разработку программного обеспечения. В настоящее время стандарт широко используется для анализа и сертификации процессов разработки программного обеспечения фирм, производящих сложное программное обеспечение в критичных областях применения. Важными преимуществами модели СММ является иерархическая вложенность моделей качества, которая позволяет измерять и сравнивать уровни качества процессов в различных организациях и обеспечивать эффективное совершенствование качество процессов.

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

В определенном отношении модели качества СММ и ISO являются взаимозаменяемыми, однако, по сути, они не противоречат друг другу, поскольку основаны на одной парадигме качества – TQM – Total Quality Management.

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

Качество программного продукта

Качество программных компонент

Разработка современных больших программных систем в настоящее время все более базируется на компонентной разработке (Component Base System – CBS). Технология построения CBS позволяет значительно снизить стоимость и время разработки. В то же время возрастает риск, связанный с использованием в системе программных компонент разработанных различными производителями.

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

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

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

Метрики

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

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

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

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

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

Таблица 1.3.

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

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

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

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

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

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

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

Первой топологической мерой сложности является цикломатическая мера Мак-Кейба. В ее основе лежит идея оценки сложности ПО по числу базисных путей в ее управляющем графе, т.е. таких путей, компонуя которые можно получить всевозможные пути из входа графа в выходы. Цикломатическое число (G) орграфа G с n-вершинами, m-дугами и p-компонентами связности есть величина (G) = m – n + p.

Имеет место теорема о том, что число базисных путей в орграфе равно его цикломатическому числу, увеличенному на единицу. При этом, цикломатической сложностью ПО Р с управляющим графом G называется величина (G) = (G) +1 = m – n + 2. Практически цикломатическая сложность ПО равна числу предикатов плюс единица, что позволяет вычислять ее без построения управляющего графа простым подсчетом предикатов. Данная мера отражает “психологическую” сложность ПО.

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

Дж. Майерс предложил в качестве меры сложности интервал [ 1 2 ], где 1 - цикломатическая мера, а 2 - число отдельных условий плюс единица. При этом, оператор DO считается за одно условие, а CASE c n - исходами за n - 1- условий. Введенная мера получила название интервальной мерой.

У. Хансену принадлежит идея брать в качестве меры сложности ПО пару {цикломатической число, число операторов}. Известна топологическая мера Z(G), чувствительная к структурированности ПО. При этом, она Z(G) = V(G) (равна цикломатической сложности) для структурированных программ и Z(G) V(G) для неструктурированных. К вариантам цикломатической меры сложности относят также меру М(G) = (V(G),C,Q), где С - количество условий, необходимых для покрытия управляющего графа минимальным числом маршрутов, а Q - степень связности структуры графа программы и ее протяженность.

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

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

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

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

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

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

1. Мера сложности простого оператора равна 1;

2. М ({F1; F2; …;Fn}) = i n M(Fi);

3. М (IF P THEN F1 ELSE F2) = 2 MAX (M (F1), M (F2));

4. М (WHILE P DO F) = 2 M(F).

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

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

Топологическая мера Чена выражает сложность программы числа пересечений границ между областями, образуемыми блок–схемой программы. Этот подход применим только к структурированным программам, допускающим лишь последовательное соединение управляющих конструкций. Для неструктурированных программ мера Чена существенно зависит от условных и безусловных переходов. В этом случае можно указать верхнюю и нижнюю границы меры. Верхняя - есть m+1, где m – число логических операторов при их гнездовой вложенности. Нижняя – равна 2. Когда управляющий граф программы имеет только одну компоненту связности, мера Чена совпадает с цикломатической мерой Мак-Кейба.

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

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

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