Опыт консалтинга: метрики процесса

бизнес-анализадля компаний, разрабатывающих программные продукты

и системы

Обзор• Цель: совершенствование процесса управления

требованиями• Клиенты: компании, разрабатывающие заказное ПО и

собственные продукты с численностью персонала более 200 человек (в RnD)•Методы: аудит процесса управления требованиями и

определение дальнейших шагов по совершенствованию процесса• Результаты: цели достигнуты

Кейс 1: Компания. Разрабатывающая мобильные приложения• Число сотрудников: около 200 человек (RnD) • Клиенты: банки, страховые компании• Проектные роли: менеджер проекта, аналитик, разработчик,

тестировщик, GUI-дизайнер • Роль аналитика: бизнес-требования, пользовательские требования,

функциональные требования, нефункциональные требования• Озвученные проблемы: противоречивые требования, разработка

требований ведется больше времени, чем запланировано (в 3 и более раз), трудности со сбором требований

Кейс 2: Компания, разрабатывающая собственный программный продукт• Число сотрудников: около 2000 человек (RnD)• Клиенты: пользователи продуктов, разрабатываемых компанией• Проектные роли: Менеджер продукта, менеджер проекта,

системный аналитик, разработчик, тестировщик, сотрудник техподдержки, технический писатель• Роль аналитика: бизнес-требования, пользовательские

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

управления требованиями

Аудит процесса бизнес/системного анализа• Используемые методы: • Интервьюирование аналитиков (опросники и устные

интервью)• Опросники: для определения объема проводимого аудита

и формирования and картины в целом• Устные интервью: для выявления конкретных проблем

• Рецензирование требований• Цель: оценка качества требований

• Проверка планов проекта• Цель: определение ошибок при планировании

аналитических работ

Аудит процесса бизнес/системного анализа• Используемые методы: • Аудит инфраструктуры проекта• Цель: определить проблемы, возникающие из-за

неправильного использования инструментария аналитика• Рецензирование регламентов процесса бизнес/системного

анализа• Цель: выявить проблемные зоны процесса

Опросники • Сконцентрированы на: • Техниках выявления требований• Методах документирования требований• Использовании шаблонов для документирования требований• Основных шагах процесса анализа (фазах выявления

требований и анализа требований) и их целях• Планировании аналитических задач• Выполнении аналитических задач

Рецензирование требований• Качество требований: • Полнота (отдельного требования и системы требований)

• точность определения scope

• точность оценки степени влияния данного требования на достижение целей

каждой из заинтересованных сторон

• возможность составления детализированного плана работ в проекте (WBS)

• возможность оценок трудоемкости работ с требуемой точностью

• возможность календарного и ресурсного планирования работ

Рецензирование требований• Качество требований: • Однозначность (ясность)

• одинаковое понимание требований всеми ролями в проектной команде

(согласованный глоссарий, модель предметной области)

• Корректность отдельного требования и согласованность (непротиворечивость)

системы требований

• точность описания поведения и характеристик системы

Рецензирование требований• Качество требований: • Необходимость

• каждое требование – шаг к достижению целей заинтересованных сторон

• каждое требование имеет свой источник (решаемая проблема)

• Осуществимость

• результат проверки возможности реализации в условиях существующих

ограничений

Рецензирование требований• Качество требований: • Проверяемость

• наличие однозначных критериев проверки корректности реализации данного

требования

• наличие количественной метрики

Рецензирование требований• Процессы:

• верификация – соответствие одних создаваемых в ходе разработки и

сопровождения ПО артефактов другим, ранее созданным или используемым в

качестве исходных данных, а также соответствие этих артефактов и процессов их

разработки правилам и стандартам

• валидация – соответствие любых создаваемых или используемых в ходе

разработки и сопровождения ПО артефактов нуждам и потребностям

пользователей и заказчиков этого ПО, с учетом законов предметной области и

ограничений контекста использования ПО

Рецензирование требований• Процессы:

• Полнота

• детализация

• Однозначность (ясность)

• уточнение

• унификация (анализ глоссария)

• Корректность отдельного требования и согласованность (непротиворечивость)

системы требований

• трассировка на другие требования

Рецензирование требований• Процессы:

• Необходимость

• трассировка на требования пользователя

• Осуществимость

• трассировка на другие требования и артефакты

• постановка задач для членов проектной команды

• Проверяемость

• наличие количественной метрики (критерия достижения определенного результата)

• наличие критериев проверки сформулированного требования

Проверка планов проекта• Планирование аналитических задач: • Время на изучение предметной области• Время на сбор требований (интервьюирование пользователей,

изучение документов, …)• Время на анализ требований• Время на документирование требований• Время на создание моделей• Время на обновление требований и моделей• …• Время подумать

Проверка планов проекта• Когда планируемое и реальное время сильно различаются?• Некоторые аналитические задачи «убираются» из плана• Оценки выполняются до того момента, когда они могут быть

сделаны обоснованно• Требования очень часто меняются• Аналитики участвуют в нескольких проектах одновременно• Несколько аналитиков участвуют в одном проекте, их работы

плохо координируются• Аналитики не знакомы с предметной областью• Качество требований очень низкое

Аудит инфраструктуры проекта• Инфраструктура проекта должна включать:• Средства для документирования требований• Инструменты для совместной работы проектной команды с

требованиями• Инструменты для легкого изменения требований• Инструменты для версионирования требований

Рецензирование регламентов процесса• Что обычно упускается?• Шаблоны спецификаций требований• Цели процесса• Метрики процесса• Практики управления требованиями

Заключение• Есть ли проблемы/Выявлены ли проблемы?• Анализ собранной информации• Количественные и качественные выводы• Использование метрик• Определение причины проблемы

Численные показатели

•Метрики• Объем требований• Качество требований• Изменяемость требований• Управление требованиями• Качество аналитических работ

Метрики объема требований

• Цели:• Управлять объемом требований• Правильно распределять работы между аналитиками

•Метрики:• Число требований для проекта/продукта• Число функциональных требований и глубина их иерархии• Число вариантов использования и шагов вариантов использования

для проекта/продукта• Число нефункциональных требований и связанных с ними

сценариев

Метрики качества требований

• Цель:• Управлять качеством требований

•Метрики:• Отношение числа ошибок в требованиях к общему объему

требований (после завершения фазы анализа)• Число ошибок на одно требование (после завершения фазы

анализа)• Уровень детализации требований (оценочно, например:

низкий/средний/высокий)• Соответствие стандартам, шаблонам, … (если применимо)

Метрики качества требований

• Что считать ошибкой в требовании?• Неоднозначность, неполнота, некорректность• Двусмысленность• Отсутствие необходимости• Отсутствие возможности проверить правильность требования

(путем составления тестов)

Метрики планирования аналитических работ

• Цель:• Повысить качество управления аналитическими работами

•Метрики:• Время, планируемое на работу (по категориям)• Время, затраченное на работу (по категориям)• Точность планирования аналитических работ: (Затраченное

время – Запланированное время)/ Запланированное время

Метрики процесса• Цель:

• Управлять требованиями и их изменениями• Метрики:

• Общее число изменений в требованиях (по категориям, на каждой фазе проекта)• Число изменений в требованиях относительно их общего объема (по категориям, на

каждой фазе проекта): Общее число изменений в требованиях (по категориям, на каждой фазе проекта)/Общее число требований для проекта (по категориям, на каждой фазе проекта)

• Процесс трассировки требований (процент требований, для которых выполнены трассировки)

Метрики продукта (в отношении требований)

• Цель:• Управлять качеством продукта

•Метрики:• Число дефектов, приходящихся на каждое требование• Максимальное число дефектов, приходящихся на требование• Метрики, связанные с атрибутами качества

Пользовательские метрики

• Цели:• Управлять отношениями с пользователями• Повысить степень удовлетворенности пользователей

•Метрики:• Проблемы, связанные с использованием продукта/системы • Уровень удовлетворенности пользователей (ожидаемый и

реальный)

Заключение• Используйте техники аудита процесса анализа для определения

проблем• Используйте эти техники правильно• Используйте метрики для определения проблем в вашем

продукте/системе и делайте выводы

Спасибо

E-mail: nzhelnova@teamcit.ru

LinkedIn: Natalia Zhelnova

SlideShare: http://www.slideshare.net/nzhelnova

Facebook: https://www.facebook.com/nzhelnova