Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Разработка автоматизированной образовательной системы

Разработка автоматизированной образовательной системы

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 11.07.2016
Размер файла 960,4 K
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Страница:

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

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

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

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

Рисунок 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. Прецедент «Уведомление участников»

Краткое описание

Прецедент дает возможность АС или КА уведомлять пользователей системы о предстоящем событии.

Актеры

Администратор системы или Контентный администратор

Предусловия

Успешно добавленное в систему событие

Основной поток

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

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

АС или КА вводит текст уведомления. Существует возможность использования служебных слов, как: %recipient_FIO%, %recipient_EMAIL%, %sender_FIO%, %note_NAME% и др.

АС или КА инициирует функцию «Уведомить» (или аналогичную)

Альтернативные потоки

АС или КА инициирует функцию «Уведомить» до того, как введет всю обязательную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию.

Клиент выбирает функцию «Отмена» (или аналогичную) для того, чтобы вернуться к странице события

Постусловия

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

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

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

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

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

Поле

Тип данных

Ограничения

Источник (таблица)

Значение

Примечание

id

int

Уникальное

users

Идентификатор

ПК

Username

varchar(50)

users

Логин пользователя

Обязательное поле

Date_create

datetime

users

Дата создания профиля

Обязательное поле

Date_edit

datetime

users

Дата последнего редактирования

Email

varchar(50)

users

Электронный ящик пользователя

По умолчанию используется эл.ящик, указанный при регистрации

Name

varchar(50)

users

Имя

Patronymic

varchar(50)

users

Отчество

Surname

varchar(50)

users

Фамилия

Birth_date

date

users

Дата рождения

Sex

Binary(1)

users

Пол

Role

int

Целое

roles

Роль пользователя в системе

Ссылка на идентификатор роли

VK_ref

varchar(50)

users

Ссылка на профиль в «VK»

FB_ref

varchar(50)

users

Ссылка на профиль в «Facebook»

TW_ref

varchar(50)

users

Ссылка на профиль в «Twitter»

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

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

Поле

Тип данных

Ограничения

Источник (таблица)

Значение

Примечание

id

int

Уникальное

roles

Идентификатор

ПК

Name

varchar(50)

roles

Название роли

Обязательное поле

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

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

Поле

Тип данных

Ограничения

Источник (таблица)

Значение

Примечание

User_id

Int

Уникальное

pupil

Идентификатор пользователя

Ссылка на идентификатор «users»

School_id

Int

Уникальное

schools

Идентификатор школы

Ссылка на идентификатор из «schools»

grade

Tinyint

pupil

Класс

Увеличивается каждый год 1 сентября, пока не достигнет значения 11.

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

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

Поле

Тип данных

Ограничения

Источник (таблица)

Значение

Примечание

id

int

Уникальное

schools

Идентификатор

ПК

Number

varchar(50)

Целое

schools

Номер школы

Type _id

int

Целое

school_type

Тип школы

Ссылка на справочник «school_type»

City_id

int

Целое

cities

Город

Ссылка на cправочник «cities»

School_src

varchar(50)

schools

Вебсайт школы

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

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

Поле

Тип данных

Ограничения

Источник (таблица)

Значение

Примечание

id

int

Уникальное

school_type

ПК

Name

varchar(50)

school_type

Обязательное поле

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

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

Поле

Тип данных

Ограничения

Источник (таблица)

Значение

Примечание

User_id

int(11)

Уникальное

employers

Идентификатор пользователя

Ссылка на идентификатор «users»

Company_id

int(11)

Уникальное

employers

Идентификатор компании

Ссылка на идентификатор «companies»

Position

varchar(50)

employers

Должность

Размещено на Allbest.ru

...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены