Предлагаемая концепция "Интегрированная информационно-аналитическая система управления вузом" создана межуниверситетской рабочей группой под руководством ректора Санкт-Петербургского государственного института точной механики и оптики (технического университета), профессора В.Н. Васильева на основе решений, принятых в рамках семинара "Информационные системы в управлении вузом" в Центрально-Европейском университете (14-16 июня 1999 г., город Будапешт). Участники будапештской встречи были единодушны в том, что разработка интегрированной информационно-аналитической системы управления вузом в настоящее время является одним из приоритетных направлений создания общероссийской университетской корпоративной сети в процессе совершенствования системы российского высшего образования.

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

Российские университеты - участники рабочей группы:

Кубанский государственный университет

Новосибирский государственный университет

Петрозаводский государственный университет

Санкт-Петербургский государственный институт точной механики и оптики (технический университет)

Томский государственный университет

Чувашский государственный университет

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

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

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

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

Многие вузы России используют информационные системы и подсистемы оперативной обработки данных, реализованные на самой различной аппаратной и программной основе. Это и автономные файловые системы, и системы, использующие локальные или сетевые версии персональных СУБД, и системы, построенные на серверах реляционных баз данных. Однако даже последние из них, как правило, созданы для автоматизации деятельности отдельных подразделений: используя их, трудно (а иногда и невозможно) обмениваться данными, трудно выдать непредусмотренную справку, трудно узнать, существуют ли в соседних системах данные, затребованные кем-либо из руководства вуза и т.п.

В результате ректорат, руководители и специалисты общеуниверситетских служб, отвечающие за определение стратегии развития различных сфер деятельности университета, вынуждены работать в условиях практически полного отсутствия интегральной информации — “вслепую”, полагаясь только на собственный опыт и интуицию. Они вынуждены опираться в своей работе преимущественно на разрозненные и зачастую противоречивые сведения, поступающие из различных источников. Это тем более неприемлемо, так как, в общем, в организации и в базах данных оперативного доступа накоплены огромные объемы информации.

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

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

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

• информационно-аналитический характер системы;
• на современные сетевые информационные технологии, собственно компьютерные сети, соответствующие инструментальные программные средства и т.д.

Если учесть, что в ряде вузов России именно за последние два года качественно изменилась инфраструктура информационной среды (осуществляется переход от отдельных персональных компьютеров к полноценным внутривузовским компьютерным сетям и их интеграция в общероссийскую университетскую корпоративную сеть, освоение интранет-технологий и технологий создания промышленных информационных систем), то разработка интегрированной информационно-аналитической системы управления вузом становится не только актуальной, но и вполне реальной задачей.

Успешности реализации и внедрения системы способствует:

• готовность к информатизации подразделений вуза;
• опыт, накопленный по эксплуатации локальных подсистем, реализованных на базе персональных СУБД;
• неудовлетворенность руководителей и сотрудников подразделений трудоемкостью расширения состава решаемых задач;
• неудовлетворенность руководителей вуза отсутствием средств автоматизированной интеграции данных разных подсистем;
• выросшие потребности студентов и преподавателей в информации о ходе учебного процесса на всех этапах.

При формировании программы разработки, реализации и внедрения ИИАС необходимо опираться на ряд принципиальных организационных и технологических аспектов.

1. Проектирование типовой ИИАС должно осуществляться на основе обобщенной комплексной функциональной модели вуза, согласованной с нормативной моделью организационной структуры вуза. Разработка этих моделей является важной и достаточно сложной задачей, которую необходимо решать на первом этапе реализации программы.
2. Использование для создания и внедрения ИИАС вуза кадрового потенциала, сетевой, организационной и программной инфраструктуры, сформированных в ходе реализации:

1. При проектировании ИИАС необходимо опираться на современные сетевые информационные технологии, ориентироваться на вузовские и межвузовские компьютерные сети. Использование интернет-интранет технологий в качестве базы для реализации ИИАС не только позволит создать современный информационный комплекс, но и обеспечит такие принципиально важные возможности, как открытость и доступность системы. Это особенно важно для развития новых форм обучения (в том числе дистанционного обучения), формирования информационных потоков в региональные и министерские органы управления и обратно, информирования абитуриентов, студентов, выпускников, населения о формах и программах подготовки и переподготовки, реализуемых вузом.
2. Должна быть обеспечена модульность и расширяемость ИИАС. При проектировании необходимо использовать единые стандарты и технологические решения, должны соблюдаться требования открытых систем: мобильность (переносимость) программных средств, совместимость работы технических и программных средств различных платформ и производителей, возможность расширения, реконфигурации и др. Успешное широкое внедрение ИИАС невозможно без обеспечения механизмов ее адаптации к потребностям и условиям конкретного вуза.
3. Необходимо обеспечить документируемость создаваемой системы на всех этапах ее создания.
4. При реализации финансово-бухгалтерских подсистем возможна адаптация и развитие одной из промышленных информационных систем управления предприятием, реализованных в соответствии с технологическими принципами данного проекта.
5. Эффективная разработка столь сложного проекта, как создание ИИАС, распределенным коллективом участников сразу из нескольких вузов может быть осуществлена только при условии использования современных технологий проектирования по типу CASE-технологии ORACLE, поддержанных адекватным лицензионным программным обеспечением (ORACLE-системы в Интернет-центрах) и соответствующими организационными мерами. Необходимо предусмотреть создание библиотек типовых моделей основных бизнес-процессов ИИАС с учетом требований обобщения комплексной функциональной модели и нормативной модели оргструктуры вуза. Спецификация моделей бизнес-процессов должна осуществляться на основе единых технологий и инструментальной среды разработки (например, CASE-технология ORACLE).
6. Реализация системы должна осуществляться на базе использования развитых промышленно-действующих лицензионных программных продуктов, в частности, поставленных в университетские Центры Интернет Oracle server 7.3 и 8, Oracle Designer 2000, Oracle Developer 2000, Oracle OLAP и др.
7. При создании ИИАС должны быть решены задачи информационной безопасности в создаваемой системе (как в сетях, так и в СУБД).
8. В процессе разработки ИИАС вуза необходимо предусмотреть регистрацию и сертификацию разработанных программных продуктов и баз данных.
9. Необходимо предусмотреть этапность при реализации программы, обеспечивающую эффективный контроль за ходом ее выполнения и возможность корректировки задач и целей программы.
10. Для успешного выполнения программы необходима консолидация средств из различных источников, включая государственный бюджет, региональные средства, средства различных фондов; привлечение к взаимовыгодному сотрудничеству ведущих отечественных и зарубежных фирм и университетов.
11. При создании ИИАС требуется обеспечить нормативную поддержку разработки.
12. Реализация ИИАС должна строиться на основах разумного сочетания принципов преемственности и развития.

Создаваемая ИИАС, как и другие крупные информационные системы, характеризуется следующими особенностями:

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

Достоинства централизованной архитектуры мэйнфреймов очевидны — это простота администрирования, защиты информации и ряд других.

С появлением персональных компьютеров (ПК) с разнообразными средствами ввода и отображения информации стало возможным иметь вычислительные и информационные ресурсы на собственном рабочем месте и управлять ими по собственному разумению. Но это не главное. Появилась идея переноса части системы для выполнения на ПК, непосредственно на рабочем месте. Таким образом, система стала распределенной — одна ее часть выполнялась на центральном компьютере, другая — на ПК, который был объединен в сеть с центральным. Появилась исключительно удобная и естественная парадигма клиент-сервер — модель взаимодействия компьютеров и программ в сети.

Но наряду с неоспоримыми достоинствами такого рода систем проявились и их недостатки.

Во-первых, такую систему трудно администрировать. Сложно представить себе администратора, которому нужно обновить программу на десятках или даже сотнях компьютеров, расположенных в разных помещениях, зданиях, городах и т.п. Ситуация усугубляется неоднородностью компьютеров на рабочих местах.

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

Они отличаются следующими чертами:

• на сервере порождается конечный продукт — информация в форме, предназначенной для представления пользователю (а не полуфабрикат в виде данных);
• для обмена информацией между клиентом и сервером используется протокол открытого стандарта (стандарт передачи данных в сети Интернет);
• информация передается клиентам в виде, пригодном для восприятия человеком (в интерфейсе навигатора Интернет, который уже начинает вытеснять пользовательский интерфейс многих программных продуктов, например, операционных систем);
• прикладная система сконцентрирована на сервере (на клиентах кроме программ-навигаторов, вызывающих Java-апплеты, ничего нет).

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

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

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

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

Когда мы переходим к технологии Интранет, мы качественно упрощаем себе задачу.

Во-первых, гораздо большая часть ресурсов централизована. Централизованными ресурсами не только легче управлять, но их и легче защищать.

Во-вторых, внешние интерфейсы оказываются унифицированными, стандартными. Способов взаимодействия удаленного рабочего места с центральным сервером оказывается очень немного. Не нужно более заботиться о десятках или даже сотнях приложений на компьютерах-клиентах и для каждого из них решать задачу защиты взаимодействия клиента с сервером. Достаточно обеспечить стандартное решение для одного рабочего места, которое и будет стандартным для всех.

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

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

Для создания и сопровождения ИИАС целесообразно использовать CASE- технологию на базе CASE-средств.

Под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения (ПО) - приложений и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

В частности, для реализации рассматриваемого проекта может быть использована технология, разработанная фирмой ORACLE — Oracle Custom Development Method (CDM), в которой детально описывается процесс разработки информационных систем в виде согласованной схемы.

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

В качестве инструмента поддержки CDM используется CASE-среда -Oracle Designer 2000.

Использование CASE-технологии позволит обеспечить системный подход с использованием методов структурного и объектно-ориентированного анализа и проектирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т.д.

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

Успешное внедрение CASE-средств должно обеспечить такие выгоды как:

• высокий уровень технологической поддержки процессов разработки и сопровождения ПО;
• соблюдение стандартов, документирование;
• успешность внедрения разработки;
• формирование и актуализация банка типовых моделей основных бизнес-процессов ИИАС.

Основным нормативным документом, регламентирующим жизненный цикл (ЖЦ) программного обеспечения, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Для создания ИИАС предлагается использовать спиральную модель ЖЦ (рис. 1), делающую упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов.

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

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой, и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:

• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
• DFD (Data Flow Diagrams) диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

В основе технологии Хранилищ данных лежат две идеи. Во-первых, это интеграция ранее разъединенных детализированных данных, то есть исторических архивов, данных из традиционных СОД, данных из внешних источников, в едином Хранилище данных, их согласование, и, возможно, агрегация. Во-вторых, разделение наборов данных, используемых для операционной обработки, и наборов данных, используемых для решения задач анализа.

Предметом концепции Хранилищ данных являются сами данные. После того как традиционная система обработки данных реализована и начинает функционировать, она становится ровно таким же самостоятельным объектом, как и любой производственный процесс. А данные, в этом смысле, обладают ровно теми же свойствами и характеристиками, что и любой промышленный продукт: сроком годности, местом складирования (хранения), совместимостью с данными из других производств, рыночной стоимостью, транспортабельностью, комплектностью, ремонтопригодностью и т.д.

• Неоднородность программной среды.
• Распределенность.
• Защита данных от несанкционированного доступа.
• Построение и ведение многоуровневых справочников метаданных.
• Эффективное хранение и обработка очень больших объемов данных.

Как показывает практика, реализация проекта Хранилища данных должна осуществляться итерационно, небольшими шагами. И на каждом этапе должна выполняться переоценка достигнутых результатов, целей и приоритетов.

Как уже было сказано выше, концепция Хранилищ данных определяет лишь самые общие принципы построения аналитической системы и, в первую очередь, сконцентрирована на свойствах и требованиях к данным, но не способах их организации и представления в целевой БД и режимах их использования.

Сегодня существует несколько различных достаточно специализированных категорий инструментальных средств, ориентированных на реализацию аналитических приложений. Среди них наиболее распространенными и употребимыми для задач построения ИИАС являются:

При этом переход на новый, более “высокий” уровень аналитической обработки данных не только не устраняет, но, наоборот, обычно ещё больше усиливает значимость результатов, получаемых с использованием средств более “низкого” аналитического уровня. Например, как показывает практика, использование средств OLAP не только не устраняет необходимость в традиционных аналитических справках и отчётах (формируемых средствами статического DSS), но наоборот увеличивает их значимость и даже их количество.

Всего три-четыре года назад результатом работы любой аналитической системы являлись регламентированные многостраничные отчеты и диаграммы. Но, как правило, после просмотра такого отчета, у аналитика появлялся не готовый ответ, а новая серия вопросов. Однако, если бы ему захотелось получить ответ на новый, не предусмотренный при проектировании системы вопрос, он мог ждать его часы, а иногда и дни.

Каждый новый запрос в системах, реализуемых на основе технологий статического анализа данных (таблица 2), должен быть сначала формально описан, передан программисту, запрограммирован и, наконец, выполнен. Но после того как аналитик, наконец, получал ответ, часто оказывалось, что решение не могло ждать и оно уже принято, или получен ответ не на совсем тот вопрос.

Элементы статического анализа предусмотрены практически во всех действующих вузовских информационных системах. Именно недостатки такого метода для новых условий функционирования вузов ставят задачу внедрения в рамках ИИАС методов динамического анализа.

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

Для решения аналитических задач можно использовать Oracle Discoverer и Oracle Express

При построении рассматриваемой информационно-аналитической системы в качестве базовых технологий выбираются:

• Интранет-технологии,
• Технологии реляционных баз данных,
• Технология хранилищ данных,
• CASE-технологии,
• OLAP-технологии.

Ядром системы является интегрированная база данных (ИБД), реализованная средствами СУБД Oracle, которая может размещаться как на одном, так и на множестве территориально разнесенных серверов, образующих единое хранилище данных ( рис. 2).

На этапе реализации и (или) внедрения ИИАС в университете в ИБД консолидируются данные из действующих информационных подсистем вуза. При внедрении ИИАС осуществляется постепенное поэтапное вытеснение действующих модулей с заменой на модули ИИАС. На базе ИБД функционирует CASE-система, обеспечивающая ведение проекта создания и внедрения ИИАС.

Внедрение в вузе ИИАС не отвергает (но и не поощряет) существования в его рамках локальных автономных подсистем подразделений. Автономные подсистемы могут взаимодействовать с ИИАС, поставляя и потребляя информацию из ИИАС. Важным фактором является учет существующих подсистем в ИИАС и описание соответствующих интерфейсов информационного взаимодействия.

Логика приложений ИИАС реализуется на серверах приложений или, в ряде случаев, в виде набора клиент-сервер приложений на Developer-2000. Поддержка доступа к интерфейсам интранет-приложений осуществляется через Web-серверы стандартными браузерами.

Для обеспечения работы аналитических приложений исторические и агрегированные данные консолидируются в ИБД и могут быть выгружены в многомерные базы данных, с которыми взаимодействуют OLAP-приложения.

Сервер ИБД подключается к сетевой инфраструктуре вуза с максимально гибким расположением рабочих мест ИИАС на территории вуза. Безопасность системы обеспечивается штатными средствами среды разработки системы и соответствующими административными мерами.

Подключение ИБД к Интернет, использование средств репликации данных позволяют осуществлять передачу потоков данных в вышестоящие органы в наиболее оперативном режиме.

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

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

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

Oracle8 позволяет создавать клиент-серверные системы и Web- приложения. На основе интегрированной базы данных можно создавать прикладные системы с различными по "толщине" клиентами, серверами приложений и т.п.

Несмотря на то что такую систему трудно администрировать, клиентские приложения, разработанные на основе Oracle Developer 2000, т.е. работающие под управлением Oracle Developer 2000 Runtime, должны быть установлены на рабочие места сотрудников, которые занимаются критичными для базы данных вводом и (или) обработкой конфиденциальной информации. Количество таких рабочих мест, работающих параллельно, по предварительным оценкам не будет реально превышать 20-60.

Количество рабочих мест, работающих на основе Web-браузера, может быть существенно больше. В жизненном цикле функционирования ИС следует предусмотреть миграцию некоторых клиент-серверных приложений в Web-приложения по мере развития возможностей серверов приложений WAS (Web Applications Servers). Это позволит упростить администрирование рабочих мест за счет администрирования серверов приложений.

На рабочих местах аналитиков дополнительно устанавливаются программные продукты семейства Oracle Express.

Как и другие университетские базы данных (дистанционное обучение, научно-исследовательская работа и др.) ИБД вуза может быть связана с ИБД других вузов, а также региональными, общероссийскими и международными базами данных (рис. 4). Такие связи необходимы для сбора статистических сведений, знакомства с передовыми идеями и технологиями, обмена опытом и т.д. Для информационного обмена используются средства E-mail, Web и другие.

Кроме того, подсистема должна иметь средства предоставления информации по состоянию учебного процесса для студентов и преподавателей.

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

данное направление является предметом отдельного проекта.

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

Интегрированная информационно-аналитическая система управления вузом должна поддерживать

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

ИИАС должна обеспечивать функционирование и принятие решений по управлению учебным процессом, научно-исследовательской деятельностью, персоналом, состоянием финансов вуза и его структурных подразделений, хозяйственной деятельностью.

получение оперативных данных о состоянии системы образования региона с целью решения вопросов устойчивого развития

получение оперативных данных для более эффективного системой образования.

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

На начальном этапе предполагается выполнить работы, связанные с:

• формированием организационной структуры программы;
• разработкой обобщенной комплексной функциональной модели вуза, согласованной с нормативной моделью организационной структуры;
• созданием функциональной модели ИИАС;
• разработкой механизмов формирования и актуализации комплекса общесистемных классификаторов, словарей, справочников;
• созданием подсистемы управления учебным процессом;
• созданием подсистемы кадрового комплекса в объеме, необходимом для полноценного функционирования учебного процесса;
• инсталляцией созданных подсистем в университетах, участниках проекта;
• опытной эксплуатацией и доработкой подсистем;
• формированием технологии и инфраструктуры внедрения и сопровождения компонент ИИАС.

На следующих этапах предполагается осуществить работы по начальному внедрению системы, созданию и развитию других (достаточно сложных и объемных) подсистем связанных с:

• тиражированием и внедрением системы в другие вузы;
• системой управления штатным расписанием и кадрами вуза;
• системой бухгалтерского учета, многоуровневое управления финансами вуза, расчет заработной платы, учет и управление запасами и материалами;
• информатизацией общего документооборота вуза;
• ведением информации о научных исследованиях и договорах в вузе;
• развитием ИИАС для решения задач ее сопряжения с региональными системами управления профессиональным образованием в межвузовской информационной среде Министерства образования РФ;
• разработкой совместных с Министерством образования РФ программ внедрения ИИАС и развития на их основе региональных и межрегиональных корпоративных информационных пространств;
• разработкой подсистем принятия решений по анализу и совершенствованию учебного процесса;
• системой ведения информации, в том числе пространственной, по зданиям, строениям и помещениям вуза и разработка средств дистанционного доступа к ней;

Организационной базой для создания и внедрения ИИАС вуза является сетевая, организационная и программная инфраструктура, сформированные в ходе реализации:

Первый этап работ по программе реализуется консорциумом российских вузов при поддержке Центрально-Европейского университета.

Для научно-технического руководства программой создаются:

• Совет по управлению программой, определяющий стратегию развития программы. Совет состоит из ректоров университетов – участников программы, представителей Минобразования РФ, ГНИИТТ "Информика" и института "Открытое общество".
• Технический комитет, осуществляющий техническое руководство программой. Члены Технического комитета поддерживают между собой постоянную связь с использованием телекоммуникационных средств, а также проводят совещания (семинары) в соответствии с планом-графиком работ. В члены Технического комитета делегируются от каждого вуза-исполнителя по два представителя, один из которых является специалистом по Oracle.
• Рабочие группы по направлениям создания ИИАС. Координацию деятельности рабочих групп осуществляет Технический комитет.

Общую координацию работ по проекту осуществляет СПбГИТМО (ТУ).

Обеспечивается создание системы организационно-технической поддержки реализации проекта, включающей выбор методов и инструментальных средств для реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний ПО, контроль за сроками и качеством выполняемых работ, обучение персонала и т.п. Система организационно-технического обеспечения поддерживается на основе создания списков рассылки, ftp- и www-серверов участников.

Приложение 1