Доклад Натальи Желновой рассматривает роль бизнес- и системных аналитиков в проектах разработки ПО, акцентируя внимание на различиях в их обязанностях и методах работы в разных методологиях. Она обсуждает ключевые навыки аналитиков, процессы их участия в проектах, а также методы оценки качества артефактов. Также затрагиваются риски и метрики, связанные с управлением требованиями и обеспечением качества документации в процессе разработки.

1. Как обзавестись аналитиками
и получить от них пользу
в проекте
Наталья Желнова

2. Об авторе доклада
• Наталья Желнова:
– С 1997 года занимается сбором,
систематизацией и управлением требованиями
в проектах по разработке ПО.
– 6 лет участия в консалтинговых проектах
(постановка процессов разработки ПО).
– Автор нескольких курсов по управлению
требованиями, управлению рисками в
проектах по разработке ПО.
– Редактор сайта Software People.

3. Тезисы доклада
• Роль бизнес-аналитика и системного аналитика
в проекте: «Зачем здесь все эти люди?»
• Различие границ ответственности проектных
ролей для системного и бизнес-аналитика
в разных методологиях.
• Как проверить качество артефактов, которые
готовят бизнес- и системный аналитик?
• Основные процессы, в которых участвуют
бизнес- и системный аналитик, и их аудит.
• Методы оценки работы бизнес- и системного
аналитика.

4. Роль бизнес-аналитика
и системного аналитика в проекте

5. Что делает аналитик
• Три уровня навыков системных
аналитиков: первый, второй,
третий
• Обязательные и необязательные
навыки
• С какими ролями взаимодуйствует

6. Первый уровень
• Выявление заинтересованных лиц в проекте
• Управление ожиданиями заинтересованных
лиц
• Выявление высокоуровневых требований и
увязывание их с собранной информацией и
между собой
• Участие в проектировании системы:
– описание поведения системы
– выявление нефункциональных требований

7. Второй уровень
• Определение границ системы
• Выделение подсистем и определение их
границ
• Выявление низкоуровневых требований
– описания алгоритмов
– описания структур данных
– описания компонентов ПО
– описания низкоуровневых интерфейсов
– описания механизмов управления ресурсами и др
• Применение стандартов (ГОСТ, IEEE 1990)

8. Третий уровень
• Знание существующего IT-ландшафта и
умение определять перспективы его
развития в контексте выполняемого
проекта
• Участие в управлении рисками проекта
• Управление требованиями
– управление документами
– управление требованиями: участие в процессе
упрпвления полным жизненным циклом
требований и трассировки требований

9. Различие границ ответственности
проектных ролей для системного
и бизнес-аналитика в разных
методологиях

10. RUP
• Бизнес-аналитик:
– описание бизнес-процессов
– изменение бизнес-процессов
– верхнеуровневые и функциональные требования к
системе
– управление изменениями, источниками которых
являются изменения бизнес-процессов
• Системный аналитик:
– функциональные и нефункциональные требования
– низкоуровневые требования
– изменения в IT-системах
– управление требованиями
– создание моделей для проектирования

11. Iconix
• Аналитик:
– выявление требований как бизнес-, так и
пользовательского уровня
– моделирование предметной области
– составление глоссария
– составление модели прецедентов
– сбор и систематизация требований к
пользовательскому интерфейсу
– управление требованиями

12. Agile
• Product Owner:
– требования бизнес-области
• «Аналитик»:
– системные требования
– требования к пользовательскому интерфейсу

13. Agile
• Product Owner:
– требования бизнес-области
• «Аналитик»:
– системные требования
– требования к пользовательскому интерфейсу

14. Разработка требований
Какую информацию собирает системный аналитик
scope: quality:
• пользователи системы, их роли и • требования к качеству продукта
число (производительность, масштабируемость,
• функции системы надежность, доступность, безопасность,
• системы, с которыми отказоустойчивость, алгоритмическая
предполагается интеграция сложность; системные требования:
• ограничения потребляемые ресурсы и требования к
• регламенты и стандарты, взаимодействию с внешним окружением;
влияющие на разработку требования к платформе; usability, etc.)
• приоритеты требований

15. Разработка требований
Какие артефакты при этом создаются
• профиль ЗЛ
• потребности ЗЛ
• требования (User Story, Use Case, перечень функций системы, НФТ)
• глоссарий
• описание реализации и архитектуры (в том числе и прототип UI)
• план тестирования

16. Связи между артефактами
uc Use Case Model
Requirements
«trace» «trace»
Use Case Model Data Flow s
Conceptual Model «trace»
«trace»
«trace» «trace» «trace»
Obj ect Model
«trace»
Components Deployment Model
«trace»

17. Связи между артефактами
uc Use Case Model
Requirements
«trace» «trace»
Use Case
Change Request
«trace»
«trace» «trace»
System Test Case Acceptance Test
Case
«trace»
«trace» «trace»
Bug

18. Качество артефактов

19. Основные артефакты
• Vision:
– требования бизнес-области
• Use Cases
– Пользовательские требования
• SRS:
– требования бизнес-области
– системные требования
– требования к пользовательскому интерфейсу
– нефункциональные требования

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

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

22. Качество требований: риски
• На этапе разработки
• time&cost&quality: риск переделок
• time&cost: невозможность точного планирования работ
• scope: невозможность реализовать те или иные требования
• quality: низкое качество продукта (много ошибок реализации; требования,
диктуемые стандартами, не выполняются)
• технические риски (неправильный выбор или несоблюдение технологий)
• На этапе тестирования
• quality: качественное тестирование продукта невозможно (отсутствуют критерии
проверки; трудности с локализацией ошибок)

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

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

25. Управление требованиями:
метрики процесса
Метрика Измеряемый параметр
Наличие артефактов процесса УТ
• Артефакты проектного управления • Перечень артефактов проектного управления, участвующих в УТ
• Источники технических требований • Перечень источников технических требований в проектах (маппинг на
трассировки)
• Технические требования к системе • Виды технических требований
• Форматы представления технических требований
• Источники изменения требований • Перечень источников изменения требований (маппинг на трассировки)
Актуальность артефактов УТ
• Поддержка версионности артефактов • Находится ли артефакт под версионным контролем (да/нет)
• Своевременность актуализации • Своевременность обновления артефактов и соответствие представленных
артефактов данных реальному состоянию
• Использование артефактов УТ в • Оценка использования артефактов УТ в реальной деятельности (экспертная
реальной деятельности оценка)

26. Управление требованиями:
метрики процесса
Метрика Измеряемый параметр
Участие системного аналитика в подготовке и согласовании артефактов УТ
• Артефакты УТ, в создании которых • Перечень артефактов, в создании которых участвует системный аналитик
системный аналитик принимает участие
• Роли, с которыми взаимодействует • Перечень ролей, с которыми взаимодействует системный аналитик
системный аналитик
• Артефакты проекта, в создании и • Перечень артефактов проекта, в создании и актуализации которых принимает
актуализации которых принимает участие системный аналитик
участие системный аналитик
Связь артефактов УТ с другими артефактами проекта
• Поддержка трассировок между • Наличие и поддержка трассировок (да/нет)
техническими требованиями и другими • Своевременность актуализации трассировок
артефактами проекта
• Поддержка трассировок между • Наличие и поддержка трассировок (да/нет)
техническими требованиями в • Своевременность актуализации трассировок
различных проектах

27. Качество работы аналитика

28. Разработка требований
Проверка качества
• Рецензирование коллегой
• Рецензирование командой
• Оценка «360»

29. Спасибо
Наталья Желнова
nzhelnova@teamcit.ru
http://www.linkedin.com/in/nzhelnova