Проектирование функциональной подсистемы обслуживания клиентов в турфирме

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Уфимский государственный авиационный технический университет Кафедра экономической информатики Форма обучения: заочная Курсовая работа по дисциплине «Проектирование информационных систем»

Проектирование функциональной подсистемы обслуживания клиентов в турфирме Уфа 2013

1. Характеристика предприятия

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

1.2 Экономическая сущность задачи

2. Теоретическая часть

2.1 Описание методологии проектирования и создания выбранного компонента экономической информационной системы

2.2 Обоснование технико-экономической эффективности выбранной технологии проектирования и методика ее расчета

3. Проектная часть

3.1 Описание функциональной модели автоматизируемого процесса («КАК ЕСТЬ»)

3.2 Обоснование необходимости разработки экономической информационной системы

3.3 Техническое задание на разработку

3.4 Описание модели проектируемой информационной системы («КАК ДОЛЖНО БЫТЬ»)

3.5 Формы первичных документов

3.6 Формы результатных документов

3.7 Классификаторы с описанием их структур

3.8 Описание информационной модели

4. Программная часть

4.1 Дерево функций

4.2 Сценарий диалога

4.3 Дерево программных модулей

4.4 Блок-схема одного программного модуля

4.5 Текст разработанного модуля программы

4.7 Программа и методика испытаний

4.8 Описание применения

4.9 Руководство оператора

Заключение

Приложения

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

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

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

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

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

Объектом исследований является туристическая фирма.

1. Характеристика предприятия

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

Туристическая фирма «Стороны света» основана в 2006 году как частное предприятие специалистами, работающим в туризме с 2001 года. Юридический статус компании — «Общество с ограниченной ответственностью». Дата государственной регистрации — 15 ноября 2006 г.

С первых дней своей деятельности фирма «Стороны света» выступала как туроператор по всем видам туризма: выездной, въездной, прием и обслуживание иностранных и российских туристов. Приоритетным остается выездной туризм.

На протяжении всей своей истории «Стороны света» постоянно расширяет спектр своих предложений, количество программ и маршрутов, сегодня география предложений «Стороны света» насчитывает более 50 различных туров.

Туристическое агентство предлагает для своих туристов весь спектр туров по всем видам отдыха во многих странах мира:

— помимо традиционных курортов Турции, Египта, Болгарии, Греции разнообразен выбор по экзотическим маршрутам: Вьетнам, Индонезия, Китай, Тайланд, Япония;

— предоставляется отдых на горнолыжных курортах;

— проводятся экскурсионные туры по странам Европы, городам США.

Одно из самых интересных направлений фирмы — активный отдых и туризм в России: Золотое Кольцо России, Русский Север, природа Алтая, Байкала, Сибири, Урала, Карелии, Камчатки.

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

В плане работы с международными турами, «Стороны света» является турагентом и сотрудничает со всеми крупными туроператорами России по различным направлениям. Например, такими, как: Tez Tour, Инна Тур, Пегас Туристик, Coral Travel, Трансаэро Турс Центр и др.

Процесс продажи туристского продукта в турфирме «Стороны света» включает в себя:

— прием клиента и установление контакта с ним;

— установление мотивации выбора турпродукта;

— предложение туров;

— оформление правоотношений и расчет с клиентом;

— информационное обеспечение покупателя.

Туристическая фирма «Стороны света» является турагентом, то есть, организация приобретает туры у других фирм и так же продает их туристам.

Фирма имеет 3 структурных подразделения: Администрация, Туротдел, Кассы.

Туротдел занимается непосредственно работой с клиентами, составлением заявок, договоров с поставщиками туристических услуг.

1.2 Экономическая сущность задачи

В процессе работы ООО «Стороны света» можно выделить несколько основных операций.

1) Прием заявки. Клиент излагает требования, сопровождая их необходимыми документами (паспорт, загранпаспорт, виза и т. д.). Менеджер по обслуживанию предлагает клиенту оптимальный тур по его требованиям. После этого оформляется Заявка на тур.

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

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

2) Менеджер (консультант), прикрепленный к клиенту, ведет дальнейшие переговоры с вышестоящими органами, консультирует клиента по сбору недостающих документов, бронирует рейсы и гостиницы.

3) Выдача путевки клиенту. Клиент предъявляет бланк заявки, по которой ему передается пакет документов, на основании которых будет осуществлен перелет, заселение и т. д. Менеджер фиксирует факт выдачи.

Турфирма «Стороны света» из суммы предоплаты клиента оплачивает билеты транспортной компании, туристическую услугу у туроператора.

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

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

4) Формирование отчета о предоставленных услугах. С определенной, установленной в компании периодичностью составляется отчетность, где указывается количество и стоимость оформленных путевок.

5) Формирование отчета о выполненных услугах работниками агентства. В конце каждого месяца составляется отчет о выполненной работе каждого сотрудника, основное внимание уделяется количеству и цене выданных путевок.

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

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

Информационные потоки туристической фирмы «Стороны света» представлены на рисунке 1.1.

Рис. 1.1 Информационные потоки турфирмы «Стороны света»

Сводная информация по работе фирмы передается руководителю ООО «Стороны света».

2. Теоретическая часть

2.1 Описание методологии проектирования и создания выбранного компонента экономической информационной системы

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

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

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

Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.

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

Для проектирования функциональной подсистемы обслуживания клиентов в турфирме выбрана методология IDEF0 — методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы.

Функциональная модель IDEF0 предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей — того, к чему нужно стремиться (модель ТО-ВЕ).

Обычно сначала строится модель существующей организации работы — AS-IS (как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, «кто что сделал» и что каждая единица бизнеса добавляет в процесс. Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса.

Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.

Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.

Необходимость автоматизации разработки сложных программных продуктов способствовало появлению программно-технологических средств специального класса — CASE-средств, реализующих технологию создания и сопровождения ИС.

Под термином CASE-средства понимаются программные системы, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

Стратегия выбора CASE-систем для конкретного применения зависит как от целей и потребностей самого проекта, так и от квалификации вовлеченных в процесс проектирования специалистов.

Наиболее популярные CASE-средства: Rational Rose Enterprise, Sybase PowerDesigner, Enterprise Architect, ARIS, пакет программных CASE-продуктов AllFusion Modeler Suite.

Для создания функциональной модели проектируемой информационной системы выбрано программное средство ERWin Process Modeler.

Программные средства CA ERWin Process Modeler (BPwin) 7 и CA ERWin Data Modeler (ERWin) 7, входящих в линейку CASE-продуктов AllFusion Modeler Suite (Computer Associates International, Inc.) получили широкую известность под названиями BPWin и ERWin (BP — от Business Process (бизнес-процесс) и ER от Entity Relation связь-отношение).

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

Кроме стандарта IDEF0, BPwin поддерживает также методологии моделирования DFD и IDEF3.

Функциональность BPwin заключается в создании моделей, проверке их целостности и согласованности. BPwin обеспечивает логическую четкость в определении и описании элементов диаграмм, а также проверку целостности связей между диаграммами.

2.2 Обоснование технико-экономической эффективности выбранной технологии проектирования и методика ее расчета

Для принятия решений о выборе определенного варианта технологии проектирования ИС будем использовать метод анализа иерархий (МАИ). Метод Анализа Иерархий (Analitic Hierarchy Process) разработан американским математиком Т. Саати.

Основное назначение иерархии в МАИ — оценка высших уровней иерархии исходя из взаимодействия ее различных уровней.

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

Этапы решения задачи с помощью МАИ:

1) декомпозиция проблемы через определение ее компонент и отношений между ними, т. е. построение иерархии задачи.

2) осуществление попарного сравнения отдельных компонент иерархии.

Попарные сравнения — это процесс, согласно которому, используя определенную шкалу (табл.1), сравниваются все пары объектов из некоторого списка по какому-либо заданному критерию, указывая каждый раз более предпочитаемый объект (по этому критерию).

Таблица 1

Качественная шкала, используемая в МАИ для попарного сравнения

3) Все результаты попарных сравнений заносятся в соответствующую таблицу (матрицу попарных сравнений), по которой потом проводятся соответствующие вычисления. Каждая ячейка этой таблицы предназначена для хранения результата сравнения двух соответствующих объектов.

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

С помощью МАИ будем исследовать приоритет выбора одной из методологий проектирования ИС: IDEF0, DFD, UML.

Зададим критерии оценки:

К1 — Функциональные возможности;

К2 — Возможность декомпозиции;

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

Построим иерархию объектов и критериев выбора наиболее подходящей методологии (рис. 2.1).

Рис. 2.1 Иерархия задачи выбора наиболее подходящего варианта

Укажем относительные оценки заданных критериев (таблица 2):

Таблица 2

Попарные сравнения критериев

Следующим шагом выполняется сравнение методологий проектирования по каждому критерию отдельно. Данные о сравнении методологий проектирования ИС по перечисленным выше критериям представлены в таблице 3.

Таблицы 3−5

Сравнительные оценки систем по критериям

К1 К2

К3

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

IDEF0 = 0,46

DFD = 0,11

UML = 0,43

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

3. Проектная часть

3.1 Описание функциональной модели автоматизируемого процесса («КАК ЕСТЬ»)

Для выявления направления исследования, рассмотрим функциональную модель осуществления управления туристической фирмой ООО «Стороны света».

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

Модель IDEF0 должна иметь контекстную диаграмму верхнего уровня (А-0), на которой объект моделирования представлен единственным блоком с граничными стрелками. Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя — общее для всего проекта. Диаграмма A-0 устанавливает область моделирования и ее границу.

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

Определим основных участников процесса.

Управление ООО «Стороны света» осуществляют директор фирмы, менеджеры, бухгалтерия. Включим их как участников процесса.

Представим первый уровень функциональной модели на рис. 3.1. Функциональное моделирование в методологии IDEF0 выполнялось в программе Bpwin.

Рис. 3.1. Модель IDEF0. Контекстная диаграмма

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

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

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

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

Рис. 3.2. Модель IDEF0. Уровень А0

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

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

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

На основе договора клиент вносит предоплату за туристическую путевку в бухгалтерию турфирмы.

После этого заявка поступает на выполнение к туроператорам.

Расчет путевки включает в себя расчет проживания, питания, перелета или другого способа поездки, с учетом времени пребывания туриста. Это наиболее трудоемкий процесс в общей модели обслуживания клиентов турфирмы. Детализация процесса «Расчет стоимости тура» показана на рис. 3.3.

Рис. 3.3. Процессы расчета стоимости тура

3.2 Обоснование необходимости разработки экономической информационной системы

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

В нынешнем состоянии деятельность турфирмы автоматизирована частично, большая часть операций и учет заявок составляется при помощи Microsoft Excel, существенно повышающего временные показатели по вводу информации и ведению отчетности по ней. Например, на обработку одной заявки о путевке может быть затрачено до 20 минут, а составление отчета увеличивается до 1−2 часов. Эти факторы заметно понижают эффективность работы, приводят к появлению ошибок и опечаток при вводе данных, делают невозможным оперативное управление деятельностью компании и многофакторный анализ.

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

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

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

3.3 Техническое задание на разработку

1. Наименование программного изделия — «Турфирма». Полное наименование «Информационно-справочная система туристической фирмы».

2. Основание для разработки — задание на курсовую работу по теме «Проектирование функциональной подсистемы обслуживания клиентов в турфирме».

3. Цели. Необходимо автоматизировать деятельность турфирмы в части обслуживания ее клиентов.

4. Назначение разработки. Для туристической фирмы ООО «Стороны света» необходимо разработать базу данных, которая бы хранила записи:

1) о городах-курортах, в какой стране находится, требуется ли виза, какая валюта в ходу;

2) о туристах (клиентах): ФИО, адрес, контактный телефон;

3) о транспортной компании: наименование, вид транспорта;

4) о туре: в какой город, страну, какая стоимость, продолжительность тура, условия отдыха (класс отеля), наличие экскурсий;

5) о заключенных договорах: дата отправления клиента, дата прибытия, тур и его стоимость, количество человек в путевке, сумма договора.

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

ИС «Турфирма» должна хранить все вводимые пользователем сведения в базе данных с возможностью дальнейшего редактирования, удаления записей, а также их сортировки и поиска.

Ввод и редактирование данных БД должно осуществляться с помощью форм клиентского приложения.

Программа должна автоматически рассчитывать сумму путевки.

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

5. Требования к системе

Минимальные аппаратные требования: Pentium III или Athlon 1 ГГц; 512 Мб ОЗУ (RAM); Видеокарта от 128 Мб памяти; от 20 Мб свободного места на жестком диске

Предполагаемый объем архивов, учитывая первый год функционирования системы, примерно составит (годовой объем информации * предполагаемый срок службы техники).

Предполагаемый срок службы техники — 5 лет, так как 5 лет — средний срок полного морального устаревания парка машин и его замены.

ОС Windows XP/Vista/7 в среднем занимают по 1000—1500 Мбайт свободного места на жестком диске.

Учитывая все вышеизложенное, приходим к выводу, что для нормального функционирования базы данных необходимо 100 + 1500 2 Гбайт свободного дискового пространства, однако желательно иметь некоторый резерв свободного места, поэтому рекомендуемый объем свободного места на жестком диске — 2,5 Гбайта. Для осуществления резервного копирования необходимо иметь еще один диск размером 850 Мбайт.

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

В нашем случае для организации информационной базы для хранения заявок клиентов и информации об их движении будем использовать реляционную СУБД Access.

Для разработки клиентской части ИС «Турфирма», обеспечивающей доступ к записям БД, будет использована среда объектно-ориентированного программирования Borland Delphi 7, ориентированная на визуальное проектирование пользовательского интерфейса.

Delphi обладает широким набором возможностей, начиная от проектировщика форм и кончая поддержкой всех форматов популярных баз данных.

6. Проектируемая информационная системы должна быть разработана в несколько этапов:

1. Обследование предметной области;

2. Характеристика информационных потоков турфирмы;

3. Выбор методологии проектирования;

4. Построение функциональной модели;

5. Определение ресурсов на разработку;

6. Определение входных и выходных данных;

7. Разработка классификаторов;

8. Построение информационной модели информационной системы турфирмы;

9. Проектирование интерфейса клиентской части приложения;

10. Разработка сценария диалога пользователя с программой;

11. Написание программных модулей приложения;

12. Составление руководства оператора.

7. Техническая документация.

Для разработки документации по ИС турфирмы необходимы следующие программные средства: BPWIN, для разработки информационных моделей предметной области; текстовый редактор MS Word любой версии 2003/2007/2010.

Данные программные средства являются вспомогательными и используются при осуществлении проектирования.

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

3.4 Описание модели проектируемой информационной системы («КАК ДОЛЖНО БЫТЬ»)

Создание и внедрение информационной системы приводит к изменению условий выполнения отдельных операций, структуры деловых процессов и предприятия в целом. Это приводит к необходимости изменения системы бизнес-правил, используемых на предприятии, модификации должностных инструкций сотрудников. Функциональная модель «КАК ДОЛЖНО БЫТЬ» позволяет уже на стадии проектирования будущей информационной системы определить эти изменения. Применение функциональной модели «КАК ДОЛЖНО БЫТЬ» позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям.

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

Поскольку разрабатываемая система предназначена для оптимизации выполнения функций управления турфирмы, то на функциональной модели «КАК ДОЛЖНО БЫТЬ» покажем область внедрения информационной системы управления обслуживанием клиентов турфирмы в структуру управления.

В этом случае в процессы «Прием заявки клиентов» (рис. 3.4), «Расчет стоимости тура» (рис. 3.5) будут добавлены процессы ввода и вывода данных ИС.

Рис. 3.4. Процессы приема заявки клиента

Рис. 3.5. Процессы расчета стоимости тура

Разработка и внедрение в деятельности турфирмы информационной системы повысит эффективность труда сотрудников (менеджеров) туристической фирмы, обеспечив оперативность и точность принятия заявок и выполнения расчетов тура и прозрачность ведения отчетности.

3.5 Формы первичных документов

информационный модель программный документ

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

Первичный документ — это письменное доказательство совершения хозяйственной операции или разрешение на ее осуществление.

Основными первичными документами по работе с клиентами турфирмы являются Заявка клиента, Договор с клиентом, Путевка, Счет об оказании услуг.

Перечень документов и их общее описание приведен в таблице 6.

Таблица 6

Первичные документы

Основным документом, связанным с обслуживанием клиента в турфирме, является заявка. Клиент излагает требования менеджеру, сопровождая их необходимыми документами (паспорт, загранпаспорт, виза и т. д.). Менеджер по работе с клиентами заполняет данные о фамилии, имени, отчестве клиента, его паспортных данных, дате рождении, адресе и телефоне; заполняет сведения о выбранном туре, его стоимости, условиях проживания. В заявке перечисляются также условия и сроки оплаты путевки.

Бланк заявки представлен на рис. 3.6.

Рис. 3.6. Форма заявки клиента

Заполняемые в системе документы являются оперативной информацией системы. К оперативной информации относят любые данные, которые необходимы для работы системы.

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

3.6 Формы результатных документов

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

Таким образом, выходная информация ИС «Турфирма» представляет собой базу данных по всем зарегистрированным документам.

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

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

3.7 Классификаторы с описанием их структур

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

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

В базу данных включают таблицы, условно именуемые классификаторами (словарями, справочниками), в которых расшифровывают эти коды.

Для организации задачи разработки ИС «Турфирма» была разработана система классификаторов (справочников):

— классификатор клиентов;

— классификатор стран;

— классификатор городов;

— классификатор туров;

— классификатор сотрудников фирмы.

При проектировании ИС «Турфирма» перечисленные классификаторы будут содержать числовые коды длиной не более 8 символов.

В таблице 7 перечислены используемые коды в таблицах ИС «Турфирма».

Таблица 7

Классификаторы ИС и их структура

3.8 Описание информационной модели

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

Модель туристической фирмы содержит следующие сущности (объекты): СТРАНА, ТУР, ГОРОД, КЛИЕНТ, ТРАНСПОРТ, СОТРУДНИКИ, ЗАКАЗЫ, ПУТЕВКИ.

Если КЛИЕНТ заказывает тур, а для турфирмы это объект ЗАКАЗЫ, впервые, то осуществляется первичная регистрация его данных и сведений. Если же КЛИЕНТ повторно обращается на фирму, осуществляется регистрация только операции ЗАКАЗЫ. Вне зависимости от того, сколько раз данный клиент покупал туры, он имеет уникальный идентификационный код (уникальный ключ). Информация о каждом клиенте включает его ФИО, адрес, телефон.

Таким образом, атрибутами объекта КЛИЕНТ являются КОД, ФИО, АДРЕС, ТЕЛЕФОН. Аналогичным образом описывается объект ТРАНСПОРТ (транспортная компания).

Объект ТУР имеет атрибуты КОД_ТУРА, НАИМЕНОВАНИЕ, ГОРОД, СТОИМОСТЬ, ПРОДОЛЖИТЕЛЬНОСТЬ, ОТЕЛЬ (класс отеля), ЭКСКУРСИИ (наличие экскурсий).

Туры продаются менеджерами компании — сущность СОТРУДНИКИ. Объект СОТРУДНИК описывается следующими атрибутами: КОД, ФИО, АДРЕС, ТЕЛЕФОН, ДОЛЖНОСТЬ, ОКЛАД.

Объект — ЗАКАЗЫ. Его атрибутами являются КОД_ЗАКАЗА, КОД_СОТРУДНИКА, КОД_ТРАНСПОРТА, КОД_ТУРА, ДАТА_ОТПРАВЛЕНИЯ, ДАТА_ПРИБЫТИЯ, КОД_КЛИЕНТА, КОЛИЧЕСТВО_ЧЕЛОВЕК.

Взаимосвязи в информационной модели могут быть трёх типов: «один к одному», «один ко многим» и «многие ко многим». Взаимосвязь «один ко многим» очень распространена при разработках реляционных баз данных.

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

В нашем случае в качестве справочников выступают объекты КЛИЕНТ, ТУР, ГОРОД, СТРАНА, ТРАНСПОРТ, СОТРУДНИК.

В объекте ЗАКАЗЫ имеются атрибуты КОД_КЛИЕНТА, КОД_ТУРА. Один клиент может осуществлять множество различных заказов, в то время как в одном объекте ЗАКАЗЫ может быть только один клиент (договор заключается с одним физическим лицом). Поэтому между данными, хранящимися в объектах КЛИЕНТ и ЗАКАЗ, которые отражаются в виде записей данных в соответствующих таблицах, будет существовать взаимосвязь «один-ко-многим».

Таблицы ТУР и ЗАКАЗЫ также будут иметь связь «один-ко-многим».

Тот же тип связи «один-ко-многим» имеют и таблицы СОТРУДНИКИ и ЗАКАЗЫ, ТРАНСПОРТ и ЗАКАЗЫ.

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

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

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

Если у объекта имеются множественные свойства, то каждому из них ставится в соответствие отдельная таблица.

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

Так, объект ТУР обладает свойствами ГОРОД и СТРАНА, однако использование двух свойств в одной таблице ТУР приведет к дублированию информации, так как каждый город принадлежит определенной стране. Поэтому выделим объект СТРАНА в отдельную таблицу.

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

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

ТУР.КОД_ГОРОДА>ГОРОД.КОД_ГОРОДА;

ГОРОД.КОД_СТРАНЫ > СТРАНА. КОД_СТРАНЫ;

ЗАКАЗЫ.КОД_ТУРА > ТУР. КОД_ТУРА;

ЗАКАЗЫ. КОД_КЛИЕНТА > КЛИЕНТ. КОД_КЛИЕНТА;

СОТРУДНИКИ. КОД_ДОЛЖНОСТИ > ДОЛЖНОСТИ. КОД_ ДОЛЖНОСТИ;

ЗАКАЗЫ. КОД_СОТРУДНИКА > СОТРУДНИКИ. КОД_ СОТРУДНИКА;

ЗАКАЗЫ. КОД_СТРАХОВКИ > СТРАХОВКА. КОД_ СТРАХОВКИ;

ЗАКАЗЫ. КОД_ТРАНСПОРТА >

ТРАНСПОРТ. КОД_ТРАНСПОРТА.

Логическая модель базы данных «Турфирма» была реализована с помощью СУБД Microsoft Access.

Структура реляционной базы данных Access определяется составом таблиц и их взаимосвязями.

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

Создание реляционной базы данных с помощью СУБД Access для решения задачи автоматизации туристической фирмы было начато с формирования структуры таблиц (таблицы 8 — 15).

Таблица 8

Структура таблицы «Doljnost»

Таблица 9

Структура таблицы «Sotr»

Таблица 10

Структура таблицы «Klient»

Таблица 11

Структура таблицы «Tur»

Таблица 12

Структура таблицы «Avtopark»

Таблица 13

Структура таблицы «Strah»

Таблица 14

Структура таблицы «Perevoz «

Таблица 15

Структура таблицы «Dogovor»

4. Программная часть

4.1 Дерево функций

В разработанном программном продукте «Турфирма» связь пользователя и программы реализована в форме диалога. Диалогэто процесс обмена сообщениями между пользователем и компьютером, при котором осуществляется постоянная смена ролей информатора и реципиента (пользователя, принимающего информацию), причем смена ролей должна быть достаточно оперативной.

Главное меню программы представлено на рис. 4.1.

Рис. 4.1 — Главное окно программы

Диалог между пользователем ЭВМ определяется функциями, которые выполняет разработанное приложение, и осуществляется путем выбора определенного подпункта пункта меню. Рассмотрим дерево функций разработанной подсистемы обслуживания клиентов турфирмы.

Главное окно (главная форма) программы содержит меню с командами для открытия дочерних форм приложения.

Список функций, реализованный в программе, представлен в таблице 16.

Таблица 16

Функции программы

4.2 Сценарий диалога

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

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

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

Управление программой «Турфирма» осуществляется с помощью меню, так как меню является основной формой диалога в прикладных системах обработки данных.

Структура меню и открываемые с его помощью формы приложения (дочерние формы) представлены в таблице 17.

Таблица 17

Команды меню

4.3 Дерево программных модулей

Для создания клиентской ИС «Турфирма» выбрана среда визуального программирования Borland Delphi. В состав Delphi входят мощные и доступные средства для разработки и эксплуатации приложений, использующих базы данных.

ADO-компоненты Delphi служат для соединения приложения с таблицами БД в локальных и распределенных системах. Они расположены на страницах Data Access и BDE палитры компонентов и с их помощью осуществляется подключение к базам данных, формирование запросов к ним, манипулирование таблицами, создание клиентов и серверов в трехзвенной архитектуре.

Приложение «Турфирма» состоит из главной формы приложения, открывающееся при запуске *.exe-файла приложения, 16 дочерних форм, открывающихся при выборе команд меню или по щелчку по кнопке соответствующей формы приложения.

В составе проекта можно выделить следующие элементы: формы; модули форм; модуль для размещения невизуальных компонент DataModule; параметры проекта; компоненты ADO.

Формы связаны друг с другом программно (рис. 4.2). Вызов формы осуществляется командой Application. CreateForm (). На рисунке 4.2 показаны формы приложения, основные визуальные компоненты на них и связь между модулями, формами и их компонентами.

Рис. 4.2 — Связи между модулями приложения «Турфирма»

С помощью компонента ADOtable и DataModule подключаем FormDog к БД подключая ADODogovor к ADOTurist (ADOconnect).

Далее создаем форму (Form) для отображения таблицы БД. Помещаем на него объект DBGrid, подключаем его к ранее созданному ADODogovor с помощью DataSource. Добавляем на форму объект DBNavigator и так же подключаем его к ADO через DataSource.

Модуль данных DataBd — это специальная «форма» (класс TDataModule), служащий для размещения компонентов доступа к данным в приложении баз данных. В модуле данных можно размещать только невизуальные компоненты, он доступен разработчику на этапе разработки, пользователь приложения не может увидеть модуль данных во время выполнения. Компонент доступа к данным является основой приложения БД. На основе выбранной таблицы БД он создает набор данных и позволяет эффективно управлять им.

В нашем случае в модуле DataBd размещены компоненты:

— ADOTurist: TADOConnection — обеспечивает связь приложения с базой данных base. mdb СУБД Access;

— ADOfio: TADOTable — обеспечивает связь с таблицей FIO БД turist. mdb;

— DataDogovor: TDataSource — обеспечивает управление потоками данных между набором данных и связанными с ним компонентами отображения данных.

4.4 Блок-схема одного программного модуля

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

Формы справочников и журнала договоров организованы по одному принципу и выводят записи таблицы БД в экранный диалог. Рассмотрим алгоритм работы модуля проекта на примере модуля UnitTur. pas — форма справочника «Туры».

Блок-схема работы модуля UnitTur. pas приведена на рисунке 1 приложения курсовой работы.

4.5 Текст разработанного модуля программы

Структура формы FormTur (правочник «Туры») модуля UnitTur. pas приведена на рис. 4.3.

Рис. 4.3 — Структура формы FormTur модуля UnitTur

Фрагмент кода модуля UnitTur приведен на рисунке 4.4.

Рис. 4.4 — Фрагмент кода модуля UnitTur

В таблице 18 перечислены визуальные компоненты, расположенные на форме FormTur и связанные с компонентом набора данных DataTur формы UnitBD.pas.

Таблица 18

Компоненты формы

При открытии набора данных компонент обеспечивает передачу в набор данных записей из требуемой таблицы БД. Курсор набора данных устанавливается на первую запись. Компонент TDataSource организует передачу в компоненты отображения данных значений необходимых полей из текущей записи. Пользователь при помощи компонентов отображения данных может просматривать и редактировать данные. Измененные значения сразу же передаются из элемента управления в набор данных при помощи компонента TDataSource. Затем изменения могут быть переданы в базу данных или отменены.

Опишем события визуальных кнопок формы FormTur.

1) Кнопка «Добавить» содержит программный код добавления новой записи в таблицу Tur (связанную с приложением через компонент ADOtur.

dataBD.ADOtur.Append;

application.CreateForm (TFormTDob, formTDob);

2) Кнопка «Удалить» содержит программный код удаления записи из таблицы Tur.

dataBD.ADOTur.delete;

3) Для выполнения поиска информации в БД написан программный код обработки щелчка кнопки «Поиск».

procedure TFormTur. Button1Click (Sender: TObject);

begin

if length (edit1.text)> 0 then begin

dataBD.ADOTur.Filtered:=false;

dataBD.ADOTur.Filtered:=true;

dataBD.ADOTur.Filter:='strana='''+edit1.Text+'''';

end;

if length (edit2.text)> 0 then begin

dataBD.ADOTur.Filtered:=false;

dataBD.ADOTur.Filtered:=true;

dataBD.ADOTur.Filter:='gorod='''+edit2.Text+'''';

end;

if length (edit3.text)> 0 then begin

dataBD.ADOTur.Filtered:=false;

dataBD.ADOTur.Filtered:=true;

dataBD.ADOTur.Filter:='srok='''+edit3.Text+'''';

end;

if length (edit4.text)> 0 then begin

dataBD.ADOTur.Filtered:=false;

dataBD.ADOTur.Filtered:=true;

dataBD.ADOTur.Filter:='cena='''+edit4.Text+'''';

end;

Для отбора необходимой информации в запросе к БД используется фильтр, который необходимо применить в отношении к данным, прежде чем они будут возвращены. Это свойства Filtered, Filter. В нашем случае фильтр пропускает только те записи БД, которые удовлетворяют некоторому условию.

Для отмены результата фильтрации данных БД программный код кнопки «Сброс» содержит команду:

dataBD.ADOTur.Filtered:=false.

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

edit2.text:='';

edit3.text:='';

edit4.text:='';

Компоненты форм FormSotr, FormAvto, FormKlient, FormPerevoz, FormSkidki, FormStrah, FormDog, FormDolj имеют аналогичную структуру и содержат подобные программные коды, что и описанные выше.