1. Как дорасти до аналитика
Наталья Желнова

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

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

4. Аналитик. Кто это?

5. Аналитик.
Кто это?
• Три уровня навыков системных
аналитиков
• Обязательные и необязательные
навыки

6. Аналитик
Рост уровня компетенций

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

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

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

10. Роли, которые играет аналитик в
проекте по разработке ПО и
внедрению ПО

11. Роли аналитика
• Добытчик информации из внешних источников
– от клиентов
– из маркетинговых исследований
– изучая опыт, накопленный в данной отрасли
• Поставщик информации внешним источникам
– клиентам
• Правая рука менеджера проекта
– участвует в управлении рисками
– участвует в управлении требованиями
• Информационный центр и хранилище информации
– структурированной
– полезной, нужной
– актуальной
• «Интегратор» в команде: объединяет все проектные роли в единое целое
– архитектор
– разработчик
– тестировщик
– проектировщик UI

12. Функции аналитика
• Сбор и анализ требований
– выявление требований
– анализ требований
– документирование требований
• Управление требованиями
– актуализация требований
– выявление изменений в требованиях
– участие в анализе влияния изменений на другие области
проекта
– изменение требований и документирование изменений
• Управление изменениями в проекте
– актуализация изменений
– информирование об изменениях

13. Функции аналитика
• Сбор и анализ требований
– выявление требований
– анализ требований
– документирование требований
• Управление требованиями
– актуализация требований
– выявление изменений в требованиях
– участие в анализе влияния изменений на другие области
проекта
– изменение требований и документирование изменений
• Управление изменениями в проекте
– актуализация изменений
– информирование об изменениях

14. Требования, которые
предъявляются к системному
аналитику
«Табель о рангах» аналитиков

15. «Табель о рангах» аналитиков
• Младший аналитик
• Аналитик
• Старший аналитик / ведущий аналитик
• Руководитель отдела

16. Требования, предъявляемые к
аналитику
• Младший аналитик
• Аналитик
• Старший аналитик
Использованные материалы: В. Иванова, А. Перерва
«Путь аналитика»

17. Младший аналитик
• Выявлять ЗЛ (заинтересованные лица)
• Управлять ожиданиями ЗЛ
• Проводить собрания
• Проводить интервьюирование
• Проводить мозговые штурмы
• Уметь определять границы системы
• Уметь выделять подсистемы и определять их границы

18. Младший аналитик
• Уметь собирать и обрабатывать информацию:
– запросы заинтересованных лиц
– глоссарий (согласовыванные с ЗЛ термины)
– характеристики аналогичных / наследуемых систем
• Учитывать требования стандартов при анализе
• Уметь выявлять высокоуровневые требования и
увязывать их с собранной информацией и между
собой:
– бизнес-требования
– бизнес-правила
– ограничения и допущения
– пользовательские требования
– функциональные требования

19. Младший аналитик
• Проводить основную аналитическую работу
по созданию и проектированию системы:
– Уметь проектировать поведение системы и
описывать его через требуемые функции системы /
варианты использования / прецеденты (use cases)
• Выявлять нефункциональные требования
– Требования к пользовательскому интерфейсу
– Требования к взаимодействию с внешними системами
• Понимать основные принципы тестирования
• Знать английский язык

20. Аналитик
+ к навыкам младшего аналитика:
• Иметь представление об управлении требованиями
– Знать, что такое План управления требованиями и уметь его
разрабатывать
• Понимать, какие модели существуют, и где их место в
разработке ПО
– Иметь навыки работы с CASE-средствами и UML-редакторами
• Уметь читать программный код
• Иметь навыки проведения презентаций

21. Старший аналитик
+ к навыкам аналитика:
• Иметь детальное представление о ЖЦ (жизненном
цикле) проекта и продукта
– Знать, что такое План управления требованиями и уметь его
разрабатывать
• Иметь детальное представление об управлении
докумнетами
– Знать, что такое План управления документами и уметь его
создавать
• Уметь писать программный код
• Проводить выученные уроки по практикам
разработки и управления требованиями

22. Старший аналитик
+ к навыкам аналитика:
• Быть наставником для аналитиков
• Уметь предотвращать и разрешать конфликты в
проектной команде
• Уметь выявлять риски и управлять ими

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

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

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

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

27. Процессы и метрики

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

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

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

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

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

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

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

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

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

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

38. Кто может стать аналитиком

39. Программст -> аналитик
• Плюсы
– Технические навыки и экспертиза
– Знание и глубокое понимание процессов разработки
– Реалистичная оценка сроков и сложности разработки
– Управление рисками
– Связка «аналитик-архитектор»
• Минусы
– Отсутствие высоких навыков коммуникации
– Отсутствие опыта общения с заказчиками
– Не видит леса за деревьями
– Не любит писать
– Не любит говорить

40. Тестировщик -> аналитик
• Плюсы
– Технические навыки и экспертиза
– Знание процессов разработки
– Связка «аналитик-тестировщик»
– Помощь команде внедрения
• Минусы
– Отсутствие опыта общения с заказчиками
– Отсутствие глубокой технической экспертизы
– Нужно дополнительное обучение

41. Технический писатель -> аналитик
• Плюсы
– Развитые навыки коммуникации
– Развитые навыки составления документов
• Минусы
– Отсутствие опыта общения с заказчиками
– Отсутствие навыков планирования и управления требованиями и
изменениями
– Отсутствие глубокой технической экспертизы
– Нужно дополнительное обучение

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