Контроль знаний: роботы против студентов
Привет, уважаемый %username%. Я снова решил поделиться с тобой своим небольшим опытом преподавания в IT. В частности, курса СУБД в совместном проекте Mail.Ru Group и МГТУ им. Баумана — Технопарке. Эту статью я хочу посвятить теме контроля знаний. Расскажу о том, как мы меняли и меняем подход к этой задаче, с какими проблемами столкнулись и как планируем их решать. Добро пожаловать под кат.
Начну свой рассказ с того, что было и какие проблемы мы хотели решить: 
Основной системой контроля знаний был экзамен. Это довольно избирательная система: можно вытащить «счастливый» билет, списать или попасть пальцем в небо. При этом остается некоторый человеческий фактор. Это расположенность к вам преподавателя, его настроение и так далее. По сути, очень сложно придумать независимую систему оценки знаний с человеческим лицом. Кроме того, экзамен в Технопарке выпадал на период сессии в Бауманке, и студенты, естественно, расставляли приоритеты не в пользу проекта.
Рубежные контроли (РК). Для того, чтобы несколько улучшить ситуацию с единой точкой контроля, мы добавляли промежуточные. На них мы хотели проверить конкретные знания без оценочных суждений, предлагая студентам задачу, правильный ответ на которую давал бы N баллов. Но, как оказалось, проверить у 30 студентов по 18 задач (итого 540) на составление запросов занимает слишком много времени, а таких РК три.
Семестровый проект. В ходе курса студентам в группах по 3 человека было предложено разработать проект на свой выбор с учетом того, что в нем должна быть высоконагруженная база данных. И снова беда: предъявить достаточно осмысленные и адекватные требования к сферическому проекту в вакууме оказалось очень сложно. В группах сложилось обыкновение делить предметы курса на людей, то есть ты делаешь Java, ты — СУБД, а я — фронт. Тем самым студенты не получали достаточных знаний, концентрируя внимание на 1 предмете.
Оценив имеющуюся ситуацию, мы решили призвать на помощь роботов.
Мы решили автоматизировать все процессы приемки рубежных контролей и семестрового проекта. Для РК мы разработали автоматизированную систему проверки знаний. Студентам предлагалось ответить на 10 вопросов за час времени, в каждом РК было по 3 попытки, а всего их было 3: Написание сложных SQL-запросов
Построение и понимание индексов
NoSQL (MongoDB)
Для проверки знаний по пунктам 1 и 3 довольно быстро было найдено простое и очевидное решение. Студентам предлагается задача, в которой необходимо написать запрос. Результат запроса сравнивается с эталонным результатом, предложенным преподавателем. Тут есть, конечно, некоторые трудности: задачи приходится составлять достаточно подробно с указанием всех атрибутов в конечной выборке, сортировки, лимиты.А вот с контролем индексов у нас возникли проблемы. Придумать хорошую систему с вводом ответов у нас так и не получилось, поэтому мы ограничились тестов с выбором одного из вариантов ответа.
Семестровый проект тоже было решено изменить. Мы решили, что его разработка должна производиться в индивидуальном режиме, и это будет единый проект для всех. В качестве такого проекта мы выбрали API движка комментариев, взяв за пример Disqus. Проект можно разрабатывать на любом языке, не требуется никакого фронтенда и, в общем, ничего лишнего. По сути, прямой интерфейс в БД.
Проект проверялся в два этапа. В середине семестра, когда прошли все лекции по основам SQL, проводилось функциональное тестирование проекта. Все элементы API должны были работать и отдавать правильные ответы. В конце семестра проводилось нагрузочное тестирование. Мы до последнего не говорили студентам, что и как будет тестироваться, предлагая им черный ящик, и идею в стиле «ссылку на ваш проект разместили на главной Mail.Ru». Мы будем имитировать такую нагрузку, но вы ее можете сами попытаться предсказать. Такое решение было нашей ошибкой, но об ошибках поговорим чуть ниже.
Тут стоит упомянуть, как складывалась оценка: РК — 10 задач, правильный ответ на каждую дает 2 балла. Итого за один рубежный контроль можно получить максимум 20 баллов за все три — 60.Функциональное тестирование — 20 баллов, но просрочка сдачи снимала каждую неделю по 2 балла.Нагрузочное тестирование. По результатам тестирования всех проектов был получен график распределения, и согласно ему начислялось 0–10 баллов.И еще 10 баллов можно было добрать на очном общении с преподавателем. На нем мы пытались выяснить, кто сделал проект сам, а кто списал.
Менее 75 баллов — не удовлетворительно.75–84 — удовлетворительно.85 — 94 — хорошо.95 и выше — отлично.
Многие скажут, что шкала очень высокая, но читайте ниже, там будет новая шкала. ;)
Проблема списывания стала основной, с которой мы столкнулись. На РК нам пришлось сделать так, что в конце студенты видят только количество правильных ответов, но не видят, в каких задачах они имеют ошибки. Небольшая ремарка. В конце каждого семестра мы собираемся с руководителями проекта и обсуждаем результаты семестра. В этом году к ним добавились студенты. Да-да, мы обсуждаем качество курса со студентами (вы бы хотели, чтобы преподаватель в вузе выслушал ваше отношение к его курсу?), и это нам дало очень важную и интересную обратную связь.Я думаю, вы уже догадались, что не так в нашей борьбе со списыванием? В погоне за контролем знаний мы потеряли элемент обучения. Наша задача не классифицировать людей на группы по остаточным знаниям, наша задача — обучить. И РК, с возможностью попрактиковаться и увидеть свои ошибки, может дать несколько больше навыков, чем пара часов лекций.
Из этого вытекает проблема «а поговорить?». На нее жаловалось большинство студентов. В новом формате оказалось недостаточно личного общения с преподавателем, с элементами работы над ошибками. Не все студенты достаточно решительны, чтобы подойти после лекции и задать интересующие их вопросы.
Проблема «черного ящика». О ней я уже немного упомянул выше. Нагрузочное тестирование проекта мы проводили в конце семестра. О результатах студенты узнавали уже по факту, не имея возможности все исправить (ну и опять: ничему это не учит по факту, и помочь/поговорить забыли).
В новом семестре мы попытаемся добавить нашим роботам немного души. На рубежных контролях теперь не будет попыток, сдавать можно сколько угодно раз, система будет показывать ошибки и правильные варианты решения, помогая учиться. Но вместе с этим максимум, который можно получить за онлайн сдачу — 5 баллов. Еще 15 будут добираться при очном общении с преподавателем, на котором студентам придется решить одну из онлайн задач в аудитории. А задача преподавателя — выявить, насколько усвоены знания, и помочь студентам найти свои слабые места и зоны роста.В семестровом проекте не будет никаких штрафов за просрочку (слово плохое, да и не работают они). Функциональное тестирование дает 10 баллов. Система нагрузочного тестирования предоставляется заранее, и к проекту предъявляются конкретные требования N rps — 10 баллов, M rps — 8 и так далее. И еще 20 баллов на очной защите.
Итого максимум снова 100, но: Менее 70 баллов — не удовлетворительно.70–84 — удовлетворительно.85–99 — хорошо.100 — отлично.
Отличная оценка — это только 100.
Я преподаю в Технопарке уже два года. На протяжении всего этого времени мы постоянно стараемся улучшить курс, сделать его интереснее и полезнее. Мы проводим встречи со студентами, между преподавателями потока и между преподавателями всех курсов вместе, делимся наблюдениями и опытом. Делаем выводы, меняем программу и подходы к обучению. Мне кажется, это здорово. И я уверен, что мы будем делать это и в будущем. ;)
