В копилку методического опыта ;)

Интернет, базы данных, языки программирования, операционные системы, системное и сетевое администрирование - этому учат ЗДЕСЬ! Сайт - http://shgpi.edu.ru/f11/
С 9 декабря 2011 года к нашей дружной семье присоединился физмат!

Модераторы: xdsl, ustinova

В копилку методического опыта ;)

Сообщение xdsl 23 сен 2010, 09:22

Не секрет, что на занятиях по программированию самостоятельно пишут действительно сложную программу от силы 20% человек из группы студентов (исключения есть, но они редки как "зависания" linux-серверов). Остальные представляют собой "примазавшихся", использующих готовый программный код или части от него в своей работе, которую затем демонстрируют преподавателю. Соответственно, перед преподавателем возникает несколько проблем:
1) Принимать или не принимать такое решение?
2) Если не принимать, то как обеспечить отчисление 80% группы?
3) Если принимать, то по каким критериям?

Выбор второго пункта достоин истинного героя, ибо только настоящий джедай в состоянии продавить в вузе отчисление или хотя-бы перевод на другую, более простую специальность или факультет четверых из каждой пятерки студентов.
Герои не истинные, а нормальные (которые, как известно "всегда идут в обход"(с)), выбирают обычно третий вариант и вот тут все и начинается. Как проверить понимание студентом сложного, объемного, с многочисленными ветвлениями, циклами и рекурсиями программного кода? Какие вопросы следует задавать и при этом не попадаться на классические студенческие крючки и подначки, которые фактически заставляют преподавателя отвечать на им-же поставленный вопрос? Каким образом формулировать вопросы, чтобы для ответа на него заставить студента не придумывать сферического коня в вакууме, а разбираться в коде?

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

Идея в следующем: после проверки студенческого решения на корректность в произвольное место программы вставляется оператор (функция, процедура и т.п.), выводящая на экран (в файл, на консоль и т.п.) значение какой-нибудь часто изменяющейся переменной. После этого, до запуска программы, студенту предлагается предсказать, сколько раз сработает этот оператор и какие значения появятся на экране. Запуск программы доказывает или опровергает предположения студента. Три подряд верных предположения - решение зачтено. И ВСЕ! Классическое противоборство преподавателя со студентом сведено к противоборству студента со своей программой. Подводный камень только один - от преподавателя требуется от момента формулировки вопроса до момента ответа не спускать со студента глаз. При малейшем подозрении на несанкционированный запуск программы - менять исходные данные.
xdsl
 
Сообщения: 1236
Зарегистрирован: 09 дек 2008, 05:16
Откуда: ВЦ ШГПИ
Полное имя: Слинкин Д.А.

Re: В копилку методического опыта ;)

Сообщение Vladislav_133 25 сен 2010, 21:54

Согласен, оригинальный подход.
Аватара пользователя
Vladislav_133
Elite
 
Сообщения: 1386
Зарегистрирован: 13 дек 2008, 18:08
Полное имя: П.В.Ю.

Re: В копилку методического опыта ;)

Сообщение xdsl 27 сен 2010, 07:59

В продолжение:
1) Студент предсказывает, что отладочный код не сработает ни разу и оказывается прав. В ответ преподаватель предлагает изменить исходные данные таким образом, чтобы код сработал 1, 2 и т.д. раз
2) Студент предсказывает, что отладочный код сработает N раз, выведет значения n1, n2 .. nn и оказывается прав. В ответ преподаватель предлагает изменить исходные данные таким образом, чтобы код сработал N+1 или N-1 раз
xdsl
 
Сообщения: 1236
Зарегистрирован: 09 дек 2008, 05:16
Откуда: ВЦ ШГПИ
Полное имя: Слинкин Д.А.


Вернуться в Факультет информатики, математики и физики

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

cron