Д А. ПАНКОВА
Дарья Андреевна II. [ИКОН. 1 — аспирантка, ассистент кафедры информатики СПбГУЭФ.
В 2009 г. окончила Санкт-Петербургский государственный университет экономики и финансов, в 2б!1 г. — Санкт-Пстсрбургский государственный политехнический университет.
Автор 12 публикаций.
Область научной специализации — инструментальные методы в
экономике, управление проектами, обучение в виртуальной среде.
^ ^ ^
МЕТОДИКА ПРИМЕНЕНИЯ АЛГОРИТМА ФОРМИРОВАНИЯ СИСТЕМЫ АВТОМАТИЧЕСКОГО ТЕСТИРОВАНИЯ ДЛЯ ПРОВЕРКИ ЗНАНИЙ СОТРУДНИКОВ*
В условиях инновационной экономики происходят фундаментальные изменения технологического базиса общественного производства. Особое значение приобретает интеллектуальный капитал, который определяет не только структуру национальной экономики, качество производимой продукции и услуг, но и эффективность функционирования предприятий на всех его функциональных уровнях. Степень развития интеллектуального труда и его участие в производственных процессах становятся важнейшими факторами, определяющими конкурентоспособность как предприятия, так и страны в мировой экономике, ее экспортные возможности и долю в мировом денежном доходе. Все это обусловило появление новых подходов к управлению этими ресурсами.
Исследование вопросов управления интеллектуальными активами современного предприятия указывает на необходимость консолидации разрозненных функций управления интеллектуальными активами в самостоятельную функциональную систему, которая состоит из подсистем, реализующих функции: управления созданием интеллектуальных активов предприятия; управления использованием интеллектуальных активов; обеспечения комфортных условий труда сотрудников предприятия, связанных с управлением интеллектуальными активами предприятия [2]. В свою очередь подсистема управления использованием интеллектуальных активов предполагает, в том числе, и овладение знаниями сотрудников предприятия с помощью реализации процессов информирования, контролирования и управления. Процессы контролирования реализуют различные методы и методики тестирования. Наиболее хорошие результаты показывают методики, основанные на тестировании с открытыми вопросами.
Задачей данной статьи является описание методики применения разработанного автором алгоритма формирования системы компьютерного тестирования с открытыми вопросами и демонстрация результатов полученных при проверке знаний сотрудников в области управления проектами.
Под открытыми вопросами понимается такой тип тестового задания, варианты ответа на который не предлагаются, с тем чтобы исключить догадки, продемонстрировать понимание содержания (второй и последующие уровни усвоения) [5].
К факторам, обусловливающим актуальность данного подхода, можно отнести следующие: техника тестирования является одной из наиболее эффективных техник при проверке знания; тестирование с использованием компьютеров (особенно дистанционно) позволяет существенно экономить время; ни одна из существующих систем компьютерного тестирования не поддерживает в полной мере авто-
ГРНТИ 06.01.29 © Д.А. Панкова,2012 Публикуется по рекомендации д-ра техн. наук, проф. В.В. Трофимова.
матическую проверку ответов тестируемых на открытые вопросы; освобождает сотрудников от рутинной работы по проверке результатов тестирования.
Для упрощения задачи построения методики тестирования были приняты следующие ограничения: для улучшения качества теста и исключения проблем неоднозначности при анализе ответа все тестовые вопросы должны быть четко сформулированы (в соответствии с определенными критериями); тест не должен проверять ответы в свободных форматах (например, как эссе или изложение).
После детального анализа существующих технологий для разработки тестовой системы были выбраны:
• IMS QTI (question and test interoperability) — стандартизация способов описания тестовых заданий и результатов тестирования. Данные о тестах в формате IMS QTI описываются на основе языка XML.
• OWL — онтологический язык вэб (ontology web language).
С целью упрощения реализации были проанализированы существующие определения и на их основе предложено определение онтологии как иерархического формального описания объектов, явлений некоторой предметной области и связей между ними. Благодаря этому разработанный алгоритм может быть построен на базе международных стандартов и легко интегрирован в корпоративную информационную систему. Разработанный алгоритм формирования системы компьютерного тестирования с открытыми вопросами представлен на рис. 1.
Он состоит из следующих основных этапов:
1) выбор предметной области. На данном этапе предъявляются требования к отрасли знаний, по которой будет проводиться тестирование;
2) поиск онтологии по выбранной на шаге 1 предметной области. В случае, если разработанную онтологию не удается найти, можно разработать новую;
3) создание шаблона тестового задания. Этому этапу предшествует просмотр структуры выбранной онтологии, и на основании структуры формируется шаблон;
4) автоматическое создание конкретного вопроса. На данном этапе система сама подставляет значение из онтологии в шаблон. При этом часть значений выводится в вопросе, а однозначно связанная с ними часть — сохраняется в файле с ответами, как эталонный вариант, и в дальнейшем с ней будет сверяться ответ, данный тестируемым;
5) проверка работоспособности системы подразумевает тестирование системы перед внедрением;
6) тестирование знаний сотрудника — основной этап, ради которого система и разрабатывалась;
7) автоматическая проверка ответа осуществляется системой посредством сравнения эталонного ответа (выбранного из онтологии на этапе формирования вопроса) и ответа, данного тестируемым;
8) оценка ответа тестируемого.
Новизна данного решения выражается в использовании онтологий как инструмента для формирования тестовых заданий [3].
Проиллюстрируем алгоритм. Допустим, нам необходимо провести проверку знаний в виде тестирования по предмету «Управление проектами» — это первый этап.
В этой предметной области существует свод знаний Project Management Body of Knowledge (РМВоК). С помощью поискового робота находим дескрипционную логику описания РМВоК, разработанную экспертами в данной предметной области: http://pszwed.ia.agh.edu.pl/ontologies [4]. Это второй этап.
Далее следует изучить содержимое файла с онтологией, проанализировать, как он устроен. Это можно сделать двумя путями:
1) визуально-графическим (*.owl) с помощью редактора, например Protégé;
2) словесно-текстовым (*.xml), открыв файл с онтологией в формате xml в любом текстовом редакторе.
Как уже было упомянуто, онтологии представляют собой визуальную связь между объектами, при этом хранятся в файле с расширением owl, который с помощью любой программы для работы с онто-логиями (например, Protégé) может быть сохранен в xml-формате. При этом очевидным становится объектно-ориентированный подход к описанию предметной области: на верхнем уровне онтология РМВоК представлена в виде 87 классов.
Рис. 1. Алгоритм формирования системы
Проанализировав онтологию, можно прийти к выводу, что с ее помощью удобно проверять знания о процессах управления (что является неотъемлемым условием сертификации на базовый уровень по компетенции «Управление проектами»).
Описания процессов хорошо структурированы. В частности, каждое из описаний обязательно включает 3 основные части: входы; выходы; инструменты и методы.
При этом особенностью авторского подхода является нечеткость границ указанных категорий. В качестве примера на рис. 2 представлено описание одного из классов, связанных с управлением проектами.
G? I Рszwed.¡a.agh.edu.pl/ontologies/pmbok-ref/claseee/pmbok. Acoepte d D e I i ve rab I es_-1 3701 G5562.html
Class: pm bo к. Accepted Deliverables
http://pszwed.ia.agh.edu.pI/ontologies/prnbok4.owl#prnbok. AcceptedDel i verables
Asserted Class Hierarchy
-+- Thing
+ i-i i Я' u г.^^И
■ pmbok. AcceptedDeli verables
-+- pmbofflp-rtif actGroups
-{- pmbok .ProjectDeiiverables
- pmbck. Acce predije li vertibles
Superclasses (4)
* P111 Li U К ..¿Tí Li ГТ^^Н
* pmE^ffiaProie^^Kli^S^ffiT^:
*■ ¡slriputTo some prnboi^CloseProjectAr dphase
* isOutputFrcm sonne pnnboK^/erif^^ccpe
Usage (2)
■ * pmbok .CloseProjectAndPhase® haslnput some pmbok. ArceptedDeli verables
I ♦ pmbok .Veri^E^B^^R hasOutp^^me pnibuk.AcceptedDe!iverdbles
Рис. 2. Описание одного из классов (AcceptedDeliverables) в онтологии РМВоК
«Создание шаблона тестового задания». Данный этап является комплексным. Во-первых, для разработки шаблона тестового задания необходимо проанализировать структуру файла с онтологией. Во-вторых, на основе этой структуры необходимо сформулировать возможные варианты вопросов. В-третьих, создать шаблон на программном уровне. Автором предложено следующее правило создания шаблона: система сможет в момент генерации вопроса подставить любые параметры (которые она выберет из перечисленных в файле с описанием предметной области).
При такой четкой регламентации и систематизации знаний некой предметной области, как описанная выше, мы получаем возможность строить не просто четко сформулированные вопросы, но и вопросы с параметрами. Например: «Какой класс обладает свойством <...> равным <...> и свойством <...>, равным <...>?».
Такие ответы можно формировать в режиме реального времени во время проверки результатов теста, а можно единожды, что уменьшит нагрузку на сервер приложения, но увеличит объем хранимой информации. Если был выбран второй вариант, то в файле с информацией о вопросе должны быть указаны такие поля, как «Текст правильного ответа». «Идентификатор тестируемого в системе», «№ заданного вопроса», «Текст клиентского ответа» и «Балл».
«Оценка результатов тестирования». Составители системы вправе сами выбирать правило оценки результатов. Например, в случае, если существует вероятность, что правильный ответ будет содержать более одного значения, можно использовать правило: «Итоговая оценка тестируемого в процентах равна сумме правильных ответов, данных тестируемым, поделенная на сумму эталонных ответов».
На шаге «Автоматическое создание конкретного вопроса» подразумевается автоматическая подстановка значений из онтологии в шаблон, созданный на этапе 4 для генерации конкретного вопроса тестируемому. В прототипе системы, созданном автором, это реализовано следующим образом: система с помощью генератора случайных чисел выбирает из онтологии какой-либо класс, его название записывает в файл, «заходит вглубь» и «смотрит» свойства этого класса, записывает их в файл и одновременно подставляет в шаблон и выводит на экран тестирования.
Шаг «Проверка работоспособности системы» подразумевает тестирование разработанного модуля с выбранной онтологией по некоторым сценариям использования.
Алгоритм не предъявляет особых требований к технологии его реализации. Так, он был реализован в виде прототипа подсистемы контроля знаний на языке программирования java, который интегрировался в систему Moodle. Тестовые испытания такой подсистемы показали хорошие результаты, а сама подсистема признана работоспособной.
Для внедрения подсистемы, реализующей описанный выше алгоритм, потребовалось (максимально): 8 часов работы программиста, 3 часа — тестировщика и 2 часа — специалиста в предметной области (менее 2 дней). Время проверки результатов тестирования, включая распечатку результатов, со-
ставило в среднем менее 2 минут. Если считать, что на проверку результатов тестирования традиционным (ручным) способом (сверку ответов 1 тестируемого с эталонными) специалист кадровой службы в среднем затрачивает 20 минут (в зависимости от количества вопросов в тесте), то для проверки 3 тестов он затратит время, близкое к 1 часу [1].
Таким образом, экономия времени при проведении тестирования с помощью предлагаемого алгоритма по сравнению с традиционным способом составляет 30 раз. Например, при проверке знаний у 12 человек традиционным способом понадобится 8 часов (1 рабочий день), а при проверке с помощью предлагаемого алгоритма — всего 12 минут! Эффективность предлагаемого алгоритма будет особенно хорошо видна при массовой проверке знаний.
Отметим также, что описанный алгоритм может быть достаточно просто интегрирован в процесс подбора персонала и легко адаптирован к различным предметным областям. С его помощью можно повысить производительность труда (минимизировать рутинную составляющую работы) кадрового отдела. Кроме того, предлагаемая подсистема при оценке знаний исключает субъективный фактор.
ЛИТЕРАТУРА
1. Вологина О.В. Психологическое тестирование при приеме на работу. URL: http://www.hr-portal.ru/article /psihologicheskoe-testirovanie-pri-prieme-na-rabotu
2. Лукичееа Л.И. Управление интеллектуальным капиталом. М.: Высшая школа менеджмента, 2008.
3. Панкоеа Д.А. Разработка алгоритма формирования системы автоматического тестирования // Всероссийский конкурс научно-исследовательских работ студентов и аспирантов «Инновационные технологии в образовательном процессе»: сборник научных работ. Том 2. Белгород, 2011.
4. Сайт кафедры автоматики Академии горного дела и металлургии им. Станислава Сташица в Кракове. URL: http://pszwed.ia.agh.edu.pl/ontologies
5. Трофимов В.В. Методология формирования образовательных программ на базе компетентностного и модульного подходов // Информационные технологии в бизнесе: материалы 6-й между народной конференции, СПбГУЭФ / под ред. проф. В.В. Трофимова. СПб.: Изд-во СПбГУЭФ, 2010. 135 с.