Захист даних в інформаційній моделі модуля "Кафедра" автоматизованої інформаційної системи університету

Размещено на http://allbest.ru

Національний технічний університет України «Київський політехнічний інститут імені Ігоря Сікорського

Захист даних в інформаційній моделі модуля «кафедра» автоматизованої інформаційної системи університету

Леонід Гальчинський кандидат технічних наук, доцент,

доцент кафедри інформаційної безпеки

Максим Стурчак здобувач вищої освіти

Фізико-технічного інституту

м. Київ, Україна



Анотація

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

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

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

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

За оцінками українських та закордонних дослідників освітній сектор за рівнем інформаційних загроз посідає одне з перших місць. Зазначено, що захист даних слід враховувати через ролі на базі RBAC (Role Base Access Control), політика якого є більш гнучкою.

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

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



Вступ

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

Аналіз останніх досліджень і публікацій. Розробка і впровадження інформаційних систем ЗВО має досить довгу і складну історію. Ідея впровадження комп'ютерних технологій у громадську сферу, насамперед в бізнес, яку сформулювали розробники першої електронно-обчислювальної машини ENIAC Моучлі та Еккерт ще у 40-х роках двадцятого століття, через двадцять років зусиллями відомої фірми ІВМ трансформувалась в концепцію MIS (Manager Information System). MIS - це комп'ютерна система, яка використовується для збору та зберігання інформації, з інструментами для її аналізу, контролю проведення операцій та прийняття обґрунтованих бізнес-рішень керівництвом. Успішні впровадження MIS були завдячені насамперед вдалому застосуванню для бухгалтерського обліку. Обчислення даних і зведення їх у звіти тепер можна було зробити значно легше та більш оперативно. Технологія передбачала мейнфрейми третього покоління, як-от IBM 360. Мовами розробки були Assembler, Fortran, COBOL. Концепція впровадження MIS почала швидко проникати в інші сфери життя США, зокрема і в університетську сферу. Поширення MIS стало загальносвітовим трендом, що змусило тодішнє керівництво Радянського Союзу започаткувати широкомасштабну програму розробок і впроваджень автоматизованих систем управління у всіх сферах життя, зокрема і в освітній сфері. Проте успіхи цієї програми були доволі скромні.

У 1970 - 80-тих роках було проведено роботу зі створення автоматизованих інформаційних систем. Силами НДІ ВШ СРСР було розроблено комплекс програм, відомий під назвою «АСУ ВУЗ». Цей комплекс централізовано впроваджувався в ЗВО країни, що мали найбільший технічний та інтелектуальний потенціал. Загалом понад 50 закладів вищої освіти брали участь у цьому проєкті. Упродовж 70 - 80 років розробки автоматизованих систем управління поширювались на інші заклади вищої освіти, проте важко стверджувати, що вони якось суттєво сприяли підвищенню якості навчального процесу, особливо якщо зважати на витрати на їх розробку. Про модуль «Кафедра» тоді взагалі не йшлося як з технологічних, так і з фінансових причин.

Революція персональних обчислень, яка відбулась у сфері вищої освіти на початку 90-х років автоматично не призвела до зміни на краще, особливо якщо врахувати, що ЗВО України опинились у важкому фінансовому стані. Про централізоване фінансування питання взагалі не йшлось, однак розробки інформаційних систем для ЗВО велись в ініціативному порядку на нових апаратних засобах та програмних технологіях в парадигмі клієнт-серверної архітектури. Власне саме такий стан відзначають дослідники на початок 2010-х років [1] - [3]. Це був необхідний етап розвитку інформаційних систем, який потребував від розробників значних зусиль в опануванні принципово новими технологіями ІТ, коли стало можливо реалізувати інформаційну систему на засадах розподілених обчислень. Однак, як справедливо зазначав один з провідних експертів О. Співаковський [4], усі ці системи мали характер автоматизованих систем управління підприємством (АСУП), у яких практично ігнорувались особливості основного процесу ЗВО - академічного навчального процесу. Ряд дослідників зробили внесок у розуміння ролі саме освітнього процесу для розробки інформаційних систем ЗВО. Так, на думку М. Топузова [5], щодо побудови інтегрованих рішень для сфери освіти в умовах розвинутого інформаційного суспільства необхідні концептуальні підходи до побудови smart-університету (розумного університету) та smart-закладів освіти та середовищ їх функціонування, що базуються на принципах Social-Mobile- Access-Regulated-Technology.

У дисертаційному дослідженні В. Гриценка [6] дано теоретичне узагальнення і показано практичне розв'язання наукової проблеми обґрунтування теоретико-методичних засад проєктування та впровадження інформаційно-аналітичної системи управління університетом.

У статті В. Бикова, А. Гуржія та М. Шишкіної [7] визначено базовий поняттєво - термінологічний апарат і принципи формування хмаро-орієнтованого середовища закладів вищої освіти; розкрито особливості створення інформаційно-аналітичних інструментів підтримки науково-освітньої діяльності, зокрема хмаро-орієнтованих сервісів науково-освітніх інформаційних мереж та ін.

У роботі С. Лондара [8] проаналізовано тенденції розвитку освітніх інформаційно - аналітичних систем (EMIS). Систематизовано класифікацію інформаційних систем (ІС) ієрархічного типу, у яких ідентифікація ієрархічних рівнів здійснюється за типами рішень, складом управлінського персоналу та видів інформації, що опрацьовується для різних владних рівнів або рівнів організації. Показана корисність закордонного досвіду для розвитку сучасних освітніх інформаційних систем в Україні.

Слід відзначити вклад закордонних учених у сфері інформатизації освіти. Зокрема в роботі K. S. Sastry Musti [9] розглянуто різні аспекти AIS, як-то вимоги, розробка, тестування, загальна безпека тощо. Проаналізовано два основних варіанти розвитку AIS: розробку з нуля та розгортання комерційно доступного програмного рішення. Показано типові стратегії управління в боротьбі з можливим опором з боку користувачів і ефективного обслуговування ширшої спільноти користувачів. Наведено вагомі аргументи на користь власної розробки AIS для зменшення початкових витрат і витрат на технічне обслуговування. Важливо, що детально представлено дизайн, розробку функціонального прототипу та загальні аспекти безпеки, надано рекомендації щодо розв'язання операційних проблем за допомогою добре відомих практик. освіта цифровизація інформаційний шифрування

Метою дослідження M. N. Habib та його колег [ 10] було визначити, що розуміють під автоматизацією закладів вищої освіти (ЗВО), і оцінити автоматизований процес з точки зору розвитку країни на основі вивчення функціонування інформаційної системи пілотного університету Пакистану. Дослідження показали в цілому позитивний потенціал інформаційної системи, насамперед цю оцінку підтвердило функціонування університету під час пан епідемії COVID-9.

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

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

Проведений В. Гужвою в [12] аналіз наявних ІС для управління ЗВО в Україні свідчить про вибіркові напрями діяльності університетів для автоматизації окремих функцій. Проте на вітчизняному ІТ-ринку існує значна кількість розробок інформаційних систем для ЗВО, що помітно відрізняються за програмними рішеннями, повнотою засобів для автоматизації освітнього процесу, наборами програмних компонент. Серед найбільш поширених з них варто виділити наступні, які суттєво відрізняються масштабами впровадження:

- АСУ «Вищий навчальний заклад» - розробник Науково-дослідний інститут прикладних інформаційних технологій. Основними компонентами програми є: «Приймальна комісія», «Деканат», «Студмістечко». Додатковими можна обрати «Тест», «Конструктор звітів», «Менеджер резервних копій», «Веброзклад», «Вебкабінет студента», «Система контролю доступу».

- АСУ «Університет» - розробник ТОВ «UNITEX+» Автоматизована система управління закладом вищої освіти (ЗВО) III - IV рівня акредитації, складається з автономних модулів: структура ЗВО, вебсайт ЗВО, навчальна частина, кафедра, навчальний розклад, абітурієнт, документообіг ЗВО, деканат, кафедра, вчені ради ЗВО.

- пакет комп'ютерних систем 1111 «Політек-софт». Пакети програм «Колоквіум», «Бібліограф», «ПС-Персонал».

З іншого боку за останнє десятиліття помітна суттєва тенденція створення систем і окремих модулів інформаційних систем власними силами університетів. Зокрема слід назвати:

- Автоматизовану інформаційну систему «Електронний кампус КПІ ім. Ігоря Сікорського (система ЕК)»;

- Автоматизовані системи управління навчальним процесом закладу вищої освіти, розроблені власне закладами вищої освіти (електронну систему управління «Сократ» Вінницького національного аграрного університету);

- АС «Університет» - розробник Херсонський державний університет;

- ІАС управління університетом - розробник Черкаський національний університет імені Богдана Хмельницького;

- Автоматизовану інформаційну систему «Електронний університет», створену в Хмельницькому національному університеті [13].

Характерною рисою університетських розробок є посилена увага до інформатизації саме навчального процесу. Судячи з опублікованих даних, не всі ці розробки передбачають окремий модуль «Кафедра». Автори статті поділяють погляди розробників Хмельницького національного університету, що такий модуль має бути як обов'язковий компонент інформаційної системи ЗВО. Більше того - він має відігравати ключову роль для інформаційної системи навчального процесу, бо саме кафедра безпосередньо реалізує освітній процес в університеті. Про необхідність модуля «Кафедра» вказується [14] на необхідність його розробки з метою функціонування пов'язаного із забезпеченням документів:

Навчальний план є основним нормативним документом, що визначає організацію навчального процесу:

- Форма № 1. Заповнюється для планування та обліку навчальної роботи науково-педагогічних працівників університету за чвертями та і семестрами.

- Форма № 2. Містить інформацію про види та обсяги навчального навантаження кафедри по семестрах і на навчальний рік залежно від форми навчання студентів.

- Форма № 3. Містить інформацію про навчальне навантаження викладачів кафедри з урахуванням їх посади (професор, доцент, старший викладач, асистент), ставку та переваги при викладанні тих чи інших курсів.

- Форма № 4. Інформація про навантаження викладачів. ЇЇ джерело - Форма № 3 за місяцями, семестрами і за рік.

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

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

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

Таблиця 1

Зарубіжні рішення ІС для ЗВО

Назва системи	Вендор	Характеристики
Salesforce.org Education Cloud	Salesforce	Забезпечує хмарну платформу, яка підтримує управління та залучення студентів, їх прийом і навчання, а також інші функції адміністративної підтримки закладів вищої освіти.
AppsAnywhere	AppsAnywhere	AppsAnywhere -- це платформа для доставки програмного забезпечення, яка надає студентам і співробітникам доступ до програмного забезпечення, необхідного для роботи, де б вони не були, як на кампусі, так і за його межами.
SAP for Higher Education and Research	SAP SE	SAP for Higher Education and Research -- це набір масштабованих взаємопов'язаних програм, розроблених для підтримки різноманітних потреб закладів вищої освіти, як-от: управління життєвим циклом студентів, навчання та управління доходами, управління грантами та дослідженнями, планування досліджень
Blackboard Learn	Blackboard Inc.	Остання версія, Blackboard Leam 9.1, була випущена в квітні 2010 року. Це система управління навчанням, яка забезпечує навчання та управління навчальними закладами; спільнота та система порталу для спілкування; система управління контентом для централізованого контролю змісту курсу; система для запису та аналізу результатів оцінювання студентів.
Tk20	Watermark	Tk20 від Watermark -- це система оцінювання та керування даними на основі підписки, яка надає студентам безпечну платформу для подання різноманітних оцінок, які використовуються для вимірювання їх академічної успішності та професійного зростання. Система Tk20 також надає персоналу платформу для введення даних, ведення записів і надання студентам належного та своєчасного зворотного зв'язку.

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

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

Проте рівень кіберзагроз невпинно зростав, і сектор освіти та досліджень вийшов на одне з перших місць за рівнем кібератак вже у 2020 році, а в наступні роки ця тенденція тільки посилилась, що це фіксують науковці [16], [18], [19]. Згідно з дослідженням Check Point Software Technologies, у 2021 році головними цілями кібератак були освіта та наукові дослідження: у середньому на організацію було зареєстровано 1605 атак на тиждень, що на 75% більше, ніж у 2020 році. Пандемія COVID-19 змусила співробітників підприємств і освіти працювати вдома. Потреба в цифрових навичках та онлайн-курсах сприяла розвитку ринку цифрової освіти, створюючи можливості для навчання, а також створюючи можливості для кіберзагроз.

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

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



Результати дослідження

Питання про систему кіберзахисту для модуля «Кафедра», на наш погляд, треба передбачати вже на рівні проєктування, а не шукати засоби захисту після того, як програмне забезпечення розроблене і запущене в експлуатацію.

Те саме стосується і забезпечення потенційної можливості забезпечення інтеграції з готовими LMS системами, такими як Moodle. Ця задача не суперечить задачі інформаційної безпеки, однак вона не є предметом даного дослідження.

Відтак треба починати з інформаційної схеми модуля і передбачити можливість усунення можливих вразливостей ще на рівні інформаційної схеми. Це буде означати уникнення вразливостей на рівні бази даних, яка забезпечує функціонування модуля «Кафедра».

Інформаційна схема кафедри ЗВО

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

Оскільки представлені у відкритих джерелах, зокрема [19], [20] ER-моделі предметної області кафедри мають вкрай спрощений характер, нижче розглянемо побудову такої моделі, яка може послужити прототипом для модуля «Кафедра».

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

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

Спочатку виділимо виконавців, які беруть участь у навчальному процесі:

- Завідувач кафедри

- Заступник завідувача кафедри

- Секретар кафедри

- Декан

- Заступник декана

- Викладач

- Куратор

- Студент

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

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

Заступник декана

- Керує деканатом.

- Проводить відбір студентів на вибіркові дисципліни.

Деканат

- Регламентація роботи кафедри.

- Моніторинг заходів контролю навчального процесу.

- Формування груп.

- Визначення списків потоків навчальних дисциплін.

Завідувач кафедри

- Визначення освітніх програм.

- Контроль освітнього процесу викладачами кафедри.

- Делегування обов'язків заступникам.

- Делегування повноважень менеджерам за напрямами.

- Призначення кураторів.

Заступник завідувача кафедри

- Створює списки потоків.

- Робота з вибірковими дисциплінами.

Менеджер-кадровик

- Співпраця з відділом кадрів для забезпечення роботи персоналу кафедри.

- Співпраця з вченою радою факультету при проведенні конкурсів викладачів.

Менеджер-планувальник

- Аналіз викладацького складу.

- Робота з даними про фінансування кафедри.

- Розробка навантаження на викладачів на основі навчального плану кафедри.

Менеджер-диспетчер

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

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

- Забезпечення ректорського контролю.

Викладач

- Викладає дисципліну.

- Розробляє нормативно-методичні документи дисциплін.

- Проводить заняття згідно з розкладом.

- Проводить оцінювання в поточному контролі.

- Проводить оцінювання в календарному контролі.

- Проводить оцінювання студентів в сесії.

- Проведення занять за визначеними дисциплінами.

- Спілкується зі студентами.

- Виконує доручення на розміщення нормативних документів.

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

Студент

- Входить до складу групи.

- Вивчає дисципліни.

- Складає іспити та заліки.

- Взаємодіє з викладачами.

- Робить вибір з набору вибіркових дисциплін.

- Взаємодіє з куратором групи.

- Бере участь у ректорських контролях.

Куратор: Куратор є викладачем, який має виконувати наступні завдання:

- Проведення виховних заходів.

- Забезпечення розробки індивідуальних планів студентів.

- Забезпечення участі студентів групи у ректорському контролі.

- Взаємодія на звернення студентів.

- Взаємодія з деканатом для розв'язання питань студентів групи.

Всі ці описані виконавці є неодмінними суб'єктами в концептуальній моделі «Кафедра». Крім того, необхідно додати суб'єкти «Група» та «Контроль».

Група: Групи можуть бути навчальними та віртуальними. Кожен студент є членом певної навчальної групи та одночасно може бути у складі декількох віртуальних груп залежно від обраної дисципліни за вибором студента. Статуси цих груп суттєво різні. До навчальної групи студент належить з моменту вступу або переводу і до моменту закінчення терміну навчання або вибуття з різних причин. У віртуальній групі студент перебуває впродовж одного семестру залежно від його вибору.

Контроль

- Календарний контроль.

- Поточний контроль.

- Ректорський контроль.

Освітня програма

- Розділ освітньої програми.

- Навчальна дисципліна.

Навчальна дисципліна

- Назва.

- Розділ освітньої програми.

- Кількість кредитів.

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

Таблиця 2

Відповідність суб'єктів предметної області ER- суб'єктам

Суб'єкти предметної області	ER-сутність
Завідувач кафедри	Zav kaf(ID, ID Dep, name, surname, patronymic, pos, academic rank, auth id)
Заступник завідувача кафедри	Dep zav kaf(ID, ID DepC, name, surname, patronymic, pos. academic rank, auth id)
Заступник декана	Dep dean(ID, ID DepD, name, surname, patronymic, pos, academic rank, auth id)
Потік студентів, що відвідують лекції з навчальної дисципліни	Stream(ID, ID student, group id name, surname, patronymic,numst stream)
Заступник декана	Dep dean(ID,ID Fac, pos, name, surname, patronymic, academic rank, auth id)
Менеджер з кадрових питань	Personner (ID, pos, name, surname, patronymic, passport, TIN, auth id)
Менеджер, що планує навантаження	Planner (ID, pos, name, surname, patronymic, passport, TIN, auth id)
Менеджер, що складає розклад занять	Dispatcher(ID, pos, name, surname, patronymic, passport, TIN, auth id)
Штатний розклад кафедри	Org staff (ID, Id Caf, pos, salary)
Навчальний план спеціальності	Ed plan(Nam plan, level, ID Ed, name о sec, Id sub, cred,
Університетський викладач	University teacher(teach ID, pos, academic rank, name, surname, patronymic, passport, TIN, auth id)
Лектор	Lector(ID, pos, comp,name, academic rank, surname, patronymic, passport, TIN, right,auth id)
Асистент	Assistant(ID, pos, comp, academic rank, name, surname, patronymic, passport, TIN, right, auth id)
Індивідуальний план викладача	Ind UT plan(ID, pos, academic rank, name, surname, patronymic, ID sub, load sub, ID sub, other load)
Студент	Student(ID stud, ID Group,ac sub,name, surname, patronymic, b day, auth id)
Індивідуальний план студента	student load (ID stud, Id spec,name, surname, patronymic, numb sem, sub name)
Навчальна група	Group(ID vgr, ID sub, ID stud, course)
Віртуальна група	Virt groupe(ID vgr, ID stud, name ac sub)
Розклад	Les schedule (teach ID, pos, day, week, name, Id educator)
Ректорат	Rectorate (ID dep, dep name, data, auth id)
Ректорський контроль	Rect control (ID rc ID stud, b time, e time, ID vgr data, b time, e time, test, test result)
Поточний контроль	Curr control(group id, ID stud, data, b time, e time, name ac sub, var control, lect ID, mark)
Календарний контроль	Cal control(group id, ID stud, data, name ac sub, var control, UT ID,result)
Деканат	Dean office (ID, pos,name, surname, patronymic, auth id)
Фонд заробітної плати	Sal pay fund (ID fin, Id dep, num, position,salary)
Відповідальний за документацію(секретар)	Dep secretary (ID, pos, name, surname, patronymic, passport, TIN, auth id)
Куратор групи	Gr Curator (ID, group id, position, name)
Освітня програма	Ed program (ID Ed, name ac sub, study load, quan cred, Sec of ed program)
Розділ освітньої програми	Sec of ed program (part id, name о sec, num sub, name ac sub)
Навчальна дисципліна	Subj (Id sub, part id,subj name, t avt, cred)

Спрощена ER-діаграма(атрибути суб'єктів виписані в Таблиці 1. представлена на Рис. 1) показує семантику навчального процесу, який реалізує кафедра. Дана схема потребує деталізації, деякі аспекти діяльності кафедри в цій схемі не показані, проте основні питання інформаційного забезпечення діяльності кафедри висвітлені. У представленій роботі важливим питанням було забезпечення інформаційної захищеності модуля «Кафедра».

Інформаційна схема «Блок оперативного управління» у контексті рольової політики доступу до даних

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

Тому короткий опис суб'єктів і зв'язків має такий вигляд:

Викладач викладає дисципліну. До суб'єкту «викладач» належить дві ролі - лектор і асистент, задачі яких суттєво відрізняються.

Лектор читає лекції, може вести практичні заняття, оцінювати студентів у поточному контролі, під час сесії та в календарному контролі. Асистент може оцінювати студентів лише в календарному контролі.

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

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

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

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

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

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

Обов'язковий контроль доступу (MAC).

Дискреційний контроль доступу (DAC).

Рольовий контроль доступу(RBAC).

Обов'язковий контроль доступу (MAC): дозволи обробляються системою, а не власником об'єкта.

При дискреційному контролі доступу об'єктам у цих системах присвоєні маркери безпеки, що визначають, хто має до них доступ. Маркер містить необхідний рівень допуску, який часто коливається від несекретних до секретних, таємних, цілком таємних тощо.

При рольовому контролі доступу [21] користувачам надають певні ролі. Його назва походить від принципу, коли користувачу надаються дозволи доступу до об'єктів опосередковано - через ролі Role Base Access Control (RBAC).

Політика інформаційної безпеки RBAC є більш гнучкою, ніж MAC або DAC, що дозволило застосовування для інформаційних систем суб'єктів публічного характеру, зокрема для університетів. Крім того, уніфікована мова моделювання (UML) може використовуватись для визначення політик RBAC для ЗВО. Подібний підхід був запропонований в [22], проте отримана в цій роботі модель забезпечувала доволі вузький спектр освітньої діяльності кафедри.

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

- Плоска модель RBAC.

- Ієрархічна модель RBAC.

- Модель RBAC з обмеженням.

Ієрархії є природним засобом структурування ролей для відображення лінії повноважень і приналежності до організації. На наведеній схемі в кружечку вписано RH, що показує наявність ієрархії.

Рис. 2. Схема ієрархічної RBAC [21]

На Рис. 2 показані компоненти ієрархічної моделі RBAC.

Основна модель RBAC містить набори з п'яти основних елементів даних, які називаються користувачами (USERS), ролями (ROLES), об'єктами (OBS), операціями (OPS) і дозволами (PRMS).

Модель RBAC у цілому фундаментально визначається з точки зору окремих користувачів, яким призначаються ролі, та дозволи, які призначаються ролям.

Отже, роль є засобом для іменування зв'язків «багато - до - багатьох» між окремими користувачами та дозволами. Крім того, базова модель RBAC містить набір сеансів (SESSIONS), де кожен сеанс є відображенням взаємодії між користувачем і активованим підмножинам ролей, які призначаються користувачеві. При наявності підпорядкування в моделі має бути передбачено ієрархію.

Ієрархія є природним засобом структурування ролей для відображення лінії повноважень і відповідальності в організації. На Рис. 2 наведена схема ієрархічної моделі RBAC.

Рисунок 2 ілюструє призначення користувача (UA) і відносини призначення дозволу (PA). Стрілки вказують на зв'язок «багато-до-багатьох» (наприклад, користувачеві можна призначити одну або кілька ролей, а роль може бути призначена одному або кільком користувачам).

Рівень ієрархічної моделі RBAC експертами[23] - [25] вважається достатнім для визначення рольової політики доступу в публічних організаціях.

Однак за необхідності можна й ускладнювати модель, зокрема шляхом доповнення певними обмеженнями. Стандарт NIST передбачає для RBAC два різновиди: статичні SOD(SSD) - для запобігання конфлікту інтересів, які виникають, коли користувач отримує дозволи, та динамічні SOD - обмеження на ролі, які не можна активувати в межах одного сеансу користувача. Тож Деканат виступає в ролі джерела динамічних SOD, а джерелом статичних SOD виступає Завідувач кафедри.

Для модуля «Блок оперативного управління» набір ролей буде наступним:

- Контроль.

- Викладач.

- Дисципліна.

- Група.

- Студент.

У такому складі джерелом обмежень у модулі є Деканат, оскільки саме він виставляє форми та часові інтервали звітності, а джерелом ієрархії - Завідувач кафедри, оскільки за статутом ЗВО він є безпосереднім керівником викладачів та методистів.

Для обраного нами блоку «Блок оперативного управління» була розроблена ієрархічна модель RBAC згідно із стандартом NIST. З урахуванням ролей набір суб'єктів буде наступний:

Subject (ID_subject, subject_name, lecturer_id, assistant_id, group_id); groups (ID_group, group_name) ;

student_load (ID_load, student_id, sub_id, active);

student(ID_student, student_name, student_surname, student_patronymic, number_scorecard); passport, TIN, group_id, auth_id, course); exams (ID_student_exam, student_id, educator_id, score, exam_date, sub_id, b_time, e_time,active);

auth (ID_auth, user_login, user_password); user_roles (ID_role, auth_id, role_id); roles (ID_role, role_name);

resource_role (ID_resource_role, resource_id, role_id, can_add, can_edit, can_view, can_delete, sub_ID); resource(ID_resources, resources_name);

calendar_control (ID_control, student_id, educator_id, calendar_control_1, calendar_control_2, subject_id);

educator (ID_educator, educator_name, educator_surname,

educator_patronymic, academic_rank, passport, TIN, auth_id);

Subject _score (ID_score, student_id, score_date, score, type_of_control, educator_id, subject_id).

Як можна бачити, базові суб'єкти взяті з загальної моделі модуля «Кафедра» плюс додані суб'єкти для відображення результатів контролю, аутентифікації, а також суб'єкти, які відображають ролі в навчальному процесі.

На схемі, зображеній на Рис. 3, показані всі користувачі (USERS), операції (OPS), які ці менеджери можуть виконувати з різними об'єктами (OBS) в моделі, для різних етапів навчального процесу, зокрема календарного та поточного контролю сеансів (SESSIONS). Далі необхідно отримати інформаційну схему для обраного прикладу із врахуванням рольової моделі доступу.

Однак розробників більше цікавить не сама по собі ER-модель, а реляційна схема, на основі якої проєктується база даних. Сучасні засоби розробки СУБД мають у своєму розпорядженні інструменти, які дозволяють будувати реляційні схеми з урахуванням вимог RBAC не тільки базової моделі, але й більш ускладнених. Такі можливості має широко відома і популярна СУБД MySQL.

Рис. 3. Ієрархічна модель рольового доступу для «Блоку оперативного управління»

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

На Рис. 4 показано приклад візуального дизайну бази даних в MySQL із врахуванням ролей:



Рис. 4. Схема бази даних із врахуванням ролей в MySQL

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

Рис. 5. Схема реалізації ієрархічного відношення в MySQL



Наступним кроком має бути розробка прототипу програмної реалізації «Блоку оперативного управління».

Реалізація прототипу вебзастосунку «Блок оперативного управління»

Як вище зазначалось, з точки зору сучасних ІТ-технологій модуль «Кафедра» має бути реалізований як вебзастосунок.

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

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

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

На Рис. 6 показана відповідна реляційна схема. Як інструмент розробки була обрана СУБД MySQL як така, що задовольняє багатьом критеріям обробки та захисту даних.

Зокрема в ній наявні вбудовані функції безпеки, як -то автентифікація та авторизація користувачів, шифрування даних та інших. Крім того, як вже зазначалось, у складі СУБД MySQL є утиліта, яка дозволяє реалізовувати рольовий доступ до даних вже на етапі проєктування. Функціонування застосунку потребує наявності двох серверів: сервера розподіленої бази даних та вебсервера, які взаємодіють між собою для обробки запиту користувачів.



Рис. 6. Реляційна схема в контексті RBAC для вебзастосунку «Блок оперативного управління».

Створення прототипу модуля «Блок оперативного управління» як вебзастосунку потребує ретельної розробки зовнішнього вигляду сторінок. Дизайн вебзастосунку - це ключ до створення гарного користувацького досвіду та успішної присутності в Інтернеті.

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

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

- Неавторизований користувач бачить лише попередню сторінку і може лише авторизуватися. Ніякі інші функції йому не доступні.

- У методиста немає можливості переглядати Контроль.

- У студента не відображаються кнопки дії з оцінками.

Студент за моделлю RBAC не має редагувати файли, бо це створює зайве навантаження на сервер, тому необхідно реалізувати показ лише потрібного контенту даній ролі. Як приклад поточний контроль для викладача і студента має вигляд, проілюстрований на Рис. 7 та Рис. 8 відповідно.

Рис. 7. Результати поточного контролю для викладача

Рис. 8. Результати поточного контролю для студента

У викладача доступні кнопки редагування оцінок. А для студентів такого функціонала не буде. Студент при перегляді поточного контролю не бачить кнопок для редагування оцінок, це зроблено за допомогою показу контенту за ролями. Для розгортання модуля необхідним є використання сервера для вебзастосунку. Це дозволить користуватися вебзастосунком через мережу Інтернет. На наш погляд, одним з функціонально кращих є AWS через свою гнучкість та високу швидкість доступу до інформації для великої кількості даних, які зберігаються, однак вважаємо, що таке рішення мають приймати розробники конкретної інформаційної системи. Для реалізації доступності домену вебзастосунку необхідно використати відповідний сервер, наприклад, Fornex.

Крім цього, для забезпечення стабільної роботи в мережі необхідно ще встановити менеджер процесів Node.js. Один з кращих є PM2 -- це менеджер процесів Node.js із вбудованим балансувальником навантаження. Це допомагає полегшити робоче розгортання та дає змогу безперервно підтримувати запущені програми (навіть якщо трапляються аварії).

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

Показані кроки при створенні вебзастосунку не є вичерпними. Власне і вибір засобів описаних кроків можуть бути видозмінений на розсуд розробників.

Однак модуль «Кафедра» необхідно розробляти з обов'язковою умовою захисту даних, керуючись рольовою політикою безпеки. Тестування застосунку показало цілковиту відповідність потребам користувачів при виконанні умов прав доступу до даних. Наприклад, якщо користувач авторизувався як Студент, то обравши Контроль користувач бачить наступне (Рис. 9):



Рис. 9. Панель Контроль для користувача Студент

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

З інтерфейсу викладача можна побачити схожий функціонал, показаний на Рис. 10.

Рис. 10. Панель Контроль для користувача Викладач

Викладач бачить назву дисципліни та групу, у якій він викладає даний предмет. Група може бути як статична, так і віртуальна. Віртуальні групи слугують для вибіркових дисциплін, коли необхідно об'єднати студентів різних груп в одну. У поточному застосунку це реалізується за допомогою статичних груп, але з'являється проблема захисту даних, коли студенти, які не обирали дисципліну, знаходяться у відомостях і тим самим ускладнюють роботу викладачу. Коли у викладача з'являється необхідність переглянути бали групи або оцінити студентів чи виправити оцінку, він обирає дію та бачить усіх студентів, які вивчають цю дисципліну.

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

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



Висновки та перспективи подальших досліджень

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

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



Список використаних джерел

[1] М. C. Львов, “Тенденції розвитку освітніх інформаційно-комунікативних технологій“, Journal of Information Technologies in Education (ITE), N°. 1, с. 107-114, 2008. https://doi.org/10.14308/ite000014.

[2] Й. М. Петрович, та Ю. М. Римар, “Інформаційні системи управління навчальним процесом у ВНЗ: порівняльний аналіз”, Вісник Львівська політехніка.Логістика, т. 735, с. 167 - 175, 2012.

[3] А. А. Тимченко, та ін., Інформаційно-аналітична система контролю і оцінювання навчальних досягнень студентів ВНЗ: монографія , Черкаси: МакЛаут, 2010.

[4] О. В. Співаковський, “Особливості автоматизованих систем управління вищими навчальними закладами”, Вісник Харківського національного університету. Математичне моделювання.Інформаційні технології.Автоматизовані системи управління, Випуск 3, № 629, с.86 - 99, 2004.

[5] М. О. Топузов, “Проектування інформаційно-освітнього середовища навчальних закладів у

сучасному суспільстві”, Український педагогічний журнал, № 1, с. 26-36, 2017. [Електронний ресурс]. Доступно: https://uej.undip.org.ua/index.php/joumal/artide/view/514/ 444. Дата звернення:20.11.2023.

[6] В. Г. Гриценко, “Теоретико-методичні основи проектування та впровадження інформаційно - аналітичної системи управління університетом”, Дисертація на здобуття наукового ступеня доктора педагогічних наук за спеціальністю 13.00.10 - інформаційно-комунікаційні технології в освіті (01 «Освіта / Педагогіка»), Інститут інформаційних технологій і засобів навчання НАПН України. 2 019. [Електронний ресурс]. Доступно: https://lib.iitta.gov.ua/716524/2/dyser_Hrytsenko.pdf.

[7] В. Ю. Биков., А. М. Гуржій, та М. П. Шишкіна. “Концептуальні засади формування і розвитку хмаро-орієнтованого навчально-наукового середовища закладу вищої педагогічної освіти”, Сучасні інформаційні технології та інноваційні методики навчання у підготовці фахівців: методологія, теорія, досвід, проблеми, Вип. 50. с. 21 - 26, 2018.

[8] С. Л. Лондар, “Міжнародний досвід розвитку сучасних освітніх інформаційних систем”, Освітня аналітика України, т.1, № 5, с. 5-19, 2019. doi:https://doi.org/10.32987/2617-8532- 2019-1-5-19.

[9] K. S. Musti, “Management Information Systems for Higher Education Institutions: Challenges and Opportunities” in Quality Management Implementation in Higher Education, M. Sony, K. Karingada, and N. Baporikar (Eds.), 2020, pp. 110 - 131.

[10] M. N. Habib, U. Khalil, Z. Khan, and M. Zahid, “Sustainability in higher education: What is happening in Pakistan?” Int. J. Sustain. High. Educ. vol. 22, no. 1, pp. 681 - 706, Jan. 2021, doi:10.1108/IJSHE -062020-0207.

[11] J. Khalid, B. R. Ram, M. Soliman, A. J. Ali, M. Khaleel, and M. S. Islam, “Promising digital university: A pivotal need for higher education transformation”, International Journal of Management in Edu cation. vol. 12, no.3, pp. 264 - 275, 2018. https://doi.org/10.1504/ijmie.2018.092868.

[12] В. М. Гужва, “Цифрова трансформація університетів”, Східна Європа: економіка, бізнес та управління, № 4(21), с. 597 - 604, 2019. [Електронний ресурс]. Доступно: http://w ww.easterneurope- ebm.in.ua/joumal/21_2019/92.pdf.

[13] М. М. Косіюк, К. Е. Більовський, та В. М. Лисак, “Автоматизована інформаційна система управління закладом вищої освіти `електронний університет”, ІТЗН, вип. 93, вип. 1, с. 96 - 116, Лют 2023.

[14] С. В. Чернишенко, та Ю. І. Воротницький, Методологічні основи створення, впровадження ірозвитку інтегрованої інформаційної системи управління університетом. Суми: Сумський державний університет, 2015. [Електронний ресурс]. Доступно: http://inure.nmu.org.ua/pdf/methodology_ua.pdf.

...