Анатолий Левенчук - Системная инженерия – 2022

Скажем, для создания текущего курса «Системная инженерия» можно использовать конкретизированную схему «образовательного проекта»:: «проекта создания»/«инженерного проекта» (и тут даже приведены названия конкретных организаций, которые связаны с проектом, ШСМ и INCOSE RUS, при этом в области интересов надсистемы/окружения могут находиться альфы, как-то связанные с разными системами в окружении, например альфы и связанные с ШСМ, и связанные с INCOSE RUS):

Эта схема также может читаться двумя способами:

• создание и непрерывное ведение курса (иногда такое называют «вечная бета») в целом, со всеми его версиями

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

Если вы будете создавать «систему найма сотрудников»:: «проект оргразвития», то это третий уровень конкретизации, конкретный проект в организации, ситуационная мета-модель уровня стандарта предприятия и модель конкретной проектной ситуации с учётом экземпляров (операционным учётом). На втором уровне конкретизации (культурная мета-модель) это будет предметная область на каком-то достаточно абстрактном уровне учебников менеджмента как прикладной дисциплины инженерии предприятия, то есть «проект оргразвития»:: «проект создания»/«инженерный проект». А сам «проект создания»/«инженерный проект» – это самый общий уровень, наименее конкретный, безмасштабный/фундаментальный, то есть создание чего угодно, уровень рассмотрения нашего курса системной инженерии, уровень мета-мета-модели. И не путайте системные уровни (отношение часть-целое) и уровни абстракции (отношение принадлежности к классу, конкретизация как противоположная направленность абстрагирования как раз тут).

Такой подход многоуровневой конкретизации инженерного метода решает и традиционные проблемы классического подхода к инженерии как отдельной от менеджмента. В классической системной инженерии как инженерии сложных киберфизических систем обычно вынуждены описывать менеджмент проектов создания самолётов и подводных лодок как «системноинженерный менеджмент». Если понимать, что речь идёт об инженерии организации, которая будет заниматься созданием киберфизической системы, то это просто описание двух инженерных проектов в цепочке создания: создание киберфизической системы (самолёта или подводной лодки – концепция использования, use cases для них, архитектурные решения, и т.д.) и создания организации проекта (стратегия этой организации как концепция использования и use cases организации/команде/коллективу/предприятия/«производственной кооперации» проекта, решения по концепции системы, архитектурные решения для предприятия как архитектурные решения по организации проекта, и т.д.). Эти проекты существенно связаны в части архитектуры целевой системы и организации (через закон Конвея и обратный манёвр Конвея), и эту связь реализуют архитекторы. Архитекторы целевой системы и организации согласуют их архитектуры и меняют их по мере развития целевой системы.

А чему учить тогда системных инженеров, например, классических киберфизических систем? Учить нужно так же многоуровнево:

• общей безмасштабной и непрерывной системной инженерии, это и есть предмет нашего курса/книги

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

• затем конкретизации этой инженерии для самолётов (конкретная предметная область, и это будет весьма разная инженерия для одномоторного одноместного самолёта и авиалайнера на три сотни пассажиров – domain), и доводят это до узкой практики, которая используется в конкретном проекте (и тут говорят про ограниченную предметную область, workflow/practice как bounded domain).

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

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

Ответственность за всю систему на многих уровнях как целое (whole system) и связанная c этим фундаментальность/трансдисциплинарность/transdisciplinarity подхода к другим инженериям (механической, электрической, программной, предприятия и т.д.) отличают системную инженерию от всех её частных/предметных/domain конкретизаций. Представим себе ледовую буровую платформу:

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

Какая инженерная/деятельностная/практическая/трудовая дисциплина должна учесть результаты работ всех других инженерных дисциплин, работающих на самых разных системных уровнях – собрать в единое целое данные ледовой обстановки, санитарных норм в помещениях для обслуживающего персонала, обеспечение электричеством попавших туда компьютерных серверов, необходимые характеристики этих серверов и программное обеспечение с нужными функциями и нужной надёжностью? Кто озаботится учётом в конструкции платформы изменений в длине металлоконструкций за счёт разницы суточных температур и одновременно установкой акустических датчиков на трубах, которые прослушивают шорох песка, чтобы по этому шороху нейросетевые алгоритмы определяли износ труб и предлагали редкий и нужный «ремонт по состоянию» вместо относительно частого и бесполезного «планового/профилактического ремонта»?