1

Этап 1

Определение инструментария

31 января—31 января

2

Этап 2

Определение входных и выходных данных

28 февраля—28 февраля

3

Этап 3

Проектирование программной логики

30 апреля—30 апреля

4

Этап 4

Проектирование интерфейса

30 июня—30 июня

5

Этап 5

Отладка

31 августа—31 августа

6

Этап 6

Документирование

30 сентября—30 сентября

7

Этап 7

Внедрение

31 октября—31 октября

1

Этап 1

Определение инструментария

31 января—31 января

2

Этап 2

Определение входных и выходных данных

28 февраля—28 февраля

3

Этап 3

Проектирование программной логики

30 апреля—30 апреля

4

Этап 4

Проектирование интерфейса

30 июня—30 июня

5

Этап 5

Отладка

31 августа—31 августа

6

Этап 6

Документирование

30 сентября—30 сентября

7

Этап 7

Внедрение

31 октября—31 октября

13 декабря 2017 31 октября 2018
Цель просрочена на 2013 дней

Цель заброшена

Автор не отписывался в цели 5 лет 8 месяцев 10 дней

Карьера и работа

Разработка простой тестирующей системы для задач по программированию

Муниципальный этап Всероссийской олимпиады школьников по информатике в Твери в этом году со всей очевидностью показал, что надо менять организацию олимпиады.

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

Во-вторых, Челябинская область использовала проверяющую систему ЮУрГУ, а в Твери на муниципальном этапе проверяющих систем нет и никогда не было. До сих пор задания проверялись вручную - запусками программ-решений на каждом тесте, заданном членом жюри, самим участником. При этом входные данные вводятся с клавиатуры, и только на больших тестах использовались файлы. В одной из задач этого года было 50 тестов, и хорошо для жюри, что её мало кто решал. Некоторые решения удалось проверить автоматически с помощью проверяющей системы ЮУрГУ. Но проверка решений всё же затянулась очень надолго. Если источник задач в следующем году поменяется, то вероятность необходимости проверяющей системы всё равно сохранится. Вывод: проверяющая система нужна.

В-третьих, уровень города и области в олимпиадном программировании крайне низок. Далеко не каждый год удаётся отправить кого-то на заключительный этап. Уже на муниципальном этапе лишь единицы набирают более 50% баллов, не говоря уже о региональном этапе. В этом году удалось повлиять на состав задач школьного этапа, и на нём сделали новые задачи, а не дали, как обычно, прошлогодние муниципальные. Казалось бы, прошлогодние задачи уж все-то должны разобрать и решить - но нет, и они не нашего уровня. Новые задачи оказались проще, что понизило входной порог на муниципальный этап, и на него прошло 65 человек - для Твери это много. Ещё сказалась готовность нашего учреждения принять 35 человек. Технически можно было сделать и больше рабочих мест, но кабинетов больше не дали - обычные уроки во время олимпиады шли по расписанию. Много участников - это неплохо, но общий их уровень остаётся невысоким: программы-решения выводят "пояснения" к входным и выходным данным, выводят ответ не в том формате, используют абсолютные пути файлов, а об ограничениях по времени можно вообще забыть. Потом пишут апелляции оттого, что их ответ "1.7E+4" засчитан как неверный (при верном целочисленном ответе "17003"). Явно не хватает опыта участия в таких соревнованиях. При этом, если в программе-решении не соблюдается регистр символов в строковом ответе (и по условию задачи он несуществен), если программа немного не укладывается в ограничения по времени, если программа не проходит тесты из условия (по нашим задачам это не обязательно для принятия на проверку) - все заинтересованы в том, чтобы такие решения как-то засчитывать. Всё равно на региональном этапе задачи будут одинаковы для всей страны и куда сложнее - "халявы" тут никто не ждёт. Но исключительная и формальная строгость на муниципальном уровне только отпугнут участников в дальнейшем. Не такая у нас конкуренция за победу, чтобы придираться. С остальными муниципалитетами региона ситуация такая же или даже хуже, поэтому их интересы не ущемлены. Вывод: проверяющая система нужна такая, чтобы в ней можно было проверить решения, не полностью соответствующие формальным требованиям.

В-четвёртых, в этом году впервые было введено ограничение на состав языков и сред программирования, допустимых на муниципальном этапе. Раньше было всякое, вплоть до того, что участник первые полчаса олимпиады устанавливал свою среду программирования, которая ему внезапно оказалась позарез нужна. Сейчас в нашем учреждении всё было установлено чётко по списку, и проблем в этой части не было. В другом учреждении, где также проходила эта олимпиада, - были. Однако есть в городе одно учреждение - Суворовское училище - чьи участники могут писать олимпиаду только в одной среде, не входящей в список, - QuickBasic 4.5. Чтобы готовить участников на чём-то более адекватном, нужно это сначала установить на компьютеры самого училища, а это весьма непросто сделать - нужна санкция больших чинов. Вывод: проверяющая система будет использоваться по максимуму и, возможно, должна как-то учитывать и такие случаи, но её использовать в первый год будет вспомогательным. Ещё с этой системой будут работать организаторы и жюри в разных учреждениях, поэтому работа с ней должна быть достаточно простой.

В-пятых, до сих пор решения проверялись после окончания написания олимпиады каждым участником. В принципе возможна ситуация, когда соседи проверяемого участника подсмотрят или подслушают содержимое тестов и соответственно скорректируют свои решения. В нашем учреждении удалось сделать иное - проверять все работы на отдельных компьютерах, файлы передавались по сети. Система пока оффлайновая: проверки - только по окончании тура. Онлайновая система потребовала бы квалификации, которая есть не у всех, т. е. поставила бы участников в не совсем равные условия. Вывод: проверяющая система может быть оффлайновой.

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

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

 Критерий завершения

Разработана система автоматической проверки решений задач

 Личные ресурсы

Время, базовые знания в программировании, в разработке небольших приложений

 Экологичность цели

Спортивное программирование, олимпиады по информатике давно представляют интерес.

  1. Определение инструментария

    Язык и среда программирования, используемые для разработки, а также вспомогательные инструменты.

  2. Определение входных и выходных данных

    Исходные данные некоторого формата - решения, тесты, компиляторы и т. п. Результаты - количество баллов.

  3. Проектирование программной логики

  4. Проектирование интерфейса

  5. Отладка

  6. Документирование

  7. Внедрение

    Начало использования системы для проверки некоторых задач.

  • 1649
  • 13 декабря 2017, 21:04
Регистрация

Регистрация

Уже зарегистрированы?
Быстрая регистрация через соцсети
Вход на сайт

Входите.
Открыто.

Еще не зарегистрированы?
 
Войти через соцсети
Забыли пароль?