Державна підсумкова атестація в школах - не всі як у ЄДІ

  1. Як ми робили станцію друку
Ми вже розповідали нашим читачам про те, як рішення ABBYY TestReader допомогло ЄДІ встати на ноги. Кілька років тому нам здалося досить логічним (а спочатку навіть простим) використовуючи отриманий досвід, обробляти і результати Державної підсумкової атестації 9-х класів (ДПА 9 класів).
Нагадаємо, що ДПА -

загальна назва для всіх державних (підсумкових) атестацій і проводиться вони в 4, 9 та 11 класах. Після довгих пошуків ДПА-11 став проводитися централізовано по всіх регіонах РФ, за що і отримав своє горде і окрему назву «єдиного іспиту». Це «однаковість» ще не встигло толком торкнутися ДПА-4, а ось дев'ятикласники вже кілька років беруть участь в експерименті з впровадження автоматизованих технологій проведення масових іспитів (замість традиційної письмової форми проведення іспиту).


Отже, що ми мали в далекому 2008 році? Налагоджену і в цілому надійно функціонує машину обробки результатів ЄДІ, яка працює на базі програмного комплексу введення бланків ABBYY TestReader Network.
Чого ми хотіли? Застосувати наші технології повторно на ДПА-9 і стати ще більш інвестиційно привабливими.
Здавалося б, чого простіше? Але, вже ступивши на цей шлях, ми виявили кілька відмінностей між іспитами, і це докорінно визначило подальший розвиток подій.

Справа в тому, що ЄДІ проводиться централізовано Міністерства освіти та науки і Рособрнадзора за єдиним сценарієм, бланки з відповідями обробляються теж однаково. Витрати при цьому діляться між федеральними та регіональними органами влади так: центр дає технологію і сервіси, а регіони, власне, організовують іспит. Проведення ДПА-9 цілком віддано в регіони, а значить, лягає на їх бюджет і проводиться так, як вирішить керівництво регіону. Об'єднує ДПА в Росії тільки те, що іспити проходять за єдиним розкладом і за однаковими завданнями.
Як ви здогадуєтеся, регіони Росії сильно відрізняються за обсягами доступного фінансування і деякі, ясно, намагаються економити. Внаслідок цього спостерігається «Кусково» автоматизація: хтось все ще кипить проводить іспит по-старому: учні пишуть від руки, а екзаменатори «від руки» перевіряють. Ті ж регіони, які на свій страх і ризик самостійно намагаються перевести іспит в тестову форму, стикаються з безліччю проблем. Однією з них є необхідність у великому обсязі друк бланки і завдання (офіційно вони називаються КІМ - контрольно-вимірювальний матеріал) для учнів. Якщо для ЄДІ бланки замовляються централізовано за рахунок федерального бюджету, то в рамках ДПА цим займаються регіональні влади.
У кращому випадку - кожен суб'єкт замовляє друк в друкарні, в гіршому - друкує бланки на звичайному принтері, копірі, а може навіть на різографі .
Оскільки для кожного регіону в першу чергу розглядалася можливість заощадити і зробити все простіше, пропонувати кольорові бланки для ДПА було безглуздо. Тому ми запропонували чорно-білі бланки, які легко тиражуються на різних пристроях.
Що ще змінилося в бланках в порівнянні з ЄДІ Крім того, з метою оптимізації витрат на папір в ДПА бланк реєстрації учасників та бланк відповідей №1 суміщені, тобто комплект складається тільки з бланка №1 (ПІБ, відповіді А і В), бланка №2 (відповіді в розгорнутій формі на частину С) і, власне, завдань.
Але на цьому заморочки не закінчилися. Ми виявили, що завдання для ДПА з різних предметів не завжди піддаються поділу на прийняті в ЄДІ частини A, B, і C (нагадаємо, що відповіді на кшталт А - це вибір із запропонованих 3-4 варіантів, тип В - відповідь у вигляді слова або набору цифр, а відповідь типу С - повноцінна письмова робота). Отже, було неможливо створити структуру бланка, яка підходить для всіх іспитів разом. Автори екзаменаційних завдань не йшли ні на які поступки, і нам довелося створювати для кожного предмета індивідуальний бланк. Ось, наприклад, бланки з математики та суспільствознавства


А тепер давайте уявимо, що ми - суб'єкт РФ. Нам потрібно забезпечити бланками до десяти тисяч школярів, кожен з яких здає обов'язкові іспити з російської мови та математики та інші предмети. Кожному учневі потрібен комплект з двох бланків відповідей та одного бланка із завданнями по кожному іспиту. Разом, нам треба роздрукувати ... порахуйте, якщо вам цікаво. Коли будете вважати, не забувайте, що ці учні навчаються в різних школах, які в свою чергу знаходяться в різних містах, селах і ... островах. Тому, коли надрукуєте, доведеться розібратися, в яку школу скільки бланків з російської, математики та інших предметів везти. А якщо в селищі «Тмутаракань» знайдеться нещасний, який раптом захоче здати літературу, то непогано б і його забезпечити відповідним комплектом. А, ну і не забудьте про запас для перехвилювався учнів, які зіпсували ненароком бланк. Ну що, порахували? Ось і ми плюнули на це пропаща справа.
Замість цього ми вирішили додати до нашого TestReader спеціальну станцію друку, яка подумає вважатиме і роздрукує за нас. Вона повинна була стати новим компонентом програмного комплексу по введенню бланків, призначеним для масової швидкісного друку машиночитаних бланків, а також бланків із завданнями.
Як ми робили станцію друку

Ця система повинна була:
  1. Бути досить простий, щоб оператори в регіонах могли розібратися з нею.
  2. Бути надійним - інакше зірветься іспит.
  3. Вміти швидко друкувати екзаменаційні матеріали на лазерних принтерах
  4. Забезпечити матеріалами все ППЕ (пункти проведення іспиту) в необхідному обсязі
  5. Мінімізувати витрати на друк
  6. Зберегти інформаційну безпеку
  7. Друкувати доведеться в самому повільному графічному режимі, щоб не порушити форматування бланків.

На підготовчому етапі ми багато спілкувалися: з фахівцями з Федерального центру тестування, з людьми в регіонах, які забезпечують проведення іспитів. В якийсь момент нам здалося, що ми втомили усіх розмовами :). Але як інакше знайти варіант, який підійде всім регіонам? Ми придумували різні ідеї, потім шукали в них недоліки і придумували нові ідеї. В процесі з'являлися ось такі "карти пам'яті" .

У певний момент у нас з'явилося розуміння, які функції повинні бути у станції друку, і ми приступили до проектування. За планом 90% функціональності мало ставитися до планування і збору комплектів і тільки 10% займати безпосередньо автоматична друк.
Уже на цьому етапі ми зрозуміли, що розробку доведеться замовляти аутсорсерам. Іспити повинні бути проведені в строго визначені терміни, а ресурсів у наших розробників не вистачало - адже рівно в ці ж терміни нам треба підготувати модернізоване ПО для ЄДІ. Доручити писати код ми хотіли давньому партнерові ABBYY - новосибірської компанії ATAPY . Приступаючи до взаємодії з аутсорсерами, ми брали до уваги наступне:
  1. Вони не розбираються в предметній області (в держіспитах тобто).
  2. Ми вже знали, що вони вміють писати відповідний код, оскільки вже неодноразово співпрацювали з ними.
  3. Вони знаходяться в Новосибірську, тому є різниця в часі.

Щоб аутсорсери краще справлялися з нашим замовленням, ми:
  1. Зробили максимально докладний ТЗ, куди включили готові алгоритми програми. Фактично від аутсорсера нам були потрібні програмісти, а саме кодери, які зроблять все точно так, як нам було потрібно.
  2. Самі повністю намалювали абсолютно всі вікна і діалоги програми і описали всі дії, які повинні відбуватися при натисканні на кожну з «кнопок».
    Так, наприклад, мало б виглядати головне вікно:

  3. Зробили спільну з аутсорсерами базу рекламацій. Треба сказати, на перших порах це викликало невдоволення і наших програмістів (невелику частину розробки ми все ж залишили собі), і новосибірських колег. Однак ми наполягли на своєму і згодом переконалися, що мали рацію.
    Коли ми працювали над цим проектом (нагадаємо, це було кілька років тому), ще не були так широко поширені хмарні рішення в цій сфері, тому використовували свою внутрішню розробку - клон бази, якою користуємося в ABBYY.
  4. Залишили за собою і розробили самотужки модулі, які повинні були відповідати за взаємодію станції друку з «навколишнім середовищем» - великими зовнішніми системами (базами даних і т.п.). Ці модулі отримали назву «адаптерів». Тим самим ми постаралися максимально захистити аутсорсеров від взаємодії з суміжними системами.
    У підсумку наші партнери все зробили добре, і ми залишилися задоволені результатом.

Після того як станція друку була готова, вона була протестована, а потім написані технічні документи до неї: експлуатаційна документація (які функції є в програмі) і відповідне інструктівка.
Ви хочете технічних подробиць?

Їх є у нас.
Мова розробки - C #. Базою даних системи є MS SQL Server 2000/2008 (оскільки він же використовується в ЄДІ). Платформа - Microsoft .NET 2.0. Для станції друку був придбаний зовнішній візуальний компонент TreeList виробництва компанії DevExpress. Все працює на платформі Windows XP, 2000. Встановлено криптозащита від компанії Аладдін.
Продуктивність станції друку на недорогих комп'ютерах того часу з процесорами рівня Pentium 4, Celeron (а саме вони були встановлені в 2008 році у більшості користувачів нашого рішення) - до 15-20 сторінок в хвилину (в графічному режимі!). Це максимальна швидкість: якщо принтер старий і повільний, буде звичайно менше.
Як це виглядає з точки зору користувача

Суб'єкт РФ, який проводить ДПА, завантажує в систему всі необхідні дані по учнях: для цього він використовує існуючі бази даних по кожному із суб'єктів РФ зі списками шкіл. Система бачить, в якому населеному пункті, місті і районі знаходиться школа і яка кількість учнів (в даному випадку дев'ятикласників) в ній навчається. А якщо таких даних немає, то доведеться ці дані ввести: задати за замовчуванням, екстраполювати дані про 11-класників, вносити вручну або будь-яким іншим способом. Так ми визначаємося з кількістю дев'ятикласників. Потім вносимо похибки, резерви, запаси і т.п. - завершуємо етап планування - вибираємо спосіб друку - Пуск! Ех, і раді б, та з печаткою теж не все так просто.
Регіону надана можливість вибрати спосіб друку з наступних основних варіантів:
  1. Друкуємо весь комплект в друкарні (бланки відповідей і завдання)
  2. Друкуємо в друкарні тільки бланки відповідей, а завдання - на принтерах (наприклад, в столиці регіону або регіональних центрах обробки інформації).
  3. Друкуємо весь комплект на принтерах в столиці регіону.
  4. Друкуємо завдання на принтері в столиці, а бланки відповідей на місцях безпосередньо перед іспитом
  5. Друкуємо весь комплект на місцях на принтерах безпосередньо перед іспитом
  6. Можливі й інші комбінації, зручні регіону, але вони використовуються рідко.

Якщо з печаткою в друкарні і на принтерах в столиці регіону більш-менш зрозуміло (озброєна охорона, вхід за відбитками пальців), то про «друк на місцях» варто додатково прояснити. Оскільки потрібно зберегти конфіденційність завдань перед іспитом, то в столиці регіону виконується «умовна» друк комплектів в файли, які кодуються паролем. Ці файли завчасно відправляються в школи, і після видачі пароля безпосередньо перед іспитом друкуються на будь-якому доступному лазерному принтері.
Пройшов іспит. Далі на сцену виходять скануючі технології ABBYY TestReader. Тут ми максимально зберегли схему обробки іспиту: заповнені учнями бланки скануються, розпізнаються, верифицируются і т.п. Після чого без взаємодії з федеральними центрами прямо на місці виставляються бали по іспитах (ще одна відмінність від ЄДІ).

Підсумки та уроки

  • На даний момент 50 з 83 суб'єктів РФ вибрали нашу технологію для проведення ДПА в своїх регіонах.
  • Проект був повністю інвестиційним з нашого боку, і він досить швидко окупився.
  • C моменту запуску проекту у вересні 2009 року станція практично не поставила вимогу про удосконалень
  • Від початку і до кінця проект зайняв 1,5 року: 10 місяців - аналітика (з них 2 місяці - підготовка докладного ТЗ з картинками), 5 місяців - розробка, решта - тестування і підготовка документації.
    Склад команди:
    З боку ABBYY: два аналітика (робота по проекту забирала у них приблизно 50% робочого часу), менеджер проекту, 1 програміст (1 робочий місяць), фахівець зі збирання дистрибутивів (2 тижні), тестувальник (1 місяць), технічний письменник (3 тижні).
    З боку аутсорсера: менеджер проекту (наше замовлення займав приблизно 20% його робочого часу), програміст (5 місяців), тестувальник (2 місяці), інтерфейс-дизайнер (2 тижні).
  • Ми не використали спеціальних систем колективної роботи, тому дуже багато часу займала листування по електронній пошті і телефонні переговори. А використовувати Outlook і Excel в якості Task-manager нікому не порадимо.
  • Як це часто буває в роботі з аутсорсерами, нам не вдалося уникнути розтягування термінів розробки: спочатку планували впоратися за 3 місяці - впоралися за 5.
  • Але зате ідея з максимально докладним технічним завданням, що включає всі елементи інтерфейсу, спрацювала на 100% - аутсорсери все зробили саме так, як бачилося нам. Вийшло добре.
  • Ідея з адаптерами теж виявилася вдалою. Вона дозволила двом командам розробників працювати незалежно і з'єднати частини програми вже на кінцевому етапі. Будемо використовувати адаптери при оновленні системи для ЄДІ.
  • Ну і нарешті - ДПА виявилася ще більш цікавим і складним проектом, ніж ЄДІ. Нам сподобалося.
Отже, що ми мали в далекому 2008 році?
Чого ми хотіли?
Здавалося б, чого простіше?
Ну що, порахували?
Але як інакше знайти варіант, який підійде всім регіонам?
Ви хочете технічних подробиць?