Первый семестр CMU MSIT-SE: чему учили, что понравилось

Ура, первый семестр в CMU закончен!

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

Текста получилось много, поэтому вот оглавление. Квадратные скобки означают полученную мною оценку. Максимальная оценка [A+]. [S] означает оценку типа прошел не прошел.

Важно: Я не могу делать утверждений касательно практической полезности того или иного предмета в силу отсутствия реального опыта использования.  Может быть это просто очередная методика из серии “Как стать счастливым” или “Как заработать миллион”, а может просто Software Development слишком молод и потому методики еще не обрели своей значимости. Тем не менее, некоторые курсы мне кажутся более практически-ориентированными, некоторые менее. Таким образом я оставляю за собой право оценивать их субъективно.

Общие размышления [наверх]

Как я уже писал раньше, в этом семестре у меня было четыре основных (core) курса и один электив (elective). (Что такое core курсы? Что такое электив?).  Этот семестр не вызвал особых осложнений: преподаваемый материал не является технически сложным, т.е. не почти бывает такого, что я не понимаю, что вообще происходит. Почти все предметы связаны с техниками и методиками, которые призваны помочь процессу разработки софта на разных его стадиях. Уровень загрузки был такой, что почти каждый день нужно было тратить 3-6 часов на выполнение разных заданий на следующий день. То же по выходным.

Положительные моменты

Вспомните, когда вы последний раз читали книгу по психологии или саморазвитию? Часто бывает ощущение, что автор на протяжении многих лет следит лично за вами и вся книга целиком только о вас и ваших собственных проблемах. Ровно те же эмоции возникали у меня на протяжении семестра: типичные проблемы при написании софта командой программистов, мало изменились за последние 20 лет. Это просто удивительно, когда, читая case-study о проблемах Microsoft при разработки второй версии Office в 1990 году, я понимаю, что видел людей, совершающих те же ошибки, и ошибался сам.

Образование очень хорошо структурировано и формализованно – есть четкая, обкатанная программа, автоматические инструменты контроля и необходимый формализм, но…

Негативные моменты

Системный подход в образовании это хорошо, но и он имеет свои минусы.

Во-первых, непривычная для русского менталитета жесткость в отношении дедлайнов (сроков сдач) которая подкрепляется автоматической системой, куда нужно загружать сделанные задания. Т.е. в 11:55 задание отправить можно, а вот в 12:00 уже нельзя. С одной стороны это прививает дисциплину, с другой стороны раздражает.

Во-вторых, профессор на своем курсе является художником и творцом. Он, похоже, имеет право требовать от студентов чего угодно, преподавать что угодно и как угодно. Я не совсем понимаю, как это работает: кто одобряет курсы или как становятся профессорами. Но если профессор требует, чтобы вы в качестве задания сделали что-то крайне сложное и непонятное, то придется делать…даже если он вам не объяснил как.

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

bezymyanasdfnyi

Models of Software Systems [наверх]

Core (основной) курс, 12 юнитов.

Единственный действительно технический курс в этом семестре. Две лекции в неделю. Каждую неделю сдача письменного задания – всего 15 штук. Три групповых проекта. Контрольная в середине семестре (mid-term), контрольная в конце семестра. Практическая ценность на мой взгляд сомнительная, но мозги размять было приятно. Мне, как физтеху, большая часть вещей давалась легко. По времязатратам – примерно 5 часов на письменное задание и часов 10 на каждый группой проект.

Обзор курса

  • Началось все с логики, формальных доказательств, доказательств теорем.
  • Затем конечные автоматы в разных их проявлениях
  • После чего: Z language,  FSP+LTSA, Alloy, Petri Nets, UML
  • Concurrency, Temporal logic.
  • Три проекта по описанию реального устройства с помощью всего этого зоопарка.

Положительные моменты.

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

Ну и в целом освежил мозги по курсу логики.

Отрицательные моменты.

Существует проблема, связанная с TA (Teaching Assistant). TA – это ассистент профессора. Они занимаются проверкой домашних работ и проведением консультаций. Так вот если мое мнение не совпадает с мнением TA, который это проверял – значит оценка идет вниз и единственный для меня вариант – доказывать свою правоту профессору. Кстати, с другими предметами, подобный казус тоже случается.

Methods: Deciding What to Design [наверх]

Core (основной) курс, 12 юнитов.

По мнению большинства – наиболее полезный для практики курс. Две лекции в неделю. Несколько case-study. Три групповых проекта плюс три критики чужих проектов. По времязатратам сказать сложно: почти все задания были проектами, а в такого рода заданиях времязатраты зависят от участников. Я видел группы, которые сидели на митингах по 5 часов в день.

Обзор курса

Этот курс отвечает на вопрос, а что делать, когда клиент приходит со своим ТЗ. Какие следующие шаги? Начать сразу программировать? А что делать, когда проект большой и в голове сразу все не помещается? Что делать с ТЗ – как его записать, как его уточнять, как лучше общаться с клиентом и прочее.

  • Requirements engineering.
  • Use-case analysis.
  • Designing prototypes
  • Storyboards
  • Goal-diagrams
  • Risks, obstacles

 Положительные моменты

Курс реально очень практический. Совсем недавно на хабре публиковалась статья, которая вызвала довольно много положительных отзывов. В этой статье автор рассказывал о методике описания и исследования проекта с помощью mind map, затем прототипы и прочее. С удивлением понял, что ровно это мне показывали и рассказывали, разве что называлось это иначе, но суть та же.

Проекты здесь были нужны важны и полезны как ничто другое. В начале семестра было предложено 8 тем проектов. Каждый тема была сформулирована в виде текстового описания общим объемом одна страница. Например: приложение для помощи людям, путешествующим в страну без наличия каких-либо знаний о стране. Каждый студент писал три понравившихся идеи и затем всех распределяли в команды по 3-5 человек. На протяжении семестра на проекте тренировались все вышеозначенные методики. К концу семестра по каждой сырой одностраничной идее у каждой команды были получены детальные требования, нарисован прототип, разобраны use-case’ы …Документ, описывающий это разросся до 30 страниц, включая все диаграммы и таблицы. Т.е. проект был детализирован очень и очень подробно – по факту, его в таком виде можно уже отдавать на реализацию.

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

Отрицательные моменты

На мой взгляд курс очень затянут. Основная причина – очень много презентаций. Если быть точнее:  из 29 занятий – 10 ушли на презентации.

У курса отсутствуют критерии оценки: глядя на чью-то goal diagram нельзя сказать хорошая она или плохая. Тем не менее TA оценивали проекты каким-то образом. Некоторые команды просто так получали нижнюю оценку, некоторые получали верхнюю оценку – каждый раз было  неясно в чем разница.

Managing Software Development [наверх]

Core (основной) курс, 12 юнитов.

Две лекции в неделю. 3 групповых case-study, 1 индивидуальный. Много заданий вида: прочитайте вот эту кучу pdf-ок, учебник и теперь ответьте на вопросы. Причем вопросы в духе: как вы считаете, будет ли работать методика, описанная в первом pdf (30 страниц) в ситуации, описанной во втором pdf (20 страниц). Ну и еще несколько индивидуальных заданий. Сколько занимает времени в неделю опять же ответить сложно. Индивидуальные задания иногда могут занимать до 6 часов. Групповые – в зависимости от эффективности митингов.

Курс призван ответить на вопросы вида:

  • а зачем нам вообще нужен какой-то процесс? мы и так код хорошо пишем
  • сколько это времени займет? да откуда я знаю
  • сколько еще будет длиться проект? ну не знаю, думаю за пару месяцев управимся
  • что это такое? это то, что вы заказывали! – но я этого не заказывал!
  • и так далее..

За счет обзора следующих тем:

  • Managing customer expectations
  • Defining and measuring processes
  • Software Development life cycle
  • Requirements management
  • Activity, milestone planning
  • Work breakdown structure
  • Estimation methods
  • Risk management

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

Положительные моменты

Курс раскрывает глаза на то, что мы привыкли разрабатывать софт так же, как это делали наши папы 20 лет назад. Вспомните, когда вы последний следовали принципу “понимаем что будем писать – быстренько соображаем как будем писать – пишем код – как-то тестируем – готово” – это ровно то, что называется Waterfall. Так писали код 20 лет назад. Ну т.е. мне правда было обидно читать case-study и понимать, что 20 лет назад серьезные люди писали код так же, как я бы стал писать код сейчас.

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

Case-study является реально очень неплохим способом изучения предмета. Используются гарвардские кейсы, которые, кстати, еще приходится покупать.

Групповые проекты это отдельная песня: я никогда не предполагал, что когда пять неглупых людей садятся делать вместе одно дело это оказывается настолько сложно. Правильное проведение встреч это искусство. Правильная встреча длится недолго. У правильной встречи есть agenda (т.е. список вопросов, который должен быть обсужден). У правильной встречи должны быть распределены роли, иначе обсуждение уйдет не туда. И так далее и тому подобное. Все вышесказанное это не “менеджерская блажь”, но реальная необходимость.

Отрицательные моменты

И опять – отсутствуют формальные критерии оценки. Кто-то получил высокую оценку, кто-то низкую – почему? – понятия не имею.

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

Communication for Software Engineers[наверх]

Core (основной) курс, 3 юнита.

Одна лекция в неделю. Иногда дают какие-то задания. Времязатраты – те самые 3 часа в неделю в среднем.

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