Борис Вольфсон: Гибкое управление проектами и продуктами

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

• UML-диаграммы – это не конечный продукт, пользователям он не принесет ценность;

• UML-диаграммы быстро теряют актуальность при начале разработки;

• UML очень объемен (более десяти видов диаграмм, 900-страничное официальное руководство) и избыточен, так как часть диаграмм фактически дублируют друг друга;

• UML описывает систему слишком подробно, часть знаний можно хранить и передавать в устном виде либо в форме текста;

• UML неявно подразумевает водопадную модель разработки.

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

Одним из вариантов гибкого анализа требований (и частично моделирования) является использование и адаптация процесса ICONIX.

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

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

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

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

ICONIX – подмножество UML

Структура процесса ICONIX

Диаграмма вариантов использования

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

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

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

Диаграмма предметной области

Диаграмма классов

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

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

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

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

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

Диаграмма робастности

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

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

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

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

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

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