Проектирование и реализация информационной системы

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

Моделирование бизнес-процессов

В данном разделе будут рассмотрены существующая и предлагаемая модели взаимодействия университета и абитуриентов. В начале главы происходит выбор нотации для моделирования бизнес-процессов. Затем приводятся модели AS_IS и TO_BE.

Выбор нотации моделирования бизнес-процессов

Моделирование бизнес-процессов может быть реализовано в рамках различных методик, отличающихся, прежде всего, своим подходом [32]. В соответствии с различными представлениями, методики принято делить на объектные и функциональные (структурные). Принципиальное отличие между функциональным и объектным подходом заключается в способе декомпозиции системы [33].

Яркими примерами функциональной методики является нотация ARIS и IDEF, в качестве примера объектной методики можно привести нотацию UML.

Для описания модели текущего взаимодействия было принять решение использовать одну из функциональных методик, поскольку функциональный подход в целом лучше дает представление о существующих функциях в организации и о методах их реализации [32]. Присутствие в нотации ARIS eEPC заранее определенных объектов для описания входящих/исходящих документов, информации, ролей и т. д. позволяет более полно отразить необходимую для бизнес-процесса информацию.

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

Анализ существующей модели взаимодействия с абитуриентами

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

• 1. Отдел по организации приема абитуриентов.
• 2. Отдел по связям с общественностью.
• 3. Отдел развития университетского округа НИУ ВШЭ — Пермь [34].

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

Рассмотрим структуру управления. Во главе пермского кампуса стоит директор Галина Емельяновна Володина; пять заместителей директора курируют различные направления деятельности (см. табл. 2.1. Заместители директора и курируемые направления). Кураторами направлений, имеющим непосредственное отношение к работе со школьниками-абитуриентами, являются Алла Владимировна Оболонская и Светлана Геннадьевна Левина.

Таблица 2.1. Заместители директора и курируемые направления

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

Заместители директора и подконтрольные подразделения.

На следующем этапе определим основные входы и выходы подразделений. Разделим их на:

• 1) школьников, участвовавших в каких-либо мероприятиях и решивших продолжить взаимодействие с НИУ ВШЭ — Пермь (подать документы);
• 2) школьников, решивших не подавать документы;
• 3) учителей, участвовавших в каких-либо мероприятиях;
• 4) мероприятия по привлечению школьников (PR — мероприятия);
• 5) мероприятия образовательного характера (дополнительные курсы, олимпиады);
• 6) результаты мониторинга образовательных услуг;
• 7) официальный вебсайт университета.

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

На следующем этапе в соответствии с положениями выбранных ранее подразделений необходимо определить их основные функции (см. табл. 2.3. Функции подразделений) [35].

Столбец «БП» содержит информацию об отношении функции подразделения к определяемым далее бизнес_процессам.

Таблица 2.2. Функции подразделений

Таблица 2.3. Функции подразделений (продолжение)

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

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

Рисунок 2.1. Бизнес-процессы организации.

Среди обеспечивающих его процессов выделим процессы, как:

• 1) проведение PR — мероприятий;
• 2) оказание информационной поддержки;
• 3) работа со школьными учителями;
• 4) проведение мониторинга рынка образовательных услуг;
• 5) организация Приемной кампании;
• 6) организация дополнительного образования школьников.

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

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

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

Определим узкие места построенного бизнес-процесса.

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

Рисунок 2.2. Бизнес-процесс «Проведение PR-мероприятия» (начало).

Рисунок 2.2. Бизнес-процесс «Проведение PR-мероприятия» (окончание).

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

В качестве одного из недостатков описанного БП также является выполнение всех этапов сотрудниками НИУ ВШЭ — Пермь. К работе над некоторыми этапами, как например, подготовка и сбор информации, могут быть привлечены студенты, чья заработная плата будет существенно ниже. Ранее также были описаны преимущества волонтерского движения для университета и студентов.

На основе анализа БП были определены следующие недостатки существующей модели бизнес-процесса:

• 1. Основными причинами задержек является необходимость обработки информации различными подразделениями НИУ ВШЭ — Пермь.
• 2. Для организации информационной поддержки мероприятия используются различные информационные системы, что ведет к отсутствию единой базы данных пользователей.
• 3. Этапы БП выполняются исключительно сотрудниками НИУ ВШЭ — Пермь, без привлечения к работе студентов.

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

2.1.1. Построение модели TO_BE

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

Для представления функций системы была описана диаграмма вариантов использования (см. рис. 2.1. Диаграмма вариантов использования). Диаграмма приписывает прецеденты к субъектам и позволяет установить отношения между ними:

Диаграмма 2.1. Диаграмма прецедентов.

В созданной диаграмме смысл отношения «расширить» состоит в том, что, например, прецедент «Добавление и редактирование» события может быть расширен прецедентом «Уведомление участников». Между администратором системы (АС), контентным администратором (КА), публицистом (Пт) и обычным пользователем (ОП) существует отношение обобщения. Таким образом, публицист обладает всеми возможностями обычного пользователя, контентный администратор — публициста, а администратор системы — возможностями контентного администратора и доступом к системе администрирования.

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

Описание прецедентов началось с описания прецедента «Добавление и редактирование события», доступного для контентного администратора и администратора системы (см. табл. 2.4. Прецедент «Добавление и редактирование события»):

Таблица 2.4. Прецедент «Добавление и редактирование события»

Таблица 2.5.Прецедент «Уведомление участников»

Администратор системы и контентный администратор могут сформировать отчет о подтвердивших участие (см. табл. 2.6. Прецедент «Формирование отчета»):

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

Базовой сущностью для хранения данных о всех пользователях системы является таблица «users», содержащая личную и контактную информацию пользователя (см. табл. C.1. Хранение данных пользователей системы — «users»).

Хранение данных пользователей системы — «users»

Следующая таблица содержит список ролей пользователей в системе (см. табл. C.2. Список ролей пользователей — «roles»). Изначально в системе определены такие роли, как: Администратор системы, Контентный администратор, Публицист и Обычный пользователь. При регистрации пользователи получают роль обычного пользователя. Изменение роли возможно в подсистеме администрирования.

Список ролей пользователей — «roles»

В ходе регистрации пользователи могут указать дополнительную информацию. Например, ученики школ могут добавить информацию о своем образовательном учреждении (см. табл. В.3. Дополнительная информация для учеников школ — «pupil»):

Дополнительная информация для учеников школ — «pupil»

Информация о школах хранится в специальном справочнике школ (см. табл. В.4. Информация о школах — «schools»).

Информация о школах — «schools»

Для каждой школы в системе определяется тип школы (общеобразовательная, лицей, гимназия и т. д.), номер, а также город, в котором она расположена. Для определения типа школы была создана отдельная таблица (см. табл. C.5. Информация о типе школы — «school_type»):

Информация о типе школы — «school_type»

Работодатели, заинтересованные в взаимодействии с факультетом, могут указать компанию, в которой работают, и свою должность (см. табл. C.6. Дополнительная информация для работодателей — «employers»):

Дополнительная информация для работодателей — «employers»