Ну и чем я тут занимаюсь с января? (MSIT-SE второй семестр, основные курсы)

Наконец, начался Spring Break – каникулы в середине семестра длительностью в одну неделю. Последние 2-3 недели были просто адскими – я проводил в [пещере] по 12-16 часов с утра до ночи каждый день, включая выходные. Времени писать посты не было.

В этом семестре у меня 3 основных курса, 2 электива и практикум. Нагрузка получается выше чем в прошлом семестре. 

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

  • Architectures for Software Systems (17-655)
  • Analysis of Software Artifacts (17-654)
  • MSIT Project I – Practicum (17-677)

Как я уже писал, всех студентов заставляют трекать время с помощью toggl.com, поэтому у меня будет шанс для каждого курса сказать, сколько времени он реально у меня занял. C начала семестра (13 января 2014) до начала Spring Break (8 марта 2014) прошло 54 дня, т.е. примерно 7 недель.

Architectures for Software Systems (17-655)

  • Основной (core) курс
  • 12 юнитов
  • времязатраты ~ 12,2 часов в неделю
  • 2 лекции в неделю + recitation раз в неделю
  • Reading Questions задание каждую неделю
  • 4 групповых проекта

На данный момент на этот курс я потратил 94 часа, что соответствует 94/54*7=12,2 часов в неделю. Наиболее интересный среди всех core курсов до сих пор.

Среди материала, покрытого за первую половину семестра:

  • что такое архитектура (а действительно, что вы имеете в виду, когда говорите: “да, у них хорошая, продуманная архитектура”?)
  • как ее описать, чтобы это было понятно кому-нибудь кроме архитектора (помните прикольные картинки, состоящие из квадратиков и стрелочек, в которых невозможно ничего понять?)
  • почему в архитектуре не бывает “хороших решений”, но бывают “менее плохие” (требования почти всегда противоречивы, и приходится выбирать что-то в ущерб чему-то другому)
  • почему слово Usability может означать почти все что угодно (мы хотим, чтобы наша система была Extensible, Maintainable и Secure – проблема в том, что эти слова означают разное для разных людей)
  • какие существуют дизайн паттерны (удивительный факт – все, что мы используем сейчас, было придумано лет 20-30 назад. Читайте книжки, не изобретайте велосипедов.)
  • как узнать, что ваш проект Maintainable? (основное требование заказчика – “Хочу, чтобы систему было легко поддерживать”. Система готова, чем докажете, что ее легко поддерживать?)

Групповые проекты

Отличительная черта этого курса. Каждое задание представляет из себя кусок более-менее работающего кода и задание. Для тех, кто знаком с business-case study заданиями – это тоже самое, только для архитекторов.

Пример

Дано две компании – А и Б. Компания А поглотила компанию Б. У компании А существует своя база данных и 3 приложения для управления их продуктами. У компании Б всего одно приложение и своя база данных.

Вас наняли, чтобы совершить слияние программных продуктов обеих компаний, причем требуется держать в голове три вещи:

  1. переход на новую систему должен занять ноль минут (zero down-time)
  2. новая система чисто визуально должна минимально отличаться от старой, чтобы не смущать пользователей
  3. компания быстро растет и когда-нибудь планирует переходить в веб

Выданный код нарочито сделан ужасным “говнокодом”. Там нет нормализации, там совершенно жуткий стиль кода, много захардкоденных констант и прочее. Само по себе задание не является кодерским, т.е. если “просто писать код”, потому что вам кажется, что “так код будет красивее”, потому что “я так раньше делал” – задание провалится, ибо вымышленному руководству компании А пофигу на код.

Цель: выполнить задание, учитывая ограничения по времени (12 часов на человека в неделю), написать репорт, выделяя и обосновывая сделанные решения.

Analysis of Software Artifacts (17-654)

  • Основной (core) курс
  • 12 юнитов
  • времязатраты ~ 10,7 часов в неделю
  • 2 лекции в неделю + recitation раз в 3 недели
  • 5 больших индивидуальных задания
  • 5 групповых проектов

На данный момент на этот курс я потратил 83 часа, что соответствует 83/54*7=10,7 часов в неделю.

Под software artifact подразумевается любой документ, код или диаграмма, но преимущественно код. Курс повествует о тестировании качества софта, о том, как это качество можно измерить. Среди прочего:

  • что означает “наш продукт качественный” ? (Это довольно забавно, но за последние 30 лет написано уйма литературы, подробно изучающей понятие качества. Если немного об этом задуматься, то даже в отрыве от IT области понятие качества – вопрос неочевидный)
  • как можно по-разному находить баги в софте (разные виды инспекции кода, тестирование white-box, black-box, fuzz, random)
  • как оценить, сколько багов все еще осталось в программе после инспекции кода?
  • почему 100% branch coverage  не гарантирует, что у вас нет багов?
  • в чем разница между statement coverage, branch coverage, path coverage?
  • как протестировать тесты? (mutation testing)
  • if (x <= 10) foo(); Как правильно написать тесты для этого участка кода? Сколько тестов понадобится?

Предположим, ваш код был покрыт тестами на 50% statement coverage. Вы напряглись, и теперь у вас 100% statement coverage, означает ли это, что у вас теперь нет багов? Может быть, это означает, что ваши тесты теперь ловят в два раза больше багов? (Ответ: нет)

MSIT Project I – Practicum (17-677)

  • Основной (core) курс
  • 12 юнитов
  • времязатраты зависят от качества планирования у команды, у нас пока маловато…
  • 1 встреча с ментором в неделю
  • 1 индивидуальная встреча с ментором в неделю
  • все остальное зависит только от команды.

Новинка этого семестра и основная особенность всей программы.

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

Среди проектов этого года:

  • Написание платформы для GiftCards
  • Написание UI для управления роботом COBOT
  • Разработка модуля для OpenStack community
  • Разработка платформы для мониторинга использования научного софта
  • Система распознавания лиц для очередной социальной сети
  • UI для Software Architecture-Based Self-Adaptation (http://rainbow.self-adapt.org/)

Важно понимать

Вся эта MSIT-SE программа не учит программировать. Вообще. =) Совсем не учит.

Основной упор – Software Engineering. Если сравнить разработку софта с постройкой моста, то это сравнение станет более понятным: важно уметь класть кирпичи, но кто-то должен думать о форме, расположении и требуемых свойствах моста.

Проект, в котором я участвую

Уже немного писал про него [тут]. Наш проект называется The Scientific Software Network Map. С технической точки зрения: что-то вроде гугл-аналитикс для научного софта. Нашим заказчиком является профессор Jim Herbsleb – человек выдающийся, про него можно почитать по ссылке выше.

Про проект я напишу подробно в следующий раз. А сейчас – основные требования курса.

Требования курса

По результатам этого и следующего семестра каждая команда должна будет не только сделать проект, но и отчитаться по следующим 7 вопросам. Каждый вопрос покрывает некоторую сферу ответственности. В каждый я включил объясняющие, но не исчерпывающие пункты и копипасту из требований преподавателей к курсу.

1. Project Planning

Teams create strategic plans and tactical plans based on some estimation technique. Strategic plans include realistic milestones. Tactical plans are the short term plans and are correlated and derived from strategic plans.

  • долгосрочный план с жесткими дедлайнами (Что вы должны сделать, к какой дате)
  • краткосрочный план (Что нужно делать в течение недели, чтобы в итоге уложиться в долгосрочный план)
  • оценки времени выполнения (А вдруг проект слишком большой, и вы просто не успеете его сделать?)

2. Project Tracking

Teams track their progress with respect to their plans and regularly monitor their progress and make changes to the plans as necessary. Teams review progress with their mentors and their customers. Teams collect and have available progress measurement metrics.

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

3. Context and Requirements Management

Teams establish communication mechanisms to maintain interaction with their customers and regularly meet with their customers to elicit and manage changes to the requirements. Changes to requirements and impacts to plans are negotiated with the customer.

  • как записать функциональные требования к системе (Use-cases? User-stories? Plain text? )
  • как проверить, что вы действительно правильно поняли клиента? (“Я хочу, чтобы система была расширяемой” – это может означать минимум три разные вещи)
  • как понять, что вы уже собрали все требования
  • насколько детально собирать требования

4. Quality Management

Teams establish quality mechanisms consistent with the needs of their client. Quality mechanisms may include prevention mechanisms as well as detection mechanisms. Teams will collect and have available basic quality metrics.

  • как узнать, что все, что вы производите (документы, договора, код, софт, собранные требования) имеет хорошее качество

5. Configuration Management

Teams will establish policies, processes, and tools for managing the configuration of the project artifacts to include at a minimum: requirements, design, meeting minutes, code, test plans, project plans. Teams will provide an archive of all artifacts each semester.

  • а где вы храните ваши требования, презентацию клиентам, договора и прочее? (на своем опыте убедился, если не потратить время на организацию рабочего пространства, начинается свалка и НИКТО не знает, где что лежит)
  • а вы можете ответить, где находится версия договора номер 1.3, которую отправили клиенту 3 недели назад?

6. Architectural Design

Teams will create architectural designs. Plans will include architecture design activities. The designs will form the basis of detailed design and construction. Teams will evaluate the design for fitness of purpose. Teams will document the design.

  • нарисуйте вашу архитектуру. Ага. Ясно. А это что за квадратик? А эта стрелочка что означает? А вот этот большой красный квадратик? А почему он красный?
  • А почему вы сделали именно такую архитектуру системы? Потому что так привыкли делать? Потому что “так правильно”?

7. Risk Management

Teams will perform basic risk management. Risk management includes: risk identification, assessment of probability, impact, priority, and mitigation strategies. Plans will include risk management activities.

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

Все не так просто

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