Gibkie-metodologii

10.Анализ требований

Scrum предоставляет гибкое и легковесное решение для управления требованиями, но зачастую есть проекты, для которых это решение приходиться расширять. Самым ярким примером здесь могут послужить проекты со сложной бизнес-логикой, которую необходимо сначала формализовать, чтобы реализовать функциональность, которую она описывает. Обычно описания такого рода хранятся в трекере либо в вики, а анализ требований ведет выделенный специалист – системный аналитик.

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

Чтобы понять, зачем вводится отдельная роль системного аналитика, давайте взглянем внимательнее на обязанности владельца продукта:

71

Процесс ICONIX

Одним из вариантов гибкого анализа требований (и частично моделирования) является использование и адаптация процесса ICONIX, который подробно описан в (Rosenberg, и др., 2005) и в (Rosenberg, et al., 2007). ICONIX – это методология анализа требований, основанная на прецедентах использования. В рамках этого процесса используется небольшое подмножество UML, что делает его более легковесным:

Рисунок 34. ICONIX - подмножество UML

Сам процесс разработки продукта в ICONIX носит практически водопадный характер, поэтому его необходимо адаптировать для итеративной методологии, к которой

относиться Scrum:

73

Рисунок 35. Структура процесса ICONIX

Давайте более подробно посмотрим, какие диаграммы предлагает нам ICONIX, и как будет происходить процесс анализа требований и моделирования. В качестве примера рассмотрим небольшое приложение по расчету кредита на веб-сайте.

На первом этапе происходит анализ вариантов использования, который является своеобразным аналогом сторимаппинга:

На ней отображаются роли пользователей (персоны из сторимаппинга) и варианты использования, которые фактически являются более тяжеловесным вариантом историй пользователей. Обратите внимание на стереотипы «Эпик» и «Тема», которыми обозначены два варианта использования.

Теперь можно провести анализ предметной области, хотя он часто проводиться параллельно. Для этого можно начать с соответствующей диаграммы, на которой мы

75

обозначим основные элементы нашего домена с полями и наметим связи между ними:

Затем можно продолжить анализ и добавить вспомогательные и абстрактные классы, которые могут напрямую не относиться к предметной области. Таким образом, мы получим набросок архитектуры нашего приложения в виде диаграммы классов:

Для примера разберем один из вариантов использования и опишем его более подробно в виде диаграммы робастности, на которой будут отражены:

граничные объекты – интерфейс взаимодействия с пользователями;

котроллеры – бизнес-логика и различные алгоритмы;

сущности – данные приложения.

Можно заметить, что данная диаграмма очень похожа на шаблон проектирования Model- View-Controller:

Красным выделены альтернативные (ошибочные) цепочки действий, про которые обычно забывают при анализе, хотя им нужно уделить максимальное внимание.

Диаграмма робастности нужна, чтобы:

осуществить проверку полноты вариантов использования;

выявить дополнительные объекты;

проработать архитектуру на высоком уровне.

Последний пункт очень важен, ведь между анализом и архитектурой существует практически пропасть, которую эта диаграмма призвана заполнить:

77

После такого анализа можно описать подробности алгоритма или логики в диаграмме последовательности:

Стратегия актуализации документации

Если рассматривать проектную документацию, в том числе требования, с позиций бережливого производства, то она является «мудой» – потерей при производстве (подробнее потери при производстве описаны в главе «Бережливое производство»). Аналогичный принцип действует и в гибких методологиях: прогресс измеряется не по документации, а по конечному продукту, который приносит ценность для заказчика.

Фактически аналитик должен выбрать одну из трех стратегий актуализации требований: