Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

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

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

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

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

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

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

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

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

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

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

"Аккуратность" -- это тоже -ость ;-) В английском эти слова обычно на -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). Можно глянуть мастер-класс (но он был больше для программистов) по системному мышлению, самое начало изложения тут: https://vimeo.com/195093952

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

И это "чему учить", это не "как учить" и уж тем более не "как учить маленьких детей". Пока (как я уже писал) простая идея, что "система сама является частью другой системы и состоит из частей, и так на много уровней вниз и вверх", т.е. идея сборки из каких-то модулей, каждый из которых является и функциональной единицей (компонентой) даётся деткам в курсе биологии, как я об этом говорил по приведённой чуть раньше ссылке. В инженерии (хотя она вся про сборку-разборку из частей!) эта мысль трудно даётся, ей специально не учат, а "интуитивно" после этого невозможно понять, как работать с принципиальными схемами самого разного рода, чем отличаются они от сборочных диаграмм, как устроен инженерный процесс в целом, как связаны инженерия и менеджмент и т.д.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 34 comments