Метрики процесса бизнес-анализа

1. Опыт консалтинга: метрики
процесса бизнес-анализа
для компаний, разрабатывающих программные продукты
и системы
Наталья Желнова | Natalia Zhelnova

2. Обзор
• Цель: совершенствование процесса управления
требованиями
• Клиенты: компании, разрабатывающие заказное ПО и
собственные продукты с численностью персонала более
200 человек (в RnD)
• Методы: аудит процесса управления требованиями и
определение дальнейших шагов по совершенствованию
процесса
• Результаты: цели достигнуты

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

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

5. Аудит процесса бизнес/системного
анализа
• Используемые методы:
• Интервьюирование аналитиков (опросники и устные
интервью)
• Опросники: для определения объема проводимого аудита
и формирования and картины в целом
• Устные интервью: для выявления конкретных проблем
• Рецензирование требований
• Цель: оценка качества требований
• Проверка планов проекта
• Цель: определение ошибок при планировании
аналитических работ

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

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

8. Рецензирование требований
• Качество требований:
• Полнота (отдельного требования и системы требований)
• точность определения scope
• точность оценки степени влияния данного требования на достижение целей
каждой из заинтересованных сторон
• возможность составления детализированного плана работ в проекте (WBS)
• возможность оценок трудоемкости работ с требуемой точностью
• возможность календарного и ресурсного планирования работ

9. Рецензирование требований
• Качество требований:
• Однозначность (ясность)
• одинаковое понимание требований всеми ролями в проектной команде
(согласованный глоссарий, модель предметной области)
• Корректность отдельного требования и согласованность (непротиворечивость)
системы требований
• точность описания поведения и характеристик системы

10. Рецензирование требований
• Качество требований:
• Необходимость
• каждое требование – шаг к достижению целей заинтересованных сторон
• каждое требование имеет свой источник (решаемая проблема)
• Осуществимость
• результат проверки возможности реализации в условиях существующих
ограничений

11. Рецензирование требований
• Качество требований:
• Проверяемость
• наличие однозначных критериев проверки корректности реализации данного
требования
• наличие количественной метрики

12. Рецензирование требований
• Процессы:
• верификация – соответствие одних создаваемых в ходе разработки и
сопровождения ПО артефактов другим, ранее созданным или используемым в
качестве исходных данных, а также соответствие этих артефактов и процессов их
разработки правилам и стандартам
• валидация – соответствие любых создаваемых или используемых в ходе
разработки и сопровождения ПО артефактов нуждам и потребностям
пользователей и заказчиков этого ПО, с учетом законов предметной области и
ограничений контекста использования ПО

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

14. Рецензирование требований
• Процессы:
• Необходимость
• трассировка на требования пользователя
• Осуществимость
• трассировка на другие требования и артефакты
• постановка задач для членов проектной команды
• Проверяемость
• наличие количественной метрики (критерия достижения определенного
результата)
• наличие критериев проверки сформулированного требования

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

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

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

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

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

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

21. Метрики объема требований
• Цели:
• Управлять объемом требований
• Правильно распределять работы между аналитиками
• Метрики:
• Число требований для проекта/продукта
• Число функциональных требований и глубина их иерархии
• Число вариантов использования и шагов вариантов
использования для проекта/продукта
• Число нефункциональных требований и связанных с ними
сценариев

22. Метрики качества требований
• Цель:
• Управлять качеством требований
• Метрики:
• Отношение числа ошибок в требованиях к общему объему
требований (после завершения фазы анализа)
• Число ошибок на одно требование (после завершения фазы
анализа)
• Уровень детализации требований (оценочно, например:
низкий/средний/высокий)
• Соответствие стандартам, шаблонам, … (если применимо)

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

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

25. Метрики процесса
• Цель:
• Управлять требованиями и их изменениями
• Метрики:
• Общее число изменений в требованиях (по категориям, на каждой фазе
проекта)
• Число изменений в требованиях относительно их общего объема (по
категориям, на каждой фазе проекта): Общее число изменений в
требованиях (по категориям, на каждой фазе проекта)/Общее число
требований для проекта (по категориям, на каждой фазе проекта)
• Процесс трассировки требований (процент требований, для которых
выполнены трассировки)

26. Метрики продукта (в отношении требований)
• Цель:
• Управлять качеством продукта
• Метрики:
• Число дефектов, приходящихся на каждое требование
• Максимальное число дефектов, приходящихся на требование
• Метрики, связанные с атрибутами качества

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

28. Заключение
• Используйте техники аудита процесса анализа для определения
проблем
• Используйте эти техники правильно
• Используйте метрики для определения проблем в вашем
продукте/системе и делайте выводы

29. Спасибо
E-mail: nzhelnova@teamcit.ru
LinkedIn: Natalia Zhelnova
SlideShare: http://www.slideshare.net/nzhelnova
Facebook: https://www.facebook.com/nzhelnova