I. Инженерные (в терминах ISO 15288 -- технические, technical) дисциплины/практики моделеориентированной системной инженерии:
1. Инженерия системных целей
Это дисциплина об обеспечении выявления всех стейкхолдеров и согласования их отношения к разработке. Это социотехническая дисциплина, она про человеков. Инженеры целей (можно по-старинке называть их инженерами по требованиям, но я пока буду называть их по-другому, чтобы не путать с традиционным пониманием) должны представлять в инженерном проекте позиции всех явных и неявных стейкхолдеров: пользователей, регуляторов, заказчиков, разработчиков, природы, злоумышленников, третьих лиц, которые можно зацепить экстерналиями и т.д., а затем делать функции системы.
Тут не столько GORE (ибо в GORE важнее всего сцепка целей и средств, а средства дают инженеры-архитекторы), сколько именно работа с людьми и выяснением их целей в виде, достаточном для начала высокоуровневого (архитектурного) моделирования. Кроме этого, тут же практики согласования целей (прежде всего -- конфликтологические), если архитекторам не удаётся придумать систему, которая удовлетворит всех.
Безопасность (и тем самым требования технического регулирования) и защита (моделирование угроз) -- тоже сюда. По Дональду Файерсмиту инженеры по безопасности и защите -- это системные инженеры, они думают о системе в целом, а не об отдельных её конструктивных аспектах. Вот те, которые думают об источниках угроз и разбираются, какие из них насколько реальны -- они и будут задавать цели разработки.
2. Высокоуровневое моделирование -- инженерия системной архитектуры
Функция системы задаётся инженерами целей, но вот конструкция в терминах подсистем -- архитекторами. В моделеориентированной системной инженерии всё то же самое, что в традиционной, только архитектурные идеи и затем оптимизация архитектуры во всевозрастающей степени обеспечиваются порождением из моделей целей, более высокоуровневых архитектурных моделей, плюс используются библиотеки справочных данных в части архитектурных решений. Опять же, результирующие модели будут служить в качестве отправных точек для порождающего проектирования в инженерии по специальностям), так что именно в этой практике будет выдача заданий по проектированию инженерам по специальности (включая понимание, какие вообще специальности тут потребуются -- это как раз задача системных инженеров-архитекторов).
3. Низкоуровневое моделирование -- мультифизика, мегамоделирование.
Порождающее проектирование (generative design) по отдельным специальностям -- это круто, но это не системная инженерия. Архитекторы выдали задание на проектирование инженерам по специальности, но затем результаты этих частных моделирований (порождённые модели) собираются под контролем конфигурации в одну мегамодель, чтобы иметь возможность быть проверенными.
Системная инженерия -- это мультифизика, сборка всех моделей по специальности в одну мультифизичную модель, под контролем конфигурации. Из множества независимых предметных моделей нужно сделать одну мегамодель, при этом добиться её исполняемости.
Это уже не архитектура, но ещё и не обеспечение качества (хотя целью сборки одной модели из многих отдельных моделей является именно снятие возможных инженерных коллизий, неизбежных при раздельном моделировании предметов отдельных инженерных специальностей).
Опять же, приводимое разбиение на практики не догма, но специалисты по низкоуровневому мультифизическому моделированию сильно отличаются по своему эээ... менталитету и от системных архитекторов, и от тестировщиков/спецов по качеству. Так что я бы эту практику мегамоделирования (комплексирования моделей) выводил в отдельную.
4. Обеспечение качества
Качество -- это сответствие системы ожиданиям. Для определения качества нужно сопоставить систему (или её модель) с ожиданиями (данными также в виде модели). Это верификация. Но качество или его отсутствие нужно не только эксплицировать (традиционным способом "сделать невидимое видимым" -- дать модель разницы целевого и наличного), его ещё нужно обеспечить.
Обеспечение качества -- это разные инженерные (а не операционные, "управленческие", логистические пересаживания квартета исполнителей по разным стульям) стратегии по тому, как обеспечить соответствие системы ожиданиям. Можно попросить доработать напильником по месту (советский способ), можно изменить процесс так, чтобы потом (на следующих прохождениях) никаких доработок по месту не требовалось (цикл Деминга). Главное -- это принять инженерное решение, что делать. А это решение должен принимать тот, кто породил проблему, ибо "за проверку отвечает исполнитель, а не заказчик". Заказчик должен вынимать из коробки, и пользоваться.
Поэтому я бы объединял верификацию (порождённой системы и модели на соответствие их более высокоуровневым моделям и справочным данным) и инициирование изменений в случае обнаружения некачественного порождения. Ага, "управление изменениями" -- это операционная дисциплина, но меня тут волнует инженерный аспект: в какой форме выдаётся запрос на изменения, как минимум (модель расхождений -- но как выглядит такая модель, в том числе в случае мультифизического моделирования, и какие инженерные решения по ней можно принять?!).
Валидацию я сюда не включаю, это не про проверку правильности трансформации модели или вещества, а про приёмку -- возможность нанесения непоправимой пользы стейкхолдерам.
5. Порождающее производство в части интеграции
Порождающее изготовление комплектующих (из бит в атомы) очень-очень условно можно отнести к инженериям по специальностям. Но вот интеграцию отнести уже нельзя. Кто-то должен обеспечить изготовление целого "под ключ" -- будь то изготовление из сырья, или изготовление путём сборки из уже готовых элементов. Эту сборку можно делать на заводе, можно (в случае больших изделий) -- прямо на объекте. В любом случае, кто-то должен брать на себя ответственность за сборку и наладку целого "под ключ".
Моделеориентированность интеграции означает прежде всего то, что появляется возможность автоматизации последних стадий интеграции -- множество роботов могут договорится (на основании мегамодели конструкции), как им собрать (или напечатать, или ещё каким-то другим образом явить миру) целевую систему в состоянии "под ключ".
Речь тут не идёт о чисто логистическом аспекте (когда комплектуюущее проходит свой жизненный цикл производства, затем транспортируется на склад сборочного предпринятия, выдаётся в монтаж, транспортируется к месту сборки, устанавливается и там проверяется). Речь идёт как раз об инженерном аспекте: режимы изготовления, что к чему с какой силой прижимается, как приваривается-прикручивается, какая должна быть последовательность сборки, чтобы минимизировать проверки, и т.д.
6. Приёмка (валидация)
Любимая моя рассказка про валидацию (приёмку, которая про "истинное" удовлетворение клиента, в отличие от проверки, которая про качество и число дефектов-отклонений на миллион изделий) -- это попытки накормить Тигру (http://readr.ru/alan-miln-vinni-puh-i-vse-vse-vse.html?page=29). Тигра на словах (в отобранных инженером по требованиям в тщательно организованном интервью) очень любил мёд, жёлуди, чертополох и т.д. -- но когда ему поставлялись эти тщательно проверенные продукты, его приёмка показывала, что по факту (а не по техзаданию) Тигры этого не любят, т.е. цель "быть сытым" не достигалась.
Тут я пока про моделеориентированность ничего сказать определенного не могу, но дам намёк: sentiment analysis (оценка эмоций в высказываниях) по поводу той или иной продукции, о которой пользователи упоминают в блогосфере, становится важной практикой, и относится, безусловно, к валидации.
7. Эксплуатация и поддержка (operations and mainteinance)
Ремонтопригодность -- это свойство обеспечивающей системы, отказы и ремонты тоже нужно моделировать. Модели износа/надёжности для принятия решений по запасам комплектующих и сроках ремонтов ("ремонт по состоянию").
Сюда же я отношу начальный ввод в эксплуатацию (практику передачи в эксплуатацию традиционной системной инженерии -- transfer), все эти "опытные" и "промышленные" эксплуатации, "поэтапные вводы" и прочие старт-стопы. Ибо эти практики уже в существенной мере зависят от эксплуатирующего персонала. Аспекты DevOps, разведение ремонтной, эксплуатационной и вводной в эксплуатацию деятелности -- это я считаю пока входящим в "моделеориентированные O&M".
8. Мусоропереработка
Вывод из эксплуатации я бы отнёс к практике эксплуатации и поддержки в части отработки старт-стопных и аварийных состояний, существенно связанных с пользовательскими аспектами функционирования системы и зависимостью пользовательского предпринятия от работоспособности системы. Но только вплоть до мусоропереработки. Но вот мусоропереработку давал бы отдельной практикой -- собственно момент "вывода из эксплуатации" обеспечивает эксплуатационно-ремонтный персонал, а вот мусоропереработку "того, что осталось" обеспечивают уже совсем-совсем другие, специално обученные люди.
9. Инженерия знаний, нормативно-справочной информации, справочных данных
Это очень существенный пункт, и я много об этом написал во втором постинге серии -- http://ailev.livejournal.com/1026036.html
Ну, и дал более развёрнутую характеристику тут: http://ailev.livejournal.com/1021613.html (в том числе разведя "инженерию" и "управление" знаний, НСИ и справочных данных).
Я считаю, что метрологию (измерения) -- сюда же, это обычно общие для всех проектов знания.
Этот пункт очень-очень хочется записать целиком в "управления", но не будем этого делать. Тут специалисты-когнитологи разговаривают со специалистами-инженерами. И никаких "логистиков" или "управленцев".
II. Операционные практики в терминах ISO 15288 были "проектными" и "обеспечения проектов" (project enabling). В моделеориентированной системной инженерии мы бы говорили об "управлениях", т.е. логистике предметов инженерной работы между инженерами-выполнителями, или так же традиционно об "инженерных сервисах" (подробнее я писал об этом в http://ailev.livejournal.com/1005515.html):
1. Управление конфигурацией
-- практика выпуска (release) инженерных артефактов (в нашем случае -- моделей и их частей), в том числе hand-over данных. Это о том, как отслеживать целостность мегамодели и системы-в-железе, а также соответствие их версий друг другу.
-- практика запросов на изменения (запросы иногда заканчиваются изменениями проекта)
-- практика изменения проекта (изменения проекта иногда заканчиваются выпуском)
-- практика выпуска [сводных] заказных спецификаций (BOM, bill of materials). Это про то, как из мегамодели выдирать правильные с точки зрения организации логистики куски ("нарезать мир на объекты работы, к которым дальше применяются логистические процедуры -- т.е. куски работы, которые перемещаются между инженерными организациями")
-- практика работы с вариантами (variant management)
Тут упор больше на инженерный аспект состояния объекта работы. Но это не инженерные практики (решения не столько инженерные, сколько решения по гранулярности/крупности определения объектов, связанные с удобством логистики -- движения битов и атомов по выполнителям инженерных работ. Тут главным образом определяется, что будем двигать, и как это версионировать и именовать.
2. Управление кейсами
Нужно как-то собрать в одно место логистические практики -- все эти "управления" программами, проектами, процессами, цепочками поставок, изменениями и т.д. -- логистику потока работ и предметов работ по выполнителям. Это и назовём "управлением кейсами" -- типовыми и уникальными, по заранее созданным планам, и динамически планируемым, с использованием специфического проектного сленга и софта, и с использованием процессного сленга и софта, и даже в их экстремальных agile вариантах.
Именно тут "исследование операций", от расчётов factory physics в supply chains до автоматизации во всяческих Multi-D -- когда информация о 3D и знания по технологии изготовления/сборки/стройки/монтажа кладётся в основу порождения графика.
Тут же -- управление портфелем проектов/кейсов, ибо это завязано на маржинальный подсчёт выгодности проекта, а factory physics и throughput accounting -- две стороны одной медали (поток денег обратен потоку комплектующих и работ по сети выполнителей предпринятия).
Упор больше на аспект планирования-исполнения и ресурсах, нежели инженерный аспект состояния объекта работы, как это делается в управлении конфигурацией. Тут определяем, как и когда будем двигать те объекты, которые заданы в управлении конфигурацией.
3. Управление информацией
Под "информацией" будем понимать всю совокупность из неэксплицированного и недокументированного знания "в головах", залежи документации на естественных языках, а также формальные записи aka "данные".
Тут грубо можно выделить:
-- управление проектными данными (чтобы нужные заинтересованным сторонам данные оказывались у них в нужное время. Да, "управление требованиями", как часть инженерии требований, отвечающая именно за то, чтобы требования адекватно хранились и адекватно предоставлялись по запросам заинтересованных сторон -- это часть именно этой практики. Ибо нет никаких особенностей именно у "управления требованиями" в отличии их от управления любыми другими данными. Ну, и помним, что слово "управление" тут ничего не означает, как обычно. Никаких управленцев в управлении данными!).
-- управление знаниями, НСИ, справочными данными -- ну, тут уже много было написано в http://ailev.livejournal.com/1026036.html и http://ailev.livejournal.com/1021613.html, речь идёт об управлении информацией, требуемой для многих проектов.
III. Вот несколько проблем, которые хотелось бы прояснить на следующем проходе (не говоря уже работы с полным списком дисциплин стратегирования-инженерии-операций в разрезе как основной деятельности, так и развития -- http://praxos.livejournal.com/14905.html):
1. "Управление информацией" (управление "битами") выделено в отдельную логистическую практику. Это, конечно, хорошо при архитектуре и проектировании, но когда от мегамодели-в-битах переходим к частям системы-в-атомах и полной системе-в-атомах (порождающее производство), то правильно бы что-то понять про порождаемую логистику "атомов".
2. Управление решениями, по идее, это "согласовательные техники", и ими должны заниматься инженеры по целям/требованиям (у них наиболее профессиональная подготовка в этой части). Грубо говоря, "упадёт ли мост" не должно решаться голосованием, для этого есть более продвинутые технологии коллективного принятия решений. С другой стороны, обеспечение качества -- эти люди как раз занимаются инженерными обоснованиями. Так что принятие коллективных обоснованных решений -- это должна быть их инициатива. В любом случае, в "управление решениями" сейчас записывают не только форму фиксации результатов решений и далее маршрутизацию принятого решения для тех, кому эти решения были нужны, но и инженерную составляющую "метода коллективного думания". Я бы считал, что модели решений такие же, как любые другие, и поэтому не выделял бы документирование, хранение и дистрибуцию решений как особый вид "управления информацией". Но выделять ли в отдельную практику инженерную составляющую, пока непонятно.
3. Управление рисками и управление стоимостью любят выделить в отдельные практики "инженерных сервисов", причём они не столько операционные, сколько инженерные. Я бы считал, что это глубоко вмазано в основные инженерные дисциплины системной инженерии, а не выделено во что-то отдельное. Оценки рисков и стоимости должны делаться прямо в ходе основного (и прежде всего -- верхнеуровневого) моделирования, а не "сбоку" специально приставленными к архитекторам людьми. Тут можно ещё поразлагольствовать, что стоимостей-себестоимостей не бывает, а должен считаться througput -- но пока не будем решать, как делить работу с деньгами между архитекторами (стоимость комплектующих) и управляющими кейсами. Я бы относил througput accounting к управлению кейсами. Ибо стоимость... тьфу, проход комплектующих существеннейшим образом зависит от времени и определяется общей логистикой, а собственно "инженерная" часть будет носить подчинённый характер (хотя бывает и наоборот -- но это пока мне кажется недостаточным поводом выносить работу с деньгами в отдельную практику. Деньгами должны быть озабочены все).
4. Отдельно стоит также вопрос, кто интегрирует между собой все инженерные дисциплины и инженерные и сервисные/операционные дисциплины. Все эти "кто системный инженер для всех этих архитекторов, требовательщиков и т.д.", а также "кто главней -- системный инженер, или операционный менеджер". Напомню, что в исходном списке дисциплин предпринятия есть ещё и низкоуровневое, и высокоуровневые стратегирования (http://praxos.livejournal.com/14905.html), и поэтому отвечать на этот вопрос в рамках данного постинга неправильно.
5. Закупка и поставка (и связанные с ними hands-over) так же имеют неопределённый статус в числе инженерных и операционных практик системной инженерии. Ибо нет "профессиональных закупщиков" и "профессиональных поставщиков", там конгломерат каких-то других практик, и с этим нужно устраивать отдельную разборку.