Нами опубликован русскоязычный "Обзор стандартов описания жизненного цикла и его практик" (http://www.techinvestlab.ru/586456).

Большое спасибо foxtreme, который выполнил основной объем работы по написанию и долготерпел моё чуткое руководство.

В обзоре приведено сравнение разных способов выделения элементов (фрагментов, кусков, сервисов и т.д.) методов, использующихся для получения описаний жизненного цикла в рамках ситуационной инженерии методов () -- SPEM 2.0, ADOM-SME, ISO 24744, OPF.

Кстати, это не первый вышедший текст на русском языке по этим вопросам. Вот, например, вышедший в Киеве текст аж 2005г. -- но там не обзор, а описание одного из многочисленных нестандартизованных вариантов (плюс терминология, с которой можно было бы поспорить. Например, там инженерия ситуационных методов, а не ситуационная инженерия методов): http://eprints.isofts.kiev.ua/459/1/%23Zinkovych.pdf

Опубликовано видео (в этот раз записано 3.5 часа) и слайды с 17-го заседания Русского отделения INCOSE -- http://community.livejournal.com/incose_ru/9812.html.

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

Мне кажется, что это заседание обсуждало абсолютно фронтирную в системной инженерии тему: про системы из людей. Я думаю, что в системной инженерии пройдет две революции:
а) слияние системной инженерии и программной инженерии (сейчас эта революция идет полным ходом, и выражается в полной растерянности перед тем, что такое моделеориентированная системная инженерия одновременно с признанием, что это и есть будущее системной инженерии). Уже признают, что все сложные системы -- это программоемкие системы (software-intensive).
б) вместе с тем, в ISO 15288 еще допускается проводить границы системы как включая людей, так и исключая людей (хотя софт включается безусловно!). Я тут жду второй революции: человеко-ориентированной системной инженерии, когда все системы будут признаны человекоемкими (human-intensive).

Движение в эту сторону только-только начинается, но оно будет столь же драматично менять системную инженерию, как сейчас ее меняет необходимость создавать киберфизические системы.

Знаменитая байка о том, что к чему компьютер ни прикоснись, начинает быть компьютером, а не куском железа (автомобиль с компьютером ведет себя как компьютер, а не как механическая система, ракета с компьютером устойчиво летит как компьютер, а не как неустойчивый кусок железа и т.д.), мной трансформируется в абсолютно такую же байку про человека -- к чему человек ни прикоснется, оно начинает себя вести как человек (и к компьютеру это тоже относится). Автомобиль с человеком (вместе с комьпютером внутри автомобиля) ведет себя уже как человек, а не как компьютер, хотя и иначе, как автомобиль без компьютера внутри или компьютер без автомобиля. Атомная станция с операторами и компьютерами ведет себя иначе, чем атомная станция с компьютерами без операторов -- и Чернобыль тому свидетельство.

Если про софт и его поведение (включая hardware-in-the-loop) хоть что-то известно (под "известно" я имею ввиду прежде всего наличие каких-то методов и соответствующих этим методам инструментов, приводящих к известным результатам) про людей пока известно не так много. Работа с людьми -- это пока целиком искусство и в очень малой степени инженерия (тут еще можно и нарваться на обвинения в манипулировании или "механистичном подходе" и мало ли еще в чем -- религиозные войны между любителями виндоуза и линукса тут по накалу страстей нервно курят в сторонке).

В общем, моделеориентированная (model-based) системная инженерия -- это нынешний фронтир, а человекоцентрическая (human-based) системная инженерия (а не просто human-systems integration как проходит эта тема сегодня) -- это фронтир ближайшего будущего, и наше счастье, что мы уже об этом знаем.

Кстати, Гугль выдает пока только одну ссылку с упоминанием Human-Based Systems Engineering (во фразе "He has been interested in Human based Systems Engineering for
many years" -- http://faculty.nps.edu/nlmiller/Fatigue/HSISymposium/cdr_pdfs/indexed/3b_1.pdf). После этого постинга будет уже две ссылки. Хотя совершенно не исключаю, что это все пойдет и под другими именами. Имена-то не важны, словарь всегда можно заменить -- а вот понятия останутся.

Я тут общаюсь в Google Wave с Kent Palmer (http://holonomic.net/ и куча других сайтов) про философию и системную инженерию (https://wave.google.com/wave/#restored:wave:googlewave.com!w%252Bi8fNaszLA). Кратенькие выдержки из сегодняшней утренней беседы я поместил в рунглийский (http://en.wikipedia.org/wiki/Runglish) свой блог (а именно, http://levenchuk.com/2009/11/29/systems-engineering-no-systems-methodology/ и http://levenchuk.com/2009/11/29/dynamic-ontologies-of-systems-engineering-sytems-methodology/).

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

Неверность прежде всего в том, что системная инженерия -- это инженерия! Это не наука. Системная инженерия не исследует, она делает. Дисциплины системной инженерии -- это инженерные дисциплины, а не научные. Но Палмер правильно замечает, что нам нужно использовать несколько онтологических мета-уровней (он приводит в пример бейтсоновские пять мета-уровней обучения -- по русски это тут: http://www.psyinst.ru/library.php?part=article&id=812).

Я ему говорю, что при этом он переводит стрелки с инженерии на деятельность как таковую, где инженерия сочетается с исследованием-наукой. Поэтому вместо философии инженерии или философии науки ему нужно разбираться с деятельностью, да еще и в залоге не ее изучения, а в залоге создания. Разбирательство (цикл создания-изучения) нужно с методом. Объектом, о котором печется Палмер является не системная инженерия, а системная методология!

Системную же методологию нужно искать не там, где светло (например, поиском в Гугле "systems methodology"), а там, где ее можно найти. Находится она в тех местах, где практически приходится разбираться с методами, включая методы системной инженерии -- это прежде всего движение метамоделирования в современном программировании/моделировании. Как минимум, там есть два интереснейших направления:

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

б) инженерия методов в общем смысле, которая сводится по большому счету к метамоделированию. И тут крайне важен тот заход, который делает Пальмер: его волнует динамическая онтология, а не просто онтология. Он хочет наблюдать всю метацепочку деятельностей (разворачивания методов) по созданию/изучению целевой онтологии. Я как раз недавно приводил примеры этого растущего внимания к динамике со стороны метамодельеров: http://ailev.livejournal.com/757999.html со ссылкой на работу Pierantonio и http://ailev.livejournal.com/760334.html со ссылкой на интерактивное программирование (про каковое, похоже, мало кто понял -- поэтому еще раз советую почитать первую пару страниц из http://dynamicaspects.org/papers/PADL2010Final.pdf. Там адресуется как раз тема отладки при мета-переходах, когда непонятно, каким образом компьютер в логических программах выполняет тот или иной код -- но отладка понимается как "изучение-наблюдение плюс затем интервенция". Можно еще указать на работу http://hdl.handle.net/1721.1/45563, где говорится о практически том же самом, но разъяснения, зачем это нужно, дается более мутное: программирование представляется как интерактивное, "понять-что-происходит-в-программе -- затем-изменить-программу" -- и далее обсуждаются свойства поддерживающего языка. В общем, дальше сами раскопаете. Хотя, думаю, мне придется еще несколько постингов на эту тему написать -- в том числе пытаясь переложить это на САПРы).

Тут можно помянуть еще и боковое направление: статические онтологии, которые отражают динамику развития системы (4D-онтологии). Тут, конечно, всем читать http://www.matthew-west.org.uk/Publications.html

Поменял адрес своего английского блога -- теперь он http://levenchuk.com (а старый адрес ailev.wordpress.com будет туда редиректить).

Но по-английски я туда сегодня не успел ничего написать. Ничего, лиха беда начало.

Относительно новая мода -- катакасты (http://katas.softwarecraftsmanship.org/, все нужные ссылки с объяснениями -- http://katas.softwarecraftsmanship.org/?page_id=2).

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

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

Я вначале даже не понимал, откуда столько восторгов. И только потом понял (хотя отнюдь не все из этого звучит в объяснениях самих программистов, это остается невысказанным):
а) это действительно радикальный сдвиг от обучения путем чтения чужих программ-результатов (наиболее распространенная парадигма обучения программированию: "хороший программист не тот, кто много кодирует, а тот, кто много читает чужой код") к обучению путем копирования процесса мастера. В ката учишься не "лучшим решениям", а учишься процессу их достижения. Учишься не дизайн-паттернам, а способам их вписывания в текст программы. Учишься процессу, а не структуре.
б) Тайминг важен. Читая книжку, невозможно понять ритм исходного действия. Ноты "Полета шмеля" не передают характера музыки, картинки характерных поз каратиста не передают скорости движений. В ката этот ритм очевиден. К тому же в книжке показать мультиоконное программирование невозможно, а видео решает проблему.
в) существеннейшая часть работы программиста перешла из кода в последовательность кодирования. TDD невозможно понять "по книжке": отсутствие ритма заставляет разбираться со многими похожими картинками (перескок между которыми дополнительно распыляет внимания) как с кинолентой, пытаясь восстановить движения по многочисленным похожим кадрикам. В результате TDD оказывается неосвоенным, и от него отказываются при легком дуновении дедлайнового ветерка. То же относится ко многим другим практикам: они сегодня относятся к процессу, а не к описанию результата. Процесс требует развертки во времени.

Современная форма программистских ката также требует перформанса, демонстрации другим людям. Так это же наш старый друг конструкционизм (http://en.wikipedia.org/wiki/Constructionist_learning) -- обучение заключается не столько в передаче знаний, сколько в создании каких-то значимых предметов и демонстрации их окружающим для получения обратной связи. В простейшей форме, это "набивание руки" на решении задач по уже освоенному материалу, переход осознанной компетентности в неосознанную, доведение мыслительного навыка до автоматизма -- но задачи эти нужно предъявлять, чтобы а) была цель, б) быть уверенным, что решил их правильно, в) получить обратную связь по улучшению.

Я вот думаю, какие могли бы быть ката в системной инженерии. И понимаю, что делать их нужно в САПР -- точно так же, как программистские ката делают в программных средах, а не с карандашом и бумагой. Учить нужно процессу, а не только результату. Недостаточно давать задачки типа "требования вот такие, найдите архитектурное решение". Нужно делать задачки в САПР, и затем добиваться ритма.

Но при программировании на DSL (а в САПР идет именно оно: программирование=моделирование на декларативных domain specific languages) почему-то нет тех практик, которые приняты при программировании на GPL (general programming languages). Но ведь суть та же! Значит, и приемы работы должны быть похожи, и приемы обучения.

– Какова основа тренерской концепции Мойеса? (Тренер Эвертона)

– У него есть своя идеология, пропагандирующая успехи «Эвертона». Мы даже целый клип смотрели: нарезка моментов за разные сезоны – там показывается, в какой футбол должен играть «Эвертон». То есть это не только голы и опасные моменты, но и удачные действия обороны, «идеальные» передачи. Очень интересно и необычно – в России такого не было. Вообще это хорошо, когда есть четкое понимание, к чему следует стремиться. Когда знаешь, чего хочешь, легче выстраивать план, как достичь это желаемое.

1. Там внутре очень кучеряво. Сначала даже показалось, что настроек побольше, чем в ЖЖ. Но это не так. Wordpress.com -- это публикации "в никуда", а не социальная сетка (чуть не опечатался: секта -- и недалеко бы ушел от истины). Поэтому настроек там с ЖЖ одинаково: в ЖЖ больше настроек, которые помогают бороться с френдами, а в wordpress.com больше настроек, помогающих бороться с постингами, их черновиками, их резюме и т.д.

2. Удивительно медленно. Я думал, что ЖЖ нетороплив. Нет, это wordpress.com нетороплив. Крайне нетороплив. Раздражительно нетороплив. И, похоже, даже его платные версии будут работать с той же неторопливостью (нигде не нашел, что оплата хоть что-нибудь ускоряет).

3. Не хватает чего-то типа semagic (по слухам, semagic тоже может постить в wordpress, но я как-то не нашел в нем возможности залогиниться и в ЖЖ и в wordpress и потом быстро переключаться между ними).

С огромным удивлением обнаружил, что я за последнюю пару дней написал ой-ой сколько по-английски (на http://ailev.wordpress.com уже 3 постинга, сделанные методом cut/paste из частной переписки. Один про системную инженерию и ее развитие, а два других про ISO 15926: как к нему приделать словарный уровень, и как к нему приделать language workbenches).

Тем самым, я теперь живу (по факту) в трех местах -- в ЖЖ, английском своем блоге и в Google Wave. А еще я иногда заглядываю в LinkedIn, ибо там в группах время от времени проскакивает что-то интересненькое.

Последние несколько дней я неоднократно натыкался в самых разных местах на рецепт счастья в описании мира. Успех в моделировании чрезвычайно прост, как 1-2-3:

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

Модели хранятся внутри компьютера как онтология, схема. Если вам не нужен доступ к моделям, этого достаточно.

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

Без онтологий очень тяжело. Поглядите на вопль комьюнити Business Rules и Complex Event Processing, как им тяжело жить без явной онтологии (особенно онтологии времени): http://intranet.cs.man.ac.uk/ruleML/presentations/keynote1.ppt

2. Лексика. Концепты по большому счету безымянны, а разные люди называют их по-разному в разных языках. Доступ к концептам дает лексика (vocabulary), терминология критична для понимания.

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

3. Нотация. Чтобы выразить отношения между концептами, вам нужна нотация, синтаксис. Графический или текстовый, или смешанный, или навроде математической нотации, или даже альтернативные нотации для одной и той же модели/программы, используемые для разных случаев.

Нотации дают удобство мыслительных операций для людей. Диаграммы Фейнмана, женевская химическая нотация, арабские цифры вместо римских -- это все были прорывы в выразительности. Нотации неразрывно связаны с концептами и лексикой, они превращают их в язык, на котором можно писать и читать.

Чтобы построить предметно-специфицированный язык (domain-specific language, DSL), вам потребуются:
-- онтология (метамодель, схема)
-- лексика (именно о ней заботятся при локализациях: кому удобно читать-писать по-русски, пусть используют русскую лексику. Кому удобно по-английски -- пусть переключаются на английский, это не должно ни на что влиять)
-- нотация (пусть она будет для этой предметной области привычна. Если вам нужно работать с музыкантами -- пусть это будут ноты на пяти линейках, а если у вас диджеи, то предложите им piano roll).

Проблема в том, что счастья нет:
-- ISO 15926 хорош как онтология, но в нем нет огромного числа важных концептов.
-- SBVR хорош для терминологии, но онтология в нем никудышная.
-- про нотации вообще сказать нечего, полная свобода делать свои собственные ошибки.

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

Но как только вам потребовалось описывать мир так, чтобы удовлетворить самых разных интересантов, и чтобы эти описания все были связаны между собой и поддерживалась их целостность, да еще и обеспечивалось коллективная работа над этим описанием, да еще объемы этих описаний велики (какая-нибудь нефтяная платформа с находящимся на ней небольшим нефтеперерабатывающим заводом, описанная с точностью, достаточной для ее изготовления), то у вас БОЛЬШИЕ ПРОБЛЕМЫ -- и с онтологией (должна быть одна, хотя в ней будет много-много метамоделей), и с лексиками (их уже будет много) и нотациями (их тоже немало -- десятки, если не сотни).

Нынешние линейки САПРов решают эту задачу "на коленке", все решения глубоко внутрифирменные. Языковые верстаки пытаются вывести решение этой задачи в обычную разработческую рутину.

Зарекался я комментировать дела нашего государства, но не выдержал -- началось обсуждение очередного проекта постановления правительства, по которому биржевые цены подлежат регулированию, чтобы они не вылезали из предписанного ФАС коридора, причем на бирже товары тоже появляются по настоянию ФАС (http://alex-pirojenko.livejournal.com/10013.html).

Эту песню не задушишь, не убьешь -- она намертво прошита в головах. Модернизация идет, причем полным ходом. Высокие регулирующие технологии ставятся на поток, этому у нас затем будут учиться бывшие развитые страны. Мы уже всех догнали, а теперь по-быстрому перегоним. Воспользуемся кризисом, когда они все замедлятся, а мы как раз в отрыв пойдем. На ручном управлении ценами кризиса-то и не заметим, кризисы ведь -- это капиталистические кризисы, при социализме кризисов не бывает, всем одинаково плохо. ФАС ведь для того и существует, чтобы никто не выигрывал. Никто и не выиграет.

Вспомнил, что в 2007г. заводил англоязычный блог (http://ailev.wordpress.com). А поскольку в самых разных местах я сегодня что-то пишу по-английски, буду делать с ним то же, что делаю с дневничком в ЖЖ: выкладывать туда то, что более-менее пригодно для публичного ознакомления.

И не буду уже бояться писать на Russlish: кому моя писанина понадобится, тот вряд ли будет обращать внимание на косноязычие (да и сам он будет откуда-нибудь из Бразилии, где акцент не меньше ;)

Первая запись -- выдержки из дискуссии с Kent Palmer в Google Wave, посвященной системной инженерии (https://wave.google.com/wave/#restored:wave:googlewave.com!w%252Bi8fNaszLA), поскольку не у всех есть эккаунты в это место, то я и вынесу свои ремарки в англоязычный блог.

Вордпресс хорош, дает короткие ссылки на записи. Так, эта моя запись имеет короткий адрес http://wp.me/p3DYC-4. А длинный адрес -- http://ailev.wordpress.com/2009/11/27/systems-engineering-in-good-shape-its-changing/

Комменты там, плиз, тоже по-английски, ежели кто захочет написать. Моя на них будет попытайся отвечает.

Манифестов прибывает: разработчики DSL сделали развернутый манифест -- http://www.industrialized-software.org/kiss-initiative

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

И что мы там видим?! Мы видим, что вопросы, которые давным-давно решаются поставщиками "Больших САПР" только-только начинают решаться этим DSL-сообществом.

Разница только в том, что сообщество хочет иметь инструментарий, чтобы делать эти САПРы дешево и сердито. А поставщики САПР хотели бы иметь такой инструментарий внутри себя и поставлять задорого готовые решения.

Почему САПР, а не какие-нибудь EAМ с ERP? А просто в САПР есть принципиально отличные от "табличных отчетов" и "диаграмм в экселе" представления: 2D чертежи и 3D компоновки, принципиальные схемы гидравлические и электрические, математика, имитационное моделирование в ассортименте, а все эта "финансовые" и "закупочно-складские" представления тоже есть -- кажущиеся уже очень-очень простыми по сравнению с предыдущими.

Дальше -- DSL-движение как немашиностроительная и вообще непроизводственная (а общего вида) САПРизация, включая первым делом сапризацию самого софтостроения (CASE).

Платформа Whole (GNU LGPL) на Eclipse заявлена как language workbench -- http://whole.sourceforge.net/ (последняя версия -- 22 апреля 2009г., краткое описание -- http://whole.sourceforge.net/docs/Sol08_EclipseCon.pdf). Сделал Riccardo Solmi (http://www.cs.unibo.it/~solmi/), это была его докторская диссертация (http://whole.sourceforge.net/docs/Sol05_JUGMI.pdf).

Существенно по возможностям отличается от MPS (в конце страницы: http://www.theserverside.com/news/thread.tss?thread_id=53606), написана целиком на себе самой (что нетрудно, ибо одним из DSL самой Whole является Java, другим -- какое-то надмножество SQL и много чего еще интересного).

UPDATE: на мой вопрос, как идут дела, 30 ноября 2009г. получен ответ от Solmi: "The last public release of the Whole Platform is the one of April. I am committed to continue the development of the platform full-time. The next milestone will mark a big step forward with respect to competition in many areas."

Interactive programming -- это про spreadsheet languages и прочие фокусы, где меняют куски кода в одном месте экрана, чтобы получить (ожиданно!) изменения кода в другом месте экрана, "как в экселе" -- http://www.cs.bham.ac.uk/~rnp/

Похожее можно встретить, например, в Matematica 6 -- http://www.wolfram.com/products/mathematica/newin6/content/DynamicInteractivity/

Основные идеи -- это про эквивалентность времени компиляции времени выполнения, инкрементальность вычислений.

Интерактивность, говорит автор подхода (Perera) дает чувство логики более высоких порядков в программе с логикой первого порядка: http://dynamicaspects.org/papers/PADL2010Final.pdf. У автора есть и блог: http://dynamicaspects.org/blog/index.html

Это все продолжение ответа на вопрос, который я задавал в марте 2008г (суперкомпиляторы и суперинтерпретаторы: http://ailev.livejournal.com/565598.html): как подход моделирования/суперкомпиляции прорывается через суперпозднее связывание. Предыдущий заход на это был в "Универсальный моделер" http://ailev.livejournal.com/757999.html в виде ссылок на работы по evolution in the large and in the small in model-driven development (рассматривались такие изменения метамоделей, чтобы сохранялась целостность моделей -- все то же самое, только ступенькой модельной иерархии выше).

Обычно переход от статики к динамике во всех науках означал крутую революцию. Может, компьютерная революция как раз где-то в этом месте? Все как раз на это указывает, даже то, что эти "интерактивные подходы к программированию" сейчас являются вполне себе rocket science даже для хардкорных нердов.

На вчерашнем заседании Русского отделения INCOSE в кулуарах произошло обсуждение того, какие критерии должны быть у хорошего САПР.

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

В кулуарах к кулуарам мы с vvagr сформулировали следующий набор вопросов, которые нужно задавать поставщикам САПР. Ответы на эти вопросы крайне разные для разных поставщиков, а у поставщиков крайне разные для разных версий их систем:

1. Поддержка специальной инженерии: все САПР хорошо поддерживают 3D-картинки или принципиальные схемы (например, P&ID). Но каждый элемент для той или иной специальной инженерии (труба, швеллер, да и сам бетон) имеют какую-то модель данных, которой для вашей специальной инженерии просто может не быть. Вопрос:
-- модели данных каких элементов наличествуют в САПР "из коробки"?
-- модели данных каких элементов можно купить?
-- модели данных какого вида можно "настроить"?
-- есть ли какие-то доступные каталоги?
Есть ли готовые "настройки" для рабочих мест специальной инженерии? (трубы, HVAC, бетон, электрика...).

2. Поддержка дисциплин системной инженерии:
-- поддерживается ли в рамках одного рабочего места (без дополнительной настройки) трассировка "по клику мышкой" между требованиями (заинтересованных сторон, требований к системе), логической архитектурой, физической архитектурой, имитационными моделями, рабочим проектом, закупками (практика соглашений), проектом-project?
-- есть ли поддержка "оценочного дела" (для требований, архитектуры, "обоснование безопасности" и т.д. -- claims, arguments, evidence).

3. Поддержка процесса системной инженерии:
-- поддерживается ли ситуационная инженерия методов? Насколько удобно описываются процессы-workflow (процесс известен и доступен "из коробки"; процесс неизвестен, ибо повторяет процесс какого-то давнего заказчика; процесс гибко настраиваем -- но без настройки ничего не работает)
-- есть ли поддержка проектной/менеджерской группы описаний (контрольные точки, пересмотры и т.д.).

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

5. Какие чертежи выдаются в производство и на стройку?
-- выдаются не чертежи, а что-то иное (тогда как это иное может быть использовано в наших краях?)
-- выдается полный комплект чертежей по ГОСТ, никаких проблем с отечественными надзорами и подрядчиками
-- выдается полный комплект чертежей по каким-то иностранным стандартам, и требуются уговоры контрагентов для их использования.

Руководство Toyota не требует, чтобы 100% времени работа велась без остановки, даже когда сборочная линия может работать весь день, но при этом по производительности предприятия Toyota постоянно опережают другие автомобильные компании. Почему? Потому что в Toyota давно усвоили: выявление первоисточника проблем с качеством экономит время и деньги.
Неустанно выявляя и решая проблемы, вы устраните потери, добьетесь значительного роста производительности и повергнете в прах конкурентов, которые заставляют сборочные линии работать на износ и накапливают проблемы.
- Джеффри Лайкер, «Дао Toyota»

Усиление коллектива — работа, которую не должен делегировать ни один руководитель, на каком бы уровне он ни находился
- Э. Майклз, Х. Хэнфилд-Джонс, Э. Экселрод, «Война за таланты»

Вчера еду по Москве. Сужение дороги до двух полос и справа примыкает второстепенная. Я по правому ряду. Со второстепенной Матиз меня режет, но все, благодаря тому, что прижал немного левого поместились. Сразу светофор. Матиз влазит справа. Поворачиваюсь, там женщина, ну я показываю ей жест пальцами себе в глаза тычу, будь как бы внимательнее. Она там что-то говорит с видом "отвали" и проезжает вперед меня. И тут я совершаю наверное ошибку... Я продвигаюсь вперед и опять же тот же жест. Она еще понятнее дает понять, что ей пофигу на меня. Я опускаю стекло, выключаю радио и прошу повторить ее слова в слух. Игнорирует. Но тут с переднего сиденья вылазит мужчинка и показывает мне фак. Забрало упало сразу, адреналин в кровь. Первая передача, выезжаю перед ней, блокирую дорогу и выхожу из машины. Женщина наверное...обосралась то самое слово, и включив заднюю передачу бьет машину, которая уже начала ее объезжать. Я посмотрел на это дело, сел и уехал. Жалко невинно пострадавшего. Poll #1490547 Гопник ли я?
Open to: All, detailed results viewable to: All, participants: 12

Как оцените мои действия?

Гораздо эффективнее и дешевле обеспечить качество на месте (не допустить передачу проблемы дальше по потоку), чем заниматься проверкой качества и исправлением дефектов постфактум.
- Джеффри Лайкер, «Дао Toyota»

99% директоров компаний, участвовавших в нашем опросе в 2000 году, заявили, что их коллективу через три года нужно стать гораздо сильнее. Лишь 20% посчитали, что у них достаточно талантливых руководителей, чтобы реализовать имеющиеся возможности
Лишь 16% опрошенных менеджеров ответили, что их компаниям известны сотрудники с высокой результативностью и неуспевающие.
Лишь 9% уверены, что их сегодняшние действия приведут к усилению команды талантов.
- Э. Майклз, Х. Хэнфилд-Джонс, Э. Экселрод, «Война за таланты»

В любом деле у вас есть роль -- какие дела вы делаете, по названию этих дел будет и ваша роль. Делаете покупки -- в этом деле вы покупатель. Учите -- тут вы учитель. Слесарите -- тогда слесарь.

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

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

А можно занимать позицию осознанно: "сейчас займу вот с такой-то целью такую-то позицию" (выберу себе такую роль, и буду придерживаться ее ценностей в самых разных делах, пока не передумаю). Такой выбор позиции обычно называется "самоопределением".

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

Многие люди не скользкие, потому как застревание в их позиции происходит вне их сознания, просто из-за их застревания в системе ценностей того дела, которым они подолгу занимаются -- поэтому они выглядят как принципиальные люди, отстаивающие какие-то свои принципы. Если у них своего дела нет, то они могут так же бессознательно "не держать позицию", и выглядеть поэтому скользкими и беспринципными.

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

Моя позиция обычно занимается осознанно и держится подолгу: консультант, с набором ценностей и методов работы консультанта. Именно это и есть мое самоопределение. В самых разных ситуациях, когда можно занять любую роль, и самоопределиться в любой позиции, я самоопределяюсь как консультант. Хотя это не означает, что я не могу вдруг осознанно перейти в позицию организатора, или позицию исследователя. Обычно это изумляет, потому что окружающим кажется, что меня вдруг подменили: при занятии той или иной позиции ведь меняется практически все, от привычного распорядка дня до поддержки разных сторон в конфликтах. А это просто осознанная смена позиции, на время.

Главное в ролях и позициях -- осознавать их. Осознавать и у себя, и у других.

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

Все образование крутится вокруг дисциплин -- самых разных методов (практик и шаблонов их применения), которые цветут и пахнут вокруг какой-то онтологии.

Эти дисциплины можно условно разбить на общеметодический уровень и ситуационный уровень (http://ailev.livejournal.com/755969.html):
-- общеметодический уровень описывает онтологию и методы, еще не касаясь особенностей системы, стадии ее жизненного цикла и используемого инструментария.
-- ситуационный уровень требует конкретизации онтологии и методов для конкретной системы (или типа систем), ее стадии жизненного цикла (или набора стадий) и используемого инструментария.

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

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

Идеальный случай был бы такой: консультант становится на некоторое время преподавателем, дает клиенту задания на "системах из задачника", а затем обученный клиент идет к своим системам и быстро-быстро применяет полученные знания на практике.

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

Теперь на примере системной инженерии.

Если я преподаватель системной инженерии, то я читаю курсы системной инженерии примерно на том уровне общности, на каком дан стандарт ISO 15288 (т.е. "для систем любой природы, любого уровня в структуре подсистем, любого масштаба и любых стадий жизненного цикла"), или руководство по конкретной дисциплине системной инженерии (например MFESA -- описание инженерии системной архитектуре опять же "для любой системы... и т.д."). Задачки из задачника, разборы ситуаций, кейсы и так далее.

Если я консультант, и понимаю, что клиенту можно помочь методами системной инженерии (некоторым -- именно что применением всей системной инженерии, некоторым -- особым вниманием к какой-то практике), то у меня не будет возможность читать им курс лекций и проводить семинарские занятия. Я должен буду уговорить обратиться к стандартам -- и сотрудники клиентов со скрипом прочтут стандарт (учебник не прочтут!). Трудные места я буду разъяснить не за флипчартом и не на учебной системе, а за третьей чашкой чая в каком-нибудь кабинете -- и вместо флипчарта будет размахивание руками, а вместо учебной системы первая попавшаяся под руку система, на которой сосредоточено внимание клиента (ничего, после третьего или четвертого объяснения на третьей или четвертой системе его бессознательное генерализует и интериоризует это трудное место, далее он и сам справится).

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

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

У нас такой запас методов называется PraxOS (другой такой запас методов у других консультантов -- www.opfro.ogr). Совершенно понятно, если PraxOS будет использован преподавателями для образования. Но мы будем использовать его для консалтинга: проделывая ситуационную инженерию метода для каждого клиента.

Преподавание же у нас довольно редкая и эпизодическая деятельность, скорее уж побочный продукт.

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

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

А теперь резко поднимем планку для преподавания, и будем обсуждать не "тренинг", а образование (слово тут тоже поменяется с "преподаватель" на "учитель").

Тут же выяснится, что у каждого ребенка есть ситуация которую преподаватель обычно игнорирует, а принимает во внимание и временами переходит в роль консультанта -- дает нужные для текущей ситуации методы (иногда даже прихватывая их не только из своего личного опыта, но и из эээ... интернета), и тогда по факту ребенок ставит задачки учителю-как-консультанту. Но дальше учитель отличается: его главная задача (в отличие от главной задачи консультанта) -- это заменить задачки ученика на те задачки, которые учитель считает правильными (вопрос о содержании образования). И вместо "давай я научу тебя хвастаться картинкой не только друзьям, а всему миру -- покажу как выложить картинку на Flickr до того, как тебя этому научит первый встречный" скорректирует изучаемую дисциплину на нужную ученику в его будущих ситуациях, а не в его текущей ситуации и одновременно заменяя реальную систему, ее стадию жизненного цикла и инструментарий из текущей ситуации ученика на учебную систему, стадию жизненного цикла и инструментарий (ибо реальных у ученика сейчас нет -- учим-то будущим ситуациям!) -- "ну что, ты еще не ловишь кайф от решения дифференциальных уравнений? Мы ведь их решаем с тобой уже пару месяцев!".

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

Это все, конечно, очень зыбкие материи. Мне очень радостно, что язык ситуативной инженерии методов вводит нужные различения и помогает разобраться в ситуации с преподаванием, консультированием и образованием. Мы на верном пути.

SPEM дан как UML профиль, но есть модельные реализации на
-- Description Logic (http://dns2.icar.cnr.it/ruffolo/progetti/projects/23.Semantic%20BPM-%20in%20OntoDLP/Represent%20Software%20Process%20Engineering%20Metamodel%20in%20DL--v11-20.pdf) и
-- OWL/SWRL (http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-460/paper09.pdf).
-- исполнимый (eXecutable) xSPEM 2, используем ATL + PetriNet --> BPEL (http://hal.archives-ouvertes.fr/docs/00/37/15/55/PDF/APSEC07-BCCG-PreliminaryVersion.pdf)

Мне кажется, что я уже неоднократно описывал эту архитектуру (см. хотя бы http://ailev.livejournal.com/757999.html), но сегодня выяснилось, что этих описаний недостаточно: нужны дополнительные группы описаний, адресующие дополнительные интересы потенциальных заинтересованных сторон. Так, приведу группу описаний, раскрывающее интересы по использованию предлагаемой архитектуры -- причем намеренно не фиксируя наименования компонент, а давая множество синонимов для пущей понятности и отвязывания от конкретной реализации.

Сегодняшние САПР (системы автоматизации ПPроектирования, ПРрограммирования, ПPроизводства, а также я сюда включаю EAM, ERP и так все корпоративные IT-системы) представляют собой распределенный набор редакторов DSL (workbenches, IDE, модули, обработчики), надстроенных над (возможно, распределенной) базой данных, хранящей модель разрабатываемой и/или изготавливаемой системы.

В некоторых САПР (например, Dassault Systemes V6, основанной на хранилище данных MatrixOne) эти модули/обработчики/редакторы_спецязыков (описания геометрии CATIA, описания коллаборации DELMIA и т.д.) основаны на SOA-архитектуре.

Подключение новых обработчиков/редакторов_верстаков по договоренности разработчиков всех этих систем происходит по ISO 15926, причем интерфейс тут вебсервисов (RDF и triple store, запросы SPARQL) -- это единственный на сегодня вариант полноценного обмена сложными данными, который позволяет передать все необходимые данные (геометрию, расчетные модели, описание workflow и т.д.) между САПР, а не только их часть.

Возьмем эту архитектуру за прототип.

То, что я все время предлагаю -- так это:

1. в явном виде иметь описание этой SOA-архитектуры. Ибо сегодня обеспечение совместной работы огромного (порядка 200) модулей современных САПР, в которых отнюдь не все модули относятся к одному поставщику, представляет собой искусство, а не инженерию. Нужно иметь отдельный артефакт: описание сервис-ориентированной архитектуры компонентов САПР, связанных друг с другом. Это описание, понятное дело, должно храниться в общей модели и использоваться для целей конфигурирования.

Для этой цели нужно иметь набор DSL для описания SOA и редактор (IDE) для редактирования этого описания. Как происходит потом использование этого описания для целей конфигурирования всей САПР-инфраструктуры -- отдельная история (но обычно САПР умеют использовать описания, данные в терминах их собственной модели).

Этот редактор (IDE) для группы описаний (view) SOA можно включить в состав модулей САПР точно так же, как включается редактор P&ID для группы описаний гидравлики в трубопроводах, редактор 3D (геометрии) для группы описаний формы деталей и их пространственной сборки, редактор описания проекта ("модуль управления проектом") для группы описаний разбиения работ и их ресурсного обеспечения, редактор требований ("модуль управления требованиями") для группы описания требований и т.д.

Согласно практики интегрирования данных жизненного цикла, это "включение в состав модулей" достигается путем
а) учета SOA-архитектуры общей IT-системы (модулей САПР различных поставщиков, хранилищ данных, модулей EAM и т.д.)
b) интегрирования данных жизненного цикла с данными, использующимися другими модулями (понимаемыми в этой группе описаний либо как сервисы, либо как обращающимися к нашему IDE как сервису) согласно стандарту ISO 15926

2. в явном виде нужно иметь описание процесса коллективной работы (как коллектива программ-модулей, так и коллектива людей-в-ролях) с этим комплексом САПР. Для этого нужно применить ситуативную инженерию методов. Это означает, что существует некоторый набор методов (коллаборативной) работы людей с модулями САПР, являющийся конкретизацией какого-то варианта описания жизненного цикла и его практик (т.е. варианта "методологии") для данной а) системы, б) стадии жизненного цикла, в) набора используемых САПР. Это традиционная постановка задачи ситуативной инженерии методов, и тут существуют развитые метамодели для этого описания (например, SPEM, ISO 24744, ADOM и т.д.).

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

Этот редактор (IDE) для ситуативной инженерии методов включается в общий набор сервисов различных модулей IT-системы точно так же, как и редактор (IDE) для SOA -- с использованием интеграции данных по ISO 15926.

Тем самым у нас возникает ситуация, когда мы можем использовать ситуативную инженерию методов для того, чтобы наладить процесс работы с развернутым комплексом САПР.

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

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

Я понимаю, что все эти вопросы обсуждаются в рамках Enterprise Architecture, но для меня эта линия рассуждения пока не важна -- не будем сейчас умножать число сущностей без надобностей, а про EA напишем когда-нибудь отдельный пост.

Дискурсивное устройство разработки софта (The Discursive Constitution of Software Development -- http://www.lse.ac.uk/collections/informationSystems/pdf/theses/cornut.pdf)-- диссертация Francis Cornut, отделение менеджмента лондонской школы экономики и политики, февраль 2009г.

Ключевой термин: символическая сила (symbolic power), а иногда и символическое принуждение (symbolic violence) -- сила (или насилие) в изменении видения мира, без экономической или физической силы, просто через принятие и сотрудничество с отдельными людьми.

В таком залоге ("онтократия") это часто обсуждается СМД-методологами. В диссертации показываются, как эти "онтократические" идеи реализуются на примере установления стандартов методов разработки софта.