В сети вы можете найти множество статей на тему “UML мертв”, “Почему системным аналитикам не нужен UML” и множество подобного. Работая на протяжении последних 15 лет в совершенно разных компаниях, с совершенно разным жизненным циклом приложений и систем, с различной структурой и методологиями разработки я вижу одно и тоже — попытки ускорения time-to-market за счет отказа от процесса управления требованиями, подаваемые под разными прекрасными аргументами, приводят 100% компаний к необходимости переписывать приложения не потому, что оно не отвечает требованиям, а потому что “никто не знает как или почему оно так работает”.

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

Можно перечислить еще огромное количество проблем, к которым приводит разработка без модели требований, например:

1. Невозможность понять, как работает/работала система в той или иной версии.

2. Невозможность нормально тестировать, опираясь на конкретные номерные требования.

3. Невозможность привязывать дефекты к конкретным требованиям.

4. Невозможность понятно и прозрачно понять на какие требования и процессы внутри системы влияют новые изменения.

5. Невозможность прозрачно и понятно посмотреть timeline изменений требований.

И тем не менее, раз за разом, этап системного анализа пытаются пропустить или пустить в параллель, почему же? 

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

Вместо холивара

Я в целом согласен с подходом прогрессивного jpeg, но вот мое отношение к попыткам отказаться от выделенного этапа анализа описывается началом первой главы рассказа «Винни Пух» Алана Милна:

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

Для того чтобы все же иметь нормальную модель требований нужно определиться с языком описания этих требований, которому не нужно будет обучать всех членов команды, а также представителей бизнес-заказчиков. И тут для многих выбор UML не очевиден, и очень часто специалисты придумывают довольно странных и страшных франкенштейнов из EPC, отдельных UML-диаграмм, схем БД, IDEF, Mind Map и черте чего еще, хотя, как показывает мой опыт, разработанный мной в 2011-2012-х годах подход лаконичного использования UML без изысков и выкрутасов позволяет получить очень простую и понятную модель требований, в том числе позволяющую генерировать ТЗ одной кнопкой. 

Меня зовут Александр Головков и именно этим подходом я и хочу с вами поделиться.

В чем суть и профит подхода

1. Использование централизованной модели требований с общим доступом к ней для всех членов позволяет переиспользовать элементы модели.

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

3. Следование определенному набору формальных требований к качеству модели требований позволяет повысить качество требований и сократить затраты на разработку требований за счет возможности у аналитика провести self-check, не отдавая недостаточно проработанные требования другим членам команды.

4. Обязательное review требований внутри команды аналитиков и продуктовых команд позволяет повысить качество требований и технических заданий.

5. Использование инструментов автогенерации технического задания из модели требований позволяет значительным образом сократить время на разработку технических заданий.

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

7. Использование ограниченного набора UML диаграмм позволяет всесторонне описывать требования и алгоритмы, и не требует глубокого знания UML от системных аналитиков и других членов команды, а также от заказчика.

Из минусов подхода можно выделить два:

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

2. Подход довольно сильно завязан на конкретные инструменты и его перекладывание на другие может быть довольно сложным.

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

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

Системный аналитик создает snapshot требований, чтобы иметь возможность отслеживать свои изменения (на самом деле этот шаг избыточен, если подход соблюдается и требования не правятся вне процессов, определяемых данным подходом) и разрабатывает модель требований, пользуясь ограниченным небольшим набором элементов и диаграмм, чтение которых не требует понимания специфических нюансов UML и знаний чем, например, заштрихованная стрелочка отличается от незаштрихованной. Требование к набору диаграмм и элементов, ограничивающее сложность получаемых ТЗ является первым из пяти основных требований подхода.

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

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

После получения замечаний, системный аналитик обрабатывает их, внося изменения в модель требований. Критически важно, чтобы на этом этапе, после разработки подхода к устранению замечаний, системные аналитики согласовали свой подход с ревьюерами, чтобы ограничить количество итераций исправлений до 1. Это требование является третьим из пяти краеугольных требований подхода, и его выполнение позволяет мотивировать аналитика на тестирование модели требований, которую он собирается передать команде и заказчику и не позволяет ему переложить это тестирование на плечи других участников.

Последние два (четвертое и пятое) из пяти критических требований подхода это:

1. Перед каждым ветвлением на activity диаграмме должен быть action с проверкой, к которому обязательно привязано требование или требования, определяющие как эта проверка должна осуществляться.

2. Модель требований и ТЗ должно версионироваться, для согласованных версий модели и ТЗ должен быть проставлен соответствующий Tag с версией.

В этом цикле статей я постараюсь дать все описания, инструкции и требования. На текущий момент, подход включает в себя следующие артефакты:

1. Инструкция по настройке централизованной модели на базе Sparx Enterprise Architect + MySQL Server:

   1. Настройка БД

   2. Настройка ODBC

   3. Настройка пользователей

   4. Настройка автонумерации сущностей модели требований

   Ее вы можете найти тут.

2. Требования к модели требования – опишу в одной из следующих статей.

3. Шаблон модели требования  – опишу в одной из следующих статей.

   

4. Требования к ТЗ  – опишу в одной из следующих статей.

5. Инструкция по автогенерации ТЗ и ведению ТЗ в Confluence  – опишу в одной из следующих статей.

6. Шаблон автогенерации ТЗ  – опишу в одной из следующих статей.

   

Что нужно, чтобы настроить инструментарий и провести пилот подхода?

1. Atlassian Confluence

   Почему:

   1. Версионность ТЗ за счет использования тегов

   2. Возможность организовать review требований командой (Inline comments)

   3. Отображение изменений системы от версии к версии

   4. Связка версии модели требований к версиям системы

2. Sparx Enterprise Architect + MySQL Server – инструкция по настройке тут

   Почему:

   1. Относительно простой инструмент отрисовки моделей

   2. Горячие клавиши позволяют значительным образом увеличить скорость разработки модели требований

   3. Возможность организации централизованная модель требований

   4. Возможность создавать snapshots модели (baseline) и вести версионность требований

   5. Возможность организовать review требований командой (опционально, многим командам больше нравится проводить review в confluence)

   6. Генерация ТЗ — killer feature, позволяет сэкономить огромное количество ресурсов