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

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

Метрики кода

Метрика программного обеспечения (software metric) – численная мера, позволяющая оценить определенные свойства конкретного участка программного кода. Для каждой метрики обычно существуют ее эталонные показатели, указывающие, при каких крайних значениях стоит обратить внимание на данный участок кода. Метрики кода разделяются на категории и могут оценивать совершенно различные аспекты программной системы: сложность и структурированность программного кода, связность компонентов, относительный объем программных компонентов и др. Наиболее простая для понимания метрика – количество строк кода в программной системе, – хотя и элементарно вычисляется, но в совокупности с другими метриками может служить для получения формализованных данных для оценки кода. Например, можно построить соотношение между количеством строк кода в классе и количеством методов/свойств в классе, получив характеристику, показывающую, насколько методы данного класса являются объемными. Кроме того, такие оценки можно использовать в совокупности с метриками сложности (например, цикломатической сложностью Мак-Кейба) для определения наиболее сложных участков в программном коде и принятия соответствующих мер.

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

Метрики программного кода являются важным инструментом и уже сегодня используются многими производителями ПО. Так, при сертификации на более высокие уровни по моделям ISO/IEC или CMM/CMMI использование метрик кода является обязательным, что позволяет в определенной степени достичь контролируемости процесса разработки.

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

размер – сравнительная оценка размеров ПО;

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

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

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

Имеет ли значение размер?

Метрика SLOC (source lines of code) отражает количество строк исходного кода. Данный показатель не всегда может использоваться для объективной оценки объемов программной системы – его числовое значение зависит от множества случайных факторов, например стиля кодирования. Сравнивать две программные системы лишь по этому критерию вряд ли правомерно, поэтому для SLOC появилось множество производных показателей: количество пустых строк; количество строк, содержащих комментарии; процентное соотношение комментариев; количество строк кода, содержащихся в методах/функциях; среднее количество строк кода на метод/функцию; среднее количество строк кода на класс/пакет; среднее количество строк кода на модуль и т.д.

Кроме SLOC, при оценке размера часто используют показатель «логических» строк кода LSI (logical source instructions), вычисляемый после нормализации (приведения исходного кода к надлежащему виду) листинга: устранение размещения нескольких инструкций на одной строке, пустых строк, очистка от комментариев, форматирование строк кода для инициализации данных и т.д. Такой показатель может служить для более объективной оценки объема системы (показатель с применением нормализации выглядит так же, как и SLOC, – количество строк, но не физических, а логических). У LSI также существуют производные, например метрика, вычисляемая не как физическое количество строк кода на исходном языке программирования, а как количество инструкций на языке более низкого уровня (язык Ассемблера, MSIL и др.), что устраняет необходимость в нормализации.

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

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

Сложность

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

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

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

Иногда используют вариацию метрики, отражающей связность кода, – количество вызовов операции. Эта метрика позволяет определить количественный показатель связности системы в виде вызовов методов. Метрика подсчитывает вызовы только тех операций, которые определены пользователем. Например, если метод A() вызывает метод B() три раза, то значение этой метрики будет равно единице; если же метод B() вызывается по одному разу из методов A(), C() и D(), то значение метрики будет равняться трем. Однако абсолютное значение данной метрики может существенно изменяться от проекта к проекту в зависимости от подходов к проектированию и кодированию программных систем. Даже в рамках одной и той же команды разработчиков на идентичных проектах значение данной метрики может отличаться в силу субъективных факторов (например, стиля конкретного разработчика при выделении логики в отдельные методы), которые оказывали влияние при построении программной системы.

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

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

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

Поддерживаемость

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

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

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

Инструмент анализа кода

Разработчики на платформе Microsoft могут воспользоваться версией Visual Studio 2008, которая позволяет вычислять базовый набор основных метрик и отслеживать их в режиме реального времени (рис. 2). Тем не менее основной сценарий использования метрик – это информирование менеджеров разработки о том, что качество продукта, возможно, понизилось или повысилось. Поэтому имеет смысл вычислять такие метрики в процессе сборки проекта.

Visual Stuido 2008 и Microsoft Build не позволяют выстроить серьезную иерархию метрик, и для этого следует воспользоваться другими инструментами, например NDepend, позволяющим для платформы.NETрассчитывать различные типы связности, наследования и абстрактности, интегрируясь в процесс создания программ в соответствии с требованиями конкретной команды разработчиков.

Проблемы при использовании метрик кода

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

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

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

Сергей Звездин ([email protected]) – аспирант Южно-Уральского государственного университета (Челябинск).

В МГУ открыт портал дистанционного обучения

Школа дистанционного образования Московского государственного университета им. М.В. Ломоносова открыла собственный Internet-портал . На нем предлагается доступ к совместной открытой электронной библиотеке МГУ и Российской академии наук, учебникам и курсам, аудио- и видеоматериалам, а также к образовательным программам с применением дистанционных образовательных технологий. Часть ресурсов портала доступна только слушателям дистанционных программ, оплатившим обучение согласно договору с университетом. Видеоматериалы МГУ теперь доступны на канале университета в YouTube. Образовательный канал содержит записи лекций, а также мероприятий университета.

eLearning только для 17% российских компаний

Исследовательский центр портала SuperJob.ru представил результаты опроса, посвященного онлайн-обучению персонала российских компаний. Среди отечественных работодателей использование электронного обучения в работе с персоналом не слишком распространено. Только 17% компаний предлагают персоналу подобную форму обучения. В основном эти технологии применяют в крупных компаниях со штатом от 5 тыс. человек (50%). Вообще не применяют подобную практику 79% работодателей. Причины кроются либо в отсутствии необходимого технического оборудования, либо в нежелании руководства применять такой вид обучения. В целом опыт дистанционного обучения имеют лишь 11% россиян. Из этого числа 9% респондентов остались довольны результатом, а 2% – недоучились и бросили. Среди тех, кто прошел обучение, мужчин оказалось почти вдвое больше, чем женщин (11% и 6% соответственно). При этом россияне в возрасте от 35 до 55 лет учатся через Internet чаще, чем молодежь. Успешным опытом дистанционного обучения может похвастаться 12% респондентов в возрасте от 40-50 лет и лишь 9% россиян в возрасте до 23 лет.

Итоги конкурса «Максимальная масштабируемость 2009»

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

Стартовал чемпионат мира по программированию

В финале 34-го ежегодного командного чемпионата мира по программированию (International Collegiate Programming Contest, ICPC), который проводится ассоциацией Association for Computing Machinery (ACM) и спонсируется IBM, встретятся сто победивших в региональных соревнованиях студенческих команд. Перед ними будут поставлены как минимум восемь задач, которые потребуется решить за 5 часов. Финал пройдет 5 февраля 2010 года в Харбинском инженерном университете (Китай). Среди задач прошлых лет были, например, такие как поиск потерянного в море корабля, триангуляция местоположения испорченного радиопередатчика, вычисление препятствий при игре в гольф, кодирование и декодирование сообщений, печать шрифтом Брайля, поиск выхода из лабиринта. В прошлом году три из четырех золотых медалей завоевали российские команды. На стадии отборочных соревнований в чемпионате участвовало 7109 команд из 1838 университетов 88 стран мира. Второй год подряд чемпионом мира стала команда Санкт-Петербургского государственного университета информационных технологий, механики и оптики.

В этой статье я хочу рассмотреть одни из самых важных 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. Вовлеченность стейкхолдеров

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<.>

Таблица D.6.

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

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

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

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

Таблица D.7.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица D.8.

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