Семантический каталог (компонент) методов и софт для его использования
Семантический каталог (компонент) методов -- по аналогии с каталогами комплектующих/предметов снабжения для промышленного оборудования -- представляет собой структурированное в соответствии с метамоделью ISO 24744 описание набора связанных между собой компонент методов набора каких-то дисциплин, выполненное в формате RDL ISO 15926 (поэтому семантический -- в смысле "его информация понятна компьютеру"). Больше всего по содержанию это может быть похоже на http://opfro.org, основные различия в формате, подразумевающем не столько "чтение человеком", сколько доступ со стороны других приложений.
Не вдаваясь в технические подробности, приведем тут ряд сценариев использования такого каталога в формате RDL:
1. Методологи, изучающие методы какой-то дисциплины (например, дисциплины системной инженерии), пользуясь Верстаком (method workbench), коллаборативно пополняют набор компонент методов этой дисциплины, связывает шаблоны работы с шаблонами возможных продуктов работ и делает прочие операции, приводящие к созданию актуализированного набора компонент методов.
Для этого сценария нужно реализовать софт Верстака.
2. Студенты, изучающие методы какой-то дисциплины, пользуясь Читальней (вики-вебсайтом, полученным публикацией компонент методов из RDL-каталога), изучают текущее состояние этой дисциплины.
Для этого сценария нужно реализовать софт Читальни.
3. Основной сценарий, предлагаемый сторонниками ситуационной инженерии методов: используя Составитель (Method Composer), отбираются компоненты метода для конкретного проекта. А потом уже данный "метод проекта" публикуется для сценария 2 -- чтобы быть справочником по методу для всех участников проекта.
Для этого сценария нужно реализовать софт Составителя.
Но я не думаю, что этот сценарий главный. Представьте, что у вас есть толстый учебник "Системная инженерия", из которого вам нужно вырвать ненужные страницы для того, чтобы остаток раздать вашим работникам в качестве руководства к действию. Страницы-то вырвать можно, а с мыслями там что делать? Что-то такой вариант меня не греет (хотя и используется в больших компаниях для постановки "процессного управления", плодя варианты RUP на EPF Composer).
Пусть весь мир идет этим путем, мы не будем этим заморачиваться. Это путь в тупик, в порождение толстых пачек "описания процессов" без малейшей связи с производственной реальностью (хотя я охотно верю, что где-то есть Очень Дисциплинированные Исполнители, которые могут в военно-приказном порядке все это использовать на деле -- но мне даже неинтересно в этом направлении работать).
4. Инженеры, которым нужно выполнить некоторый проект, используют Читальню из сценария 2, но в режиме "активного эссе" (http://ailev.livejournal.com/466004.html, и чуть более развернуто в http://ailev.livejournal.com/810126.html). Это означает, что все ВидыМоделей-из-Читальни работоспособны и могут порождать конкретные модели. Тем самым речь идет не столько о Читальне, сколько о Писальне -- это уже не столько Читальня Учебников, сколько Библиотека Рабочих Тетрадей с Хелпами к ним. Если компонента метода описывает какой-то ВидМоделей, то инженеру-пользователю можно породить экземпляр этой модели и работать с этим экземпляром. Рабочая Тетрадь при этом подтягивает Справочные Данные из RDL (как типографская Рабочая Тетрадь, в которой что-то уже преднапечатано в типографии), а данные моделирования оставляет при себе (как вписывание ручкой в типографскую Рабочую Тетрадь).
И верстать/составлять нужно не "компоненты метода", а экземпляры используемых моделей, оставляя связанные с ними компоненты метода в качестве Хелпа (еще раз напомню про http://ailev.livejournal.com/810126.html)!
Про workflow/lifecycle/project, который ведет инженера через заполнение этой Рабочей Тетради я пока молчу, это мне представляется не главным. Как правильно заметил Cesar Gonzales-Perez, пул продуктов важнее, и софт нужно организовывать вокруг поддержки него, а не поддержки воркфлоу. Как будет устроен тамошний issue tracker можно будет понять позднее).
Для этого нужно реализовать софт Писальни -- Рабочей Тетради Модельера/Инженера/Организатора (инженера -- если модели "железной" системы; организатора, если речь идет об организационной модели).
Итого: нужно делать Каталог-RDL (невидимый простым человечьим глазом, а видимый только как endpoint из semantic web), Верстак, публичную Читальню и затем коллаборативную Писальню (Рабочую тетрадь модельера).
Не вдаваясь в технические подробности, приведем тут ряд сценариев использования такого каталога в формате RDL:
1. Методологи, изучающие методы какой-то дисциплины (например, дисциплины системной инженерии), пользуясь Верстаком (method workbench), коллаборативно пополняют набор компонент методов этой дисциплины, связывает шаблоны работы с шаблонами возможных продуктов работ и делает прочие операции, приводящие к созданию актуализированного набора компонент методов.
Для этого сценария нужно реализовать софт Верстака.
2. Студенты, изучающие методы какой-то дисциплины, пользуясь Читальней (вики-вебсайтом, полученным публикацией компонент методов из RDL-каталога), изучают текущее состояние этой дисциплины.
Для этого сценария нужно реализовать софт Читальни.
3. Основной сценарий, предлагаемый сторонниками ситуационной инженерии методов: используя Составитель (Method Composer), отбираются компоненты метода для конкретного проекта. А потом уже данный "метод проекта" публикуется для сценария 2 -- чтобы быть справочником по методу для всех участников проекта.
Для этого сценария нужно реализовать софт Составителя.
Но я не думаю, что этот сценарий главный. Представьте, что у вас есть толстый учебник "Системная инженерия", из которого вам нужно вырвать ненужные страницы для того, чтобы остаток раздать вашим работникам в качестве руководства к действию. Страницы-то вырвать можно, а с мыслями там что делать? Что-то такой вариант меня не греет (хотя и используется в больших компаниях для постановки "процессного управления", плодя варианты RUP на EPF Composer).
Пусть весь мир идет этим путем, мы не будем этим заморачиваться. Это путь в тупик, в порождение толстых пачек "описания процессов" без малейшей связи с производственной реальностью (хотя я охотно верю, что где-то есть Очень Дисциплинированные Исполнители, которые могут в военно-приказном порядке все это использовать на деле -- но мне даже неинтересно в этом направлении работать).
4. Инженеры, которым нужно выполнить некоторый проект, используют Читальню из сценария 2, но в режиме "активного эссе" (http://ailev.livejournal.com/466004.html, и чуть более развернуто в http://ailev.livejournal.com/810126.html). Это означает, что все ВидыМоделей-из-Читальни работоспособны и могут порождать конкретные модели. Тем самым речь идет не столько о Читальне, сколько о Писальне -- это уже не столько Читальня Учебников, сколько Библиотека Рабочих Тетрадей с Хелпами к ним. Если компонента метода описывает какой-то ВидМоделей, то инженеру-пользователю можно породить экземпляр этой модели и работать с этим экземпляром. Рабочая Тетрадь при этом подтягивает Справочные Данные из RDL (как типографская Рабочая Тетрадь, в которой что-то уже преднапечатано в типографии), а данные моделирования оставляет при себе (как вписывание ручкой в типографскую Рабочую Тетрадь).
И верстать/составлять нужно не "компоненты метода", а экземпляры используемых моделей, оставляя связанные с ними компоненты метода в качестве Хелпа (еще раз напомню про http://ailev.livejournal.com/810126.html)!
Про workflow/lifecycle/project, который ведет инженера через заполнение этой Рабочей Тетради я пока молчу, это мне представляется не главным. Как правильно заметил Cesar Gonzales-Perez, пул продуктов важнее, и софт нужно организовывать вокруг поддержки него, а не поддержки воркфлоу. Как будет устроен тамошний issue tracker можно будет понять позднее).
Для этого нужно реализовать софт Писальни -- Рабочей Тетради Модельера/Инженера/Организатора (инженера -- если модели "железной" системы; организатора, если речь идет об организационной модели).
Итого: нужно делать Каталог-RDL (невидимый простым человечьим глазом, а видимый только как endpoint из semantic web), Верстак, публичную Читальню и затем коллаборативную Писальню (Рабочую тетрадь модельера).