- •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 |
223 |
|||
|
|
|
|
|
|
|
условие для готовности к |
испытаний. |
|
|
|
|
разворачиванию |
|
|
|
|
|
(отсутствие неотвеченных |
|
|
|
|
|
замечаний). |
|
|
|
|
Удовлетворены в использовании |
|
|
|
|
|
Система удовлетворяет или превышает минимальные ожидания стейкхолдеров |
|
|
|||
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
||
|
(views) |
|
(viewpoints) |
|
|
Стейкхолдеры используют |
Эксплуатационные отчёты |
Формат исторических |
|
|
|
новую систему и |
|
|
данных (показания |
|
|
предоставляют обратную |
|
|
датчиков, журналы |
|
|
связь об их опыте. |
|
|
использования, журналы |
|
|
|
|
|
ремонтов и |
|
|
|
|
|
техобслуживания) |
|
|
Стейкхолдеры |
Протокол об отсутствии |
|
|
|
|
подтверждают, что новая |
рекламаций. |
|
|
|
|
система соответствует их |
Результаты опросов |
|
|
|
|
ожиданиям |
|
|
|
|
|
Возможности
Основа работы с возможностями — это предпринимательство, которое принципиально неформализуемо, ибо связано как-то с оценками будущего. В современном мире предпринимательские решения слабо поддаются формализации. Это относится и к таким решениям, как принятие заказа к исполнению в зависимости от текущей загрузки ресурсов — принятие решения на основе теории предельной (marginal/маржевой/граничной) полезности (utility) и маржинальных цен, или инвестиционные решения в проработку возможностей по заключению контракта или выходу на рынок. Но в силу сложности предпринимательской деятельности и коллективного её характера появилось довольно много практик формализации и документирования промежуточных для принятия предпринимательских (инвестиционных, стратегических, маркетинговых) решений.
Пожалуй, альфа возможности — это самая сложная для работы альфа. По сложности работы с ней может сравниться только альфа команды. С другой стороны, инженер может стать великим предпринимателем и великим лидером. Но отнюдь не каждый великий предприниматель и великий лидер может стать инженером, так что к оценкам относительной сложности работы с разными альфами нужно относиться очень осторожно: что просто для одного человека, может быть запредельно трудно и даже невозможно для другого, и наборот.
Среди подальф возможностей нужно особо указать “бюджет”, с которым работают практики бюджетирования (включая такие, как beyond budgeting), а также “потребности” (stakeholder needs), с которыми работают практики анализа потребностей (user needs analysis, целеориентированная инженерия требований и т.д.).
Определена
Коммерческая, общественная или инвестиционная возможность, которая могла бы быть адресована инженерным решением, определена.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
224 |
|||
|
|
|
|
|
|
|
(views) |
|
(viewpoints) |
|
|
Идея по способу |
Описание целей проекта |
Раздел в заявлении на |
|
|
|
улучшения текущих |
|
|
открытие проекта |
|
|
технологий работы, |
|
|
|
|
|
увеличения рыночной |
|
|
|
|
|
доли или по применению |
|
|
|
|
|
новой или инновационной |
|
|
|
|
|
инженерной системы была |
|
|
|
|
|
определена. |
|
|
|
|
|
Как минимум один из |
Подпись имеющего |
Место для подписи в |
|
|
|
стейкхолдеров желает |
ресурсы стейкхолдера на |
заявлении об открытии |
|
|
|
сделать инвестицию в |
заявлении на открытии |
проекта |
|
|
|
более подробное |
проекта |
|
|
|
|
понимание возможности и |
|
|
|
|
|
пользы, связанной с |
|
|
|
|
|
адресацией этой |
|
|
|
|
|
возможности. |
|
|
|
|
|
Другие стейкхолдеры, для |
Список стейкхолдеров |
Формат списка |
|
|
|
которых это общая |
|
|
стейкхолдеров |
|
|
возможность, определены. |
|
|
|
|
|
Нужно решение
Потребность в инженерном решении была подтверждена.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Стейкхолдеры для |
Список стейкхолдеров |
Формат списка |
возможности и |
|
стейкхолдеров |
предложенное решение |
|
|
были определены. |
|
|
Потребности |
Документированные |
Формат описания нужд |
стейкхолдеров, которые |
нужды стейкхолдеров |
стейкхолдеров (практика |
порождают возможность, |
|
user needs analysis) |
были установлены. |
|
|
Любые связанные с |
Список рисков |
Практика управления |
возможностью проблемы и |
|
рисками |
их корневые причины |
|
|
были определены. |
|
|
Было подтверждено, что |
Подпись руководителя на |
Практика |
инженерное решение |
решении (приказе, project |
предпринимательства |
нужно. |
charter, других формах |
|
|
инициирования проекта) |
|
По меньшей мере одно |
Предложена |
Формат представления |
инженерное решение было |
верхнеуровневая |
эскизной архитектуры и |
предложено. |
архитектура решения |
требования к ней для |
|
|
данного класса решений |
Польза установлена |
|
|
Польза успешного решения была установлена |
|
|
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
225 |
|||
|
|
|
|
|
|
Польза реализации |
Технико-экономическое |
Практики технико- |
|
|
|
возможности была |
обоснование |
экономических |
|
|
|
определена количественно |
необходимости системы |
обоснований, |
|
|
|
либо в абсолютных |
для клиента |
стратегирования, оценки |
|
|
|
значениях, либо в |
|
|
ROI и т.д. |
|
|
единицах дохода или |
|
|
|
|
|
экономии за период |
|
|
|
|
|
(например, за год). |
|
|
|
|
|
Влияние решения на |
Описание удовлетворения |
Таблица, в которой |
|
|
|
стейкхолдеров понятно. |
needs |
|
описаны колонки needs и |
|
|
|
|
|
влияния системы на них |
|
|
Польза, которую |
User needs |
|
Практика “User needs |
|
|
инженерная система |
Технико-экономическое |
analysis” |
|
|
|
предлагает стейкхолдерам, |
обоснование |
Практика технико- |
|
|
|
которые финансируют и |
|
|
экономических |
|
|
используют систему, |
|
|
обоснований (оценки |
|
|
понятна. |
|
|
стоимости). |
|
|
Критерии успеха, по |
Меморандум о целях |
Ключевые характеристики |
|
||
которым будет |
проекта с визами |
технического решения |
|
|
|
приниматься решение о |
стейкхолдеров |
|
|
|
|
разворачивании системы, |
|
|
|
|
|
ясны. |
|
|
|
|
|
Желаемые результаты, |
Архитектурные требования |
Формат представления |
|
|
|
требуемые от решения, |
(основные требования, |
требований (в части |
|
|
|
ясны и определены |
влияющие на архитектуру) |
архитектурных |
|
|
|
количественно. |
|
|
требований) |
|
|
Жизнеспособна
Согласовано, что решение может быть произведено достаточно быстро и дёшево, чтобы успешно реализовать возможность.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Решение обрисовано в |
Архитектурное описание |
Архитектурные практики |
общих чертах. |
|
|
Есть признаки, что |
Экспертное заключение по |
Архитектурные практики |
решение может быть |
архитектуре |
|
разработано и развёрнуто |
|
|
в текущих ограничениях. |
|
|
Риски, связанные с |
Таблица рисков и способа |
Практики управления |
решением, приемлемы и |
ответов на них |
рисками |
управляемы. |
|
|
Грубая оценка цены |
Бюджет проекта в |
Практики бюджетирования |
решения меньше, чем |
сравнении с технико- |
и технико-экономического |
ожидаемая польза от |
экономическим |
обоснования |
реализации возможности. |
обоснованием |
|
Причины для разработки |
Проведение kick-off |
Практики презентации и |
инженерного решения |
meeting |
контроля понимания |
понимаются всеми |
|
|
членами команды. |
|
|
Ясно, что реализация |
Экспертное заключение |
Практика feasibilities study |
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
226 |
возможности жизнеспособна.
Реализована
Решение, которое произведено, демонстрирует реализацию возможности.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Готовая к использованию |
Готовая система |
Конфигурационная |
система, которая |
|
ведомость |
демонстрирует |
|
|
реализацию возможности, |
|
|
доступна. |
|
|
Стейкхолдеры согласны, |
Акт о готовности к |
|
что доступное решение |
опытной эксплуатации |
|
заслуживает |
Приказ о переходе к |
|
разворачивания. |
эксплуатации |
|
Стейкхолдеры |
Подписание акта приёмки- |
|
удовлетворены тем, как |
сдачи |
|
разработанное решение |
Результаты опроса |
|
адресует возможность. |
|
|
Извлекается выгода
Эксплуатация или продажа решения создаёт осзязаемые выгоды.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Решение начало извлекать |
Акт о начале эксплуатации |
|
выгоды для |
|
|
стейкхолдеров. |
|
|
Профиль возврата |
Результат опроса |
|
инвестиций по меньшей |
стейкхолдеров- |
|
мере так хорош, как |
пользователей |
|
ожидалось. |
Сверка бюджета |
|
|
инженерной команды |
|
Определение системы
Определение системы в целом для инженерного проекта — это самый-самый верхний уровень детализации проекта, больше пригодный для общения с менеджерами, нежели для собственно инженерии.
С определением системы лучше работать, разбивая его на различные подальфы: как соответствующие отдельным частям-модулям (ибо речь идёт об управлении разработкой), так и соответствующие различным видам описаний: подальфы требований, архитектуры, неархитектурной части проекта.
Определение системы, даже если рассматривать его через подальфы, также крайне разношёрстно в части практик описания (так только архитектурное описание в стандарте DoDAF имеет 28 видов групп описаний/viewpoint. Крайне разнообразы также и рабочие продукты — проектная документация занимает много томов, инженерные базы данных имеют крайне сложные модели данных). Поэтому примеры практик работы с альфой определения системы носят очень условный
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
227 |
характер.
Замыслено
Ясно, каково будет определение системы.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Ясно, что будет считаться |
User needs |
Практика Needs analysis |
успехом для новой |
|
|
системы. |
|
|
Методы описания системы |
Список документов и |
Указание на ЕСКД, СПДС, |
согласованы. |
стандартов по их |
3D моделирование |
|
подготовке |
|
Способ согласования |
Завизированный |
Указывается способ |
описаний со |
меморандум по |
предоставления доступа к |
стейкхолдерами |
согласованиям |
рабочим продуктам, |
согласован. |
|
формат и способ запросов |
|
|
на изменения (указания |
|
|
проблем), графики и сроки |
|
|
предоставления обратной |
|
|
связи, необходимые визы |
|
|
и т.д. |
Механизмы управления |
Завизированный командой |
Указываются система |
конфигурацией описаний |
меморандум по |
хранения версий, система |
согласованы. |
управлению |
управления изменениями, |
|
конфигурацией |
регламенты по работе с |
|
|
ними, конкретные папки |
|
|
или базы данных, |
|
|
заведённые для проекта |
Непротиворечиво |
|
|
Определение системы создано и непротиворечиво. |
|
|
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Описания |
База данных в системе |
Практика управления |
документированы и |
управления |
конфигурацией |
доступны команде и |
конфигурацией, все члены |
|
стейкхолдерам. |
команды и стейкхолдеры |
|
|
имеют доступ к этой базе |
|
|
данных |
|
Происхождение описаний |
Мета-информация об |
Эккаунт в системе |
ясно. |
авторе (при этом каждый |
управления |
|
автор имеет свой эккаунт) |
конфигурацией для |
|
|
каждого члена команды и |
|
|
стейкхолдера |
Описания проверяются. |
Наличие отметок о |
Роли исполнителя и |
|
проверках, а не только об |
принимающего работу |
|
окончании работ |
разведены |
|
(возможно, реализуется |
|
|
как статус issue в issue |
|
|
tracker) |
|
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
228 |
|||
|
|
|
|
|
|
Противоречивые описания |
Issue, порождаемые по |
Практика проверок |
|
|
|
идентифицированы и ими |
обнаруженным коллизиям, |
(review, инструментальные |
|
||
занимаются. |
эти issue назначаются на |
проверки, сборки |
|
|
|
|
исполнителей и по ним |
конфигурации и т.д.) |
|
|
|
|
проводится работа. |
Практика управления |
|
|
|
|
|
|
изменениями |
|
|
Команда понимает |
Утверждённое |
Практика архитектурного |
|
|
|
описания и соглашается их |
архитектурное описание |
проектирования |
|
|
|
воплотить. |
Результаты опроса |
Практики MBSE |
|
|
|
Система, соответствующая |
Решение о начале |
|
|
|
|
описаниям, принимается |
производства |
|
|
|
|
стейкхолдерами как |
|
|
|
|
|
заслуживающая |
|
|
|
|
|
воплощения. |
|
|
|
|
|
Используется для изготовления
Определение системы используется для изготовления системы.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Подготовлено достаточное |
Рабочая документация |
Стандарты |
количество описаний |
(неархитектурные |
конструкторской и |
системы, чтобы начать |
решения) |
проектной документации |
изготавливать систему. |
|
|
Технологии изготовления |
Технологическая |
Стандарты |
определены. |
документация |
технологической |
|
|
документации |
Часть команды, |
Акт об успешном hand over |
Практики hand-over |
изготавливающая систему, |
Уведомление о начале |
(передачи всей |
признаёт описания |
производства |
необходимой информации |
достаточными для |
Визы технологов на |
на очередную стадию |
изготовления системы. |
проектной |
жизненного цикла) |
|
документации/моделях |
|
Возникающие при |
Запросы на изменения, |
Практика управления |
изготовлении проблемы |
проходящие обработку |
изменениями |
приводят к переработке и |
|
|
актуализации определения |
|
|
системы. |
|
|
Используется для проверки воплощения
Определение системы используется для проведения тестов и испытаний.
Контрольные вопросы |
Пример рабочих продуктов |
Пример практик описания |
|
(views) |
(viewpoints) |
Нет частей определения |
Проектная |
Архитектурное |
системы, без которых |
документация/модели |
проектирование |
проверки невозможны. |
Конфигурационная |
Управление |
|
ведомость |
конфигурацией |
Проверки, критерии их |
Программа испытаний |
Практики проверки и |
успешности и способ их |
|
приёмки (verification and |
проведения определены. |
|
validation, V&V) |
Стейкхолдеры согласны с |
Виза стейкхолдеров на |
Практика военной приёмки |