Практикум

Общее

Практикум предназначен для практического усвоения ряда положений программной инженерии и использует в качестве инструментария продукт Microsoft Visual Studio Team System, поддерживающий многие практики командной разработки ПО. В рамках практикума предполагается освоение планирования, конфигурационного управления (средства контроля версий и управление сборками), автоматического тестирования и командной работы в рамках формально определенного процесса разработки. Такой выбор обуславливается с, одной стороны, важностью этих практик в реальном промышленном производстве, с другой стороны, возможностями, предоставляемыми продуктом MS VSTS. Ряд важных аспектов – проектирование, разработка требований и т.д. не вошли в данный практикум по причине ограниченности времени – он рассчитывается на один университетский семестр. Мы старались предложить максимально эффективный способ обучения основам программной инженерии в рамках университетского процесса обучения, прекрасно понимая, что полное освоение практик включенных в данный практикум, а также и иных, равно как и продукта MS VSTS, возможно при погружении в реальный индустриальный процесс.

Особо отметим, что нашей задачей является не столько обучение продукту MS VSTS, сколько использование его в качестве основы для практического освоения программной инженерии. В современном производстве без подобных инструментов уже не работают, и в принципе, для обучения годится любой продукт такого класса. Достоинство продукта MS VSTS заключается в его доступности для целей обучения. Компания Microsoft ведет широкую работу по бесплатному распространению своих продуктов в образовательных целях в российских университетах, поэтому и данный продукт не составляет труда получить. Однако для его включения в учебный процесс от преподавателей требуется индустриальный опыт использования среды разработки Microsoft Visual Studio – важной составной части MS VSTS – и существенная поддержка в области администрирования (либо собственный опыт, либо поддержка опытного сетевого администратора). При этих условиях ознакомление с TFS (серверной компонентой VSTS) и рядом удобных клиентских приложений (инструменты пакетов Visual Studio Team Suite и Team Foundation Server Power Tools) не составит существенного труда, но потребует значительной работы. Мы надеемся, что данные методические материалы помогут ее сократить и облегчить.

Требования к техническому оснащению

Занятие по данному курсу должны проводиться в компьютерных классах, удовлетворяющих следующим условиям.

• Все компьютеры должны находиться в домене Active Directory под управлением доменного контроллера версии 2003.
• Все учащиеся должны иметь логин и пароль для входа в этот домен.
• В рамках этого домена должен быть развернут Team Foundation Server 2003 со всеми необходимыми компонентами (Microsoft SQL 2005, Sharepoint Server 3.0, Internet Information Server 6,0^{1При использовании с Windows Server 2008 необходимо использовать IIS 7.0.} ).
• В рамках этого домена должен быть развернут Team Foundation Build и настроен для работы с Team Foundation Server.
• На всех компьютерах класса должна быть установлена Visual Studio Team Suite 2008 и Team Foundation Power Tools^{2http://msdn.microsoft.com/en-us/tfs2008/bb980963.aspx} .
• На сервере TFS должен быть импортирован шаблон процесса разработки Scrum for TFS^{3http://scrumforteamsystem.com/en/default.aspx} .

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

Организация процесса

Занятия предполагается проводить со студентами, разбитыми на группы в 5-6 человек. Общее количество одновременно обучающихся команд может составлять 2-4 в одном классе. Возможен также запуск нескольких параллельных команд в разных классах, по разному расписанию и пр. Более крупные группы нежелательны, поскольку существуют разовые, общие для всей группы действия – создание проекта, изменение параметров процесса и пр. – и они потеряются в более крупной группе.

В качестве методологии процесса разработки ПО мы предлагаем использовать Scrum. Эта методология очень проста и хорошо проецируется на учебные команды. Кроме того, Scrum получил в последнее время значительное распространение в мире и в России. Наконец, имеется и легко доступен Scum-шаблон для MS VSTS.

Теперь о проекциях Scum на наш учебный процесс. Produсt Owner – это преподаватель, в роли Scrum-мастера может выступать один из студентов – самый активный, самый заинтересованный. При этом данная роль может допускать широкие вариации по активностям и ответственностям – от простого слежения за временем и некоторых формальностей (именно Scrum-мастер будет выполнять некоторые общие, единые для всех действия, а остальные будут наблюдать за тем, как он это делает), до некоторых функций project manager. Здесь многое зависит от самих студентов – найдется ли в группе один, которому предмет будет интереснее всех, кто будет самым активным. Часто такие студенты находятся, но иногда и нет. В последнем случае большинство обязанностей Scum-мастера возьмет на себя преподаватель. Ну, и наконец, вся группа учащихся будет являться scrum-командой, работающей над реализацией некоторого проекта в рамках одного sprint. Начальные требования к модельной задаче предоставляются в виде backlog, из которого студенты изготовляют sprint backlog.

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

Модельная задача

Данный практикум проводится на основе некоторой практической задачи, которую scrum-команда учащихся реализует в рамках практикума. Требования к этой задаче следующие.

• Она не должна быть очень трудной и допускать реализацию студентами за 6-8 часов.
• Задача должна быть распределенная, разные ее части, розданные разным участникам, должны быть зависимы друг от друга.
• Задача должна иметь более широкий контекст, чтобы ее можно было выделить из более объемлющего backlog.
• Задача должна хорошо подходить для написания модульных тестов.
• Задача НЕ должна содержать сложного пользовательского интерфейса или других технических сложностей.

В качестве своего варианта мы предлагаем предлагаем реализацию игры "балда" на компьютере. Правила игры можно найти здесь: http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%BB%D0%B4%D0%B0_(%D0%B8%D0%B3%D1%80%D0%B0).

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

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

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

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

• Они должны быть знакомы с курсом "Введение в программную инженерию"
• Они должны владеть практическими навыками работы с языком C# и средой разработки MS Visual Studio

О масштабируемости практикума

Практикум состоит из пяти занятий. Но это не означает, что это ровно 5 встреч преподавателя со студентами. Одно занятие может выполняться на нескольких встречах. Кроме того, в рамках нескольких встреч должна происходить разработка модельной задачи. В зависимости от подготовленности студентов может также потребоваться дополнительная информация, дополнительные детали по тем или иным основам MS VSTS, в частности по модульному тестированию. Этот целесообразно оформлять как отдельную лекцию. В целом мы не старались создать полный guideline оставляя значительную свободу для импровизаций, имея также в виду различную подготовленность и активность студентов и, кстати, преподавателей.

Обзор тем и задач

Тема 1. При изучении первой темы (на первой серии занятий) студенты организуются как Scrum-команда. Они также знакомятся с условиями модельной задачи, настраивают инфраструктуру TFS для будущей разработки (создают командный проект и распределяют права на работу с ним).

Тема 2. На второй серии занятий студенты практикуются в планировании работ на основе методологии Scrum, а также изучают способы использования системы отслеживания задач TFS. Студентам необходимо импортировать список пользовательских историй их файла Excel в TFS, а затем детально спланировать будущий спринт и распределить задачи.

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

Тема 4. На занятиях четвертой серии студенты практикуются в разработки модульных тестов средствами Visual Studio Team Developer. На этих занятиях студенты должны освоить средства автоматической генерации тестов, наполнить сгенерированные тесты содержимым, а также научится изменять конфигурацию запуска модульных тестов и считать тестовое покрытие.

Тема 5. Пятая серия занятий посвящена системе автоматических сборок TFS. На этих занятиях студенты должны создать несколько определений для автоматической сборки (build definitions) в разных случаях – с тестами и без, с анализом кода и без и т.д. Кроме того, студенты должны настроить параметры непрерывной интеграции и рассылки уведомлений.

Тема 6. На заключительной, шестой, серии занятий студенты должны повести ретроспективный анализ выполненного Scrum sprint, выявить потенциальные способы оптимизации, а затем и применить их, используя средства настройки процесса разработки TFS. На этих занятиях студенты должны освоить изменение настроек системы остлеживания задач средствами Team Foundation Server Power Tools.