Ставим оценку

Ставим оценку
Вопрос выведения оценки, наверное, является одним из самых сложных и
противоречивых в педагогике. В самом деле, задать вопрос легко, а вот определить,
правильно ли ответил учащийся, насколько правильно он ответил, правильно ли он мыслил,
несмотря на неправильный ответ - это задача, которая полностью далеко не решена.
Соответственно, и компьютерный аналог выведения оценки страдает теми же недостатками,
если не большими.
В большинстве систем программированного контроля принцип выведения результата
прост. Так как в таких системах, как правило, используется только одинарная выборка, то и
оценка вычисляется просто: ответил - плюс, не ответил - минус. Затем количество плюсов и
минусов приводится к пятибалльной шкале и выводится оценка.
Подобный принцип вывода оценки, хотя и является примитивным, однако в случае,
когда все вопросы в базе данных равнозначны и однотипны, он тоже имеет право на
существование. Однако прямое приведение количества положительных и отрицательных
ответов к пятибалльной системе заслуживает серьезной критики. Общепризнанно, что
зачетный порог коэффициента усвоения равен 70%. В рассматриваемом же случае для
получения зачетной оценки (т.е. "удовлетворительно") достаточно ответить правильно на
51% вопросов, для получения оценки "хорошо" - на 71%, для получения оценки "отлично" на 91%.
Однако вышеописанной практики, как правило, не происходит, так как всем
разработчикам тестирующих систем очевидна неравнозначность вопросов в базе данных.
Вот тут-то и происходит абсолютно недопустимая с точки зрения и педагогики, и
формальной логики процедура - разработчики дают возможность преподавателю
определять "вес", т.е. относительную значимость каждого вопроса. Эта, казалось бы,
невинная с виду идея способна похоронить самые перспективные разработки.
Дело в том, что с точки зрения педагогической теории не бывает вопросов простых и
сложных. Простым вопрос всегда будет для того, кто знает на него ответ. И сложным - для
того, кто ответ не знает. Таким образом, расставляя "веса" вопросов, преподаватель
фактически расставляет их в соответствии с собственными представлениями о их сложности,
в соответствии со своим уровнем компетентности или некомпетентности, т.е. занимается
чистой воды волюнтаризмом.
Тем не менее, существуют вопросы, требующие большего или меньшего времени на
ответ. Логично было бы предположить, что на каждый вопрос, с точки зрения
психофизиологии, может быть затрачено большее или меньшее число мыслительных (т.н.
существенных) операций. Определение этого количества, как правило, не составляет особого
труда, в простых типах вопросов равно количеству предложенных вариантов ответов, и
полностью поддается автоматизации.
Таким образом, на настоящий момент существует два способа определения результата
ответа - по правильным или неправильным ответам в целом на вопрос и по существенным
операциям. При выборе принципа оценки следует предполагать, что оценка по существенным
операциям гибче и объективнее, так как она позволяет выявлять неполные, не совсем верные,
частично ошибочные и другие подобные ответы и вычислять их в конкретных цифрах
коэффициента усвоения.
Гибкость использования способа оценивания по существенным операциям кроется в
возможности ввода так называемой "мягкой оценки". В системе оценивания по ответам в
целом всегда используется "жесткая оценка" - т.е. если учащийся допустил ошибку, не
засчитывается весь вопрос. Однако такой метод оценивания оправдан далеко не для всех
вопросов. К примеру, в большой части вопросов, имеющих несколько вариантов правильных
ответов (подразумевается выборочный тип вопроса), не является обязательным отметка
полностью всех правильных ответов. В таких вопросах вполне допустим или частично
правильный ответ, или, наоборот, отсутствие неправильного ответа. Использование
принципа оценивания по существенным операциям позволяет в подобных вопросах
определять коэффициент правильности ответа и засчитывать частично правильные ответы.
С другой стороны, существует целый пласт молодых программистов разного уровня
квалификации (но, как правило, высочайшей степени самоуверенности), которые свято верят
и в свои силы, и в то, что запрограммировать можно все, что угодно. Они с энтузиазмом
берутся за любую задачу, быстро разочаровываются в способности специалиста объяснить
им суть задачи, разрабатывают кое-как работающую программу (безусловно, тут и там
разукрашенную прыгающими окнами, копирайтами, паролями и прочими проявлениями
неудовлетворенного программистского самовыражения) и переходят к какому-либо другому
интересному делу.
Существует и еще одна категория разработчиков контролирующих систем. Это инженерыпрограммисты, решившие, что они хорошо разбираются в вопросах педагогики. Не будем
здесь обсуждать прописную истину о том, что подобная уверенность чревата серьезными
педагогическими ошибками - понятно и без объяснений, что подобные разработчики
способны создать прекрасный программный комплекс, но его педагогическая ценность
почти наверняка будет близка к нулю.
Контролирующие системы должны разрабатываться в тесном симбиозе
профессиональных программистов и педагогов-теоретиков, а информационное наполнение
таких систем должен осуществлять эксперт-практик.