Проблемы системной инженерии. Русский взгляд (мой доклад на RuSEC2010, 23 сентября 2010)

ailev — 13.10.2010 Слайды этого доклада (русскоязычный вариант -- http://www.slideshare.net/ailev/levenchuk-se-challengesrus23sep10, англоязычный вариант -- http://www.slideshare.net/ailev/systems-engineering-challenges).

Я – президент Русского отделения INCOSE, поэтому в моем докладе русский взгляд. Русский – тут имеется в виду язык, потому что в нашем отделении INCOSE есть также члены из Белоруссии, есть члены из Украины. И некоторые из них даже доехали до этого зала, и я приветствую их на этой действительно международной конференции. Очень рад, что «международное» – это относится и к нашему Русскому отделению INCOSE.

Откуда вообще появилась эта тема пробем системной инженерии, как вообще появилась эта конференция, откуда взялся этот RuSEC, это название? Дело в том, что раз в два года проходит Европейская конференция, EuSEC, European Systems Engineering Conference. И мы подумали, что очень хорошо было бы иметь также региональную русскую конференцию (RuSEC). И только потом – европейскую, ну, и международную конференцию INCOSE, куда приезжают люди со всего мира.

У нас не было выбора. Нашему Русскому отделению всего год, но мы хотели работать на мировом уровне. А как тут работать на мировом уровне? Вы же слышали содержание предыдущего доклада Виктора Батоврина про состояние образования по системной инженерии в России! Помните, у хоккеиста Уильяма Грецки спросили: «Как ты оказываешься всё время в том месте, где шайба?» Он отвечает: «Нет, я прихожу в то место, где шайба вот-вот будет». Мы сказали: «Тогда наша задача – прийти не в то место, где сейчас шайба…». Мы решили, что в нашем Русском отделении мы обсуждаем будущее системной инженерии, надеясь, что когда мы его дообсудим, оно станет настоящим, и мы попадем туда одновременно с иностранцами. Вот так, собственно, и появилась задумка.

Когда мы в мае 2010 года собрались на конференции EuSEC в Стокгольме, то неожиданно лидеры некоторых европейских отделений INCOSE сказали: «У нас есть собственное видение, видение, каким будет системная инженерия в 2020 году, отличное от INCOSE vision 2010».

В прошлом докладе как раз поминали INCOSE vision 2020. Это такая небольшая электронная бумажечка, в которой расписано, что в 2020 году системная инженерия будет моделеориентированная, и разная другая. Написано было не очень конкретно, но идея была в том, чтобы системные инженеры мира ориентировались на это описание, и через 10 лет мы все совместно получили ту системную инженерию будущего, которую все так поодиночке хотят.

И неожиданно в Стокгольме главы европейских отделений INCOSE сказали: «Нам эта бумажечка не очень нравится, потому что у нас уже другое вИдение». В частности, глава французской делегации сказал: «А мы во Франции разрабатываем своё видение системной инженерии». Я сказал: «Какое совпадение, мы в в Русском отделении, среди даже уже нескольких республик, которые обсуждают эти проблемы на русском языке, мы тоже разрабатываем своё видение системной инженерии».

Наверное, нам надо объединить вот эти видения, которые сейчас разрабатываются, и обновить это трёхлетней давности вИдение INCOSE. Мы в Русском отделении, наверное, можем предложить что-то своё не только в содержание этого вИдения, но, наверное, и в форму. Тем более, что это вИдение уже пора обновлять, поскольку оно было разработано 2007 году, а 2020 оно уже должно быть реализовано, и как раз сейчас нужно делать обновление, не нужно запаздывать с этим.

Обратите внимание, что в этом видении есть пять так называемых областей внимания. Это глобальная среда системной инженерии, системы и их природа, практики системной инженерии, модели и моделеориентированная системная инженерия, образование по системной инженерии. Это структура, фактически это оглавление INCOSE видения 2020. Вообще говоря, эта структура более или менее произвольна. Собрали некоторых экспертов, и они сказали, что «давайте эти пять областей внимания, потому что мы о них чаще всего разговариваем». Но мы думаем, что структура должна быть другой, на основе того, что системная инженерия – это, прежде всего, метод работы.

Здесь должен упомянуть дискуссию, которая проходит у нас в России. «Мы, инженеры, хорошо работаем, но тут приходят разные западные товарищи, в том числе явно прозападные товарищи из Русского отделения INCOSE, и говорят, что надо заниматься системной инженерией. Ну, мы и так это всё делаем. Только они об этом говорят на другом языке. Ну да ладно, выучим 10-15 новых слов и то, что мы сейчас делаем, будем называть этими новыми словами». Собственно, это и есть текущий российский подход к системной инженерии.
Самое интересное, что на Западе с этим тоже столкнулись. Когда люди из аэрокосмической промышленности приходят куда-нибудь в пищевую промышленность и говорят: «У нас системная инженерия, мы ракеты в космос запускаем!», то в пищевой промышленности говорят: «А вы посмотрите на производство булочек в "Макдональдсе", там два металлоискателя, два контура защиты, и они за все время работы разу не сработали, но мы их тестируем, мы делаем то же самое, что у вас в аэрокосмической промышленности». И непонятно, как им обменяться знанием о своих методах, потому что все слова разные и от этого вроде как похожие по сути методы получаются разные. Есть большой соблазн сказать, что это всё вопрос о словаре, вопрос о словах. Выучим общие слова для всех инженеров, и всё наладится.

Но почему-то не налаживается. Если посмотреть на продукцию, например, российского не только автопрома, но, например, даже и судостроения, и сравнить с западной продукцией, то, вероятно, судя по разнице в результатах, есть и разница в методах.

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

Говоря про структуру INCOSE vision, мы предлагаем взять для нее структуру описания метода. Есть ли у нас стандарт описания структуры метода, показывающая из чего состоит метод? Есть. Это стандарт метамодели разработки ISO 24744, и мы можем использовать структуру описания метода из этого стандарта На нашей конференции завтра будет подробная презентация про это, Цесарь Гонсалес-Перес нам расскажет об этом много подробней.

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

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

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

За пределами конференции осталось много проблемных вопросов. Например, традиционный вопрос (первый же в списке на слайде): системная инженерия против просто инженерии. Существует мнение, что системные инженеры – это просто инженеры. В системной инженерии ничего особенного нет, поэтому берём любого инженера – и он сделает всё то же самое, ибо «все инженеры делают это». Кроме того, существует мнение, что системная инженерия – это, вообще говоря, наука. Есть системный подход, им занимается наука, и есть его прикладная версия. Часто говорят, что системная инженерия – это наука, в ней математические модели, поэтому этим вроде как должны заниматься учёные, а не инженеры. Есть мнение и про системную инженерию как искусство. Сторонники этого мнения говорят: «Есть гениальные системные инженеры, они сделали мост через Темзу 200 лет назад, выполнив при этом всё то, о чём вы тут говорите в XXI веке. Почему бы нам тоже не работать по наитию и вдохновению?».

Это мнение про системную инженерию как искусство имеет непосредственное отношение к моему тезису про метод. Я говорю, что системная инженерия – это прежде всего метод. Конечно, гениальные инженеры древности строили уникальные суда, они строили первые в мире линии электропередач, когда ещё слов «системная инженерия» в помине не было, и даже не было системного подхода. Но вот беда: у них были ученики. Десять учеников стояли за плечом и с изумлением смотрели, что делают гении. И повторить тот же уровень мастерства мог только один из этих учеников, один человек. Почему? Его что-то «тумкнуло», когда он долго смотрел на результат работы, долго смотрел на то, как шел проект, он что-то неосознанно или даже чуть-чуть осознанно понял про метод и поэтому смог воспроизвести этот метод и даже чуть-чуть его развить. И так вот эта традиция «гениальной инженерии» передавалась по цепочке.

Сейчас, я думаю, у нас просто нет времени заниматься вот такой подготовкой гениальных кадров путем охоты и собирательства. У нас как генеральный конструктор рос? Обычно он был из «просто инженеров». Инженер растёт-растёт, и в какой-то момент становится всем понятно, что у него в голове каким-то чудесным образом помещается весь проект, все модели, весь метод для корабля, атомной станции, для чего угодно.

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

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

На слайде упомянуто и много другого. Например, системное мышление, понятие системы и онтологии. У нас в зале присутствует онтолог Мэтью Вест, который будет нам завтра рассказывать онтологическое понимание системы. Но в системной инженерии настолько всё быстро движется вперёд, что уже не хватает понятия системы для описания того, что делают системные инженеры. В утренних докладах уже упоминалось новое понятие «системы систем».

Эта система систем вызывает бурные дискуссии в сообществе системных инженеров. Есть противники, которые говорят: «их не существует, потому что уже есть системы, подсистемы, надсистемы, и нам не нужно лишнее понятие». Те люди, которые занимаются системами систем, отвечают: «это неверно, потому что ни один учебник из тех, которые вы написали с таким подходом систем-подсистем-надсистем, для нас не подходит».

Почему по поводу системы систем так спорят? Надо вспомнить о философских, онтологических основаниях. Что такое система? Это способ без обращения к вечным платоновским идеям, без говорения об «вечной» онтологии как-то временно (на время проекта) выделить из действительности новый объект для каких-то субъективных целей. Именно субъективных, а не платоновски-объективных и вечных. Помните – «система в глазах смотрящего»? То есть нужно в проекте определить границы системы и работать с этим новым объектом. И когда прибегают онтологии и говорят: «А правда ли, что ваша система существует в мире?», вы их отгоняете и говорите: «нет-нет, что вы, эти системы не существуют в мире, это всё неправда, это мы временно, для целей проекта всего только обозначили границы, и это будет наша система, не больше». Мы тем самым вводим новое понятие, но не претендуем на его предельный онтологический статус.

Когда люди говорят о системе систем, то пытаются напомнить, что объявленная ими целевая «своя» система состоит из «чужих» систем, каждая из которых в глазах другого, «чужого» смотрящего! И это полностью не соответствует взгляду, когда я владею системой и я сам выделяю подсистемы, определяю их связи. Система систем тем самым – это система одного, «увиденная» этим одним из систем, «увиденных» и владеемых другими.

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

Всё вот это – системный подход и системная инженерия – это метауровень для метода системной инженерии. Мы немножечко коснёмся на Конференции моделирования, документирования знаний и управления знаниями в системной инженерии. В частности, мы тут, на Конференции, обсудим ситуационную инженерию методов. Присутствующие Дональд Файерсмит и Цесарь Гонсалес-Перес являются представителями сообщества, которое имеет опыт обсуждения всего этого, которое занимается этой проблематикой много лет, которое выпускало на эту тему стандарты. И мне очень приятно, что на Конференции возможна эта дискуссия на международном уровне, докладчики приносят всё самое новое, что появляется в этой области. И очень приятно, что это новое, может быть, появится сейчас и в этом зале в течение ближайших двух дней.

Далее – очень интересный разворот. Кроме проекта видения 2020 системной инженерии в INCOSE есть проект, который называется BKCASE, это создание Body of Knowledge для системной инженерии, набора знаний по системной инженерии, который планируется использовать в качестве образовательного ресурса.

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

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

У присутствующего здесь Дональда Файерсмита, например, есть веб-сайт www.opfro.org, который показывает пример структурного отображения подобных знаний. Дональд возглавляет консорциум OPF, который некоторое время назад выполнил работу по структурированию знаний о компонентах метода системной инженерии и представил эти знания в соответствии с метамоделью, очень похожей на метамодель ISO 24744. И мы видим тут рабочий пример для предлагаемого нами проекта каталога методов – и содержание OPF посвящено системной инженерии, и форма – близкую к стандарту представления компонент метода ISO 24744, и мы тем самым видим, что есть принципиальный подход к ответу на вопрос о способе документирования знаний системной инженерии, решающем проблему множества языков, который постоянно задается тут в зале.
Я повторю этот вопрос: «Если вы описываете систему систем и если вы описываете полный жизненный цикл, то как вы объедините все эти сотни и тысячи потребных для такого описания языков, все эти миллионы описаний объектов, из которых состоит атомная станция (от описания управления персоналом, например, до описания того, как устроена прокладка в каком-то клапане и описание материала, из которого сделана эта прокладка). Как вы это всё единообразно опишете?»

Ответ на этот вопрос прост -- у нас есть онтологический стандарт ISO 15926. И, в частности, этот стандарт позволяет делать каталоги. Вот те промышленные каталоги, которые уже прозвучали минимум в двух презентациях (Росатома и Судоэкспорта) на нашей Конференции.

Всё, что я говорю – я говорю, что давайте мы добавим к этим каталогам продукции каталог методов. Давайте к каталогам комплектующих в стандарте ISO 15926 (то есть в универсальном языке, «Лингва Франка», «промышленном эсперанто» – это сейчас фактически такой вот «язык для языков») мы добавим каталог компонент методов системной инженерии и давайте мы попробуем изложить в этом каталоге учебное содержание такое, которое сразу становится не учебным, а рабочим. Потому что методология ситуационной инженерии методов, которую мы тут услышим завтра в нескольких докладах, предполагает перевод учебного метода, общего метода-описанного-для-обучения в экземпляр метода – работы, которые мы непосредственно исполняем и продукты, которые мы непосредственно создаем и модифицируем этими работами. И исполняем мы эти методы, в частности, с использованием инструментов – таких, как PLM-системы, системы автоматизации и проектирования САПР, системы автоматизации машиностроения.

Вы можете посмотреть остальные строчки на слайде, там примерно такая же объемная дискуссия по каждой строчке. Я думаю, нам хватит на много лет обсуждать вот такой даже один слайд, потому что это и есть выписанные текущие проблемы системной инженерии. Это то, что системные инженеры внутри себя ещё не «утрясли», не «утрамбовали», ещё не знают, как отвечать на возникающие по этим темам вопросы, и что положить в этот самый Body of Knowledge (корпус знаний, набор знаний).

Также у нас есть множество разных других проблем, решения которых как компоненты метода можно классифицировать по предложенной ISO 24744 классификации. Это уже рассмотрения «внутри» метода системной инженерии. Например: традиционная дискуссия про методы управления временнЫм циклом. Гибкость против водопада (agile vs. waterfall), взаимная координация против плана, давнее обсуждение. Фактически эта же дискуссия и в управлении проектами. Управление проектами иногда понимается более узко, как планирование, а иногда и более широко, включая установление вида разработки, вида жизненного цикла. Как управлять жизненным циклом -- управляют ли жизненным циклом инженеры или же им управляют проектные менеджеры? Это тоже традиционный вопрос.

Как мы координируем временнЫе циклы множества контракторов, потому что у каждого контрактора, как вы понимаете, свой план, но есть и общий план. Как все эти планы совмещаются? Потому что это совмещение подразумевает ещё и инженерный процесс, а не только менеджерский, проектно-управленческий процесс. Каким образом мы раскладываем в жизненном цикле ответственность, полномочия, инструменты и инфраструктуры? Для этого тоже существует своя организационная теория. В частности, я особо бы подчеркнул подход DEMO, предложенный профессором Ян Дитцем. Он уже бывал в России, и я надеюсь его увидеть на одной из наших ближайших конференций.

Управление проектами само по себе вызывает взрыв разных мнений, потому что системные инженеры говорят: «Конечно, управление проектами внутри системной инженерии». Когда вы послушаете, что говорят управляющие проектами, вы увидите, что они фактически потихонечку-потихонечку от версии к версии своих Body of Knowledge увеличивают объём знаний, который они забирают из зоны ответственности системных инженеров.

Если вы посмотрите текущий PMI PMBoK, то там уже чуть ли не главами цитируется то, что должны делать не управляющие проектами как управляющие менеджеры, а как системные инженеры. Но управляющие проектом считают, что наоборот. Они-то управляют проектом, а инженеры – они рядом, не управляют «по определению». Существует большая дискуссия по этому вопросу. Какая школа управления проектами используется в системной инженерии? Вы видите на слайде, их довольно много. Наиболее знаменитая – это, конечно, PMI PMBoK. Есть ещё PRINCE2. Есть ещё теория ограничений (Theory of Constraints) в основе школы P2M. Есть ещё школа LastPlanner – это из так называемого Lean Project Management в строительстве. И есть методы управления проектами, разработанные в рамках многих других школ. Какие из этих методов используются системными инженерами, как именно они сочетаются с собственно инженерной деятельностью? Кроме управления проектами есть и множество других аналогичных тем: интегральные команды, виртуальное сотрудничество и так далее – это все те проблемные вопросы, которые мы фактически не будем обсуждать на Конференции. Единственное, что эту тему (в частности, Lean Six Sigma и системная инженерия) затронет Виктор Николенко, это будет буквально через несколько минут.

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

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

Но всё-таки подготовка у инженеров по этим двум системно-инженерным специализациям должна быть разная. В одном случае работа с людьми, в другом случае дополнительная подготовка по сложному моделированию и синтезу моделей. Но и та и другая специальная подготовка относятся к подготовке системных инженеров. На Конференции мы будем обсуждать инженерию безопасности и защиты, которая есть фактически во всех проектах. Как сделать так, чтобы она вошла в корпус знаний системной инженерии?
Опять же мы оставляем за пределами нашего обсуждения на конференции вопрос: может быть, нужен полностью новый набор дисциплин? Может быть, этого чуть коснется Цесарь Гонсалез-Перес в своем докладе, потому что он предлагал в своем проекте OpenMetis высокоуровневое моделирование, низкоуровневое моделирование, которые мы можем обсуждать либо как стадии жизненного цикла, либо как просто новые дисциплины системной инженерии. Когда вы занимаетесь высокоуровневым моделированием, это примерно эквивалентно архитектурной работе. Но если вы послушаете доклад Яна Александера, то вы с удивлением обнаружите, что одновременно эта же работа является инженерией требований. Одновременно с разработкой архитектуры происходит открытие, обнаружение требований (Requirements Discovering). Вы делаете архитектуру и получаете требования фактически в одном процессе.

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

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

Фактически положение тут бедственное. Когда вот эти мои слайды дошли до членов INCOSE UK, то один из тамошних лидеров мне прислал письмо, в котором он заметил: «Ты написал неправильно "мегамодель", а не метамодель». Потому что он знает только слово «метамодель». Мне пришлось ему сказать, что слово «метамодель» я, конечно, знаю, но ещё великий военный инженер, великий системный инженер, великий программный инженер Барри Боем сказал, что существует еще и мегамодель. Мегамодель -- это совокупность всех тех моделей и метамоделей, а также конфигурационных моделей этой совокупности описаний, всех тех нотаций, которые с этим связаны, модельных трансформаций и всего остального того, что как-то связано с моделированием в комплексном проекте. Когда у вас сотни разных моделей на разных языках, они как-то связаны друг с другом, у вас есть куча версий, у вас есть множество метамоделей для них, и вы должны как-то этим управлять, тогда у вас появляется отдельный объект, и он называется «мегамодель».

Сейчас понятно, что мы имеем хотя бы какой-то подход к говорению об этой мегамодели, в частности, ISO 15926 может помочь единообразно выразить эту мегамодель. Но это еще совсем неочевидно, когда это все случится. Я надеюсь, что, может быть, присутствующий тут доктор Ханну Ниемисто что-то об этом скажет, потому что он работает как раз над объединением в одну мегамодель ряда имитационных моделей реального времени (real-time).

Про системы систем, о которых тут уже много говорилось, я в связи с видами рабочих продуктов сейчас промолчу. Про семейства систем, например, семейства ядерных реакторов или семейства выпускаемых судов, или подразумевающую семейства каких-то технологий Smart Grid, я тоже сейчас промолчу. Технологическая платформа, системы с людьми – это тоже всё оставим для будущих Конференций.

Виды моделей, языки, метамодели, нотации. Нам каким-то образом надо договориться о том, как мы об этом всём будем говорить. Проблема в том, что системная инженерия заявляет, что она является методом изготовления любых систем, гордо подчёркивая «любых». Вы помните, что полгода назад говорил в этом же зале автор стандарта ISO 15288 доктор Гарольд Лоусон: «Наше грандиозное достижение в том, что мы сумели сделать стандарт, который делает такое заявление об общности метода. То есть мы сумели сделать такое общее описание практики системной инженерии, в котором мы говорим о производстве спичек и о производстве космических ракет на одинаковом языке». Но это хорошо говорить на уровне практик, когда ты говоришь, что «я делаю требования, я делаю архитектуру». А когда ты начинаешь смотреть архитектуру ракеты и архитектуру спички, выясняется, что для представления этих архитектур нужны совсем разные языки.

Системная инженерия сделала заявление, что она будет легко говорить и о практиках, и системах, не имея внутри себя фактически никакого обсуждения про используемое многообразие нотаций, про вот эти вот языки, про формальные модели, про онтологии. Онтологическое движение в системной инженерии только-только появляется, и мне очень хотелось бы, чтобы мы на Конференции поговорили, как это реально происходит в нынешней системной инженерии. В частности, обсудили семантическую, онтологическую интеграцию мегамоделей (мегамодель – мы только говорили об этом понятии). И в программе Конференции на эту тему не только ISO 15926, но и проект Simantics, который по очень похожим на ISO 15926 принципам, но применяя их по-другому и к немного другим объектам -- real-time моделям имитационного моделирования, simulations.

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

Тут же старинный вопрос: у нас бывают только модели системы, или, может быть, ещё бывают и другие типы моделей – например, модели требований? Этот вопрос надо поднимать в явном виде. Как мы объединяем модель системы и модель требований? Только ли используя систему DOORS? Ведь через некоторое время выяснится, что системы DOORS нам недостаточно в силу того, что точности, в которой мы храним эти модели в текстовом виде в системе DOORS, не хватает для поддержки работы систем автоматизации проектирования.
Модели стоимости – это предмет нашей конференции. И я ожидаю по моделям стоимости, в частности, связанным с архитектурой, очень интересное выступление от Тайсона Браунинга. Сама инженерия системной архитектуры, с которой связаны модели стоимости, пока не главная тема конференции, но неявно и она представлена – например, Дональд Файерсмит книжку об этом написал, и у него есть метод инженерии системной архитектуры.

Порождающее проектирование, доказательные инженерные обоснования (assurance case) обсудить не успеваем. Я думаю, для этого надо будет делать отдельную, специальную конференцию.

Виды акторов: люди, инструменты. Фактически это обсуждается состоящая из них организация. Замечу, что ни инструменты, ни организация не вошли в ISO 15288, а также не вошли по факту в учебник системной инженерии INCOSE. Почему? Доктор Гаролд Лоусон сказал об этом так: «К сожалению, к нам, инженерам, в рабочую группу пришли в больших количествах люди -- менеджеры, которые разрабатывали стандарт ISO 9000. И мы хотели по-инженерски сделать раздел в ISO 15288 про структуру организации, но мы не смогли ничего добиться, нам оставили только описание практик».

Что касается учебника системной инженерии INCOSE, то произошло примерно то же самое. У нас в INCOSE есть и представители менеджеров, которые действительно увидели в системной инженерии прежде всего только процесс. Роб Хаманн заметил мне на EuSEC2010: «Как же инженеры могут иметь дело только с процессом? Такого же не бывает, потому что кроме процесса обязательно надо иметь структуры, надо иметь описания инструментов, надо понимать, кто это делает, то есть видеть всю картинку, все элементы. У NASA, – говорит, – лучше учебник системной инженерии, потому что там много больше было оставлено про структуры и инструменты. А у INCOSE получилось хуже, потому что менеджеры при пересмотре аккуратно вычеркнули там сугубо инженерные части про структуру, интересные именно для инженеров, а не менеджеров».

Поэтому в описаниях системной инженерии сейчас превалируют «чистые процессы» по мотивам ISO 9000. Я думаю, что нам надо срочно исправлять эту ситуацию. Я думаю, что это исправление является одним из важнейших положений как доклада Дональда Файерсмита, так и Цезаря Гонсалеза-Переса. Нужно также возвращать обсуждение людей и инструментов в составе методов системной инженерии. Нельзя рассматривать только процессы и практики, но нельзя и только железки, не обсуждая также то, какие люди, какими инструментами работают этими процессами и практиками с этими железками.

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

Практики моделеориентированной системной инженерии. Их фактически мы успеем рассмотреть хоть как-то всего четыре. Это моделеориентированный процесс разработки (development process) или поставки (delivery process). Практики моделирования стоимости в рамках всего жизненного цикла. Моделирование в инженерии требований. Моделирование в безопасности и защите. И это как бы центр, основное содержание Конференции, ее предмет.

Но с каких позиций мы будем это содержание рассматривать?

С позиции ситуационной инженерии методов, потому что мы будем рассматривать не просто: «Ну, вот я тут делал что-то». А я буду смотреть на себя рефлексивно, как бы со стороны и говорить: «Я что-то делаю и вижу в этом способ, метод которым я это делаю». То есть я не говорю: «Вот я делаю так, так, так». А я говорю: «Обратите внимание, это отчуждаемый метод -- способ, которым я делаю так, так, так».

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

С позиции методов онтологической инженерии и семантики. Онтология и семантика – это тот язык, на котором надо говорить, чтобы договориться обо всём, потому что мы имеем столько много разных языков и нотаций даже в этих немногих упомянутых моделях! Плюс мы имеем ещё один язык, которым мы будем описывать метод работы, и мы должны как-то ухитриться все эти модели склеить друг с другом. Причём желательно ещё так склеить и «разжевать» это склеенное модельное знание настолько детально, чтобы понял не только человек, но и компьютер. Почему мы говорим не только об онтологиях, но и о семантике? Потому, что историки, юристы любят поговорить об онтологиях. Но мы говорим ещё «семантика», потому что семантика – это когда эта онтология разжёвана настолько хорошо, что даже компьютер её понимает, даже тупой компьютер понимает значения используемых в моделях символов.

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

Спасибо.

Сохранено