Обговорюються проблеми якості підготовки фахівців з інформаційних технологій. Для якісної підготовки необхідна велика кількість завдань на програмування, що збільшує навантаження на викладача. Пропонується підхід, заснований на генерації контрольних завдань з дисципліни "Бази даних». Завдання формуються на основі набору базових завдань з використанням техніки параметризації. Результат виконання студентського запиту до базі даних оцінюється. В оцінці враховується кількість спроб до досягнення правильного результату. Підхід може використовуватися для різних дисциплін.

Анотація наукової статті з комп'ютерних та інформаційних наук, автор наукової роботи - Лукін Володимир Миколайович, Чернишов Лев Миколайович


Область наук:
  • Комп'ютер та інформатика
  • Рік видавництва: 2018
    Журнал
    Освітні технології (м.Москва)
    Наукова стаття на тему 'ПРОБЛЕМИ ПІДГОТОВКИ СТУДЕНТІВ У ГАЛУЗІ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ: КОНТРОЛЬ ЯКОСТІ'

    Текст наукової роботи на тему «ПРОБЛЕМИ ПІДГОТОВКИ СТУДЕНТІВ У ГАЛУЗІ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ: КОНТРОЛЬ ЯКОСТІ»

    ?ОСВІТНІ ТЕХНОЛОГІЇ № 3/2018

    .............................119

    Лукін Володимир Миколайович, кандидат фізико-математичних наук, доцент

    Чернишов Лев Миколайович, кандидат фізико-математичних наук, доцент

    Московський авіаційний інститут (національний дослідницький університет), м.Москва

    ПРОБЛЕМИ ПІДГОТОВКИ СТУДЕНТІВ У ГАЛУЗІ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ: КОНТРОЛЬ ЯКОСТІ

    Обговорюються проблеми якості підготовки фахівців з інформаційних технологій. Для якісної підготовки необхідна велика кількість завдань на програмування, що збільшує навантаження на викладача. Пропонується підхід, заснований на генерації контрольних завдань з дисципліни «Бази даних». Завдання формуються на основі набору базових завдань з використанням техніки параметризації. Результат виконання студентського запиту до бази даних оцінюється. В оцінці враховується кількість спроб до досягнення правильного результату. Підхід може використовуватися для різних дисциплін.

    Ключові слова: контроль знань, інформаційні технології, генерація контрольних завдань, бази даних.

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

    до авторів неодноразово зверталися з проханням порекомендувати тлумачних випускників або, на худий кінець, студентів старших курсів. Так як якість випускника, в кінцевому рахунку, визначається потребами ринку праці, виникає питання, кого ми випускаємо? Він природно переростає в проблему якості викладання, яке визначається тим,

    120

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

    Визначимося з тим, кого ми вчимо. Низький рівень шкільної підготовки - це вже загальне місце. І знання з інформатики не виняток. Хоча на першому курсі і зустрічаються студенти з непоганою підготовкою, і їх присутність дуже корисно, вони не визначають, на жаль, загальний рівень. Отже, треба вести заняття так, як ніби в школі нічому не вчили (знаменита свого часу фраза Аркадія Райкіна «забудьте школу як кошмарний сон» тут навіть і не потрібна).

    Тепер про тих, хто вчить інформаційних технологій. Якщо вважати, що якість навчання визначається потребами виробництва, необхідно, щоб викладач інформатики (програмування) був з ними знайомий. З природних причин в масовому порядку підібрати таких викладачів неможливо. Для вирішення цієї проблеми А.Н. Терехов пропонує пов'язати з кафедрою підприємство з розробки програмного забезпечення, на якому, зокрема, будуть працювати викладачі [1].

    Але це не так уже й просто: по-перше, підтримкою подібного підприємства або постійними контактами з ним повинен займатися спеціальний співробітник, якого зазвичай немає, по-друге, на підприємстві не обов'язково будуть практикуючі програмісти, які бажають займатися зі студентами. У цих умовах потрібно, щоб вимоги викладача були максимально близькі до виробничих. Якщо обмежитися програмуванням, слід вимагати дотримання характеристик якості програмного забезпечення з стандарту ДСТУ ISO / IEC 25010-2015 [2], найбільш важливі з яких для програмування - це функціональна придатність, надійність, зручність використання, сопровождаемость.

    На питання «чому вчити» найпростіша відповідь - того, що зазначено в навчальній програмі. Так, звичайно, але в програмі немає поняття «якісне програмування». Пробігти протягом семестру тему «програмування» можна без праці, але тоді результат буде такий, який він є. Якщо ми беремося за навчання якості, розглянемо докладніше його характеристики.

    Функціональна придатність - найбільш очевидна характеристика. У студентському варіанті вона означає, що студент в точності реалізує ті функції, які вимагає викладач, який грає роль замовника програмного забезпечення.

    Надійність в «великому світі» визначається ймовірністю появле-

    121

    ня помилки, що завдає істотної шкоди. Зазвичай вона оцінюється загальною кількістю помилок при тестуванні. Звідси випливає, що викладач повинен враховувати кількість помилок, які робить студент при здачі роботи, а особливо - помилок при обробці позаштатних ситуацій. Саме вони призводять до падіння космічних апаратів, збоїв в банківських системах тощо.

    Зручність використання в студентських роботах зводиться до призначеного для користувача інтерфейсу. На жаль, цієї, в найбільшою мірою впливає на користувача, характеристиці якості приділяється в навчальному процесі дуже мало уваги. А величезна кількість втраченого часу, значне число помилок користувача виходить з-за потворного інтерфейсу, виготовленого нашими, по суті, випускниками. Ця проблема дуже стара (див., Наприклад, [3, 4]), але віз і нині там. Подивіться хоча б на стиль взаємодії з системою, яка працює в поліклініках і яку просувають під маркою «цифровізації» медицини.

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

    Проблема навчання створенню якісного програмного забезпе-

    чення досить складна, вона охоплює всі розділи технології розробки програмного забезпечення. Ми зупинимося лише на двох темах, найбільш близьких до студентських робіт: програмуванні та роботі з базами даних.

    І тут ми переходимо до питання «як вчать». Ми бачимо, що для навчання якісної розробки потрібен ретельний контроль студентської продукції. Значить, для перевірки тільки однієї програми необхідно підготувати пакет «правильних» тестів, які перевіряють функціональність, і пакет «неправильних», які перевіряють надійність. Перевірка стилю виконується візуально, для цього тести не потрібні. А з огляду на тезу Р. Гласса [5] «Більшість завдань допускають безліч однаково хороших програмних рішень», визнаємо, що автоматична перевірка тексту - дуже непросте завдання.

    Щоб бути впевненим у якісній підготовці майбутнього фахівця, слід для кожної теми мати кілька завдань, в тому числі і задач на аналіз тексту. Окремо стоять контрольні заходи: тут потрібно підготувати пакет однотипних завдань. При сучасних технологіях списування, завдання для кожного іспиту (заліку) повинні бути унікальними. Ми приходимо до висновку, що обсяг роботи для підготовки викладачем добротного курсу стає надмірним, і доводиться, на жаль, жертвувати якістю. Отже, ми дісталися

    122

    до однієї з ключових причин випуску неякісних програмістів: природна перевантаження викладача на підготовку курсу, ускладнена необхідністю виконувати все більше безглуздих, по суті, робіт по звітах і контролів.

    Автори абсолютно незалежно один від одного прийшли до однієї і тієї ж ідеї: автоматизувати, по можливості, як процес генерації завдань і тестів, так і процес перевірки студентських робіт. Результатом стали спільно розроблені системи підтримки діяльності викладача з дисциплін програмування і баз даних (див., Наприклад, [6]). Системи спочатку не передбачалися для широкого поширення, автори їх розробляли для себе. Але близькість одержані рішень дала привід задуматися про користь подібних розробок і для інших викладачів, які бажають випускати якісних програмістів.

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

    альность автоматизації підготовки та перевірки контрольних завдань. При цьому завдання не повинні повторюватися, інакше ми отримуємо проблему ГДЗ (готових домашніх завдань). Генерація тестових завдань застосовується в різних дисциплінах і реалізована в декількох системах [7], але для програмування є своя специфіка.

    Автоматизована перевірка відповідей на контрольні завдання аналогічна перевірці відкритих відповідей у ​​системах автоматизованого тестування, але для програмістів дисциплін завдання дещо спрощується. Можна було б скористатися досвідом перевірки правильності роботи програм при проведенні олімпіад, тим більше що для цього існує кілька систем. Але там завдання унікальні, і тестові дані складаються кожен раз заново. Для контролю в типовому навчальному процесі необхідний набір типових завдань, а їх унікальність забезпечується генерацією варіантів на деякому досить великому наборі «базових» завдань. Ці базові завдання можуть а) складатися самими студентами і б) накопичуватися від семестру до семестру.

    Розглянемо дисципліну програмування, де необхідно перевіряти вміння читати і писати програми на деякій мові програмування. У базі тестових завдань (БТЗ) зберігається набір готових програм разом з вихідними даними і результатами роботи програм

    123

    на них. Можливі наступні типи тестових завдань з відкритими відповідями:

    1. Студенту пред'являється програма і дані. У відповіді він повинен вказати результат роботи програми. Система перевіряє правильність результату по зберігається еталону.

    2. Студенту пропонується написати програму по заданій умові. Система виконує його програму на збережених даних і звіряє отриманий результат з еталонним.

    3. Студенту пред'являється програма і результат її роботи. У відповіді він повинен вказати дані, на яких програма отримала зазначений результат. Система зіставляє дані з зберігаються еталонами або виконує програму і порівнює отриманий результат з зазначеним в завданні.

    У першому і третьому випадках перевіряється вміння читати програму, в другому - писати.

    Предметною областю, для якої складаються алгоритми і формулюються умови програм, є, як правило, абстрактні об'єкти: масиви, матриці, рядки і т.п. Саме на таких об'єктах вивчаються типові завдання на алгоритмізацію.

    Простий спосіб генерації програм, пропонованих студенту, - заміна імен змінних і об'єктів програми. Трохи складніше варіювати алгоритм шляхом заміни кін-

    трукцій, наприклад заміна циклу типу «for» на тип «while». Великі можливості з'являються, якщо програму зберігати у вигляді синтаксичного дерева, на якому можна проводити еквівалентні перетворення, а потім генерувати програму.

    Принципи організації перевірки контрольних завдань з дисципліни програмування підходять і для інших дисциплін, наприклад, дисциплін по базах даних, в яких вивчається мова SQL. Роль програми грає SQL-запит, даних - набір таблиць (база даних), а результат виконання програми - результуюча таблиця.

    Розглянемо розроблені нами дві близькі системи для підготовки контрольних завдань і проведення тестування для дисципліни «Бази даних» (БД) з теми «Мова запитів SQL». Перша система реалізована як web-додаток, що дозволяє формувати БТЗ одночасно кільком викладачам.

    Обидві системи використовують наступну технологію для створення бази тестових завдань.

    Підготовка тестового матеріалу:

    • визначити предметну область для формування бази даних;

    • визначити інформаційні потреби і обмеження;

    • спроектувати БД в 3-й нормальній формі і згенерувати її в заданій СУБД;

    • виходячи з складності курсу, визначити безліч запитів і реалізувати їх на SQL;

    124

    • протестувати реалізовані запити на тестових варіантах.

    На даний момент створені десятки предметних областей - основ для «базових» завдань. Опис БД для кожної предметної області створюється у вигляді SQL-скрипта, який може динамічно виконуватися як на етапі підготовки БТЗ, так і на етапі тестування. Для кожної БД створюється кілька завдань у вигляді формулювання запиту до БД на природній мові і на мові SQL.

    Для поповнення БТЗ та перевірки коректності опису БД і запитів створено окремий web-додаток, який використовується і викладачами, і студентами. У додатку автоматично формується екран з кнопками «створити БД» і кнопками для виконання запитів «1 run», «2 run» і т.д. (Рис. 1). За радіокнопку «SQL» і «текст» в правій частині форми відображаються скрипти створення БД і опису завдань відповідно, які можуть редагуватися.

    При виконанні запиту на екран видається його формулювання, відповід-

    ний SQL-запит, результат запиту у вигляді таблиці, а також вміст беруть участь в запиті таблиць (рис. 2).

    За створеної таким чином БТЗ надалі проводяться контрольні заходи.

    Розглядаються два основних типи завдань.

    1. Студенту, як і описувалося раніше, пропонується скласти SQL-запит по заданій формулюванні природною мовою і по заданій БД. Для перевірки відповіді система динамічно генерує БД, виконує SQL-запит, введений студентом, виконує SQL-запит, наявний в БТЗ, і порівнює результати. Завдання спрощується, якщо студенту запропонувати ввести тільки частину запиту.

    2. Студенту пропонується заповнити таблицю результату запиту по заданому SQL-запиту. На екрані відображаються значення вихідних таблиць і SQL-запит. Для перевірки відповіді система динамічно генерує БД,

    Запити SQL itixi Додати ТешБіи данник Я) ик MnpocosSOl

    29 Кнмопрогат

    25 Пара-Аудитор «я-Ев ** ку _4 П роду рр-Б людо-Рецелт 14 Кліект-банк-Вялад

    30 Продам г: омпь *>теров 10 УчвнмК'Кру жо * -Заняття

    24 Студемт-8ід_спорга-У№ечеш *

    26 День недегм-ДіСф «пл№ * а-Заняття

    ?SESE2ЕЕ

    I-7 '

    113 г

    I 7 Автомобмль-Зевод-випус «113 Паціант-врамя-Лікування

    створити БД

    1 run Вивести розклад Хютте для грліп

    2 ru> розташувати групи > порядку \ -меньшеік * числа студентів

    3 run Підрахувати кількість груп учнів з різних напрямків

    4 rut Знайти групи, яким читають предмет "Баш даних" до час цих зднятнй

    5 run Вивести список аудиторій. в яких менше 20 посадкових місць і є мультимедіа

    Мал. 1. Екран контролю правильності тестових завдань

    125

    Мал. 2. Результат виконання запиту

    виконує SQL-запит і порівнює з тим, що ввів студент.

    У першому випадку перевіряється вміння вирішити задачу, в другому - вміння проаналізувати рішення. Це різні вміння, кожне з яких потрібно в практичній роботі програміста.

    Проведення контрольного заходу:

    • студент реєструється в системі;

    • самостійно або за вказівкою викладача вибирає предметну область;

    • автоматично або від викладача отримує варіант завдання;

    • вирішує завдання на SQL, вносить отриманий запит в систему і отримує результат;

    • отримує з системи правильну відповідь;

    • спільно з викладачем візуально порівнює результат і відповідь;

    • якщо вибірки семантично еквівалентні, завдання вважається зарахований, робота закінчується, в іншому випадку збільшується лічильник підходів, і завдання вирішується повторно;

    • якщо кількість підходів перевищує критичний рівень, завдання вважається незачтённой, робота закінчується.

    Тут потрібно невеличкий коментар, пов'язаний з перевіркою результату. В описі проведення контрольного заходу йдеться про візуальному порівнянні результатів, а в описі типів завдань - про автоматичне. Автоматичне порівняння результатів - не така проста задача, хоча і здійсненне. Тому для складних запитів на практиці зручніше подивитися на результат і оцінити його, а для простих краще порівнювати автоматично. Найпростіший ознака помилки - різний обсяг вибірки в результаті і відповіді.

    Різноманітність варіантів завдань забезпечується переходом від фіксованих формулювань до параме-трізірованним шаблонами, за якими генератор формує унікальні завдання. Простий спосіб генерації варіантів - випадкові розміри таблиць в базовому завданні. Тут необхідно тільки стежити за відповідністю

    126

    пов'язаних таблиць, а також за збереженням деякого числа записів, від яких залежать запити. Це дотримання цілісності можна спростити, якщо після вибору випадкових значень перевіряти коректність запитів. При цьому деякі запити можуть бути відкинуті (забраковані).

    Іншим способом генерації є зміна вмісту таблиць. Для певних полів записи створюються таблиці можливих значень, наприклад, список прізвищ FIO. Шаблон додавання інформації представляється в параметризрвані вигляді, наприклад:

    INSERT INTO Groups values ​​([1-3],

    'ПІ' + id, 3, {20-30}, dm = {FIO});

    Тут значення «[1-3]» показує, що згенерує три команди для вставки записів зі значеннями першого атрибута від 1 до 3. Конструкція «{20-30}» - генерація випадкових значень в діапазоні від 20 до 30. Якщо значення атрибута символьне , вказується ім'я домену - заздалегідь створеного довідника значень, наприклад прізвищ.

    Генерація вмісту БД (тестових завдань) може проводитися як одноразово при створенні БТЗ, так і безпосередньо при проведенні контрольного заходу. Перший варіант використовується при груповому контролі, другий - при індивідуальному або при самоконтролі. У будь-якому випадку при генерації може виник-

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

    На наступних малюнках представлена ​​друга система, реалізована як звичайна програма на базі Foxpro. Сценарій використаний той же.

    Наприклад, викладач визначає предметну область «Екзаменаційна відомість», опис якої наводиться в першому полі. Потім задається структура БД, яка використовується для генерації. За кнопці «Додати» створюється БД і додається в репозиторій (рис. 3). Потім для обраної предметної області викладач формулює запити і реалізує їх на SQL (рис. 4).

    Завантаження тестових даних проводиться або виходячи з характеру запитів, або масово, для більшої кількості варіантів.

    Мал. 5 і 6 демонструють процес вирішення завдання студентом. В даному випадку обидва рішення є помилковими. Вірна відповідь видається після натискання кнопки «Відповідь».

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

    127

    Мал. 3. Викладач визначає предметну область і створює БД

    Запити і рішення • »=: LH)

    База даних Екзаменаційна відомість * ^ J Номер запиту t8 Текст затооса

    Алфавішин список боржників дпя кожної групи і кожної дисципліни (основа • допоптгтельно »відомості)

    текст відповіді

    Select Dtstricl name_stud As Студент, StiKfent group As Група, branch As Дісцпппіне. From Student, Mark, List. Branch; Where (mark is null or mark < 3); and Mark id_stud - Student id_stud; and Mark numjist = List numjist; and List id_branch = Branch >d_branch; Order By branch, Student group, namestud

    Додати: Видалити Стерти все]

    J Вперед Назад | В кінець На початок |

    Мал. 4. Викладач готує завдання

    128

    Мал. 5. Студент вирішує завдання. Помилка: у списку таблиць не вказано List

    Мал. 6. Студент вирішує завдання. Змістовна помилка: не враховано не з'явилися студенти: в умови замість (mark is null or mark<3) задано mark<3

    129

    ність, яка, увійшовши у звичку, ускладнить професійну роботу майбутнього програміста, а тестування перевіряє лише наявність відомостей, а не вміння. І дуже важливо те, що пропонована технологія істотно знижує трудомісткість підготовки матеріалу до контрольних заходів, дозволяє проводити контроль в умовах, схожих на виробничі, і не викликає суперечок і випрошування оцінки: «Ну я ж майже правильно все зробив! ..» А тут система об'єктивно приймає рішення, і питань немає.

    Зауважимо, що подібний підхід годиться і для таких дисциплін, як програмування. Тут роль SQL-запитів грає програма, умова - це формулювання завдання, а тестові варіанти готуються навіть простіше. У режимі самопідготовки студенту може додатково пред'являтися коректне рішення (рис. 7),

    але потрібно, щоб він розумів, що воно зазвичай не єдине.

    Подібний підхід застосовувався одним з авторів і для дисципліни «Спеціальні розділи програмування» на тему «Кінцеві автомати та регулярні граматики» [8].

    Повертаючись до проблеми підготовки якісних програмістів, можна сказати, що, звичайно, так просто її не вирішити, необхідний комплексний підхід, який зачіпає практично всі дисципліни з цього напрямку. Але навіть такі відносно прості рішення дозволяють помітно поліпшити розуміння предмета, рівень володіння нею, а часом і викликають до нього додатковий інтерес, про що свідчать роботи [9, 10], виконані спільно зі студентами. І, звичайно, економія часу викладача на рутинні дії дає можливість більше працювати зі студентами.

    Мал. 7. Самопідготовка до іспиту з програмування на 1-му курсі

    130

    ЛІТЕРАТУРА

    1. Терехов А.Н. Технологія програмування. - М .: Інтернет-Університет Інформаційних Технологій; БИНОМ. Лабораторія Знання, 2006..

    2. Стандарти: ISO / IEC 25010: 2011 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models ДСТУ ISO / IEC 25010-2015 Інформаційні технології. Системна і програмна інженерія. Вимоги та оцінка якості систем і програмного забезпечення (SQuaRE). Моделі якості систем і програмних продуктів.

    3. Купер А. Психбольница в руках пацієнтів. - СПб: Символ-Плюс, 2004.

    4. Платт Д. Софт - відстій! І що з цим робити? - СПб: Символ-Плюс, 2007.

    5. Гласс Р. Факти й омани професійного програмування. - СПб: Символ-Плюс, 2008.

    6. Лукін В.М., Чернишов Л.М. Технологія контролю знань студентів з дисциплін програмування. Матеріали XX Міжнародної конф. по вирахував. механіці і сучасна. прикладним програмним системам, Алушта. - М .: Изд-во МАІ, 2017. - С. 785-787.

    7. братчиків І.Л. Генерація тестових завдань у експертно-навчальних системах / І.Л. Братчиків // Вісник РУДН. Серія «Інформатизація освіти» - 2012. - № 2.

    8. Чернишов Л.М. Програма-тренажер з теорії формальних мов і кінцевих автоматів. / Тези доповідей Міжнародної конференції з обчислювальної механіки і сучасним прикладним програмним системам. - М., 2013 (ВМСППС), Алушта, Крим, 2013, - М .: Вузівська книга, 2013. - С. 862-863.

    9. Рижов А.А., Чернишов Л.М., Булигін А.С. Система автоматичної перевірки відповідей. / Дванадцята конференція «Вільне програмне забезпечення у вищій школі»: Матеріали конференції / Переяславль, 27-28 січня 2017 року. - М .: Basealt, 2017. - С. 22-24.

    10. Махлай В.С., Чернишов Л.М. Web-додаток для проведення контрольних і практичних робіт з програмування з автоматичною генерацією завдань. / Десята конференція «Вільне програмне забезпечення у вищій школі»: Тези доповідей / Переяславль, 24-25 січня 2015 року. - М .: Альт Лінукс, 2015. - С. 86-88.


    Ключові слова: КОНТРОЛЬ ЗНАНЬ / ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ / ГЕНЕРАЦІЯ КОНТРОЛЬНИХ ЗАВДАНЬ / БАЗИ ДАНИХ

    Завантажити оригінал статті:

    Завантажити