Обсуждение

Анатолий, спасибо за насущную тему! Интересно узнать Ваше мнение, вдогонку: 1. Процессы vs. Функции Мне удалось найти только в ArchiMate ситуацию, в которой создатели: -- одновременно выделяют оба концепта (еще и сервисы потом вводят) -- явно отделяют их друг от друга Семейство IDEF (0, 3), наверное, не в счет. А где еще задумываются о разнице, рассматривая и то, и другое одновременно? 2. Функции и цели -- можно ли свести функциональную декомпозицию, которую Вы упомянули, к структуре целей (видимо, в этом контексте -- objectives)? 3. Процесс как последовательность смены состояний -- еще одна трактовка, из физики/математики. Она укладывается в Ваш пункт 3 (BPMN-like)? 4. Дополнение про экземпляры Известно два взгляда на процессы -- как на поток экземпляров и как на трубопровод в целом. К примеру, в программной реализации workflow в явном виде есть понятие экземпляра. Понятно, что, в итоге, все всему изоморфно. Но можно ли считать, то workflow-идеология -- это экземпляры, а SE-подход (практики) -- это, как раз, про деятельность вообще?

Вопросы, которые вы задаёте, очень интересны -- и на каждый из них можно отвечать долго и пространно (но, увы, это не формат комментов в ЖЖ). 1. Процессы (физические работы, "конструкция") против Функций (логические работы) -- это традиционное архитектурное разделение. В одном случае указывается назначение (цель), но не делается никакой связи с физической реализацией (неважно, речь идет о физической работе или вещи), а в другом случае как раз указывается на что-то, из чего можно создать конструкцию. ArchiMate это прихватил из DEMO, ибо Jan Dietz много и долго занимался архитектурой в связи с enterprise engineering, и у него диаграммка различий "функция-конструкция" принципиально важная. Есть много разных традиций разговора на эту тему. Так, в системной инженерии многие школы призывают обсуждение функций максимально дистанцировать от обсуждения конструкций (т.е. что делать обсуждать отдельно от вопроса как делать). А есть прямо другой подход: "функциональный физический объект" и "физический объект" в ISO 15926 связаны как 1:1 (то же в RLFP подходе ENOVIA, где всегда можно выделить "функцию" на 3D модели). При ближайшем разбирательстве выясняется, что у слова "функция" пять разных значений, и начинаются нюансы... Так что вся архитектурная традиция рассматривает и "функции" и "конструкцию", и "работы" тут просто частный случай. 2. Да, функциональная декомпозиция вполне представима как декомпозиция целей. Только функциональная декомпозиция обычно связывается с "назначением" (purpose), а слово "цель" имеет некоторые другие оттенки смыслов (и в орг.инженерии его передают иногда даже не как objective, а как motive -- ср. Busniess Motivation Model, OMG BMM). На практике это, конечно, всё страшно путается: цели, назначения, функции, задачи... Терминология существенно зависит от "школы мысли", и тут все школы путаются по своему :-) 3. Традиция процесса, как последовательности смены состояний распространена только в среде программистов, а в оргпроектировании по факту не применяется. Но вы правы, среди программистов этот подход крайне популярен. Поглядите на разнообразие стандартов, это всё только "разный XML": http://xml.coverpages.org/bpm.html -- и там формальных машин состояний много. Конечно, этот подход и BPMN 2.0 родственники, вплоть до неразличимости (формально там, кажись, до сих пор сам движок -- BPMS -- работает как машина состояний). 4. Я обычно говорю так, что "в учебниках по воркфлоу нет экземпляров, но есть в документации к софту. В учебниках по проектам нет шаблонов, но есть в документации к софту". Так что ответ на вопрос зависит от того, софт вы рассматриваете, или "теорию" :-) Но есть еще более правильный ответ: подумайте еще и над "различалками" из ISO 24744 -- там WorkKind и Work связаны через Powertype pattern. Т.е. отношение между ними -- класса и экземпляра, и оба рассматриваются и "в реализации", и "в теории". Это и есть правильный подход: не "или", а "и". Обязательно (и в учебниках, и в софте) рассматривать и классы, и экземпляры -- что, правда, не соответствует традиции "процессников ISO 9000" и "проектников PMBoK". Но мы-то понимаем, в чем фишка, и поэтому плохую традицию игнорируем, равно как и изготовители соответствующего софта.

Спасибо за наводки, куда копать дальше. Про формат комментариев я понимаю, просто тема про "моделирование "процессов"" очень больная.

Нестандартный взгляд на моделирование процессов. т.е. взгляд со стороны. В любом случае - интересно и познавательно. >> Когда вам поручают "моделировать процессы", поинтересуйтесь, >> какие именно "процессы" имеются ввиду, и какого сорта >> решения планируется принимать по этим моделям. Логика конечно правильная, но ... Вы серьезно думаете, что на этот вопрос кто-то даст ответ? Как правило здесь встречный вопрос вызывает у заказчика модели лишь раздражение и сомнения в профессионализме специалиста по моделированию. Типа - сам должен догадаться.

Действительно, мне как бизнес-аналитику, было интересно увидеть подход к моделированию сболее технической стороны - спасибо автору. Мне приходилось моделировать на разных кейсах, и освоение инструмента моделирования никогда не шло ни в какое сравнение с решением задач выделения элементов и связей процессов. Поэтому ,соглашаясь с советом автора: "Когда вам поручают "моделировать процессы", поинтересуйтесь, какие именно "процессы" имеются ввиду, и какого сорта решения планируется принимать по этим моделям", я могу порекомендовать пост о подходах к выделению процесса http://www.manager-activity.ru/2010/05/pravilny-process.html