Информационная модель ЧП «такси»

Для моделирования деятельности такси используется функциональное моделирование.

3.1. Функциональная модель

 

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

Функция — самая существенная характеристика любой системы, отражает её предназначение, то, ради чего она была создана. Подобные модели оперируют, прежде всего, с функциональными параметрами. Графическим представлением этих моделей служат блок-схемы. Они отображают порядок действий, направленных на достижение заданных целей. Функциональной моделью является абстрактная модель [5].

 

Рис.1. Обслуживание клиентов службы такси

 

На рисунке 1 представлен  основной бизнес процесс службы такси.

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

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

 Рис.2. Декомпозиция бизнес процесса «обслуживание клиентов службой такси».

 

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

 

Рис.3. Декомпозиция бизнес процесса «принятие заказа».

 

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

 

 

Рис.4. Декомпозиция бизнес процесса «подготовка к выполнению заказа».

 

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

 

Рис.5. Декомпозиция бизнес процесса «выполнение заказа».

 

На рисунке 5 представлен результат декомпозиции процесса выполнения  заказа. Видно, что на входе участвуют заказ, а на выходе выполненный заказ. Элемент управления - технология работы службы такси, а механизм диспетчеры и водители [10].

3.2. Моделирование потоков данных

 

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

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

• внешние сущности;
• системы/подсистемы;
• процессы;
• накопители данных;
• потоки данных[3].

Рис.6. Диспетчер такси.

 

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

 

Рис.7. Диспетчер такси.

 

На рисунке 7 в построенной модели на основании нотации DFD показан процесс работы и документооборота  в службе такси. Где потоки данных будут происходить параллельно между диспетчером, директором и заказчиком [8] .

 

3.3. Моделирование  потоков работ

 

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

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

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

IDEF3 также может быть использован как метод проектирования бизнес-процессов. IDEF3-моделирование органично дополняет традиционное моделирование с использованием стандарта  методологии IDEF0. В настоящее время оно получает все большее распространение как вполне жизнеспособный путь построения моделей проектируемых систем для дальнейшего анализа имитационными методами. Имитационное тестирование часто используют для оценки эксплуатационных качеств разрабатываемой системы [7].

Рис.8. Диспетчер такси.

На рисунке 8 представлен  поток работ происходящих в данной области «Такси». Здесь видно, что при определении наличия свободного водителя происходит один из перечисленных этапов.

3.4. Определение  узких мест, предлагаемое решение

Узкое место (bottleneck) - это  условие, при котором ограничения  одного из аппаратных компонентов не позволяют всей системе в целом  работать быстрее. С наибольшей вероятностью узким местом системы становится устройство, обладающее наименьшей производительностью, особенно в условиях его сильной загрузки. В этой ситуации повышение производительности любого другого устройства системы никогда не позволит повысить производительность системы в целом; результатом может явиться только низкая степень загрузки высокопроизводительных устройств [12].

Анализ исследуемой  модели показал, что сотрудники такси  затрачивают уйму времени на:

- большое количество документации;

- устаревшие технологии обработки данных;

- поиск нужной информации.

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

3.5. Техническое задание на разработку ИС

Техническое задание  для ИС «Такси» 

1.Общие  сведения:

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

Свободный доступ к электронным  материалам.

Разработчик- студентка  ИрГСХА Дырочкина Татьяна Евгеньевна

2.Назначение  и цели.

Цель:

Сокращение времени  на обслуживание клиентов такси.

Назначение:

  ИС «Такси» ориентирована на следующих пользователей ЧП:

- руководителей ЧП;

- сотрудников ЧП;

- для организаций осуществляющих  проверки по данному ЧП.

3.Характеристика объекта автоматизации.

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

- Предоставление сотрудникам новых форм сервисных услуг.

- Совершенствование ИС ЧП.

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

4.1. Требования к системе в целом:

 - сбор, организация хранения и обеспечение сохранности данных в ИС;

- целенаправленное создание  информационных массивов.

4.2. Требования к инструментальным средствам:

- Развёртывание CASE средства BpWin и ErWin;

- Развёртывание СУБД Access;

5. Состав и содержание работ по созданию системы:

- Создание пользовательского интерфейса.

- Создание рабочей документации, в том числе инструкции для пользователя по  работе в системе.

- Установка на рабочее место ИС,  заполнение БД, пробная эксплуатация.

- Возможные исправления в работе, структуре ИС и полная загрузка ИС.

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

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

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

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

4. Проектирование БД

 

Проектирование баз  данных — процесс создания схемы  базы данных и определения необходимых  ограничений целостности.

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

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

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

Основные задачи проектирования баз данных:

- Обеспечение хранения в БД всей необходимой информации.

- Обеспечение возможности получения данных по всем необходимым запросам.

- Сокращение избыточности и дублирования данных.

-Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.

Модели «сущность-связь» (ER-модель данных)

Модель «сущность-связь» (англ. “Entity-Relationship model”), или ER-модель, предложенная П. Ченом в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма, либо с использованием других графических нотаций (Crow's Foot, Information Engineering и др.).

Основные преимущества ER-моделей:

- наглядность;

- модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;

- ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

- объекты (сущности);