В последнее время про низкое качество подготовки студентов в вузах не говорит только ленивый. В том числе и на хабре за последнее время появилось множество статей, которые клеймят позором существующую систему высшего образования, сложившуюся в настоящий момент. Основная претензия, которую предъявляют вузам – это оторванность высшего образования от реальной жизни, от тех технологий, которые используются в бизнесе. Увы, зачастую эти претензии не безосновательны. Но я хочу показать свой личный, позитивный (надеюсь) опыт, как можно преломить эту ситуацию.
В данной статье представлен опыт использования системы версионного контроля subversion и системы отслеживания изменений Trac в рамках учебного процесса по дисциплине «Лингвистическое и программное обеспечение САПР» на каф. КСУП ТУСУР. Показаны преимущества, которые получили студенты и я, как преподаватель, от использования этих систем в учебном процессе.
Цели
Цель любого обучения в вузе – подготовка студентов к реальной работе в коммерческой компании. Следовательно, требования к компетенциям выпускника вуза выдвигает рынок. Рынок в сфере ИТ, и особенно в сфере разработки программного обеспечения (ПО) с одной стороны весьма разнообразен, то есть, существует множество технологий и инструментов для разработки ПО, а с другой стороны, все быстро меняется – меняются используемые технологии, подходы к разработке ПО, инструменты, которые используются программистами и т.д. Это касается и технологий сопровождения разработки ПО. Однако, ряд технологий и инструментов используются, если не всеми, то, во всяком случае, значительной частью компаний – разработчиков ПО. В данном случае я имею в виду две нижеследующих технологии.
Систему версионного контроля. На сегодняшний день существует большое количество систем версионного контроля. Даже если взять краткий список наиболее популярных свободных к распространению, систем версионного контроля, то здесь можно будет вспомнить, cvs, git, mercurial, subversion, bazaar. Кроме того, существует немало проприетарных систем версионного контроля, которые обеспечивают лучший или худший функционал, чем указанные выше свободные. В данной статье говорят, что популярность git и subversion практически равны, но у меня лично, полной уверенности в этом нет. Как правило, мне приходится использовать на работе subversion (в последнее время чаще mercurial), а в некоторых, сторонних, в первую очередь свободных проектах — git. В пользу subversion говорили так же некоторые другие причины – в конце концов, он нужен был не только мне, и для студентов был выбран subversion.
Система отслеживания изменений это общее название целого ряда систем, таких системы отслеживания ошибок (bugtracker), системы отслеживания запросов на изменения и т.д. В отличие от систем версионного контроля в данном классе систем нет явных лидеров. Более того, не редки случаи, когда каждая компания – разработчик программного обеспечения разрабатывает свою собственную систему отслеживания ошибок. По этой причине сделать какого-то явного предположения о том, какой именно системой придется пользоваться выпускнику вуза, когда он придет на работу в компанию невозможно. Оставалось только бросить монетку, и в качестве инструмента была выбрана система trac.
Лабораторные работы
Большую часть лабораторных работ дисциплины «Лингвистическое и программное обеспечение САПР» студентам было проще делать на unix, для чего они имеют доступ к кафедральному серверу на FreeBSD. Однако, желающие могли делать это на Windows с использованием Cygwin или даже при помощи VisualStudio или других средств разработки ПО. Фактически, нужен lex, yacc, компилятор C и какая нибудь система автоматизации сборки проекта. Поэтому доступ к svn репозиторию был обеспечен как с кафедрального unix сервера так и с любого, в том числе личного/домашнего компьютера при наличии доступа к Интернет.
Надобно сказать, что у нас на кафедре давно сложилась практика выполнения студентами лабораторных работ дома. В компьютерный класс студенты приходили только для того, чтобы получить задание и затем сдать его на следующем занятии (как правило, через две недели) и попутно получить следующее задание. Выполняли задание они дома, или в том же компьютерном классе, в более удобное время, чем это позволяют рамки аудиторных часов лабораторной работы. Это позволяет оставлять свободное время на работу… ну или на развлечения. (Здесь надо заметить в скобках, что значительная доля сотрудников кафедры включая и меня, днем работают, и только в нерабочее время – вечером после 18:00 и по субботам могут преподавать на кафедре). Многие студенты этим пользовались, и только небольшая кучка регулярно приходила и сидела в компьютерном классе… иногда они даже делали там лабу, но чаще просто сидели в Интернете на халяву.
Централизованное хранилище исходных текстов позволило студентам работать еще более самостоятельно. Фактически, теперь студенты могут приходить в компьютерный класс только для того, чтобы сдавать лабы – задание лежит в trac, а делать они могу дома – только надо залить в svn результат. При этом, отговорки студентов типа «я забыл дома флешку/дискету» пропали — все исходные тексты хранятся в одном месте и доступны отовсюду.
Естественно, что сроки сдачи лабораторных работ были не резиновые. Например, если лабораторная работа по расписанию проводится в субботу, то я назначал контрольный срок выполнения данной работы – 23:59 следующего дня (воскресенье), если работа выполнена не в срок, то снижается максимальный балл, который за нее можно получить. А защита работы проводилась в аудиторные часы следующего занятия — через две недели. Пропали и отговорки студента типа «А я все сделал в тот же день вечером, не снижайте мне баллы», так как по логам svn я точно вижу, что именно и когда студенты коммитили в репозиторий. И если я вижу, что на самом деле работа была сделана в ночь перед сдачей, а не две недели назад, то баллы снижаются. Случаи, когда все основные commit’ы были сделаны где-то между полуночью и шестью часами утра в ночь перед сдачей были нередки, правда и качество работы, а отсюда и баллы за нее были соответствующими.
Collaboration
Более того, использование SVN позволило проводить групповые лабораторные работы. Считаю, что оптимальный размер группы для большинства работ 2-3 человека, если, конечно групповая разработка не является самоцелью лабораторной работы (такие работы у меня также есть в рамках второй половины того же курса). Групповая работа позволяет, с одной стороны подготовиться к реальной работе, которая, разумеется, будет проходить в коллективах, а с другой стороны, позволяет немного усложнить задачи, за счет того, что задача будет распараллеливаться между участниками группы.
Типичное распределение ролей в такой группе следующее: один студент реализует основную задачу, второй – тесты для нее (формирует тестовые входные данные и эталонные выходные, к которым в конце-концов должна прийти программа). Третий студент, если он есть, может, например, формировать сборочные скрипты, и согласует работу первых двух. SVN позволяет видеть, что именно делал каждый из них, и, соответственно, оценить степень участия каждого студента. Посмотрев, кто какие коммитв делал я могу спросить каждого по его части. Это, разумеется, не является панацеей, но все же небольшой зашитой от «прицепов», то есть студентов, которые не участвовали в реализации задания, но при этом надеются получить оценку «на шару» вместе со своими товарищами по группе.
Следующим шагом в групповой работе является использование Trac. В данном случае, я использовал Trac для общения со студентами, выполняющими курсовой проект. Оговорюсь, что я реализовал пока еще не все, что мне хотелось в рамках данной технологии. Опишу, как это будет в конечно итоге (уже в скоро наступающем семестре).
Выполнение курсового проекта в течение семестра разбивается на ряд этапов:
- формирование ТЗ;
- формирование проекта системы;
- реализация;
- защита.
Это очень хорошо вписывается в идеологию «milestone» на «roadmap». Каждый студент создает себе тикеты по своему проекту. Когда студент счел работу по этапу завершенной, он переводит этот тикет из состояния, например, «формирование ТЗ» в состояние «проверка ТЗ» и прикрепляет созданный документ (если это касается текстовых документов или ссылку на SVN репозиторий где эта задача реализована. Или ссылку на wiki, где этот документ создан.
В состоянии «проверка» я анализирую выполненную работу и при наличии замечаний, возвращаю задачу студенту на доработку. Таким образом, задача может итеративно пройти несколько циклов. После чего, когда все замечания исправлены, я закрываю задачу. Студент заводит себе новую задачу. Milestone позволяют контролировать какие задачи, были во время закрыты, а какие нет, что позволяет с одной стороны изменять их оценку, а с другой стороны в простом и доступном виде показывает и мне и студентам, кто не укладывается в срок.
Если студенты выбрали выполнение курсового проекта группой, то их работа с использованием trac и svn становится очень похожа на реальную работу в компании.
Заключение
Необходимость включения указанных в данной статье инструментов в учебный процесс, следуя требованиям рынка, было очевидным. Тематика дисциплины предусматривает, в том числе, и технологии разработки программного обеспечения, поэтому данные инструменты смотрелись в этом курсе вполне органично.
Однако использование данных технологий привело к модификации учебного процесса и позволило, с одной стороны сделать работу студентов более прозрачной, а соответственно, и сделало их более дисциплинированными, а с другой стороны позволило сделать более прозрачным формирование оценки студента за сделанную работу.
Автор: risik
