Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Четыре группы описаний жизненного цикла в PraxOS

Для того, чтобы описывать жизненный цикл, PraxOS требует как минимум четырех групп описаний, адресующих интересы различных сторон:

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

2. Инженерная (трансформационная, процессная) группа описаний, задающая технологический процесс -- кооперативную (из актов деятельности) схему в терминах указания традиционных для процессов входных и выходных продуктов и сведений, а также выполняемых преобразований. Метамодель и нотация в BPMN, плюс нормы в SBVR с нотацией в контролируемом языке.

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

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

Подробнее про важность первых трех групп описаний см. презентации http://www.slideshare.net/ailev/ss-presentation-615257 (двухлетней давности) и http://www.slideshare.net/ailev/ss-2290189 (месячной давности), плюс свежайший обзор http://www.techinvestlab.ru/586456.

Объединение всего этого зоопарка метамоделей можно устроить при помощи шаблонов и OIM ISO 15926 (а не UML). Вовсе необязательно при этом разворачивать все эти описания вокруг SPEM 2.0 или ISO 24744, но из них можно взять много интересного и полезного. Например. из ISO 24744 можно взять интересную нотацию, позволяющую организовать многоаспектное представление жизненных циклов: http://isotc.iso.org/livelink/livelink/fetch/2000/2122/327993/755080/1054034/2541793/JTC001-N-8628.pdf?nodeid=6558555&vernum=0. Так что, скорее всего, итоговую метамодель придется делать самим, не забывая кроме онтологии еще о лексике и нотации. Подробности в http://ailev.livejournal.com/761744.html.

Где взять моделер, который поддерживает (меняя лексику по потребности, и в удобных нотациях!) все эти 4 группы описаний? Скорее всего, сделать самим, используя инструменты типа платформы Whole (ключевые слова -- DLS, language workbench) -- подробности в http://ailev.livejournal.com/760577.html.

Как эти описания жизненного цикла доводить до сведения выполняющих workflow самых разных САПР (а не только до сведения людей-работников)? Скорее всего, через прикрутку софта IRING (http://iring.ids-adi.org/repository/org/ids-adi/camelot/index.html) к моделеру на платформе Whole.

Такое решение позволяет использовать нестандартную метамодель, обеспечивая стандартную функциональную совместимость (interoperability) по ISO 15926 (как работает ISO 15926 -- см. https://www.posccaesar.org/wiki/ISO15926Primer).

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

Конечно, это все верно только для описаний жизненного цикла, и пока ничего не говорится про организацию-enterprise, в которой добавятся:
-- описание функциональной (подразделения) инфраструктуры (полномочия-поручения, но уже линейных менеджеров)
-- описание персонала (навыки и умение, работа по обучениюи т.д.)
-- описание инфраструктуры (сервисы -- метамодель SOA, чтобы это в общем неайтишном случае ни значило).
-- финансы
-- цели (стратегия), показатели и т.д.
-- и много чего еще

В принципе, в ситуационной инженерии методов доводят идею, витающую в воздухе про "предприятие -- это такой большой проект с эволюционным жизненным циклом, когда на каждой стадии мы не знаем, какие требования следующего этапа" до конца: метамодели ISO 24744 и OPF предлагают считать endeavour ("предприНятие" ;) как проекты, из которых составлена программа (множество проектов на общих ресурсах и под общим управлением), из которых составлено предприятие-организация (множество программ на общих ресурсах и под общим управлением). Но с этим еще нужно специально разбираться.

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

UPDATE: Английский пост на эту же тему -- http://levenchuk.com/2009/12/04/situational-method-engineering-and-life-cycle-modeling-roadmap/
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 5 comments