решений по разным видам деятельности университета имеет свои ад
-
министративные полномочия
,
и технические полномочия ИИС долж
-
ны им полностью соответствовать
.
Данное требование касается также
ИИС других организаций
(
банков
,
заводов и т
.
д
.).
Отличительной чер
-
той ИИС университета является намного большее разнообразие стату
-
сов
,
а зачастую
—
их совмещение
,
для каждого из пользователей си
-
стемы
.
Один человек может выступать в нескольких ролях
,
и эти роли
могут изменяться
(
раз в полгода
,
год
).
Например
,
преподаватель может
быть участником научно
-
исследовательской работы
,
деканом факуль
-
тета и одновременно заведующим кафедрой и куратором студенческой
группы
.
В следующем семестре этот же преподаватель может избавить
-
ся от части обязанностей или получить новые
.
Система должна поддер
-
живать такую динамику изменения статусов сотрудников университе
-
та
.
В
-
пятых
,
архитектура ИИС должна проектироваться с учетом осо
-
бенностей жизненного цикла системы
.
Внедрение ИИС предполагает
ее дальнейшую эксплуатацию
,
развитие и модернизацию
.
Большинство
университетов из
-
за ограниченности финансовых ресурсов не может
привлекать извне высококвалифицированных
(
и дорогостоящих
)
спе
-
циалистов для сопровождения
,
развития и модернизации ИИС
,
а стре
-
мится это делать собственными силами
.
Следовательно
,
архитектура
ИИС должна позволять эксплуатировать систему
,
не выходя за преде
-
лы возможностей штатного расписания университета по соответству
-
ющим категориям сотрудников
.
Рассмотрим теперь влияние перечисленных факторов на архитекту
-
ру ИИС для поддержки управления университетом
.
Разветвленная организационная структура университета подразу
-
мевает наличие сетевой обработки информации
.
Самым распростра
-
ненным вариантом на данный момент является трехзвенная клиент
-
серверная архитектура
(
клиент
—
сервер приложений
—
сервер баз
данных
),
которая используется в большинстве подобных ИИС
.
Ввиду разнородности существующих в университете аппаратных и
программных средств системе необходим
“
тонкий клиент
”.
В этом слу
-
чае на машины пользователей системы ложится минимальная нагруз
-
ка при работе с системой
,
а основная нагрузка приходится на сервер
приложений и сервер баз данных
.
Соответственно
,
учитывая ограни
-
ченные финансовые ресурсы университета
,
легче купить один мощный
сервер баз данных
,
чем заменить ряд клиентских мест
.
В результате
,
достаточно эффективным вариантом архитектуры си
-
стемы является вариант
,
представленный на рис
. 1.
Подобный вариант
68 ISSN 0236-3933.
Вестник МГТУ им
.
Н
.
Э
.
Баумана
.
Сер
. "
Приборостроение
". 2004.
№
2
