- •1. Системная инженерия
- •Определения системной инженерии
- •Ответственность за целокупность и междисциплинарность
- •Для чего нужна системная инженерия: победить сложность
- •Профессия системного инженера
- •Системный инженер как профессия
- •Профессиональные организации системных инженеров
- •Можно ли научить творчеству?
- •Метанойя — не просто обучение, а смена способа мышления
- •Можно ли научить системного инженера, или им нужно родиться?
- •Моделирование творчества в виде, понятном даже компьютеру
- •Методология системной инженерии
- •Образование системных инженеров
- •Отличия системной инженерии от других дисциплин
- •Системная инженерия против других инженерий
- •Системная инженерия против советской инженерии
- •Системная инженерия и системотехника
- •Системная инженерия и менеджмент
- •Инженерный менеджмент
- •Управление технологией
- •Системная инженерия и государство
- •2. Формализмы системной инженерии
- •Терминология и онтология
- •Соглашение по терминологии
- •Выбирайте слова
- •Что такое онтология
- •Индивиды, классы и классификаторы
- •Экстенсионализм и интенсионализм
- •Функциональные объекты
- •Процессы и действия
- •О логических уровнях
- •Выбор уровней
- •Математические формализмы
- •Объекты и атрибуты
- •Объекты и факты
- •Факты и графы
- •Теория категорий
- •Моделеориентированность
- •Что такое модели
- •Онтологизирование, моделирование, программирование
- •Зачем моделировать
- •Почему моделирование не повсеместно
- •Информатика
- •Принципы моделеориентированности
- •3. Инженерия и наука
- •Инженерия не научна
- •Разница между инженерами и учёными
- •Предмет инженерии и научные предметы для инженерных объектов
- •Ненаучность инженерии. Эвристики
- •Наука как “научение птиц полёту”
- •Инженерия научна
- •Инженерная наука
- •Научное (формальное) основание системной инженерии
- •Системный подход как научное основание системной инженерии
- •Системноинженерное мышление коллективно
- •А в чём мышление?
- •Наука/менеджмент = наука/инженерия
- •4. Схема/онтология инженерного проекта
- •Схемное/онтологичное мышление
- •Ситуационная инженерия методов
- •Описание метода в настоящем курсе системноинженерного мышления
- •Яблоки из жизни и яблоки из задачи
- •Альфы
- •Метонимия и схемы
- •Методологическая действительность: дисциплины, практики, методы
- •Дисциплины/области интереса
- •Практики
- •Метод
- •Методологическая действительность и действительность предпринятия
- •Семь основных альф инженерного проекта
- •Основы системной инженерии: альфы инженерного проекта
- •Стейкхолдеры
- •Возможности
- •Определение системы
- •Воплощение системы
- •Команда
- •Работы
- •Технология
- •5. Системный подход
- •Понятие “подхода”
- •Системный подход в системной инженерии
- •Варианты системного подхода
- •Системный подход и кибернетика
- •Сложность и меры сложности
- •Термин “система”
- •Классификация систем по ISO 15288
- •Системная медитация
- •“Сначала как часть надсистемы”
- •Стейкхолдеры. Театральная метафора
- •Система — это субъективное понятие
- •Театральная метафора.
- •Позиция
- •Работа со стейкхолдерами
- •Граница системы и деятельностная субъективность её проведения
- •“Просто” системы и системы систем.
- •Навигация по уровням холархии ”zoom — select”.
- •Системы с участием людей: осторожно!
- •6. Воплощение системы: компоненты, модули, размещения
- •Многерица
- •Сколько разных ипостасей в одной системе?
- •Принцип разделения интересов
- •Закрытый и открытый миры
- •Два типа “целого”
- •Компоненты, модули, размещения
- •Компоненты
- •Модули
- •Размещения
- •Структура системы: разбиения.
- •Разбиения (breakdowns)
- •Представления разбиений
- •Обозначения систем
- •Практики изготовления (производства)
- •7. Определение системы: требования, архитектура, неархитектурная часть проекта
- •Определения и описания
- •Обобщение ISO 42010 на определение системы
- •Контроль конфигурации
- •Фокусирование определений системы
- •Практики проверки и приёмки
- •Практики описания системы
- •Требования
- •Два смысла слова “требования”.
- •Модальности в требованиях
- •Инженерные обоснования
- •Рабочие продукты требований
- •Требования стейкхолдеров
- •Требования и ограничения
- •Требования к системе
- •Инженерия требований
- •Какие бывают виды требований
- •Кто должен делать требования
- •Целеориентированная инженерия требований
- •Архитектура
- •Практики архитектурного проектирования
- •Минимальная архитектура
- •Субъективность и относительность архитектуры.
- •Архитектурные описания
- •Как объединять разные модели и группы описаний
- •Архитектурные модели и другие виды описаний
- •Архитектурные знания
- •Неархитектурная часть проекта
- •8. Жизненный цикл системы и проекта
- •Понятие жизненного цикла
- •Жизненный цикл чего?
- •Управление жизненным циклом
- •Типовой жизненный цикл и разнообразие
- •Гейты и вехи
- •Рабочие продукты для определения жизненного цикла
- •Информационные системы управления жизненным циклом
- •Управление информацией/данными жизненного цикла
- •Практики жизненного цикла
- •V-диаграмма
- •Горбатая диаграмма
- •Водопад и agile
- •Вид жизненного цикла
- •Стили разработки: водопад и agile
- •Паттерны жизненного цикла
- •Основной жизненный цикл
- •Состояния альф
- •Основной жизненный цикл
- •Практики жизненного цикла в версии ISO 15288
- •9. Практика контрольных вопросов
- •Контрольные вопросы для управления жизненным циклом
- •Успех контрольных вопросов
- •Контрольные вопросы к состояниям альф
- •Карточки состояний
- •Когда заводить подальфы
- •Карточные игры
- •Контрольные вопросы инженерного проекта
- •Карточки основных альф инженерного проекта
- •Стейкхолдеры
- •Возможности
- •Определение системы
- •Воплощение системы
- •Команда
- •Работа
- •Технологии
- •Пример введения новой альфы: подальфа «подрядчик»
- •10. Инженерия предпринятия
- •Инженерия: организационная, предприятия, бизнеса, предпринятия
- •Сообщества и их отличия от предпринятия: целенаправленная коллективная деятельность
- •Миссия предпринятия
- •Корпоративное управление
- •Стратегирование, маркетинг, продажи
- •Предпринятие как система-машина, а не толпа людей
- •Развитие и совершенствование предпринятия
- •Проект технологического развития: постановка практик
- •Организационное развитие. Закон Конвея
- •Системноинженерное мышление и инженерия предпринятия
- •Цикл непрерывного совершенствования
- •Цикл Деминга
- •Шесть Сигм
- •Архитектура предпринятия
- •Основные альфы организационного и технологического решения предпринятия
- •Подальфы определения предпринятия
- •Подальфы воплощения предпринятия
- •Виды практик описания деятельности
- •Предпринятия-киборги, workflow
- •Организация, координация, коммуникация
- •Архитектура предприятия
- •Подход Захмана к архитектуре предприятия
- •Бизнес-архитектура
- •Органиграмма
- •Писцы против инженеров
- •Неархитектурные описания предпринятия
- •Это всё системный подход
- •ArchiMate
- •Зачем нужен Архимейт
- •Люди, программы, оборудование
- •Элементы и отношения
- •Нужен не ты, нужен твой сервис.
- •Люди
- •Роли
- •Работы людей
- •Архитектура IT-решения
- •Управление операциями
- •Инженерия предпринятия и управление операциями
- •Проектное управление
- •Управление процессами
- •Ведение дел/кейс-менеджмент
- •Управление проектами и управление жизненным циклом
- •Проектное управление и ведение дел: не “или”, а “и”.
- •Управление мероприятиями
- •Финансы
- •Управление знаниями, НСИ, (справочными и мастер, а также проектными) данными
- •Инженерия и предпринятия-киборги.
- •Инженерия знаний и управление знаниями.
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
144 |
электростанцию” или “прибор анализа крови”) одинаково, представлять себе они её будут по-разному, и по-разному проводить границу между системой и её средой (системами в операционном окружении).
Личная субъективность актёра Пупкина или даже народного артиста Черезколеноногузадерищенского тут мало кого интересует (хотя иногда интересно сообразить, что это за пьесу они играют и какую в этой пьесе роль — критика тогда их “личной субъективности” будет проще). В деятельности нас интересуют мнения стейкхолдеров, когда они “в образе” и играют честно, а не когда они актёры-без- роли (хотя, конечно, есть множество ситуаций, когда обсуждается сама деятельность и распределение ролей в ней — но это мы пока не рассматриваем).
Какова граница солнечной системы? Эта граница проходит по “диску” планетарных орбит, или же сферична, игнорируя планеты? Правильный ответ на этот вопрос — это сначала задать уточняющий вопрос: какой стейкхолдер определяет границы, и какова деятельность этого стейкхолдера, чтобы для него было осмысленно проводить границы именно таким способом — каким образом целевая система важна для его деятельности? “Изучить систему” при этом — не ответ, ибо что в системе нужно изучить? Цвет солнечной системы? Пригодность для жизни? Наличие ангелов? Пригодность для стихосложения? “Дать краткое описание солнечной системы” — тоже не ответ, ибо для кого эти “краткие описания” будут полезны, как и кто их будет использовать? Но уже для деятельности по организации радиосвязи с каким-нибудь космическим зондом вопрос о границах солнечной системы может быть осмысленным. И для людей, задающихся вопросом о потенциальной космической экспансии. Вообще, определение границ солнечной системы мало кого интересовало, пока не появился деятельностный повод: пиар-компания по поводу выхода Voyager 1 за пределы границ солнечной системы в межзвёздную среду. Тогда были уточнены представления разных стейкхолдеров, заинтересованных в солнечной системе как целом и которые на неё хоть как-то “влияют” (например,
описывая её для различных целей) — http://www.astronet.ru/db/msg/1171222, http://habrahabr.ru/post/193562/
Итак — “система в глазах смотрящего”, определяется субъективно. Эта субъективность деятельностная (то есть повторяемая, но повторение не делает “субъективность” “объективностью”). Любая “объективизация” — это результат договорённостей разных стейкхолдеров, согласовывающих свои деятельности и картины мира.
“Просто” системы и системы систем.
Различают “просто” системы (system) и “системы систем” (system of systems, SoS). Оба варианта с точки зрения самого воплощения системы как физического объекта
вреальности (system realization) представляют собой какие-то холархии (иерархии по отношениям “часть-целое”, разбиения/breakdowns). В обоих случаях “подсистемы” очень часто называются точно так же: “системы” (и поэтому новички
всистемной инженерии часто пытаются обозвать просто систему “системой систем”
— но это ошибочно). Вот, например, диаграмма “просто системы” из ISO 15288 — обратите внимание, что термины “подсистема” и “надсистема” не используются,
чтобы подчеркнуть единообразность понимания “системы” на всех уровнях разбиения системы на части-системы и части-элементы (в ISO 15288 элементом называется та часть системы, которая будет оставаться в данном инженерном проекте “чёрным ящиком” и поэтому дальше не будет разбита на части — например, закуплена целиком или изготовлена как целое из какого-то материала):
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
145 |
Этот рисунок структуры системы говорит, что ISO 15288 рассматривает целевую систему как набор из частей-систем и частей-элементов и продолжает разбиение систем на части-системы и части элементы. Но неправильно такие картинки называть “система систем” (system of systems, SoS), ибо этот термин закреплён за другой ситуацией. Системой систем называют такую систему, которая (критерии
Maier):
●Имеет независимое управление её систем-элементов (нет, кому скомандовать общее развитие-модернизацию)
●Независимая работа элементов (нет, кому скомандовать работу в общем сервисе)
●Эмерджентность от объединения в систему (кто-то желает получить от целевой системы систем функцию, которую невозможно получить от работы с отдельными входящими в систему систем элементами, и требуется совместная работа этих элементов).
●Эволюционное развитие (понимание того, что будет происходить в системе систем на каждом следующем шаге проекта требует исследований, ибо нет точки, которая знает as built для всех)
●Географическое распределение элементов
Эти критерии различаются, конечно, в разных инженерных школах, но общее остаётся: обычные “системы” подразумевают централизованное “владение” системой — наличие стейкхолдеров, полномочных принимать решения по всем частям системы, полномочных распоряжаться всем, что в границах их системы. Это традиционный случай: автомобиль с двигателем и колёсами, железнодорожный мост и компьютер — это типичные “просто системы”, у них есть свои системные инженеры, которые полностью определяют их функции, конструкцию, интерфейсы с системами в операционном окружении, планы по модернизации и выводу из эксплуатации. У каждой из этих систем есть один хозяин, один владелец.
А вот в системе систем каждая из систем имеет своего хозяина, и система может функционировать автономно, без вхождения в систему систем. Тем самым разница
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
146 |
между “просто системой” и “системой систем” определяется не через особую структуру или конструкцию системы, а через наличие независимых друг от друга стейкхолдеров, определяющих и создающих системы, а затем независимо использующих их.
Всистеме систем важны прежде всего владеющие частями-системами людистейкхолдеры, именно они делают систему систем особым случаем.
Вармии NATO сейчас больше говорят не о системной инженерии, а о системосистемной инженерии (system of systems engineering), потому что вся армия должна действовать в бою как единое целое — но это оказалось крайне сложно обеспечить: каждый род войск имел своё независимое финансирование много лет, свои планы развития, свои типы вооружений. В итоге флот, авиация, пехота, космические
войска получили несовместимое оборудование и вооружение — и никакими силами нельзя было создать из этих несовместимых между собой систем-элементов систему систем, ведущую бой как единое целое.
NATO выделило четыре типа систем систем, отличающихся степенью их автономности:
●управляемые (directed), в которых есть назначенный архитектор, который может выдавать приказы составляющим системам и распоряжается ресурсами.
●подтвержденные (acknowledged), в которых признаваемый архитектор есть, но он может только уговаривать составляющие системы самоизмениться согласно разработанной им архитектуре.
●сотрудничающие (collaborative), в которых все системы договариваются друг с другом по каждому чиху, но архитектора, менеджера проекта или аналогичного выделенного органа управления нет.
●виртуальные (virtual), в которых системы вообще не знают друг о друге ничего и не влияют друг на друга явно.
Был выведен основной способ работы с системами систем: совместная постепенная асинхронная эволюция (модернизация) входящих в систему систем автономных систем — ибо согласованность и синхронность изменений в этих автономных системах крайне сложно обеспечить: даты утверждения проектов модернизации будут различаться, получаемое на модернизацию финансирование будет выделяться в разные моменты и нельзя будет гарантировать его достаточность, системные инженеры могут иметь разные мнения по поводу взаимодействия их систем с другими системами в составе системы, хозяева систем могут сопротивляться переменам (ибо их вполне может удовлетворять и автономная
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
147 |
работа их систем в их надсистемах, а желание какого-то стейкхолдера системы систем об объединении автономных систем в общую систему систем они могут не разделять).
В системо-системной инженерии нет никаких чудес: в ней по факту нет никаких своих понятий. Поскольку работа со стейкхолдерами является главной, то к самой обычной системной инженерии в больших количествах добавляются заимствования из гуманитарных дисциплин. Работы по системо-системной инженерии объединяют с использованием системного мышления достижения отдельных гуманитарных дисциплин: социологии, политологии, психологии, менеджмента, конфликтологии.
Тем не менее нельзя системо-системную инженерию считать “системным менеджментом”, ибо в ней таки ставятся задачи не столько главным образом по созданию системы из людей, сколько задачи по созданию главным образом технических систем, но с активным участием людей — что требует изменения инженерных практик и методов.
Навигация по уровням холархии ”zoom — select”.
Понимание того, что любая система входит в холархию позволяет системному инженеру хорошо ориентироваться в сложном мире: ни на секунду он не теряет контекста, оставаясь способным обсуждать как самый маленький винтик в самом маленьком приборе, так и совсем огромные системы планетарного масштаба. От этих “скачков масштаба” он не сходит с ума, для него это самая обычная процедура: поменять целевую систему в ходе обсуждения на надсистему или подсистему — главное, чтобы он это делал осознанно. Системный подход даёт нам не только оператор “select” (выбора объекта для действия), но и способ для зума — как в фотоаппаратах, можно выбрать подходящий масштаб разбирательства с ситуацией.
Harold “Bud” Lawson приводит следующий пример для транспортной системы:
В транспортной системе мы сначала можем обсуждать мультимодальные перевозки и конкуренцию независимых друг от друга транспортных систем (так, трубопроводный транспорт конкурирует в перевозке нефти с железнодорожным транспортом — для их владельцев они враги в операционном окружении, для желающего перевезти нефть из одной точки мира в другую они части одной