Как обзавестись аналитиками и получить от них пользу

в проекте

Наталья Желнова

Об авторе доклада• Наталья Желнова:– С 1997 года занимается сбором,

систематизацией и управлением требованиями в проектах по разработке ПО.

– 6 лет участия в консалтинговых проектах (постановка процессов разработки ПО).

– Автор нескольких курсов по управлению требованиями, управлению рисками в проектах по разработке ПО.

– Редактор сайта Software People.

Тезисы доклада

• Роль бизнес-аналитика и системного аналитика в проекте: «Зачем здесь все эти люди?»

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

• Как проверить качество артефактов, которые готовят бизнес- и системный аналитик?

• Основные процессы, в которых участвуют бизнес- и системный аналитик, и их аудит.

• Методы оценки работы бизнес- и системного аналитика.

Роль бизнес-аналитика и системного аналитика

в проекте

Что делает аналитик

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

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

Первый уровень

• Выявление заинтересованных лиц в проекте• Управление ожиданиями заинтересованных

лиц• Выявление высокоуровневых требований и

увязывание их с собранной информацией и между собой

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

Второй уровень

• Определение границ системы• Выделение подсистем и определение их

границ• Выявление низкоуровневых требований– описания алгоритмов– описания структур данных– описания компонентов ПО – описания низкоуровневых интерфейсов – описания механизмов управления ресурсами и др

• Применение стандартов (ГОСТ, IEEE 1990)

Третий уровень

• Знание существующего IT-ландшафта и умение определять перспективы его развития в контексте выполняемого проекта

• Участие в управлении рисками проекта• Управление требованиями– управление документами– управление требованиями: участие в процессе

упрпвления полным жизненным циклом требований и трассировки требований

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

и бизнес-аналитика в разных методологиях

RUP

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

изменения бизнес-процессов • Системный аналитик:

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

Iconix

• Аналитик:– выявление требований как бизнес-, так и

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

пользовательскому интерфейсу– управление требованиями

Agile

• Product Owner:– требования бизнес-области

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

Agile

• Product Owner:– требования бизнес-области

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

Разработка требований

Какую информацию собирает системный аналитик

scope:

• пользователи системы, их роли и число

• функции системы

• системы, с которыми предполагается интеграция

• ограничения

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

quality:

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

• приоритеты требований

Разработка требований

Какие артефакты при этом создаются

• профиль ЗЛ

• потребности ЗЛ

• требования (User Story, Use Case, перечень функций системы, НФТ)

• глоссарий

• описание реализации и архитектуры (в том числе и прототип UI)

• план тестирования

Связи между артефактамиuc Use Case Model

Use Case Model Data Flows

Object Model

Components Deployment Model

Conceptual Model

Requirements

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»«trace»

Связи между артефактамиuc Use Case Model

Use Case

System Test Case Acceptance Test Case

Bug

Change Request

Requirements

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

«trace»

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

Основные артефакты

• Vision:– требования бизнес-области

• Use Cases– Пользовательские требования

• SRS:– требования бизнес-области– системные требования– требования к пользовательскому интерфейсу– нефункциональные требования

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

Управление требованиями: трассировки

Полнота

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

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

заинтересованных сторон

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

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

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

Однозначность

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

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

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

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

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

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

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

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

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

• На этапе концептуальной проработки продукта

• scope: не все заинтересованные стороны выявлены, не все цели и

проблемы заинтересованных сторон идентифицированы

• не все ограничения выявлены

• не все участники проекта одинаково понимают цели, задачи,

перспективы, связанные с проектом

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

(решение: цели -> измеряемые показатели)

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

• На этапе разработки

• time&cost&quality: риск переделок

• time&cost: невозможность точного планирования работ

• scope: невозможность реализовать те или иные требования

• quality: низкое качество продукта (много ошибок реализации; требования,

диктуемые стандартами, не выполняются)

• технические риски (неправильный выбор или несоблюдение технологий)

• На этапе тестирования

• quality: качественное тестирование продукта невозможно (отсутствуют критерии

проверки; трудности с локализацией ошибок)

Качество требований: проверка и улучшение

• Процессы:

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

артефактов другим, ранее созданным или используемым в качестве исходных данных, а

также соответствие этих артефактов и процессов их разработки правилам и стандартам

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

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

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

• Полнота

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

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

• уточнение

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

Качество требований: проверка и улучшение

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

требований

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

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

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

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

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

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

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

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

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

Управление требованиями: метрики процесса

Метрика Измеряемый параметр

Наличие артефактов процесса УТ

• Артефакты проектного управления

• Источники технических требований

• Технические требования к системе

• Источники изменения требований

• Перечень артефактов проектного управления, участвующих в УТ

• Перечень источников технических требований в проектах (маппинг на трассировки)

• Виды технических требований

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

• Перечень источников изменения требований (маппинг на трассировки)

Актуальность артефактов УТ

• Поддержка версионности артефактов

• Своевременность актуализации артефактов

• Использование артефактов УТ в реальной деятельности

• Находится ли артефакт под версионным контролем (да/нет)

• Своевременность обновления артефактов и соответствие представленных данных реальному состоянию

• Оценка использования артефактов УТ в реальной деятельности (экспертная оценка)

Метрика Измеряемый параметр

Участие системного аналитика в подготовке и согласовании артефактов УТ

• Артефакты УТ, в создании которых системный аналитик принимает участие

• Роли, с которыми взаимодействует системный аналитик

• Артефакты проекта, в создании и актуализации которых принимает участие системный аналитик

• Перечень артефактов, в создании которых участвует системный аналитик

• Перечень ролей, с которыми взаимодействует системный аналитик

• Перечень артефактов проекта, в создании и актуализации которых принимает участие системный аналитик

Связь артефактов УТ с другими артефактами проекта

• Поддержка трассировок между техническими требованиями и другими артефактами проекта

• Поддержка трассировок между техническими требованиями в различных проектах

• Наличие и поддержка трассировок (да/нет)

• Своевременность актуализации трассировок

• Наличие и поддержка трассировок (да/нет)

• Своевременность актуализации трассировок

Управление требованиями: метрики процесса

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

Разработка требований

Проверка качества

• Рецензирование коллегой

• Рецензирование командой

• Оценка «360»

Спасибо

Наталья Желноваnzhelnova@teamcit.ruhttp://www.linkedin.com/in/nzhelnova