Практикум

Общее

Практикум предназначен для практического усвоения ряда положений программной инженерии и использует в качестве инструментария продукт 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) не составит существенного труда, но потребует значительной работы. Мы надеемся, что данные методические материалы помогут ее сократить и облегчить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Практикум состоит из пяти занятий. Но это не означает, что это ровно 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.

Тема 1. Знакомство и создание проекта

Целями данного занятия является следующее.

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

Команды получают эти документы и в течение 20-30 минут обсуждают их в рамках команды, готовя вопросы к хозяину продукта. Затем, в течение 20-30 минут хозяин продукта отвечает на подготовленные командами вопросы.

После того, как команды получили представление о разрабатываемом продукте (модельной задаче), им необходимо создать командный проект в MS VSTS и занести всех участников проекта в список пользователей.

Шаг 1. Создание проекта

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

Открыть Visual Studio Team Suite и окно Team Explorer в ней:

Нажать кнопку соединится с сервером

Задать имя и порт сервера в открывшееся диалоге:

После того, как соединение с сервером установлено, запустить процедуру создания проекта, используя соответствующую команду контекстного меню (

В качестве имени проекта необходимо указать

В качестве шаблона процесса разработки выбрать Scrum:

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

После выбора всех настроек, создать проект.

Шаг 2. Настройка прав

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

Шаг 3. Подключение проекта остальными участниками команды

После того, как все получили права на работу с проектом, каждый участник команды должен на своей машине открыть Visual Studio и добавить соединение с этим проектом. Выполняется это аналогично пунктам 1-4 первого шага занятия.

Тема 2. Работа с системой отслеживания ошибок

Основной целью данного занятия является знакомство участников с системой отслеживания элементов работы.

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

Шаг 1. Импорт списка пользовательских историй

Для того, чтобы загрузить пользовательские истории из Excel-файла, полученного командами на прошлом занятии нужно:

Выбрать команды

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

После того, как колонки настроены, скопировать значения из исходного Excel в редактируемый.

Показать колонку с именем Work Item Type и задать для все строчек значение Product backlog item.

Нажать кнопку

Убедится, что при выполнении запроса

Шаг 2. Создание sprint

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

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

Шаг 3. Формирование Sprint backlog

После обсуждения открытых вопросов по 10 наиболее приоритетным пользовательским историям команда должна приступить к планированию текущего sprint и формированию sprint backlog. Для этого ей необходимо рассмотреть список всех пользовательских историй и разбить его на список более мелких задач. При этом для каждой задачи необходимо создать элемент работы типа sprint backlog item и проставить следующие атрибуты:

Выполнить все операции нужно средствами Visual Studio и Team Explorer.

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

Тема 3. Работа с системой контроля версий

Основной целью данного занятия является освоение системы контроля версий Team Foundation Server и её интеграции с системой отслеживания задач. Занятие предполагает выполнение следующих действий.

Шаг 1. Разработка кода

Перед началом работы команде необходимо создать решение ( solution ) средствами Visual Studio, включив опцию Add to Source Control:

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

Затем необходимо внести все данные в систему контроля версий, используя команду Check-in, открывающую диалог:

В этом диалоге необходимо внести комментарии к вносимому коду, а также, на вкладке Work items, связать вносимое изменение с элементами работы:

Шаг 2. Создание ветки кода

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

Открыть Source control explorer:

Выбрать нужный проект и в контекстном меню команду

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

Внести изменения с помощью команды Check-in

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

Шаг 3. Объединение изменений

После того, как в отдельные ветви было внесено некоторое количество изменений, необходимо перенести изменения из отделенной ветви в основную, используя команду Merge:

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

Все конфликты необходимо разрешить, используя команду Resolve и утилиту для объединения результатов.

После разрешения конфликтов все изменения внести в систему контроля версий посредством операции Check-in.

Тема 4. Разработка модульных тестов

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

Шаг 1. Автоматическая генерация тестов

Для ускорения разработки тестов команды могут воспользоваться возможность Visual Studio по автоматической генерации тестов. Для этого необходимо воспользоваться командой Test/New Test и выбрать Unit Test wizard в открывшиеся окне:

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

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

Шаг 2. Наполнение тестов содержимым

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

/// <summary>
///A test for Multiply
///</summary>
[TestMethod()]
public void MultiplyTest()
{
   // TODO: Initialize to an appropriate value
   Calculator target = new Calculator();
   int a = 0; // TODO: Initialize to an appropriate value
   int b = 0; // TODO: Initialize to an appropriate value
   int expected = 0; // TODO: Initialize to an appropriate value
   int actual;
   actual = target.Multiply(a, b);
   Assert.AreEqual(expected, actual);
   Assert.Inconclusive("Verify the correctness of this test
   method.");
}

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

Шаг 3. Запуск тестов

Для того, чтобы исполнить созданные тесты необходимо использовать соответствующую панель инструментов:

После этого результаты выполнения тестов будут видны в окне результатов:

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

Шаг 4. Изменение конфигурации тестов

Для того, чтобы проанализировать качество разработанных тестов, команда должна вычислить тестовое покрытие. Для этого её необходимо:

Открыть файл конфигурации запуска тестов, автоматически добавленный к решению при создании тестов:

На открывшемся диалоге выбрать вкладку

После сохранения конфигурации запустить тесты и активировать опцию

Тема 5. Создание и конфигурация автоматической сборки

На данном этапе команда должна создать в своем проекте процедуру автоматической сборки. При этом должно быть создано несколько процедур:

После создания сборок необходимо настроить параметры непрерывной интеграции:

Шаг 1. Создание простой сборки

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

Для создания простой сборки необходимо обратится к окну Team Explorer, после чего в разделе Builds выбрать команду Build Definitions:

Вызов этой команды приведет к открытию мастера, в котором нужно задать следующие параметры сборки:

Задать имя и описание сборки:

На закладке

На закладке

На закладке

После того, как определение сборки было создано, её необходимо запустить, используя команду Queue new build:

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

Шаг 2. Создание сложной сборки

Создание сложной сборки проходит во многом аналогично созданию сборки простой, за исключением нескольких шагов:

На закладке опций при создании проекта сборки необходимо включить автоматический запуск модульных тестов и анализ кода:

На закладке

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

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

Следующая же собранная сборка будет содержать большое количество предупреждений от анализатора:

Шаг 3. Настройка непрерывной интеграции

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

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

После настройки простой сборки для запуска при внесении изменения необходимо проверить работу системы – внести некоторое изменение и дождаться сообщения о сборке.

Аналогичным образом можно настроить и автоматический запуск сложной сборки каждый день в определенное время.

Тема 6. Настройка шаблона процесса

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

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

Шаг 1. Ретроспектива

На ретроспективе команда в течение 20-30 минут обсуждает то, как прошел данный спринт, выделяя позитивные и негативные моменты, а также предложения по изменениям.

Все комментарии должны быть внесены в соответствующий элемент работы типа Sprint retrospective, а для каждого предложения по улучшению заведены элементы работы типа Sprint backlog item, а для каждого идентифицированного негативного момента, требующего устранения – элемент работы типа Impediment.

Результаты ретроспективы необходимо обсудить с хозяином продукта.

Шаг 2. Изменение элемента работы

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

Открыть тип элемента работы на редактирование с помощью команды меню

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

На закладке

На закладке

На закладке

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