В сети вы можете найти множество статей на тему “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 и знаний чем, например, заштрихованная стрелочка отличается от незаштрихованной. Требование к набору диаграмм и элементов, ограничивающее сложность получаемых ТЗ является первым из пяти основных требований подхода.

Какие диаграммы мы используем

Не более чем перечислено, но все что перечислены в обязательном порядке):

  1. Domain model

  2. Use Case model

  3. Activity diagram для каждого Use Case

  4. Custom diagram для GUI - для привязки функциональных требований к конкретным элементам GUI

Этого набора более чем достаточно для отображения всего набора функциональных требований.

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

Domain Model

Качественно проработанная модель предметной области — это залог правильного понимания аналитиком терминов, которыми оперирует бизнес-заказчик и, как следствие, озвучиваемых им требований. Для проведения самопроверки у аналитика есть простой чек-лист:

  1. На всех ли коннекторах указаны мультипликаторы на обоих концах?

  2. Является диаграмма предметной области планарным графом? (коннекторы между классами на диаграмме нигде не пересекаются)

  3. Нет ли классов без атрибутов?

  4. Дано ли определения для каждого класса?

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

После проведения самопроверки, системный аналитик отдает заблокированную для изменений и доступную только для комментирования модель команде на 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, позволяет сэкономить огромное количество ресурсов

Комментарии (11)


  1. tempart
    00.00.0000 00:00
    +1

    Подход понравился, надо будет посмотреть детальнее.

    По мелочам. В (непронумерованной в числе остальных :) ) схеме "Процесс системного анализа" после ревью надо ли откатываться сразу в самое начало? Заранее причина неудачного ревью неизвестна, её надо валидировать, а это - шаг "Self-check"


  1. DmitryShm
    00.00.0000 00:00

    Статья отражает то, что использую сам в работе. Это часть PIM-модели, которая наверное должна трассироваться на имеющуюся CIM, и далее на её основе создаётся PSM-модель. Из минусов подхода - людям становится сложно называть себя аналитиками, ведь теперь надо владеть профессией, и вместо расплывчатых фраз и рисунков - есть требования к результатам работы. Соответственно далее становятся обусловленными и роли бизнес-аналитиков с требованиями к их CIM-модели, и роль системного архитектора с его PSM-моделями. Короче слишком много людей, не владеющих профессиями, останутся без зарплаты, если применять этот подход.


  1. romanukov
    00.00.0000 00:00
    +1

    не требует глубокого знания UML от системных аналитиков

    На практике беда в том, что важны на таких схемах как раз детали: формы стрелок, правила описания данных / логики. Аналитиков надо учить соблюдать кучу глубоких, но важных формальных требований к оформлению такой диаграммы, если они решили в ней что-то исправить. Или хотя бы прочитать, вникнув до конца во все нужные им процессы.

    Есть ощущение, что на практике такое применяют только на совсем огромных масштабах из-за того, что UML - вещь абстрактная, четкого стандарта того, как фичи должны работать в нем, нет. Кто-то пишет текстовую декларацию, кто-то привык стрелки раскидывать. У всех не очень совместимые друг с другом версии UML. Поэтому использование UML'ом надо вводить в компании с огромным гайдом по нему и учить пользоваться строго определенным софтом. То есть все-равно примерно с нуля придется создавать язык, на котором будут описаны диаграммы.

    При таком раскладе уже проще взять "рисовалку квадратиков-стрелочек" с интерфейсом полегче и определиться, какие формы/цвета/размеры/border'ы у стрелок что значат, написав под это док. UML убивает отсутствие стандартизации :(


    1. AlexGFrei Автор
      00.00.0000 00:00

      Мой опыт говорит, что вот такой подход, желание описать все, соблюсти все правила UML и перфекционизм в рисовании диаграмм, вместо перфекционизма в передаче требований и приводит к скатыванию к попыткам замены разработки нормальных полноценных моделей требований на описание системных требований в виде нумерованных списков в документах типа BRD или в тикетах в Jira/Redmine/etc


    1. DmitryShm
      00.00.0000 00:00

      Как раз-таки с языком UML идут и RUP, и RUP/ICONIX и ещё ряд вещей, что сделано стандартами предприятия в ряде известных компаний.

      UML убивает отсутствие у нас в стране людей, владеющих профессией.


  1. ivorrus
    00.00.0000 00:00
    +3

    Довольно иронично, что в статье, посвященной преимуществам UML, диаграмма процесса системного анализа нарисована в нотации BPMN


    1. iggr63
      00.00.0000 00:00

      Точно. Бизнес аналитики именно BPMN и предпочитают.


      1. ivorrus
        00.00.0000 00:00

        Я в курсе, т.к. сам - аналитик и BPMN знаю, умею, практикую


    1. AlexGFrei Автор
      00.00.0000 00:00

      На самом деле не очень, хотя я тоже об этом думал когда рисовал :)

      Системный анализ, в моем понимании, не включает в себя описание бизнес-процессов.


  1. antaratmananda
    00.00.0000 00:00

    Почему требуется планарность графа для диаграммы предметной области? Какие проблемы повлечёт непланарность?


    1. AlexGFrei Автор
      00.00.0000 00:00

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