Информатизация в образовательном процессе: решения, средства и возможности

А. О. Голосов

Информатизация в образовательном процессе: решения, средства и возможности

●

Аннотация В статье рассматривается инновационный подход к со зданию систем автоматизации учебной деятельности, на базе которого в компании ФОРС были разработаны решения для высшей школы (S&M_Art_University) и средней школы (S&M_Art_School). Решения сочетают в себе, с одной стороны, гибкость и адаптируемость к условиям образовательного учреж дения (ОУ), а с другой — унифицированность. Гибкость дости гается за счет использования модели, а унифицированность — за счет применения связанного с моделью универсального прог раммнотехнологического комплекса S&M_Art. Через универ сальную интеграционную шину с решениями в технологии S&M_Art могут быть интегрированы различные информацион ные системы, используемые в ОУ. * * * Задачи реформирования системы образования требуют серьезной информационной поддержки, а в национальном про екте «Образование» автоматизация образовательных учреж дений названа одним из приоритетных направлений деятель ности. Проводимые в настоящее время реформы в образователь ной сфере требуют согласования задач информатизации с зада чами модернизации управления образованием. Это означает, что информационные системы (ИС) в сфере образования долж ны соответствовать следующим основным требованиям: 1) гибкость и модифицируемость функционала системы, позволяющие адаптировать систему под требования конкретно го ОУ при внедрении, а в процессе эксплуатации без привле чения разработчиков отражать в системе изменения в деятель ности ОУ;

386

2) интегрируемость с ИС, ранее внедренными и эксплуати руемыми в ОУ. При этом интеграционное решение должно позволить руководству ОУ получить целостную информацию о результатах деятельности и управлять качеством учебного процесса. Компания ФОРС, разрабатывая свои решения для средней и высшей школы, применила инновационный подход к созда нию систем управления ОУ. Подход является процессно ориен тированным и базируется на модельной архитектуре MDA (Model Driven Architecture), в которой вначале создается модель, а на ее базе — собственно автоматизированная система. При таком подходе принципиально изменяется объект автоматизации — в качестве него выступает интегрированная модель деятельности ОУ, которая включает в себя описание деловых процессов ОУ, информационных объектов, отражаю щих объекты предметной области деятельности ОУ, а также компонентов ИТинфраструктуры. Поскольку в модели описывается, по сути, вся деятельность ОУ, эта модель может существенно помочь в прохождении аттестации, а также в формировании системы менеджмента качества в ОУ. Наше решение позволяет моделировать и далее поддержи вать в информационной системе различные способы организа ции учебного процесса — и традиционные, и инновационные, различные формы обучения (включая дистанционное). Кроме того, предлагаемый подход фактически стирает грань между системой высшего образования и системой профессиональной переподготовки, приближая ОУ к реализации системы непре рывного обучения, что очень актуально в современных услови ях постоянного развития и изменения технологий. Система предполагает методическую открытость — все мето дики, связанные с содержательной частью учебного процесса или с оценкой его результатов, могут быть описаны в виде стандарти зованных документов и загружены в хранилище системы для их использования в реализации учебного процесса. Это предоставит ОУ возможность изменить подходы к оценке результатов учебно го процесса, определяя различные критерии эффективности и вводя соответствующие показатели оценки результатов. Обучающимся при этом может быть предоставлена возмож ность гибко формировать свою собственную учебную програм му (за рамками обязательных курсов) и получить необходимые квалификации для дальнейшей профессиональной деятельнос ти. Кроме того, став дипломированными специалистами, они могут продолжать поддерживать связь с ОУ, получая дополни тельные компетенции по нужным направлениям, а также пре доставлять информацию о фактической востребованности на рынке тех или иных компетенций, что позволит ОУ соответ ственно регулировать учебную программу.

387

Преподаватели получают возможность не только создавать собственные учебные курсы, но и, имея информацию о потреб ностях рынка и востребованности курса, своевременно актуали зировать их, повышая тем самым свой рейтинг в ОУ и в науч ном мире. Возможность изменения модели позволяет адаптировать систему в течение всего его жизненного цикла к внешним и внутренним изменениям в деятельности ОУ. Реализованный компанией ФОРС подход к созданию сис темы автоматизации образовательной деятельности сочетает в себе, с одной стороны, гибкость и адаптируемость к условиям ОУ, а с другой — унифицированность. Это достигается за счет двух уровней моделирования/конструирования: 1) создание модели учебного процесса; 2) конструирование самой системы из ядра и внешних компонентов. При этом разработанная модель служит источни ком для автоматизированной генерации хранилища данных и ядра системы. Эта модель позволяет также сформулировать требования к интеграции с ядром внешних модулей (планирование, финан совое управление, анализ результатов и т. д.). Компоненты, не входящие в состав ядра, могут быть заменяемыми. Например, ес ли ОУ уже имеет собственную финансовую систему, то эту сис тему можно интегрировать с ядром и эксплуатировать в рамках комплексного решения. Благодаря интегрированному хранилищу данных и полно му описанию существующих информационных процессов в мо дели руководство ОУ сможет иметь качественные, актуальные и полные данные для анализа и прогнозирования вариантов раз вития событий, получая тем самым серьезную информацион ную поддержку процесса принятия решений по стратегическим и тактическим вопросам управления ОУ. ОУ в процессе создания автоматизированной системы вы ступает в роли соразработчика, активно участвующего в выпол нении всех этапов работ. Стоимость владения таким решением существенно ниже, чем, скажем, стоимость владения ERPсистемой, поскольку из держки предлагаемого подхода являются в основном единовре менными, относящимися к начальной стадии внедрения систе мы. Последующая поддержка работы такой системы, в том чис ле реализация изменений в бизнеспроцессах и в составе интегрированных с ядром внешних систем, выражается глав ным образом в изменении моделей и системе настроек.

388

1

ТЕХНОЛОГИИ

Для реализации описанного выше подхода применяется универсальный программнотехнологический комплекс S&M_Art. Рисунок 1 демонстрирует основные компоненты технологии S&M_Art и иллюстрирует три шага эволюции технологического комплекса: (1) ЭЛАД (ФОРСЦР) — средство онтологического модели рования, проектирования и управления объектно ориентиро ванным хранилищем, развитый набор сервисов для управления доступом к данным в хранилище; (2) ЭЛАДЭР (ФОРСЦР) — программный комплекс для соз дания процессно ориентированных решений, включающий ЭЛАД и интегрированные с ним средства управления потоками работ (для поддержки бизнеспроцессов) — Oracle Workflow или Oracle BPEL PM; (3) S&M_Art — комплексная технология, которая, кроме ЭЛАДЭР, включает Corporate Modeller (Casewise) — инструмен тальное средство для создания модели.

Рис. 1. Технологии, используемые при построении решений для обра зовательной сферы

389

С помощью Corporate Modeller создается модель, далее с по мощью специальных конверторов производится генерация ме таописания объектного хранилища в ЭЛАД и генерация прото типа информационной системы поддержки процессов деятель ности ОУ.

2

РЕШЕНИЯ

В описанных выше технологиях ФОРС реализовал два ба зовых решения: ● S&M_Art_School — система для автоматизации деятельнос ти средних школ; ● S&M_Art_University — система для автоматизации дея тельности вузов. Оба эти решения базируются на одной и той же техноло гии S&M_Art, а их различие заключается в моделях, описываю щих деятельность соответственно средней и высшей школы.

3

ОПИСАНИЕ ПОДХОДА К И Н Ф О Р М А Т И З А Ц И И ОУ В ТЕХНОЛОГИИ S&M_ART

Создание интегрированной автоматизированной системы ОУ согласно предлагаемому подходу происходит в два этапа, на каждом из которых осуществляются ключевые работы по конструированию (рис. 2). Этапы создания системы

Уровни конструирования

Консалтинг и моделирование

Создание модели деятельности ОУ

Сборка и интеграция

Конструирование программной сис темы из ядра и внешних компонен тов, часть которых ранее эксплуати ровалась в ОУ

Этап консалтинга и моделирования состоит из следу ющих шагов: 1. Моделирование/конструирование деятельности, опреде ление целей и задач ОУ, описание значимых результатов и кри териев оценки качества учебного процесса. 2. Создание модели существующей ИТинфраструктуры, идентификация средств поддержки различных задач и функций ОУ. 3. Сопоставление модели ИТинфраструктуры и модели де ятельности ОУ с целью определения целесообразности включе

390

Рис. 2. Этапы создания системы автоматизации образовательной деятельности

ния эксплуатируемых локальных систем в единую интегриро ванную систему ОУ и выделения деловых процессов, подлежа щих автоматизации с помощью новых инструментов и техно логий. На шаге моделирования/конструирования деятельнос ти ОУ создаются две модели: ● информационная (объектная, семантическая) модель, опи сывающая объекты предметной области учебного процес са, их структуру и взаимосвязи; ● процессная модель, описывающая бизнеспроцессы и их связи с объектами информационной модели. Изза тесной взаимосвязи моделей, которая проявляется в том, что каждый процесс описывается в связи с объектами (ука зывается, какие объекты связаны с процессом, каким образом из меняется их состав и характеристики в результате выполнения процесса), целесообразно рассматривать их как единое целое.

391

Процессы в модели можно разделить на основные (поддер живающие основную деятельность ОУ) и вспомогательные (под держивающие неосновную деятельность). Процессы могут быть проранжированы по их приоритетности. Примечание. В ряде ОУ такая модель уже реализована. Если же ее нет, создание модели может быть существенно упрощено, если ис пользовать в качестве отправной точки какуюлибо типовую модель деятельности ОУ и лишь адаптировать ее для конкретного ОУ. Так, ФОРС поставляет типовую модель деятельности средней школы для решения S&M_Art_School и типовую модель деятельности вуза для S&M_Art_University.

На шаге анализа существующей ИТинфраструктуры создается модель ИТинфраструктуры, описывающая приклад ные ИС, базы данных, общесистемные программные средства, компьютерное и телекоммуникационное оборудование, эксплу атируемые в ОУ. Эта модель также включает объекты и процес сы. Ее объектами являются элементы ИТинфраструктуры, а процессами — процессы управления ИТинфраструктурой. Кроме технических характеристик, в модели должно быть ука зано, какие функции, задачи и на каком уровне поддерживает каждый из элементов ИТинфраструктуры. На шаге сопоставления и анализа модели ИТинфра структуры и модели деятельности ОУ эти модели должны быть тесно увязаны (интегрированы). Полученный результат яв ляется значимым для ОУ, так как предоставляет данные для ана лиза не только степени автоматизации тех или иных процессов, но и многих других интересующих руководство аспектов дея тельности ОУ. В рамках анализа созданной модели на соответ ствие возможностей ИТинфраструктуры целям и задачам ОУ выявляются следующие основные сведения: ● поддержка каких задач и функций ОУ дублируется несколь кими системами и насколько это оправданно; ● какие задачи и функции ОУ не поддерживаются средства ми автоматизации или поддерживаются недостаточно; ● каков уровень интеграции ИС с существующей ИТинфра структурой, какие обменные процессы не автоматизирова ны и требуют автоматизации; ● достаточно ли мощностей компьютерной техники и теле коммуникационного оборудования для реализации задач и функций ОУ, описанных в модели. На основании этих данных необходимо провести аудит существующих программных средств и техники, с тем чтобы решить, какие из них имеет смысл использовать в создаваемой системе автоматизации деятельности ОУ. В результате состав ляются: 1. Перечень ИС, которые должны быть включены в инфра структуру новой системы. 2. Перечень ИС, включение которых в новую систему неце лесообразно.

392

3. Аналогичные перечни для технических средств. 4. Дефицит/профицит мощностей компьютерного и теле коммуникационного оборудования. 5. Перечень недостающих общесистемных средств. 6. Требования к прикладным функциям и задачам, которые необходимо автоматизировать. На основании требований к прикладным функциям и зада чам в модели можно обозначить виртуальные программные компоненты, которые в перспективе будут обеспечивать выпол нение дополнительных функций. Предлагаются два способа их реализации — собственная разработка или использование гото вых систем, имеющихся на рынке. Выбор готовых средств в этом случае облегчается тем, что все требования к ним подроб но описаны. На этом первый этап — консалтинг и моделирование — за канчивается, и можно приступать к выполнению второго этапа создания системы. На втором этапе происходит конструирование про граммной системы на основании модели, созданной на пер вом этапе. Конструирование программной системы состоит из следующих шагов: 1. Автоматическая генерация на основании модели, создан ной на этапе консалтинга и моделирования, следующих компо нентов ядра системы: а) метаописание хранилища данных о деятельности ОУ; б) объектно ориентированное хранилище данных деятель ности ОУ; в) прототип информационной системы, поддерживающий деловые процессы ОУ. 2. Адаптация прототипа ИС, поддерживающего деловые процессы ОУ (формализация внутренней логики отдельных ша гов деловых процессов). 3. Интеграция с созданным ядром прочих компонентов, ав томатизирующих отдельные направления деятельности ОУ (например, бухгалтерский учет, анализ результатов и т. д.). Каждый из вышеперечисленных шагов требует детального описания подхода к его реализации и используемых техно логий. Шаг генерации ядра системы позволяет на основании модели автоматически получить прототип информационной системы, поддерживающей деятельность ОУ. Иными словами, на этом шаге по модели автоматически создается работоспособная информационная система. При генерации создаются следующие компоненты ядра: 1. На основании объектной модели ОУ — хранилище дан ных о деятельности ОУ. 2. На основании процессной модели ОУ — прототип ин формационной системы, поддерживающей деятельность ОУ.

393

Для управления хранилищем данных ОУ в ядре ис пользуется программный продукт ЭЛАД, о функциях и воз можностях которого будет рассказано ниже. Генерация хранилища в ядре выполняется следующим об разом (рис. 3): 1. Объектная модель ОУ экспортируется в XMLфайл. 2. Специальная программаконвертор преобразует XML файл модели в XMLфайл ЭЛАД. 3. Средствами импорта ЭЛАД на основании XMLфайла соз дается метаописание объектов предметной области ОУ. 4. На основании метаописания средствами системы ЭЛАД в хранилище происходит автоматическая генерация структур для хранения информации об объектах. Генерация прототипа системы, поддерживающей деловые процессы ОУ, осуществляется так: 1. Процессная модель ОУ экспортируется в XMLфайл. 2. Специальная программаконвертор преобразует XML файл модели в XMLфайл workflowсистемы. 3. Новый XMLфайл импортируется в workflowсистему — создается прототип системы поддержки процессов.

Рис. 3. Генерация компонентов ядра системы на основании модели деятельности ОУ

394

Примечание. Workflow (потоки работ) — технология автоматиза ции бизнеспроцессов (управления потоками работ), организованных в процедуры (последовательности шагов) в соответствии с предвари тельно заданными правилами и ориентированных на коллективное выполнение.

Шаг адаптации прототипа системы является чисто технологическим и предназначен для программной реализации той логики бизнеспроцесса, которая не была формализована в модели. Фактически на этом этапе прототип системы превраща ется в реальную систему. При этом разрабатываются процедуры, связанные с обращением к хранилищу и реализующие алгорит мы работы, которые не были формализованы в модели. Шаг адаптации, вообще говоря, не является обязательным при создании системы. В том случае, если детализация модели предполагает учет всех формализованных алгоритмов бизнес логики, процедура генерации, выполняемая на предыдущем ша ге, автоматически создаст уже не прототип, а готовую систему. Таким образом, детализация процесса может быть выполнена либо на этапе моделирования силами бизнесаналитика, либо на этапе адаптации силами программистаразработчика про цедур. Шаг интеграции с внешними компонентами является для ОУ, пожалуй, одним из важнейших в создании системы. Именно на этом шаге к ядру подключаются прикладные систе мы, ранее эксплуатировавшиеся в ОУ, а также иные внешние системы, выбранные ОУ. В вопросах интеграции сотрудники ОУ становятся актив ными соисполнителями работ по автоматизации: они не толь ко принимают решение о включении в инфраструктуру интег рации тех или иных систем, но и могут участвовать в реализа ции самих интеграционных решений. Общий подход к интеграции вокруг ядра внешних про граммных систем таков: 1. В модели в разделе ИТинфраструктуры описываются внешние системы, которые предполагается интегрировать с яд ром. Если заранее известно, какие это будут системы, то описы ваются их характеристики. Если же конкретные системы неиз вестны, а есть только представление о том, какие функции они должны обеспечивать, то описываются виртуальные системы. При этом указывается, какие объекты и процессы из модели деятельности ОУ должны реализовываться в каждой из систем. Таким образом, в целостной модели ОУ для каждой внешней системы определяется подмодель, которая должна реализовы ваться этой внешней системой. 2. Внешняя система, которую предполагается интегрировать с ядром, подвергается обследованию с целью выявить соответ ствие реализуемых ею процессов и объектов аналогичным про цессам и объектам в подмодели ОУ (см. предыдущий пункт).

395

В случае если соответствие удалось установить, т. е. внешняя система обеспечивает реализацию процессов и учет объектов, предусмотренных для нее в модели, такая система может быть включена в инфраструктуру интеграции. 3. Для реализации интеграционных решений должно быть формально описано соответствие процессов и объектов в моде ли деятельности ОУ и аналогичных им процессов и объектов во внешней системе. На основании такого формализованного опи сания определяется архитектура интеграции. Чаще всего интег рация осуществляется на уровне данных. В интеграции на уровне процессов, как правило, необходимости нет, поскольку внешние системы обычно реализуют целостные законченные процессы. Однако возможны ситуации, когда процесс выполня ется по частям в различных системах. Этот вариант требует он лайнинтеграции, т. е. специальное средство маршрутизации процесса должно осуществлять поочередные вызовы систем, вы полняющих части процесса, передавать им параметры процес са и получать результаты, из которых формировать входные параметры для следующей части процесса, и т. д. 4. Далее выбирается механизм интеграции. Наиболее уни версальным в этом качестве является механизм обмена сообще ниями, при котором для передачи информации между внешней системой и ядром необходимо в передающей системе сформи ровать сообщение (например, XMLдокумент), содержащее пере даваемую информацию, и доставить это сообщение к получаю щей системе, которая должна принять и обработать сообщение. Для реализации этого механизма необходимо описать инфор мационные потоки между внешней системой и ядром, а также регламенты обмена. 5. Наконец, реализуются сервисы интеграции. Сервисы ин теграции включаются в состав единой интеграционной плат формы автоматизированной системы ОУ. Задачей этих сервисов является обеспечение интеграционных процессов — передачи данных между ядром и интегрируемой с ним внешней системой в соответствии с регламентами и правилами, описанными на предыдущем шаге. Кроме того, сервисы транслируют данные с семантического языка внешней системы в язык семантики яд ра (т. е. в термины модели деятельности ОУ). Реализация интеграционных процессов описанным выше образом сохраняет интегрируемые системы независимыми друг от друга, не требует никаких изменений в технологии их эксплу атации, а также позволяет строить распределенные решения. Одним из важных преимуществ предлагаемого подхода является решение задачи приведения данных от различных внешних систем к единой терминологии, их одинаковой интер претации и точного сопоставления. Это обеспечивается за счет приведения данных, полученных из всех систем, к единому языку семантики ядра.

396

В предлагаемой архитектуре интеграции возможно отка заться от дублирования данных от внешних систем в едином хранилище ядра. В этом случае в ядре должна быть реализова на система выполнения распределенных запросов, которая смо жет извлекать информацию не только из хранилища ядра, но и из хранилищ внешних систем. Данный подход к созданию системы автоматизации обра зовательной деятельности сочетает в себе гибкость и адаптиру емость к условиям ОУ за счет двух уровней: моделирова ния/конструирования (создание модели учебного процесса и конструирование самой системы из ядра и внешних компонен тов) и унифицированности. Последнее, в свою очередь, обеспе чивается благодаря использованию единого технологического ядра и интеграционной платформы. Стоимость владения таким решением существенно ниже, чем, скажем, стоимость владения ERPсистемой, за счет того, что издержки предлагаемого подхода являются в основном едино временными, относящимися к первоначальной стадии внедре ния системы. Последующая поддержка работы такой системы, в том числе реализация изменений в бизнеспроцессах и в сос таве интегрированных с ядром внешних систем, выражается, главным образом, в изменении модели и способа настроек. В части программного обеспечения изменения могут касаться лишь сервисов интеграции. Остальные программные компонен ты базируются на метаописаниях и поэтому не изменяются при модификации состава процессов и функций.

4

ИНФОРМАЦИОННАЯ ПОДДЕРЖКА ПРИНЯТИЯ РЕШЕНИЙ

Под средствами для информационной поддержки принятия решений подразумевается широкий спектр аналитических инструментов — от формирования отчетности до мониторинга показателей эффективности деятельности и моделирования сце нариев развития событий. В данном разделе мы рассмотрим, как могут быть построены запроснопоисковая подсистема и под система анализа результатов образовательной деятельности в рамках предлагаемого подхода.

4.1. ЗАПРОСНОПОИСКОВАЯ ПОДСИСТЕМА Реализация запроснопоисковой подсистемы является од ной из главных задач информатизации ОУ. Ведь именно благо даря этой подсистеме сотрудники ОУ получают возможность через единую точку входа извлечь нужную им информацию из

397

любого информационного ресурса, существующего в ОУ (при условии, что он интегрирован с ядром). Но для обеспечения такой возможности необходимо при вести данные всех ресурсов к единой терминологии, обеспечить их одинаковую интерпретацию и точное сопоставление. При этом запроснопоисковая подсистема в общем случае строится над распределенным хранилищем информации, поскольку часть данных для анализа может быть получена из хранилища ядра, а остальные — из интегрированных с ядром внешних систем. Итак, должна быть построена система для выполнения распределенных запросов, которая умеет приводить данные из различных систем «к единому языку», чтобы обеспечить их со поставимость. Для этого необходимо описать этот единый для всех интегрируемых ресурсов «язык» и сформулировать прави ла, по которым данные из различных источников будут преоб разованы. Единый «язык» может быть представлен в виде информаци онной модели интеграции. Модель предназначена для описания объектов обобщенной предметной области интегрируемых ис точников данных, их структуры и взаимосвязей. Информация об этих объектах может быть фрагментирована и рассредоточена по различным источникам. На уровне семантической модели появляется целостная картина имеющейся в ОУ информации. Составной частью модели также является модель классифика ции и кодирования информации. Данные из ядра системы хра нятся в структуре этой информационной модели, а данные из других ресурсов, интегрированных с ядром, приводятся к языку информационной модели динамически, в ходе выполнения запросов. Приведение внешних данных к языку информационной модели предполагает использование следующих компонентов: 1. Репозиторий информационных ресурсов, содержащий унифицированное описание всех интегрируемых с ядром ре сурсов — состав информации (в терминах информационной модели) и способы доступа к ней. 2. Адаптеры доступа к информационным ресурсам, пред ставляющие собой наборы сервисов, обеспечивающих коррект ный доступ к информационным ресурсам и извлечение из них данных, необходимых для реализации запросов. Адаптеры явля ются внешними по отношению к ресурсам компонентами, по этому сами ресурсы и принципы их эксплуатации в ОУ остают ся неизменными. После того как описаны информационная модель интегра ции и правила извлечения информации из различных источни ков, интегрированных с ядром, остается последний шаг — соз дание собственно запросной системы. Должен быть создан ка талог запросов, с которыми сотрудники ОУ могут обращаться в систему. Как запросы, так и ответы на них должны формиро

398

ваться в терминах информационной модели. При получении запроса система сама сможет определить, какие ИР ей понадо бятся для выполнения запроса (в соответствии с вышеописан ными правилами) и обратится к требуемым сервисам. В случае если запрос связан с обращением к нескольким источникам, осуществляется маршрутизация запроса, т.е. последовательное (или параллельное, в зависимости от алгоритма маршрута) об ращение к сервисам и обработка получаемой информации. Об работка информации подразумевает ее корректную консолида цию и устранение дублирования. Точкой входа для запросной системы удобнее всего сделать информационный портал ОУ, так как это обеспечит возмож ность удаленного доступа к информации для различных катего рий заинтересованных лиц (разумеется, доступ должен быть регламентированным, т. е. ограниченным в соответствии с тре бованиями информационной безопасности). Потребитель ин формации, зарегистрировавшись на портале, сможет выбрать нужный запрос из числа доступных ему, ввести значения вход ных параметров (если запрос это предусматривает) и выпол нить запрос, получив результат поиска. Для ряда категорий пользователей, кроме преднастроенных запросов, может быть предусмотрена возможность задания нерегламентированных запросов, т. е. запросов, условия которых пользователи форму лируют динамически, сразу же выполняют их и получают результат поиска.

4.2. АНАЛИТИЧЕСКАЯ ПОДСИСТЕМА Аналитическую подсистему также в общем случае придется строить над распределенным хранилищем. Целесообразно ис пользовать сервисы запроснопоисковой подсистемы для извле чения данных из распределенного хранилища с целью постро ения специального аналитического хранилища. Иными словами, запроснопоисковая подсистема может выступать в качестве виртуального «единственного» источника информации для ана литической подсистемы. Таким образом, структура информаци онной модели, которая описана выше, должна рассматриваться как структура хранилища, из которого получает исходные дан ные аналитическая подсистема. Мы рассмотрим реализацию аналитической подсистемы на распределенном хранилище на примере двух типов аналитичес ких систем: 1. OLAPсистема. 2. Система анализа ключевых показателей деятельности (например, система сбалансированных показателей).

399

4.3. ПОСТРОЕНИЕ OLAPСИСТЕМЫ Алгоритм работы OLAPсистемы: 1. Получение данных для анализа в виде плоской таблицы или результата выполнения SQLзапроса. 2. Кэширование данных и преобразование их к многомер ному кубу. 3. Отображение построенного куба при помощи кросстаб лицы или диаграммы и т. п. В случае построения OLAPсистемы над распределенным хранилищем эти этапы выглядят следующим образом: 1. Описание правил формирования аналитического храни лища на базе хранилища данных ядра в терминах объектов ин формационной модели системы. 2. Использование поисковозапросного механизма ядра для извлечения данных по каждому из классов объектов и представ ления результатов в виде плоских таблиц для аналитической системы. 3. Анализ структуры каждого объекта. Атрибуты объекта разбиваются на 2 категории: измерения и факты. 4. Построение кубов.

4.4. ПОСТРОЕНИЕ СИСТЕМЫ АНАЛИЗА КЛЮЧЕВЫХ ПОКАЗАТЕЛЕЙ ДЕЯТЕЛЬНОСТИ Системы анализа показателей обычно работают следующим образом: 1. Настройка: а) составление набора показателей по важнейшим аспектам деятельности предприятия для увязывания оперативной деятель ности со стратегией; б) описание алгоритмов расчета показателей на основании учетных данных и других показателей; в) установление причинноследственных связей между по казателями. 2. Расчет значений показателей, отслеживание динамики их изменения во времени. 3. Графическое отображение информации для анализа. В случае построения системы анализа показателей над распределенным хранилищем эти этапы выглядят следующим образом: 1. Описание показателей и методик их расчета средствами ядра системы. 2. Расчет значений показателей средствами ядра системы с использованием поисковозапросного механизма для извлече ния данных для расчета.

400

3. Графическое отображение информации средствами ана литической системы. Система автоматизации образовательной деятельности пред полагает методическую открытость — в ней могут быть сформи рованы ключевые показатели деятельности, связанные с содержа тельной частью учебного процесса или с оценкой его результа тов, методики расчета которых могут быть описаны в виде стандартизованных XMLдокументов и загружены в хранилище системы для их использования в реализации учебного процесса. Таким образом, в хранилище системы еще на оперативном уровне формируются значения показателей, которые затем можно использовать в аналитической подсистеме. Это предоставит ОУ возможность расширить подходы к оценке результатов образо вательной деятельности, определяя различные критерии эффек тивности и вводя соответствующие показатели оценки.

5

У П РА В Л Е Н И Е Х РА Н И Л И Щ Е М ДАННЫХ

Как уже было отмечено ранее, для управления хранилищем данных об ОУ в ядре используется программный продукт ЭЛАД — собственная разработка компании ФОРС. Система ЭЛАД предназначена для создания метаописаний процессов, управления гибким объектно ориентированным хра нилищем данных, быстрой разработки прототипов информаци онных систем, реализации электронных административных рег ламентов. ЭЛАД — трехуровневая система, реализованная в среде JavaTM2 Platform, Enterprise Edition — архитектуре для создания процессно ориентированных приложений уровня предприятия в распределенных системах. J2EE обеспечивает системные сер висы, такие, как управление транзакциями, безопасность и дос туп к базе данных. Система легко масштабируема и переносима на любую платформу, поддерживающую виртуальную Javaма шину. Архитектура ЭЛАД показана на рисунке 4. Система управления информационными ресурсами ЭЛАД хорошо себя зарекомендовала на рынке подобных систем и бы ла использована в качестве интеграционной платформы в раз личных проектах. ЭЛАД был выбран Центральным аппаратом Министерства Российской Федерации по налогам и сборам для решения задач автоматизации технологических процессов обработки и хранения документов категории «служебного поль зования». В Национальном фонде подготовки кадров (НФПК) на базе ЭЛАД была создана и внедрена автоматизированная систе ма мониторинга текущего состояния проектной деятельности фонда («ЭЛАДДокументооборот» и «Аналитический модуль»).

401

Рис. 4. Архитектура ЭЛАД

Система позволяет формировать отчетные документы для руководства по различным срезам, в том числе и сводным дан ным (займам, проектам, источникам финансирования и пр.). Создано специальное хранилище различного вида документов, связанных с выполняемыми фондом проектами, которое позво ляет быстро и корректно проводить анализ и поиск данных до кументов как по атрибутам, так и по контексту. В системе ЭЛАД заложены возможности для выполнения функции автоматичес кой публикации информации о проводимых конкурсах на сай те фонда, реализованной на базе технологий Оracle Portal. На программный продукт ЭЛАД компания ФОРС имеет сертификаты соответствия Госстандарта России № РОСС RU.СП09.Н00015 и Инкомтехсерта № ROCC RU.04 ИК.П00001 на использование ЭЛАД в системе образования. Ниже представлены ключевые технологические особеннос ти ЭЛАД: ● XMLформат документов; для хранения текстов документов в системе используется единый XMLформат. Этот формат открыт для пользователя. Документы в этом формате могут быть отформатированы, включать графику и пр.; ● структурированный текст. При вводе текста можно выде лить части, главы, параграфы, таблицы, сноски и пр.; ● информация о связях и версиях в «теле» документа. Инфор мация о связях и версиях может быть включена в него и передаваться вместе с ним; ● разные способы преобразования и отображения текста. Способы преобразования и отображения информации оп ределяются стандартными средствами XSL; ● оглавление документа. Оглавление формируется на основе XMLтегов документа. С помощью оглавления документа

402

●

6

имеется возможность перехода в любое место документа без пролистывания; совместное хранение текста и графики. Документы ЭЛАД могут содержать текст и графику одновременно. Такая воз можность удобна для вставки в текст различных диаграмм, пояснительных иллюстраций и т. д. Хранилище документов также может содержать отсканированные оригиналы доку ментов.

Ц И Ф Р О В Ы Е О Б РА З О В А Т Е Л Ь Н Ы Е РЕСУРСЫ

Технология создания и управления информационными ре сурсами ЭЛАД используется в качестве системы управления хра нилищем цифровых образовательных ресурсов (ЦОР). Целью создания хранилища Единой коллекции ЦОР явля ется обеспечение доступности ресурсов для системы образова ния и контроль их качества. Коллекция может быть использо вана как педагогами для формирования собственных курсов по программам обучения, так и учащимися для самостоятельной подготовки и использования хранилища в качестве системы справочных материалов. При поиске и отборе информации из крупных информа ционных массивов, как и при управлении такими массивами, возникает необходимость избегать сплошного просмотра и ана лиза, пусть даже в той или иной степени автоматизированного, всей имеющейся информации. Гораздо предпочтительнее по лучить компактно записанные стандартизованные данные о представляющих интерес информационных объектах. Подоб ные данные об информации вполне естественно называть ме таданными. Типичным примером метаданных являются, напри мер, библиографические описания и выходные данные книг (учебников или других изданий). Набор метаданных о том или ином ЦОР составляет его ме таописание. Различают два типа ЦОР. Простой ЦОР — исполь зуемый как единое целое и не допускающий деления на отдель ные элементы, которые могли бы использоваться самостоятель но. Примерами «простых» ЦОР являются: документы в форматах MS Office, HTML, PDF и др., иллюстрация в формате JPEG (фор мат поддерживает использование собственных метаданных), аудиозапись, видеозапись, отдельный объект учебного курса, выполненного на определенной технологической платформе. Вторым типом является сложный ЦОР — состоящий из элемен тов, которые можно использовать отдельно как самостоятель ные образовательные ресурсы. В наиболее общем случае слож ный ЦОР может состоять из ядра технологической платформы

403

с набором сервисных модулей, рубрикатора ЦОР и набора простых ЦОР, привязанных к элементам рубрикатора ЦОР. При мерами «сложных» ЦОР могут являться: электронный учебный курс по определенному предмету (программе), выполненный на определенной технологической платформе или требующий проигрывателя для использования, система тестирования, тема тический каталог. Структура и состав метаописаний, очевидно, в значительной степени должны зависеть от уровня, типа и фи зической природы описываемых ЦОР. В коллекции входят статические, динамические и интерак тивные цифровые образовательные ресурсы: ● учебнометодические, художественные и научные тексты; ● графические изображения; ● звуковые и музыкальные ресурсы; ● цифровые копии художественных и научнопопулярных фильмов; ● модели физических явлений, естественнонаучных и соци альных процессов; ● картографические системы; ● словари, переводчики. В целях удобства использования коллекции большое вни мание уделяется разработке интуитивно понятной системы по иска необходимой информации, «привязке» отдельного ресурса к потребностям процесса обучения: стандартам образования, классу, уровню изучения материала, темам по предмету, видам деятельности. Разработка таких коллекций рассчитана на массовую ауди торию как преподавателей, так и учащихся. Главная ее задача — максимально полно обеспечить учебный процесс информаци онными пособиями. Например, предоставить возможность пре подавателю легко и быстро создавать презентации по опреде ленной учебной теме на основе имеющихся графических объ ектов и оцифрованных статей первоисточников по данной тематике. Количество образовательных ресурсов в рамках каж дой темы должно быть избыточным (с учетом различных сту пеней обучения, уровней изучения материала, траекторий инди видуального развития и т. д.) и позволять преподавателю фор мировать учебный материал для различных целей обучения. В качестве базового стандарта описания цифровых образо вательных ресурсов при разработке хранилища ЦОР предпола гается использование переработанного стандарта описания ме таданных образовательных объектов LOM, разработанного меж дународным комитетом IEEE Learning Technology Standards Committee. Цель использования данного стандарта — облегчить поиск, рассмотрение и использование ЦОР преподавателями, инструкторами или автоматически в ходе выполнения про грамм, а также облегчить совместное использование таких объ ектов путем создания библиотек и хранилищ.

404

Стандарт предлагает базовую схему, которая может исполь зоваться для создания практических разработок, например с целью автоматического адаптивного назначения образователь ных объектов тем или иным агентам программного обеспече ния. Стандарт не определяет, каким способом обучающие сис темы будут представлять или использовать метаданные образо вательных объектов. Определяя общую концептуальную схему данных, стандарт обеспечивает связывание ЦОР. А так как мета данные обладают высокой степенью семантической интеропе рабельности, трансформации этих связей будут протекать без затруднений. Образовательные объекты описываются элементами дан ных, сгруппированными в категории. Базовая схема LOM опре деляет девять таких категорий: ● общая категория объединяет информацию об образова тельном объекте в целом; ● категория жизненного цикла группирует элементы об исто рии и текущем состоянии образовательного объекта и тех, кто влиял на него в ходе эволюции; ● категория метаданных содержит информацию о метадан ных; ● техническая категория группирует технические требования и характеристики образовательного объекта; ● образовательная категория объединяет образовательные и педагогические характеристики; ● категория прав содержит данные об интеллектуальной собственности и условиях использования; ● категория связей (реляций) определяет понятия, определя ющие взаимосвязи между данным и иными образователь ными объектами. ● категория аннотации представляет комментарии к образо вательному использованию объекта и данные о создателях этих комментариев; ● классификационная категория определяет место данного объекта в пространстве той или иной классификационной схемы. Все вместе эти категории образуют базовую схему LOM. С использованием классификационной категории возможны различные типы расширений этой схемы. Категории группиру ют элементы данных. Модель данных LOM имеет иерархичес кую структуру и включает как агрегаты элементов данных, так и простые элементы данных (листья на иерархическом дереве). В качестве базовой платформы для формирования распре деленного хранилища единой коллекции образовательных ре сурсов используется СУБД Oracle Database и сервер приложений Oracle Application Server. Такой выбор технологической плат формы обеспечивает выполнение всех необходимых требова ний, предъявляемых хранилищу ЦОР:

405

корректная работа с большими и очень большими объема ми данных и возможность неограниченного расширения объемов хранимой и обрабатываемой информации; ● высокая степень защиты хранимой и передаваемой инфор мации (в том числе и за счет использования гибкой поли тики доступа к компонентам и данным системы); ● масштабируемость и возможность миграции на любую платформу; ● простота настройки и администрирования программного обеспечения; ● возможность создания единого репозитория пользователей для всех применяемых систем SSO; ● возможность балансирования нагрузки на сервер за счет использования кластерных решений Oracle. В качестве средства доступа к хранилищу ЦОР, построен ному на платформе ЭЛАД, используется Oracle Portal. Этот про дукт, входящий в состав Oracle Application Server, является одним из наиболее мощных на рынке портальных решений. Основным преимуществом использования портала является представление данных, консолидированных из разнообразных источников, как внутренних, так и внешних. Кроме того, портал позволяет поль зователям и группам пользователей модифицировать способ представления этих данных и права доступа к ним в соответ ствии со своими потребностями. Портал представляет собой единую отправную точку для доступа ко всем данным хранили ща вне зависимости от того, где находится образовательный ре сурс — в центральном или региональном хранилище. Авториза ция представлена единой службой (Single SignOn). Пользова тель авторизуется лишь один раз при входе в систему, после чего портал предоставляет его автоматически всем приложени ям, требующим авторизации, например для того, чтобы вос пользоваться сервисами наполнения, ведения, администрирова ния хранилища. В качестве системы публикации цифровых образователь ных ресурсов используются технологии ЭЛАД—Information Exchange. Данная система позволяет оперативно публиковать, обрабатывать информацию и обмениваться ею. Кроме того, в ней предусмотрены интегрирующие функции электронной службы оповещения и функции электронного хранилища доку ментов. Основные задачи ЭЛАД—IE — адресное доведение опе ративной информации до потребителя по электронной почте и обеспечение легкого, точного и быстрого обмена данными меж ду пользователями системы. Информирование пользователей о включении новых ЦОР в коллекцию реализуется следующими путями: ● автоматический вывод на портал системы в разделе «Новые поступления» информации обо всех вновь включенных в хранилище ресурсах; ●

406

автоматическое формирование уведомлений пользователям в соответствии с подпиской на определенные ЦОР. Технология как включения ЦОР в хранилище, так и редак тирования описания ЦОР определяется соответствующими воз можностями системы ЭЛАД. Любой ЦОР в системе ЭЛАД представляет собой совокуп ность следующих объектов: ● Учетная карточка ЦОР На карточке информационного ресурса вводятся его атри буты, определяемые при разработке системы или администра тором ЭЛАД для данного типа образовательного ресурса. ● Текстовое описание ЦОР Текстовое описание (аннотация) информационного ресур са в формате XML. ● Присоединенные файлы В качестве присоединенных файлов могут выступать раз личные файлы в любом формате. ● Ссылки между ресурсами ЭЛАД позволяет устанавливать связи (ссылки) между ЦОР, размещенными в хранилище. Ссылки между образовательными ресурсами обеспечивают быстрый и удобный переход между связанными образовательными ресурсами. На рисунке 5 схематически представлена структура ЦОР, размещенных в хранилище. Система автоматически отслеживает правильность вводи мых форматов данных в соответствии с метаописанием, внесен ным при разработке системы или откорректированным адми нистратором системы. ●

Рис. 5. Структура ЦОР

407

Контроль целостности структуры данных обеспечивается внутрисистемными средствами как на уровне СУБД Oracle, так и на уровне ПО системы ЭЛАД. В системе ЭЛАД обеспечивается протоколирование всех действий любого пользователя, в том числе и все данные по внесенным в хранилище изменениям. Гибкая система распреде ления полномочий позволяет разделять права пользователей на внесение изменений вплоть до отдельных атрибутов учетной карточки ЦОР. Кроме того, в системе ЭЛАД обеспечивается веде ние версий ЦОР, позволяющее создать эффективный контроль и разрешение конфликтов версий. Для обеспечения импорта данных из заранее определенных и согласованных с заказчиком форматов других хранилищ дан ных ЭЛАД имеет развитую систему API, позволяющую разрабо тать модули импорта данных из внешних систем с минималь ными затратами. Использование системы ЭЛАД для хранения ЦОР различ ного вида дает возможность реализовать хранение структуриро ванной и слабоструктурированной информации с возможностя ми ее анализа как по атрибутам, так и по контексту. Уникальная система типизации документов позволяет осуществлять описа ние, хранение и анализ информации с любыми характеристи ками, в том числе и неизвестными на момент первоначальной настройки системы. Хранение цифровых образовательных ресурсов (изменение атрибутов существующих ресурсов, добав ление новых типов документов и т. д.) не требует специально обученных администраторов, а может осуществляться самими пользователями системы.

ЗАКЛЮЧЕНИЕ Предложенный в данной статье подход был разработан в первую очередь для динамично развивающихся ОУ с высоким уровнем инновационности, стремящихся повысить свой рей тинг за счет предложения более качественных и нетрадицион ных образовательных услуг, освоения новых направлений и форм обучения, реализации системы непрерывного образова ния, внедрения системы менеджмента качества, интеграции в межвузовское информационное пространство. Такие ОУ используют новые методы автоматизированного управления образовательным процессом и предъявляют повы шенные требования к гибкости и адаптируемости ИС, а для при нятия решений хотят иметь актуальную и достоверную инфор мацию обо всех аспектах деятельности ОУ. Преимущества предлагаемого компанией ФОРС решения заключаются в следующем:

408

● ●

●

● ●

●

● ● ●

● ●

Экономичность в эксплуатации, не требующая дополни тельных расходов при изменении в моделях и настройках. Доступность актуальных, качественных и полных данных в любое время и в любом месте — как в локальной сети учеб ного заведения, так и через Интернет. Моделирование различных схем организации учебного процесса — и традиционных, и инновационных, а также различных форм организации обучения, включая дистан ционную. Возможность использования модели для прохождения ат тестации. Максимальное приближение системы высшего образования к системе профессиональной переподготовки, реализующее идею непрерывного обучения. Поддержка системы менеджмента качества. Система обла дает методической открытостью и предоставляет воз можность описания результатов учебного процесса в виде рассчитываемых показателей, загруженных в хранилище данных системы. Гибкость модели, легко модифицируемой в зависимости от текущих задач образовательного учреждения. Возможность использования как типовых, так и собствен ных моделей управления образовательным процессом. Возможность выступать соисполнителями работ по созда нию интеграционных решений, включающих использова ние собственных программных разработок образователь ного учреждения. Унифицированность системы, использующей единое тех нологическое ядро и интеграционную платформу. Масштабируемость системы, охватывающей в том числе и территориальнораспределенные подразделения образова тельных учреждений.