Чтобы понять, зачем вводится отдельная роль системного аналитика, взглянем внимательнее на обязанности владельца продукта.
Аналитик не выступает стеной между заказчиком и командой. Аналитик – член команды, который помогает заказчику понять, чего тот хочет на самом деле.
Чтобы разгрузить владельца продукта, часть его обязанностей, а именно анализ и детальная проработка требований, отдается системному аналитику. Обращу ваше внимание, что расстановка приоритетов остается и становится главной обязанностью владельца продукта.
UML
Классическим подходом к описанию требований в виде модели является UML, который позволяет описать буквально каждый аспект системы в визуальном виде. Однако такой подход не является гибким:
• UML-диаграммы – это не конечный продукт, пользователям он не принесет ценность;
• UML-диаграммы быстро теряют актуальность при начале разработки;
• UML очень объемен (более десяти видов диаграмм, 900-страничное официальное руководство) и избыточен, так как часть диаграмм фактически дублируют друг друга;
• UML описывает систему слишком подробно, часть знаний можно хранить и передавать в устном виде либо в форме текста;
• UML неявно подразумевает водопадную модель разработки.
Если мы говорим о гибких процессах, то применение тех или иных средств визуализации системы должно основываться на здравом смысле. Ни одна диаграмма не заменит коммуникации в команде. Диаграммы подходят для описания сложных бизнес-процессов со сложной логикой поведения.
Наталья Лукьянчикова, аналитик
Процесс ICONIX
Одним из вариантов гибкого анализа требований (и частично моделирования) является использование и адаптация процесса ICONIX.
ICONIX – это методология анализа требований, основанная на прецедентах использования. В рамках этого процесса используется небольшое подмножество UML, что делает его более легковесным.
Сам процесс разработки продукта в ICONIX носит практически водопадный характер, поэтому его необходимо адаптировать для итеративной методологии, к которой относится Scrum.
Более подробно рассмотрим, какие диаграммы предлагает нам ICONIX и как будет происходить процесс анализа требований и моделирования. В качестве примера возьмем небольшое приложение по расчету кредита на сайте.
На первом этапе происходит анализ вариантов использования, который является своеобразным аналогом построения карт историй.
ICONIX – подмножество UML
Структура процесса ICONIX
Диаграмма вариантов использования
Здесь отображаются роли пользователей (персоны из карт историй) и варианты применения, которые фактически являются более тяжеловесным вариантом историй пользователей. Обратите внимание на стереотипы «Эпик» и «Тема», которыми обозначены два варианта использования.
Теперь можно провести анализ предметной области, хотя он часто выполняется параллельно. Для этого можно начать с соответствующей диаграммы, на которой мы обозначим основные элементы нашего домена с полями и наметим связи между ними.
Затем можно продолжить анализ и добавить вспомогательные и абстрактные классы, которые могут напрямую не относиться к предметной области. Таким образом, мы получим набросок архитектуры нашего приложения в виде диаграммы классов.
Диаграмма предметной области
Диаграмма классов
Для примера разберем один из вариантов использования и опишем его более подробно в виде диаграммы робастности, на которой будут отражены:
