Software Measurements Training Overview

Измерения в разработке ПО. Как, что и зачем измерять. Обзор тренинга Сергей Поволяшко , www.it-tuning.com

1 5 лет стажа в IT. Работал по нескольким IT специальностям (разработчик, системный администратор, тестировщик). С 2001 года управляю проектами и IT подразделениями. Место работы – Team ODC (TODC) , LLC. www . teaminternational . com . Менеджер отдела разработки, менеджер проектов, менеджер IT инфраструктуры Принимал лидирующее участие во внедрении CMMI Level 3 Проект «ИТ Тюнинг» - www.it-tuning.com . Настройка, упорядочивание рабочих процессов ИТ компании. Давайте познакомимся Образование, сертификации: ХГТУРЭ, 1996. Project Management Professional (PMP), PMI. 2007 ITIL Foundation V 3. 2009 Сергей Поволяшко

Цели Обзора Рассмотреть полное содержание тренинга Рассмотреть выборочные темы из тренинга «Измерения в разработке ПО. Как, что и зачем измерять.» ( В полном содержании выделены зеленым ) Зачем вообще что-то мерять? Основные Концепции Метрик Ознакомиться с одним из практических заданий, позволяющим оценить взаимосвязь системы измерений с бизнес целями, а также подход по количественному контролю

Содержание тренинга, Организационные вопросы, Цели Введение в метрики Зачем вообще что-то мерять? Внедрение Метрик. Обзор (Люди, Процессы, Инструментарий) Взаимосвязь с окружающей средой Основные Концепции Метрик. Обзор Философия и реальность Жизненный цикл измерений Практика. Жизненный цикл измерений Структура показателей ( Измерение , Метрика , Key Performance Indicator - KPI, Critical Success Factor – CSF, Balanced Scorecard, Dashboard) Понятие Размера (Size) Зачем нужен размер Методики и единицы размера Практика. Определение модели размера для функциональной спецификации Размер документации, объема работ, продукта Полное содержание

Основные области применимости метрик, обзор Измерения по фазам жизненного цикла Качество продукта Производительность: проекта, персональная Качество процессов производства Сервисные метрики HR метрики Нефинансовые метрики деятельности компании Модель реестра метрик Содержание

Метрики поподробней Качество продукта - инспектирование документов Практика, модель реестра метрики инспектирования Спецификаций Качество продукта - инспектирование кода Качество продукта - функциональное тестирование Практика. Модель реестра реестра метрики DRE Качество подержки Качество продукта – производительность Содержание

Метрики поподробней (продолжение…) Производительность проекта (метод освоенного объема) Персональная производительность Качество процесса производства Практика. Определение системы метрик качества процесса Сервисные метрики HR метрики Нефинансовые метрики деятельности предприятия Практика. Подобрать состав метрик для разных типов проектов, контрактов Содержание

Анализируем метрики О чем задуматься анализируя метрики Происхождение и количество дефектов Примеры анализа метрик и принятия мер Количественное управление и предсказание качества Исторические данные (Historical Data) Статистическое управление процессом (Statistical Process Control - SPC) Модели размерности (COQUALMO - COCOMO) Внедрение программы метрик План внедрения (интеграции) Практика. Внедрение метрик в производственную среду Проблемы внедрения Содержание

Ссылки Software Measurement: Establish - Extract - Evaluate – Execute. Christof Ebert, Reiner Dumke Measuring the software process . William A. Florac, Anita D. Carleton ISO 15939 Systems and software engineering -- Measurement process The complete Project Management Office Handbook. Gerard M. Hill ITIL Core Publications: Service Design, Continual Service Improvement. UK Office of Government Commerce Project Management. A systematic approach to planning, scheduling and controlling. Harold Kerzner PMBOK® Guide . Fourth Edition . PMI PMP Exam Prep. Fifth edition. Rita Mulcahy Wikipedia ( www.wikipedia.org ) Practice Standard for Earned Value Management . PMI http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html http://csse.usc.edu/csse/research/COQUALMO/

Зачем вообще что-то мерять? Измеряем чтобы: Контролировать ( Monitor ) Улучшать ( Improve ) Делать приемку товаров / услуг ( Acceptance criteria ) Непрерывно оценивать качество процесса, продукта, услуги Оценивать достижение целей Принимать обоснованные решения (Manage)

Зачем вообще что-то мерять? Зачем? Контролировать ( Monitor ): качество, состояние, тренды Значения (напр. дефекты) Периоды измерений Инструментарий . Контрольная диаграмма ( Control Chart ) Целевые показания или среднее значение (goal) Верхняя и нижняя контрольные границы ( upper and lower control limits ) Пример . Количество дефектов в очередной итерации, релизе

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

Зачем вообще что-то мерять? Зачем? Делать приемку товаров / услуг ( Acceptance criteria ) Инструментарий . Договорные обязательства, специфический инструментарий, запланированные процедуры контроля критериев Примеры : Программный продукт должен содержать не более 10 несущественных дефектов Веб сайт должен быть доступен не менее 99.8% времени 98% дверей в партии должны быть 2 метра в высоту с допустимым отклонением + / - 2 мм.

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

Зачем вообще что-то мерять? Зачем? Оценивать достижение целей Инструментарий . План действий и система измерений отражающие текущее и целевое состояния Примеры : Увеличить эффективность использования ( utilization ) ресурсов на 20% к концу полугодия Какие ресурсы у нас есть сейчас (люди, оборудование, площади)? Как они используются сейчас? Какие именно из ресурсов подлежат оптимизации и измерению? Какой реалистичный план по увеличению эффективности? Если в течение полугодия видно что цель недостижима, то что будет предпринято? Уменьшить количество дефектов в два раза в следующем типичном проекте Сколько обычно дефектов в типичных проектах? Почему они появляются? Какой реалистичный план по уменьшению количества дефектов? Если количество дефектов не уменьшается, то что будет предпринято?

Зачем вообще что-то мерять? Принимать обоснованные решения (Manage) Контролировать ( Monitor ) Улучшать ( Improve ) Делать приемку товаров / услуг ( Acceptance criteria ) Непрерывно оценивать качество процесса, продукта, услуги Оценивать достижение целей

Основные Концепции Метрик Немного Философии Нельзя управлять тем, что нельзя измерить . Peter Drucker, Tom De Marco Не имея правильной информации, вы всего лишь еще один человек со мнением . Tracy O’Rourke Если вы не знаете куда вы идете, то любая дорога приведет вас туда

Основные Концепции Метрик Немного Реальности Измерения должны давать ответы, реальная потребность состоит не в числах, а что стоит за ними, т.е. быть полезными Измерения должны быть интегрированы в инженерные и управленческие процессы Измерения должны быть ориентированы на конкретные цели и помогать бизнесу быть успешным В последние годы происходит смена парадигм от «Какие измерения следует использовать ? » до «Что нужно для улучшений ( Improvements ) ? » Ловушкой многих программ измерений является отсутствие взаимосвязи между целями бизнеса и этой программы. Цели должны быть SMART (Specific, Measurable, Attainable, Relevant, Timely) Лучший способ контролировать успешность проекта это установить формальные цели (содержание, расписание, бюджет, качество) в виде измеримых величин и контролировать их

Основные Концепции Метрик Необходимые условия для успешности измерений Люди Процессы Инструментарий

Основные Концепции Метрик Жизненный цикл измерений [ISO 15939 Systems and software engineering -- Measurement process ] Информационные потребности Цели / интересы компании, заказчика, проекта Виды контрактов, проектов, бизнеса, среда, ресурсы Бизнес процессы Технологические процессы Учредить и поддерживать обязательства по измерениям (Establish and Sustain Measurement Commitment) Планирование процесса измерений (Plan the Measurement Process) Выполнение процесса измерений (Perform the Measurement Process) Оценка измерений и улучшения (Evaluate Measurement , Improvements ) Информационный продукт для управленческих решений ( Information product )

Основные Концепции Метрик ISO 15939 Информационная модель измерений ( Measurement Information Model ) [ISO 15939 Systems and software engineering -- Measurement process ] Аттрибут Метод измерения Базовое измерение Аттрибут Метод измерения Базовое измерение Функция имерения Производное измерение (метрика) Производное измерение (метрика) Модель анализа Индикатор Интерпретация Информационный продукт

Основные Концепции Метрик Структура показателей Миссия, видение, стратегические цели бизнеса. Информационные потребности. (Mission, Vision, Goals, Information needs) Критический фактор успеха ( CSF – Critical Success Factor ) Ключевой индикатор эффективности ( KPI – Key Performance Indicator ) Метрики ( Metrics ) Измерения ( Measurements, raw data )

Основные Концепции Метрик Структура показателей Измерения ( Measurements, raw data ) Аттрибут – базовая характеристика, свойство какого-то объекта Измерение (процедура, метод) – присвоение количественных значений аттрибутам объектов с целью систематического представления свойств, характеристик этого объекта. Измерение (базовое) – количественное значение, присвоенное аттрибуту как результат метода измерения Примеры: Аттрибут «рост», измеряется Методом растягивания рулетки от пола до макушки и замера значения роста, полученное значение – Базовое Измерение – измеряется в сантиметрах. Аттрибут «размер кода», измеряется Методом подсчета строк кода не учитывая комменатрии и пустые строки, полученное значение измеряется в строках кода ( LOC – Lines of Code ) Аттрибут Метод измерения Базовое измерение

Основные Концепции Метрик Структура показателей Метрики ( Metrics ) Функция измерения – алгоритм / способ комбинирования / обработки Базовых Измерений Производное измерение (Метрика) – значение, получившееся в результате применения Функции измерения к двум или более Базовым Измерениям. Во многих случаях Метрика нормализуется, т.е. приводится к определенной шкале / размерности с целью соизмеримости. Например процентам, или от 0 до 1, или по соотношению к определенному размеру. Пример: Метрика Плотность Дефектов на тысячу строк кода ( DD – Defect Density ) может определяется путем вычисления Базовых Измерений – количество строк кода и количество дефектов, с применением Функции : DD = DN/KLOC Функция измерения Производное измерение (метрика)

Основные Концепции Метрик Структура показателей Ключевой индикатор эффективности ( KPI – Key Performance Indicator ) Модель анализа – алгоритм / способ комбинирования / обработки одного или более Базового и / или Производного измерения (Измерения и / или Метрики) и критериев принятия решений. Индикатор ( KPI ) – значение, получившееся в результате применения Модели анализа к Базовым и / или Производным измерения и критериям принятия решений. На практике, в стратегическом смысле, KPI определяют / отслеживают цели, наиболее важные / ключевые для бизнеса / проекта К KPI можно применить SMART модель: Specific ( Конкретный ) ; Measurable ( измеримый ) ; Achievable ( достижимый ) ; Relevant ( значимый ) ; Time ( временнОй ) . Модель анализа Индикатор

Основные Концепции Метрик Структура показателей Пример структуры: CSF – KPI - Метрики : CSF: Эффективное управление проектами KPI: Уменьшить перерасход бюджета на 5% в течение года Улучшить качество на 10% в течение года Улучшить оценку трудозатрат на 20% для проектов типа А к концу 2010 года Метрики ( KPI: Улучшить качество на 10% в течение года) Плотность дефектов при инспекции кода Плотность дефектов при функциональном тестировании Эффективность удаления дефектов Рейтинг качества процессов разработки

Метрики поподробней Определение системы метрик качества процесса. Практика

Метрики поподробней Определение системы метрик качества процесса. Практика Условие. Разрабатывается продукт, квартальные итерации. В каждой итерации должна добавляться новая функциональность. Есть план по добавлению новых функций на несколько кварталов вперед. Объем работ в каждом квартале примерно одинаков. Жизненный цикл в каждой итерации одинаков. Он состоит из следующих фаз и результатов: Сбор требований и инспекция требований. Результат – Спецификация ( SRS ) и Отчет инспектирования Архитектура продукта и инспекция архитектуры. Результат – Спецификация ( SDS ) и Отчет инспектирования Кодирование и инспекция кода. Результат – Код и Отчет инспектирования Тестирование: разработка Тест Кейсов, инспектирование Тест кейсов, Тестирование. Результат – Тест Кейсы ( TC ), Отчет инспектирования , Отчет по тестированию , протестированный продукт Приемочное тестирование ( UAT ) . Результат - Отчет по приемочному тестированию

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

Метрики поподробней Определение системы метрик качества процесса. Практика Руководство в новом году решило искоренить проблемы и поставило перед отделом разработки такие Бизнес цели к концу года: Укладываться в срок Реализовывать обещанный состав функций в квартал Уменьшить количество дефектов при приемочном тестировании в три раза

Метрики поподробней Определение системы метрик качества процесса. Практика Задача отдела разработки достичь указанных бизнесс целей, для этого, очевидно, нужно серьезно пересмотреть существующие проблемы в процессах производства продукта, возможно найти новые, и убедиться на конкретных цифрах что улучшения происходят, и происходят достаточно быстро и эффективно. Как видно из условия в распоряжении есть 1 год. Для количественного контроля и управления нужно внедрить систему измерений качества процессов разработки. Рассмотрим такой подход: Шаг №1. Определить бизнес цели и проблемы Шаг №2. Определить цели и проблемы процессов Шаг №3. Выбрать и определить измерения

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №1. Определить бизнес цели и проблемы: Прояснить бизнес цели Определить текущие и потенциальные проблемы Ожидаемый результат: Список бизнес целей Список текущих и потенциальных проблем

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №1. Ответ. Определить цели и проблемы Список бизнес целей Укладываться в срок Реализовывать обещанный состав функций в квартал Уменьшить количество дефектов при приемочном тестировании в три раза

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №1. Ответ. Определить цели и проблемы Список бизнес целей Укладываться в срок Реализовывать обещанный состав функций в квартал Уменьшить количество дефектов при приемочном тестировании в три раза Список текущих и потенциальных проблем Плохое качество Несоблюдение сроков Невыполнение объема работ Плохая масштабируемость (переработки)

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №2. Определить цели и проблемы процессов: Определить критичные процессы Определить цели для каждого критичного процесса Сгруппировать проблемы в логические блоки Ожидаемый результат: Список критичных процессов с весовым коэффициентом от 1 до 5 (5 – наиболее критичен) Список целей для критичных процессов Сгруппированный список проблем (если это имеет смысл)

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №2.1. Ответ. Определить цели и проблемы процессов Список критичных процессов с весовым коэффициентом от 1 до 5 (5 – наиболее критичен) Сбор требований – 4 Архитектура продукта – 4 Кодирование – 3 Тестирование – 5 Планирование – 2 Инспекция документов и кода – 5 Выберем наиболее критичные (вес – 4, 5)

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №2.2. Ответ. Определить цели и проблемы процессов Список целей для критичных процессов Сбор требований. Документировать запланированное количество требований с высоким качеством Архитектура продукта. Должны быть качественно отражены задокументированные ранее требования с учетом существующей и будущей функциональности Тестирование. Тестовая документация должна полно отражать требования . При тестировании должно быть увеличено количество обнаруживаемых дефектов с целью достижения критериев приемки Инспекция документов и кода. Инспекция SRS, SDS, TC, кода должна находить «адекватное» количество дефектов Для оценки соблюдения сроков и количества реализованных требований используется SPI (Schedule Performance Index)

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3. Выбрать и определить измерения Для каждого выбранного процесса определить объекты и аттрибуты, подлежащие измерениям Протестировать адекватность выбранных измерений. Например, оценить адекватность инспектирования документов Четко описать что именно включено, исключено и как считается для определения измерений Ожидаемый результат: Список метрик и измерений для выявленного ранее списка целей Предложить условия и способ оценки адекватности инспектирования документов Для любой одной метрики подробно описать как именно она определяется

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3.1. Ответ. Выбрать и определить измерения Список метрик и измерений для выявленного ранее списка целей Оценка качества документации посредством инспектирования документов. Метрика Плотности дефектов – Defect Density (DD) – количество дефектов на единицу размера. DD(SRS) . DD(SDS) . DD(TC)

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3.1. Ответ. Выбрать и определить измерения Список метрик и измерений для выявленного ранее списка целей Оценка качества документации посредством инспектирования документов. Метрика Плотности дефектов – Defect Density (DD) – количество дефектов на единицу размера. DD(SRS) . DD(SDS) . DD(TC) Оценка качества тестирования. Эффективность устранения дефектов – Defect Removal Efficiency (DRE (UAT))

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3.1. Ответ. Выбрать и определить измерения Список метрик и измерений для выявленного ранее списка целей Оценка качества документации посредством инспектирования документов. Метрика Плотности дефектов – Defect Density (DD) – количество дефектов на единицу размера. DD(SRS) . DD(SDS) . DD(TC) Оценка качества тестирования. Эффективность устранения дефектов – Defect Removal Efficiency (DRE (UAT)) Оценка соблюдения сроков и количества реализованных требований используется – Schedule Performance Index ( SPI )

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3.1. Ответ. Выбрать и определить измерения Список метрик и измерений для выявленного ранее списка целей Оценка качества документации посредством инспектирования документов. Метрика Плотности дефектов – Defect Density (DD) – количество дефектов на единицу размера. DD(SRS) . DD(SDS) . DD(TC) Оценка качества тестирования. Эффективность устранения дефектов – Defect Removal Efficiency (DRE (UAT)) Оценка соблюдения сроков и количества реализованных требований используется – Schedule Performance Index ( SPI ) Оценка размерности (количества) прошедших сквозь жизненный элементов # ( Req ) – количество задокументированных требований # (Des) – количество задокументированных новых или измененных элементов архитектуры # ( TC ) – количество созданных тест кейсов или их элементов

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3.2. Ответ. Выбрать и определить измерения Предложить условия и способ оценки адекватности инспектирования документов. Или как убедиться что инспекция проведена качественно Желательно наличие руководств по инспектированию документов

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3.2. Ответ. Выбрать и определить измерения Предложить условия и способ оценки адекватности инспектирования документов. Или как убедиться что инспекция проведена качественно Желательно наличие руководств по инспектированию документов Необходимы чек листы инспектирования для каждого типа документов

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3.2. Ответ. Выбрать и определить измерения Предложить условия и способ оценки адекватности инспектирования документов. Или как убедиться что инспекция проведена качественно Желательно наличие руководств по инспектированию документов Необходимы чек листы инспектирования для каждого типа документов Проводить инспекцию должны достаточно квалифицированные специалисты

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3.2. Ответ. Выбрать и определить измерения Предложить условия и способ оценки адекватности инспектирования документов. Или как убедиться что инспекция проведена качественно Желательно наличие руководств по инспектированию документов Необходимы чек листы инспектирования для каждого типа документов Проводить инспекцию должны достаточно квалифицированные специалисты Специалисты должны быть обучены и заинтересованы найти дефекты

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3.2. Ответ. Выбрать и определить измерения Предложить условия и способ оценки адекватности инспектирования документов. Или как убедиться что инспекция проведена качественно Желательно наличие руководств по инспектированию документов Необходимы чек листы инспектирования для каждого типа документов Проводить инспекцию должны достаточно квалифицированные специалисты Специалисты должны быть обучены и заинтересованы найти дефекты Практика и статистика за определенное время покажет какова усредненная Плотность дефектов на единицу размерности. Существенное отклонение в любую сторону это повод для беспокойства

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3.3. Ответ. Выбрать и определить измерения Для любой одной метрики подробно описать как именно она определяется. Рассмотрим Эффективность устранения дефектов ( Defect Removal Efficiency - DRE )

Метрики поподробней Эффективность устранения дефектов ( Defect Removal Efficiency ): DRE = Σ Устраненные_Дефекты ÷ ( Σ Устраненные_Дефекты + Σ Обнаруженные_Позже ) * 100%

Метрики поподробней Эффективность устранения дефектов ( Defect Removal Efficiency ): DRE = Σ УД / ( Σ УД + Σ ОП ) * 100% Производство продукта Приемочное тестирование ( UAT ) Эксплуатация Начало отсчета для Σ ОП Начало отсчета для Σ ОП или

Метрики поподробней Определение системы метрик качества процесса. Практика Шаг №3.3. Ответ. Выбрать и определить измерения Для любой одной метрики подробно описать как именно она определяется. Рассмотрим DRE : « Σ _ Устраненные_Дефекты» - до Приемочного тестирования « Σ _ Обнаруженные_Позже» - обнаруженные во время Приемочного тестирования Используются весовые коэффициенты «тяжести» дефектов - High = 5 , Middle = 3 , Low = 1 « Σ _ Обнаруженные_Позже», которые являются изменениями и дубликатами не защитываются Данные берутся из системы управления дефектами NNN …

Контакт: [email_address] Подробнее: О проекте « ИТ Тюнинг » и тренингах http :// www.it-tuning.com О себе http :// www . linkedin . com / in / sergiypovolyashko Презентации http://www.slideshare.net/sergiyp1974 Тренинги Risk Management (Управление Рисками). Оказывается ими можно управлять. Scheduling (Планирование, Разработка расписания работ). Не так просто как кажется, структурируем очевидные вещи. Software Measurements (Измерения в разработке ПО). Как, что и зачем измерять. Полет по приборам: метрики проектных команд – управляемое движение.

Software Measurements Training Overview

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Software Measurements Training Overview (20)

More from Sergiy Povolyashko (9)

Software Measurements Training Overview