Комментарии 8
Я всегда думал, что бизнес-аналитик или системный аналитик или просто аналитик, это в первую очередь человек, который глубоко разбирается в предметной области в которой создаётся программное обеспечение. Ну не знают программисты фармацевтику и в производстве, учёте, продаже столовых приборов они тоже не разбираются. И в транспортных операциях не разбираются. Его выделяет инвестор из своей команды для того, чтобы он долго и нудно объяснял программистам, что они хотят получить. И если он даже сам сумеет нарисовать удобный для фирмы или пользователей UI/UX, то ему нужно медаль купить в интернет-магазине. Ему нужно на человеческом языке написать программистам, что должно отображаться на экране при нажатии на кнопку. А UML это уже слишком сложно и не очень читабельно. А программисты уже напишут, какой JSON полетит на HTTP сервер на какой Endpoint и какие запросы полетят на SQL сервер (Если в приложении REST архитектура). В процессе программисты будут пытаться всё максимально упростить. Из документов они любят Use Case, но предпочитают их писать сами.
Соглашусь отчасти.
В профессиональной среде до конца не сложилось единого "эталонного" перечня обязанностей аналитика, хотя потихоньку идём в этом направлении (к примеру, слышал, что в одной компании на аналитика возлагают и саппорт). Так, в РФ уже появились проф.стандарты, и они разделяют системного аналитика и бизнес-аналитика. То, что касается предметной области в большей степени отнесли ко 2-й специальности, хотя и пересечение никто не отменял.
Что же касается "ему нужно на человеческом языке написать программистам", то визуализация как раз и поможет этот человеческий язык подтвердить. Это как перефразирование, но только наглядное и лишённое недостатков естественных языков, к примеру, многозначности трактовок.
Далее. "Программисты уже напишут, какой JSON полетит на HTTP сервер на какой Endpoint и какие запросы полетят на SQL сервер" -- тут тоже поле для "творчества". В разных компаниях и даже командах внутри одной компании существуют разные договорённости. Часто именно системный аналитик формирует эндпоинт, определяет HTTP-метод и состав форматов запроса-ответа, а разработчики уже это красиво реализуют.
Основной посыл, я бы сказал, не в том, чтобы "застолбить" какую-то работу за какой-то ролью в команде, а чтобы показать пользу визуализации, на примерах показать границы применимости и предложить альтернативы.
Вкратце, 1) выбор той или иной визуализации зависит от ее потребителя, 2) время жизни диаграммы обратно пропорциональна ее детализации.
Спасибо за интересное резюме, но я бы сказал, что после прочтения каждый может вынести из статьи что-то своё. Кто-то может отметить, например, такое:
всему нужен свой инструмент (условно, киянку и кайло не всегда можно без ущерба делу заменить молотком),
при определённых обстоятельствах надо декомпозировать и/или выбирать иной инструмент (а для этого полезно расширять кругозор).
По должности (ИТ Архитектор) рисую кучу диаграм и сейчас пришел к тому, что к целом не придерживаюсь особой нотации. Конечно, бизнес ориентированные диаграммы рисую реже, но приходится
Получается так. Если надо схему, чтобы вставить для презентации, то получается, что ее основной критерий "успеха" - наглядность демонстрации идеи.
К примеру:
Описание процесса на высоком уровне проще все делать "шевронами", где каждый шеврон - это отдельный этап последовательного процесса. Все понятно, как все происходит и можно акцентировать важные моменты.
Переходы между формами - ну тут все понятно, прямоугольник - форма, стрелочка - переход. Размер значения не имеет
Use cases - разве что для начального этапа, чтобы типа ничего не пропустить. Дальше в реальной жизни она на фиг не нужна, так как все переехало в Jira и таски. Разве что для самопроверки, но по идее - все уже переехало в Backlog
Диаграммы последовательностей в конечном итоге не сильно полезны. Раньше рисовал много, но больше с целью показать, что процесс в целом рабочий и нигде нет косяков. Разработчику это не слишком интересно кроме случая, если сценарий реализуется на "шины" в рамках SOA-парадигмы (ну или чего-то схожего). Иначе - разработчик делает отдин квадратик в момент времени, который отделен от других квадратиков "контрактами" (если не отделен - это вопрос ко мне, почему :) )
Логическая модель данных - да, это можно. Но так как часто из нее нельзя автоматически генерить DDL - получается мартышкин труд. Если можно, тогда нет, но тогда нужен соответствующий тул.
Поэтому выходит, что схема больше нужна для:
презентации мысли здесь и сейчас конкретной аудитории
как емкое и лаконичное описание чего-то большого, вроде карты
Но тогда смысл заморачиваться с нотациями? С опытом пришло понимание как рисовать, плюс всегда пожно подглядеть что-то новенькое. У для тех у кого опыта нет - ну блин, смотри, как рисуют другие :)
Спасибо за развёрнутый комментарий! Попробую по возможности прокомментировать.
Получается так. Если надо схему, чтобы вставить для презентации, то получается, что ее основной критерий "успеха" - наглядность демонстрации идеи.
На мой взгляд, наглядность нужна всегда. Если доносим идею или пытаемся сами обозреть некую концепцию, то да, диаграмма должна быть максимально наглядной.
Если же цель состоит в том, чтобы презентовать широкой публике, то ещё возникает потребность представить "красиво" (в меру своего понимания красоты, конечно:)). Так для написания данной статьи (моя проба пера) ряд вещей пришлось перерисовать, чтобы убрать лишние детали и сделать красочней.
Диаграммы последовательностей в конечном итоге не сильно полезны... Разработчику это не слишком интересно кроме случая, если сценарий реализуется на "шины" в рамках SOA-парадигмы (ну или чего-то схожего).
Диаграммы последовательностей для разработчиков могут быть полезны. Во-первых, с их помощью можно количественно оценить, сколько интеграций потребуется. Во-вторых, можно сделать качественные выводы:
с какими системами строим взаимодействие (при микросервисной архитектуре особо интересно),
объекты каких классов нужно будет инстанцировать (в зависимости от вызываемой системы они могут различаться),
какие паттерны проектирования будут полезны (синглтон, например).
Плюс на сиквенсах можно показать особенности обработки ошибок и тайм-аутов. К примеру, недоступность сервиса А должна приводить к сообщению об ошибке для клиента, а недоступность Б -- всего лишь досадное недоразумение и мы можем подготовить клиенту ответ в усечённом виде, основываясь только лишь на данных из ответа сервиса А.
Если приложение распределённое и идут цепочки вызовов, то диаграммы взаимодействий позволят таже понять цепочку, а не воспринимать контракт ближайшей системы как чёрный ящик. Не всегда это нужно, но иногда бывает.
Но тогда смысл заморачиваться с нотациями?
Нотации хороши в том плане, что это как профессиональный язык, который помогает скорее и с меньшим числом разночтений понять людям из одной сферы. Пример: если приходишь в новую команду или компанию, так вы быстрей договоритесь об "общем знаменателе".
В нотациях есть потенциальный риск, который состоит в том, что нотации содержать зачастую сильно больше возможностей и правил, чем стоит пользоваться (моё мнение). Если базовые возможности помогают общаться, то применение редких (чтобы выделить какой-то нюанс) может сыграть злую шутку: твою задумку без дополнительных пояснений попросту могут не понять или неверно интерпретировать.
Но, повторюсь, что нотации полезны. Не придётся каждый раз с разными визави договариваться о том, что скрывается за какой стрелочкой.
И ещё. Если Вы для себя выработали и зафиксировали правила вроде "красная стрелка это..., а чёрная -- ...", придерживаетесь их всегда, то можно утверждать, что Вы создали свою личную нотацию, и это тоже может иметь свой смысл. Иногда такие нотации закрепляются внутри компаний и мы возвращаемся к тезису о том, что это помогает упростить коммуникации и избегать разночтений.
С опытом пришло понимание как рисовать, плюс всегда можно подглядеть что-то новенькое. У для тех у кого опыта нет - ну блин, смотри, как рисуют другие
Вот этот труд нотации и помогают упростить. Если все пользуются плюс-минус одними правилами, то перенять опыт проще:)
Интересно кто-то занимается иммитационным моделированием бизнес процессов, ну или дискретным. Чтобы были схемы процесса, где кнопку тык, и софт сказал что процесс в принципе рабочий. Ну или запустилась схема и сразу видно что блоке А всё в очередях пухнет при количестве обращений Н.
Как будто чего-то всё время не хватает при проектировании больших систем. Единого инструмента что-ли, где бы и контракты были, и границы сервисов, и bpmn модели и UML схемы, и форматы данных, и смоделированные процессы.
Последнее имитационное моделирование, с которым я имел дело,— это курсовая в ВУЗе много лет назад, в рамках которой наблюдали за потоком клиентов в столовой, как это сказывалось на длину очереди и время обслуживания в динамике. По итогу на C++ Builder делали имитационную модель, которая позволяла поиграть параметрами и посмотреть, как это повлияет на вышеназванные показали.
В жизни же задач на системы массового обслуживания не приходилось решать, да и промышленных инструментов такого рода не попадалось. А так да, тоже было бы интересно почитать/посмотреть, тем более если бы это всё поддавалось настройке и позволяло наложить на ИТ-решения.
Осмысленная визуализация при анализе и проектировании информационных систем