Слайдкаст. Измерения в ИТ и ПО. Часть II

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

Давайте познакомимся
Сергей Поволяшко.
IT с 1996 года. Работал по нескольким IT специальностям . С 2001 года управляю операционной деятельностью и проектами.
Принимал лидирующее участие во внедрении и оценке CMMI L3 в TEAM International, 2008 .
PMI PMP, 2007
Работаю в должности CTO в компании TEAM International, www . teaminternational . com .
Веду проект ИТ Тюнинг, www.it-tuning.com .
Настройка проектной и операционной деятельности

Содержание
Часть 1. Концепции, структура. (Предыдущий слайдкаст)
Зачем вообще что-то мерять?
Основные Концепции Метрик
Структура показателей (Измерение, Метрика, Key Performance Indicator – KPI, Critical Success Factor – CSF)
Часть 2. Практика. (Этот слайдкаст)
Определение системы метрик качества процесса для достижения бизнес цели , а также подход по количественному контролю

Эта презентация представляет собой обзор 2-х дневного тренинга “ Измерения в ИТ и ПО. Как, что и зачем измерять. ”
Области применимости метрик
Измерения по фазам жизненного цикла
Качество продукта
Производительность: проекта, персональная
Качество процессов производства
Сервисные метрики
HR метрики
Нефинансовые метрики деятельности компании
Понятие Размера (Size)
Анализируем метрики
Количественное управление и предсказание качества
Внедрение программы метрик
Подробнее о тренинге здесь: http ://it-tuning.com/?page_id=56
Тренинг

Ссылки
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/

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

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

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

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

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

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

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

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

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

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

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

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

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

Для любой одной метрики подробно описать как именно она определяется.
Рассмотрим Эффективность устранения дефектов
( Defect Removal Efficiency - DRE )
Практика

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

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

Для любой одной метрики подробно описать как именно она определяется. Рассмотрим DRE :
« Σ _ Устраненные_Дефекты» - до Приемочного тестирования
« Σ _ Обнаруженные_Позже» - обнаруженные во время Приемочного тестирования
« Σ _ Обнаруженные_Позже», которые являются изменениями и дубликатами не защитываются
Данные берутся из системы управления дефектами NNN
…
Практика

Спасибо за внимание!
Смотрите «Часть 1. Концепции, структура»
Подробнее:
О тренинге « Измерения в ИТ и ПО. Как, что и зачем измерять.” http :// it-tuning.com /?page_id=56
О проекте ИТ тюнинг www.it-tuning.com
Контакт: [email_address]

Слайдкаст. Измерения в ИТ и ПО. Часть II

by Sergiy Povolyashko on Jul 02, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 771

Statistics

Слайдкаст. Измерения в ИТ и ПО. Часть II — Webinar Transcript

http://it-tuning.com	766
url_unknown	5