BoatmansHome: ЧемуУчитьИТСпецов ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Внезапно, вскипели нешуточные страсти по теме «чему и как учить студентов ИТ специальностей» — тут.
Началось все со спора, нужно ли заставлять студентов ИТ специальностей доводить курсовик до работающего кода. Здесь я напишу кого, чему и как учить и почему, а про код в конце.


Оглавление

Из какого опыта я делаю свои выводы


Сейчас я расскажу, где я набрался всего того, что ниже напишу:


В итоге, в деле подготовки ИТ специалистов, я побывал и за прилавком, и перед прилавком, и над, и под прилавком, и даже слева, справа и по каждой диагонали от прилавка.
И сейчас я вам расскажу, что там у нас с вами творится.

Основные проблемы ИТ рынка, связанные с высшей школой


Основная проблема отечественных ИТ

  1. В средней массе мы дремучи и неграмотны в той части, в которой надо переставать лишь писать софт и начинать строить из него полезно работающие системы
  2. По процессам разработки самого софта до сих пор идут священные войны остроконечников против тупоконечников
  3. В средней массе мы имеем ужасно высокие амбиции на фоне комплекса самозванца: люди имеют квалификацию (дипломы и сертификаты), опыт в резюме, но в глубине души им кажется, что они ничего не знают и не умеют, точнее знают слишком много бесполезного, а умеют гораздо меньше, чем рассказывают.

Сами ИТ-специалисты думают, что у нас царит благословенная эпоха древнеегипетских жрецов, которые обладают тайными мистическими знаниями, позволяющими повелевать разливами Нила и воздвигать монументальные сооружения. Бюджеты на эти мероприятия и жреческие зарплаты всем нам очень нравятся.


Пользователи и заказчики, в основном придерживаются древнегреческого взгляда, где τέχνη (techne) – это удел рабов и простолюдинов — «компьютерщиков».
При этом пресловутые ИТ можно выбрать в магазине, как унитаз и сразу оплатить доставку и установку, приедет сантехник, смонтирует, и все заработает. А если потечет труба, то можно позвонить, придут какие-то пьяные морды из ЖЭКа и все починят с помощью лома трубного ключа и какой-то матери.


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


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


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

Основные проблемы высшей школы в ИТ


Четыре смертных греха, которые я вижу в высшей ИТ школе:


Проектные роли и предметы труда достаточно плохо разделены в стандартах ИТ специальностей. И еще хуже они разделены в процессе учебы.
Все выпускают одну роль – «ИТ-жреца», который продает один предмет — информационные технологии. Что это такое, из чего состоит, и что делать точно — обычно в голове и в учебе полная каша. Один семестровый курс может спокойно оборзевать (не опечатка :) множество страшных слов (каждое из которых само по себе — предмет отдельной специальности), а, например, «язык UML» изучать вместе с методами раскрутки сайтов.


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


Все стандарты специальности поголовно выпускают программистов (ну и кого-то еще) по тому, что так модно. Программирование понятно абитуриентам, ему легко учить, результат ясен и осязаем, специальность на слуху. Как только кафедра вычеркнет «программист» из специальностей выпускников, на нее резко упадет спрос, а значит, и финансирование.
В итоге грамотных проектировщиков и (эксплуатационщиков) не хватает.


Отсутствие на рынке проектировщиков повышает спрос на программистов. Ведь (мало кому) очевидно, что основная задача любого бизнес-аналитика – закрывать проекты с низкой отдачей. А системный аналитик нужен, чтобы заказчик получил то, что надо ему, а не то, что хотят продать разработчики.


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


В любом из этих случаев студенты получают слишком широко и слишком разрозненно. При этом все, что им рассказывают на учебе достаточно плохо бьется с реальностью.


Что с этим делать, как я это понимаю, написано ниже.
Я буду отталкиваться от трех вещей:

Предмет труда и роли


Давайте для начала наведем порядок в предмете труда ИТ-специалистов, в связанных с ним ролях и заодно разберем параллели с машиностроением.


Мы можем строить и продавать:


С ролями все достаточно просто:


Если наложить на ИТ, выйдет где-то так:


Программист — очень размазанная специальность он может соответствовать:


Но чаще всего в прикладном программировании программист, работающий по спецификации от архитектора — это оператор станка с ЧПУ (3 года техникума) с редкими вкраплениями инженера технолога.


В итоге, когда ВУЗ выпускает ИТ-инженера широкого профиля, он пытается натолкать в него то, на что машиностроителю понадобилось бы 15–25 лет учебы.

Чему учить


Сразу оговорюсь – образование программистов там, где это не касается архитектуры ПО и прикладной математики, меня интересует мало.
Во-первых – это за редкими исключениями, не имеющими отношения к реальному производству, дело техникумов.
Во-вторых, моя задача спустить спеку, гарантирующую заказчику отдачу от вложений, (при этом согласованную разработчиками) и пусть они корячатся, как хотят — по какому сраму (не опечатка :) они будут писать софт, мне вообще все равно, главное, чтобы сдача-приемка началась вовремя и прошла успешно.
В-третьих, при наличии тестовых сценариев и тестировщиков работа программиста проста — «пилить до совпадения с калибром», найдут баги — переделаем. Впрочем, без тестировщиков в большинстве случаев баги ищут сами пользователи.


Так вот, мы говорим о проектировщиках и эксплуатации.


Какие навыки самые главные для любого специалиста?
Основой любого мастерства являются когнитивные навыки.


Там, где
– «блондинка» видит красную машинку, которая фыр-фыр-фыр,
– водитель со стажем — кузов, колеса, руль, коробку передач, двигатель и т.п с внятными сценариями поведения,
– инженер видит несколько десятков тысяч деталей и узлов, соединенных между собой и понимает назначение и процессы взаимодействия каждой с каждой.


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


Второй навык – понимание процессов. Мы видим структуру объекта, понимаем, как устроено взаимодействие и можем путем численных или логических расчетов прогнозировать их течение: заработает ли сразу, и когда (при каких условиях) сломается.


Третий навык – коммуникационный.
Инженер все, что он видит или задумал, может объяснить другим инженерам.
В машиностроении это выглядит примерно так:
http://mognovse.ru/mogno/623/622413/622413_html_6f306cb8.png


Самое главное, что при соединении когнитивного и коммуникационного навыка мы получаем возможность изображать реальность и передавать это изображение коллегам.
Это очень важно – сначала научиться изображать то, что уже есть. И только потом мы будем изображать то, чего нет. Если сделать наоборот, в голове у студентов не будет никакого отклика, никаких реальных примеров на предлагаемые им схемы и чертежи.


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


Те же расчеты дают нам базовые физические параметры – диаметры канатов и болтов, марки сталей, марки подшипников, меж-осевые расстояния, мощности двигателей и т.п.
И после этого мы рисуем сборочные чертежи и деталировки, когда на ключевые параметры машины, оси и покупные узлы надевается мясо.


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


В ИТ схема и базовые расчеты – это концептуальная фаза, чертеж общего вида – это ТЗ на АС/ИС, сборочные чертежи – это технический проект, деталировка – это ТЗ на ПО.


Есть и другие навыки — более узкие и углубленные, но, я думаю, для нашего обсуждения пока достаточно.

Как учить


Так вот, когда и в каких пропорциях учить ИТ-шников.
Я сейчас сделаю слепок со структуры машиностроительного курса с переводом на ИТ.



Все блеяние на тему «мы пока не договорились о нотациях — они очень быстро устаревают» проистекает из того, что кто-то ищет там, где не прятали.
Важно не как рисовать, а что рисовать. Пока нет ясности, какие классы объектов могут вообще быть изображены и как они друг с другом могут быть связаны, ничего нарисовать нельзя, даже если нотация устоялась. И наоборот, как только станет ясно, что бывают сущности 1..N и больше ничего не бывает, становится вообще не важно, в какой нотации рисовать.
В изобразительном навыке очень важна полнота. Нельзя на одном курсе учить рисовать вид сбоку, в следующем году учить рисовать вид сверху, а на третий год учить рисовать разрезы и сечения. Хотя именно так и поступает большинство, изучая разные нотации моделирования отдельно друг от друга.
Еще раз: на курсах по моделированию необходимо концентрироваться на изображаемых сущностях и объектах и их свойствах и лишь потом на том, как это рисовать.


Для будущего обсуждения — вот набросок, что такое виды и разрезы в ИТ:
file:a1.png



Кому интересно, штуцер — это вот:


http://edu.dvgups.ru/metdoc/enf/nachgeom/ing_graf/metod/sokolova/Image17572.gif


Можно видеть, что это лист АЗ, который мы мусолим целый семестр. И я говорю – пусть это ТЗ будет на 2–3 страницы, но оно должно быть написано верно. Убейте в себе гигантомана и научите студентов сначала делать правильно, а только потом уже много. Для этого программа должна быть простой, как палец.





Почему я так против кодирования в курсовиках в ВУЗе — доля проектирования в реальной работе составляет 10–30%. В итоге если требовать работоспособный продукт в каждом проекте, на проектирование времени почти не останется. А рынку очень нужны хорошие проектировщики.



 
Один файл.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]