CC BY
54
Юрченко Алексей Васильевич
Yurchenko Alexey Vasylievich ЗАО «ЕС-лизинг^/^БС-leasing» Руководитель направления конфигурационного управления и сопровождения программного обеспечения Head of software configuration management and software maintenance department [email protected]
Формы критериев выбора для программных метрик различных типов
Forms of decision criteria for different types of software metrics
Аннотация: Программные метрики необходимы для обеспечения информацией при принятии обоснованных и подходящих решений. Согласно стандарту «ISO/IEC 15939 Технология программного обеспечения. Процесс измерения» критериями выбора являются «пороговые величины, целевые величины, или шаблоны, используемые для определения необходимости дальнейших действий, или исследований, либо для описания степени достоверности полученного результата». То есть критерии выбора требуются для того, чтобы получить правила, которые помогли бы интерпретировать результаты измерений. В данной работе показано как создавать полезные критерии выбора для различных типов метрик.
The Abstract: Software metrics provide information for making reasonable and appropriate decisions. According to the «ISO/IEC 15939 Software Engineering - Software Measurement Process» standard, decision criteria are the «thresholds, targets, or patterns used to determine the need for action or further investigation, or to describe the level of confidence in a given result». This means, that decision criteria is needed to obtain rules that will help to interpret the measurement results. In this paper is shown how to design helpful decision criteria for different types of metrics.
Ключевые слова: Критерий выбора, программные метрики, измерение, контроль, оценка, анализ, прогнозирование.
Keywords: Decision criteria, software metrics, measurement, control, evaluation, analysis, prediction.
Введение
Измерения являются неотъемлемой частью повседневной жизни. Измерения используются постоянно, чтобы принимать лучшие решения, основываясь на фактах и информации. Целью измерений программного обеспечения (ПО) является снабжение менеджеров и инженеров информацией, используя которою, они смогут принимать оптимальные решения, основываясь на фактах, а не на ощущениях.
В такой сложной области, как разработка ПО, не всегда просто интерпретировать программные измерения и использовать их во время принятия решения. В этом случае помогает определение критерия выбора. Создание критерия выбора может помочь интерпретировать результаты измерений, когда необходимо принимать решения.
Согласно [4] существует четыре основных функции программных измерений:
- контроль: метрики контролирующего типа используются для мониторинга программных процессов, продуктов и служб, и для определения областей, в которых требуется корректирующее, или управляющее воздействие.
- оценка: метрики оценивающего типа используются в процессе принятия решений для изучения (исследования) продуктов, процессов, или служб, чтобы устанавливать базисные уровни и определять соответствует ли реальное положение дел установленным стандартам, целям и критериям приемки.
- анализ: как часть исследований, метрики анализирующего типа могут собираться для изучения существующих программных процессов, продуктов и служб.
- прогнозирование: метрики прогнозирующего типа используются для оценки значений измерений в будущем.
Чтобы установить критерии выбора для различных типов метрик в данной работе будут использоваться различные типы функций программных измерений.
1 Измерительная информационная модель
Итак, в каком именно месте критерий выбора должен встраиваться в измерительный процесс? Чтобы ответить на это, рассмотрим информационную измерительную модель, определенную в стандарте «ISO/IEC 15939 Технология программного обеспечения. Процесс измерения» [2], и изображенную на рисунке 1. Данная модель сопоставляет объекты и их атрибуты с информационным продуктом, который соответствует информационным потребностям пользователя, производящего измерения (потребителя).
Рис. 1. Информационная измерительная модель
Объекты и атрибуты. Объект представляет собой специфическую сущность (например, программный продукт, программный процесс, или ресурс), у которой есть специфиче-
Главный редактор - д.э.н., профессор К.А. Кирсанов тел. для справок: +7 (925) 853-04-57 (с 1100 - до 1800) Опубликовать статью в журнале - http://publ.naukovedenie.ru
ские измеряемые атрибуты (свойства, или характеристики). Например, если представить программный исходный код в качестве объекта, то его измеряемыми атрибутами могут быть его размер, или количество найденных дефектов в этом коде.
Методы измерения и базовые меры. Метод измерения включает в себя правила для постановки в соответствие чисел, или символов измеряемым величинам, чтобы создать базовую меру для атрибута. Например, можно подсчитать количество точек с запятой, чтобы присвоить это число базовой мере логических строк кода для атрибута размера некоторого моду-
Функции измерения и производные меры. Это алгоритм, или расчет, используемый для комбинации двух, или более базовых мер в производную меру. Например, можно использовать функцию измерения, которая делит количество дефектов в модуле Х на число строк кода в этом же модуле (получим количество дефектов на 1 строку кода в модуле), и умножает их на 1000 (чтобы преобразовать значение в количество дефектов на тысячу строк кода). В результате получим функцию, измеряющую плотность дефектов в модуле Х.
Аналитическая модель. Согласно стандарту КОЛЕС 15939 аналитическая модель -это «последовательность действий, или вычисление, сочетающее одну, или более базовых и/или производных мер с ассоциированным критерием выбора. Она основана на понимании, или предположении ожидаемого отношения между мерами компонента и/или их поведением во времени» [2]. Например, основываясь на исторических данных можно вычислить среднюю плотность дефектов и среднеквадратическое отклонение плотности дефектов для некоторого множества модулей программного кода, которые входят в некоторый продукт, удовлетворяющий требованиям качества и надежности. Далее, можно использовать эти требования для подобного продукта, чтобы смоделировать приемлемый уровень плотностей дефектов для текущего множества модулей программного кода.
Критерии выбора. Согласно стандарту КОЛЕС 15939 «критерии выбора могут быть рассчитаны, или могут быть основаны на концептуальном понимании ожидаемого поведения. Критерии выбора могут происходить из исторических данных, планов, эвристических правил, или вычисляться, как статистические пределы регулирования, или как статистические доверительные пределы» [2]. Например, основываясь на вышеописанной исторической модели «приемлемой» плотности дефектов, можно установить следующие критерии выбора. Они будут указывать, что любой модуль с плотностью дефектов большей, чем одно (имеется в виду правило трех сигм из математической статистики) среднеквадратическое отклонение плотности дефектов относительно среднего значения, является кандидатом на повторные комплексные испытания перед выпуском продукта. Любой модуль с плотностью дефектов большей, чем два среднеквадратических отклонения относительно среднего значения будет требовать дальнейшего анализа на предмет возможной модернизации (реинжиниринг).
Индикаторы, интерпретация и информационные продукты. Применение аналитической модели и критериев выбора приводит к индикатору, который «обеспечивает оценку указанных атрибутов, происходящих от аналитической модели, согласно установленным информационным потребностям». Один, или более индикаторов, вместе с их интерпретациями, составляют информационный продукт, который связан с информационной потребностью. На рисунке 2 приведен индикатор, который можно использовать для примера с плотностью дефектов.
ля Х.
Рис. 2. Пример индикатора плотности дефектов
Метрики контролирующего типа используются для мониторинга программных процессов, продуктов и служб, и для определения областей, в которых требуется корректирующее, или управляющее воздействие. Метрики контролирующего типа используются как «красные флаги», предупреждая, когда происходят неожиданные, или незапланированные вещи. Если все идет по плану, то никаких дополнительных действий предпринимать не требуется. Критерии выбора для метрик контролирующего типа могут принимать форму:
- пороговых величин;
- изменчивостей (отклонений, дисперсий);
- пределов регулирования.
Пороговые величины. Пороговые величины устанавливают границы, при пересечении которых требуются некоторые действия, или проведение анализа.
Пороговые величины могут устанавливаться, основываясь на исторических данных, как в приведенном ранее примере с метрикой плотности дефектов. В этом примере было установлено две пороговые величины, основываясь на вычислении среднего значения плотности дефектов и среднеквадратического отклонения плотности дефектов, исходя из величин
исторических данных. Похожим способом можно использовать графики для установления по-
роговых величин, основываясь на промышленных стандартах эталонных тестов. Например, эмпирическим путем установлено, что модули, у которых цикломатическое число графа программы (цикломатическая сложность) больше 10, имеют тенденцию содержать ошибки и сложны для сопровождения [1]. Можно создать график, похожий на график на рисунке 2, где пороги основывались бы на величинах цикломатической сложности для приемлемого уровня меньше, или равного 10, предостерегающего уровня - от 10 до 20, и неприемлемого уровня -больше 20.
Пороговые величины можно устанавливать, основываясь на будущих прогнозах. Например, если планируя проект, прогнозируется 15% коэффициент текучести кадров, то кадровое обеспечение и планы обучения для проекта устанавливаются соответствующе. Тем не менее, существует риск того, что коэффициент текучести кадров может быть выше 15%, что, в свою очередь, может повлиять на возможность завершить проект согласно плану (в сроки), и/или предоставить заявленный уровень функциональности, или качества.
Можно использовать эту меру текучести кадров в качестве инициирующего воздействия при управлении рисками. Критерий выбора в этом случае будет предельно ясным. Если
превышен 15% порог, то применяется кадровый и обучающий план на случай непредвиденных обстоятельств. График на рисунке 3 можно использовать в качестве примера для отслеживания отношения данной меры с течением времени к установленному пороговому значению.
30% -|------------------------------------------
25%---------------------------------------------
^ 20% ш о о.
ч
л 15%
ь 0 т >
^ 10%
5%
о%Н—I—|—I—I—I—|—|—|—I—|—I—I—I—|—I
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Месяцы с начала разработки
Рис. 3. Коэффициент текучести кадров
Похожие графики могут быть использованы для отслеживания других инициирующих воздействий, связанных с рисками, и основанных на прогнозируемых значениях, которые используются для планирования проекта. Например, можно отслеживать постоянно меняющиеся требования в зависимости от прогнозируемых значений, уровень реальной производительности персонала в зависимости от прогнозируемого уровня и предъявляемых к персоналу требований, реальный размер продукта в зависимости от прогнозируемых работ и планов.
Пороговые величины могут устанавливаться, в зависимости от требований заказчика. Например, могут быть требования заказчика к уровням производительности, скорости вычислений, времени реагирования, использования памяти, доступности, надежности, качества. Перечисленные типы технических требований должны быть спроектированы и реализованы в продукте. Если реальные измерения во время моделирования, или тестирования не удовлетворяют установленным требованиям (то есть, пройден порог), то должно быть создано уведомление о дефекте для анализа необходимости изменений в дизайне продукта.
Еще один пример использования требований заказчика в качестве пороговых величин приведен на рисунках 4 и 5. Здесь со стороны заказчика существует требование в виде договора об уровне обслуживания, в котором указано, что 95% всех важных дефектов, уведомления о которых поступают от заказчика, должны быть исправлены в течение 30 дней. График на рисунке 4 показывает процент уведомлений о дефектах, закрываемых каждый месяц в рамках 30-дневного ограничения. Проблема с этим графиком заключается в том, что индикаторы показываются с запаздыванием (за прошедший месяц). Критерием выбора для данной меры было бы использование большего количество ресурсов для решения проблемы в течение следующего месяца, что могло бы улучшить показатели измерений последующего месяца, если ресурсы были бы правильно использованы. Тем не менее, это уже не поможет исправить факт, что требование заказчика не было выполнено в текущем периоде. Данная метрика дополнена графиком распределения на рисунке 5. Данный график и его 30-дневное пороговое значение позволяет действовать упреждающе в стремлении удовлетворить договорным тре-
Пороговая величина
бованиям об уровне обслуживания. Критерий выбора для данной меры временного периода заключается в расстановке возрастающих приоритетов для работ по устранению дефектов по мере приближения дефекта к 30-дневному возрасту.
X
-О
О. 20%
си
м
о4
Месяцы с начала использования программного обеспечения
% дефектов, удовлетворяющих мели 62 65 79 82 76 97 89 96
Количество незакрытых дефектов 1 3 2 1 4 2 1 0
Средний возраст, в днях 22 34 48 30 27 38 23 0
Рис. 4. Скорость реагирования на уведомления о дефектах
Возраст в днях с момента открытия
Рис. 5. Возраст уведомлений о дефектах
Отклонения (дисперсии). Отклонения сравнивают действительные величины с ожидаемыми величинами, после чего принимается решение в зависимости от разницы между величинами. Обычно отклонения вычисляются двумя способами, либо как коэффициент (действительная величина делится на ожидаемую величину), либо как абсолютная разница (действительная величина минус ожидаемая величина).
Диапазон критериев выбора для отклонения коэффициентного типа устанавливается как 1 (или 100%) плюс-минус величина, представляющая собой приемлемый уровень откло-
нения. Отклонение равное 1 (100%) показывает, что реальная величина совпадает с ожидаемой в конкретный момент времени.
Рассмотрим пример определения статуса работ по написанию программного кода, в котором используется отклонение коэффициентного типа. Отклонение рассчитывается как
П
£ Мод
Откл = —--------
п 100%’
где п - количество разрабатываемых модулей, Мод{ - процент завершенности работ по конкретному п-му модулю. На рисунке 6, приведен пример того, как может выглядеть график измерения данного отклонения коэффициентного типа.
1,2 ----------------------------------------------
1.15
Недели с начала разработки
Рис. 6. Определение статуса работ по написанию программного кода
Отклонения коэффициентного типа сильно подвержены влиянию расхождений между реальными и ожидаемыми величинами в зависимости от времени. Например, если сравнивать количество реально выполненных задач на текущее число и количество ожидаемых к выполнению на это же число, то на ранних этапах проекта каждая отдельная задача будет вносить значительный вклад в отклонение. Если ожидается, что 10 задач должны быть выполнены в срок, но реально одну задачу выполнить не успели, то отклонение будет 9/10, или 90%. Если подсчитать отклонение на более поздних этапах проекта, то, например, при ожидаемых выполненных 100 задачах и одной реально невыполненной в сроки, отклонение будет 99/100, или 99%. В зависимости от прогнозируемых и реальных величин в различные моменты времени, при одной и той же разнице между ними, коэффициенты отклонения могут быть разными.
На ранних этапах процесса, или проекта, является более приемлемым (менее рискованным) иметь в наличии большее отклонение, потому что еще достаточно времени на внесение изменений и на усиление контроля отклонений. Но, по мере приближения процесса, или проекта к своему завершению, величина отклонения должна быть небольшой.
Учитывая вышесказанное, рекомендуется рассматривать различные установленные значения диапазонов отклонений для различных периодов проекта, или процесса. Например, для программного проекта на начальном этапе приемлемый диапазон отклонений может быть установлен в 100% ± 25%, а предупреждающий диапазон установлен в 100% ± 40%. На сред-
нем этапе проекта приемлемое отклонение может быть сокращено до 100% ± 15% и предупреждающий диапазон до 100% ± 25%. И на завершающих стадиях проекта приемлемое отклонение может быть снова снижено до 100% ± 5%, а предупреждающий диапазон до 100% ± 10%.
Одним из преимуществ использования отклонений, рассчитываемых как абсолютная разница, является то, что они помогают избегать проблем, связанных с изменениями реальных и ожидаемых величин во времени. На рисунке 7 приведен пример отклонения абсолютной разницы для метрики, отображающей коэффициент использование ресурсов. Другим преимуществом использования отклонений абсолютной разницы является то, что для интегральных измерений таких, как количество завершенных задач, выполненный объем работ, количество использованных ресурсов, или финансов, и т.п., ожидаемые величины, обычно планируемые до окончания процесса, или проекта, и реальные величины, на текущую дату, могут быть экстраполированы.
Рис. 7. Пример использования ресурсов
Создание критериев выбора для отклонения обычно субъективно и основывается на том, что именно управленческий персонал считает важным. Анализ при создании критериев выбора может включать:
- Исторические величины. Сбор и анализ исторической информации о прошлых отклонениях для сходных процессов, продуктов, или служб может помочь обеспечить ценной информацией текущие оценивающие/прогнозирующие процессы. Либо может предоставить информацию о том, какие именно исторические отклонения были приемлемыми во времена успешных процессов, продуктов, или служб. Устанавливая критерий выбора, необходимо учитывать текущие возможности и прошлые успехи.
- Требования клиентов, договоров, или руководства. Могут существовать специфические требования клиентов, договоров, или руководства, которые будут задавать приемлемые, предупреждающие и недопустимые величины для определенных отклонений.
- Практический опыт и стандарты качества. В организации могут быть установившиеся стандарты качества и опыт прошлых работ, которые так же могут задавать приемлемые, предупреждающие и недопустимые величины для определенных отклонений.
Если измеряемое значение отклонения находится в диапазоне допустимых значений, то никаких действий предпринимать не требуется. Если оно находится в диапазоне предупреждающих значений, то, как минимум, измерение должно отслеживаться более тщательно, пока не вернется на приемлемый уровень. Если используемые базовые, или производные меры немного отклоняются от своих оптимальных значений, то может потребоваться анализ причин таких отклонений и корректирующие действия по мере необходимости. Если измеряемое значение отклонения находится в недопустимом диапазоне, то необходимо проводить анализ для определения причин отклонений и выполнить корректирующие действия.
Пределы регулирования. Контрольные карты статистических процессов с пределами регулирования являются одним из классических способов управления процессами. Чтобы установить пределы регулирования, необходимо вычислить среднее значение и стандартные девиации на примере выборки некоторого множества данных из процесса. Среднее значение становится центральной линией (ЦЛ), а создаваемые зоны ± 1, ± 2, ± 3 - стандартными девиациями от среднего значения. Верхний предел регулирования (ВПР) устанавливается в третьей зоне стандартных девиаций от среднего значения. Нижний предел регулирования (НИР) устанавливается в третьей зоне отрицательных величин стандартных девиаций от среднего значения (или на нулевом уровне, если отрицательных величин в измерениях не существует).
Пример, приведенный на рисунке 8, показывает критерий выбора, основанный на пяти шаблонах (паттернах):
- паттерн 1: одно значение данных больше, чем ± 3 стандартных девиации от среднего значения;
- паттерн 2: два из трех последовательных значений данных больше, чем ± 2 стандартных девиации от среднего значения;
- паттерн 3: восемь последовательных значений данных по одну сторону от центральной линии;
- паттерн 4: четыре из пяти последовательных значений данных больше, чем ± 1 стандартная девиация от среднего значения;
- паттерн 5: последовательность из восьми увеличивающихся, или уменьшающихся значений данных подряд.
Весьма маловероятным будет то, если все эти паттерны будут возможны. Если будет обнаружен один из этих паттернов, то процесс, создающий такие данные, должен быть проанализирован на предмет выявления причины такого поведения, которую необходимо скорректировать, либо паттерн данных может быть результатом естественных изменений в процессе, тогда коррекция не потребуется.
2. Критерии выбора для метрик оценивающего типа
Метрики оценивающего типа используются для проверки и анализа программных процессов, продуктов и служб, как составляющая процесса принятия решений. Примерами использования метрик оценивающего типа могут быть:
- выполнение анализа затрат/прибылей;
- анализ возможных вариантов и расстановка их приоритетов;
- выполнение анализа для определения готовности процесса к запуску, или за-
вершению (критерии входа и выхода).
Анализ затрат/прибылей. Данный анализ рассматривает расчетную стоимость проекта, или работы, и сравнивает их с расчетными прибылями от выполнения проекта, или работы, для того, чтобы:
- определить является ли достаточным расчетный коэффициент окупаемости инвестиций для того, чтобы рекомендовать начало выполнения проекта, или работы;
- осуществить выбор между альтернативными проектами, или работами.
Обычно анализ затрат/прибылей выполняется, используя коэффициент, который вычисляется как отношение прибыли проекта, или работы к их стоимости. Примерами стоимости могут служить затраты на людей (зарплата, премии, командировки, обучение, оплата работы подрядчиков), материалы, методологии и инструментарий, основное оборудование, инфраструктуру, и риски. Примерами прибылей могут быть будущие доходы, удержание, или увеличение доли на рынке, улучшение качества технического управления, увеличение производительностей и мощностей, снижение рисков.
Рис. 8. Паттерны критериев выбора на графиках контроля
Любой коэффициент отношения выгод к затратам, меньший единицы, говорит о том, что стоимость проекта, или работы выше, чем ожидаемая прибыль, и должна быть признана неприемлемой. Несмотря на это, должна быть какая-то выгода от вложений, поэтому отношение стоимости к прибыли равное 1, лишь говорит о безубыточности. Когда устанавливаются критерии выбора для коэффициента отношения выгод к затратам, нужно учитывать приемлемые границы прибыли. Например, если принято решение, что прибыль от инвестиций должна быть по меньшей мере 15%, то критерий выбора для коэффициента отношения выгод к затратам должен быть установлен как >= 1,15.
В следующем примере рассматривается проектный риск, который был подвергнут анализу, и было установлено, что вероятность неблагоприятного завершения проекта равна 25% (см. таблицу 1). И если проект завершается неблагоприятно, то прогнозируемые потери соста-
вят 300 000 рублей. Ожидаемая величина риска, подверженность риску, следовательно, будет равна 25% от 300 000 = 75 000 рублей. Если критерий выбора подверженности риску в данном примере показывает, что вероятные потери для любого риска составят более 50 000 рублей, то необходимо рассматривать возможные альтернативы по снижению текущего риска. Как показано в таблице 2, в примере рассматривается три возможных альтернативы.
Таблица1
Текущие параметры риска
Вероятность неблагоприятного завершения (текущая) Потери при неблагоприятном завершении (текущие) Подверженность риску (текущая)
25 % 300 000 руб. 75 000 руб.
Таблица 2
Альтернативы снижения риска
Аль- тер- нативы Вероятность неблагоприятного завершения (будущая) Потери при неблагоприятном завершении (будущие) Подверженность риску (будущая) Стоимость Коэф- фи-циент снижения риска
1 5% 300 000 руб. 15 000 руб. 65 000 руб. 0,9
2 25% 160 000 руб. 40 000 руб. 25 000 руб. 1,4
3 20% 300 000 руб. 60 000 руб. 2 000 руб. 7,5
Ожидается, что принятие альтернативы №1 снизит вероятность неблагоприятного завершения проекта до 5%. Прогнозируемая подверженность риску будет составлять 5% от 300 000 рублей и равняться 15 000 рублям. Выгода от такого снижения риска будет равна 75 000 - 15 000 = 60 000 рублей. Но прогнозируемые затраты на снижение данного риска составляют 65 000 рублей, поэтому коэффициент отношения выгод к затратам будет равняться 60 000/65 000 = 0,9. Поскольку это меньше единицы, то данная альтернатива отвергается.
Альтернатива №2 при реализации риска сокращает потери до 160 000 рублей. Если ее применить, то новый прогноз для подверженности риску будет составлять 25% от 160 000 рублей и равняться 40 000 рублям. Выгода от снижения риска будет равна 75 000 - 40 000 = 35 000 рублей. Прогнозируемые затраты на работы по снижению данного риска составляют 25 000 рублей. Коэффициент отношения выгод к затратам будет равняться 35 000/25 000 = 1,4.
Альтернатива №3 сокращает вероятность наступления риска до 20%. Если применить данную альтернативу, то прогноз для подверженности риску будет составлять 20% от 300 000 рублей и равняться 60 000 рублям. Выгода от снижения риска будет равна 75 000 - 60 000 = 15 000 рублей. Прогнозируемые затраты на работы по снижению данного риска составляют
2 000 рублей, таким образом коэффициент отношения выгод к затратам будет равняться 15 000/2 000 = 7,5. Очевидно, что у данной альтернативы самый высокий коэффициент отношения выгод к затратам из всех трех. Но необходимо помнить о критерии выбора касающегося подверженности риску, который указывает, что любая подверженность риску большая, чем 50 000 рублей, требует анализа альтернатив по снижению этого текущего риска. Новая подверженность риску после применения альтернативы №3 по сокращению риска будет равна 60 000 рублей. Поэтому, несмотря на то, что по коэффициенту отношения выгод к затратам можно применить обе альтернативы №2 и №3, нужно выбрать альтернативу №2.
Следует отметить, что если выбрать альтернативу №2, то подверженность риску останется равной 40 000 рублей. Следовательно, анализируя соотношение выгод и затрат, 40 000 рублей будут рассчитываться как рисковая сумма при подсчете стоимости всего проекта
Анализ возможных вариантов и расстановка их приоритетов. Во время анализа и расстановки приоритетов возможных вариантов, измерения используются для ранжирования множества элементов. Два подобных примера уже обсуждались в данной работе. В первом примере, в котором рассматривался возраст уведомлений о дефектах, критерий выбора использовался для расстановки приоритетов по возрасту уведомления о дефекте. Во втором примере, в котором рассматривался анализ соотношения затрат к выгодам, критерий выбора использовался для расстановки приоритетов между альтернативами снижения риска по их коэффициенту снижения риска.
Одним из классических примеров использования измерений для анализа и расстановки приоритетов является использование диаграмм Парето для набора данных. Анализ с помощью диаграмм Парето представляет собой процесс ранжирования проблем, или категорий, основанный на их частоте проявления, или на величине их воздействия, для того, чтобы определить какой из множества перспектив следует заниматься в первую очередь. Анализ Парето основан на законе Парето, который можно озвучить как «80% всех неисправностей происходят от 20% проблем», или другая формулировка: «20% усилий дают 80% результата, а остальные 80% усилий - лишь 20% результата».
Диаграмма Парето представляет собой гистограмму, в которой высота каждого столбца обозначает частоту, или воздействие проблемы. Для создания диаграммы Парето необходимо следующее:
- Определить категории диаграммы. Например, можно анализировать количество дефектов, возникающих в каждом из нескольких модулей. Или можно распределить частоту появления дефектов по основным причинам, этапам проекта, пользователям, от которых приходят уведомления.
- Выбрать временные интервалы для анализа. Например, можно рассмотреть все дефекты, уведомления о которых получены за последние полгода.
- Определить единицу измерения для каждой категории. Например, это может быть количество дефектов на тысячу строк кода.
- Проранжировать категории от самых частых случаев к самым редким и создать гистограмму, в которой столбцы расположены в убывающем порядке слева направо.
В примере, приведенном на рисунке 9, с помощью диаграммы Парето ранжируются программные модули по плотности обнаруженных в них дефектов для того, чтобы можно было расставить приоритеты над тем, кто является первым кандидатом на повторное проектирование, или кандидатом на дополнительные работы по выявлению дефектов.
Рис. 9. Диаграмма Парето. Подверженность дефектам
Другим методом для анализа и расстановки приоритетов является использование системы показателей (баллов). На рисунке 10 приведен пример системы баллов для ранжирования и выбора поставщиков. Критерием выбора для данной системы показателей является простой выбор поставщика с наибольшими баллами.
Система баллов для ранжирования потенциальных поставщиков
Атрибут Максимальный балл Поставщик 1 Поставщик 2 Поставщик 3
| Возможность доставки к. требуемой дате 10 10 1 8
Стоимость покупки /лицензии 10 П 5 10
Ограничения действия лицензии 5 5 4 5
Стоимость эксплуатации 15 12 15 5
Стоимость сопровождения 10 5 10 7
Возможности технологического процесса 10 10 8 5
Соответствие функциональности продукта потребностям 20 18 16 8
Качество продукта 20 20 15 15
Возможность интеграции с существую- я з 5
щими системами
Возможность интеграции с используемыми бизнес процессами 10 10 7 10
Возможность настройки продукта 5 5 4 5
Техническая поддержка 5 5 3 2
Доступность обучения 10 10 5 5
Общие баллы 135 120 10-1 88
Возможность доставки к требуемой дате = 10 баллов минус один "балл за каждую неделю просрочки после требуемой даты
Соответствие функциональности .продукта потребностям = (число выполненных требований/общее число требований) х 20
Рис. 10. Система баллов для выбора поставщика
Критерии входа и выхода. Критерии входа и выхода представляют собой специфические, измеряемые условия, которые должны удовлетворяться, прежде чем процесс может быть начат, или завершен. Критерии выбора для некоторых метрик оценочного типа зачастую используются как критерии входа/выхода для процесса.
Например, если происходит оценка завершенности тестирования системы, то могут потребоваться измерения следующих величин:
- Критерий выбора отклонения работ по тестированию системы (рисунок 11): суммарный коэффициент интенсивности работ по тестированию системы должен отклоняться от плана не более чем на 10%.
- Критерий выбора статуса активности тестирования системы (рисунок 12): 95% всех запланированных контрольных примеров должны быть выполнены; не должно быть заблокированных контрольных примеров; 95% всех выполненных контрольных примеров должны быть пройдены.
3 4 5 6 7 8 9 10 11 12
Недели с начала тестирования
Рис. 11. Отклонение работ по тестированию системы
Рис. 12. Статус активности тестирования системы
— Критерий выбора частоты появления уведомлений о проблемах (рисунок 13): наклон кривой частоты появления уведомлений о критических проблемах на графике должен приближаться к нулю и не должно быть новых уведомлений о критических проблемах за прошедшую неделю после тестирования; наклон кривой частоты появления уведомлений о сложных проблемах на графике должен приближаться к нулю и не должно быть новых уве-
домлений о сложных проблемах за прошедшие два дня после тестирования; наклон кривой частоты появления уведомлений о средних проблемах должен стремиться к нулю.
— Критерий выбора количества незакрытых уведомлений о проблемах (рисунок 13): должно быть нулевое значение незакрытых уведомлений о критических проблемах; должно быть менее 10 незакрытых уведомлений о сложных проблемах, и для них всех должны быть приняты, согласованные с заказчиком, методы устранения проблем; должно быть меньше 25 незакрытых уведомлений о средних проблемах.
Критические проблемы
] Закрытых
1 2 3 4 5 6 7 8 9 10 11 12
Недели с начала тестирования Сложные проблемы
Недели с начала тестирования
Средние проблемы
І I Закрытых
К>у<Ж>1 Исправленных
1 2 3 4 5 6 7 8 9 10 11 12
Недели с начала тестирования
Рис. 13. Интегральные коэффициенты частоты появления уведомлений о проблемах, распределенные по статусам
3. Критерии выбора для метрик анализирующего и прогнозирующего типа
Метрики анализирующего типа используются как часть исследовательского процесса для изучения программных процессов, продуктов и служб. Примером использования метрик анализирующего типа можно назвать попытки определить:
- Какое количество ресурсов тратится на разработку ПО? На тестирование?
- Как и когда размещать и использовать ресурсы на протяжении всего жизненного цикла?
- Сколько ошибок и какого типа обычно происходят в разрабатываемом ПО? Во сколько они обходятся?
- Каков текущий уровень производительности в организации?
Информация, полученная с помощью метрик анализирующего типа, может использоваться для:
- установления базовых конфигураций, стандартов и целей;
- получения моделей программных процессов;
- выявления зависимостей между параметрами процессов;
- планирования работ по улучшению процессов и продуктов;
- лучшей оценки проектных работ, стоимостей и графиков работ.
Далее, данная информация может быть использована для принятия решений при составлении других типов метрик. Например, в ранее обсуждавшейся плотности дефектов, необходимо было выяснить среднее и среднеквадратичное отклонение для исторического множества данных о плотности дефектов, чтобы установить пороговые значения для критериев выбора, которые используются для контроля плотности дефектов в модулях текущего проекта.
Метрики прогнозирующего типа используются для оценки будущих значений базовых, или производных мер. Метрики прогнозирующего типа используются для ответа на следующие вопросы:
- Сколько это будет стоить (бюджет)?
- Сколько это будет длиться (график работ)?
- Сколько усилий на это понадобится (планирование рабочего штата)?
- Какие другие ресурсы могут потребоваться (управление ресурсами)?
- Какова вероятность того, что что-то пойдет не так, как запланировано? Сколько будет стоить, если что-то пойдет не так, как запланировано (управление рисками)?
- Сколько будет ошибок (качество)?
- Как эти ошибки будут влиять на функционирование (надежность)?
Возвращаясь к стандарту «ISO/IEC 15939 Технология программного обеспечения. Процесс измерения» критериями выбора являются «пороговые величины, целевые величины, или шаблоны, используемые для определения необходимости дальнейших действий, или исследований, либо для описания степени достоверности полученного результата» [2]. Часть этого определения касательно «степени достоверности полученного результата» применяется именно к метрикам анализирующего и прогнозирующего типа.
Рассматриваемыми вопросами во время определения уровня достоверности для полученного результата могут быть следующие:
- Полнота используемых данных. Например, если требуется понять сколько времени было потрачено на разработку ПО, то хотелось бы знать учитывает ли система подсчета времени потраченное на работу время во внеурочные часы?
- Субъективны, или объективны используемые данные? Могут ли люди, или другие виды воздействий, повлиять на данные?
- Какова целостность и точность данных? Если рассмотреть опять пример с учетом времени, то в нем необходимо так же учитывать отмечают ли люди время работы сразу по выполнении конкретной задачи, или они ждут конца недели, а потом вспоминают и подсчитывают сколько времени они потратили на разные проекты?
- Насколько стабилен измеряемый процесс, или служба? Например, если в организации используется новый процесс, или новый язык программирования, то сделанные прогнозы могут быть недостоверными, поскольку существующие исторические данные были сделаны в других условиях, либо подходящих исторических данных для прогноза может не быть вообще.
- Какими могут быть отклонения внутри множества данных? Например, на рисунке 14 отображено распределение ответов на три разных вопроса из анкетирования клиентов на предмет удовлетворенности обслуживанием. На каждый из этих вопросов средний уровень удовлетворенности клиентов равен трем. Но насколько можно быть уверенным в том, что для всех трех вопросов уровень равен трем? Если распределение выглядит как для вопроса A, то можно быть уверенным в том, что тройка явно представляет мнение клиентов. Но в том, что тройка представляет уровень удовлетворенности клиентов для распределений B и C , уверенности гораздо меньше.
Рис. 14. Результаты опроса об уровне удовлетворенности клиентов
Заключение
Имея четко поставленные и адекватные критерии выбора, можно быть уверенным в том, что результаты измерений корректно интерпретируются и применяются пользователями этих измерений. Хотя стандарт «ISO/IEC 15939 Технология программного обеспечения. Процесс измерения» дает определение тому, что такое критерий выбора и приводит несколько примеров, но он не дает указаний как именно создавать критерии выбора для метрик. Важно решить, как именно будут использоваться метрики, которые планируется собирать, и нужны ли они вообще, чтобы контролировать, оценивать, анализировать, прогнозировать, или делать все перечисленное вместе. Предметом исследования дальнейших работ будут попытки определить и создать критерии выбора для различных типов метрик.
ЛИТЕРАТУРА
1. C. Jones. Applied Software Measurement: Assuring Productivity and Quality // McGraw Hill, New York, 1991, ISBN 0-07-032813-7.
2. ISO/IEC 15939:2007. Software Engineering. Software Measurement Process.
3. Practical Software Measurement: Objective Information for Decision Makers / J. McGarry, D. Card, C. Jones, B. Layman, E. Clark, J. Dean, F. Hall // Addison-Wesley, Boston, 2001, ISBN-0201-71516-3.
4. W.S. Humphrey. Managing the Software Process // Addison-Wesley Publishing Company, Reading, MA, 1989, ISBN 0-201-18095-2.
Рецензент: Помелов Денис Сергеевич, руководитель направления проектирования и разработки программного обеспечения, кандидат технических наук, ЗАО «ЕС-лизинг»
