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

1. Системная инженерия
как технология мышления
29 января 2015г.

2. Запрос: «Системная инженерия как технология мышления»
Николай Верховский:
• Как происходит проблематизация в СИ [4]
• Как происходит объективация в СИ [2]
• Как происходит Схематизация [3]
• Как формируется позиция [1]
Считайте это рефератом для попадания на Чтения-2015
Наши баксы – это ихние доллары!
• СМДМ: «Системная инженерия» – что это?!!
• СИ: «Технология мышления» -- что это?!!
• СИ: «проблематизация», «объективация», «схематизация»,
«позиция» -- что это?!
• СМДМ, СИ: ложные друзья переводчика: технология,
логика, практика, дисциплина, метод, проблема
2

3. Самоопределение
• Тематическое
• Моя тематика: мышление в системной инженерии + начат разворот
в технологичный менеджмент (technology management)
• Вопрос: задан в терминах СМД-методологии
• Методологическое
• Сейчас – системное мышление на базе международных стандартов
• Давно – СМД-методология (т.е. могу понять вопрос)
• Практико-методологическое
• Системная инженерия (и инженерия предприятия)
• Ситуационная инженерия методов, архитектура предприятия
• Computational ontology, инженерное моделирование
• Позиционное (социальное)
• Методолог системной инженерии
• Учебный курс системноинженерного мышления:
http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--
TechInvestLab_2014.pdf
• создание схемного языка системного моделирования SysMoLan,
http://ailev.livejournal.com/1127145.html
• Онтолог (выпустил онтологический редактор, есть исследования)
• Консультант и преподаватель (клиенты и студенческие группы)
• Посол западных технологий мышления в СМД-сообществе
(регулярно делаю доклады) 3

4. Системная инженерия: борьба со сложностью
4
Systems Engineering (SE) is an interdisciplinary approach and means to enable the
realization of successful systems. It focuses on holistically and concurrently
understanding stakeholder needs; exploring opportunities; documenting
requirements; and synthesizing, verifying, validating, and evolving solutions while
considering the complete problem, from system concept exploration through
system disposal.
http://www.sebokwiki.org/1.0.1/index.php?title=Systems_Engineering_%28glossary%29

5. Что инженерим: вид целевой системы
5
Июнь 2015

6. Что инженерим: какие системы участвуют в проекте
• Использующая система (часто социотехническая) –
системы в операционном окружении
• Целевая система (всякая бывает: инженерия
предпринятия, инженерия предприятия) и
системы в её составе
• Обеспечивающая система (социотехническая –
системноинженерный менеджмент.
Методология/управление/практики как объекты --
тут)
6

7. Технология мышления?
(или проблемы советской инженерной школы)
7
Сколько времени нужно (и можно ли вообще) обучать студента,
чтобы проект помещался у него в голове как целое?

8. Шесть племён системной инженерии
Выделены в 2013 году техническим директором INCOSE Bill Miller:
1. Технические практики всего жизненного цикла (работа с
требованиями, архитектурой, проверкой и приёмкой, и т.д.)
2. Системноинженерный менеджмент, который тоже озабочен
практиками, только практики о другом (управление
конфигурацией, управление информацией, и т.д.).
3. Моделеориентированная системная инженерия, которая
пытается трансформировать практику использования неявных (и
часто запертых в сером веществе инженеров) описательных и
вторичных по отношению к спецификациям моделей в практику
использования явных первичных и богатых выразительными
возможностями моделей.
4. Нетрадиционные промышленные экосистемы (то есть за
пределами аэрокосмической инженерии), часто включают и
"местные" практики.
5. "Мягкие системы", системное мышление и системная наука,
которые имеют дело со сложными, вероятностными или
недетерминистскими системами.
6. Системноинженерое лидерство, заинтересовано объединить
практики всех остальных племён и уболтать их работать
сообща.
8

9. OMG Essence: Язык и Основы
9
...
Язык
(абстракция
абстракции)
Дисциплина
(абстракции)
Технология
(конкретности)
...
Практика/метод

10. Схематизация:
различение дисциплины и технологии в практике
• дисциплины = мышление (операции с абстрактными
типизированными объектами). Меняются за 30 лет. Учатся в
школе и ВУЗе.
• технологии = инструменты и рабочие продукты (поддержка
мышления в экзокортексе). Меняются каждые 5 лет. Учатся на
производстве.
• Связь дисциплин и технологий, дисциплин и жизни нужно
ТРЕНИРОВАТЬ, для этого обычно нужен преподаватель
10
В жизни ни одного
слова из учебника
В учебнике ни
одного слова из
жизни

11. 11
«Хорошая» модель/схема/язык
• Разделяемая
– Известная всем участникам
– Та, с которой все участники согласны
• Понятная
– Людям и компьютерам
– А что значит «понятна компьютерам»?
• Описывающая реальный мир
– А какой мир «реален»?
– Страшное слово – «онтология»

12. Cхематизация по версии INCOSE
12

13. Пример: методологии MBSE
(согласованные между собой наборы практик)
• IBM Telelogic Harmony-SE
• INCOSE Object-Oriented Systems Engineering
• Method (OOSEM)
• IBM Rational Unified Process-Systems Engineering
• (RUP-SE) for Model-Driven System Design (MDSD)
• Vitech MBSE (STRATA)
• JPL State Analysis
• Object Process Methodology (OPM)
• Weiliens Systems Modeling Process (SYSMOD)
• Fernandez Process Pipelines in OO Architectures (PPOA)
• An Ontology for State Analysis Formalizing the Mapping to SysML
• ISO15288, OOSEM and Model-based Submarine Design
• SysML JumpStart Training with Enterprise Architect
• MBSE Framework for Concept Development (http://seari.mit.edu/documents/theses/SDM_LONDON.pdf)
• ... их тысячи (сколько проектов, столько методов)
• Архитектурные методологии -- http://www.iso-architecture.org/ieee-1471/afs/frameworks-table.html
13
http://www.omgwiki.org/MBSE/doku.php?id=mbse:methodology

14. 14
Jean Bezivin
Model-based vs model-driven

15. Что делаем: SysMoLan
SysMoLan (Systemese): System Modeling Language
http://ailev.livejournal.com/1127145.html
«Иметь возможность нарисовать на одной схеме
системы то, что раньше рисовалось только на двух
разных, чтобы явно указать связи и обсудить».
• Ничего нового: такая была дизайн-цель ArchiMate
(прожекторный язык, факт-ориентированный).
• Отличия от SysML: в самом SysML множество
диаграмм изначально, нет языка запросов и мэппинга,
нет факт-ориентированности, нет upper ontology и т.д.
• Одновременно product и project модели
15

16. SysMoLan
• Три языка в одном (данных, прожективный-запросы, синтетический-мэппинг для «инженерии в
большом»). Проблема.
• Факт-ориентированный [как Архимейт], со внешним представлением, но не семантический
веб. Проблема.
• Графический и текстовый синтаксисы. Проблема
• Онтологический (конфигуратор для дисциплин: upper ontology, общая модель мира – против
онтик-микротеорий-без-объединения) – как ISO 15926, но со внешним представлением.
Проблема.
• Или теория категорий?! Проблема
• Требования и архитектура [как SysML]
• Гибридные вычисления [тексты и эскизы, псевдокод, код в одном флаконе]. Выход на поиск-
ориентированность. Проблема.
• Аказуальное моделирование [как Modelica и SyM]
• Киберфизические системы [как AADL]. Исполняемость [как xUML] – проблема.
• Язык как стандарт отдельно, моделеры как софт отдельно.
• Архитектурные библиотеки (как в Modelica) + каталоги продукции (как ISO 15926): поддержка
языком «инженерии в большом»
• Жизненный цикл и ситуационность (независимость от проекта) [как Essence].
• Стык product model и project model (case management и project management). Проблема.
• 20% выразительных фич должны закрыть 80% случаев использования. Проблема. Но это и
есть определение предметной области.
16

17. Откуда берутся схемы/мета-модели/viewpoints?
• Редко: в ходе решения проблем
• Чаще: из прошлых проектов
• Очень часто: из стандартов
• Что влияет на распространённость?
• Качество, выразительная сила, учебники – 5%
• Инструментарий (компьютерные программы) – 95%
17

18. Схематизация: определения и описания
18

19. Схема инженерного проекта
19
Technology
management
Engineering
management
Engineering

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

21. Технологичный менеджмент
technology management
21

22. Zoom -- select
Leidraadse (2008), Guideline Systems Engineering for Public Works and Water Management, 2nd edition, http://www.leidraadse.nl/
22
Управление вниманием: фигура и фон
Холархии: «рекурсивное применение мышления»)

23. На этой картинке стейкхолдеры есть!
Goal-oriented requirements engineering (GORE)
System of
interest
требования
System of
interest
архитектура
Using system
Нужды
стейкхолдеров

24. I* -- задаёт тон в GORE
http://www.cs.toronto.edu/km/istar/
Goal-oriented requirements engineering
1995г.: Agents attribute intentional properties (such as goals, beliefs, abilities, commitments)
to each other and reason about strategic relationships. Dependencies between agents give rise
to opportunities as well as vulnerabilities. Networks of dependencies are analyzed using a
qualitative reasoning approach. Agents consider alternative configurations of dependencies to
assess their strategic positioning in a social context.
Стандарты: 2008г. ITU-T Z.151 (Goal-oriented Requirements Language + Use Case Maps)
24
Язык
Пример модели
http://www.cs.toronto.edu/~
gelahi/Extensions.htm

25. Motivation model ArchiMate 2.1
http://pubs.opengroup.org/architecture/archimate2-doc/chap10.html
[инженерия предприятия – поддисциплина системной инженерии]
25
Язык
Пример модели

26. V-диаграмма инженерного проекта
26

27. Архитектура: главная практика системной инженерии
• Что это: важнейшие инженерные решения «прозрачного
ящика»
• Раньше: основные структуры системы, теперь (после
интернета – там структуры нет) основные принципы
организации
• Проблематизация тут (пространство проблемы, пространство
решений).
• Соединяет две деятельности: reverse engineering
(реконструирование несконструированного) и engineering
(схема Jan Dietz)
• Системнодеятельностный подход в явном виде (stakeholders и
их concerns, множество групп описаний и моделей)
• Обсуждение формы без содержания: схематизация тут:
онтология ISO 42010, её поддержка архитектурными языками
• Обучение двух сортов:
• Отраслевое, управление знаниями (паттерны и стили с
поддержкой библиотеками и инструментами)
• Универсальное, инженерия знаний (ТРИЗ, DSM)
• Обобщение для архитектурных описаний: на все виды
описаний
27

28. Проблематизация и вокруг неё
28
Практики проблематизации в ММК (по А.Буряку, XIII чтения, http://www.fondgp.ru/lib/chteniya/xiii/materials/colloquium_1/0):
1. самоопределение; [тематическое, методологическое, практико-методологическое, позиционое-
социальное]
2. ситуационный анализ; [простановка рамок]
3. целеполагание; [модельная формулировка идеала: «Не положил на рабочую доску структуру будущего
объекта - не получил цели» -- О.Генисаретский ]
4. анализ ситуации (в отличие от ситуационного анализа);
5. собственно проблематизация, или постановка и формулирование проблем;
6. перевод проблем в задачи, то есть переход к продуктивному продвижению (кстати, на мой взгляд, по-
прежнему один из самых темных моментов в этой линии технологий);
7. и, наконец, решение задач.
А.Зинченко --
http://alzin.ru/files/problem.doc

29. Стейкхолдеры  интересы  практики описаний
На основе
рис.3
в ISO 81346-1
-Модули
=Компоненты
+Места
29

30. Пример: три viewpoint для определения предпринятия
• Работы – process-based (activity-based), BPMN 2.0
• Технология – product-based (практики, кейсы), CMMN
• Команда – communications-based (полномочия и
поручения), DEMO.
• Отсутствует (проблема) внятный подход для:
leadership (DEMO только упоминает «выход в
дискурс», Essence только упоминает компетенции, но
в целом дисциплина отсутствует)
30

31. Уровни обобщения и формализации: методология
мышления/дисциплин/предметов
(обеспечение мультидисциплинарности/мультипарадигмальности)
31
• Философские логики – знаковые системы и их связь с окружающим
миром, предельные онтологи
• Рефлексирующие модельеры данных – MOF, ISO 15926 Part 2
(Upper ontology, foundational ontology). Компьютерщики:
преобразования одних выражений мысли в другие
(теоркатегорное представление, не теория множеств – операции
главные, вычисление). Поддержка системного подхода
• Модельеры данных/intermediate ontology – одна логика, помогают
выразить мысль непротиворечиво (теоретико-множественное
представление – объекты главные).
• Ситуационные инженеры методов, кейс менеджмент, BPM,
проектные управленцы, оргдизайнеры – мысли о деятельности
(практиках).
• Рефлексирующие инженеры/микротеоретики=онтики – мысли о
своей дисциплине (объекты-предметы: системная инженерия,
программная инженерия, инженерия предприятия, инженерия
психика)
• Профессионалы-инженеры – мысли о своих конкретных Мирах:
целевых объектах (софтинках, самолётиках) и обеспечивающих
объектах (то бишь субъектах), их жизненных циклах.

32. Пример: 4 уровня метамоделирования в OMG ESSENCE
• Level 3 – Meta- Language: the specification language,
i.e. the different constructs used for expressing this
specification, like “meta - class” and “binary directed
relationship.”
• Level 2 – Construct: the language constructs, i.e. the
different types of constructs expressed in this
specification, like “Alpha” and “Activity.”
• Level 1 – Type: the specification elements, i.e. the
elements expressed in specific kernels and practices,
like “Requirements” and “Find Actors and Use Cases.”
• Level 0 – Occurrence: the run - time instances, i.e.
these are the representations of real - life elements in a
running development effort.

33. Мэппинг («картирование» онтологий, нанесение на свою карту «их территории»)
и многоступенчатая объективация
• Чью практику мэппинга брать? [СИ vs
СМДМ]
• Можно ли считать, что
системноинженерное мышление
независимо от всей его этажерки
объективации?! Нет. Т.е. берём вместе с
объемлющей онтологией – которых
несколько.
• Практики системного и онтологического
(не системноинженерного) мышления
для мэппинга – по лестнице
объективации «вверх» от СИ, чтобы
совместить хоть как-то объекты
• Как сравнивать объемлющие онтологии
• Через предельную (но это без толку)
• Аналогии (структурное соответствие) и
гомологии (функциональное соответствие),
изоморфизмы?
• Достаточно ли просто «отмэппить» два
набора понятий «впрок»? Вспоминаем
схему мыследеятельности: что там было
про ситуацию?
33
Схема мыследеятельности -
системно-структурное строение,
смысл и содержание
http://www.fondgp.ru/gp/biblio/rus/57

34. Как происходит позиционирование
• Специальность системного инженера: формально с
1990г. (формирование NCOSE, ныне INCOSE – в 2015 году
празднуется 25 лет)
• Проект GRCSE (Graduate Reference Curriculum for Systems
Engineering) -- http://www.bkcase.org/grcse-2/
• Позиция системного инженера: technical leadership –
кооперация со всеми стейкхолдерами проговаривается
явно, учитывается всеми практиками, поддержана всеми
основными схемами.
• Тренинг позиционирования обязателен: выполнение
рабочих проектов в команде: до 2/3 времени
магистерского обучения.
34

35. Пример рабочего проекта: робот-теннисист
http://ailev.livejournal.com/1159346.html
35

36. Практика=дисциплина+технология
Дисциплинированные (компетентные) исполнители,
Обеспеченные необходимыми для поддержки дисциплины инструментами.
36

37. Системные инженеры на предприятии
• На Западе
– В аэрокосмосе позиция как у врача (культурно-обусловлена, хотя и
может быть глубоко специализирована), не требует особых
демонстраций, обоснований, разъяснений
– Во многих других отраслях должности и профессии называется по-
другому, но стремительно конвергируют в системную инженерию.
Проблема позиционирования тут осознана, рецептов нет, совет
INCOSE «заниматься пиаром системной инженерии в своём
окружении» (а не менять себя, не тренироваться самому). Т.е.
«место красит человека» (хотя в ВУЗе учат занятию именно этого
места!)
• В России позиции нет, системных инженеров по факту нет –
позиция не держится. Нет головы – голова не болит.
• Конкурирующие позиционирования: инженеры-специалисты «с
опытом», изобретатели (не путать с учёными), менеджеры
(операционные чаще всего, но бывают и технологические).
37

38. 38
Спасибо за внимание
Анатолий Левенчук,
Президент Русского отделения INCOSE
http://ailev.ru
ailev@asmp.msk.su
Книжка «Системноинженерное мышление в управлении жизненным
циклом» --
http://techinvestlab.ru/files/systems_engineering_thinking/systems_en
gineering_thinking--TechInvestLab_2014.pdf
TechInvestLab.ru
(495) 748-53-88