Доброго времени суток уважаемые форумцы!

Описываю процесс разработки ПО. Не обладаю большим опытом в описании процессов в нотации BPMN.
Прошу покритиковать один подпроцессов "Разработка и согласование Концепции с Заказчиком".

Спасибо!

Егор,
1.
Давайте сразу отсечём один момент. Схема составляется только для того чтобы лечь Регламентом на полку или предполагается перенос в работку в Bizagi Studio или что-то подобное? Если планируется запуск BPMS - сразу избавляйтесь от граничных событий. Нет их там.
 
2.
Давайте сразу учиться хорошему тону. Action на любой схеме, а уж тем более в BPM - это действие, которое кто-то (или что-то) должен (должно) выполнить. Вы для этой схемы кто ? Автор или сторонний наблюдатель ? Автор. Значит это Вы говорите кто и что должен делать. Соответственно нужно использовать глаголы повелительного наклонения.  Не "Разработка" и "Доработка", а "Разработать" и "Доработать".
Неопределенные формы глаголов допустимы только в объявлении пулов и лэйнов - там идёт общее описание процесса.

3.
По схеме наконец.
1. Руководитель проекта возвращает концепт на этап начальной разработки. На самом деле это не так - там будет 1 или несколько этапов доработки. Стоит сделать отдельную задачу.
2. Выход сообщением из анализа документа РП непонятен. РП то продолжает работать с документом или нет ? Если продолжает - может возникнуть любопытный казус, который опишу ниже.
3. А Ведущему БА мы верим на слово ? Результат его работы на анализ к РП не возвращается ? Сразу на Заказчика ? В общем, так действительно может быть, я просто спросил на всякий случай.
4. Возвращаясь к п.2. - ЕСЛИ сообщение на ВБА пошло, а РП продолжил работать - он перешлёт документ Автору на гейте "не согласован". В итоге Автор получит 2 экземпляра Концепта: отклоненный РП и обработанный ВБА. И с каким из них он продолжит работать? В общем, не зная реального процесса, предполагать сложно, но на мой взгляд у Вас там должно стоять граничное событие "Эскалация" или "Ошибка", а внутри - обрыв основной ветки.
5. Отправка - получение на заказчика. Вы не получили ответа. Я вообще не понял как система дала Вам воткнуть сообщение из внешнего пула в "Пользовательскую" задачу (неужто это Visio ?), но там должно стоять "Получить ответ" типа "Входящее сообщение", и только потом - пользовательская "Анализировать". А вместе с Получением ответа стоит сразу предусмотреть параллельную ветку с таймером - что делать если не получено.
6. Концепт, отклоненный Заказчиком, уходит на БА. Это точно так ? Вариант передачи на ВБА не рассматривается ?

Также рекомендую посмотреть бесплатные моделлеры с валидацией диаграммы.
Из того, чем лично пользовался - Bizagi Modeller и Bonita BPM примерно одинаковы по функциональности и вполне достойны.

Андрей, большое спасибо за развернутый ответ.

1. По поводу применения схемы. Хочется верить, что эта схема как и несколько других попадут не только в регламент, который будет пылиться на полке. Я ставлю себе цель автоматизировать процесс, скорее всего это будет сделать с помощью BizAgi.
2. Учтено.
3.1 Если я правильно понял Вашу мысль, то в случае если документ возвращается на доработку, он попадет не в задачу "Разработать документ", а в задачу "Доработать документ". Так? Действительно этапов доработки может быть несколько, особенно для сложных тем.
3.2 С помощью события (прерывающего) соединенного с границей действия хотел изобразить примерно следующие, что в случае если БРП анализирую документ понимает, что без ВБА не обойтись (например, сложная тема или БА не понял предметную область), БРП ставит ВБА задачу провести анализ документа, тогда включается цикл ВБА и БА по подготовке документа. А задача БРП по анализу документа подготовленного БА прерывается. Вычитал в спеке BPMN http://www.elma-bpm.ru/bpmn2/10_4_3.html , Таблица 10.90
3.3  Действительно БРП всегда смотрит документ перед отправкой Заказчику. Поправил на схеме.
3.4 см. п. 3.2.
3.5 Диаграмму моделировал в Business Studio, т.к. система заточена только рисовать схемы и генерировать регламенты, то соответственно не такие строгие правила к моделированию. Перерисовал в BizAgi, схема проходит валидацию без ошибок. Правильно ли сейчас смоделирована ситуация?
3.6 Зависит от специфики, по-моему мнению если документ готовил изначально БА, то и после рецензии Заказчика в случае необходимости ему нужно продолжать дорабатывать документ.

1. Ну автоматизировать так автоматизировать.
И пусть наши цели совпадают с планами руководства.
Тогда так. Под каждым Action будет лежать свой кусок кода, а к каждой "Пользовательской" задаче будет дополнительно привязана форма на портале. В этом случае, на мой чисто взгляд, схема для регламента и рабочая схема BPMS должны отличаться. Моделируя регламент, можно в целях упрощения схемы вообще и экономии места в частности объединить несколько похожих действий в 1 блок, ну комментарий там ещё добавить.
При переносе же на портал у Вас для "Разработать" (первичной постановки задачи) и "Доработать" (с комментариями и причинами сброса в доработку) будут сильно отличаться параметры, а соответственно лучше не мудрить в коде и на форме, а сделать 2 разных задачи.
Это же касается и граничных событий. Даже если Бизаги их и реализовали, что сомнительно, то далеко не факт, что оно реально работает и удобно. Потому что на программном уровне такой переход связан с кучей проблемок.

Егор, здесь крайне желательно слушать не меня одного, а найти ещё 2-3 человек. Потому что выше я написал как бы делал я. Могут быть и другие варианты.
А уж если выбрана Bizagi - то рекомедую сразу к Белайчуку.
http://mainthing.ru/ru/
http://bpmnforum.ru/forum/2
Ну и на тренинг желательно сходить. Ибо зачем время терять? Стартовый задел у Вас хороший, нужно прокачивать.
http://bpmntraining.ru/

По остальному вечерком отвечу. Ну или днём если время будет.
С мобильника печатать такие объёмы лень.

Дальше.
Давайте разберем ещё выход по граничному событию. Уже с учётом того, что мы нацеливаемся на BPMS.

Я развернул подпроцесс "Анализировать концепт" для наглядности.

В портальной форме BPMS системы РП получает в читку очередной Концепт, что-то с ним делает (возможно даже читает), после чего или оставляет его как есть (для отправки на рецензию Заказчику) и или же вносит свои комментарии и выбирает куда эти замечания пойдут.
Варианта у нас 2
- БА на доработку
- ВБА на уточнение.
И здесь Вы создаёте отдельный поток, вырывающийся из процесса с триггера по данным. Как это реализовать программно ? Внутри процесса обработки Формы нужно будет встроить проверку выбора:
- БА на доработку - поставить в некое поле флаг "доработка", закомиттить и выйти из модуля, отдав управление на следующий гейт, который и разведет потоки по этому флагу.
- ВБА на уточнение. Тут даже не знаю. Нужно также записать куда-то данные, оборвать этот модуль (событие какое? в базе для статистики что писать ?) а затем ещё поймать чем-то эти данные в БД и утащить управление к ВБА.
На первый взгляд - так.

Теперь второй вариант Вашей схемы.
поставить в некое поле флаг "доработка БА" ИЛИ "доработка ВБА", закомиттить и выйти из модуля, отдав управление на следующий гейт, который и разведет потоки по этому флагу. Просто на гейте будет проверяться на 1 состояние больше.
Мне кажется, так проще.

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

Ну и бегло по остальному.

2. Ок.
3.1. Выше описал. Отдельная задача проще в реализации в BPMS.
3.2. Выше описал. С точки зрения "здравого смысла" - натянуто (на мой взгляд, тут нет ошибки. Подключение Ведущих - это нормальный рабочий процесс), но принимается потому что Вам виднее что считать ошибкой (я не иронизирую). С точки зрения "расово чистой нотации" ошибки тут нет. С точки зрения реализации в BPMS - лучше с конкретным разработчиком обсудить как ему проще. На мой взгляд - по завершении задачи на РП проверить все варианты на одном гейте. С ELMA я на практике не работал, возможно у них уже готовые триггера на этот случай есть. Допускаю.
3.3. Ок
3.4. Ок.
3.5. Тут мы опять возвращаемся к теме разных моделей для разных целей.
Если модель - только для Регламента, можно вообще убрать пул "Заказчик", поставить РП Пользовательскую задачу "Передать на рецензию и получить ответ от Заказчика" и нас реально слабо волнует как он это будет делать. Мы нашли жертву и ладно.
Если же модель пойдёт в BPMS - задачи Send и Receive лучше возложить не на РП, а на машину (отдельной дорожкой). А то будет бедный сидеть кнопки нажимать при наличии автоматизации.
3.6. Дело хозяйское.

Доброго времени суток уважаемые форумцы!

Описываю процесс разработки ПО. Не обладаю большим опытом в описании процессов в нотации BPMN.
Прошу покритиковать один подпроцессов "Разработка и согласование Концепции с Заказчиком".

Спасибо!

Неявные развилки (когда в активность входит и выходит более одного потока управления) - плохой стиль
Так же как и непарность развилок (расходящейся развилке должны соответствовать сходящаяся). Хотя иногда потоки управления синхронизировать не требуется...