Метрики. Роль метрик в процессах разработки пп
Метрики. Роль метрик в процессах разработки ПП
Измерение помогают понять как процесс разработки продукта, так и сам продукт.
Измерение процесса производится для его улучшения, а измерение продукта для повышения его качества.
В результате измерения определяется мера – количественная характеристика какого-либо свойства объекта.
Путем непосредственного измерения могут измеряться только опорные свойства объекта. Все остальные свойства вычисляются с помощью функций от значений числовых опорных характеристик. Такие вычисленные значения свойств называются метриками.
И в IEEE Standart Golossary OF SoftWare Ingeniring Terms метрика определена как мера степени обладания свойством, имеющая числовое занчение.
Все метрики можно распределить на 2 основные группы:
метрики процесса;
метрики проекта;
метрики продукта.
Рассмотрим типовую структуру распределения проектных работ.
Структура:
системный анализ
анализ требований
предварительное проектирование
Как видно из типовой структуры, задачи по проектированию и планированию тестов могут быть распараллелены. Благодаря модульной природе ПО для каждого модуля можно предусмотреть параллельный путь для детального (процедурного) проектирования, кодирования и тестирования.
Ромбиками на рисунками обозначены вехи – процедуры контроля промежуточного результата. Очень важно чтобы вехи были расставлены через регулярные интервалы (вдоль всего процесса разработки ПО). Это даст возможность регулярно получать информацию о текущем положении дел. Вехи распространяются и на документацию.
Параллельность действий повышает требования к планированию, т.к. параллельные задачи выполняются асинхронно, планировщик должен определить межзадачные зависимости это гарантирует «непрерывность движения к объединению». Кроме того, руководитель должен решать задачи лежащие на критическом пути. Для того чтобы весь проект был выполнен в срок, необходимо выполнять в срок все критические задачи.
Основной рычаг в планирующих методах это метрики – вычисление границы времени выполнения задачи. Время относится к размерно-ориентированным метрикам.
Мера измерения объема планируемого продукта LOC метрика (lines of code) – количество строк программной продукции. На основание LOC оценок можно вычислить размерно-ориентированные метрики производительности качества для каждого проекта.
Производительность равна = длина (LOC) / затраты (человеко-часы)
Качество = ошибки / длина (LOC)
Метрики и модели cmm-sei. Парадигмы Бейзили
Метрики и модели CMM-CEI
Рассмотрим второй уровень зрелости. Ключевой процесс: управление требованиями к ПП, примеры метрик. Действия в этом процессе представлены в таблице.
На этом процессе собираются следующие метрики: состояние каждого из сформулированных требований; действия по изменению сформулированных требований. Накапливающийся итог по количеству изменений сформулированных требований.
Ключевой процесс планирования ПП, примеры метрик: дата завершения основополагающих стадий для различный действий в соответствии с развитием проекта, трудозатраты, определяемые после завершения работ, распределение средств по видам действий, связанных с планированием проекта.
Ключевой процесс: контроль за выполнением программного проекта. Примеры метрик: затраты ресурсов при выполнении контроля, число изменений при планировании проекта.
Третий уровень зрелости. Ключевой процесс: повышение квалификации сотрудников. Метрики: посещаемость (реальная) каждого курса обучения и сравнение с планированной посещаемостью. Прогресс для организации проекта в результате посещения курсов, число сбоев при проведении обучения, результаты тестирования по окончанию курсов, поддержка обратной связи с руководителями проектов.
Ключевой процесс: индустриальный подход к проектированию и разработке ПП. Примеры метрик: число, типы и серьезность дефектов определенных в ПП, соответствуют ли требования категориям «безопасность», «системная конфигурация», «надежность». Кроме того, измерение метрик производится для определения различных форм по разработке ПП: состояние каждого требования на протяжении всей разработки. Отчеты об имеющихся проблемах с указанием степени их важности.
Трудозатраты на анализ предложенных изменений, объем изменений по категориям, объем затрат при реализации и тестирование внесенных изменений.
Четвертый уровень зрелости. Ключевой процесс: управление качеством проекта. Данный ключевой процесс включает в себя действия по определению целей, измерение производительности процесса, анализ этих измерений, а также настройку и функционирование процесса в рамках допустимых ограничений. Если при выполнении процесс пройдет его стабилизация в рамках допустимых ограничений, определенный проектом процесс и его измерение утверждаются и применяются в качестве базы для осуществления количественного контроля над выполнением процесса. Следующий ключевой процесс: измерение и анализ процесса. Примеры метрик: точность измерения данных о размере стоимости проекта. Производительность при выполнении различных видов работ. Качественные показатели, тестовое покрытие и эффективность тестов, меры по обеспечению надежности программ, число и серьезность недостатков, обнаруженных в программном коде и требований к ПП.
Парадигмы Бейзили
Подход Бейзили наиболее удобен для контроля над проектом и формировании решений. Цель устанавливается еще до выбора метрик.
Методика Бейзили состоит из 7 этапов:
Первый этап: определение набора целей
Представление (характеристика) предполагает формирование модели, в которой удобно представить собранные данные. Оценивание подразумевает наличие шаблона для данных, который позволяет разрабатывать постоянную модель, основанную на корректно отсеиваемых данных. Мотивация (совершенствование), предполагает наличие точной модели, позволяющей правильно представить объект или позитивное качество. Перспектива – проверка объема затрат, эффективности, корректности, наличия дефектов, изменений, измерений продукта с точки зрения разработчика, менеджера, заказчика. Среда определяет контекст, в котором происходит изучение.
Фактор процесса: выбор модели ЖЦ, методик инструментов, языков программирования.
Факторы продукта: внутренние поставки, размер системы, требуемый уровень качества.
Факторы ресурса: календарное время, объемы бюджетных средств, существующий программный код.
Второй этап: Формирования набора вопросов, характеризующих цели.
Цели определяются на абстрактном уровне, а вопросы предназначаются для освещения уровня выполняемых операций. Отвечая на вопросы необходимо уточнить, достигнута ли поставленная цель.
Третий этап: Определение метрических показателей, необходимых для получения ответов.
Четвертый этап: Разработка механизмов сборов данных.
Сбор данных, который не относится к целевым изменениям не приносит пользы. В идеале собранные данные размещаются в исторической базе данных организации, и постоянно используются в работе.
Чтобы правильно организовать работу по сбору данных, полезно рассмотреть следующие вопросы:
Кто ведет сбор данных?
Когда следует выполнять сбор данных?
Каким образом назначить сбор данных лучше и эффективнее? Лучше всего воспользоваться автоматизированными инструментами.
Кто непосредственно работает с метриками?
Пятый этап: сбор подтверждений и анализ данных в реальном времени для поддержки обратной связи между корректирующими действиями и проектами.
Следует руководствоваться следующими принципами: не усложнять процедуру сбора, избегать ненужных записей, обучить персонал вести записи в соответствии с процедурами которые для этого используются, подтверждать данные собранные в исторической базе данных. Процесс анализа удобнее всего проводить на графическом материале (Графики, диаграмма Ишикава, диаграмма Парето, рассеянная диаграмма)
(Причины и следствия в виде елочки)
Шестой этап: анализ данных с использованием подпрограммы для соответствия целям и рекомендации для дальнейшего совершенствования.
Необработанные метрические данные трудны для понимания, необходимо их структурировать, например: общее количество ошибок ни о чем не говорит, а если ошибки распределить по типам, то уже можно разработать рекомендации.
Седьмой этап: поддержка обратной связи для организаторов проекта и его участниками.