Пояснительная записка (1206295), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

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

3.5 Требования к защите информации от несанкционированного доступа

3.5.1 Требования к информационной безопасности

В системе должны быть реализованы:

• идентификация пользователя;

• проверка роли пользователя;

• разграничение прав доступа в зависимости от роли.

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

• нет доступа к объекту;

• нет доступа на чтение;

• нет доступа на изменение;

• нет доступа на добавление;

• нет доступа на удаление.

• доступ (к объекту/части объекта) только на чтение;

• доступ (к объекту/части объекта) только на изменение;

• добавление объекта;

• удаление объекта.

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

3.6 Требования по сохранности информации при авариях

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

3.7 Требования по стандартизации и унификации

Разработка системы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEF1Х в рамках рекомендаций по стандартизации Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования». Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 4.х и BPWin 4.х или Astah. Для работы с БД должен использоваться язык запросов SQL в рамках стандарта ANSI SQL-92 (третья версия языка запросов к базам данных SQL).

4 Требования к функциям (задачам), выполняемым системой

4.1 Блок администратора

4.1.1 Подсистема контроля действий менеджеров

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

4.2 Блок менеджера

4.2.1 Подсистема обработки заявок

Подсистема обработки заявок должна состоять из следующих модулей:

4.2.1.1 Модуль новых заявок

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

4.2.1.2 Модуль заявок менеджера, находящегося в системе

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

4.2.1.3 Модуль архива заявок

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

4.2.2 Ведение базы отзывов клиентов

1. Подсистема управления справочной информацией

Подсистема управления справочной информацией должна обеспечивать ведение следующих справочников:

• реестр «Категории туров»;

• реестр «Способы передвижения»;

• реестр «Страны»;

• реестр «Курорты»;

• реестр «Регионы»;

• реестр «Населенные пункты».

4.2.4. Подсистема управления разделом вопросов

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

4.3 Блок клиента

4.3.1 Подсистема управления личными данными

Подсистема управления личными данными включает в себя:

• добавление личных данных пользователя;

• редактирование существующих данных.

4.3.2 Подсистема управления закладками

Данная подсистема обеспечивает хранение истории изменений туров, которые клиент добавляет в закладки;

4.3.3 Модуль истории личных заявок

4.3.4 Модуль истории личных отзывов

5. Требования к видам обеспечения

5.1 Требования к информационному обеспечению

5.1.1 Требования к составу, структуре и способам организации данных в системе.

Модель данных системы физически должна быть реализована в реляционной СУБД.

5.1.2 Требования по применению систем управления базами данных.

Для реализации хранения данных должна использоваться СУБД Microsoft SQL Server.

5.2 Требования к лингвистическому обеспечению системы

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

5.3 Требования к программному обеспечению

Для описания объекта автоматизации должен использоваться Erwin или Astah. Для реализации алгоритмов манипулирования данными в системе необходимо использовать стандартный язык запроса к данным SQL и его процедурное расширение. Для организации диалога системы с пользователем должен применяться графический оконный пользовательский интерфейс. Для управления Web – приложением должны использоваться следующие браузеры: IE 11, Edge 15, Firefox 53, Chrome 58, Safari 10.1, Opera 44 и выше с поддержкой JavaScript.

5.4 Требования к техническому обеспечению

Минимальные требования к хостингу: процессор – 2 ядра с частотой 2ГГц, объем диска – 30 Гб, скорость подключения – 10 Мбит/с, размер оперативной памяти – 1500 Мб. Персональные компьютеры пользователей должны удовлетворять требованиям, предъявляемым к типовым рабочим станциям.

6 Требования к методическому обеспечению

Комплексы нормативных документов на разработку информационной системы:

• ГОСТ 34.601– 90. Автоматизированные системы. Стадии создания;

• ГОСТ 34.602– 89. Техническое задание на создание автоматизированной системы;

• РД 50– 34.126– 92 Рекомендации. Правила проведения работ при создании автоматизированных систем.

2.2 Проектирование бизнес-процессов и структуры системы

Разработка модели информационной системы осуществляется с помощью объектно-ориентированного подхода для автоматизации работы турагентства. Туроператор заключает с турагентом агентский договор, согласно которому агенту поручается реализовывать туры, сформированные туроператором, за вознаграждение. Работа информационной системы турагентства осуществляет структурирование туров и представление их в удобном для пользователя виде, позволяет забронировать тур, кроме того, клиент может оставить отзыв о туре и поставить оценку. Предметом автоматизации являются процессы работы с клиентами, систематизация, хранение, накопление данных, необходимых для функционирования турагентства, бронирование туров, поисковое продвижение коммерческих предложений (туров). При ведении личного кабинета, хранятся следующие данные: ФИО, дата рождения, почта, номер телефона, туры в закладках, ближайшие туры, пройденные туры, отзывы. Для того чтобы пользоваться услугами информационной системы (бронирование тура) пользователю необходимо пройти регистрацию. При подтверждении бронирования менеджером на определенный тур количество мест уменьшается. Проектирование информационной системы выполняется на основе объектно-ориентированного подхода и языка UML.

2.2.1 Разработка функциональной модели

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

• подбор тура по заданным критериям;

• регистрация пользователя;

• бронирование тура;

• оставление отзыва;

• формирование и модерация коммерческих предложений (туров);

• модерация прав и аккаунтов.

Так же выделим актеров, взаимодействующих в информационной системе:

• администратор (главный менеджер) – сотрудник предприятия, отвечающий за добавление и контроль деятельности менеджеров;

• менеджер – сотрудник предприятия, осуществляющий организацию продаж и работу с клиентами;

• авторизованный клиент – человек, который имеет возможность добавление туров в закладки, бронирование туров и оставление отзывов;

• не авторизованный клиент – человек, который имеет возможность просмотра предложений.

На рисунке 2.1 изображена контекстная диаграмма вариантов использования информационной системы турагентсва.

Рисунок 2.1 – Контекстная диаграмма вариантов использования

На рисунке 2.2 показана декомпозиция варианта использования «Подбор тура». Для того чтобы клиент смог подобрать тур, ему желательно определить дату поездки и какие-нибудь другие параметры (например, сезон, продолжительность, название) или же просто выбрать категорию тура (например, пляжный отдых или горные путешествия). После чего клиент выбирает дату поездки.

Рисунок 2.2 – Диаграмма декомпозиции варианта использования «Подбор тура»

Далее рассмотрим декомпозицию варианта использования «Бронирование тура», представленную на рисунке 2.3. На ней взаимодействуют два актера: пользователь и менеджер. Для того чтобы забронировать тур, клиенту необходимо после выбора тура, нажать кнопку «Забронировать». После чего будет проверяться статус клиента, авторизован он или нет, а также проверка наличия свободных мест в туре. Если клиент не авторизован, то он перенаправляется на страницу «Регистрация». После того, как клиент совершил все необходимые операции, в интерфейсе менеджера появляется заявка, и в зависимости от того подтвердит он ее или нет, клиенту должно прийти письмо с ответом. Если менеджер подтвердил заявку, то данный тур будет добавлен в личный кабинет клиента в графу «Ближайшие туры».

Рисунок 2.3 – Диаграмма декомпозиции варианта использования «Бронирование тура»

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

Характеристики

Список файлов ВКР