Work.дыбр

[dzz]

Изучаю наработки IDS Scheer / ARIS, BPMI и OMG на тему методологий представления бизнес-процессов.

Три нифига не стыкующиеся между собой языковые спецификации... Чувствую себя пророком ;)

Comments

[(Anonymous)]

Ну, скромной я такую задачу не назвал бы. Честно говоря, мне всегда казалось, что термин реверс-инжиниринг подразумевает извлечение данных из уже созданных систем, а если системы нет, то, о каком реверс-инжиниренге может идти речь? Если это данные анкетные, то мы сталкиваемся с огромным массивом неструктурированной информации, тогда мне не понятно каким образом это можно автоматизировать, а если и можно, то уж точно не скромно.
Что касается нотаций, то опять же, смотря, какая цель, лично я приверженец стандартов, и если есть необходимость в построении workwlow и использовании новомодных языков бизнес-процессов, а на сколько я понял ты и хочешь как раз видеть именно язык, типа BPEL или BPML, то лучше выбирать тот, у которого объективно есть будущее. А зачем тебе, кстати, открытый язык? На сегодняшний день, вся проблема то и заключается в том, что никто договориться не может, те же FWMC, BPMI, OMG и IBM с SAP да с Microsoft только и делают, что стандарты пытаются свои продвинуть, от этого страдает экономика в целом. На мой взгляд, в науке об автоматизации и управлении бизнес-процессами стандартизация и унификация приносит только пользу.

[(Anonymous)]

Насчёт "скромной задачи" я, конечно, поскромничал. Задачка достаточно объёмная.
Реверс-инжиниринг - это восстановление описаний из собранных данных.

Источник данных в данном случае достаточно специфический - это хранилище (data warehouse) информации комплексных обследований, структура которого сейчас проектируется. Кроме данных по бизнес-процессам там будут, к примеру, данные CMM (Common Maturity Model) и т.п. Структуризация и верификация данных - задача, решаемая на фазе построения хранилища. Средства моделировния БП тут несколько сбоку, сама система - "базоцентрическая".

Под открытостью я имел в виду не открытый код, а наличие у продукта открытых интерфейсных спецификаций (форматы данных, API), позволяющих решить две задачи:

1. Правильно сформировать описание БП, понимаемое средством моделирования/визуализации

2. Получить описание БП от системы моделирования/визуализации в виде набора объектов, атрибутов и связей, понимаемых софтом со стороны хранилища.

Само собой, спецификация не должна кардинально меняться с каждой версией и поддерживаться в течение обозримого времени. Лучше, если несколькими продуктами. Ещё лучше - если кроссплатформенно.

Унификация - это замечательно.