avigdor по возврату навара в мировой бульон (http://ailev.livejournal.com/730523.html). Похоже, что наваристость этого бульона таки удалось чуть-чуть поднять -- некоторые наши предложения были услышаны и признаны интересными лидерами нескольких профессиональных сообществ, которые до этой конференции практически не слышали друг о друге.Ниже заметочки для памяти:
1. Все подходы INCOSE к созданию "рабочей группы по онтологии системной инженерии" бессмысленны. Онтология нужна только тогда, когда идет разборка с методом ("дискуссия о методе"), при этом сначала нужно разобраться с онтологией самого метода -- иначе эта дискуссия будет просто размахиванием руками. Когда разобрались, что такое метод, нужно будет описать компоненты метода таким образом, чтобы из этих компонентов можно было собирать метод сообразно ситуации -- и в этот-то момент и понадобится онтология, чтобы представлять эти компоненты метода. Поэтому в INCOSE нужно создавать рабочую группу по методу, используя формализм ситуационной инженерии методов, и только после этого будет осмысленна рабочая группа по онтологии.
Увы, текущие методические работы INCOSE (например, BKCASE, или работа с Handbook) не были в достаточной мере озабочены ни методом, ни (поэтому) онтологией. Тем самым все "онтологические инициативы" INCOSE были обречены на неудачу -- от разговоров про онтологию к делу перейти было нельзя теоретически, что и наблюдалось.
Если сама системная инженерия становится моделе-ориентированной и основанной на семантике, то и ее описание должно быть таким же -- именно так нужно воплощать в жизнь "инженерию системной инженерии". Уж точно "врачу, исцелися сам".
2. Задача представления метода как набора используемых по ситуации компонент по сути сводится к задаче создания каталога компонентов методов (по аналогии с каталогом комплектующих -- http://community.livejournal.com/praxos/9600.html). Каталог методов -- это RDL в их федерации. То есть http://opfro.org нужно
а) представить как каталог методов в формате RDL (для чего перевести в OWL для сохранения имеющейся в нем структуры, потом переформатирования для удовлетворения метамодели ISO 24744, а уже затем переформатирование в OWL части 8 ISO 15926).
На втором шаге содержимое OPFRO (которое представляет собой "текущую системную инженерию образца 2010") нужно заменить содержанием системной инженерии образца 2020, заодно дополнив описанием продуктов, моделей, языков и т.д. (это будет уже вполне возможно, ибо к этому моменту в RDL у нас будет вполне онтологическое представление).
Для успеха проекта нужно три человека: один знает, как что-то делать (например, Ян Александер знает, как проводить моделе-ориентированную инженерию требований), второй способен представить это знание как метод (т.е. у него в голове метамодель ISO 24744 -- например, Дональд Файерсмит), а третий способен это все единообразно представить в RDL (например, Ян Глендиннинг).
Теперь нужно заменить иностранные имена отечественными, что вполне возможно. И обзавестись инструментарием, которого по факту нет и у иностранных товарищей.
3. Обсуждался вопрос, может ли победить концепция федерации RDL против RDL-со-спайдером? Когда-то на заре интернета я делал "федерацию поисковых машин" и в ней было что-то около 16 вебсайтов в пике ее развития. Поиск там был ужасный (медленно, разные сайты регулярно отваливались, развитие зависело от уговоров всех вебмастеров -- типичная "система систем"). Потом пришли поисковые системы-с-пауками (lycos, altavista и в конечном итоге -- google). И "федерации" поисковиков закончились: был найден способ превращения "системы систем" в "просто систему".
Так что я бы задумался над созданием RLD-спайдера (то бишь RDL-гугля/яндекса, зависит от того, кто раньше купит этот стартап ;)
4. Удивительно, но Ian Alexander не знал, что три его книжки есть в gigapedia.com. Отослал, пусть получит удовольствие.
5. Сесар и Дональд признали, что в ISO 24744 нужно Producers вводить не непосредственно как исполяющих работы, а через сервисы и их capabilities (это текущий мейнстрим). Думаю, в этом может сильно помочь работа
kir_lis, у которого по факту случилось два доклада на эту тему.6. Есть несколько дисциплин системной инженерии, которые не осознают себя системноинженерными -- это инженерия безопасности и защиты, инженерия качества и т.д. У них свои учебники, тусовки, профессиональные сообщества и конференции. Вообще, список дисциплин системной инженерии пока никем особо не обсуждается.
По факту дело состоит в том, что работы системной инженерии проводятся одновременно: например, инженерия требований и системной архитектуры не могут быть как-то разведены. С другой стороны, сам набор возможностей/навыков (capabilities/skills) у инженеров по требованиям и инженеров-архитекторов разнятся. Одни являются "адвокатами людей", а другие -- "адвокатами системы". Я когда-то в 80-х интересовался парной работой суперпрограммистов, так в этих парах наблюдалась именно такая специализация -- кто-то отстаивал упихивание в программу "нужных пользователям" конструктов, а кто-то обеспечивал простоту системы, ее быстродействие и принципиальную расширяемость. Но работали эти суперпрограммисты обычно вместе, а не порознь. Сегодня системные инженеры признают, что "требования сначала, архитектура потом" -- это абсолютно не соответствующее жизненным реалиям требование. Как описывать одновременное выполнение практик двух различных дисциплин -- это вопрос.
7. Было бы очень интересно переложить сленг моделирования данных в какой-нибудь более гуманитарный. Так, ни один менеджер не купит "библиотеку справочных данных" (и всё остальное со словом "данные"), но многие были бы готовы купить "компьютерную библиотеку корпоративных/отраслевых/промышленных/других справочных знаний".
8. Смешной разговор про "онтологов" из СМДМ: им для начала нужно научиться различать отношения классификации и специализации, а уже потом рассуждать о "предельной онтологии". А то смешно выглядит разговор про онтологию у тех людей, у которых 2+2 складывать получается еще не очень уверенно, но они уже свободно рассуждают об интегралах.
9. Организационная инженерия, организационная онтология (про полномочия и ответственность, контракты/поручения) пока вообще никем, кроме Jan Dietz не рассматривается. Удивительно.
10. Вопрос про архитектурное описание деятельности, которое состоит из описаний жизненного цикла, воркфлоу (процессы в стиле ISO 9000), проектов пока никак не решается, но уже виден подход к их решению:
-- нужно перейти к нормальному онтологическому описанию "4-уровневой архитектуры" для деятельности (а не только продукта), чем снять коллизии методологии-предпринятия, или "процесса-класса -- проекта-экземпляра"
-- перейти к 4D-описанию с темпоральными частями продукта деятельности, чтобы снять проблемы описания разнообразных workflow из предопределенных компонент метода, не потеряв связности шагов процесса над пулом рабочих продуктов и не потеряв строгости описания.
11. Про теги и системы из ISO 15926 нужно будет специально разобраться: это рассмотрение нужно включать в курсы системной инженерии в самом начале, где вводится понятие системы и жизненного цикла.
12. Никто (даже из инженеров-онтологов, которые не сталкивались с интенсивным использованием онтологий из разных источников) не понимает про проблему версионирования мегаонтологий (см., например http://community.livejournal.com/dot15926/7988.html и http://community.livejournal.com/dot15926/7570.html -- и там по ссылкам в комментах). Ее считают частным случаем управления конфигурацией продукта, а эту задачу по факту решенной. Так, Мэтью Вест говорит, что если ему заплатят, то он может разработать посвященную этому часть ISO 15926 как раз по аналогии с управлением конфигурацией продукта -- но мне кажется, что проблема пока не понимается даже им. Ханну Ниемисто в презентации по Simantics недаром часто ссылается на трудность менеджмента всех этих онтологий. Ибо учесть конфигурацию легко, весь вопрос в том, как автоматизировать поддержание непротиворечивости этой конфигурации. Это отдельная и специальная тема, и я очень надеюсь, что
cryozot ее будет копать.13. Мэтью Вест очень удивился, когда обнаружил в зале 20 человек, которые что-то пытались делать с ISO 15926, а не только что-то о нём слышали. Хорошо, что ему не рассказали, что именно пытаются эти люди делать с этим стандартом :-) Но лиха беда начало!
14. Ян Александер сильно удивился, когда обнаружил примерно 70 человек (столько народу было в зале на его презентации), которые совершенно очевидно поняли его метамодель выявления требований. По его словам, в обычной его аудитории западных инженеров эта метамодель просвистела бы далеко над головой -- никто бы ничего не понял. А он сам явно не понимал, что в России по факту во многих отраслях воссоздан социализм, который тем и отличается от капитализма, что блестящие люди при социализме создают весьма и весьма посредственные продукты, а вполне ограниченные люди при капитализме создают весьма и весьма нетривиальные продукты -- секрет не столько в людях и их понимании сути дела, а в организации коллективного труда.
15. Тематика системы систем востребована явно в бОльшей степени, чем можно себе представить. Когда эта конференция замысливалась, то не было никаких планов по поводу включения в доклады вопроса про системы систем. А на самой конференции система систем появилась в 4 докладах.
16. Шутка Яна Александера про simantics -- это очень говорящее за себя имя (sim antics, simulation antics -- по словарю "antics are funny, silly, or unusual ways of behaving").
Слайды на русском и английском языках, надеюсь, будут опубликованы в понедельник.