- •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 |
70 |
но вовсе не “предприятие” как юридическое лицо. “Проект” в смысле проектного управления – это тоже ”предпринятие”). Тут с использованием профессиональных понятий моделируется (уже не мета-моделируется!) то, что происходит “в жизни”, в привязке к конкретным условиям работы в ООО
“Незабудка” по проекту ремонта лифта "к празднику". Занимаются этими описаниями люди конкретного предпринятия, используя понятия и методы, созданные на всех верхних уровнях.
Повторим, что границы между логическими уровнями расплывчаты, но в каждом конкретном случае мы можем увидеть цепочку мета-моделирования, где тщательно обсуждённые одними профессионалами понятия используются для построения понятий другими профессионалами — от самых абстрактных до самых конкретных.
Математические формализмы
Основной объём этой книги будет посвящён рассказу об интересующей нас предметной области на 4-м и 5-м логических уровнях. Эти уровни для нас включают деятельностную парадигму в целом, системное мышление, дисциплины системной инженерии и инженерного менеджмента. Чтобы перейти к этому материалу, ещё немного задержимся на 2-м и 3-м уровнях (формально-математическом и онтологическом), в дополнение к рассказу о 4D экстенсиональной онтологии, с которого мы начинали.
Разумеется, 2-й и 3-й уровни плотно смыкаются с 1-м, философско-логическим. Посмотрите, как обсуждает стык индуистской философской традиции, онтологический статус математики с заходом на лингвистику и гомотопические алгебры математик Роман Михайловский вот тут: http://baaltii1.livejournal.com/573648.html. А вот как обсуждают этот вопрос физики: “вещество происходит из информации”, или “информация происходит из вещества”
— http://fqxi.org/community/essay/winners/2013.1
В целом применения математики к реальной жизни сегодня распадаются на два широких класса методов:
●Точные математические методы, воплощённые в точных компьютерных вычислениях (hard computing). К этим методам относятся поиск точных решений уравнений, формальные преобразования, символьные вычисления. Про используемую при этом математику и её влияние на естественные науки
есть статья Eugene Wigner "The Unreasonable Effectiveness of Mathematics in the Natural Sciences" — https://www.dartmouth.edu/~matc/MathDrama/reading/Wigner.html
●Приближённые математические методы, воплощённые в алгоритмах так называемых мягких вычислений (soft computing). Сегодня к этому классу относятся чрезвычайно широко используемые нечёткие вычисления, статистические методы, генетические алгоритмы, нейронные сети. Про соответствующую математику есть статья с упором на работу с текстами Alon
Halevy, Peter Norvig и Fernando Pereira из Google (2009) "The Unreasonable Effectiveness of Data" — http://static.googleusercontent.com/media/research.google.com/en//pubs/archiv e/35179.pdf .
При математическом моделировании реального мира принято начинать с моделирования точными методами, в инженерии вообще принято опираться на точные модели. Однако поиск решений для поставленных в ходе моделирования
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
71 |
задач всё чаще осуществляется через тот или иной тип мягких вычислений.
Первое на что надо изучить при выборе того или иного формального математического аппарата – это определённую нотацию (notation). Нотация – это соглашение о знаках, то есть мета-модель того, что мы будем записывать. Наши математические утверждения должны быть записаны так, чтобы человек или компьютер могли их понять. Так же как и в обычной речи, в математике и в программировании одни и те же понятия и связывающее их утверждения можно выразить на разных по виду формальных языках: графических, текстовых для чтения человеком, текстовых для чтения компьютером (бинарных файлах). Языки могут быть основаны на разных разделах математической науки: на теории множеств, логике предикатов, графах и гиперграфах, деревьях и ссылках, текстовых строках и грамматиках, струнных диаграммах и формулах теории категорий, и т.д. Предпочтения тех или иных формальных систем в программировании привели к формированию семейств языков, объединённых определённым языковым стилем (языковых стилях).
Многие формализмы допускают работу с несколькими нотациями, и позволяют перекодировку между ними, например, так можно заменить логические предикаты операциями с графами.
Онтология предприятия из стандарта OMG SBVR, разработанная в логическом формализме, может быть использована в нескольких формальных нотациях: RuleSpeaks (контролируемый естественный язык, ограниченное подмножество английского языка), ORM (Object-Role Modeling, факт-ориентированный язык), UML (Universal Modeling Language, объект-ориентированный язык), Common Logic (язык логики предикатов). Кроме того, стандарт содержит указания на то, как следует выражать эту же онтологию и на других формальных языках.
Из полезных инструментов для формального описания упомянем ещё “псевдокод”. Текст на псевдокоде понятен для человека, и при этом выглядит так, как будто это программа, которую может исполнить и компьютер, однако на самом деле программой не является. Настоящий код на языке программирования может быть выполнен компьютером с использованием формальной семантики этого языка, т.е. точного знания о том, как компьютер должен выполнять вычисления. Псевдокод же только для непосвящённых выглядит как код, у выражений нет формальной семантики, не определён математический смысл используемых понятий. Поэтому компьютер не может исполнить псевдокод, человек-программист должен понять, что описал на псевдокоде автор текста, а потом закодировать это на каком-то языке программирования.
Мы ограничимся рассказом о двух формализмах описания данных, используя при этом формализмы и нотации теории графов, теории множеств и математической логики:
●классического атрибутного описания;
●факт-ориентированного описания, наиболее подходящего для теоретикомножественного подхода.
Кроме того, мы упомянем о наличии теоркатегорных описаний, базирующихся на математической теории категорий (не путать с философскими категориями!). Иные формализмы мы в этой книге обсуждать не будем, но интересующимся вопросом советуем посмотреть ряд обзоров: http://plato.stanford.edu/entries/concepts/ , http://www.iep.utm.edu/concepts/ , и далее попробовать понять, чем занимается
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
72 |
mind and cognitive science (не путать с cognitive psychology, cognitive linguistics!): http://www.iep.utm.edu/category/m-and-e/mind-cog/ . А чтобы понять, насколько формальные подходы далеки от “обыденного” подхода, зафиксированного в бытовом человеческом языке, нужно читать книжку George Lakoff "Women, Fire, and
Dangerous Things".
Объекты и атрибуты
Наиболее распространённым формализмом описания данных является мета-модель “объект-атрибут”. В ней всё в мире представляется как объекты, индивидуальные признаки которых описывают атрибуты. В той или иной форме такая мета-модель используется и в объект-ориентированном программировании, и в языке UML, и в основанном на нём языке моделеориентированной системной инженерии SysML, и в языке мультифизического моделирования Modelica. Но самым известным примером использования объект-атрибутного формализма являются реляционные базы данных. Или их упрощённый вариант – электронные таблицы.
Это формализм является, пожалуй, и самым старым — он ведёт своё начало от работ Аристотеля. А популярен он потому, что простая, ещё не электронная, таблица – это самый очевидный способ систематизировать информацию на плоскости – на листе бумаги, пергамента, и даже папируса.
Каждый класс/тип объектов представляется своей табличкой, со своим набором колонок. Заголовки колонок – это и есть названия атрибутов. Каждая строка – это очередной элемент класса, а каждая клеточка на пересечении колонки и строки содержит значение данного атрибута для данного элемента (число, текст). Значением атрибута может быть и ссылка, чтобы атрибут мог указывать на другие объекты/элементы. Но чаще всего отношения между объектами присутствуют в объект-атрибутной модели непосредственно (реифицированы), и сами, в свою очередь, имеют атрибуты.
Однако именно атрибуты (а не отношения!) являются в объект-атрибутной модели способом выделить объект из класса ему подобных. Отношения могут возникать, изменяться и исчезать (для учёта этого могут использоваться атрибуты отношений), а вот изменения атрибутов объектов мета-моделью, как правило, вообще не предусмотрены. Точнее говоря, в каждый момент времени у объекта есть только одно значение атрибута, и сохранение истории его изменений мета-модель не предполагает
Вот модель объекта Language из стандарта OMG Essence, записанная на языке OMG CMOF, это как раз объект-атрибутный подход.
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
73 |
Прямоугольники на диаграмме – объекты, отношения между ними обозначены линиями с разными типами стрелочек на концах, а атрибуты указаны в прямоугольниках именами с плюсиками перед ними. Объект Method имеет атрибут Purpose (значением которого будет текстовая строка), этот объект является подклассом объекта ElementGroup, у которого много атрибутов — имя, иконка, краткое и полное описания, и все они наследуются, в том числе и объектом Method.
Атрибуты очень понятны и привычны: есть автомобиль, у него есть атрибут "цвет", значение атрибута "цвет" для проезжающего автомобиля — красный. Похожим образом действительно описывал мир Аристотель, а когда были изобретены объекториентированное программирование и реляционные базы данных, информатика стала непредставима без атрибутов.
Для атрибутной мета-модели нет простого основания на философско-логическом и онтологическом уровнях. Как говорить об атрибутах без объектов? Что такое "цвет" без объекта? "Красный" — это может быть атрибут объектов машина, лазер, звездакарлик. Это один и тот же "красный"? Как это обсуждать?
Но и в сугубо практической деятельности возникают трудности. Если вам нужно сложить две объект-ориентированные модели мира, составленные разными людьми
– могут возникнуть существенные проблемы. С довольно большой вероятностью то, что отмоделировано в одном проекте как “объект”, будет в другом проекте “атрибутом”. И просто “слить вместе” такие две модели мира в одну будет нельзя, придётся эту модель переработать.
Например, два студента заводят таблички в базах данных двух лабораторий — один табличку лазеров с атрибутами "вес" и "частота", а другой табличку конденсаторов с атрибутами "вес" и "ёмкость". А третий студент спроектировал базу данных склада, в которой табличка называется “оборудование”, и в ней есть атрибуты "вес"
и"габарит", плюс атрибут "тип оборудования", с возможными значениями "лазер”
и“конденсатор” (и это ещё хороший вариант, потому что атрибут "тип оборудования" может оказаться просто текстовой строкой, в которую рано или поздно запишут и "канденсатор" и "лазир"). Вспомним функциональную нотацию, она неплохо подходит для описания атрибутов (на самом деле это как раз пример