Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Об "курс робототехники" и чему в нём учат "проекты"

Опять ввязался в фейсбуке в разговор про то, что такое "курс робототехники" -- https://www.facebook.com/alx.kornilov/posts/1666426850235544 (пост Алексея Корнилова). Там обсуждалась табличка компетенций программиста (их было много таких, типа http://sijinjoseph.com/programmer-competency-matrix/, но год назад была сделана новая инкарнация, на базе европейской классификации уровней владения языками -- http://science.raphael.poss.name/programming-levels.html).

Дальше обсуждение пошло по линии "всё, что нужно программисту, нужно робототехнику", и "ну и как программирование гироскопа в леговском EV3 продвигает движение студента по этим уровням?", "в чём образовательная фишка курса робототехники"?

Тут я и ввязался с парой комментов, которые я сюда вытащу и лишь чуток отредактирую (более обстоятельно этот вопрос я обсуждал в других местах, прежде всего доклад "Непрерывное инженерное образование. Итоги 2014 года и планы", видео и слайды в http://incose-ru.livejournal.com/50538.html. Разъяснение про "практика=дисциплина + технология" дано в учебнике "системноинженерное мышление", http://techinvestlab.ru/systems_engineering_thinking).

Ключевое различение для ответа на вопрос "где тут образование, если студента учат программировани гироскоп в EV3" следует из формулы "практика = дисциплина + технология". "Гироскоп вообще" -- это понятие (учебной) дисциплины, и пока не определили, что это такое и из какого учебного предмета это понятие, и в каком объеме эти сведения про "гироскопы вообще" нужно изучить и мыслительные операции с "гироскопами вообще"нужно освоить, совершенно бессмысленно обсуждать "гироскоп в EV3" и бессмысленно программировать его -- образовательных следствий такое программирование не имеет.

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

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

Чем хороша таблица компетенций программиста, приведённая топикстартером в фейбуке? Она в терминах дисциплины и применима к любой технологии (понятие "код", "функция" и т.д. это из дисциплины software engineering), а вот если бы там была Visual Studio и С++ это было бы про конкретные технологии.

Дальше помянули два потенциальных проекта робототехники:
1. Робот-теннисист (см. мой большой текст с описанием возможных дисциплин курса и видео самого робота в http://ailev.livejournal.com/1159346.html),
2. Робот-гимнаст, я просто привёл его видео (там целый канал с этими видео -- http://www.youtube.com/channel/UCYQDHzSrOA6sFVk7gPjnRWg):



Теперь можно пообсуждать: какие знания нужно загрузить в голову студентов, чтобы их можно было использовать в обоих проектах, использующих абсолютно разную элементную базу -- и гимнаста, и теннисиста (а также, по возможности, и всех остальных робототехнических проектов)? Эти знания и будут необходимые образовательные дисциплины. А то, что в этих проектах что различается -- эти знания будут про технологии (типы моторчиков, варианты 3D принтеров или обрабатывающих центров с их инструкциями эксплуатации, умение держать в руках отвёртку или паяльник или паяльную станцию или программатор конкретной фирмы -- это всё технологии, они на каждом производстве, у каждого предприятия разные. А дисциплина, она должна быть из ВУЗа, одна для всех возможных вариаций технологий, надёжно загружена в голову и натренирована на использование с самыми разными поддерживающими эту дисциплину технологиями).

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

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

Какие знания нужно давать инженерам, кроме специфических дисциплин (ТАУ, электроники, software engineering и т.д.), чтобы они могли справиться с коллективным проектом? Курс системноинженерного мышления (мой учебник, например -- http://techinvestlab.ru/systems_engineering_thinking), курс системноинженерных практик (у меня это второй семестр, во второй версии учебника это скрыто в обзорах литературы по соответствующим практикам) и предметные знания типа тех, что давались в посте для робота-теннисиста (вот они могут быть раскиданы по разным людям). Плюс обязательно системоменеджерские практики, например Lean 2.0 и kanban -- работы ведь нужно как-то планировать и выполнять. Ну, и инфраструктура для всего этого (моделеры, issue tracker). "Инфраструктура" -- это технология, конечно. Ибо опробовать теорию можно только на базе какой-то технологии, не абстрактно.

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

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

Так что я не согласен с постановкой вопроса про обучение инженерным специальностям без преподавания им основ системной инженерии. Ещё я не согласен, что системная инженерия это обязательно профессиональная деятельность (см. также про развал понятия "профессия" в последние годы технологий "полнотекстового поиска" -- пост "об профессии и их атласы", http://ailev.livejournal.com/1209566.html). Есть какой-то набор мыслительных и деятельностных знаний и навыков, а также компетенций (например, личностная компетенция честно прочекивать чеклист до конца, и не скипать пункты. Компетенция думать о системе не только по состоянию на момент её разработки, но и про то, что в какой-то момент система будет изготавливаться, а в какой-то момент ещё и эксплуатироваться -- то есть компетенция удерживать в голове весь жизненный цикл, а не зацикливаться только на своей стадии и своей практике). Это и есть системная инженерия, совсем необязательно это должно стать профессией. Я вот пишу практически каждый день, но профессия у меня отнюдь не "писатель". То же и к системной инженерии относится: компетенции по системной инженерии у инженеров есть, и они используются. Но необязательно эти инженеры именно системные инженеры, как необязательно все пишущие -- писатели.

Если человек умеет работать с требованиями, то он системный инженер по определению -- в тот момент, когда работает с требованиями. Это его функциональная роль "инженер по требованиям", подроль системного инженера, но не факт, что это "профессия" (и не факт даже, что у этого человека вообще есть какая-то "профессия" традиционно понимаемая, опять сошлюсь на http://ailev.livejournal.com/1209566.html).

Скучная была дискуссия, по кругу про одно и то же... Неинтересно было отвечать на вопросы. Скажем, на лекции открытой (которая и была когда-то записана на видео аж в 2012 году, сутки рассказа -- http://video.techpred.ru/lecturer/LevenchukAI/), а также в моём курсе сейчас (который отражён в учебнике http://techinvestlab.ru/systems_engineering_thinking) меня меньше всего заботят студенческие учебные проекты. У моих студентов обычно не учебные, а вполне боевые рабочие проекты, в которых они участвуют (подробней я писал о том, как это получается в межвузовских инженерных школах, тут: http://ailev.livejournal.com/1181065.html). Можно обсуждать, плохо это или хорошо, для образования (есть мнение, что для начала нужно тренироваться на игрушечных проектах, и только потом тебя можно будет пускать в проекты реальные), но это так. И ничего, образование работает и с таким подходом: "требования" те же нужно уметь отличать от "планов испытаний" и для спичечных коробков, и для лазеров, и для софта. Дело-то не в размере проекта и не в типе целевой системы! Дело в том, чтобы в любом проекте понималось, что без требований нельзя, без планов испытаний нельзя, и что существует связь между требованиями и планами испытаний. И испытания проверки и приёмки, и не делать испытания приёмки низззя! Это должно оставаться от учебного курса, в голове должна оставаться дисциплина: не делать испытания приёмки низзя! не писать требования хоть по какой-то методе, просто перечисляя что-то на бумажке -- низзя! Образование должно выдавать на-гора дисциплинированного инженера! Дисциплина должна быть натренирована в паре-тройке конкретных технологических инфраструктурах!

В университете Лафборо для системных инженеров курс системного мышления 150 часов, архитектуры тоже 150 часов, инженерный проект -- 600 часов. Я даю сегодня курс системноинженерного мышления 32 часа + ещё 36 часов для практик (всех скопом -- архитектуры, требований, испытаний, управления конфигурацией и т.д., буквально по нескольку часов на каждую практику). И больше часов не предусмотрено, хотя это и универсальное знание, которое обеспечивает целостность инженерного проекта в части объединения знаний всех других дисциплин. Вот и делайте выводы: почему электронщики и программисты, менеджеры и специалисты по ТАУ не могут сформулировать требования, поделить работу на части и собрать результаты, забывают испытать систему, не имеют слов для обсуждения вида жизненного цикла -- и жизненный цикл остаётся необсуждённым.

Часть студентов после этого краткого курса интересуется и дальше занимаются самостоятельно до освоения на очень приличном уровне. Часть просто пропускают материал мимо ушей (я проверял: материал других преподавателей они точно так же пропускают мимо ушей, это не только моему предмету так везёт). Часть осваивают ровно в объеме этих 32+36 часов, но не факт, что используют эти знания потом в работе. На практике в группе примерно по трети каждой категории. Опять же, вопрос такой же, как к курсу математики: какой объем давать инженеру матана? Особенно в эпоху, когда Mathematica берёт аналитически любой интеграл? Тут вопросов на часы и способ обучения математике не возникает, а в отношении системного подхода почему-то возникает! Хотя меня тут же в дискуссии фейсбуковской поправили, что такой же нервный разговор про матан, как и разговор про системную инженерию.

Но если рассматривать то, чему учить именно робототехников, есть много более насущные и сложные вопросы. Скажем, без глубоких нейронных сеток через год (а то и прямо сейчас) робототехника уже не робототехника будет вообще. Когда глубокие нейронные сетки пришли на соревнования kaggle.com, то все другие виды алгоритмов проиграли. На соревнованиях робототехников будет то же самое, в рыночной кокуренции робототехников (по английски тут будет то же слово, что наши "соревнования" -- competition) будет то же самое -- без нейронных сетей роботы будут проигрывать роботам с нейровнными сетями. Всё будет быстро.

Но с deep learning сегодня засада в части инженерного образования. Инженерия нейронных сетей недоопределена, там куча особенностей по сравнению с программной инженерией. Как учить тому, что даже названия ещё не имеет, непонятно, но не учить нельзя: нейронные сетки и дисциплина, и целый букет уже технологий (поглядите на описание интеллект-стека, для робототехников это весьма и весьма актуально: http://ailev.livejournal.com/1210678.html). Вот такое нужно робототехникам для вставки в учебные программы и учебные проекты срочно обсуждать, а не фигнёй маяться по поводу "как совместить курс ТАУ и знания о существовании системного подхода": проблематизацию вообще понимания науки и инженерии и их связи http://ailev.livejournal.com/1207563.html (и раньше я поднимал этот вопрос странного типа инженерии, который появляется при работе с нейронными сетками в http://ailev.livejournal.com/1205999.html).
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 3 comments