Практики системной инженерии: как-для-Coursera vs. как-для-Udacity
Вот пример диаграммы классического прикладного образования для системной инженерии:
Это я просто сделал чуть более подробной ветку с классическими прикладными дисциплинами системной инженерии из более общей диаграммы фундаментального образования (см. эту диаграмму и все необходимые оговорки в https://ailev.livejournal.com/1431940.html).
К этой диаграмме тоже много оговорок:
1. Это дисциплины. Или практики? Практики всё-таки должны включать и инструменты тоже -- но практики именуются обычно по их дисциплинам, даже если инструменты не игнорируются.
2. Список классических основных дисциплин системной инженерии не совпадает с таковым из классического источника: ISO 15288:2015. И не совпадает с таковым из BKCASE/SEBoK, и ещё с огромным числом других "официальных источников" (включая NASA, INRIA и т.д.). Канона нет! Но этот список как-то отстоялся за последние годы, он оказался вполне удобен для работы. В таком виде он был и в учебнике "Системноинженерное мышление", и в учебнике "Системное мышление" -- и ни одного нарекания за все эти годы.
3. Список поддисциплин каждой дисциплины системной инженерии - там тоже почти нет новаций, но канон тут ещё меньший, и там сразу в каноне противоречия (так, дисциплина инженерии требований обычно включает в себя практику управления требованиями, но по содержанию она же явно включена в практику управления конфигурацией!). При этом список этих поддисциплин может быть весьма и пополняем и изменяем, в зависимости от прихотей авторов курса.
4. Список совсем уж прикладных дисциплин последнего уровня едва-едва намечен (все эти DSM и Use Case 2.0), это можно выбирать по вкусу. Если разрабатывать какой-то обзорный курс системной инженерии (традиционный "Введение в системную инженерию", только рассчитанный не на космическую или авиационную промышленность сразу с их антисистемными ГОСТами, а на нормальную системную коммерческую инженерию), то я бы руководствовался этой схемой: и шевелил бы там практики четвёртого уровня в прицеле на потенциальную предметную область. Понятно, что авиационные практики для какой-нибудь робототехники не пойдут, равно как автомобильные для атомщиков. Вообще, мой опыт показывает, что студенты приходят с проектами размером для бригады из 10-20 человек, так что никакие практики для тяжёлой военной системной инженерии я бы там не рекомендовал учить.
5. На диаграмме не показаны разные "монстровые методологии", например ТРИЗ++ (он был показан на более общей диаграмме в https://ailev.livejournal.com/1431940.html). С ними понятно что делать: разбирать на части, и относить выбранные части к указанному эээ... классификатору? Нет, я бы предпочёл диаграммку продолжать считать платформенной, и говорить, что выбранные части нужно выучивать в состав того или иного знаниевого модуля системной инженерии, интегрировать там и переплетать с другими выученными знаниями по практикам/дисциплинам.
Это всё мелкие оговорки. А теперь главнаый вопрос: всё это сегодня вилами по воде написано, ибо системноинженерный процесс кардинальным образом меняется. Вот, например, как можно по-другому записать этот же набор практик, напирая на моделеориентированность (и дальше при росте уровня порождения/generative и нарастания уровня agile и модификаций железных систем "прошивкой" можно ещё этот набор практик помодифицировать):
-- Инженерия системных целей (напополам с предпринимательством)
-- Высокоуровневое моделирование (инженерия системной архитектуры, включая порождение и изобретения)
-- Низкоуровневое моделирование - мультифизика, мегамоделирование, порождение
-- Обеспечение качества (верификация)
-- Порождающее производство (из битов в атомы)
-- Приёмка (валидация)
-- Эксплуатация и поддержка
-- «Мусоропереработка» (вывод из эксплуатации)
-- Инженерия знаний, НСИ, справочных данных
Понятно, что подпрактики в "моделеориентированности" там совсем уж другие будут, а в случае generative практик, то вообще всё абсолютно другое. Но эти практики даже ближе к жизни сегодняшней могут оказаться, чем замшелая классика из SEBoK.
Так что я отношусь к диаграммке на картинке как консервирование классического статус-кво начала века. Для меня это -- ну как помахать платочком уходящему прошлому, чтобы никто из академически настроенных системных инженеров не расстроился и не предъявил формальных претензий "несоответствия канону". Особо ничему не учит, но и не особо студентов портит. Даже наоборот, будет какая-то польза "прямо сейчас" (большинство ведь русскоязычных студентов отнюдь не в моделеориентированную инженерию попадёт после окончания курса, так что они ничего и не заметят).
Мне сегодня Даниил Браташов заметил в фейсбуке по поводу текста о EduOp, об ответственности исследователей за разработку курсов (https://www.facebook.com/groups/771940449578453/permalink/1497615923677565/): "Проекты вроде Coursera (и особенно Udacity) и задумывались изначально этакими EduOps, Udacity вроде держит выбранный курс, а вот курсера скатывается назад в классический университет через интернеты (и становится постепенно всё менее интересной, на мой взгляд)". Я ему ответил "Вообще-то "классический" раньше было словом в значении "образец для подражания". А сейчас значение меняется на ровно обратное: "сдохнешь, если будешь этому подражать"
Вот с системной инженерией примерно то же самое происходит сейчас. NVIDIA свои курсы по беспилотным автомобилям публикует на Udacity (https://www.udacity.com/course/self-driving-car-engineer-nanodegree--nd013). И не заморачиваются, что это "отход от инженерных канонов".
Так что диаграммка на картинке у меня, несмотря на все оговорки, классическая -- "для Курсеры". И критика её неизбежно будет как "из прошлого", так и "из будущего". Одним придётся доказывать, что "классику я знаю, но не беру её", другим "state-of-the-art я знаю, но мы сейчас зальём новое вино в старые мехи -- иначе не выжить". Вот тебе, бабушка, и EduOps.
Это я просто сделал чуть более подробной ветку с классическими прикладными дисциплинами системной инженерии из более общей диаграммы фундаментального образования (см. эту диаграмму и все необходимые оговорки в https://ailev.livejournal.com/1431940.html).
К этой диаграмме тоже много оговорок:
1. Это дисциплины. Или практики? Практики всё-таки должны включать и инструменты тоже -- но практики именуются обычно по их дисциплинам, даже если инструменты не игнорируются.
2. Список классических основных дисциплин системной инженерии не совпадает с таковым из классического источника: ISO 15288:2015. И не совпадает с таковым из BKCASE/SEBoK, и ещё с огромным числом других "официальных источников" (включая NASA, INRIA и т.д.). Канона нет! Но этот список как-то отстоялся за последние годы, он оказался вполне удобен для работы. В таком виде он был и в учебнике "Системноинженерное мышление", и в учебнике "Системное мышление" -- и ни одного нарекания за все эти годы.
3. Список поддисциплин каждой дисциплины системной инженерии - там тоже почти нет новаций, но канон тут ещё меньший, и там сразу в каноне противоречия (так, дисциплина инженерии требований обычно включает в себя практику управления требованиями, но по содержанию она же явно включена в практику управления конфигурацией!). При этом список этих поддисциплин может быть весьма и пополняем и изменяем, в зависимости от прихотей авторов курса.
4. Список совсем уж прикладных дисциплин последнего уровня едва-едва намечен (все эти DSM и Use Case 2.0), это можно выбирать по вкусу. Если разрабатывать какой-то обзорный курс системной инженерии (традиционный "Введение в системную инженерию", только рассчитанный не на космическую или авиационную промышленность сразу с их антисистемными ГОСТами, а на нормальную системную коммерческую инженерию), то я бы руководствовался этой схемой: и шевелил бы там практики четвёртого уровня в прицеле на потенциальную предметную область. Понятно, что авиационные практики для какой-нибудь робототехники не пойдут, равно как автомобильные для атомщиков. Вообще, мой опыт показывает, что студенты приходят с проектами размером для бригады из 10-20 человек, так что никакие практики для тяжёлой военной системной инженерии я бы там не рекомендовал учить.
5. На диаграмме не показаны разные "монстровые методологии", например ТРИЗ++ (он был показан на более общей диаграмме в https://ailev.livejournal.com/1431940.html). С ними понятно что делать: разбирать на части, и относить выбранные части к указанному эээ... классификатору? Нет, я бы предпочёл диаграммку продолжать считать платформенной, и говорить, что выбранные части нужно выучивать в состав того или иного знаниевого модуля системной инженерии, интегрировать там и переплетать с другими выученными знаниями по практикам/дисциплинам.
Это всё мелкие оговорки. А теперь главнаый вопрос: всё это сегодня вилами по воде написано, ибо системноинженерный процесс кардинальным образом меняется. Вот, например, как можно по-другому записать этот же набор практик, напирая на моделеориентированность (и дальше при росте уровня порождения/generative и нарастания уровня agile и модификаций железных систем "прошивкой" можно ещё этот набор практик помодифицировать):
-- Инженерия системных целей (напополам с предпринимательством)
-- Высокоуровневое моделирование (инженерия системной архитектуры, включая порождение и изобретения)
-- Низкоуровневое моделирование - мультифизика, мегамоделирование, порождение
-- Обеспечение качества (верификация)
-- Порождающее производство (из битов в атомы)
-- Приёмка (валидация)
-- Эксплуатация и поддержка
-- «Мусоропереработка» (вывод из эксплуатации)
-- Инженерия знаний, НСИ, справочных данных
Понятно, что подпрактики в "моделеориентированности" там совсем уж другие будут, а в случае generative практик, то вообще всё абсолютно другое. Но эти практики даже ближе к жизни сегодняшней могут оказаться, чем замшелая классика из SEBoK.
Так что я отношусь к диаграммке на картинке как консервирование классического статус-кво начала века. Для меня это -- ну как помахать платочком уходящему прошлому, чтобы никто из академически настроенных системных инженеров не расстроился и не предъявил формальных претензий "несоответствия канону". Особо ничему не учит, но и не особо студентов портит. Даже наоборот, будет какая-то польза "прямо сейчас" (большинство ведь русскоязычных студентов отнюдь не в моделеориентированную инженерию попадёт после окончания курса, так что они ничего и не заметят).
Мне сегодня Даниил Браташов заметил в фейсбуке по поводу текста о EduOp, об ответственности исследователей за разработку курсов (https://www.facebook.com/groups/771940449578453/permalink/1497615923677565/): "Проекты вроде Coursera (и особенно Udacity) и задумывались изначально этакими EduOps, Udacity вроде держит выбранный курс, а вот курсера скатывается назад в классический университет через интернеты (и становится постепенно всё менее интересной, на мой взгляд)". Я ему ответил "Вообще-то "классический" раньше было словом в значении "образец для подражания". А сейчас значение меняется на ровно обратное: "сдохнешь, если будешь этому подражать"
Вот с системной инженерией примерно то же самое происходит сейчас. NVIDIA свои курсы по беспилотным автомобилям публикует на Udacity (https://www.udacity.com/course/self-driving-car-engineer-nanodegree--nd013). И не заморачиваются, что это "отход от инженерных канонов".
Так что диаграммка на картинке у меня, несмотря на все оговорки, классическая -- "для Курсеры". И критика её неизбежно будет как "из прошлого", так и "из будущего". Одним придётся доказывать, что "классику я знаю, но не беру её", другим "state-of-the-art я знаю, но мы сейчас зальём новое вино в старые мехи -- иначе не выжить". Вот тебе, бабушка, и EduOps.