В сети вы можете найти множество статей на тему “UML мертв”, “Почему системным аналитикам не нужен UML” и множество подобного. Работая на протяжении последних 15 лет в совершенно разных компаниях, с совершенно разным жизненным циклом приложений и систем, с различной структурой и методологиями разработки я вижу одно и тоже - попытки ускорения time-to-market за счет отказа от процесса управления требованиями, подаваемые под разными прекрасными аргументами, приводят 100% компаний к необходимости переписывать приложения не потому, что оно не отвечает требованиям, а потому что “никто не знает как или почему оно так работает”.
Важной проблемой отказа от нормального процесса управления требованиями является то, что разрабатываемые без этого процесса приложения и системы получаются абсолютно не гибкими и даже элементарнейшие, с точки зрения заказчиков, изменения приводят к запуску полного цикла разработки.
Можно перечислить еще огромное количество проблем, к которым приводит разработка без модели требований, например:
Невозможность понять, как работает/работала система в той или иной версии.
Невозможность нормально тестировать, опираясь на конкретные номерные требования.
Невозможность привязывать дефекты к конкретным требованиям.
Невозможность понятно и прозрачно понять на какие требования и процессы внутри системы влияют новые изменения.
Невозможность прозрачно и понятно посмотреть timeline изменений требований.
И тем не менее, раз за разом, этап системного анализа пытаются пропустить или пустить в параллель, почему же?
Если отчистить от шелухи все обтекаемые и политизированные аргументы, все сведется к тому, что заказчик хочет напрямую ставить задачи разработке, и видеть, как те сразу без промедления и пауз на подумать, берут их в работу.
Вместо холивара
Я в целом согласен с подходом прогрессивного jpeg, но вот мое отношение к попыткам отказаться от выделенного этапа анализа описывается началом первой главы рассказа «Винни Пух» Алана Милна:
При этом я не призываю проектировать эскалатор для Винни Пуха, и даже отмечаю, что Винни Пух-таки добирается до низа этой лестницы. Если этот вопрос покажется вам интересным, я могу попробовать написать отдельную статью со своим отношением и пониманием роли системного анализа в процессе разработки для разных методик разработки ПО.
Для того чтобы все же иметь нормальную модель требований нужно определиться с языком описания этих требований, которому не нужно будет обучать всех членов команды, а также представителей бизнес-заказчиков. И тут для многих выбор UML не очевиден, и очень часто специалисты придумывают довольно странных и страшных франкенштейнов из EPC, отдельных UML-диаграмм, схем БД, IDEF, Mind Map и черте чего еще, хотя, как показывает мой опыт, разработанный мной в 2011-2012-х годах подход лаконичного использования UML без изысков и выкрутасов позволяет получить очень простую и понятную модель требований, в том числе позволяющую генерировать ТЗ одной кнопкой.
Меня зовут Александр Головков и именно этим подходом я и хочу с вами поделиться.
В чем суть и профит подхода
Использование централизованной модели требований с общим доступом к ней для всех членов позволяет переиспользовать элементы модели.
Следование набору требований к описанию элементов модели требований позволяет обеспечить полное понимание требований, а также автогенерацию технического задания, из модели требований.
Следование определенному набору формальных требований к качеству модели требований позволяет повысить качество требований и сократить затраты на разработку требований за счет возможности у аналитика провести self-check, не отдавая недостаточно проработанные требования другим членам команды.
Обязательное review требований внутри команды аналитиков и продуктовых команд позволяет повысить качество требований и технических заданий.
Использование инструментов автогенерации технического задания из модели требований позволяет значительным образом сократить время на разработку технических заданий.
Версионирование требований жестко привязанное к версионированию кодовой базы позволяет в любой момент времени иметь полное достаточно подробное техническое задание на каждую версию системы или продукта, не плодить, прости господи, частные технические задания и вообще иметь одно живое изменяемое от версии к версии ТЗ, вместо вороха файлов.
Использование ограниченного набора UML диаграмм позволяет всесторонне описывать требования и алгоритмы, и не требует глубокого знания UML от системных аналитиков и других членов команды, а также от заказчика.
Из минусов подхода можно выделить два:
Заказчиков все еще нужно заставлять читать требования и читать им придется, водя пальчиком по диаграммам, иногда возвращаясь к развилкам, вместо зачастую более привычного им текста и списков.
Подход довольно сильно завязан на конкретные инструменты и его перекладывание на другие может быть довольно сложным.
Смотря на описанные выше тезисы, зная, что лежит под каждым из них, я понимаю, что в одной статье все это не опишешь, поэтому для полного описания подхода понадобится несколько статей, ссылки на них будут здесь.
Процесс системного анализа в описываемом подходе выглядит так:
Системный аналитик создает snapshot требований, чтобы иметь возможность отслеживать свои изменения (на самом деле этот шаг избыточен, если подход соблюдается и требования не правятся вне процессов, определяемых данным подходом) и разрабатывает модель требований, пользуясь ограниченным небольшим набором элементов и диаграмм, чтение которых не требует понимания специфических нюансов UML и знаний чем, например, заштрихованная стрелочка отличается от незаштрихованной. Требование к набору диаграмм и элементов, ограничивающее сложность получаемых ТЗ является первым из пяти основных требований подхода.
Какие диаграммы мы используем
Не более чем перечислено, но все что перечислены в обязательном порядке):
Domain model
Use Case model
Activity diagram для каждого Use Case
Custom diagram для GUI - для привязки функциональных требований к конкретным элементам GUI
Этого набора более чем достаточно для отображения всего набора функциональных требований.
Обратите внимание, что согласно процессу первой должна быть разработана модель предметной области — это второе из пяти ключевых требований подхода, которое позволяет ему быть эффективным.
Domain Model
Качественно проработанная модель предметной области — это залог правильного понимания аналитиком терминов, которыми оперирует бизнес-заказчик и, как следствие, озвучиваемых им требований. Для проведения самопроверки у аналитика есть простой чек-лист:
На всех ли коннекторах указаны мультипликаторы на обоих концах?
Является диаграмма предметной области планарным графом? (коннекторы между классами на диаграмме нигде не пересекаются)
Нет ли классов без атрибутов?
Дано ли определения для каждого класса?
С помощью таких простых проверок, не требующих даже проверки логики, которую аналитик и так сделает, можно быстро, в течение нескольких минут найти дефекты в понимании аналитиком предметной области, устранив которые на ранней стадии можно кардинальным образом улучшить качество разрабатываемых требований.
После проведения самопроверки, системный аналитик отдает заблокированную для изменений и доступную только для комментирования модель команде на review, параллельно генерирует ТЗ и публикует его, импортируя в Confluence, где отдает требования на review заказчику.
После получения замечаний, системный аналитик обрабатывает их, внося изменения в модель требований. Критически важно, чтобы на этом этапе, после разработки подхода к устранению замечаний, системные аналитики согласовали свой подход с ревьюерами, чтобы ограничить количество итераций исправлений до 1. Это требование является третьим из пяти краеугольных требований подхода, и его выполнение позволяет мотивировать аналитика на тестирование модели требований, которую он собирается передать команде и заказчику и не позволяет ему переложить это тестирование на плечи других участников.
Последние два (четвертое и пятое) из пяти критических требований подхода это:
Перед каждым ветвлением на activity диаграмме должен быть action с проверкой, к которому обязательно привязано требование или требования, определяющие как эта проверка должна осуществляться.
Модель требований и ТЗ должно версионироваться, для согласованных версий модели и ТЗ должен быть проставлен соответствующий Tag с версией.
В этом цикле статей я постараюсь дать все описания, инструкции и требования. На текущий момент, подход включает в себя следующие артефакты:
Инструкция по настройке централизованной модели на базе Sparx Enterprise Architect + MySQL Server:
Настройка БД
Настройка ODBC
Настройка пользователей
Настройка автонумерации сущностей модели требований
Ее вы можете найти тут.Требования к модели требования – опишу в одной из следующих статей.
Шаблон модели требования – опишу в одной из следующих статей.
Требования к ТЗ – опишу в одной из следующих статей.
Инструкция по автогенерации ТЗ и ведению ТЗ в Confluence – опишу в одной из следующих статей.
Шаблон автогенерации ТЗ – опишу в одной из следующих статей.
Что нужно, чтобы настроить инструментарий и провести пилот подхода?
Atlassian Confluence
Почему:Версионность ТЗ за счет использования тегов
Возможность организовать review требований командой (Inline comments)
Отображение изменений системы от версии к версии
Связка версии модели требований к версиям системы
Sparx Enterprise Architect + MySQL Server – инструкция по настройке тут
Почему:
Относительно простой инструмент отрисовки моделей
Горячие клавиши позволяют значительным образом увеличить скорость разработки модели требований
Возможность организации централизованная модель требований
Возможность создавать snapshots модели (baseline) и вести версионность требований
Возможность организовать review требований командой (опционально, многим командам больше нравится проводить review в confluence)
Генерация ТЗ - killer feature, позволяет сэкономить огромное количество ресурсов
Ссылки на связаннные статьи:
Моя статья о версионировании требований "Почему системные аналитики и QA инженеры должны требовать от разработчиков семантическое версионирование"
