- •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 |
82 |
которые “моделью” язык не повернётся назвать. Кроме того, использование моделирования связано с затратами (закупка софта моделеров, обучение людей), и на одном проекте эти затраты могут не окупиться. Ах, кроме того, некогда закупать моделеры и отвлекать людей от срочных задач. На втором, третьем, десятом проекте ситуация повторяется, и так годами.
2. Существующий софт моделирования (моделеры) и поддерживаемые им языки моделирования плохи: неточно отражают моделируемые объекты. Например, не отражают основное инженерное понятие — понятие “система”. Да, каждые пятьдесять лет появляются новые языки моделирования и новое поколение программного обеспечения, но по-настоящему хороших и универсальных до сих пор нет. Без языков же и софта моделировать невозможно.
3.Модели (и результаты моделирования, например, расчёт по модели) оказываются непонятными людям. Решение об использовании моделирования принимают часто не непосредственные пользователи модели, а совсем другие люди — менеджеры и финансисты, которые ничего сами в моделировании не понимают, но знают, что в моделях есть ответ на нужные им вопросы. “Продать” им модели, в которых они не могут найти ответы на свои вопросы очень трудно. Современные моделеры не генерируют “попсовую” инфографику, они часто очень убоги в части дизайна. Поэтому решение об освоении технологии моделирования не принимается: уход денег очевиден, польза неочевидна, результаты непонятны.
4.Модели являются хорошим средством накопления знаний в организации. Если никто не заинтересован в накоплении знаний, то и интерес к моделированию слабый: зачем спрашивать модель, если всегда можно спросить Иван Иваныча? Ах, жаль, что он всегда занят, и его ответ нельзя распечатать и послать по почте, и вообще он пару недель болел в прошлом месяце. Но знания-то в нём есть! Мысль
же о том, что эти знания можно отделить от Ивана Ивановича в виде модели — эта мысль обычно не обсуждается, тем более что “искусственного интеллекта всё равно не сделать” и “экономически вы это ваше моделирование всё одно не обоснуете” (что правда).
Тем не менее, если посмотреть на происходящее в менеджменте и инженерии за последние пятнадцать лет, то из состояния “почти нигде, кроме самых развитых компаний” моделирование перешло в состояние “почти везде, кроме самых отсталых компаний”.
Информатика
Граница между онтологизированием, моделированием и программированием очень, очень зыбка и неопределённа. Все они — предмет изучения информатики (не путать с computer science), дисциплины по работе агентов (людей и компьютеров) с текстами и кодами.
Текст — понимается тут как "всё есть текст" ("text" is any object that can be "read," [человеком] whether this object is a work of literature, a street sign, an arrangement of buildings on a city block, or styles of clothing), неформален в части семантики и синтаксиса использованного в нём языка.
Код — формальное в части семантики и синтаксиса использованного языка представление какого-то содержания, независимо от сериализации в строку буковок или оставления в виде какого-нибудь графа, таблиц или триплов.
Особо нужно обсуждать действия в информатике: "акты" (в том числе речевые акты) и "вычисления" (в том числе отработка инструкций компьютером).
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
83 |
Информатика-в-малом — это когда работу с текстами и кодами ведёт один агент (компьютер или человек). Информатика-в-большом — когда в работе с текстами и кодами участвует много агентов.
Дисциплины информатики:
●(философская) логика, объектом практик которой является поиск наиболее компактных описаний для связи текстов и кодов с реальным миром, а также выражения связи с реальным миром формальных и неформальных языков, на которых представлены тексты и коды. Можно считать, что философия языка
— это тоже сюда.
●когнитивная наука (cognitive science), объектом практик которой является поиск наиболее компактных описаний для понимания (перевод текстов и кодов во внутреннее представление в голове человека) и писательство (порождение текстов и кодов из внутреннего представления в голове человека).
●лингвистика, объектом практик которой является поиск наиболее компактных описаний кодирования текста и отекстовки кодов.
●компьютерная наука (computer science), объектом практик которой является поиск наиболее компактных описаний перекодирования.
Сюда вполне можно отнести и биосемиотику (в варианте http://galicarnax.livejournal.com/39260.html).
Все эти дисциплины обладают немеренным шовинизмом, то есть пытаются прихватить в свой состав практики смежных дисциплин, поэтому границы между ними весьма расплывчаты. Тем не менее, специалисты одной дисциплины практически не понимают специалистов другой дисциплины, ибо их предметы крайне разнятся, а сообщества почти не пересекаются (подробнее: http://ailev.livejournal.com/1008054.html).
Важно понимать, что текст и код тут понимаются как описывающие что-то (возможно, бывшее, будущее или даже фантастическое и невозможное) в мире, то есть интересует даже не просто “математика работы с текстами/кодами”, а и отношение результатов этой работы к окружающему миру — онтологизирование и моделирование акцентируют именно этот аспект, в то время как программирование уделяет этому аспекту недостаточное внимание.
Принципы моделеориентированности
Работы группы AtlanMod (http://www.emn.fr/z-info/atlanmod/index.php/Main_Page)
посвящены подходу model-driven engineering (моделеориентированная инженерия). Как -based, так и -driven оба переводятся как -ориентированная, но имеют разный смысл. -Based означает, что для решения каких-то задач выполняется моделирование. Далее человек смотрит на результаты моделирования (расчёт, текст, чертёж, диаграмму) и делает очередную модель (расчёт, текст, чертёж, диаграмму). А вот -driven означает, что модель является основным, что работает — на неё не “глядят для осмысления, и сочиняют другую модель”, а она компьютерно преобразуется с добавлением новых данных в другую необходимую модель. Часто про model-driven подход говорят как о преобразованиях (transformation) моделей.
Вот десять принципов model-driven engineering, сформулированные Jean Bezivin (один из бывших руководителей группы AtlanMod, далее мы цитируем по его презентации