В последнее время про низкое качество подготовки студентов в вузах не говорит только ленивый. В том числе и на хабре за последнее время появилось множество статей, которые клеймят позором существующую систему высшего образования, сложившуюся в настоящий момент. Основная претензия, которую предъявляют вузам – это оторванность высшего образования от реальной жизни, от тех технологий, которые используются в бизнесе. Увы, зачастую эти претензии не безосновательны. Но я хочу показать свой личный, позитивный (надеюсь) опыт, как можно преломить эту ситуацию.
В данной статье представлен опыт использования системы версионного контроля 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’ы были сделаны где-то между полуночью и шестью часами утра в ночь перед сдачей были нередки, правда и качество работы, а отсюда и баллы за нее были соответствующими.
Более того, использование SVN позволило проводить групповые лабораторные работы. Считаю, что оптимальный размер группы для большинства работ 2-3 человека, если, конечно групповая разработка не является самоцелью лабораторной работы (такие работы у меня также есть в рамках второй половины того же курса). Групповая работа позволяет, с одной стороны подготовиться к реальной работе, которая, разумеется, будет проходить в коллективах, а с другой стороны, позволяет немного усложнить задачи, за счет того, что задача будет распараллеливаться между участниками группы.
Типичное распределение ролей в такой группе следующее: один студент реализует основную задачу, второй – тесты для нее (формирует тестовые входные данные и эталонные выходные, к которым в конце-концов должна прийти программа). Третий студент, если он есть, может, например, формировать сборочные скрипты, и согласует работу первых двух. SVN позволяет видеть, что именно делал каждый из них, и, соответственно, оценить степень участия каждого студента. Посмотрев, кто какие коммитв делал я могу спросить каждого по его части. Это, разумеется, не является панацеей, но все же небольшой зашитой от «прицепов», то есть студентов, которые не участвовали в реализации задания, но при этом надеются получить оценку «на шару» вместе со своими товарищами по группе.
Следующим шагом в групповой работе является использование Trac. В данном случае, я использовал Trac для общения со студентами, выполняющими курсовой проект. Оговорюсь, что я реализовал пока еще не все, что мне хотелось в рамках данной технологии. Опишу, как это будет в конечно итоге (уже в скоро наступающем семестре).
Выполнение курсового проекта в течение семестра разбивается на ряд этапов:
Это очень хорошо вписывается в идеологию «milestone» на «roadmap». Каждый студент создает себе тикеты по своему проекту. Когда студент счел работу по этапу завершенной, он переводит этот тикет из состояния, например, «формирование ТЗ» в состояние «проверка ТЗ» и прикрепляет созданный документ (если это касается текстовых документов или ссылку на SVN репозиторий где эта задача реализована. Или ссылку на wiki, где этот документ создан.
В состоянии «проверка» я анализирую выполненную работу и при наличии замечаний, возвращаю задачу студенту на доработку. Таким образом, задача может итеративно пройти несколько циклов. После чего, когда все замечания исправлены, я закрываю задачу. Студент заводит себе новую задачу. Milestone позволяют контролировать какие задачи, были во время закрыты, а какие нет, что позволяет с одной стороны изменять их оценку, а с другой стороны в простом и доступном виде показывает и мне и студентам, кто не укладывается в срок.
Если студенты выбрали выполнение курсового проекта группой, то их работа с использованием trac и svn становится очень похожа на реальную работу в компании.
Необходимость включения указанных в данной статье инструментов в учебный процесс, следуя требованиям рынка, было очевидным. Тематика дисциплины предусматривает, в том числе, и технологии разработки программного обеспечения, поэтому данные инструменты смотрелись в этом курсе вполне органично.
Однако использование данных технологий привело к модификации учебного процесса и позволило, с одной стороны сделать работу студентов более прозрачной, а соответственно, и сделало их более дисциплинированными, а с другой стороны позволило сделать более прозрачным формирование оценки студента за сделанную работу.
В данной статье представлен опыт использования системы версионного контроля 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 становится очень похожа на реальную работу в компании.
Заключение
Необходимость включения указанных в данной статье инструментов в учебный процесс, следуя требованиям рынка, было очевидным. Тематика дисциплины предусматривает, в том числе, и технологии разработки программного обеспечения, поэтому данные инструменты смотрелись в этом курсе вполне органично.
Однако использование данных технологий привело к модификации учебного процесса и позволило, с одной стороны сделать работу студентов более прозрачной, а соответственно, и сделало их более дисциплинированными, а с другой стороны позволило сделать более прозрачным формирование оценки студента за сделанную работу.
