Как учить основам инженерного подхода

Как учить основам инженерного подхода

by Евгений Волков -
Number of replies: 0
Пишет Anatoly Levenchuk (ailev
2017-02-24 10:53:00
http://ailev.livejournal.com/1332397.html

Как учить основам инженерного подхода

Анатолий Шперх опять обсуждает основы инженерного подхода, вытащив текст Дмитрия Польского про аккуратность как что-то в этом инженерном подходе важное -- https://www.facebook.com/shperk/posts/10158233057340153. И дальше опять ставится вопрос, как "на коленке" сочинить народный эпос про инженерные умения, который (чисто в традициях советской инженерной школы) как-то передавать ученикам. Что должно войти в этот эпос? Уже понятно, чем должна закончиться такая дискуссия: "был бы хороший инженер, который должен стать педагогом и заинтересовать, а уж чему он научит будущих инженеров -- это он разберётся. Если хороший инженер и педагог, то как-то всё само произойдёт". Ну да, это просто продолжение обсуждений советской инженерной школы, где никакой науки про саму инженерию как дисциплину нет (это ж для советского инженера неформализуемое "творчество", научному изучению и потом научению других недоступно! ну, разве на кухне или в фейсбуке вечерком поговорить с коллегами-творцами), а интуитивные знания передаются по цепочке поколений как народный эпос.

Для меня советская школа инженерии это переросшее себя ремесленничество, кулибинство, которое может выпускать доведённые по месту напильником отдельные изделия и гениальные технические решения, но с середины восьмидесятых годов (после появления второго поколения системного подхода и оформления системной инженерии как отдельной дисциплины) стремительно отстающее явление.

Вернёмся к "аккуратности" и "ремонтопригодности", о которой следует сообщать инженерам. Анатолий Шперх задаёт вопрос -- базовое ли это в проекте? Этому ли нужно учить. Мой ответ: конечно, это не базовое понятие, ибо это просто конкретный пример одного из concerns (уровень удовлетворения которого задаётся в quality requirements). Дальше можно обсуждать: сначала научить аккуратности и ремонтопригодности, а потом сказать, что это примеры concerns, которых десятки и что на эту тему в проектах есть требования, не менее важные, чем требования по функциональности, или сразу рассказать, что есть concerns и requirements, и всеми этими -остями нужно будет заниматься, и вариантов избежать этого нет. Это уже неважно, вопрос ведь не стоит "как научить". Вопрос стоит в том, что лежит в основе инженерного подхода -- чему учить. Как учить, кто будет учить, когда этому учить -- это второй вопрос. Если неизвестно, чему учить, то обсуждение "как учить инженерии" бессмысленно.

Вот мои комменты из того треда:

Для меня это [предложения Дмитрия Польского и Анатолия Шперха] такой интуитивный способ говорить про системную инженерию, формулировать на ходу её понятия, перечислять "на пальцах" наиболее распространённые concerns (особенно -ilities, связанные с качеством -- у нас это -ость: модульность, ремонтопригодность, доступность, реализуемость, эстетичность и т.д., т.е. то, что будет общее для всех, не связано с конкретной функцией). Но при этом не заговаривать о требованиях, архитектуре, жизненном цикле.
Для меня это неприемлемо, ибо знание немногих принципов заменяет знание многих фактов. Что в одном месте будет "провода не торчат", в другом месте будет чем-то совсем другим -- нужно как-то компактифицировать мышление инженера. Нельзя, чтобы физики учили траектории полёта гаек, шариков, пуль и всего остального так, как тут учим инженерии роботов, сепулек и разного всего другого. Нужно учить траектории "физического тела", а в инженерии нужно учить работать с "целевой системой" -- и дальше, конечно, будут нюансы в полётах пули в воздухе и гаечки при разных скоростях и закрутках, а также нюансы разных инженерий, но принципы должны быть вбиты в головы в самом общем виде.

Опять же, в мире ардуинов учат ремесленному подходу чаще всего: в явном виде требования не выявляются, архитектурные решения как таковые не обсуждаются, разработка идёт методом проб и ошибок. И нужно думать, как объяснить, что инженерное мышление в мире из такого кулибинства давно вышло, что оно осталось по факту только в хоббийном мире -- "доводка по месту напильником" инженерами уже не считается хорошим тоном, разделение труда существенно изменило понимание "технологичности" и инженерия от режима ремесленничества уходит к режиму мануфактуры.

Так что при постановке задачи на привитие инженерного мышления хорошо бы перестать его формулировать интуитивно. Увы, это противоречит идеям советской инженерной школы. Пичалька.

Конечно, известен и другой путь. Учат, например, что такое "физическое тело" и понятие траектории. А потом учат тому, какова траектория физического тела. А дальше подумайте сами, как люди приходят к идее, что собаки, гайки, гири и бетонные блоки летят по параболе, если их кинуть с какой-то скоростью. Один вариант -- нужно побольше кидать, и прийти к обобщению (как это когда-то сделали люди, сформулировавшие потом про физическое тело, траекторию и параболу). Второй вариант -- воспользоваться уже готовым знанием и научиться отождествлять все предметы в мире с физическими телами, и когда эти предметы бросают, то сразу понимать, что там будет парабола. Я вот предлагаю сразу учить понятиям целевой системы, требований, архитектуры, жизненного цикла и т.д.. И уметь их видеть в окружающем мире. И этот мир неожиданно будет проще, в разы и разы. Для этого все такие понятия и придуманы.

К сожалению, связь функции и конструкции не изучается в школьных предметах, системный подход и системное мышление только в биологии как-то встречаются. Вот, я уже предлагаю плюнуть слюной на робототехнику как дисциплину, в которой можно начинать объяснять что-то про инженерию и системы. Может, проще зайти со стороны биологии, там больше шансов наладить работу понимающего мозга, а рефлексы бездумной мелкой псевдотворческой моторики по сборке-разборке и доточке напильником роботов: http://ailev.livejournal.com/1332207.html

"Аккуратность" -- это тоже -ость wink В английском эти слова обычно на -ility. Вот список примеров concerns из ISO 42010, посмотрите, сколько там слов на -ility. Это и есть базовый уровень: рассказать про наличие таких контролируемых в проекте сущностей, а затем научить с этим работать, удерживать это в мышлении сначала при полном напряжении мозгов, а потом "на автомате", уже бессознательно -- но при любом обсуждении уметь вытащить из бессознательного и обсудить явно, не сочиняя на ходу, а опираясь на знания, полученные в обучении. Вот этот список: functionality, feasibility, usage, system purposes, system features, system properties, known limitations, structure, behavior, performance, resource utilization, reliability, security, information assurance, complexity, evolvability, openness, concurrency, autonomy, cost, schedule, quality of service, flexibility, agility, modifiability, modularity, control, inter-process communication, deadlock, state change, subsystem integration, data accessibility, privacy, compliance to regulation, assurance, business goals and strategies, customer experience, maintainability, affordability and disposability.
В CPS PWG Cyber-Physical Systems (CPS) Framework Release 1.0 есть много более развёрнутый и аннотированный список этих concerns, группированый по "аспектам" (Functional, Business, Human, Trustworthness, Timing, Data, Boundaries, Composition, Lifecycle) https://pages.nist.gov/cpspwg/
Я даю это на первом же занятии по системному мышлению, это его краеугольный камень. Это база мышления инженера: что должно интересовать, чем должен быть озабочен (concern!) инженер. обычно это concerns, а уровень снятия той или иной озабоченности ими в инженерных документах известны как quality requirements -- насколько нужно в данном проекте сделать что-то ремонтопригодным, круглосуточно доступным, какая должна быть наработка на отказ и т.д. Всё остальное делается в меру удовлетворения этих интересов, снятия этих озабоченностей, удовлетворения этих требований.

Ну, а дальше или вы сочиняете из головы про все эти -ости (аккуратности, ремонтопригодности и т.д.) и даже игнорируете то, что их много и у них есть общее название concerns и quality requirements (которые для -ilities, ибо для functionality другие requirements -- functional requirements), или становитесь на плечи гигантов и изучаете хотя бы то, что на эту тему есть в литературе и инженерной практике. При этом в советской инженерной школе это народный эпос аксакалов-инженеров, а в западной практике -- учебники системной инженерии. Вот, я по-русски обо всём этом пишу учебники, читаю курсы. И да, нагло утверждаю, что это и есть базовое мышление, где наличие именно "аккуратности" уже вторично, а первично высказывание, что "есть много разных -остей, которые вам нужно отслеживать в ваших проектах, и вам нужно будет познакомиться с требованиями по ним, а также научиться практикам их удовлетворения. Эти -ости отвечают различным стейкхолдерским интересам, а описываются среди требований как требования качества".

Дмитрий Польский обсуждает "на пальцах" вид жизненного цикла и те concerns, которые возникают в ходе разработки. Всё это имеет имена (например, управление конфигурацией -- "всё подписано, всё можно найти и ничего не потеряно, ни о чём не забыли"). Конечно, об этом тома написаны! Но не в России. В России это живёт главным образом в программной инженерии, но в "железное дело" по факту не проникает.

Нужно просто для себя различить два вопроса: чему учить и как учить. Если непонятно, чему учить, то обсуждение вопроса как учить этому бессмысленно. Но если понятно, чему нужно учить, то для разных детей (и даже разных взрослых) можно выбрать разные способы обучения. Можно дальше отдельно думать, как выходить к разного возраста детям в разных инженерных мастерских, и что им при этом говорить, показывать, что заставлять их делать руками, и о чём думать головой.

Но "чему учить" в самых азах я пытался сформулировать по-русски (ибо основные материалы все по-английски и раскиданы по самым разным источникам, прежде всего инженерным стандартам и публичным документам) -- но не для детей, а для взрослых (магистров. Увы, даже не бакалавров). Вот учебник в его второй версии: http://techinvestlab.ru/systems_engineering_thinking/ (есть к нему и более современный вариант последовательности изложения материала, и задачки, и более развёрнутое изложение каких-то вопросов тут: http://system-school.ru/wp-content/uploads/2016/11/system_thinking_11nov2016.pdf). Можно глянуть мастер-класс (но он был больше для программистов) по системному мышлению, самое начало изложения тут: 

Но это всё не народный эпос, не попса, не "на пальцах". Это как физика и высшая математика, не как уроки рукоделия или "образовательной робототехники".

И это "чему учить", это не "как учить" и уж тем более не "как учить маленьких детей". Пока (как я уже писал) простая идея, что "система сама является частью другой системы и состоит из частей, и так на много уровней вниз и вверх", т.е. идея сборки из каких-то модулей, каждый из которых является и функциональной единицей (компонентой) даётся деткам в курсе биологии, как я об этом говорил по приведённой чуть раньше ссылке. В инженерии (хотя она вся про сборку-разборку из частей!) эта мысль трудно даётся, ей специально не учат, а "интуитивно" после этого невозможно понять, как работать с принципиальными схемами самого разного рода, чем отличаются они от сборочных диаграмм, как устроен инженерный процесс в целом, как связаны инженерия и менеджмент и т.д.
 
 
 
Какая советская инженерная школа?
Когда кончились гимназисты, в середине 60х где-то, даже технические книжки превратились в УГ.
Это отсутствие школы (науки, исследований и т.д.) и есть "советская инженерная школа" -- уж какая есть. Народный эпос -- это ж тоже такая "школа"!
Сборник анекдотов, и куски теории - качественная теория ду, асимптотическая механика, теория устойчивости, неравновесная термодинамика - для описания локальных процессов.
Н.Моисеев пытался системность привнести - сгоняли инженеров девятки, меня в том числе - но было поздно...
> Н.Моисеев пытался системность привнести - сгоняли инженеров девятки, меня в том числе - но было поздно... 

Это о чём речь? Если можно.
На закате СССР в поисках асимметричного ответа на туфтовую рейгановскую ПРО решили перестроить деятельность девяти оборонных министерств (а то - три типа танков, ХЗ сколько подлодок, ракет на них...).
А основу подхода формулировал акад.Н.Моисеев из ВЦ АН.
Вот-вот. Ограниченный, кстати, был системный подход. Потому как в объемлющей системе становится понятно, что конкуренция внутри девятки была единственным шансом делать хоть что-то конкурентоспособное на тогдашнем уровне. Без этой конкуренции и "дублирования разработок" вообще бы всё загнило на много шагов раньше.
Да, единственная отрасль...
Но - во сколько ж влетали параллельные семейства танков, самолетов и кораблей-одноклассников...
У янки в поколении - одна ударная, и одна ракетоносная лодка. А у нас...

Сегодня в гараже глазом кошу в ящик - "решили поддержать отечественного производителя, приняли на вооружение и Ми-28, и Ка-52"... А это ж падение серийности, закрытые сельские школы и районные больнички.
Кто это вас так отделал??? (риторический вопрос)
Вдохновляюще. Брожу по ссылкам. Спасибо!
ailev: "Конечно, известен и другой путь. Учат, например, что такое "физическое тело" и понятие траектории. А потом учат тому, какова траектория физического тела. А дальше подумайте сами, как люди приходят к идее, что собаки, гайки, гири и бетонные блоки летят по параболе, если их кинуть с какой-то скоростью. Один вариант -- нужно побольше кидать, и прийти к обобщению (как это когда-то сделали люди, сформулировавшие потом про физическое тело, траекторию и параболу). Второй вариант -- воспользоваться уже готовым знанием и научиться отождествлять все предметы в мире с физическими телами, и когда эти предметы бросают, то сразу понимать, что там будет парабола. Я вот предлагаю сразу учить понятиям целевой системы, требований, архитектуры, жизненного цикла и т.д.. И уметь их видеть в окружающем мире. И этот мир неожиданно будет проще, в разы и разы. Для этого все такие понятия и придуманы."

1. т.е. вы предлагаете идти вторым путем?
2. и т.е. вы предлагаете изучать сразу метаправила?
3. не уверен, что правильно идти сразу через несколько уровней вверх, имхо надо давать несколько типичных примеров текущего уровня и пару контрпримеров, и потом обобщать на метауровень

ps и ваще говоря не обязательно парабола, зависит от скорости, это чисто придирка
Для начала нужно договориться, что метаправила есть и какие они. Вопрос о том, как им учить -- второй вопрос, отвечают на него по-разному в зависимости от того, кого учат (какой там возраст, какой уже есть объём знаний о мире). 

Можно, конечно, пойти по эзотерическому пути и сказать о "тайном знании", которое открывается многоуровнево по мере "посвящения" -- тогда набор метаправил действительно будет зависеть от того, кого учим и как учим, от его "степени посвящения", степени освоения предыдущих ступенек знания.

Но я бы предложил сразу обсуждать системное мышление по гамбургскому счёту: всё, что про инженерный подход известно. А потом предполагать множество вариантов того, как этому мышлению учить маленьких детей, подростков, студентов, взрослых.
> системный подход и системное мышление только в биологии

Биология исходит из фракталов - как из одной клетки при уходе вырастают способные к размножению организмы.

Тот же Кулибинский подход создания само-разворачивающегося само-воспроизводящегося дерева знаний в подходящей среде.

Мое предложение - включение технологического блока при обучении истории, возможность поиграться руками с технологиями разных веков и постепенный выход на новейшую историю с ее экономикой и государственной специализацией.
"Биология исходит из фракталов" 

сорри, фракталы ваще тут не причем
не забывайте, что начинаемся мы с одной клетки, с некоторым набором хромосом, а затем достраиваемся до более полного организма. 
каким будет организм - достаточно хорошо известно по одной клетке, является функцией от неё.
ailev: "первично высказывание, что "есть много разных -остей, которые вам нужно отслеживать в ваших проектах, и вам нужно будет познакомиться с требованиями по ним, а также научиться практикам их удовлетворения. Эти -ости отвечают различным стейкхолдерским интересам, а описываются среди требований как требования качества"."

получается есть перечень свойств системы, которые хотелось бы иметь и есть ограничения, т.е. получается, что это типичная задача многокритериальной оптимизации, правильно?


ps. я не троллю, пытаюсь понять фишку подхода, пытаюсь понять концепцию системного подхода на пальцах
Понимать можно по разному: кто говорит об оптимизации, кто говорит о поиске в пространстве выборов (http://ailev.livejournal.com/1122876.html), кто говорит о синтезе. Но главная фишка сегодняшнего системного подхода не в том, что находится какой-то оптимальный объективный минимум какой-то функции, а что сами критерии задаются кем-то субъективно. Это отличает системный подход современный (второе поколение) от предыдущего, времён заглохшей кибернетики. И это только одно из положений системного подхода, что системы определяются субъективно, что без стейкхолдера и его деятельности, и проистекающих из деятельности интересов никаких систем нет. Одно положение, одна из множества сутей.

Опять же, "на пальцах" одной фразой ни концепцию высшей математики, ни концепцию системного подхода не понять. Все эти свехрупрощения не работают, увы. Нужны примеры, конкретизации, решения задач, тренинг в постановке задач.
1."Понимать можно по разному: кто говорит об оптимизации, кто говорит о поиске в пространстве выборов (http://ailev.livejournal.com/1122876.html), кто говорит о синтезе. "

угу, в некотором смысле оптимизация и поиск одно и тоже, для меня по крайней мере

а вот синтез, тут уже я понимал бы как существенную модификацию модели/задачи/методов решения
аналогия из математики, добавили новые аксиомы или правила вывода к некой теории

ок, я примерно так и понимал

2. "Но главная фишка сегодняшнего системного подхода не в том, что находится какой-то оптимальный объективный минимум какой-то функции, а что сами критерии задаются кем-то субъективно. "

понятно, в принципе для меня это даже довольно очевидно, поскольку занимался оптимизацией
понятно, что субъект (по вашему видимо стейкхолдер) имеет некие потребности и субъективные цели, ну и понятно, что как-то они превращаются в некую шкалу предпочтений, и таким образом объективизируются

вроде примерно понял системный подход
Вы поняли один из маленьких кусочков системного подхода. Ну, типа как нельзя говорить "я понял высшую математику, ибо проникся идеей дифференцирования".
"Вы поняли один из маленьких кусочков системного подхода. "

да, конечно, именно так

" Ну, типа как нельзя говорить "я понял высшую математику, ибо проникся идеей дифференцирования"."

если взять аналогию про математику, то я ребенку-дошкольнику примерно так пояснял про "что такое математика", это специальный язык манипуляции символами по неким строгим правилам
конечно, это не дает даже представления о каких-то разделах математики, но позволяет понимать фишку ))
Вы логицист. "Манипуляция символами по неким строгим правилам" это больше похоже на логику, а не на математику )))
ну дык логика часть математики

а более развернуто я так примерно еще это добавляю ) с расшифровками конечно

Математика это язык описания моделей.
Математика это такой специфический специальный язык. А мат.модель это кусочек текста на языке математики, т.е. мат.модель это описание (на спец.языке) или рецепт, если желаете.
Математика, в широком смысле, не только язык, но и метод. А в узком смысле, только язык.
хм. прочел. смешанные чувства. советская - она изчезла - осталось в основном местечковая. и подход аналогичный.

хотя интересный вопрос Вы подняли, интересно чем он вызван?

О инженерах интересно слушать практических инженеров, а не теоретиков инженерии. Потому что опыт нарабатывается только на ошибках. И не нарабатывается в системах, где ошибки прячутся под слоем бюрократии.
Так, на всякий случай: у меня довольно много общения с практическими инженерами, самыми разными. Например, прямо сейчас я несколько часов в неделю провожу в машиностроительном КБ, так что лично виденных историй из жизни могу привести немало. Но я ещё и с практическими инженерами по линии INCOSE регулярно общаюсь. А они там одной половиной мозга проекты делают, а другой половиной мозга теории об этом разрабатывают -- так уж их воспитали.

Ваш скепсис по поводу окружающей действительности и вреде теорий я, конечно, знаю. И во многом разделяю. Но всё-таки я избирателен по поводу теорий. Я неоднократно видел, как системное мышление вытаскивало совсем провальные проекты, убирало огромные риски, преодолевало суровые (на несколько лет!) отставания от графика.

Так что у меня кроме скепсиса есть и положительные примеры. Многие из них я тут не привожу, ибо не все примеры любят публичность, даже если они и положительные.
преодолевало суровые (на несколько лет!) отставания от графика.

Если вокруг бардак и тупицы, любая менее-более продуманная система даст Огромные Улучшения. 

На интересную информацию людей надо уметь специально раскручивать. Большинство работников умственного труда не понимают, как они думают и почему делают то, что делают.
в этом и фишка системного подхода, имхо, чтобы дать инструкцию "тупицам" с целью уменьшения бардака и организации производства чуть более качественного продукта, с чем по моему мнению, цивилизация и более-менее справляется
и получается, что системный подход это некие метаправила/метаинструкции по изготовлению сложных систем
имхо, пусть меня поправят, если что
Вместо скрытия тупизны за горами бюрократии проще поменять менеджеров на тех, кто сможет нанять правильных людей и задавать реалистичные сроки. (Ну да, не на российские зарплаты.)

Что бывает от Правильных Системных Подходов показал пример Мотороллы.
Вдогонку: Основная проблема консультантов - их зовут туда, где всё плохо. Практически, у всех клиентов я видел "как надо" в других отделах, а не там, где требовались люди со стороны. Мои советы, давшие Огромные Улучшения относились в основном к элементарным вещам, вроде "Может вы всё-таки поставите систему контроля версий?", "Человечество уже задавалось этим вопросом. Вместо завалов вордовских и экселовских файлов лучше использовать какой-нибудь из этих тулов.", "Чтобы проверить Вашу версию не проще ли посчитать статистику ошибок вот по этим данным?".
тут вот системный подход зацепили и вас 
http://dxdy.ru/topic115882.html
О да, там ключевая фраза "убивает много времени, чтобы объяснить простое". Насколько я понимаю, это удел всех занимающихся системным мышлением )))

3499 words