Embed Size (px)
Citation preview
Как дорасти до аналитика
Наталья Желнова
Об авторе доклада• Наталья Желнова:– С 1997 года занимается сбором,
систематизацией и управлением требованиями в проектах по разработке ПО.
– 6 лет участия в консалтинговых проектах (постановка процессов разработки ПО).
– Автор нескольких курсов по управлению требованиями, управлению рисками в проектах по разработке ПО.
– Редактор сайта Software People.
Тезисы доклада• Аналитик: кто это?• Роли, которые играет аналитик в проекте по разработке ПО и
внедрению ПО• Аналитик и процесс разработки• Аналитик и команда разработки: кто кого?• Требования, которые предъявляются к системному аналитику• «Табель о рангах» аналитиков• Кто может стать аналитиком (умная девочка с техническим
образованием? бывший разработчик? варианты професиий на "входе" и особенности каждой)
• Можно ли научить людей быть аналитиками и как это сделать
Аналитик. Кто это?
Аналитик.Кто это?
• Три уровня навыков системных аналитиков• Обязательные и необязательные
навыки
Аналитик
Рост уровня компетенций
Первый уровень
• Выявление заинтересованных лиц в проекте• Управление ожиданиями заинтересованных
лиц• Выявление высокоуровневых требований и
увязывание их с собранной информацией и между собой
• Участие в проектировании системы:– описание поведения системы– выявление нефункциональных требований
Второй уровень
• Определение границ системы• Выделение подсистем и определение их
границ• Выявление низкоуровневых требований– описания алгоритмов– описания структур данных– описания компонентов ПО – описания низкоуровневых интерфейсов – описания механизмов управления ресурсами и др
• Применение стандартов (ГОСТ, IEEE 1990)
Третий уровень
• Знание существующего IT-ландшафта и умение определять перспективы его развития в контексте выполняемого проекта
• Участие в управлении рисками проекта• Управление требованиями– управление документами– управление требованиями:
• участие в процессе упрпвления полным жизненным циклом требований
• трассировки требований
Роли, которые играет аналитик в проекте по разработке ПО и
внедрению ПО
Роли аналитика • Добытчик информации из внешних источников
– от клиентов– из маркетинговых исследований– изучая опыт, накопленный в данной отрасли
• Поставщик информации внешним источникам– клиентам
• Правая рука менеджера проекта– участвует в управлении рисками– участвует в управлении требованиями
• Информационный центр и хранилище информации– структурированной– полезной, нужной– актуальной
• «Интегратор» в команде: объединяет все проектные роли в единое целое– архитектор– разработчик– тестировщик– проектировщик UI
Функции аналитика
• Сбор и анализ требований– выявление требований– анализ требований– документирование требований
• Управление требованиями– актуализация требований– выявление изменений в требованиях– участие в анализе влияния изменений на другие области
проекта– изменение требований и документирование изменений
• Управление изменениями в проекте– актуализация изменений– информирование об изменениях
Функции аналитика
• Сбор и анализ требований– выявление требований– анализ требований– документирование требований
• Управление требованиями– актуализация требований– выявление изменений в требованиях– участие в анализе влияния изменений на другие области
проекта– изменение требований и документирование изменений
• Управление изменениями в проекте– актуализация изменений– информирование об изменениях
Требования, которые предъявляются к системному аналитику
«Табель о рангах» аналитиков
«Табель о рангах» аналитиков
• Младший аналитик• Аналитик• Старший аналитик / ведущий аналитик• Руководитель отдела
Требования, предъявляемые к аналитику
• Младший аналитик• Аналитик• Старший аналитик
Использованные материалы: В. Иванова, А. Перерва «Путь аналитика»
Младший аналитик
• Выявлять ЗЛ (заинтересованные лица)• Управлять ожиданиями ЗЛ• Проводить собрания• Проводить интервьюирование• Проводить мозговые штурмы• Уметь определять границы системы• Уметь выделять подсистемы и определять их границы
Младший аналитик
• Уметь собирать и обрабатывать информацию:– запросы заинтересованных лиц– глоссарий (согласовыванные с ЗЛ термины)– характеристики аналогичных / наследуемых систем
• Учитывать требования стандартов при анализе• Уметь выявлять высокоуровневые требования и
увязывать их с собранной информацией и между собой:– бизнес-требования– бизнес-правила– ограничения и допущения– пользовательские требования– функциональные требования
Младший аналитик
• Проводить основную аналитическую работу по созданию и проектированию системы:– Уметь проектировать поведение системы и
описывать его через требуемые функции системы / варианты использования / прецеденты (use cases)
• Выявлять нефункциональные требования– Требования к пользовательскому интерфейсу– Требования к взаимодействию с внешними системами
• Понимать основные принципы тестирования• Знать английский язык
Аналитик
+ к навыкам младшего аналитика:• Иметь представление об управлении требованиями
– Знать, что такое План управления требованиями и уметь его разрабатывать
• Понимать, какие модели существуют, и где их место в разработке ПО– Иметь навыки работы с CASE-средствами и UML-
редакторами
• Уметь читать программный код • Иметь навыки проведения презентаций
Старший аналитик
+ к навыкам аналитика:• Иметь детальное представление о ЖЦ (жизненном цикле)
проекта и продукта– Знать, что такое План управления требованиями и уметь его
разрабатывать
• Иметь детальное представление об управлении докумнетами– Знать, что такое План управления документами и уметь его
создавать
• Уметь писать программный код • Проводить выученные уроки по практикам разработки и
управления требованиями
Старший аналитик
+ к навыкам аналитика:• Быть наставником для аналитиков• Уметь предотвращать и разрешать конфликты в
проектной команде• Уметь выявлять риски и управлять ими
Аналитик и процесс разработки
Различие границ ответственности проектных ролей для системного и бизнес-аналитика
в разных методологиях
RUP
• Бизнес-аналитик: – описание бизнес-процессов– изменение бизнес-процессов– верхнеуровневые и функциональные требования к системе– управление изменениями, источниками которых являются
изменения бизнес-процессов • Системный аналитик:
– функциональные и нефункциональные требования– низкоуровневые требования– изменения в IT-системах– управление требованиями– создание моделей для проектирования
Iconix
• Аналитик:– выявление требований как бизнес-, так и
пользовательского уровня– моделирование предметной области– составление глоссария– составление модели прецедентов– сбор и систематизация требований к
пользовательскому интерфейсу– управление требованиями
Agile
• Product Owner:– требования бизнес-области
• «Аналитик»:– системные требования– требования к пользовательскому интерфейсу
Процессы и метрики
Разработка требований
Какую информацию собирает системный аналитик
scope:
• пользователи системы, их роли и число
• функции системы
• системы, с которыми предполагается интеграция
• ограничения
• регламенты и стандарты, влияющие на разработку
quality:
• требования к качеству продукта (производительность, масштабируемость, надежность, доступность, безопасность, отказоустойчивость, алгоритмическая сложность; системные требования: потребляемые ресурсы и требования к взаимодействию с внешним окружением; требования к платформе; usability, etc.)
• приоритеты требований
Разработка требований
Какие артефакты при этом создаются
• профиль ЗЛ
• потребности ЗЛ
• требования (User Story, Use Case, перечень функций системы, НФТ)
• глоссарий
• описание реализации и архитектуры (в том числе и прототип UI)
• план тестирования
Основные артефакты
• Vision:– требования бизнес-области
• Use Cases– Пользовательские требования
• SRS:– требования бизнес-области– системные требования– требования к пользовательскому интерфейсу– нефункциональные требования
Качество требований
Управление требованиями: трассировки
Полнота
• точность определения scope
• точность оценки степени влияния данного требования на достижение целей каждой из
заинтересованных сторон
• возможность составления детализированного плана работ в проекте (WBS)
• возможность оценок трудоемкости работ с требуемой точностью
• возможность календарного и ресурсного планирования работ
Однозначность
• одинаковое понимание требований всеми ролями в проектной команде
Необходимость
• каждое требование – шаг к достижению целей заинтересованных сторон
• каждое требование имеет свой источник (решаемая проблема)
Осуществимость
• результат проверки возможности реализации в условиях существующих ограничений
Проверяемость
• наличие однозначных критериев проверки корректности реализации данного требования
Качество требований: риски
• На этапе концептуальной проработки продукта
• scope: не все заинтересованные стороны выявлены, не все цели и
проблемы заинтересованных сторон идентифицированы
• не все ограничения выявлены
• не все участники проекта одинаково понимают цели, задачи,
перспективы, связанные с проектом
• существуют конфликты между целями заинтересованных сторон
(решение: цели -> измеряемые показатели)
Качество требований: риски
• На этапе разработки
• time&cost&quality: риск переделок
• time&cost: невозможность точного планирования работ
• scope: невозможность реализовать те или иные требования
• quality: низкое качество продукта (много ошибок реализации; требования,
диктуемые стандартами, не выполняются)
• технические риски (неправильный выбор или несоблюдение технологий)
• На этапе тестирования
• quality: качественное тестирование продукта невозможно (отсутствуют критерии
проверки; трудности с локализацией ошибок)
Качество требований: проверка и улучшение
• Процессы:
• верификация – соответствие одних создаваемых в ходе разработки и сопровождения ПО
артефактов другим, ранее созданным или используемым в качестве исходных данных, а
также соответствие этих артефактов и процессов их разработки правилам и стандартам
• валидация – соответствие любых создаваемых или используемых в ходе разработки и
сопровождения ПО артефактов нуждам и потребностям пользователей и заказчиков этого
ПО, с учетом законов предметной области и ограничений контекста использования ПО
• Полнота
• детализация
• Однозначность (ясность)
• уточнение
• унификация (анализ глоссария)
Качество требований: проверка и улучшение
• Корректность отдельного требования и согласованность (непротиворечивость) системы
требований
• трассировка на другие требования
• Необходимость
• трассировка на потребности пользователя
• Осуществимость
• трассировка на другие требования и артефакты
• постановка задач для членов проектной команды
• Проверяемость
• наличие количественной метрики (критерия достижения определенного результата)
• наличие критериев проверки сформулированного требования
Управление требованиями: метрики процесса
Метрика Измеряемый параметр
Наличие артефактов процесса УТ
• Артефакты проектного управления
• Источники технических требований
• Технические требования к системе
• Источники изменения требований
• Перечень артефактов проектного управления, участвующих в УТ
• Перечень источников технических требований в проектах (маппинг на трассировки)
• Виды технических требований
• Форматы представления технических требований
• Перечень источников изменения требований (маппинг на трассировки)
Актуальность артефактов УТ
• Поддержка версионности артефактов
• Своевременность актуализации артефактов
• Использование артефактов УТ в реальной деятельности
• Находится ли артефакт под версионным контролем (да/нет)
• Своевременность обновления артефактов и соответствие представленных данных реальному состоянию
• Оценка использования артефактов УТ в реальной деятельности (экспертная оценка)
Метрика Измеряемый параметр
Участие системного аналитика в подготовке и согласовании артефактов УТ
• Артефакты УТ, в создании которых системный аналитик принимает участие
• Роли, с которыми взаимодействует системный аналитик
• Артефакты проекта, в создании и актуализации которых принимает участие системный аналитик
• Перечень артефактов, в создании которых участвует системный аналитик
• Перечень ролей, с которыми взаимодействует системный аналитик
• Перечень артефактов проекта, в создании и актуализации которых принимает участие системный аналитик
Связь артефактов УТ с другими артефактами проекта
• Поддержка трассировок между техническими требованиями и другими артефактами проекта
• Поддержка трассировок между техническими требованиями в различных проектах
• Наличие и поддержка трассировок (да/нет)
• Своевременность актуализации трассировок
• Наличие и поддержка трассировок (да/нет)
• Своевременность актуализации трассировок
Управление требованиями: метрики процесса
Кто может стать аналитиком
Программст -> аналитик
• Плюсы– Технические навыки и экспертиза– Знание и глубокое понимание процессов разработки– Реалистичная оценка сроков и сложности разработки– Управление рисками– Связка «аналитик-архитектор»
• Минусы– Отсутствие высоких навыков коммуникации– Отсутствие опыта общения с заказчиками– Не видит леса за деревьями– Не любит писать– Не любит говорить
Тестировщик -> аналитик
• Плюсы– Технические навыки и экспертиза– Знание процессов разработки– Связка «аналитик-тестировщик»– Помощь команде внедрения
• Минусы– Отсутствие опыта общения с заказчиками– Отсутствие глубокой технической экспертизы– Нужно дополнительное обучение
Технический писатель -> аналитик
• Плюсы– Развитые навыки коммуникации– Развитые навыки составления документов
• Минусы– Отсутствие опыта общения с заказчиками– Отсутствие навыков планирования и управления требованиями и
изменениями– Отсутствие глубокой технической экспертизы– Нужно дополнительное обучение
