Метод проектов для обучения разработчиков ПО

Любой специалист в области разработки программного обеспечения обязан обладать навыками командной работы, понимать суть проекта, знать современные методы организации проектов, однако применяемый сегодня в вузах «бригадный» метод выполнения лабораторных работ неэффективен при освоении принципов работы в команде. Кроме того, нынешний студент не владеет навыками использования средств ведения проекта. Возможно, опыт работы со студентами специальности «Вычислительные машины, комплексы, системы и сети» на приборостроительном факультете Южно-Уральского государственного университета поможет в организации процесса подготовки специалистов, способных эффективно работать в команде.

Образовательный процесс

Классическим вариантом применения метода проектов может быть курсовое проектирование в рамках дисциплины «Технология программирования», имеющее четкие временные рамки (семестр), постановку задачи, а также трудовые ресурсы (некоторое количество студентов). Остается понять, каким образом создать студенту условия, которые существуют в компаниях по разработке ПО. Опишем фазы проекта, отталкиваясь от проектных фаз, применяемых в Rational Unified Process, и посмотрим, как мотивировать студента на качественную работу на всех этапах курсового проектирования, а также как научить его пользоваться системой контроля версий и системой документирования ошибок (так называемый «баг-трекинг», bug tracking).

Фаза Inseption

Главная цель этой фазы – постановка задачи, определение проблемы и выбор возможных вариантов решения. Примером задачи может служить игровая программа «Битва роботов» с элементами обучения алгоритмизации. Главный герой пытается остаться в живых, уничтожая противников, среда – поле, основной ресурс – энергия робота. Управление роботом осуществляется благодаря программируемой стратегии поведения. Для достижения реалистичности задача в рамках курсового проектирования должна ставиться так, чтобы ее решение было неочевидным из ее условия – это должно побудить студента к взаимодействию с «заказчиком», в роли которого выступает преподаватель. Результатом работы студента на этом этапе является документ «концепция проекта», соответствующий аналогичным документам из Rational Unified Process или из Microsoft Solution Framework. На этой фазе студент учится анализировать проблему и выделять главное из множества фактов, получаемых при общении с заказчиком. По окончании фазы студент предоставляет на утверждение документ, который, по сути, является техническим заданием, обязательным для исполнения на последующих этапах.

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

• систему централизованного управления версиями (свободно распространяемая система Subversion), позволяющую хранить различные версии исходного кода, что дает возможность нескольким разработчикам получать совместный доступ к модулям создаваемого продукта;
• систему документирования ошибок (свободно распространяемые системы Trac и Agilo) – Web-приложение, позволяющее описывать ошибки проекта в виде текстовых сообщений, называемых обычно «тикетами» (ticket).

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

Фаза Elaboration

На этой фазе студент должен предоставить проект системы, выполняемой согласно RUP, когда от диаграммы функций системы осуществляется переход к ее модели на языке UML, а затем к проекту системы, в котором отражены ее архитектура, компоненты и классы, которые их образуют. Этот этап очень важен с точки зрения результата выполнения проекта, так как полученные технические решения будут определять качество всего проекта в целом. Именно здесь студент учится анализировать, принимать решения и создавать качественный проект программной системы. К концу фазы студенты обязаны представить документ – «логический дизайн», который содержит модель предметной области, определяющую дальнейшие пути реализации системы. Проверка документа происходит по той же схеме, что и на первой фазе.

Фаза Construction

Это, по мнению студентов, самая интересная фаза в курсовом проектировании – здесь начинается воплощение проекта в программу. Основная задача студентов состоит в том, чтобы за четыре недели итераций реализовать функциональные возможности программного продукта согласно методологии Scrum [1]. В Scrum итерации называются спринтами, и каждая из них длится месяц, однако в условиях учебного процесса наиболее приемлем двухнедельный интервал. После каждой итерации студент предоставляет готовую часть программной системы. Именно на этой фазе возникает задача тестирования и появляется вопрос – кто будет тестировать программный код и отвечать за его качество?

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

Фаза Transition

Последняя фаза заключается в сдаче курсовых и лабораторных работ. При их оценке используется рейтинговая система «демократия и ответственность», основная идея которой в том, что студентам с самого начала известно, как и за что их будут оценивать. Каждый шаг студента, каждый этап курсового проектирования, каждое техническое решение оценивается определенными баллами, сумма которых затем пересчитывается в стандартную оценку, принятую в системе высшего образования РФ. Кроме того, баллы за курсовой проект вносят существенный вклад в оценку на экзамене по дисциплине «Технология программирования». Например, рейтинговая система учитывает в баллах качество постановки задачи (наличие диаграмм бизнес-моделирования для выявления требований, если это применимо к задаче), применение архитектурных типовых решений (многослойные системы, клиент-серверная архитектура и др.), использование библиотек, Direct X или Open GL и т.д. На защите курсового проекта студент указывает, на какие баллы он претендует, после чего доказывает обоснованность этого. Все задания, не достигшие минимально необходимых баллов, отправляются на доработку. Практика применения такой системы показывает объективность оценки представленной работы и повышает мотивацию студента, так как он сам может решать, сколько баллов ему необходимо и какая оценка ему в итоге нужна, а задача преподавателя – проверить обоснованность заявленных студентом баллов.

Платформа для образовательного процесса

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

Недостатком такой организации платформы является то, что включенные в нее свободно распространяемые продукты слабо интегрированы между собой. Это не позволяет решать задачи, связанные с обучением и контролем работы студентов, поэтому на кафедре ЭВМ ЮУрГУ был развернут проект по доработке программной платформы обеспечения образовательного процесса. Данная работа проводится в рамках научно-исследовательского проекта «Применение теории паттернов Гренандера к объектно-ориентированному проектированию программных систем». Основная идея данного исследования состоит в том, что использование паттернов, описываемых для предметных областей, а не для частных решений, как в GoF-паттернах, позволяет более эффективно проектировать программные системы.

Во второй половине XX века математик Ульф Гренандер предложил научному сообществу теорию паттернов, одной из областей применения которой является описание модульных систем [2]. Теория представляет собой математическое обоснование поиска регулярных конфигураций (паттернов) в различных системах. К сожалению, теория паттернов не получила сегодня должной практической реализации, и пока отсутствует опыт ее применения для объектно-ориентированного анализа и проектирования программных систем. Поэтому целью исследования является разработка способов распознавания паттернов предметной области на основе готовых моделей на языке UML или языке описания предметной области [3].

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

По оси X этого пространства располагаются требования пользователя к разрабатываемому приложению, ось Y представляет собой иерархию бизнес-отраслей, для которых могут быть разработаны программные системы, например «технологические процессы металлургии» или «технологические процессы в цветной металлургии». Ось Z – это абстрактные понятия бизнес-процессов и бизнес-сущностей, используемых практически в любых предметных областях. Образуемая поверхность определяет конкретную предметную область, для которой разрабатывается программное обеспечение.

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

Если детализировать функции системы, то в зависимости от выбранного метода разработки (RUP, MSF или Scrum) алгоритм выполнения этих функций будет совершенно различным. Методы разработки располагаются на оси Y, например, в порядке сложности процесса разработки (итерационный, спиральный и т.д.). Ось Z – это набор сущностей и бизнес-процессов, которые используются во многих отраслях, связанных с разработкой конечного продукта (программы или другого изделия) (рис. 4, 5).

Образовательный процесс базируется на наборе Web-сервисов предметной области, построенном на основе описания результатов исследования в области теории паттернов и применения этой теории к предметной области «Разработка программного обеспечения». Взаимодействие сервисов между собой обеспечивается на основе механизма события – одномоментного действия пользователя или системы. Для программирования логики поведения системы при реакции на то или иное событие разрабатывается язык описания предметной области, который позволит, оперируя понятиями, близкими любому разработчику или менеджеру проектов, настраивать систему на требуемую методику разработки программного обеспечения.

***

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

Литература

1. Ken Schwaber. Agile Project Management with Scrum. Microsoft Press, 2004.
2. Гренандер У. Лекции по теории образов. Т. 1. Синтез образов. – Пер. с англ. – М.: Мир, 1979.
3. Цытович П.Л. UML-модель элементов теории паттернов У. Гренандера. Материалы конференции Software Engineering Conference 2009.

Павел Цытович (pavel.tsytovich@item74.ru) – доцент кафедры ЭВМ Южно-Уральского государственного университета (Челябинск).

«Университетский кластер» масштабируется

Учредители программы «Университетский кластер» – РАН, компании «Синтерра» и НР – подписали соглашение о сотрудничестве с компанией Microsoft. Основной целью сотрудничества является повышение уровня использования параллельных и распределенных вычислений в образовательной и научно-исследовательской деятельности российских вузов и подготовка профессиональных ИТ-кадров. Соглашение поможет расширить применение решений Microsoft в научно-исследовательской деятельности, а также станет основой для формирования научного сотрудничества, направленного на развитие облачных технологий в России. Еще одно соглашение подписано с Ассоциацией разработчиков программных продуктов «Отечественный софт», которая планирует предоставить участникам «Университетского кластера» дополнительную экспертизу в различных прикладных областях.

Компьютерные игры могут научить математике

Авторы сайта Mangahigh.com разрабатывают несложные компьютерные игры, в которых детям необходимо применять знания элементарной математики в объеме школьной программы. Совместно с британской организацией Learning and Teaching Scotland авторы провели исследование, в котором приняли участие ученики шотландских школ. В течение 12 недель они играли в представленные на сайте игры. После этого их средние оценки по математике выросли на 13%. Более двух третей учеников заявили по итогам исследования, что желание добиться лучшего результата в играх было для них стимулом к занятиям математикой. Большинство учителей тоже думают, что игровая форма облегчает школьникам изучение математики. Дети активно пытаются решить представленные в игре задачи, и, возможно, если бы это была не игра, а упражнение на бумаге, некоторые из них не смогли бы проявить должную настойчивость и найти верное решение.