- •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 |
74 |
использования псевдокода): вес: ЛАЗЕР → Real частота: ЛАЗЕР → Real
вес: КОНДЕНСАТОР → Real ёмкость: КОНДЕНСАТОР → Real вес: ОБОРУДОВАНИЕ → Real
габарит: ОБОРУДОВАНИЕ → Real X Real X Real
тип оборудования: ОБОРУДОВАНИЕ → {"лазер", "конденсатор"}
Если четвёртому студенту поручат сделать общую систему автоматизации – он не сможет понять, какая модель мира должна быть: как в лаборатории, где лазеры и конденсаторы объекты, или как на складе, где это просто атрибуты оборудования? Заметим ещё, что в первой базе атрибут "вес" будет иметь имя "Вес", а во второй – "Weight", и заполнен в первой базе будет в килограммах, а во второй – в граммах. Для решения задачи объединения всех баз нарисовать картину мира придётся заново, просто сложить результаты работы первых трёх студентов не получится.
Разумеется, на эти вопросы выработаны ответы, и у философов, и у программистов. Но эти ответы очень непросты. Атрибутный формализм (иногда говорят “парадигмы моделирования”) критикуют вовсе не за отсутствие формальности, тут всё в порядке, математическое обоснование у него есть. Критикуют именно неудобство моделирования мира, низкую вероятность того, что два независимых модельера без предварительных консультаций сделают одинаковые модели, пригодные к непосредственному объединению.
Объекты и факты
В начале 20 века теория множеств получила твёрдые математические основания и стала основой математической логики. Мы уже обсуждали преимущества теоретикомножественного подхода к онтологиям, теперь мы продвинемся в рамках этого подхода чуть дальше.
Основанной на теории множеств альтернативой стал факт-ориентированный способ моделирования мира. В середине 20 века именно этот способ был поддержан аналитической философией. Как говорил Витгенштейн, мир нам дан не “в объектах”
— мир нам дан "в фактах об отношениях объектов". Это философская позиция - мы ничего не можем сказать про сами объекты, все наши утверждения делаются про отношения между объектами, объекты проявляют себя в отношениях.
Как представить себе мир, в котором есть только объекты и отношения, а атрибутов у объектов нет? Как представить красный автомобиль? Очень просто: КРАСНЫЙ – это множество всех красных предметов, которые были, есть или будут в мире. Автомобили, лазеры, звёзды, имеющие красный цвет – все вместе и составляют этот класс. А утверждение "мой автомобиль имеет красный цвет" превращается в отношение классификации/членства в классе КРАСНЫЙ.
мой автомобиль ϵ КРАСНЫЙ
Мы помним, что сами классы тоже могут быть классифицированы – принадлежать классификаторам, классам классов. Таким классом классов оказывается ЦВЕТ – это класс, членами которого являются классы КРАСНЫЙ, СИНИЙ, ЗЕЛЁНЫЙ, определённые так, как сказано выше.
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
75 |
ЦВЕТ = { КРАСНЫЙ, СИНИЙ, ЗЕЛЁНЫЙ, … } Атрибуты в теоретико-множественном подходе стали классами.
Теперь мы можем обсуждать "цвет вообще" и "конкретный цвет" в отрыве от имеющих цвет объектов!
Но и утверждение "любой автомобиль имеет цвет" никуда не потерялось. В атрибутной модели оно выглядело как обязательная колонка "цвет" в таблице автомобилей. В факт-ориентированной модели этому соответствует более сложное утверждение "класс АВТОМОБИЛЬ классифицирован классами класса классов ЦВЕТ". Или, на математическом языке:
xϵАВТОМОБИЛЬ yϵЦВЕТ (x ϵ y)
Опора на использование отношения классификации уже не позволит легко совершить ошибку, введя текстовый атрибут "тип оборудования" (в рамках такого моделирования это именно ошибка!). Класс ОБОРУДОВАНИЕ включает подклассы ЛАЗЕР и КОНДЕНСАТОР:
ЛАЗЕР ОБОРУДОВАНИЕ КОНДЕНСАТОР ОБОРУДОВАНИЕ
При этом каждый из них принадлежит ещё и классу всех материальных объектов, то есть обязательно является подклассом одного из классов предметов с данным весом, и одного из классов предметов с заданными высотой, длиной, шириной:
xϵМАТЕРИАЛЬНЫЙ ОБЪЕКТ yϵВЕС (x ϵ y) ЛАЗЕР МАТЕРИАЛЬНЫЙ ОБЪЕКТ
ind002233 ϵ ЛАЗЕР
1.25 кг ϵ ВЕС ind002233 ϵ 1.25 кг
Факт-ориентированное моделирование мира целостно, но так мыслить о мире не очень привычно. Аристотелевский подход царил пару тысяч лет, а теория множеств как средство моделирования мира существует всего-то сто лет!
Современная информатика и инженерия медленно осваивают факториентированное моделирование. Толчок к этому переходу дало решение проблем больших данных (Big Data). Большие данные определяются как такие данные, для которых важны одновременно большой объём, большая вариабельность, большая скорость, большая достоверность (big volume, big variety, big velosity, big veraсity).
Факт-ориентированность помогает справиться как раз с большой вариабельностью
– взаимосвязанные данные приходят из разных источников, собираются там по разным правилам, хранятся в разных базах данных – то есть проблемы объединения разных данных надо решать регулярно и быстро. А как раз при факториентированном моделировании гораздо больше вероятность того, что данные просто сложатся вместе, без существенной перестройки.
Подробнее про факт-ориентированное описание в логической парадигме по сравнению с атрибутным подходом можно прочитать в уже упоминавшейся выше книге Chris Partridge “Business Objects: Re-Engineering for Re-Use”.
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
76 |
Факты и графы
Самым распространённым формализмом для факт-ориентированного моделирования стали ориентированные графы.
Философы и логики предложили простой способ записывать факты, согласующийся с тем, как факты отражаются в человеческой речи и даже в человеческом мышлении. Каждый факт может быть представлен как упорядоченная тройка (triple)
<субъект, предикат, объект> (<subject, predicate, object>).
Например:
<Королева Елизавета, является_матерью, Принц Чарльз> или <Королева Елизавета, классифицирована_как, МАТЬ>
В естественных языках похожей структурой является связка "подлежащее- сказуемое-дополнение".
Упорядоченные тройки являются естественным представлением ориентированного графа с нагруженными рёбрами: субъекты и объекты образуют узлы, стрелки/рёбра/связи направлены от субъектов к объектам, а предикаты - подписи на рёбрах. В таких моделях никаких атрибутов у узлов нет, только связи.
Вот пример факт-ориентированного описания языка архитектуры предприятия
OpenGroup Archimate 2.1 (http://pubs.opengroup.org/architecture/archimate2doc/chap10.html). Мета-модель описания целей и требований для архитектуры предприятия выглядит так:
На следующей диаграмме – соответствующая этой мета-модели конкретная модель (следующий логический уровень):
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
77 |
Разные виды квадратиков и стрелочек — разные типы объектов и отношений. Но никаких атрибутов!
Про связь факт-ориентированных представлений с логикой можно прочесть на http://www.jfsowa.com/ontology/ontometa.htm, подробная информация по математическому аппарату для факт-ориентированных представлений — http://www.jfsowa.com/logic/math.htm .
Факт-ориентированный подход может встретиться вам под разными именами. Наиболее популярным формализмом в этой области сегодня является разработанный для Семантического Интернета (Semantic Web) язык RDF (http://en.wikipedia.org/wiki/Resource_Description_Framework). Множество стандартов используют RDF для факт-ориентированного представления информации, например, ISO 15926 для представления инженерных данных.
В связи с описанными преимуществами растёт применение графовых баз данных, специально предназначенных для хранения данных, не укладывающихся в реляционные таблицы. Графовое представление не так компактно, как атрибутное, но гораздо более универсально.
Теория категорий
В 21 веке начали обсуждать возможность использовать для представления мира ещё один раздел математики – теорию категорий, раздел высшей алгебры, который “начинается с наблюдения, что многие свойства математических систем можно представить просто и единообразно посредством диаграмм” (стр. 12 из Маклейн С., Категории для работающего математика. М.: Физматлит, 2004). Теория категорий видит в мире объекты, связанные особого рода отношениями – “морфизмами” (преобразованиями).
Теория категорий ещё более непривычна людям, чем теоретико-множественный подход. Но если говорить о компактности представления мира и его универсальности, то теория категорий выглядит более многообещающе, чем теоретико-множественное представление. В настоящее время есть только отдельные результаты применения теоркатегорного аппарата к задачам моделирования в разных предметных областях. Стандартов, регламентирующих использование теории категорий для представления мира, нет.
Мы не будем касаться в нашей книге теории категорий, но советуем хотя бы знать о существовании этого раздела математики. Начальное представление о теор-