Проблемы интеграции методов должны быть похожи на проблемы интеграции данных: те же различения мета-мета-модели, мета-модели, модели и экземпляров, те же проблемы разных уровней детальности описания, те же проблемы называния одинаковых объектов разными именами и разных объектов одинаковыми именами.

Еще недавно репозиториев (библиотек типовых методов, reference method library) не было, а сегодня их полно -- строгие вокруг тех или иных метамоделей (библиотеки в формате SPEM, или OPFRO)
-- нестрогие в форме PMBoK, BABoK и прочих ITIL.

Интересности начинаются, когда нам требуется исполнение методов (enactment): интеграция должна быть не только на уровне описания библиотеки методов или собранного из библиотеки одного "типового", но и на уровне описания порожденного этим типовым методом процесса -- каковой процесс (workflow) должен будет исполняться машинами и людьми в расширенном предприятии (extended enterpise).

И тут, я думаю, может помочь ISO 15926 с его подходом к интеграции данных, включая архитектуру RDL. Аналогии есть, и они более чем глубокие. Поэтому ISO 15926 может выступать как один из инструментов такой интеграции методов, равно как и образец архитектуры интеграции.

Жизнь устроена так, что все новые и новые библиотеки типовых методов будут кодироваться во все более и более формальном виде, и нельзя ожидать, что где-то появится Главная Библиотека. Скорее, должна появиться какая-то онтология методов, которая позволит затем делать мэппинг к этой библиотеке для всех других методов.

Поэтому у PraxOS может быть разные судьбы:
-- репозиторий методов, такой же, как OPFRO, только русскоязычный и другой по составу (например, в нем будут методы Голдратта). Но лучше сразу вступить в OPEN Framework Repository Organisation, и просто добавлять методы туда.
-- особое внимание к задаче интеграции методов и перехода к автоматизированному исполнению методов. Тогда PraxOS может выступать в качестве reference method library так же, как RDL в ISO 15926 (а в RDL ISO 15926 будет упихнут значительный кусок онтологии предметной области методологии).

По-английски на эту тему я высказался тут: http://levenchuk.com/2009/12/17/situational-method-engineering-reference-method-library-as-a-way-to-methodworkflow-integration/

Земля пухом

Tags: r.i.p., Музыка к фильмам

Первая из строящихся технологических пирамидок будет маленькой (и, надеюсь, поэтому быстровозводимой). Все названия условные, уровень исполнения -- "на коленке":

1. Все желающие поучаствовать ставят себе Protege, закачивают туда ISO 15926-2,4 и разбираются с ISO 15926-7,8. Это у нас будет развернута среда онтологического моделирования с накоплением знаний (Protege используется вместо привычного для всех UML или ER моделера).

2. Потом туда как-то добавляется метамодель ситуационной инженерии методов ISO 24744 -- чтобы подготовить возможность работать с репозиториями методов типа PraxOS, OPFRO и прочими Body of Knowledge (foxtreme).

3. Для тестирования получившегося добавляется содержимое вебсайта www.opfro.org (piter239)
-- содержимое сайта парсируется, чтобы получились данные хоть в каком-то удобном для обработки формате, а не нынешние html-страницы
-- содержимое сайта подводится под сделанную на шаге 2 метамодель (при этом, возможно, метамодель расширяется) в формате хранения данных этой
-- содержимое сайта помещается в среду, позволяющую его удобно редактировать (скорее всего, Protege) и публиковать в виде вебсайта (скорее всего, публикационный плагин к Protege)

4. Русификация:
-- метамодель методов (итог шага 2) расширяется, чтобы учесть возможность перевода на русский и другие языки.
-- содержимое OPFRO начинает переводиться на русский

5. Делается метамодельный механизм (Reference Method Library, по архитектуре, максимально приближенной к ISO 15926 RDL), позволяющий различать оригинальное содержание OPFRO, содержание PraxOS и устраивать различные варианты гибридизации содержания (пополнение OPFRO из репозитория PraxOS и обратно). Это обеспечит международное партнерство методологов и инженеров методов. Больше RDL/RDM хороших и разных -- больше "песочниц" (sandbox из проекта IRING, чтобы онтологические эксперименты можно было вести, не мешая другим).

6. Заводится песочница RDL/RDM PraxOS и пополняется наработанным на настоящий момент содержанием методов (Голдратовщина и т.д.) -- кодирование методов (vvagr).

Ветвь: курс на автоматизированное исполнение предполагает следующие шаги, которые могут начинаться после шага 2 (foxtreme):

3. Добавить в RDL PraxOS метамодель BPMN 2, чтобы иметь возможность детального моделирования процессов.

4. Добавить метамодель сервисов, чтобы было описание той инфраструктуры, которая обеспечивает выполнение всех конкретных (ситуационных) методов-процессов-проектов.

Ветвь: курс на то, чтобы этим все могли пользоваться тоже может начинаться после шага 2:

3. Реализовать method composer на базе какой-то из language workbenches (Whole или ConceptBase).
-- реализовать презентационные нотации (например, нотация ISO 24744) для методов.

4. Выполнить моделирование деятельности и инфраструктуры какого-то КонкОрг, чтобы подтвердить всю концепцию -- с использованием репозитория методов и метод композера (никакого автоматизированного выполнения, только картинки для обеспечения общего понимания и "справочный вебсайт").

Ссылки и объяснения использованных терминов не даю, все это уже обсуждалось у меня в блоге: кому интересно, тот все уже понял и заинтересовался. Русскоязычных материалов по этой проблематике пока нет. Кто еще хочет поучаствовать (бескорыстно), you are welcome (пришлите мне письмо, а я отвечу с приложением материалов, которых нет в открытом доступе).

Эти ближайшие планы, конечно, не отменяют других дел и планов, а также подлежат ежемесячному, еженедельному, ежедневному и ежечасному пересмотру, но мультитаскинг (как минимум, свой) я все-таки буду стараться удавливать.

За $99 можно уже сегодня получить(в магазине http://www.cherrypal.com):

The 7" Cherrypal was designed with developing countries in mind. The Africa is powered with an 400 MHz processor, 256 MB DDR / 2 GB NAND-flash and runs Linux (GMo) or Windows CE. Here are some more basics: Screen: 7 inch high-resolution TFT .(800 x 480 pixels) LAN:10/100M Ethernet Access WIFI: IEEE 802.11 b/g Ethernet RJ-45 Keyboard: QWERTY 86 keys Mouse&Touch pad:build-in touch panel, set two shortcut key,and support usb port mouse USB Port: USB 2.0 x 1 (aid external memory) USB 1.1 x 2 (aid keyboard & mouse only) External Memory : SD card , U-Disk , USB-HDD Card port: SD / MMC card slot (8GB) Battery: 7.4 V 1800Mha built in Lithium battery 1800MAH Last time:4 HRS Sound effect:build-in realtek sound effect chipset, Built in 2 x 0.5W Built in speaker 1 x microphone Weight:1.2kg Size: 213.5 x 141.8 x 30.8 mm

В качестве моделера для ISO 15926 Онно Паап рекомендует использовать Protégé (http://protege.stanford.edu/) и OWL в манчестерском синтаксисе (http://www.co-ode.org/resources/reference/manchester_syntax/, поддерживается версией 4 Protégé) -- а затем поступать так, как написано в ISO 15926-7,8 (то есть работать с шаблонами).

Страничка с онтологией (части 2 и 4 стандарта) в OWL -- https://www.posccaesar.org/wiki/ISO15926inOWL

Вдруг кому нужно -- на http://www.bpmn.org/ выложен текст BPMN v2.0 Beta 1 (похоже, что это версия середины августа 2009, а выложена где-то 20 октября, судя по properties файла).

BPMN (версии 1.0) по состоянию на 24 сентября 2009г. имела 61 реализацию и еще 4 запланированных.

Оно, понятно, что это ненастоящий суперкомпьютер (из NVIDIA GTX295), но бельгийцы собрали настольный блок о 12 терафлопсах за 6000 евро, самый мощный десктоп в мире -- http://fastra2.ua.ac.be/ (там и видео есть).

Куда девать такую мощь? Вычислять ненужное! Используется этот десктоп для 3D-томографии костей (повысили на тех же данных разрешение вдвое за счет того, что увеличили вычислительную мощность в восемь раз). Поглядел я на видео в примере, и понял: -- в основном там считаются данные, которые никогда и никому не понадобятся, их никто никогда увидеть не сможет, кроме крошечных кусочков.

Я, конечно, все хорошо понимаю про голографию, томографию и прочие технологии, основанные на утверждении, что "все со всем связано, в каждой капле отражается весь мир". Ну да, сегодняшние алгоритмы таковы, каковы они есть. Нужно менять алгоритмику: требуется что-то придумывать с алгоритмами (или их использованием в вычислителе, что не сводится к замене алгоритма, а уже относится к инженерии), чтобы вычислять только то, на что сейчас смотрим -- и с тем разрешением, с каким сейчас смотрим. Если смотрим на кость, то вычислять с разрешением не бОльшим, чем пикселей на экране в этой кости. Ежели микроструктуру кости -- то вычислять не бОльший кусок микроструктуры, чем на том же экране помещается. Ежели мы это не смотрим, то и вычислять не нужно. А дальше, как с веб-картами: если двигать-зуммировать, то вычислять только то новое, что еще не вычисляли. Это будет быстро, "на лету".

В САПР была та же самая задача: какая-нибудь подводная лодка с 4млн. деталями не хотела быстро крутиться на экране -- пока Dassault Systemes V6 не придумала вынимать из базы, рендерить (переводить данные в визуальную форму) и дальше уже крутить только то, что на этом экране помещается. Если вся лодка, то на экране крутится лодка -- винтики в ней не крутятся, их все равно не видно. Если вы сделали зум такой, что стали видны винтики, то тогда крутятся только винтики, а лодки уже не видно, и все лишнее из вычислений для отображения изымается.

У веб-разработчиков такой прорыв был с AJAX -- как и в САПР, в революция произошла именно в тот момент, когда Google в своем почтовом интерфейсе стал обмениваться с сервером не целыми страницами, а только теми кусками, которые прямо сейчас нужны. Все необходимые решения в стандартах, серверах и браузерах к тому моменту уже давно (несколько лет как) присутствовали, но нужно было систематически провести эту идеологию в жизнь. И тут же скорости уже имеющихся каналов и производительности уже имеющихся компьютеров стало хватать для более-менее приличной работы, ранее доступной только в варианте толстых клиентов и локальной базы данных.

Точно так и тут. Не нужны алгоритмы, которые восстанавливают всё. Нужны алгоритмы и способы их вызова, которые восстанавливают только то, что можно посмотреть "на лету" -- и с тем разрешением, которое можно разглядеть. Хотя запрограммировать такое будет явно дороже, чем купить 12терафлопс в настольном исполнении -- зато потом можно будет использовать массово, иметь сканеры чуть ли не в телефонах.

Выполнение (enactment) метода в предприНятии (endeavour, проект/программа/организация) является существенным концептом современной ситуационной инженерии методов, в которой метод существует на трех уровнях абстракции: метамодель, методология (набор фрагментов и их связей) и конкретное предпринятие.

Чем инструменты ситуационной инженерии методов лучше инструментов управления бизнес-процессами (workflow+business rules) или инструментов управления проектами?
1. Особое внимание уделяется накоплению знаний, в том числе и неформализуемых (guidance). Поэтому в поле внимания и поддержки попадает конструирование процессов/методов из шаблонов, а не "с нуля". Выделению повторноиспользуемых шаблонов уделяется значительное внимание -- в том числе и путем использования шаблонов высокого уровня абстракции (репозиториев методов).
2. Особое внимание используется обучению людей (хелпы, описания продуктов работы и т.д.), "встроенная документация по процессу/проекту".
3. Управление процессами и проектами обычно в разных инструментах, требует разных групп описаний (на PERT не видны продукты, в BPMN трудно со стадиями и контрольными точками -- хотя в свежей версии это может быть, уже и снято, нужно проверить). В любом случае, традиционные инструменты управления процессами/проектами несбалансированы для различных (инженерной, менеджерской, клиентской, организационной) групп описаний.
4. Существенный упор на группы описаний продуктов работы, команды людей и инструментов, а не только группу описаний процесса-проекта: подразумевается модель деятельности, а не только процесса/проекта.
5. Поддерживает постепенное создание метода (emergent process -- https://openair.rgu.ac.uk/bitstream/10059/220/1/Allison+and+Merali+ISTJ+paper+final.pdf).
7. Есть тенденция к объединению достоинств традиционного процессного подхода и ситуационной инженерии методов (например, SPEM+BPMN).
8. Тоже стандартизовано, но поскольку "процесс" рассматривается как шаблон, то выразимы более сложные случаи, нежели в традиционных проектах-процесссах (например, для ISO 24774 http://www.pa.icar.cnr.it/cossentino/AOSETF08/docs/UnisconKeynote.ppt):
( тут большая картинка примера нотации ISO 24744 для enactment )
Примеры систем, которые как-то учитывают (или не учитывают) дальнейшее исполнение кастомизированного метода (инструмент+репозиторий):

( четыре системы )

Новый логотип Сбербанка - это ребус-сообщение от власти народу.

У меня уже есть своя версия. А у вас?

Прекратить рожу брить штоле? ггг

Tags: ethnic, Бодро-настойчивая музыка, Кавер-версии