Каталог практик инженерного проекта
Сразу несколько клиентов заговорили о тьюториалах осенью -- неожиданно они становятся нашим популярным продуктом. Беда в том, что всем им требуются разные тьюториалы на очень похожие темы. Скажем, два клиента сейчас хотят примерно восьмидневный тьюториал, но у одного будет возможность flip teaching (то есть люди будут знакомиться с объяснительными материалами до собственно тьюториала), а у другого не будет. Это значит, что у первого клиента люди затратят на занятия примерно вдвое больше времени, чем у второго -- и эти тьюториалы никак нельзя считать одинаковыми, несмотря на похожесть тем и затрат времени ведущих.
Тем самым нужно перейти к product lines, и наладить управление конфигурацией. Сейчас (поскольку тьюториалы были периферийной нашей активностью) управление конфигурацией было реализовано в виде толстого набора слайдов, из которых надёргивались нужные для каждого и дополнительно готовились недостающие. Проблемы с этим подходом в том, что:
а) трудно формулировать программы (аутлайн рассказываемого), ибо слайды единичны по природе своей.
б) трудно поддерживать актуальным набор слайдов (держать "мастер дек"), ибо для каждого тьюториала делается довольно много новых слайдов и обновляются старые. При вставке их в старый полный набор возникает много проблем (например, куда именно их вставлять? Общего-то аутлайна "теории всего" нет!)
б) по слайдам невозможно организовать flip teaching (нужны объясняющие тексты, оригинальная литература и лекции, а не только картинки).
С другой стороны, мы сами методологи -- то есть организация методического материала как раз и является нашей специализацией. Так что я затеял большую реорганизацию "внутри себя":1. Перевожу излагаемое по большей части в формат практик (то есть делаю моделирование в OMG Essence). Одна из целей такого моделирования -- осознанно разделить теорию (альфы и деятельности -- то, что может переноситься из одного производственного контекста в другой) и производственные контексты (варианты рабочих продуктов и возможные дела). Учить нужно общему, а привязка к производственным контекстам -- это задача уже не тьюториалов, а консалтинга.
После этого для создания отдельного тьюториала нужно будет выбрать из этого огромного каталога практик необходимые для того или иного тьюториала (возможно, переопределив уровень подробности и порядок их изложения).
Опираюсь в изложении на системный язык (да, я знаю, что его ещё нет -- но это не значит, что уже имеющихся идей этого языка не хватает, чтобы компактифицировать и переориентировать изложение). Это означает, что OMG Essence в части основ инженерного проекта (kernel) и системный язык должны быть как-то гармонизированы (в том числе и путём изменения Essence, мы уже начали это в части альф инженерного решения путём замены их на определение и воплощение системы).
"Претендотипом" такого каталога практик может быть большой аутлайн всего текущего содержания (и тут надо сказать, что я уже имею довольно развёрнутый аутлайн в части системноинженерного мышления в управлении жизненным циклом и именно в эти дни активно дорабатываю этот аутлайн до более-менее полного, это потянет на . Похоже, это будет порядка семисот строчек в первом варианте). Конечно, аутлайн -- это не полная модель (это всего-навсего классификатор, по большому счёту, и проблемы с ним те же, что с любым классификатором), но программы тьюториалов по его дереву (в текущем варианте у него до 9 уровней) обсуждать много легче, чем по вытянутым в линеечку сотням слайдов.
Вот для примера фрагментик такого аутлайна в его текущем состоянии (смотреть лучше каким-нибудь Sublime Text 3 с Tab Size=2, чтобы были лучше видны уровни дерева):
системное мышление/system thinking
ситуационная инженерия методов
появление инженерии методов (по Donald Firesmith)
основная идея инженерии методов: язык (дробление метода на части)
поколения инженерии методов
первое поколение: язык OPF, SPEM 2.0,
второе поколение: OMG Essence язык + основы (основные сущности, kernel)
инженерия как теория
альфы как идеальные объекты и рабочие продукты как реальные объекты
физическое тело: пример
контринтуитивность и мощность теории
инженерия как коллективная деятельность в отличие от изобретательства
изобретательство (безумные "учёные" из мультфильмов, "прикладная наука" с НИОКР)
байка из gaperton про "программировать" против "работать"
computer science против software engineering
яблоки из задачи vs. яблоки из жизни
диаграмма альф инженерного проекта
области интересов инженерной компании: клиента, инженерного решения, предпринятия
основы инженерного проекта
деятельности (activity spaces) и состояния альф
чеклисты состояний альф
разделение и объединение труда как способ борьбы со сложностью
разделение труда системных инженеров (как врачи)
пример госпиталя в Индии
компетенции инженерного проекта
практика чеклистов
отражают не всё, а только главное (в том числе банальное: 1. Fly the aircraft)
прогон в специальных паузах (pause point) перед началом или окончанием каких-то работ
обязательно вслух, читает не начальник
срабатывают 1 раз из 10 (и 9 холостых прогонов окупаются полностью одной предотвращённой неудачей)
карточки состояний альф с контрольными вопросами и их использование (в том числе практическая работа)
понятие системы
бытовое и терминологическое понятие системы
"система классификации" -- синонимизация "систематичности и системности"
кибернетическая парадигма, гомеостазис
одновременное удерживание множества представлений
метафоры: инь-ян-хрень, оператор select
метанойя: необходимость мозгового тренинга (как религиях, так и в математике и логике)
холон: воплощение системы
мереология -- наука о частях и целом
уровни структуры вещества
система из систем, система-подсистема, Russian Babushka Doll
нельзя путать "система в составе системы" с "системой систем"
функциональное определение системы: никогда не начинать с конструкции!
Неявное присутствие деятеля в функции ("система в глазах смотрящего"), определяющего назначение системы
диаграмма гамбургера "функциональные слоты -- конструктивные модули"
механизм и эмерджентность (несводимость целого к частям)
интерфейсы и классификация систем: целевая система, системы в операционном окружении (неявное время), обеспечивающие системы (неявное время)
функциональный и физический объекты
физичность системы: система и её сервис, система и capabilities
правила для элементов системы (по Mathew West)
4D: "черви", индивиды и состояния, пространственно-временные диаграммы -- сведение сложных отношений к мереологии (и тем самым протаскивание эмерджентности)
система, элемент системы (с тегом) и устанавливаемый физический объект (серийный номер)
замены элементов системы в физическом смысле: 4D-диаграммы замены насоса, двигателя
прерывистость существования элементов системы
жизненный цикл комплектующих/предметов снабжения -- диаграмма по RDS-PP
жизненный цикл задвижки -- пример диаграммы из ISO 15926
жизненный цикл системы
онтологический статус: activity, в которой принимают участие разные объекты, в том числе система не всегда времени operation, в том числе стадии определения системы)
всегда полный. Отличия от жизненного цикла проекта
всегда разбит на стадии. "Минималистичная диаграмма ЖЦ" (стрела времени с засечками)
Критерий выделения стадии (mental framework)
пересекаемость стадий.
типовые стадии (замысел, проект, изготовление, эксплуатация, вывод из эксплуатации), примеры разнообразия ("колбаски" из ISO 15288)
предметная многомерность современного представления(множество альф, проходящих состояния и рабочих продуктов, проходящих уровни детальности)
холонная многомерность (разница жизненных циклом на разных уровнях воплощения)
практики жизненного цикла и связь с ситуационной инженерией метода ("языки описания жизненного цикла" в отличие от языков процессов и языков проектов)
V-диаграмма
вариативность множественность вариантов
основная идея: связь определения системы и воплощения системы через V&V
особость представления эксплуатации (operations)
недопустимость "одномерного" трактования V-диаграммы как строгой последовательности: диалог в каждый момент времени
вариант диаграммы с альфами определения (последовательность "фокусирования") и воплощения (последовательность сборки) системы
многомерный жизненный цикл по Essence
горбатая диаграмма: оценка распределение труда по практикам
понятие "управления жизненным циклом" (в противопоставлении "управления старением", проектному/процессному управлению, поиску коллизий и т.д.)
жизненный цикл как особый объект для договорённостей менеджеров и инженеров
ошибки рассинхронизации инженерной и менеджерской работы (отдельный слайд)
виды жизненного цикла
водопад против agile (и всевозможные промежуточные варианты)
пошаговая модель выделения ресурсов (incremental commitment model)
гейты: ACM Ancor point review (синхронизация множества жизненных циклов)
генератор видов ЖЦ по профилю рисков
многообразие форм представления ЖЦ (roadmap FIATECH)
главная мысль управления ЖЦ: перевод операций с атомами в операции с битами (упор на определение системы вместо воплощения системы)
трудность выделения границ ЖЦ по supply chain (диаграмма производства карандаша)
информационные системы управления жизненным циклом (на диаграмме жизненного цикла оборудования)
системный язык
цель: обеспечить формальность в мультидисциплинарных рассуждениях про целое (логицизм: http://ailev.livejournal.com/1059168.html)
современное состояние: не используется в силу монодисциплинарности большинства инженерных нотаций.
требования к языку: http://ailev.livejournal.com/1061167.html
ближайшие подходы: ISO 15926 и HQDM без нотации, ISO 42010 только к архитектуре, OMG Essence и т.д. Сервис-ориентация, capabilities и т.д.
как ISO 15926 моделирует систему -- какие типы задействуются в этом моделировании
критика существующих языков:
системная динамика
архитектурные языки (UML, SysML, AADL)
Modelica (в том числе SysML+Modelica)
контрактные языки + constraints languages (логические языки)
онтология
проблемы с онтологическим понятием "система"
4D extensionalism
эпистемология: "невечные" классы
факт-ориентированные представления
книжка BORO
практические трудности по выделению систем
необходимость тренинга в выделении систем
основные ошибки
недеятельностное выделение системы
в тачку не положишь, не пнёшь (не воплощения) -- процессы, деятельности, технологии, стандарты, продуктные линии, типовые проекты и т.д.
неверно проведённые границы (например, рынок в SmartGrid)
игнорируется полный жизненный цикл, только жизненный цикл проекта
немногомерный жизненный цикл, то есть отслеживаются не все альфы
"системная медитация" для целевых систем по http://ailev.livejournal.com/1040842.html
Материал далее бьётся по основным областям интересов инженерной компании (клиентская, инженерного решения, предпринятие) и там дальше по практикам работы с основными альфами этих областей интересов (в том числе подальфам -- например, для альфы определения системы подальфы требований, архитектуры, дизайна. Ну, и подальфами уже этих подальф -- например, по требованиям это user story, user case и т.д.).
Обратите внимание, насколько тут представленное отличается от рассказываемого в лекциях 2012 в МФТИ -- за прошедший год с небольшим материал в нынешних тьюториалах поменялся очень существенно!
2. К модели практик в Essence приложить guides:
-- слайды (картинки диаграмм без текстов), ибо многие хотят живых лекций
-- тексты (со слайдами в качестве картинок), желательно письменные, но можно и видеолекции (это хуже, так как смотреть их дольше). В каком-то приближении такими текстами можно считать некоторые тексты у меня в блоге -- только в блоге я не часто забочусь о понятности этих текстов, о связях между текстами, вытаскивании картинок из первоисточников в сам текст и т.д.. Более точным приближением являются мои видеолекции, но тамошние транскрипты моей устной речи абсолютно нечитаемы, их нужно переписывать.
-- "хрестоматию" (фрагменты оригинальных статей, стандартов и т.д. -- чтобы было знакомство с первоисточниками)
-- наборы тестов и упражнений (главная задача которых -- это проверить понимание происходящего с "яблоками из задачи" и затем тренинг совмещения "яблок из задачи" с "яблоками из жизни").
Это всё материалы для flip teaching (они же могут пойти как основа для distance learning, они же -- раздатка для участников очных тьюториалов).
Особо нужно обсуждать, как устроить управление конфигурацией в этой части (в том числе как привязывать все эти тексты к модели/аутлайну, как устраивать нарезку его на материал для отдельных тьюториалов -- и не терять при этом целостности).
Ровно этим всем я и собираюсь позаниматься. В идеале результаты этой работы будут выложены в открытый доступ, а продавать мы будем доработки содержания образования под потребности клиентов и общение с авторами -- не "лекторий" (это всё будет в письменном виде), а "семинарские занятия" по привязке к производственному контексту клиентов. Ибо быть магнитофоном скучно, но для избавления от этой магнитофонности приходится попотеть.
Тем самым нужно перейти к product lines, и наладить управление конфигурацией. Сейчас (поскольку тьюториалы были периферийной нашей активностью) управление конфигурацией было реализовано в виде толстого набора слайдов, из которых надёргивались нужные для каждого и дополнительно готовились недостающие. Проблемы с этим подходом в том, что:
а) трудно формулировать программы (аутлайн рассказываемого), ибо слайды единичны по природе своей.
б) трудно поддерживать актуальным набор слайдов (держать "мастер дек"), ибо для каждого тьюториала делается довольно много новых слайдов и обновляются старые. При вставке их в старый полный набор возникает много проблем (например, куда именно их вставлять? Общего-то аутлайна "теории всего" нет!)
б) по слайдам невозможно организовать flip teaching (нужны объясняющие тексты, оригинальная литература и лекции, а не только картинки).
С другой стороны, мы сами методологи -- то есть организация методического материала как раз и является нашей специализацией. Так что я затеял большую реорганизацию "внутри себя":1. Перевожу излагаемое по большей части в формат практик (то есть делаю моделирование в OMG Essence). Одна из целей такого моделирования -- осознанно разделить теорию (альфы и деятельности -- то, что может переноситься из одного производственного контекста в другой) и производственные контексты (варианты рабочих продуктов и возможные дела). Учить нужно общему, а привязка к производственным контекстам -- это задача уже не тьюториалов, а консалтинга.
После этого для создания отдельного тьюториала нужно будет выбрать из этого огромного каталога практик необходимые для того или иного тьюториала (возможно, переопределив уровень подробности и порядок их изложения).
Опираюсь в изложении на системный язык (да, я знаю, что его ещё нет -- но это не значит, что уже имеющихся идей этого языка не хватает, чтобы компактифицировать и переориентировать изложение). Это означает, что OMG Essence в части основ инженерного проекта (kernel) и системный язык должны быть как-то гармонизированы (в том числе и путём изменения Essence, мы уже начали это в части альф инженерного решения путём замены их на определение и воплощение системы).
"Претендотипом" такого каталога практик может быть большой аутлайн всего текущего содержания (и тут надо сказать, что я уже имею довольно развёрнутый аутлайн в части системноинженерного мышления в управлении жизненным циклом и именно в эти дни активно дорабатываю этот аутлайн до более-менее полного, это потянет на . Похоже, это будет порядка семисот строчек в первом варианте). Конечно, аутлайн -- это не полная модель (это всего-навсего классификатор, по большому счёту, и проблемы с ним те же, что с любым классификатором), но программы тьюториалов по его дереву (в текущем варианте у него до 9 уровней) обсуждать много легче, чем по вытянутым в линеечку сотням слайдов.
Вот для примера фрагментик такого аутлайна в его текущем состоянии (смотреть лучше каким-нибудь Sublime Text 3 с Tab Size=2, чтобы были лучше видны уровни дерева):
системное мышление/system thinking
ситуационная инженерия методов
появление инженерии методов (по Donald Firesmith)
основная идея инженерии методов: язык (дробление метода на части)
поколения инженерии методов
первое поколение: язык OPF, SPEM 2.0,
второе поколение: OMG Essence язык + основы (основные сущности, kernel)
инженерия как теория
альфы как идеальные объекты и рабочие продукты как реальные объекты
физическое тело: пример
контринтуитивность и мощность теории
инженерия как коллективная деятельность в отличие от изобретательства
изобретательство (безумные "учёные" из мультфильмов, "прикладная наука" с НИОКР)
байка из gaperton про "программировать" против "работать"
computer science против software engineering
яблоки из задачи vs. яблоки из жизни
диаграмма альф инженерного проекта
области интересов инженерной компании: клиента, инженерного решения, предпринятия
основы инженерного проекта
деятельности (activity spaces) и состояния альф
чеклисты состояний альф
разделение и объединение труда как способ борьбы со сложностью
разделение труда системных инженеров (как врачи)
пример госпиталя в Индии
компетенции инженерного проекта
практика чеклистов
отражают не всё, а только главное (в том числе банальное: 1. Fly the aircraft)
прогон в специальных паузах (pause point) перед началом или окончанием каких-то работ
обязательно вслух, читает не начальник
срабатывают 1 раз из 10 (и 9 холостых прогонов окупаются полностью одной предотвращённой неудачей)
карточки состояний альф с контрольными вопросами и их использование (в том числе практическая работа)
понятие системы
бытовое и терминологическое понятие системы
"система классификации" -- синонимизация "систематичности и системности"
кибернетическая парадигма, гомеостазис
одновременное удерживание множества представлений
метафоры: инь-ян-хрень, оператор select
метанойя: необходимость мозгового тренинга (как религиях, так и в математике и логике)
холон: воплощение системы
мереология -- наука о частях и целом
уровни структуры вещества
система из систем, система-подсистема, Russian Babushka Doll
нельзя путать "система в составе системы" с "системой систем"
функциональное определение системы: никогда не начинать с конструкции!
Неявное присутствие деятеля в функции ("система в глазах смотрящего"), определяющего назначение системы
диаграмма гамбургера "функциональные слоты -- конструктивные модули"
механизм и эмерджентность (несводимость целого к частям)
интерфейсы и классификация систем: целевая система, системы в операционном окружении (неявное время), обеспечивающие системы (неявное время)
функциональный и физический объекты
физичность системы: система и её сервис, система и capabilities
правила для элементов системы (по Mathew West)
4D: "черви", индивиды и состояния, пространственно-временные диаграммы -- сведение сложных отношений к мереологии (и тем самым протаскивание эмерджентности)
система, элемент системы (с тегом) и устанавливаемый физический объект (серийный номер)
замены элементов системы в физическом смысле: 4D-диаграммы замены насоса, двигателя
прерывистость существования элементов системы
жизненный цикл комплектующих/предметов снабжения -- диаграмма по RDS-PP
жизненный цикл задвижки -- пример диаграммы из ISO 15926
жизненный цикл системы
онтологический статус: activity, в которой принимают участие разные объекты, в том числе система не всегда времени operation, в том числе стадии определения системы)
всегда полный. Отличия от жизненного цикла проекта
всегда разбит на стадии. "Минималистичная диаграмма ЖЦ" (стрела времени с засечками)
Критерий выделения стадии (mental framework)
пересекаемость стадий.
типовые стадии (замысел, проект, изготовление, эксплуатация, вывод из эксплуатации), примеры разнообразия ("колбаски" из ISO 15288)
предметная многомерность современного представления(множество альф, проходящих состояния и рабочих продуктов, проходящих уровни детальности)
холонная многомерность (разница жизненных циклом на разных уровнях воплощения)
практики жизненного цикла и связь с ситуационной инженерией метода ("языки описания жизненного цикла" в отличие от языков процессов и языков проектов)
V-диаграмма
вариативность множественность вариантов
основная идея: связь определения системы и воплощения системы через V&V
особость представления эксплуатации (operations)
недопустимость "одномерного" трактования V-диаграммы как строгой последовательности: диалог в каждый момент времени
вариант диаграммы с альфами определения (последовательность "фокусирования") и воплощения (последовательность сборки) системы
многомерный жизненный цикл по Essence
горбатая диаграмма: оценка распределение труда по практикам
понятие "управления жизненным циклом" (в противопоставлении "управления старением", проектному/процессному управлению, поиску коллизий и т.д.)
жизненный цикл как особый объект для договорённостей менеджеров и инженеров
ошибки рассинхронизации инженерной и менеджерской работы (отдельный слайд)
виды жизненного цикла
водопад против agile (и всевозможные промежуточные варианты)
пошаговая модель выделения ресурсов (incremental commitment model)
гейты: ACM Ancor point review (синхронизация множества жизненных циклов)
генератор видов ЖЦ по профилю рисков
многообразие форм представления ЖЦ (roadmap FIATECH)
главная мысль управления ЖЦ: перевод операций с атомами в операции с битами (упор на определение системы вместо воплощения системы)
трудность выделения границ ЖЦ по supply chain (диаграмма производства карандаша)
информационные системы управления жизненным циклом (на диаграмме жизненного цикла оборудования)
системный язык
цель: обеспечить формальность в мультидисциплинарных рассуждениях про целое (логицизм: http://ailev.livejournal.com/1059168.html)
современное состояние: не используется в силу монодисциплинарности большинства инженерных нотаций.
требования к языку: http://ailev.livejournal.com/1061167.html
ближайшие подходы: ISO 15926 и HQDM без нотации, ISO 42010 только к архитектуре, OMG Essence и т.д. Сервис-ориентация, capabilities и т.д.
как ISO 15926 моделирует систему -- какие типы задействуются в этом моделировании
критика существующих языков:
системная динамика
архитектурные языки (UML, SysML, AADL)
Modelica (в том числе SysML+Modelica)
контрактные языки + constraints languages (логические языки)
онтология
проблемы с онтологическим понятием "система"
4D extensionalism
эпистемология: "невечные" классы
факт-ориентированные представления
книжка BORO
практические трудности по выделению систем
необходимость тренинга в выделении систем
основные ошибки
недеятельностное выделение системы
в тачку не положишь, не пнёшь (не воплощения) -- процессы, деятельности, технологии, стандарты, продуктные линии, типовые проекты и т.д.
неверно проведённые границы (например, рынок в SmartGrid)
игнорируется полный жизненный цикл, только жизненный цикл проекта
немногомерный жизненный цикл, то есть отслеживаются не все альфы
"системная медитация" для целевых систем по http://ailev.livejournal.com/1040842.html
Материал далее бьётся по основным областям интересов инженерной компании (клиентская, инженерного решения, предпринятие) и там дальше по практикам работы с основными альфами этих областей интересов (в том числе подальфам -- например, для альфы определения системы подальфы требований, архитектуры, дизайна. Ну, и подальфами уже этих подальф -- например, по требованиям это user story, user case и т.д.).
Обратите внимание, насколько тут представленное отличается от рассказываемого в лекциях 2012 в МФТИ -- за прошедший год с небольшим материал в нынешних тьюториалах поменялся очень существенно!
2. К модели практик в Essence приложить guides:
-- слайды (картинки диаграмм без текстов), ибо многие хотят живых лекций
-- тексты (со слайдами в качестве картинок), желательно письменные, но можно и видеолекции (это хуже, так как смотреть их дольше). В каком-то приближении такими текстами можно считать некоторые тексты у меня в блоге -- только в блоге я не часто забочусь о понятности этих текстов, о связях между текстами, вытаскивании картинок из первоисточников в сам текст и т.д.. Более точным приближением являются мои видеолекции, но тамошние транскрипты моей устной речи абсолютно нечитаемы, их нужно переписывать.
-- "хрестоматию" (фрагменты оригинальных статей, стандартов и т.д. -- чтобы было знакомство с первоисточниками)
-- наборы тестов и упражнений (главная задача которых -- это проверить понимание происходящего с "яблоками из задачи" и затем тренинг совмещения "яблок из задачи" с "яблоками из жизни").
Это всё материалы для flip teaching (они же могут пойти как основа для distance learning, они же -- раздатка для участников очных тьюториалов).
Особо нужно обсуждать, как устроить управление конфигурацией в этой части (в том числе как привязывать все эти тексты к модели/аутлайну, как устраивать нарезку его на материал для отдельных тьюториалов -- и не терять при этом целостности).
Ровно этим всем я и собираюсь позаниматься. В идеале результаты этой работы будут выложены в открытый доступ, а продавать мы будем доработки содержания образования под потребности клиентов и общение с авторами -- не "лекторий" (это всё будет в письменном виде), а "семинарские занятия" по привязке к производственному контексту клиентов. Ибо быть магнитофоном скучно, но для избавления от этой магнитофонности приходится попотеть.