Неполные и неточные задачи в обучении информатике (Николай Непейвода, OSEDUCONF-2025)

Ссылки сюда (1) →

Короткая ссылка: 20250208H

Докладчик

Николай Непейвода

В реальности программист и информатик будет почти всегда (кроме работы в нескольких уникальных фирмах) получать в лучшем случае неполное, а часто ошибочное, «техническое задание». Худший случай, когда оно имеет при этом внешнюю форму полного и точного и оформлено по всем ГОСТам.

В практике обучения в УдГУ и на ФИТ НГУ применялись неточные и неверные постановки задач, чтобы отрабатывать навыки критического отношения к формулировкам и их уточнения формальными и неформальными методами. Это было применено также в олимпиадах (Всероссийской и Удмуртской). Поскольку это практиковалось достаточно длительное время, был накоплен некоторый опыт. Его систематическое изложение требует большой статьи, поэтому в тезисах ограничимся кратким анонсом.

Презентация

Thesis

При уточнении учебных задач поощрялись коллективные обсуждения студентов, но затем организовывалась соревновательная ситуация, когда разные варианты уточнения решали отдельные люди.

На олимпиадах задачи имели либо принципиально неформальную постановку (например, в 90-х годах обработка безграмотных отчётов об операциях работников шарашки, при условии невозможности дисциплинировать их на единую форму, а посаженная на обработку девочка просто исправляла орфографию и набивала текст в почти произвольной форме, сохраняя лишь ключевые поля, типа кто (не соблюдая официальных имён, например, Сергей Иванов мог быть и Серёгой, и Серым), кому, что, за сколько (тоже название валюты могло иногда быть сленговым) загнал либо купил. При этом соревнующийся заодно сам писал аналогичные тест для других, и выше всего оценивался тест, который сумела пройти примерно половина участников.

Также практиковались двухтактные задачи, когда в первый день участники получали почти точную формулировку, затем она прогонялась на тестах и каждый мог по результатам тестов её доработать. А на следующий день участники получали на вид чуть изменённую и уточнённую задачу и чужую программу, которую должен был переработать, причём оценивалась заодно близость текста переработанной и исходной программы. Этот пункт заранее никогда не объявлялся.

Также практиковались «игровые» задачи, когда несколько модулей участников соревновались между собой под управлением общей программы. Здесь интерфейс модулей задавался всегда строго и полно. Зато правила игры часто были чуть неполны. И после анализа результатов первого тура давалась возможность доработать свои модули для второго тура, но неполноту правил должны были восполнить каждый из участников, проанализировав логи всех соревнований первого тура.

Главная трудность таких задач — большая сложность проверки и невозможность обеспечить формальную объективность. И очевидно, что проверка требует полной открытости и часто хорошей комментированности кода программ участников.

640px