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

Введение

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

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

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

информационный метрика клиент

1. Разработка и анализ технического задания

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

1.2 Постановка задачи Система должна обеспечить возможность:

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

— расчета прайс-листа;

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

— статистического анализа.

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

1.3 Требования, предъявляемые к проекту

1.3.1 Функциональные требования

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

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

Основные функции системы можно разделить на две крупные группы:

— Регистрация, хранение и поиск документов;

— Обработка документов и бизнес-процессы.

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

— Microsoft Windows Server 2003;

— Microsoft SQL Server 2000;

— Microsoft .NET Framework 2.0

— Microsoft Internet Explorer 6.0;

— Microsoft Office 2000 или выше.

Пользователь работает с системой при помощи клиентского приложения «Навигатора», которое запускается с помощью интернет — браузера Microsoft Internet Explorer 6.0 с необходимыми параметрами в строке адреса. К разработанной системе должно прилагаться «Руководство пользователя» и «Руководство администратора».

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

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

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

— пользователь работает с системой при помощи клиентского приложения — «Навигатора», получая через него, в соответствии со своими правами, доступ ко всем объектам системы. Пользователь может искать, просматривать, создавать и модифицировать объекты, для работы с которыми у него достаточно прав;

— система автоматически выполняет действия, предусмотренные бизнес-логикой карточек и бизнес-процессов (формирует задания, взаимодействует с внешними системами и т. д.);

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

— при получении задания пользователь получает также и всю необходимую информацию в виде вложений и ссылок на документы, объекты внешних систем;

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

Кроме того управление процессами в DocsVision обеспечивает возможность реализации процессного управления в организации по стандарту ISO 9001:2000 (ГОСТ РИСО 9001:2001).

1.5 Выбор средств решения выполнения технического задания Для работы с СУБД я буду использовать MS Access, т. к. она удовлетворяет основным требованиям по разработке ИС:

— защита информации осуществляется на уровне пользователя

— возможность совместного доступа к данным

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

— перспективность MS Access (возможность повышения уровня системы за счет перехода на MS SQL Server)

Для моделирования бизнес-процессов будет использоваться язык IDEFO. В IDEFO система представляется как совокупность взаимодействующих работ или функций. Это позволит нам проанализировать функции системы независимо от объектов, которыми она оперирует. С помощью программы BPwin будет разработана модель процессов, происходящих при работе с информационной системой. Затем с использованием программы ERwin будет разработана модель данных с последующей генерацией программного модуля на языке VBA и экспорт данного модуля в Access, где после компиляции этого модуля будет создано ядро базы данных.

2 Разработка системного проекта

2.1 Построение модели прецедентов

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

Рисунок 1. Модель прецендентов.

Выполним описание прецедентов в текстовом формате:

Прецедент «оформить путевку» является основным прецедентом, распишем его подробно.

Прецедент П1. Оформить путевку

Основной исполнитель. Клиент Заинтересованные лица и их требования

— Сотрудник фирмы. Консультирует клиента по услугам, их стоимости. Помогает клиенту ориентироваться в системе.

Предусловия. Сотрудник фирмы идентифицирован и аутентифицирован.

Результаты (Постусловия). Клиент оформил путевку в санаторий исходя из своих предпочтений, оплатил ее.

Основной успешный сценарий (или основной процесс)

1. Клиент приходит в фирму.

2. Сотрудник фирмы консультирует клиента об услугах.

3. Клиент с помощью сотрудника фирмы создает путевку.

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

5. Система сообщает клиенту общую стоимость и предлагает оплатить путевку.

6. Клиент оплачивает путевку, система обрабатывает платеж.

7. Система регистрирует продажу и отправляет информацию о ней внешней бухгалтерской системе.

8. Система выдает чек.

9. Клиент покидает туристическую фирму с чеком и путевкой.

Расширения (или альтернативные потоки)

*а. При каждом выходе системы из строя.

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

1. Сотрудник фирмы перезапускает систему, регистрируется и предлагает восстановить предыдущее состояние.

2. Система восстанавливает предыдущее состояние.

2а. Система определяет аномалию, повлекшую сбой.

2.1. Система уведомляет об ошибке сотруднику фирмы, регистрирует ее.

2.2. Сотрудник фирмы приносит извинение клиенту и вызывает системного администратора.

3а. Неправильный идентификатор.

3.1. Система уведомляет об ошибке .

3.2. Сотрудник фирмы заново регистрируется в системе.

3.2.а Система снова уведомляет об ошибке «Неправильный идентификатор».

3.2.1 Сотрудник фирмы приносит извинение клиенту и вызывает системного администратора.

3.2.б Сотрудник фирмы успешно зарегистрирован.

3.2.1 Сотрудник фирмы продолжает работать с клиентом.

Прецедент П2. Отменить путевку

Основной исполнитель. Клиент Заинтересованные лица и их требования

— Сотрудник фирмы. Консультирует клиента по услугам, их стоимости. Помогает клиенту ориентироваться в системе.

Предусловия. Сотрудник фирмы идентифицирован и аутентифицирован.

Результаты (Постусловия). Клиент отменяет заказ.

Основной успешный сценарий.

1. Клиент приходит в фирму и сообщает что хочет отменить путевку.

2. Сотрудник фирмы находит заказ в системе.

3. Клиент просматривает заказ и отменяет его в системе.

4. Система выдает сообщение об отмене заказа.

2.2 Построение модели процессов Методология IDEF0 (Integrated Definition Function Modeling) — это технология описания системы как множества взаимозависимых деталей или функций. IDEF0 функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. Функциональная точка зрения позволяет четко отделить аспекты назначения системы от аспектов его физической реализации. Наибольшая часть IDEF0 применяется как технология исследования и проектирования систем на логическом уровне. Поэтому IDEF0 используется на ранних этапах разработки проекта. Модель IDEF0 сочетает в себе небольшую по объему графическую диаграмму со строгими и четко определенными рекомендациями, предназначенными для построения качественной и понятной модели системы. Диаграмма содержит только два обозначения: блоки и стрелки. Любой блок может быть декомпозирован на составляющие его блоки. Описание любого блока должно как минимум включать описание объектов, которые блок потребляет или преобразует. В IDEF0 также моделируются управление и механизмы исполнения. Под управлением понимают объекты, воздействующие на способ, которым блок преобразует вход и выход. Механизм исполнения — объекты, которые непосредственно меняют преобразование входа в выход, но остаются неизменными.

Рисунок 2. Контекстная диаграмма Диаграмма декомпозиции первого уровня представлена на рисунке 3 (остальные диаграммы декомпозиции расположены в Приложении А).

Рисунок 3. Диаграмма декомпозиции первого уровня Описание процессов в IDEF0:

1) А-0 -Система взаимодействия с клиентами фирмы (контекстная диаграмма).

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

2) А-1 — Консультация.

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

3) А-2 — Оформление путевки.

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

4) А-3 — Статистический анализ.

На этом этапе происходит обработка полученных данных из блока «оформление путевки» и формирование отчетов, а на выходе получаем отчеты о работе персонала и предпочтение клиента.

3. Разработка модели данных системы

Модель данных проектируемой системы разрабатывается с учетом предъявляемых к ней функциональных требований. База данных системы состоит из следующих сущностей: Сотрудник фирмы, Клиент, Путевка, Транспорт, Лечение, Номер. Рассмотрим основные сущности системы подробнее.

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

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

Сущность Путевка состоит из следующих атрибутов: ID транспорта, ID клиента, ID лечения, ID номера. С сущностью Путевка связаны сущности Транспорт, Лечение, Номер.

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

Рисунок 4 — Логический уровень модели данных Рисунок 5 — Физический уровень модели данных

4. Связь модели данных с моделью процессов

Первым шагом связывания модели данных и модели процессов является экспорт данных из ERwin в BPwin.

Существует три способа связывания объектов модели данных и модели процессов:

1. Экспорт через .DBF-файлы (реализован в ранних версиях ERwin и BPwin).

2. Экспорт и импорт через файлы формата .EAX — .BPX.

3. Синхронизация моделей, хранящихся в репозитории ModelMart при помощи утилиты ModelMart Synchronizer.

Ниже будет рассмотрен второй способ связывания моделей. Для экспорта модели данных из ERwin в BPwin необходимо в ERwin открыть модель и выбрать пункт меню File->Export->To AllFusion Process Modeler. В появившемся диалоге необходимо выбрать имя файла *.eax и нажать кнопку Сохранить.

Затем в BPwin нужно открыть модель процесса, выбрать в меню пункт FiIe/Import/Erwin (EAX)…, выбрать имя файла и нажать ОК. Появится протокол импорта. Нажать на кнопку Ассept.

После внесения данных в модель процессов можно связать сущности и атрибуты со стрелками. Правой кнопкой мыши нужно щелкнуть по стрелке и выбрать в контекстном меню Arrow Data.

Так как работы могут воздействовать на данные. Для документирования такого воздействия необходимо щелкнуть правой кнопкой мыши по работе и выбрать пункт меню Data Usage Editor .

В появившемся диалоге Data Usage Editor в виде иерархического списка показываются все работы модели, стрелки, которые касаются работ, сущности и атрибуты, которые были связаны со стрелками.

Для сущностей задается ассоциация CRUD (Create, Read, Update, Delete), для атрибутов — IRUN (Insert, Read, Update, Nullify). Ассоциации CRUD и IRUN — это правила использования сущностей и атрибутов работами, т. e. то, что могут делать работы с входящими или исходящими данными.

5. Расчеты и оценки

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

Рассмотрим первую пользовательскую форму «Клиент».

1. Количество внешних вводов: 3 (Добавить, Удалить, Отмена) каждый элемент ввода состоит из 4 элементов данных (id, opening date, closing date, components).

2. Количество внешних выводов: 1 (сообщение уведомления об ошибке, если обязательные поля не заполнены);

3. Количество внешних запросов: 1

4. Количество внутренних логических файлов:0

5. Внешних интерфейсных файлов: 0.

Таблица 1

Рассмотрим вторую пользовательскую форму «Лечение».

1. Количество внешних вводов: 3 (Добавить, Удалить, Отмена) каждый элемент ввода состоит из 5 элементов данных (id, наименование, стоимость лечения, дата).

2. Количество внешних выводов: 1 (сообщение уведомления об ошибке, если обязательные поля не заполнены);

3. Количество внешних запросов: 2

4. Количество внутренних логических файлов: 1

5. Количество внешних интерфейсных файлов: 0

Таблица 2

Рассмотрим третью пользовательскую форму «Путевка».

1. Количество внешних вводов: 3 (Добавить, Удалить, Отмена) каждый элемент ввода состоит из 7 элементов данных (id, лечение, количество, номер, транспорт, стоимость).

2. Количество внешних выводов: 0

3. Количество внешних запросов: 3

4. Количество внутренних логических файлов: 1 таблицы (Лечение).

5. Количество внешних интерфейсных файлов: 0.

Таблица 3

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

FP = 16 +29+ 28 = 73

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

FP = Общее_количество * (0,65+ 0,01 * ¹⁴_i=1F_i),

где F_i — коэффициенты регулировки сложности.

Определение системных параметров приложения Каждый коэффициент может принимать следующие значения: 0 — нет влияния, 1 — случайное, 2 — небольшое, 3 — среднее, 4 — важное, 5 — основное.

Таблица 4

В результате количество функциональных указателей равно:

FP = 73 * (0.65 + 0.01*(2+3+3+2+5+5+5+5+2+5+2+4+2+4)) = 73*(0.65+0.49) =83.22

Сопоставление с LOC метрикой Оценив сложность проекта по функционально ориентированным метрикам необходимо связать их с конкретным языком программирования. Для такой оценки используются LOC-метрики (lines of code, LOC).

Полученные FP пересчитываются в LOC использую среднестатистические показатели.

Таблица 5

Разрабатываемая информационная система будет писаться на языке Java. Таким образом, воспользовавшись формулой, получаем LOC системы:

LOC ?FP*53 = 83.22*53 = 4414 строк кода.

Заключение

В результате работы была разработана информационная система, которая выполняет следующие функции:

— регистрация клиентов;

— расчет прайс-листа;

— оформление заявки;

— статистический анализ;

— каждый сотрудник вовремя получает задание на выполнения своего этапа работ;

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

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

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

Рассчитаны FP-метрики. Система ориентирована на работу с базой данных достаточно большого объема. Использование этой системы облегчит работу сотрудникам фирмы.

Список литераторы

1. Моругин С. Л. Проектирование информационных систем. Методические указания по выполнению курсового проекта для студентов специальности 230 102 (71 900) — Нижний Новгород, НГТУ — 2006

2. Горин С. В., Тандоев А. Ю. Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки данных. «СУБД», 1995, № 3.

3. Лекции профессора Моругина С. Л. по курсу «Проектирование информационных систем»

Приложение, А Рисунок 6. Развернутая модель «Оформление путевки»

Рисунок 7. Развернутая модель «Статистический анализ»