Здравствуйте.
Столкнулся с некоторыми проблемами при разработке модели бизнес-процессов, и хотелось бы испросить совета у уважаемой публики.
Итак, есть реальная задача. Должен сказать, что в связи с несколько параноидальным отношением заказчика к информационной безопасности, вынужден опустить некоторые непринципиальные моменты и настоящие названия заменять на условные.
Есть несколько подразделений, одно из которых осуществляет внутренний контроль (назовем его Служба Контроля), а остальные (назовем их Бизнес-подразделения) - вводят различные документы, касающиеся данных по клиентам.
Служба контроля проверяет введенные данные на корректность и, в случае если обнаруживает какие-то ошибки или пропуски в информации, направляет сотрудникам (допустившим ошибки) замечания. Сейчас все это работает в ручном виде, через почту и систему документооборота.
Предлагаемая схема:
- Служба контроля вводит замечания и назначает срок, в течении которого замечания должны быть устранены. Замечание получает статус "Введено".
- ИС по этим замечания рассылает уведомления по эл. почте (этот момент я не нашел как отразить в схеме, но его, наверно, можно в считать второстепенным)
- Подразделение, получившее уведомление о замечаниях, открывают карточку замечаний. Замечание получает статус "В работе".
- Подразделение либо устраняет все ошибки и ставит статус "Выполнено", либо не устраняет (не может устранить) и ставит статус "Не выполнено" с обяз. указанием причины.
- Служба контроля проверяет выполнение замечаний и, либо подтверждает их (на схеме это выход), либо отправляет их обратно на доработку (с соотв. статусом). На схеме этот поток ведет к процессу "Вводят замечания", т.к. при этом необходимо указать причину доработки.
- Допускаем, что сотрудники, в адрес которых направлено замечания, могут по каким-то причинам (напр., разгильдяйство) не посмотреть замечания и не взять их в работу. Или взять и забыть про них. Такие замечания опять же попадают службе контроля как просроченные после чего опять возвращаются к подразделению (и возможно следуют какие-то административные телодвижения).
Посмотрите, пжлста - что я накосячил. Должен сказать что я не шибко владею UML...

Здравствуйте.
Столкнулся с некоторыми проблемами при разработке модели бизнес-процессов, и хотелось бы испросить совета у уважаемой публики....

А в чем сама проблема-то (для Вас лично при разработке модели) ?

Посмотрите вот эту статью:
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep03/f_umlbasics_db.pdf
Особенно стр. 13 - ваш случай

Вообще тут мне кажется должна быть ДД более простая. Если статья не поможет, то нарисую свой взгляд.

Shur
Дык, в том, чтобы правильно диаграмму нарисовать

bas
Спасибо, буду думать.
Пока понял что черезмерно увлекся синхронизациями. Насчет различия между object flow и transition line - как-то смутно. Не могу различить где у меня одно, а где другой. Подозреваю, что в Power Designer, к которму я привык, это назвается Flow/Resource Flow, но в целом у меня здесь туман...
Вот слегка исправленная версия:


Наибольшее затруднение вызывает как показать, что сообщение может как поступить на обработку, так и быть просрочено...

Наибольшее затруднение вызывает как показать, что сообщение может как поступить на обработку, так и быть просрочено...

Может быть у Службы контроля есть два потока работ - "обработка входящей информации (С формулированием замечаний)" и "анализ (контроль) устранения замечаний (включая сроки)", которые могут выполняться параллельно? Хотя второй поток и "питается" от первого, но  информация об устраненных замечаниях не попадает снова в пакет "входящей информации" и не анализируется заново? 
Возможно, имеет смысл параллельно рисовать диаграмму с указанием состояний документа (но не пытаться вместить это на диаграмму деятельностей). Тогда и с этой диаграммой (деятельности) будет больше ясности.

Shur

но  информация об устраненных замечаниях не попадает снова в пакет "входящей информации" и не анализируется заново?

Информация об устраненных и не попадает во входящие. Туда попадает информация о неустраненных. Служба контроля получает ответ (информацию) от подразделений - но она должна проверить, действительно ли замечания устранены?
Что касаемо параллельности обработки - в принципе, примерно да.
Разносить на отдельные диаграммы не хотелось бы, т.к. состояния документа напрямую связаны с деятельностью.
Вот как показать на диаграмме, что просрочка может быть как у непринятых замечаний, так и у тех, что на обработке - пока не знаю...

Попробуйте использовать событийный механизм ...

Вот как показать на диаграмме, что просрочка может быть как у непринятых замечаний, так и у тех, что на обработке - пока не знаю...

Проблема в том, что нельзя различить, пытались ли пользователи устранить адресованное им замечание или просто "забили"?   С точки зрения изображения этого на диаграмме все очень просто:) : нужно нарисовать квадратик действия или ромбик события, который соответствует установлению того факта, что именно пользователи делали с замечанием в отведенные им сроки. И присвоить замечанию по результату этого действия/события статус "саботировано" или "не успели". Правда, скорее всего после этого потребуется еще один квадратик - проверка того, что служба контроля сама не забыла осуществить это контрольное действие.

Shur

Проблема в том, что нельзя различить, пытались ли пользователи устранить адресованное им замечание или просто "забили"?
...И присвоить замечанию по результату этого действия/события статус "саботировано" или "не успели".

Не-не-не. Различать саботаж от несознанки не надо. Не успели - все, неважно по какой причине, неважно брались за устранение или нет.
Замечание может: 1) быть принято и устранено в срок, 2) быть не принято и не устранено и 3) быть принято, но не устранено в срок. Разилчичать последние два случая непринципиально. Вот как все это визиализировать без кучи ромбиков - которые загромождают диаграмму - что-то не получается.
Юрий Булуй

Попробуйте использовать событийный механизм ...

Попробовал ARIS Там все красиво. Схему сейчас привести не могу, к сожалению.

Событийный механизм можно использовать и в UML, не только в ARIS. В UML 2.0  есть штатные средства для описания событий и реакции на них. И если даже инструментарий не поддерживает такой возможности -- всегда можно использовать стереотипы.

В UML 2.0 диаграммы видов деятельностей по сути представляют собой сети Петри. Сети Петри работают на событиях и правилах перехода, т.е. деятельность сама по себе есть условие возникновения события, а потоки управления - собственно событием.