Ціна авторської розробки із використанням рівня знань

Скачати 113.97 Kb.

Назва	Ціна авторської розробки із використанням рівня знань
Дата	02.04.2013
Розмір	113.97 Kb.
Тип	Документи

bibl.com.ua > Фізика > Документи

The Cost of Authoring with a Knowledge Layer

Lichao LI, Judy KAY

School of Information Technologies,

The University of Sydney, NSW 2006, Australia

{lli1, judy}@it.usyd.edu.au

Ціна авторської розробки із використанням рівня знань

Анотація
Ми щойно додали рівень знань до навчального інструменту, Assess, розробленого, щоб допомагати студентам розвивати свої навички у програмуванні. Ця стаття описує вигляд нового Assess для авторів і оцінку авторського інтерфейсу. Ми обговорюємо вигоди додавання рівня знань і звітуємо про навчання спроби авторської розробки.
Вступ
Сьогодні існує багато освітніх систем адаптивного гіпермедіа (AH) [1], наприклад ELM-ART [2], WebTutor [3], INSPIRE [4] and TANGOW [5]. Перевагою адаптивних навчаючих систем над іншими є те, що надають персоналізоване навчальне середовище і/або навчальний досвід. Більше того, такі системи відносно легко будувати, порівняно із традиційними Інтелектуальними навчаючими системами. Проте з перспективи авторської розробки, ефективне АН не завжди просто розробити [6]. Були зроблені важливі роботи для підтримки потужної і гнучкої розробки для авторів АН, такі як LAOS [6] і MetaLinks [7].

У цій статті ми презентуємо Assess [8], освітню систему по програмуванню, яка допомагає студентам у самоперевірці знань і надає адаптований зворотній зв'язок учням. Наше дослідження в основному зосереджене на доданні рівня знань у систему, таким чином можуть бути змодельовані знання студентів, і може бути наданий більш інтелектуальний зворотній зв'язок щодо прогресу студента. У цій статті ми детально обговорюємо авторську розробку навчального матеріалу у системі. Для більш детального огляду всієї системи і оцінювання з точки зору студента, див. [8]. Наступна частина надає легкий огляд системи Assess з точки зору студента. Частина 3 описує авторську розробку вправ у системі. Частина 4 описує оцінювання і частина 5 є завершенням.
2. Assess: Інструмент для самооцінювання
Звітована тут робота була виконана у контексті викладання/вивчення програмування на C і Java на нашому предметі, що вивчається студентами, Методи розробки програмного забезпечення, який є курсом з програмування другого року, що має метою викладання програмування на С у середовищі UNIX.

У Assess вправи для самооцінювання мають форму завдань. Кожне завдання задачу з програмування, яку студенту потрібно вирішити. Система дозволяє студентам надати розв’язання тих задач і самостійно оцінити свої розв’язки по набору оціночних критеріїв, що надаються авторами. Більш важливо, система забезпечує студентів прикладом розв’язку для оцінки. Вони, як правило, вони не є «досконалими» рішеннями, проте вони дають студентам деякі ідеї, щоб обдумати і оцінити. Ці приклади рішень були заздалегідь оцінені авторами завдань. Студент має оцінити їх так, як він оцінював свої власні рішення. Його оцінка потім порівнюється з оцінкою викладача по цьому ж самому прикладу розв’язку. Порівняння дає студенту зворотній зв'язок: як учитель оцінив приклад, відмінність між оцінкою викладача і оцінкою студента, і чому учитель оцінив приклад саме таким чином. Ця інформація використовується для оновлення знань системи про навчальний прогрес студентів, який може бути переглянутий у студентському профілі користувача. Поточний підхід нашої системи до оцінювання студентів є досить унікальним, таким , що відрізняється від інших існуючих систем, таких як CourseMaster [9] і InSTEP [10], обидві з яких автоматично оцінюють коди студентів і надають негайний зворотній відклик. Уся розробка мала на меті допомогти студентам міркувати над кодом з перспективи, визначеної у критеріях.

Процес самооцінювання студентів показано на Рис.1 Ця система використовувалась у 2004 р. у курсі Методи розробки програмного забезпечення. Ми зрозуміли, що там мав місце брак подання знань у системі, таким чином перешкоджаючи інтелектуальному і інформативному зворотному зв’язку із студентами. Для подолання цього обмеження ми додали рівень знань до системи Assess (див. Рис.2), таким чином усі спеціальні елементи були замінені на систематичний рівень знань, який визначив навчальні цілі, компоненти моделі користувача і онтологію предметної області. Щоб вмістити цей новий рівень, процес авторської розробки був сильно змінений у Assess. В даній статті ми подаємо новий процес створення завдань і їх оцінювання.

Рис.1. Старий процес самооцінювання студентів

Рис.2. Новий процес самооцінювання студентів

3. Створення завдань з рівнем знань
Разом із включенням рівня знань, нам потрібно встановити навчальні цілі до системи. Ці цілі є поняттями, які мають бути викладені/вивчені, визначені викладачами у відповідності до вимог до результатів навчання. Вони є тим, чому система намагається навчити, і що використане для визначення викладацьких/навчальних цілей індивідуальних завдань. Більше того, вони визначають знання, якими система намагається моделювати кожного студента, встановлюючи у студентській моделі чи знає студент їх, чи ні. Додавання чи видалення цілей досягається за допомогою використання Веб-інтерфейсу, як показано на рис. 3. Після визначення цих цілей, потрібно пройти три етапи, щоб створити завдання у Assess:

Етап 1: Створити вираз завдання і поставити у відповідність навчальні поняття

Етап 2: Редагувати оціночні критерії

Утап 3: Створити приклади розв’язків

Рис.3. Інтерфейс редагування понять

(Ліва частина інтерфейсу вказує поняття, які вже існують в системі. Вони організовані у різних попередньо визначених категоріях. Верхня права частина екрану дозволяє додати поняття. Кожне нове поняття має бути обране із попередньо визначеної категорії. Нижня права частина екрану дозволяє видалити поняття з системи)
На першому етапі (Рис.4) автор вводить вираження завдання (тобто завдання, яке студент має вирішити) і, можливо, нарис відповіді, щоб допомогти студенту. Вони також мають вказати складність проблеми і визначити, чи потрібно вести студентів зберегти і оцінити їх власну відповідь перед переглядом рішень-прикладів. Більш важливо те, що автор повинен співвіднести завдання із відповідними навчальними цілями. Кожна вибрана навчальна мета представляє викладацьку/навчальну ціль завдання. Завдання повинно мати хоча б одну, співвіднесену з ним, ціль, для відмічення, чого воно прагне навчити.

Другим етапом у створенні завдання є редагування оціночних схем. Див. рис. 5. Набір схем для оцінювання по замовчуванню автоматично генерується на основі навчальних цілей завдання. В результаті, коли студенти оцінюють їхнє власне рішення і наші приклади рішень з ними, вони повинні зосередитися на навчальних цілей завдання. Однак, так як автоматично сгенеровані оціночні критерії схем не завжди виразні, ми дозволяємо редагувати їх.

Етап 3 включає створення, редагування і оцінювання рішень-прикладів. На цьому рівні може бути створений новий приклад. Автор може редагувати оціночні схеми рішень-прикладів. Усі рішення-приклади завдання використовують (розділяють) той самий набір схем, які були створені на Етапі 1 і 2. Однак, для кожного рішення можна мати додаткові оціночні схеми. Це означає, що кожне завдання має ключові навчальні цілі, проте кожен приклад-рішення може мати додаткові елементи. Рис.6 показує, яким чином додаткові оціночні схеми можуть створюватись і видалятись у прикладах-рішеннях. Тим часом, головні начальні поняття завдання не можуть бути змінені тут; як було сказано вище, вони є ядром усього завдання і можуть редагуватися лише на рівні завдання, тобто на Етапі 1 і 2.

Рис.4. Етап 1 процесу створення нового завдання із вибором навчальних цілей (верхня ліва частина інтерфейсу містить текстове поле для введення вираження завдання автором. Праворуч від цього автор може ввести необов’язковий нарис відповіді. Внизу інтерфейсу автор може вибрати навчальні цілі завдання. Нижнє ліве поле містить усі навчальні цілі, доступні у системі, які не були поставлені у відповідність до завдання. Поле, праворуч від цього, містить цілі даного завдання. Завдання не може містити повторення тієї самої цілі. )

Рис.5. Етап 2 створення нового завдання, редагування схеми оцінювання (Усі схеми оцінювання відображаються внизу сторінки, з їх критеріями ліворуч і опціями оцінок праворуч у меню, що відкриваються у нових вікнах. Коли автор редагує схему, схема буде взята із нижньої частини і буде показана вгорі інтерфейсу. Її критерії буде показано у текстовому полі ліворуч і її опції оцінок відобразяться в полях праворуч, таким чином їх можна буде редагувати. Після завершення створення автор може зберегти зміни)
Після оновлення оціночних схем для рішення-прикладу автор може оцінити рішення по повному набору схем оцінювання і надати пояснення оцінювання (Рис.7). Коли студент оцінює це рішення-приклад, його оцінка порівнюється із оцінкою автора. Відмінність показує, на скільки добре студент розуміє навчальні поняття, асоційовані із оціночними схемами, і записується у його індивідуальну модель учня для забезпечення адаптивного начального зворотного зв’язку. Ми можемо проілюструвати це на прикладі: поняття Управління виконанням програми – цикл While вибране як навчальна ціль завдання і його оціночна схема згенерована автоматично. Оціночний критерій схеми такий: «Цикл while, використаний у рішенні правильний» і його опції оцінки «Так» і «Ні». Під час оцінки даного рішення студент вважає, що код правильний, проте автор завдання вважає інакше, це показує, що студент не може розрізнити елементи, які роблять цикл while правильним, і тому він на даний момент не розуміє (не досяг) навчальну мету. Ця інформація записується у його учнівську модель.

Рис.6. Редагування навчального поняття для одного приклада-рішення для одного завдання (Верхня лідва частина показує головні навчальні цілі завдання. Верхня права частина показує навчальні цілі для цього конкретного приклада-рішення, в даному випадку – Динамічні структури в мові С – створення зв’язаного списку, Вони також можуть бути видалені звідси. Нижня частина дозволяє додати додаткові навчальні цілі і створити відповідні оціночні схеми)

Рис.7. Оцінювання рішення-приклада (Інтерфейс дозволяє редагувати приклад-рішення у верхньому лівому текстовому полі. У верхній лівій частині автор може оцінити код по оціночній схемі. Він також може надати необов’язкове пояснення у текстовому полі внизу)
Після закінчення створення і оцінки рішення-прикладу та наповнення його внутрішнім завданням, автор може опублікувати його для перегляду студентами.
4. Оцінка
Ми провели попередній експеримент по Assess з точки зору авторів. Це було розроблено для оцінювання інтелектуальних зусиль і часу, який витрачається на створення завдань у Assess, так само і для оцінки зручності використання інтерфейсів системи. Конкретно ми хотіли запитати: «Які зусилля і час необхідні для введення нового завдання у Assess». Щоб відповісти на це запитання, ми оцінювали:

На скільки ефективні і зручні інтерфейси?
Як швидко і правильно автори, що працюють вперше, можуть створити завдання?

Ми обрали 5 учасників із наших відмінників по комп’ютерним наукам і студентів четвертого курсу взяти участь у випробуванні. Вони мали різні передумови і походження. Учасник 1 був практикуючим тьютором, проте ніколи не викладав Методи розробки ПЗ до цього. Учасники 2 і 3 були тьюторами цього предмету у 2004 р. Учасник 4 ніколи не викладав і учасник 5 був тьютором лише короткий період у 2003р. Учасник 3 був викладачем-асистентом по МРПЗ у 2004.Усі учасники були у перших 15 відсотках класу по завершенні курсу, тому всі вони добре розумілися у ньому. Хоча це, очевидно, високо кваліфікована група, технічна еліта, вона представляє клас користувачів, кваліфікованих визначати і вводити завдання з предмета.

На початку занять ми продемонстрували студентську частину Assess, щоб показати, як працює система. Це дозволило учасникам отримати деякий погляд всередину Assess, проте не відхилило експеримент, давши їм побачити, що вони мають зробити. Ми також забезпечили учасників матеріалами, які вони повинні ввести в систему. Це включало вираження завдання і два простих рішення-приклада, які були взяті з початкової системи Assess. Їх попросили створити знову це завдання у Assess. Їм також повідомили навчальні цілі завдання і рішень-прикладів. Ми не просили учасників створювати нові завдання, тому що створення навчальних матеріалів це завжди процес, що бере багато часу і вимагає глибокого розуміння великої картини цілей курсу. Ми не ставили за мету визначити, як люди намагаються зробити завдання, що вимагає більшого інтелекту, використовуючи вибір завдань і надаючи рішення. Крім того, ми наперед ввели навчальні матеріали у текстовому редакторі, тому учасники могли просто вирізати і вставляти їх за допомогою інтерфейсу. Це відображає типовий сценарій створення завдань у Assess, коли лектор встановивши питання екзамену, класифікує відповіді студентів і потім розробляє і тестує рішення-приклади. У такому випадку усі матеріали, доступні учасникам, могли б бути завершені і підготовлені на момент, коли лектор має вводити завдання до Assess.

Для експерименту учасників попросили створити завдання у системі, використовуючи наданий матеріал, і оцінити процес створення навчального матеріалу на основі його зручності, відокремивши необхідні інтелектуальні зусилля від простоти використання інтерфейсу. Учасників попросили думати вголос, таким чином ми могли занотовувати будь-які труднощі, з якими вони стикалися. Усі учасники завершили випробування успішно. Інтелектуальні зусилля, необхідні для кожного етапу створення завдання позначалися від 1 (найменші зусилля) до 6 (багато зусиль). Оцінки учасників проілюстровані на рис.8, який показує, що необхідні невеликі інтелектуальні зусилля. Учасник 4 визначив етап 1 і етап, як такі, що вимагають багато зусиль. Учасники були схильні вважати Етап 2 таким, що вимагає інтелектуальних зусиль найвищого (або рівного найвищому) рівня, так як створення запитань, які можуть правильно оцінити розуміння студента оціночного критерію, що відповідає навчальному поняттю, є непростим процесом.

Щодо зручності інтерфейсу більшість учасників мають позитивні оцінки. Учасник 3 оцінив інтерфейс Етапу 2, як не простий для використання, тому що учасник вважає, що для авторів надано не достатньо керівництва (див. Рис.5). Учасник 5 оцінив інтерфейс Етапу 1, як не дуже зручний і висловив думку, що там було занадто багато інформації (див. рис.4). Загалом нова функціональність, якої потребує рівень знань, не значно збільшила інтелектуальні витрати, необхідні для створення завдання і не ввела занадто складності в інтерфейси.

Рис.8. Ілюстрація оцінок учасників щодо інтелектуальних зусиль, необхідних для кожного з етапів процесу створення завдання (1 – мінімальні, 6 – багато зусиль)

Рис.9. Ілюстрація різних часових витрат учасників на кожний етап процесу створення завдання.

Дані про витрати часу мають бути розглянуті адекватно у зв’язку з тим, що учасники виконували оцінювання за допомогою роздумів вголос. Однак, це давало знати про зусилля і задіяний час і, взяте разом із спостереженнями учасників, є цінним для встановлення показових часів створення завдання. Час, який різні учасники провели на різних етапах, створюючи завдання, зображено на рис.9. Усі, окрім одного учасника, завершили створення завдання за 15 хвилин. У першого учасника для завершення пішло 19 хвилин, тому що це був перший пробний користувацький запуск, і учасник дав великі і значні пояснювальні відгуки по експериментальній процедурі під час користувацької спроби. Учасники 2 і 3 використали найменше часу з усіх, тому що вони були знайомі із поняттями курсу, так як були тьюторами предмету, що буде нормою для типового автора завдань. Етап три був найповільнішим для усіх учасників, тому що він містить більше функцій і більше інтерфейсів для перегляду. Слід відмітити, що загальний час не є просто сумою часів, що були використані учасниками на кожному з чотирьох рівнів. Він також включає час, затрачений учасниками на читання інструкцій на домашній сторінці тьютора і початковій сторінці завдання, що не є частиною жодного з конкретних етапів. Звичайно, це також включає будь-який час, витрачений на знайомство/спостереження.
5. Завершення

Ми подали інструмент для самооцінювання студентів Assess і пояснили процес створення вправи в системі із сумісним рівнем знань. Ми також описали користувацькі спроби із результатами, що показують:

Інтелектуальні зусилля, які вимагаються для введення нового завдання невеликі і інтерфейси, що дозволяють створити нове завдання порівняно зручні у використанні;
Внутрішній авторський процес у Assess бере до 15 хв., що ще раз показує задіяні зусилля і час, які, з урахуванням рівня знань, є мінімальними.

Це показує, що новий рівень знань додає лише невелику складність у задачу створення навчальних матеріалів у Assess. На початку може здаватися, що додавання рівня знань у стандартний навчальний інструмент повинно вимагати більше зусиль від авторів завдань. З нашого досвіду, все виглядає так, що рівень знань може насправді зменшити роботу по визначенню нового завдання і підвищити якість завдання, так як навчальні цілі чіткі, і тому допомагають авторам зосередитися на тому, що вони хочуть, щоб студенти вивчили. Більше того, у новій системі Assess оціночні критерії автоматично генеруються і відповідають навчальним цілям завдання. Це означає, що авторам не потрібно створювати запитання, щоб перевірити навчальні цілі завдання і запобігає ризику, що вони забудуть їх включити. Крім цього рівень знань робить реальним забезпечення учнів і авторів моделями учня, які відбивають навчальний прогрес, підтримуючи відображення (рефлексію).

Література
[1] Brusilovsky, P. (2002) Adaptive hypermedia, User Modeling and User Adapted Interaction, Ten Year

Anniversary Issue 11 (1/2), 2002. 87-110.

[2] Brusilovsky P., Schwarz E., and Weber G. (1996) ELM-ART: An intelligent tutoring system on World

Wide Web. In Frasson, C., Gauthier, G., and Lesgold, A., eds., Proceedings of the Third International

Conference on Intelligent Tutoring Systems, ITS-96. Berlin: Springer. 261-269.

[3] Pérez T.A., Gutiérrez J. (1996) WebTutor, Un sistema Hipermedia Adaptativo para la educación en

WWW, Actas del V Congreso Iberoamericano de Inteligencia Artificial, IBERAMIA'96. Cholula,

Puebla, MÉXICO, 1996.

[4] Grigoriadou, M., Papanikolaou, K., Kornilakis, H., & Magoulas, G. (2001) INSPIRE: An INtelligent

System for Personalized Instruction in a Remote Environment. In P. D. Bra, P. Brusilovsky, & A. Kobsa

(Eds.), Proceedings of Third workshop on Adaptive Hypertext and Hypermedia, July 14, 2001.

Sonthofen, Germany, Technical University Eindhoven. 13-24.

[5] Carro R., Pulido E., Rodríguez P. (1999) Task-based Adaptive learNer Guidance On the WWW: the

TANGOW System, Second Workshop on Adaptive Systems and User Modeling on the Web, en la Eighth

International World Wide Web Conference. Toronto, Canadá. Mayo 1999.

[6] Cristea A. (2004) Authoring of Adaptive Hypermedia; Adaptive Hypermedia and Learning

Environments. Book chapter to appear in "Advances in Web-based Education: Personalized Learning

Environments", Sherry Y. Chen and Dr. George D. Magoulas (eds.). IDEA Publishing group.

[7] Murray T., (2002) MetaLinks: Authoring and affordances for conceptual and narrative flow in adaptive

hyperbooks. International Journal of Artificial Intelligence in Education, 13 (1).

[8] Li L., Kay J., (2005) Learner Reflection in Student Self-Assessment, TR 568, School of Information

Technologies, The University of Sydney, ISBN 1864877170.

[9] CourseMaster. (17 May, 2005). CourseMaster [Online]. School of Computer Science & IT, The

University of Nottingham, UK., Available: http://www.cs.nott.ac.uk/CourseMaster/cm_com/index.html

[10] Odekirk-Hash, E. (2001). Providing Automatic Feedback To Novice Programmers. Unpublished MA,

The University of Utah, Utah.

Схожі:

Кисленко Тетяна Леонідівна Розробки уроків обслуговуючої праці 5-9 класи з використанням інформаційно-комунікативних технологій	«Початок війни. Події1939червня» Розробки уроків по темі: «Друга світова війна» з використанням мультимедійних засобів
Завідувачка лабораторії «Культурно-виховуюче середовище сучасної... О. М. Коберника. В центрі уваги Авторської школи О. А. Захаренка завжди знаходилася дитина з її проблемами, інтересами, прагненнями....	Алгоритмічний підхід до створення файлів з розширенням SWF та використанням технології Flash На сучасному етапі розвитку країни значно підвищуються вимоги до рівня підготовки спеціалістів, які повинні володіти запасом теоретичних...
Методичні рекомендації щодо оформлення дипломних робіт для студентів напряму підготовки “ Підсумковим етапом навчання в університеті, що дає право на присвоєння освітньо-кваліфікаційного рівня «бакалавр» з напряму підготовки...	Методичні рекомендації щодо оформлення дипломних робіт для студентів напряму підготовки “ Підсумковим етапом навчання в університеті, що дає право на присвоєння освітньо-кваліфікаційного рівня «бакалавр» з напряму підготовки...
Визначення ефективних шляхів підвищення рівня іншомовної комунікативної... Ти актуалізує розробку підходів до використання технічного та дидактичного потенціалу інформаційних технологій для розвитку особистості...	Коли ціну знизили, кількість відвідувачів збільшилась на 50%, а збір... Ціна на вход на стадіон 1 грн. 50 коп з чоловіка. Коли ціну знизили, кількість відвідувачів збільшилась на 50%, а збір на 25%. на...
Урок-проект з української мови Тема: удосконалення знань про складне... Тема: удосконалення знань про складне речення і його типи (з використанням інформаційних технологій)	ПРОГРАМА вступних випробувань освітньо-кваліфікаційного рівня бакалавр... Критерії оцінювання знань (за 200-бальною системою, мінімальна кількість балів – 140)

Додайте кнопку на своєму сайті:
Портал навчання