May 23rd, 2012

2019

Сверхкраткое введение в конструкцию системной инженерии

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

Вот примерная линия рассуждений (а иллюстрирующие диаграммы -- на доске):

центральная доска (22 мая 2012, лекция в МИФИ)

1. Система в её простейшем варианте определения -- это единство функции (назначения её как части надсистемы. Представляется функциональным объектом) и конструкции (физических объектов, которые являются её частями). Согласно ISO 15288 говорят сейчас о системах в составе системы (не путать с "системами систем" -- это про другое!), хотя можно использовать и более древнюю терминологию с надсистемой-системой-подсистемой.

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

2. Инженерные системы отличаются от "просто систем" тем, что единство функции и конструкции в них определяется через понятие слота (для функциональной части) и модуля (для конструктивной части). Диаграмма гамбургера Wim Gielingh показывает декомпозицию системы с учётом единства функции-конструкции.

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

4. Самое важное про то, как конструкция системы обеспечивает её функцию -- это архитектура. Инженерия системной архитектуры -- это практика системной инженерии, которую выполняет системный архитектор. Архитектор придумывает архитектуру и отражает её в архитектурном описании.

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

6. Инженер по испытаниям обеспечивает проверку соответствия конструкции функции (изготовленной системы требованиям).

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

И только после этого мы переходим к тому, чтобы ввести понятие жизненного цикла:

1. Про функцию системы мы обычно думаем так, как будто система уже есть и эксплуатируется (буквально -- "функционирует"). Целевая система -- это та, которую мы делаем. Системы в составе надсистемы, у которых есть интерфейс с нашей целевой системой в ходе функционирования (в момент эксплутации) называются системами в операционном окружении [целевой системы]. Изменения, которые происходят в ходе эксплуатации/функционирования называются "поведением системы".

2. Эксплуатация -- это иногда небольшой отрезок жизни системы (термоядерная бомба: долго делают, быстро эксплуатируют), а иногда большой (атомная электростанция: относительно быстро строят и проектируют, потом долго эксплуатируют). Отрезок времени от замысла до снятия с эксплуатации целевой системы называют её жизненным циклом. Еще раз: жизненный цикл -- это отрезок времени, а не материальный объект или что-то абстрактное типа схемы. Жизненный цикл -- это от рождения до смерти. Если речь идёт о том отрезке времени, который система проводит в чьих-то руках, то это "жизненный цикл проекта".

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

4. Целевая система пассивна, и до стадии эксплуатации её буквально волокут за шкирку по жизненному циклу другие системы, которые называются обеспечивающими. Если стрелу времени согнуть, то получится V-диаграмма, в которой можно выделить три суперстадии жизненного цикла:
-- определение системы (ведущие практики системной инженерии: инженерия требований, инженерия системной архитектуры)
-- воплощение системы (ведущая практика верификации и валидации, ибо при повышении точности изготовления сама "интеграция" перестаёт быть чем-то творческим).
-- эксплуатация (функционирование, operation. В этот момент системные инженеры уже выполнили свою основную работу).
-- вывод из эксплуатации (который на v-диаграмму традиционно не попадает).
Почему нужно было гнуть линию времени? Чтобы показать, что верификация (проверка того, что сделали) против архитектуры, валидация (приёмка заказчиком) против требований.

В жизни всё много запутанней, и поэтому V-диаграмма имеет самые разные формы и вариации. Более того, нельзя считать, что разные системные инженеры и инженеры по специальности работают последовательно во времени: нет, обычно они работают все вместе.

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

А вот переходной шаг для обсуждения инженерного менеджмента, предмета следующей лекции:

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

В лекции я затронул еще и разные другие моменты (например, советы по выбору карьеры между менеджером и инженером. Ключевой вопрос для осмысленного принятия решения: можно ли из инженера стать менеджером, и можно ли из менеджера стать инженером?).
2019

Системная инженерия, инженерный менеджмент и инженерные сервисы

Некоторое время я варился в материалах самых разных профессиональных тусовок, членом которых я являюсь:
-- INCOSE (международный совет системных инженеров), http://incose.org
-- ASEM (американская, но по факту -- международное общество инженерного менеджмента), http://asem.org
-- ACDM (ассоциация управления конфигурацией и управления данными), http://acdm.org/.

Я много лет еще и член ACM (ассоциация компьютерной машинерии), http://acm.org, а в ней SIGSOFT (специальная группа по интересам, занимающаяся программной инженерией), но тамошнее членство позволяет лишь сказать, что новейшие IT-технологии будут продолжать взрывать содержание текущих практик системной инженерии, инженерного менеджмента и управления конфигурацией и данными с неменьшей скоростью, чем это происходило до сих пор. Я думаю, что скорость этих изменений ещё и увеличится: переход к моделеориентированной системной инженерии и порождающему проектированию и производству обеспечивается прежде всего новыми алгоритмами, новым софтом.

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

Например, ISO 15288 (определяет практики жизненного цикла системной инженерии -- вот список: ), из четырех групп практик только одну (технические практики) определяет как собственно "системная инженерия" в узком смысле слова (практики того, что делают с целевой системой: задумывают, проектируют, изготавливают, проверяют и сдают, эксплуатируют, выводят из эксплуатации и т.д.). Остальные группы практик -- контрактные, проектные и обеспечения проектов -- это про то, что делает обеспечивающая система, сиречь предпринятие, занимающееся работами по продвижению целевой системы по её жизненному циклу. В эти практики попадает и управление портфелем проектов, и управление персоналом проектами, и управление конфигурацией, и даже заключение контрактов. Это было абсолютно сознательное склеивание системной инженерии и инженерного менеджмента (с выходом на организационную инженерию) со стороны разработчиков стандарта, я обсуждал эту тему с редактором первой версии Бадом Лоусоном. Вот это разбиение (т.е. набор частей) системной инженерии по версии ISO 15288 (на английском это цитируется вот тут -- http://ailev.livejournal.com/632128.html -- заодно там обсуждается и бессмысленность какого-то содержательного анализа использования слова management в названии дисциплины/практики, например, обоснование отнесения к широкой дисциплине "менеджмент" на основании использования этого слова в названии практики):

Системная инженерия:
1. Контрактация
1.1. Закупка
1.2. Поставка

2. Обеспечения проектов
2.1. Определение вида (описывание, моделирование) жизненного цикла
2.2. Управление инфраструктурой
2.3. Управление портфелем проектов
2.4. Управление персоналом
2.5. Управление качеством

3. Проектные
3.1. Управление проектами
3.1.1. Планирование проекта
3.1.2. Управление выполнением и контроль проекта
3.2. Поддержка проектов
3.2.1. Управление решениями
3.2.2. Управление рисками
3.2.3. Управление конфигурацией
3.2.4. Управление информацией
3.2.5. Измерения

4. Технические
4.1. Сбор требований
4.2. Анализ требований
4.3. Архитектурное проектирование (дизайн)
4.4. Изготовление
4.5. Верификация (проверка)
4.6. Переход к эксплуатации
4.7. Валидация (приёмка)
4.8. Эксплуатация
4.9. Обслуживание
4.10. Вывод из эксплуатации



Инженерный менеджмент тоже крут в плане своего шовинизма. Он, вообще-то говоря, псевдодисциплина: скомпонованный для целей совместного маркетинга учебными заведениями набор разных полезных дисциплин. "Истинные дисциплины" -- это которые имеют свои собственные объекты (типа "требования" и "архитектура" в системной инженерии), и поэтому "истинные части" (типа "инженерии требований" и "инженерии системной архитектуры"). Разбиение истинных дисциплин -- это отношение состава (часть-целое, композиция). Псевдодисциплины -- это объединения (агрегация) по каким-то критериям фрагментов разных других "истинных дисциплин": информационная архитектура (но не моделирование данных!), инженерный менеджмент и много-много других. Так вот, инженерный менеджмент включает в себя не только лидерство и управление проектами, но и системную инженерию! Почему? "Инженерный менеджер должен знать основы системной инженерии". Ага, ибо мало кто в ASEM интересуется, что делает инженерный менеджер -- но всех волнует, что должен знать инженерный менеджер. Вот главы Handbook of Engineering Management, сравните их с практиками системной инженерии:

1. Инженерный менеджмент -- настоящее, прошлое, и будущее.
2. Вопросы профессиональной ответственности, этики и законодательства.
3. Теория и понятия менеджмента
4. Управление знаниевыми работниками.
5. Исследование операций
6. Имитационное моделирование
7. Анализ при принятии решений (decision analisys)
8. Мультикритериальный анализ
9. Основы бухучёта и финансов
10. Инженерная экономика
11. Роль управления проектами в стоимости жизненного цикла
12. Системная инженерия [только технические практики]
13. Управление рисками
14. Стратегическое управление
15. Системное мышление
16. Лидерство для индивидуальных работников и команд инженерных проектов.

Тамошнее Body of Knowledge не лучше, но в нём хотя бы системной инженерии на верхнем уровне нет (оглавление на английском -- http://asmedl.org/ebooks/asme/asme_press/802991):
1. Исследования рынка, оценки и прогнозы
2. Стратегическое планирование и управление изменениями
3. Разработка продукта, сервиса и процесса
4. Управление инженерными проектами и процессами
5. Управление финансовыми ресурсами
6. Маркетинг, продажи, и управление коммуникациями
7. Лидерство и организационное управление
8. Вопросы профессиональной ответственности, этики и законодательства.

Инженерные сервисы (engineering services) -- это весьма спорное название для группы инфраструктурных практик типа управления конфигурацией и управления данными, которые системные инженеры относят к "поддержке проектов" (ISO 15288), инженерные менеджеры вообще не замечают, соответствующие функциональные подразделения на предприятиях часто так и называют. Ирония судьбы в том, что в инженерные сервисы свободно записывают и системную инженерию, и вообще любую инженерию в целом, равно как и configuration and data management (вот, например, обратите внимание, в каком разделе и среди каких других практик configuration and data management тут: http://www.windmill-intl.com/professional/engineeringservices/configuration.htm, а вот configuration change control вынут из engineering services и засунут в management services -- www.control-pt.com/services/engineering-services, вот управление конфигурацией прямо внутри проектного управления, но не в инженерных сервисах -- http://www.novasystems.com/services/project_management/configuration_management, и так дальше везде: некоторый ряд инфраструктурных практик обеспечивающей системы системной инженерии имеет неопределённое отнесение и претендует на какую-то самость (ибо имеет собственные понятия, не встречающиеся в менеджменте и системной инженерии -- конфигурация, данные жизненного цикла и т.д.).

Ещё одно мнение -- это синонимичность управления конфигурацией и управления данными с управлением инженерной документацией и управлением жизненным циклом продукта. Вот что об этом говорится в четвертом издании одной из самых популярных книжек по управлению конфигурацией (Watts, Frank B. (2011-11-07). Engineering Documentation Control Handbook: Configuration Management and Product Lifecycle Management):
The title of this book indicates that Engineering Documentation Control – Configuration Management and Product Lifecycle Management are equivalent terms. But are they really? Many people feel that EDC is a subset of CM. Some think of EDC as what they are currently doing and CM as what they ought to be doing. PLM is a term used primarily by software applications for engineering – but it certainly implies a cycle that transcends engineering into manufacturing and to the customer. Much of the truth in this discussion is in “the eyes of the beholder.”
Другими словами: есть некоторая дисциплина, набор практик, а как уж его назвать и к какой наддисциплине это принадлежит -- зависит от называльщика.

Жизнь также показывает, что управление конфигурацией, в том числе и управление изменениями (опять же -- то включается, то исключается из "управления конфигурацией" и рассматривается отдельно) невозможно рассматривать отдельно от управления данными (управления информацией, интеграции данных жизненного цикла и т.д.) -- это подтверждает и неразрывность CM и PLM, и само именование профильной ассоциации (Association of Configuration and Data Management, http://acdm.org/).

Какие практики попадают в этот блок, нужно изучать специально. Похоже, сюда попадают:
-- практика выпуска (release) инженерных артефактов (например, выпуск чертежей) -- и можно обсуждать, является ли hand-over данных входящим в эту практику, или должен рассматриваться отдельно
-- практика выпуска [сводных] заказных спецификаций (BOM, bill of materials)
-- практика запросов на изменения
-- практика изменения проекта
-- практика управления данными (чтобы нужные заинтересованным сторонам данные оказывались у них в нужное время. Да, "управление требованиями", как часть инженерии требований, отвечающая именно за то, чтобы требования адекватно хранились и адекватно предоставлялись по запросам заинтересованных сторон -- это часть именно этой практики. Ибо нет никаких особенностей именно у "управления требованиями" в отличии их от управления любыми другими данными. Ну, и помним, что слово "управление" тут ничего не означает, как обычно. Никаких управленцев в управлении данными!).

Все эти бесхозные инфраструктурные дисциплины, которые попадают в зазор между чисто менеджерскими (типа лидерства -- когда живых людей убалтывают занять позиции в бездушной машине-предпринятии) и чисто техническими (когда придумывают и изготавливают конструктивные решения для целевой системы) я бы назвал не "практики поддержки проектов" (чтобы на слово "проект" не набежали технически неподготовленные MBA с сертификатами PMI), а "инженерными сервисами" -- подчеркнув тем самым, что они относятся к инженерам-проектировщикам (Watts, Frank B. (2011-11-07). Engineering Documentation Control Handbook: Configuration Management and Product Lifecycle Management):
The CM title is preferred when the responsibilities are generally as outlined in this book. When the responsibilities are broader (include functions such as publications, reproduction, data backup, software system input/control, etc.), then the generally preferred name is Engineering Services.
Тут нужно учесть, что книжка корнями уходит (это ведь четвертое издание!) в бумажную систему инженерного документооборота. Появление PLM систем уже не позволяет обсуждать configuration management без data management -- и неминуемо организационное звено предпринятия, ответственное за engineering documentation control, configuration management и PLM будет ответственным и за data and information management. Так что -- инженерные сервисы, однозначно, причем эти инженерные сервисы в связи с переходом к моделеориентированной системной инженерии претерпевают коренную ломку, включая всё больше и больше сервисов по работе с данными (ага, "инженерная шина предприятия" или что-то типа этого, управление инженерными справочными/мастер данными -- это ведь тоже сюда).

Аналогично, из традиционного менеджерского блока выпадают практики проектного управления в той мере, в какой они зацепляют:
-- создание графика изготовления/сооружения так, как это понимают технологии (все эти Multi-D, когда информация из 3D проекта и информация по технологиям изготовления/сборки/стройки/монтажа используется для создания графика работ).
-- исследование операций (приложения к логистике, к расчетам supply chain, эвристики планирования потоков работ/комплектующих из теории ограничений Голдратта, "заводская физика" и т.д.), ибо это требует не столько "менеджерской", сколько чисто расчётной инженерной экспертизы.
Вообще, это огромная дискуссия, что в "проектном управлении" останется, если из тамошнего проектного шовинизма выделить "это просто менеджмент, учись расставлять людей, детка" и "это просто инженерия, учи математику, детка". А если следовать логике теории ограничений, то управленческий финансовый учёт (как логистика денежных потоков) тоже уйдёт сюда -- и тоже как инженерная дисциплина. Но я бы не рискнул эту инженерную составляющую считать "инженерным сервисом". Я хорошо понимаю, почему авторы ISO 15288 группу проектных практик (единственную) разбили на две подгруппы. Я бы считал практику планирования проектов частью практики архитектурного проектирования (это очень удобно в русском языке, где "проект" понимается и как project и как design), а контроль исполнения проекта -- частью практики интеграции, подчеркивая это самое Multi-D как в проектировании, так и в интеграции/сооружении (недаром на практике часто путают -- то Multi-D означает "все D", то "только начиная с 4D и дальше, но не 3D").

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