Метрика программного обеспечения. Средняя стоимость исправления дефекта. Тестовое покрытие требования
Берг О.Ю.
МЕТРИКИ ОЦЕНКИ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Поскольку обработка данных затрагивает нашу жизнь всё в большей степени, ошибки ЭВМ могут теперь иметь такие последствия, как нанесение материального ущерба, нарушение секретности и многие другие, включая смерть. Надёжность программного обеспечения (ПО) есть вероятность его работы без отказов в течение определённого периода времени, рассчитанная с учётом стоимости для пользователя каждого отказа. Следовательно, необходимо иметь возможность измерять качество ПО на протяжении всего цикла разработки. Качество ПО целесообразно оценивать на основе критериев качества , которые должны:
Численно характеризовать основную целевую функцию программы;
Обеспечивать возможность определения затрат, необходимых для достижения требуемого уровня качества, а также степени влияния на показатель качества различных внешних факторов;
Быть по возможности простым, хорошо измеримым и иметь малую дисперсию.
Для измерения характеристик и критериев качества используют метрики. В настоящее время известно большое количество метрик, оценивающих отдельные производственные и эксплуатационные свойства ПО . Однако погоня за их универсальностью, игнорирование области применения разрабатываемого ПО, этапов жизненного цикла существенно снижает эффективность их использования.
Метрика качества программ - система измерений качества программ. Эти измерения могут проводиться на уровне критериев качества программ или на уровне отдельных характеристик качества. В первом случае система измерений позволяет непосредственно сравнивать программы по качеству. При этом сами измерения не могут быть проведены без субъективных оценок свойств программ. Во втором случае измерения характеристик можно выполнить объективно и достоверно, но оценка качества ПО в целом будет связана с субъективной интерпретацией получаемых оценок.
В исследовании метрик ПО различают два основных направления:
Поиск метрик, характеризующих наиболее специфические свойства программ, т.е. метрик оценки самого ПО;
Использование метрик для оценки технических характеристик и факторов разработки программ, т.е. метрик оценки условий разработки программ.
По виду информации, получаемой при оценке качества ПО метрики можно разбить на три группы :
Метрики, оценивающие отклонение от нормы характеристик исходных проектных материалов. Они устанавливают полноту заданных технических характеристик исходного кода.
Метрики, позволяющие прогнозировать качество разрабатываемого ПО. Они заданы на множестве
возможных вариантов решений поставленной задачи и их реализации и определяют качество ПО, которое
будет достигнуто в итоге.
Метрики, по которым принимается решение о соответствии конечного ПО заданным требованиям. Они позволяют оценить соответствие разработки заданным требованиям.
В настоящее время в мировой практике используется несколько сотен метрик программ. Существующие качественные оценки программ можно сгруппировать по шести направлениям:
Оценки топологической и информационной сложности программ;
Оценки надежности программных систем, позволяющие прогнозировать отказовые ситуации;
Оценки производительности ПО и повышения его эффективности путем выявления ошибок проектирования;
Оценки уровня языковых средств и их применения;
Оценки трудности восприятия и понимания программных текстов, ориентированные на
психологические факторы, существенные для сопровождения и модификации программ;
Оценки производительности труда программистов для прогнозирования сроков разработки программ и планирования работ по созданию программных комплексов.
В зависимости от характеристик и особенностей применяемых метрик им ставятся в соответствие различные измерительные шкалы:
Номинальной шкале соответствуют метрики, классифицирующие программы на типы по признаку наличия или отсутствия некоторой характеристики без учета градаций;
Порядковой шкале соответствуют метрики, позволяющие ранжировать некоторое характеристики путем сравнения с опорными значениями, т.е. измерение по этой шкале фактически определяет взаимное положение конкретных программ;
Интервальной шкале соответствуют метрики, которые показывают не только относительное положение программ, но и то, как далеко они отстоят друг от друга;
Относительной шкале соответствуют метрики, позволяющие не только расположить программы определенным образом и оценить их положение относительно друг друга, но и определить, как далеко оценки отстоят от границы, начиная с которой характеристика может быть измерена.
Анализ технологического опыта лидеров производства ПО показывает, насколько дорого обходится несовершенство ненаучного прогноза разрешимости и трудозатрат, сложности программ, негибкость контроля и управления их разработкой и многое другое, указывающее на отсутствие сквозной методической поддержки и приводящее в конечном итоге к его несоответствию требованиям пользователя, требуемому стандарту и к последующей болезненной и трудоемкой его переделке. Эти обстоятельства, требуют тщательного отбора методик, моделей, методов оценки качества ПО, учета ограничений их пригодности для различных жизненных циклов, установления порядка их совместного использования, применения избыточного разномодельного исследования одних и тех же показателей для повышения достоверности текущих оценок, накопления и интеграции разнородной метрической информации для принятия своевременных производственных решений и заключительной сертификации продукции.
В заключение, необходимо отметить, что при выборе метрик оценки качества ПО необходимо руководствоваться следующими правилами :
метрика должна иметь смысл, как для заказчика, так и для исполнителя;
метрика должна быть объективна и ее определение недвусмысленно;
метрика должна давать возможность отслеживать тенденцию изменений;
метрика может быть автоматизирована.
Тщательно проведенный метрический анализ качества в соответствии с целями разработки создает основу для корректного планирования и контроля затрат на качество для достижения требуемых показателей и эффективности использования ресурсов.
ЛИТЕРАТУРА
1. Liu K., Zhou S. Yang H., Quality Metrics of Object Oriented Design for Software Development and Re-development,- Proceedings of the First Asia-Pacific Conference on Quality Software, 2000 IEEE
2. Boehm B. W., Brown J. R., Lipow M. QUANTITATIVE EVALUATION OF SOFTWARE QUALITY Proceedings of the 2nd International Conference on Software Engineering on International conference on software engineering October 1976
3. Houdek F., Kempter H. Quality patterns - An approach to packaging software engineering experience ACM SIGSOFT Software Engineering Notes , Proceedings of the 1997 symposium on Symposium on software reusability May 1997
4. У. Ройс Управление проектами по созданию программного обеспечения, Москва, ЛОРИ
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. Модели оценки надежности
Из всех областей программной инженерии надежность ПС является самой исследованной областью. Ей предшествовала разработка теории надежности технических средств, оказавшая влияние на развитие надежности ПС. Вопросами надежности ПС занимались разработчики ПС, пытаясь разными системными средствами обеспечить надежность, удовлетворяющую заказчика, а также теоретики, которые, изучая природу функционирования ПС, создали математические модели надежности, учитывающие разные аспекты работы ПС (возникновение ошибок, сбоев, отказов и др.) и оценить реальную надежность. В результате надежность ПС сформировалась как самостоятельная теоретическая и прикладная наука .
Надежность сложных ПС существенным образом отличается от надежности аппаратуры. Носители данных (файлы, сервер и т.п.) обладают высокой надежностью, записи на них могут храниться длительное время без разрушения, поскольку разрушению и старению они не подвергаются.
С точки зрения прикладной науки надежность – это способность ПС сохранять свои свойства (безотказность, устойчивость и др.) преобразовывать исходные данные в результаты в течение определенного промежутка времени при определенных условиях эксплуатации. Снижение надежности ПС происходит из–за ошибок в требованиях, проектировании и выполнении. Отказы и ошибки зависят от способа производства продукта и появляются в программах при их исполнении на некотором промежутке времени.
Для многих систем (программ и данных) надежность является главной целевой функцией реализации. К некоторым типам систем (реального времени, радарные системы, системы безопасности, медицинское оборудование со встроенными программами и др.) предъявляются высокие требования к надежности, такие как недопустимость ошибок, достоверность, безопасность, защищенность и др.
ПрограммноеДокумент
Т.д. Цветная паутина, предлагаемая в учебниках , сложна для восприятия и понимания... его использования. М.М. Петрухин ГОУ ВПО « ... средства . На сегодняшний день в программной инженерии можно выделить два основных подхода к разработке программного обеспечения ...
Свежие подборки материалов для скачивания! Мы собрали пакеты материалов по актуальным темам, включающие презентации экспертов, вебинары, статьи, примеры внедрений и пр.
Для загрузки материалов нажмите на соответствующую кнопку:
Наиболее широко известным и используемым стандартом для организации процессов контроля качества является серия стандартов 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. Большинство традиционных метрик используются на этапе планирования и разработки. Ключевым для управления качеством при использовании метрик в разработке компонентных систем является выбор метрик качества применимых на всех этапах жизненного цикла и оценивающих как качество процесса, так и качество продукта.
В этой статье я хочу рассмотреть одни из самых важных 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. Вовлеченность стейкхолдеров
Количество инициатив и предложений по улучшению процесса и продукта, поступивших в течение итерации (релиза) со стороны стейкхолдеров
Назначение метрики: определить степень участия внешних стейкхолдеров в работе над продуктом. Имея на руках такую метрику можно сориентироваться, где требуется получить обратную связь, чтобы однажды не столкнуться с презрением и ненавистью проблемами и непониманием.
| Обучающее видео. Яндекс.Метрика: знакомство Посмотреть видео |
Что можно отслеживать с помощью Метрики
Привлечение посетителей
Отчеты по Директу в Метрике наглядно показывают, по каким кампаниям, объявлениям, фразам и поисковым запросам приходят на ваш сайт посетители, из каких регионов и с каких рекламных площадок. Используйте эту информацию, чтобы оптимизировать ваши кампании.
Например, вы можете улучшить фразы: добавить ключевые фразы из релевантных поисковых запросов и минус-слова из нерелевантных запросов - это поможет привлечь более заинтересованных посетителей и повысить CTR.
Аудитория сайта
В Метрике вы можете получить подробные характеристики вашей аудитории. Пол, возраст и интересы посетителей вычисляются путем анализа их поведения в интернете с помощью технологии Крипта. Ориентируясь на эти данные, рекламу можно делать более релевантной и за счет этого повышать ее эффективность.
Достижение целей и конверсии
Важно не просто привести на свой сайт посетителей, а понять, становятся ли они реальными клиентами. Для этого в Метрике нужно настроить цели - то есть определить ключевые действия, которые должны выполнить посетители сайта.
Например, вашим покупателем может стать посетитель, который:
- нажал кнопку «В корзину» ;
- прошел путь от корзины до страницы «Спасибо за покупку» при оформлении заказа;
- посетил не менее двух страниц сайта;
- зашел на страницу с контактной информацией;
- зарегистрировался на сайте или подписался на рассылку.
Наличие настроенных целей позволит понять, по каким фразам и объявлениям на сайт приходят пользователи, достигающие цели. Вы сможете не только анализировать прирост целевых визитов, но и оптимизировать их при помощи одной из автоматических стратегий: Средняя цена конверсии или Недельный бюджет. Максимум конверсий .
Выручка
Владельцы интернет-магазинов могут получать в Метрике детализированную информацию о заказах, совершенных на сайте магазина. Вы сможете узнать, сколько денег принес каждый заказ и из каких каналов поступают наиболее прибыльные заказы.
Прямо в интерфейсе Метрики вы можете быстро оценить ваши затраты на рекламу в Директе. Например, вы можете посмотреть общие затраты на рекламу, узнать среднюю стоимость конверсий по всем своим рекламным кампаниям, оценить среднюю или суммарную стоимость кликов для определенных типов устройств, регионов, поисковых запросов или площадок.
Целевые звонки
Клиенты делают заказы не только на сайте, но и по телефону. Услуга «Целевой звонок» позволяет сравнить эффективность различных каналов продвижения. Вы получаете специальные телефонные номера, которые можно привязать к разным источникам, с уровнем детализации вплоть до отдельных рекламных кампаний. Номер на сайте и в виртуальной визитке автоматически подменяется в зависимости от источника - таким образом можно отследить, откуда о вас узнал каждый позвонивший.
Как начать собирать статистику
Установите код счетчика на все страницы вашего сайта как можно ближе к началу страницы - от этого зависит полнота собираемых данных. Корректность установки счетчика вы можете проверить в консоли браузера .
Если вы создаете много кампаний с одинаковым набором счетчиков, вы можете указать счетчики на странице настроек пользователя в поле Счетчик Метрики для новых кампаний .
Пока вы не указали номера счетчиков, передавать данные между Директом и Метрикой вам поможет автоматическая разметка ссылок. Убедитесь, что в параметрах кампании включена опция Размечать ссылки для Метрики , а ваш сайт корректно открывает ссылки с метками.
Как работает разметка ссылок
Внимание. Если в параметрах кампании не заполнено поле Счетчики Метрики , и при этом выключена опция Размечать ссылки для Метрики , то данные о кликах по объявлениям не будут попадать в Метрику, а данные из Метрики не будут попадать в статистику Директа.
Вопросы и ответы
Как быстро обновляются данные в отчетах Метрики?
Действия посетителя на сайте отражаются в большинстве отчетов Метрики уже через несколько минут. Данные для специальных отчетов по Директу проходят дополнительную проверку, поэтому они попадают в Метрику с задержкой до нескольких часов.
Как быстро в Директ попадают данные о достижении целей?
Данные о достижении конкретной цели попадают в Директ в течение суток.
Почему отличаются данные в статистике Директа и в Метрике?
