Не кажется ли вам, уважаемые форумчане, что начиная свой опыт по использованию нотации BPMN сразу с версии 2.0 вы заведомо поддаетесь соблазну использовать весь ее "алфавит" где можно обойтись простыми элементами? Это как если бы усложнить азбуку и добавить еще 1000 новых букв эквивалентных слогам. Ведь для большинства процессов вполне хватит нотации версии 1, за исключением лишь некоторых удобных добавлений по работе с данными. Зная о существовании богатого набора значков вы поддаетесь соблазну использовать их. Хотелось бы узнать ваше мнение, стоит ли сначала новичкам рисовать базовыми элементами схему и только после откладки начинать тюнинг и то только если без этого жить диаграмма не будет в полевых условиях.
-
Опубликовано 12 лет назад #
-
Neverpoint
Ваш вопрос из серии "чем лучше копать ямы - лопатой или трактором"?
И простой ответ на него такой: умеешь работать на тракторе - копай трактором, не умеешь - копай лопатой.
С уважением, ПСОпубликовано 12 лет назад # -
Как выяснилось в другой ветке, г-н аноним плохо представляет чем BPMN 2.0 отличается от BPMN 1.x.
Опубликовано 12 лет назад # -
А, кстати, таки отличается или нет?
Опубликовано 12 лет назад # -
Цитирую Анатолий Белайчук:
Как выяснилось в другой ветке, г-н аноним плохо представляет чем BPMN 2.0 отличается от BPMN 1.x.Уточню - речь об использовании базовых элементов BPMN 2.0, в одной из веток я это оговаривал. А не о замене более поздней нотации ранней. Отличия есть конечно, по части уточнения и систематизации того, что было - никто не спорить, нужно использовать. Я много раз везде делал оговорку, что речь о "расширениях" и о начале проектирования процесса с нуля
Опубликовано 12 лет назад # -
Цитирую pipec:
А, кстати, таки отличается или нет?Разумеется отличается. Но основное отличие не там, где его ищет большинство.
С точки зрения пользователя BPMN (т.е. аналитика) изменений немного: появился непрерывающий обработчик, появился тип события "эскалация", появился подпроцесс-обработчик события... Без всего этого можно жить.
Принципиальное отличие в том, что модель стала частью схемы процесса: BPMN 1.x = "modeling notation" vs. BPMN 2.0 = "model and notation". Это очень важный шаг с точки зрения стандартизации, и как результат мы наблюдаем консолидацию отрасли вокруг BPMN 2.0.
Значимость такой консолидации трудно переоценить - я бы ее сравнил с признанием SQL в качестве стандарта.
Опубликовано 12 лет назад # -
Цитирую neverpoint:
Уточню - речь об использовании базовых элементов BPMN 2.0, в одной из веток я это оговаривал. А не о замене более поздней нотации ранней. Отличия есть конечно, по части уточнения и систематизации того, что было - никто не спорить, нужно использовать. Я много раз везде делал оговорку, что речь о "расширениях" и о начале проектирования процесса с нуляВы на нескольких ветках представляли BPMN 1 как упрощенную версию BPMN 2. ОК, проехали.
Что касается использования базового или расширенного набора элементов BPMN: вы опять-таки ломитесь в открытую дверь. Не сомневайтесь - авторы, чьи модели вы комментируете, прекрасно понимают, что с помощью BPMN можно создавать упрощенные модели. И этому они учатся без особых затруднений.
Затруднения возникают при попытке все описать точно. Для этого нужна полная палитра и умение ей пользоваться. Вот люди и учатся.
И тут появляетесь вы с призывом: зачем рисовать сложные модели, рисуйте простые ;)
Опубликовано 12 лет назад # -
Цитирую Анатолий Белайчук:
И тут появляетесь вы с призывом: зачем рисовать сложные модели, рисуйте простые ;)Как бы это дико не звучало, но действительно лучше рисовать простые модели - один процесс одна цель (одно конечное событие у процесса), а процессы обработчики исключительных ситуаций, вызывающие отклонение от цели основного процесса вообще выделять в отдельные процессы. Что касается межпроцессорного взаимодействия то по каждой задаче, у которой есть такое взаимодействие, создавать отдельную хореографию и не включать описание межпроцессорного взаимодействие в основную диаграмму. Чем меньше условных обозначений задач, событий, точек ветвления - тем проще ее читать, это факт. Если этому не следовать то на какой нибудь версии BPMN 10.0 количество обозначений будет как в китайском языке иероглифы - каждое слово иероглиф. Достоинством дополнительных обозначений может явиться уменьшение размера схемы, но при разделении модели на процессы и подпроцессы, избегая отображение межпроцессорных взаимодействия в диаграмме основного процесса - схема будет читаться легко, если выделены грамотно уровни абстракции задач (а они выделяются по руководителям задач, контролирующих выполнение участниками процесса задачи на результат).
Но ваш мессадж я услышал - на форуме люди тренируются в нотации. Учту при комментарировании и создании темОпубликовано 12 лет назад #
Ответ
Вы должны авторизоваться, чтобы публиковать сообщения.