Автоматизированная система бронирования для авиа-компании

Разработка автоматизированной системы (далее АС) должна вестись с учетом программного обеспечения, имеющегося в распоряжении компании, в данном случае, это платформа IBM Lotus Notes/Domino. Поэтому компании не надо тратить деньги на приобретение программного обеспечения для разработки АС.
Для осуществления вышеперечисленного необходимо решить следующие задачи:
• изучить предметную область;
• изучить средства для создания АС, включая IBM Lotus Notes/Domino;
• проанализировать имеющиеся приложения на базе IBM Lotus Notes/Domino;
• проанализировать какие типы пользователей будут работать с системой, и какие у них будут роли;
• разработать компоненты и сформировать с их помощью приложение;
• провести тестирование приложения.

Отсутствует ряд рисунков, но большая часть в наличии, поэтому цена ...

1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Описание объекта автоматизации
1.2 Общее описание системы
1.3 Обзор проектных решений и обоснование необходимости своей разработки
2 ПОСТАНОВКА ЗАДАЧИ
2.1 Цель и задачи автоматизации
2.2 Описание автоматизируемых функций
2.3 Анализ выходной/входной информации
2.4 Требования к обеспечению подсистемы
3 ПРОЕКТИРОВАНИЕ ВИДОВ ОБЕСПЕЧЕНИЯ
3.1 Проектирование информационного обеспечения
3.2 Проектирование программного обеспечения
4 ОПИСАНИЕ РАБОТЫ СИСТЕМЫ
4.1 Настройка системы
4.2 Описание программы
4.3 Руководство пользователя

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

Стилистика Evoko Room Manager хорошо сочетается как с классическим, так и с современным интерьером.Если у сотрудников есть опыт бронирования совещаний при помощи Outlook, то они легко освоят Evoko Room Manager. Иконки меню на сенсорном экране интуитивны, поэтому не требуется особых навыков для управления устройством Evoko Room Manager – задать продолжительность мероприятия можно просто коснувшись нужного символа. Данные, введенные при помощи Evoko Room Manager и Outlook, синхронизируются автоматически. Если мероприятие затянулось, то достаточно выйти из зала и прикоснуться к экрану Evoko Room Manager и система самостоятельно подберет альтернативное помещение для продолжения мероприятия, если в занимаемом зале на ближайшее время уже забронировано другое мероприятие.Однако у данной системы есть недостаток, который заключается в невозможности управления расписанием конференц-залов, находящихся в других городахДалее приведена сводная сравнительная таблица (таблица 1) систем бронирования Evoko Room Manager, Gesroom, Booking Engines и одного из online- сервисов (online-бронирование конференц-залов на сайте Hotelpoisk).Таблица 1.1 – Сравнительные характеристикиEvoko Room ManagerGesroomBooking EnginesБронирование к-зна сайте HotelpoiskДоступ к ресурсу через сеть Internet+++Доступ к ресурсу через локальную сеть+Возможность рассылки почтовых уведомлений+++Возможность продления мероприятия за пределы заявленного времени+Наглядность и интуитивное управление++Территориально не ограничено (конференц-залы в разных городах)+Техническая поддержка мероприятий++Мобильное приложение+Управление другими ресурсами (питание, парковка и т.д.)+++Из данной таблицы можно сделать вывод, что каждое из описанных аналогов хорошо по своему, однако есть некоторые функции, которые, учитывая современный уровень развития IT-технологий и скорость вращения деловой среды, просто необходимы при работе с подобными системами, но они присутствуют не во всех рассматриваемых системах.Например, если организация имеет достаточно разветвленную организацию (наличие дочерних предприятий, как в Авиакомпании), то существует необходимость в наличии связи между филиалами для принятия оперативных решений, а это значит, что должна быть организована связь между конференц-залами всех филиалов. Такую возможность может предложить только online-сервис на сайте Hotelpoisk.С целью экономии многие предприятия ограничивают сотрудников в доступе к сети Internet. Учитывая этот фактор, возникает необходимость доступа к системе бронирования конференц-залов из локальной сети компании. Такая возможность существует только при работе в системе Evoko Room Manager.Не будем забывать и то, что многие деловые люди современного мира для эффективной организации своего бизнеса пользуются смартфонами и соответствующими приложениями. Поэтому когда на предприятии возникает проблема особой важности, требующая скорейшего или немедленного решения, и нет времени или возможности подключаться к системе бронирования посредством рабочей станции (компьютера), руководителю необходимо самостоятельно забронировать конференц-зал, используя мобильное приложение системы бронирования. Такой тип работы с системой реализован только в системе бронирования Booking Engines.Учитывая всё описанное выше, можно сделать вывод о необходимости разработки приложения, отвечающего всем современным требованиям делового мира. А именно: приложение, доступ к которому можно осуществлять как посредством рабочей станции (ПК), находящейся в состоянии подключения к сети Internet или к локальной сети компании, так и с помощью смартфона посредством мобильного приложения; приложение, в котором можно забронировать любой конференц-зал любого филиала компании или все сразу (например, для конференции), находясь в любом из филиалов компании;приложение, для управления которого не требуются особые навыки работы, поскольку его интерфейс просто и интуитивно понятен.2 ПОСТАНОВКА ЗАДАЧИ2.1 Цель и задачи автоматизацииАвиакомпания является очень крупной развивающейся организацией, поэтому количество дочерних сообществ и представительств Авиакомпании в различных городах России и за рубежом довольно большое количество и для нормального и непрерывного функционирования компании связь между ними должна быть постоянной. Организация конференц-залов так же служит для поддержания данной связи (селекторная связь, совещания, переговоры и т.п.), поэтому для компании целесообразна синхронизация работы конференц-залов в разных городах путем работы с модулем бронирования свободного времени работы конференц-зала в уже привычной для сотрудников СУБД.Целью создания автоматизированной системы бронирования является автоматизация и упрощение процесса организации работы конференц-зала, в который входит автоматическое составление расписания работы конференц-зала и рассылка почтовых уведомлений участникам мероприятия, проводимого в конференц-зале.Для полноценной работы в АС должны быть реализованы следующие функции:наглядное отображение свободной даты в расписании работы конференц-зала;наглядное отображение в выбранной дате забронированного и свободного времени работы конференц-зала (с учетом часового пояса);составление списка участников планируемого мероприятия из БД «Адресная книга»;автоматическая рассылка почтовых уведомлений участникам планируемого мероприятия согласно списку;добавление нескольких конференц-залов в карточку одного мероприятия;выбор типа расстановки мест в конференц-зале;указание списка оборудования, необходимого для проведения мероприятия;распечатка отчёта о рассылке уведомлений;получение печатного варианта карточки мероприятия.Для реализации данных функций необходимо, чтобы система взаимодействовала с имеющейся в Авиакомпании СУБД. Это можно осуществить путем разработки АС на основе СУБД на платформе IBM Lotus Notes, так как в данной СУБД есть возможность создания дополнительных приложений. Таким образом, данная АС будет являться дополнительным приложением в СУБД.Взаимодействие АС с СУБД необходимо по нескольким причинам:данная СУБД имеет большой спектр возможностей и широко применима в организации работы сотрудников компании (нет необходимости приобретения нового или дополнительного программного обеспечения);СУБД давно является привычным инструментом работы почти всех сотрудников компании (период адаптации к новой системе сводится к минимуму, т.е. будет необходимо всего лишь ознакомиться с инструкцией пользователя);ФИО всех сотрудников и их почтовые адреса уже внесены в СУБД (нет необходимости вручную добавлять информацию такого типа в карточку события);функция рассылки почтовых уведомлений входит в функционал данной СУБД (сокращается время разработки приложения и длина программного кода).2.2 Описание автоматизируемых функцийПосле авторизации в СУБД создает новую регистрационную карточку, вводит дату и времяПомощник руководителя (секретарь)АС«Конференц-залы»А) Зал занят – Сообщает ФИО и № телефона сотрудника, забронировавшего залБ) Зал свободен – Добавляет зал в поле регистрационной карточкиБронирует зал путем заполнения регистрационной карточкиПроверяет занятость зала на запрашиваемую дату и времяСообщает регистрационные данныеА) Зал занят – Согласовывает новую дату и времяБ) Зал свободен – Сообщает об успешном бронировании залаА) Зал занятБ) Зал свободенСообщает согласованную датуОбновляет информацию в расписании залаЭлектронное расписание работы залаДействия аналогичные помощнику руководителяРуководительРисунок 2.1 – Схема информационных потоков (как будет)Если сравнивать между собой схемы, приведенные на рисунке 1.2 и на рисунке 2.1 («как есть» и «как будет» соответственно), то можно заметить, что в целом схема информационных потоков не изменится. Однако, есть несколько существенных отличий:благодаря добавлению в схему звена «АС «Конференц-залы» стало возможным исключить из схемы «как есть» согласование даты и времени мероприятия посредством телефонного звонка, что существенно упростит процесс бронирования зала, а так же сильно сократит временной промежуток от запроса свободной даты и времени до фактического бронирования зала;введение в схему «АС «Конференц-залы» вместо звена «Ответственный за работу конференц-зала» позволит если не совсем исключить, то минимизировать печально известный на любом производстве «человеческий фактор»;наличие в схеме звена «Электронное расписание работы зала» совсем не означает, что процесс бронирования будет замедлен (как это происходило в схеме «как есть»), а совсем наоборот - пользователь (руководитель или помощник) сможет видеть загруженность бронируемого зала, наглядно отображаемую в календарном расписании работы зала, самостоятельно, без участия «Ответственного за работу конференц-зала».Таким образом, можно сделать вывод о том, что если следовать схеме «как будет», то будут автоматизированы следующие функции системы:Составление расписания работы зала. Электронное расписание будет формироваться в электронном виде и обновляться автоматически, что исключит потерю информации (как в случае с бумажным носителем) и ее дезорганизацию.Проверка бронирования зала на требуемую дату и время. Процесс проверки занятости зала будет автоматически выдавать сообщение о сотруднике, забронировавшем зал на запрашиваемую дату и время, для связи с ним в случае необходимости согласования каких-либо моментов.Рассылка уведомлений участникам события. Процесс рассылки уведомлений всем участникам события будет автоматически активирован пользователем, который создал карточку события и составил в ней список участников с помощью СУБД, поэтому нет необходимости вручную выполнять рассылку через почту.Информация о сотруднике, забронировавшем зал. Информация о сотруднике, который зарегистрировал бронирование зала, будет автоматически фиксироваться АС. Эти данные АС будет «подтягивать» из БД «Адресная книга» при авторизации сотрудника в СУБД, так что необходимость в бумажном носителе полностью отпадает.2.3 Анализ выходной/входной информации2.3.1 Выходная информацияНа выходе системы будет происходить формирование расписания работы конференц-зала, которое сможет просматривать любой идентифицированный пользователь с целью поиска свободной даты для создания планируемого события или же ответственный за работу конференц-зала с целью определения объёма работ по организации того или иного планируемого события в соответствие с созданной карточкой события. Характеристики данного выходного параметра системы приведены в таблице 2.1.Таблица 2.1 – Характеристики первого выходного сообщенияХарактеристикаЗначениеИдентификаторТабельный номерФорма представленияЭкранная формаПериодичность выдачиПо рассписаниюПолучательСотрудники авиакомпанииНазначениеОбновление БД GLPIОписаниеПосле создания и сохранения пользователем карточки планируемого события нажатием кнопки «Уведомить участников» АС будет осуществлять рассылку уведомлений участникам события. Для контроля присутствия всех участников система будет формировать отчёт о рассылке уведомлений, в котором будет содержаться информация о доставленном/не доставленном сообщении на электронную почту сотрудникам в соответствие со списком, составленным пользователем при создании события. Отчёт о рассылке будет иметь возможность просмотреть как пользователь АС, чтобы своевременно разослать повторное уведомление, так и ответственный за работу конференц-зала с целью определения окончательного количества человек и принятия соответствующих организационных мерах. Характеристики данного выходного параметра системы приведены в таблице 2.2.Таблица 2.2 – Характеристики второго выходного сообщенияХарактеристикаЗначениеИдентификаторОтчёт о рассылкеФорма представленияЭлектронная таблицаПериодичность выдачиПо запросуПолучательПользователь системы, ответственный за работу конференц-залаНазначениеКонтроль информированности участников событияОписаниеФИО участника, статус уведомления (доставлено, не доставлено)2.3.2 Входная информацияДля подключения к АС любому пользователю будет необходимо сначала авторизоваться в СУБД посредством ввода личных учетных данных. Характеристики данного входного параметра системы приведены в таблице 2.3.Таблица 2.3 – Характеристики первого входного сообщенияХарактеристикаЗначениеИдентификаторУчетные данныеФорма представленияЭлектронная таблицаЧастота поступленияПо запросуИсточникПользователь системыОписаниеЛогин, парольСледующим входным параметром системы будет являться карточка события, информацию в которую будет вносить идентифицированный пользователь системы. Данный параметр будет содержать в себе всю информацию, необходимую для организации планируемого события. Характеристики данного параметра системы приведены в таблице 2.4.Таблица 2.4 – Характеристики второго входного сообщенияХарактеристикаЗначениеИдентификаторКарточка событияФорма представленияЭкранная формаЧастота поступленияПо запросуИсточникПользователь системыОписаниеТема события, председатель (инициатор), повестка, перечень документов для проведения события, дата события, период времени для события, список участников, список необходимого оборудования, место проведения, тип расстановки мест.Ещё одним входным параметром будет список почтовых адресов сотрудников, участвующих в планируемом событии, который будет загружаться из СУБД путем выбора ФИО участвующего в событии сотрудника. В соответствие с этим списком СУБД будет рассылать уведомления о событии на соответствующие почтовые адреса. Характеристики данного параметра системы приведены в таблице 2.5.Таблица 2.5 – Характеристики третьего входного сообщенияХарактеристикаЗначениеИдентификаторСписок почтовых адресовФорма представленияЭкранная формаЧастота поступленияПо запросуИсточникПользователь системы, СУБДОписаниеФИО, почтовый адрес2.4 Требования к обеспечению подсистемыДля реализации вышеперечисленных операций нет необходимости в приобретении дополнительных аппаратных средств или организации дополнительных рабочих мест, так как СУБД установлена почти у всех сотрудников компании, то и приложение будет доступно любому пользователю с соответствующим уровнем доступа. Соответствующий уровень доступа должны будут иметь максимум два ответственных сотрудника каждого отдела/подразделения компании (один из которых будет иметь доступ на случай отсутствия на рабочем месте первого).Для ознакомления пользователей СУБД с приложением в АС будет раздел «Помощь», в котором будет находиться инструкция пользователя. А для менее опытных пользователей будет необходимо провести инструктаж по работе с системой дистанционно (посредством программы Radmin) или же на рабочем месте сотрудника.3 ПРОЕКТИРОВАНИЕ ВИДОВ ОБЕСПЕЧЕНИЯ3.1 Проектирование информационного обеспечения3.1.1 Идентификация информационного пространстваДля нормального функционирования АС необходимо создание базы данных, в которой будет храниться информация о планируемых событиях (карточки события) и сотрудниках, участвующих в этих событиях.Данные подлежащие хранению в БД приведены в таблице 3.1.Таблица 3.1 – Данные, хранящиеся в БДНаименованиеИдентификаторТипКол-во знаковИдентификаторпользовательid_uservarchar20ФИО пользователяFIOtext-e-mail пользователяe-mailtext-Номер телефона пользователяN_telvarchar11Номер карточки событияn_cardinteger5Дата событияdate_carddateDatetimeВремя событияtime_cardtimeDatetimeТема событияtema_cardtext-Список документовlist_docobject-Список участниковlist_uchasttext-Тип расстановки местtype_rastext20Список оборудованияlist_devicetext-Название конференц-залаname_zaltext30РасписаниеdatedateDatetimeВремя в расписанииtimetimeDatetimeТема события в расписанииtematext-3.1.2 Разработка ER-моделиНаиболее удобный метод разработки базы данных это ER – метод.Модель сущность-связь (ER-модель) (Entity-Relationship model) — модель данных, позволяющая описывать концептуальные схемы предметной области.ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма).Сущность — реальный или представляемый объект, имеющий значение при решении задачи, информация о котором должна храниться и быть доступной. Сущность, как правило, именуется существительным и имеет экземпляры, каждый из которых должен быть отличен от другого экземпляра, то есть однозначно идентифицируем. На диаграммах сущность обычно изображается прямоугольником с ее именем.Атрибут сущности – это свойство сущности, существенное для решения задач. Атрибуты сущности перечисляются внутри нее (нотация Чена и Баркера) или под прямоугольником, изображающим сущность (нотация Хау). Иногда на диаграммах изображают не все атрибуты сущности, а только ее идентификатор.Связь – ассоциация (зависимость) устанавливаемая между двумя или более сущностями, обычно выражается глаголом. Чаще всего используются бинарные связи, то есть связи между двумя разными сущностями или сущностью и ею же самой. В последнем случае связь называется рекурсивной. В связи выделяются два конца, для каждого конца указывается его имя и степень, т. е. сколько экземпляров сущности участвует в связи, а также класс принадлежности сущности связи (обязательная или необязательная). На диаграммах связи изображают весьма разнообразно. Поскольку ER-модель получила развитие в работах многих авторов, то и графические средства, предложенные ими для изображения ER-диаграмм, отличаются друг от друга. Наиболее распространенными являются нотации Чена, Хау и Баркера. В нотации Хау связь изображается ромбом с именем связи, степень связи – цифрой 1 ( если в связи участвует один экземпляр) и буквами ,например: m, n, p ,(если в связи участвуют несколько экземпляров); обязательность – необязательность связи обозначается точкой на линии связи внутри сущности или снаружи соответственно.На рисунке 3.1 приведена графическая структуры базы АС в нотации Хау.n1dateКонференц-залРасписаниеработаетN_zalmпроходитформирует1ПользовательКарточка событияnnn_cardid usernmучаствуетРисунок 3.1 – ER-модельПосле генерации набора предварительных отношений получилось 7 отношений:пользователь (id_user);карточка события (n_card);расписание (date);конференц-зал (n_zal);работает (id_r, n_zal, date);проходит (id_p, n_zal, n_card);участвует (id_u, id_user, n_card).После получения предварительных результатов проектирования базы данных дальнейшим шагом является проектирование при помощи CASE пакета. Для реализации этого проекта был использован пакет CA ERwin Data Modeler 7.3.В ERwin существует два уровня представления и моделирования – логический и физический. На логическом уровне не учитываются особенности конкретной СУБД, не определяются типы данных и не определяются индексы для таблиц. Целевая СУБД, типы данных, индексы таблиц составляют второй (физический) уровень модели.Создание логической модели включает в себя:создание всех сущностей;определение для каждой сущности своих компонентов (атрибуты, первичные ключи, тип сущности);установка всех связей между сущностями;определение характеристик связей (тип связи, мощность, допустимость нулевых значений, родительская или дочерняя связь).При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности переносятся в состав первичного ключа дочерней сущности (миграция атрибутов). В дочерней сущности они помечаются как внешний ключ (FK). При установлении не идентифицирующей связи, дочерня сущность, остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав не ключевых компонентов родительской сущности.