Full Text

Введение. Высшее учебное заведение как любая государственная или частная организация имеет процессы, которые нуждаются в автоматизации. В большинстве вузов существуют внедренные системы, например, система учета сотрудников в бухгалтерии и отделе кадров, системы по работе со студентами и другие локальные системы. В работе рассмотрен учебно-методический отдел (УМО) вуза в качестве владельца вспомогательных бизнес-процессов вуза, связанных с учебно-методической работой. В ходе анализа протекающих в нем процессов были выявлены следующие проблемные места: 1. Часть основных процессов учебных заведений, связанных с планированием и реализацией основных образовательных программ (ОП), переведена на процессное управление, а большинство вспомогательных процессов в вузе реализуется вручную. 2. В связи с отсутствием общей базы данных по учебно-методическим процессам (УМП) существуют некоторые проблемы, например, действия работников не всегда являются согласованными, происходят задержки в принятии решений или обработке информации. 3. Сотрудники, реализующие учебно-вспомогательные процессы, даже являясь информированными о существовании возможностей автоматизации неких рутинных процессов, все равно ведут работу старыми методами в силу привычки и устоявшихся правил поведения и не используют информационные технологии там, где это поможет сэкономить время и ресурсы компании. Например, сотрудники ведут несколько маленьких баз данных вместо единой, собирают данные только через «присутствие» преподавателей на кафедре вместо дистанционного заполнения онлайн-форм и т.п. Таким образом, информационная система управления (ИСУ) УМП вуза, необходима в силу того, что, во-первых, позволит сократить время сотрудников, затраченное на тот или иной процесс, а во-вторых, повлияет на совершенствование работы вуза в целом. Целью данной работы является выявление особенностей проектирования учебно-методических ИСУ вуза. Статья содержит описание бизнес-процессов УМО, описание акторов системы. Также в статье описан выбор архитектуры и программных компонентов ИСУ для реализации заложенных функций. 1. Особенности проектируемой системы. Процессный подход к управлению, реализованный во многих университетах, ориентирован в первую очередь на бизнес-процессы, «конечными целями которых является создание продуктов или услуг, представляющих ценность для внешних или внутренних потребителей» [1]. Используя один из подходов к классификации процессов организации, были выделены следующие бизнес-процессы университета: основные и вспомогательные, а также бизнес-процессы управления. В основе данной классификации лежат характер деятельности и создаваемый в результате реализации процесса продукт [2]. Учебно-методические процессы являются вспомогательными и обеспечивают качественную реализацию основных процессов университета. Организация УМП в вузе подчиняется жестким федеральным требованиям, которые предъявляет Министерство образования и науки РФ как стратегический стейкхолдер, реализующий определенные цели. Например, Министерство образования и науки РФ заинтересовано в контроле за тем, чтобы во всех государственных вузах выдавались дипломы государственного образца, т.е. соответствовали федеральным требованиям. В связи с этим помимо наличия этих требований они проводят периодические проверки вузов. Таким образом, одной из основных задач университета является своевременная подготовка документов к лицензированию и аккредитации образовательных программ. Чтобы выполнить эти условия, сотрудникам, организующим УМП в вузе, необходимо взаимодействовать с множеством сотрудников различных подразделений, собирать большое количество документов, подписывать их, согласовывать. Данный процесс занимает много времени и требует автоматизации. Более того, вуз - это государственная организация, существующая за счет субсидий из государственного бюджета, поэтому учреждение должно обеспечивать свою деятельность согласно государственным стандартам. Так как многие процессы связаны между собой, соответствие стандартам легче проверяется при налаженной коммуникации между отделами. Данная система позволит собрать всех участников учебно-методического процесса вместе в единую систему [3]. Если рассматривать подробнее внутреннюю организацию учебно-методической работы вуза, то она имеет целью обеспечить участие педагогических, научных работников, представителей работодателей в разработке образовательных стандартов высшего образования, примерных образовательных программ высшего образования, в координации действий подразделений, осуществляющих образовательную деятельность по образовательным программам высшего образования в области экономики и управления, в обеспечении качества и развития высшего образования. Для реализации этой цели организуются заседания учебно-методического совета (УМС). На заседаниях УМС кроме утвержденного приказом состава на добровольных началах могут присутствовать любые педагогические работники и научные работники вуза. Кроме этого хорошая организация УМП подразумевает наличие множества документов и эффективную организацию их оборота среди сотрудников. Поэтому в проектируемой системе необходимо предусмотреть возможность управления документооборотом (именно учебно-методической документации). УМП направлены на организацию методической поддержки учебного процесса с целью подготовки высококвалифицированных кадров, поэтому обеспечение более гибкой модели реализации системы, где «продуктом» является студент, «производителями продукта» - профессорско-преподавательский состав (ППС), а заказчиком - бизнес, - важная стратегическая цель учебно-методического процесса. В нашей системе гибкость подстройки под «производителей» обеспечивается проектированием системы в виде веб-приложения, обеспечивающего возможность реализации УМП в более удобное время и в наиболее комфортном для ППС месте. Дополнительно для ППС в системе необходимо обеспечить возможность удобного предоставления информации в едином месте (о расписании, реализуемых дисциплинах и учебной нагрузке) и возможность загрузки учебно-методических документов (программы учебных дисциплин, фонды оценочных средств, контрольно-измерительные материалы и т.п.) в единое хранилище вуза через Интернет. Это будет преимуществом для держателей учебно-методического процесса, так как позволит более оперативно собирать информацию, контролировать актуальность содержания материалов, преподаваемых студентам, что, в свою очередь, приведет к реализации цели более высокого порядка - выпуску более качественного и современного «продукта», наиболее подходящего для заказчиков [4-10]. Таким образом, были выделены следующие основные УМП вуза: 1. Контроль соблюдения федеральных требований к образованию, разработанных Министерством образования и науки РФ (например, реализация образовательных стандартов по направлениям подготовки). 2. Организация подготовки к лицензированию новых направлений подготовки бакалавриата/магистратуры и аккредитации основных ОП вуза. 3. Администрирование существующей информационно-образовательной среды вуза (далее - LMS), консультирование и техническая поддержка ППС вуза по проблемам, связанным с эксплуатированием LMS. 4. Планирование учебной нагрузки ППС и последующий контроль за распределением учебной нагрузки между факультетами, отделениями и кафедрами. 5. Проверка ведения учебно-методической документации (УМД): рабочих программ курсов, расчета учебной нагрузки на учебный год, протоколов заседаний кафедры, журналов учета лабораторных работ, домашних заданий, курсового проектирования, списка тем дипломных проектов, списка руководителей дипломных и курсовых проектов, расписаний лабораторных работ, приема домашних заданий, проведения консультаций, а также анализ состояния учебно-методической работы в учебных подразделениях с целью разработки предложений по повышению ее эффективности. 6. Администрирование сайта портала вуза с целью осуществления контроля появления учебно-методических и информационных материалов (УММ) для ознакомления ППС и последующее их обновление. 7. Организация и проведение Учебно-методического совета для обсуждения, планирования и реализации концепции учебно-методической работы в вузе. 8. Организация процесса разработки программ учебных дисциплин. 9. Ведение базы данных по программам учебных дисциплин (ПУД), в том числе версий прошлых лет, т.е. архива. 10. Координирование процессов, связанных с реализацией учебно-методических проектов по привлечению студентов к педагогическому процессу (на примере проекта «Учебный ассистент»). После описания учебно-методических процессов вуза были выделены акторы проектируемой системы [11]. Ниже приведены несколько основных акторов: 1. Актор верхнего уровня - проректор. Это стратегический стейкхолдер, который при взаимодействии с государством в лице Министерства образования и науки РФ вырабатывает внутреннюю и внешнюю политику вуза, определяет рамки и ограничения, в которых будет функционировать заданная система. 2. Следующий актор среднего уровня, в данном случае группа акторов, это учебно-методический отдел, состоящий из начальника отдела, заместителя начальника отдела, двух специалистов. Каждый из участников имеет собственный функционал и является держателем различных бизнес-процессов. Логически акторы данного уровня организуют соблюдение другими акторами требований, заданных проректором. 3. Следующий уровень акторов - это ППС. Преподаватели имеют достаточно ограниченные права в системе (просмотр информации и загрузка данных), однако они являются самыми многочисленными по количеству и основными «наполняющими» базы данных, загружая ПУД и УМД в систему. 4. Среди ППС можно выделить отдельную группу лиц с расширенным функционалом - руководители учебных подразделений. Кроме обычных функций ППС руководители могут согласовывать заявки, принимать запросы, проверять загруженные документы («портфолио») ППС и формировать отчеты для УМО. На рис. 1-4 представлены диаграммы прецедентов [12, 13] главных из бизнес-процессов, описанных выше (это бизнес-процессы 1, 5, 7, 8). Рис. 1. Диаграмма БП «Контроль соблюдения федеральных требований к образованию» Рис. 2. Диаграмма БП «Проверка ведения учебно-методической документации» Рис. 3. Диаграмма БП «Организация и проведение Учебно-методического совета» Рис. 4. Диаграмма БП «Организация процесса разработки программ учебных дисциплин» 2. Особенности архитектуры системы. Очень важной частью проектирования системы, безусловно, является корректно спроектированная архитектура [14, 15]. В ходе анализа предметной области было решено создать следующую архитектуру (рис. 5). Архитектура состоит из трех слоев: 1. Слой клиента (браузер). Этот слой является самым верхним уровнем приложения с интерфейсом пользователя. Главная функция интерфейса - предоставление задач и результатов, понятных пользователю. 2. Слой логики (веб-сервер, сервер приложений, ftp-сервер). Этот слой координирует программу, обрабатывает команды, выполняет логические решения и вычисления, выполняет расчеты. Слой логики также перемещает и обрабатывает данные между двумя окружающими слоями. 3. Слой данных (MySQL). Здесь информация хранится и извлекается из базы данных и файловой системы. Информация отправляется в логический слой для обработки и в конечном счете отправляется пользователю. Браузер Web-сервер FTP-сервер Каталог Сервер приложений Сервер БД Запрос Ответ Протокол HTTP Ftp-ответ Ftp-запрос TCP/IP TCP/IP Данные SQL Данные SQL-запрос MySQL Рис. 5. Архитектура Системы Помещение базы данных в облако обусловлено некоторыми факторами. В преподавательский состав Пермского филиала входят около 500 человек, которые могут либо загружать, скачивать, править или просто просматривать программы учебных дисциплин. Облачные технологии позволяют объединить ресурсы в один пул для более эффективного обслуживания большого количества пользователей (позволяют перераспределять мощности в зависимости от потребности пользователя - кому-то меньше, кому-то больше). Также они позволяют автоматически вести учет потребления, подсчитывая использованные ресурсы: пропускную способность, объем сохраняемых данных, количество пользователей, транзакции облачным провайдером и оценивать размер предоставленных пользователям услуг. Эти характеристики облачных хранилищ позволяют создать эффективную и эластичную систему, значительно экономя ресурсы системы. Пользователь заходит в браузер на страницу системы и начинает работу. Веб-сервер получает запрос от браузера и выдает http-ответ в виде HTML-страницы, файлом или другими данными. При необходимости сервер приложения связывается с системой управления базами данных и получает необходимые данные, которые потом передает на слой клиента. Пользователь может напрямую обратиться к файл-серверу (ftp-серверу) через локальную сеть. Такая архитектура обусловлена первоначально выделенными требованиями к системе: доступ к системе в любое время, в любом наиболее удобном месте (веб-приложение), общее хранение документов, а также доступ к ним (база данных, FTP-сервер), доступ к актуальной информации всех акторов процесса. 3. Особенности выбора компонентов системы. Разработанная система использует ресурсы и возможности двух групп компонентов: внутренних и внешних (независимых). Взаимосвязь компонентов представлена на рис. 6. Рис. 6. Диаграмма компонентов Среди внутренних компонентов системы можно выделить: 1. УМО.exe - файл для запуска программы. 2. Web.config - файл с описанием конфигурации системы. 3. УМО.py - файл с программным кодом, реализованный на языке программирования python. 4. УМО.mdb - база данных системы. 5. Help.hlp - информационная справка для пользователя. Как было описано выше, проектируемая система будет взаимодействовать с уже имеющимися системами вуза. Одним из наиболее важных существующих компонентов является информационная система управления учебными процессами вуза, представленная компонентом asav.mdb. Данная система нужна нашей системе для выгрузки необходимой информации по вузу, на основании которой мы будем составлять отчеты, проверять показатели на соответствие требованиям. Для работы с информацией нам необходим ряд независимых компонентов приложения: 1. Hse.auth и security.dll - компоненты для реализации входа в систему по корпоративному логину и паролю. 2. Matplotlib представляет собой библиотеку 2D-графики Python, которая позволяет получать данные о качестве публикации в различных форматах и интерактивных средах на разных платформах [16]. 3. Jasper reports - это библиотека для создания отчётов. В ней генерируются готовые для печати документы, консолидирующие данные из различных источников, в том числе JDBC. Отчёты могут выводиться на экран, принтер, либо в различные форматы, например PDF. Также возможна группировка данных по требуемому полю [17]. 4. Pandas - программная библиотека для обработки и анализа данных. Pandas предоставляет специальные структуры данных и операции для манипулирования числовыми таблицами и временными рядами. Библиотека подходит для работы с многомерными структурированными наборами информации [18]. 5. Gensim - это средство моделирования векторных пространств. Он специально разработан для обработки больших коллекций текстов, используя потоки данных и эффективные инкрементные алгоритмы, которые отличают его от большинства других программных пакетов, которые предназначены только для пакетной обработки и обработки в памяти [19]. 6. Scrapy - это одна из наиболее популярных библиотек Python для получения данных с веб-страниц, которая включает в себя большинство общих функциональных возможностей. На данный момент есть необходимость использования данного инструмента для сбора и анализа информации с официальных сайтов: Минобрнауки.рф и портала университета с целью сбора статистики, анализа информации и совершенствования размещения компонентов сайта [20]. Кроме этого для оптимизации работы пользователей необходимо разработать модуль работы с ППС и модуль работы с ПУД. Выводы. Таким образом, были сформулированы критерии, исходя из которых осуществлялось проектирование системы: 1. Доступ к системе через Интернет, чтобы ППС могли получать доступ к актуальному расписанию, дисциплинам и учебной нагрузке и возможность загрузки учебно-методических документов (программы учебных дисциплин, фонды оценочных средств, контрольно-измерительные материалы и т.п.) в единое хранилище вуза в любое время, в любом месте. 2. Доступ к системе разных групп пользователей, которые могут взаимодействовать друг с другом. Как было изложено ранее, существуют процессы, в которых задействованы различные отделы. Например, своевременная подготовка документов к лицензированию и аккредитации образовательных программ, проверка соответствия стандартам работы вуза - подразумевают взаимодействие множества сотрудников различных подразделений для сбора документов, подписания, согласования. 3. Организация доступа к документам, архивам вуза. В качестве основного объекта УМП практически всегда выступают документы, поэтому хорошая организация УМП подразумевает наличие множества документов и эффективную организацию их оборота среди сотрудников. 4. Доступ к системе как внутренних, так и внешних акторов. Несмотря на то, что пока рассмотрены только внутренние акторы системы (проректор, сотрудники УМО и т.д.), со временем возможно предоставление доступа внешним пользователям, например, акторам Министерства образования для непосредственной загрузки актуальных требований, документации и.т.д. 5. Распределенная клиент-серверная модель архитектуры. Выбор обусловлен необходимостью разграничения доступа к данным, необходимостью поддержки системой многопользовательского режима работы, а также гарантией целостности данных. 6. Помещение базы данных в облачное хранилище для обеспечения эффективной работы множества пользователей: гибкое распределение мощностей по принципу - кому, сколько надо, тот столько и получает. 7. Максимальное использование независимых компонентов с открытым кодом, что позволит эффективнее совершенствовать систему в дальнейшем: например, заменить неэффективные компоненты или расширить функционал системы с помощью добавления новых. 8. И, наконец, любой современный университет - это корпоративная организация, следовательно, немаловажной особенностью проектирования является использование корпоративного стиля организации при разработке системы.

About the authors

I. I Zakharova

National Research University «Higher School of Economics»

N. S Mezevetova

National Research University «Higher School of Economics»

S. K Filipson

National Research University «Higher School of Economics»

References

Statistics

Views

Abstract - 37

PDF (Russian) - 5

Refbacks

• There are currently no refbacks.