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

Вид материала

Содержание

Приложение б. диаграмма dfd 48
1. Аналитическая часть 1.1. постановка задачи
1.2. Анализ предметной области
1.3. Анализ инструментальных средств разработки и проектирования
1.4. Обоснование проектных решений
2. Проектная часть 2.1. проектирование модели idef0
2.2. Построение модели потоков данных
2.3. Разработка схемы базы данных
2.4. Генерация базы данных
2.5. Разработка приложения
3.Оценка экономического эффекта
Список литературы
Приложение а. диаграммы idef0
Приложение б. диаграмма dfd

Подобный материал:

ВВЕДЕНИЕ 2

1. АНАЛИТИЧЕСКАЯ ЧАСТЬ 3

1.1. ПОСТАНОВКА ЗАДАЧИ 3

1.2. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ 4

1.3. АНАЛИЗ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ РАЗРАБОТКИ И ПРОЕКТИРОВАНИЯ 7

1.4. ОБОСНОВАНИЕ ПРОЕКТНЫХ РЕШЕНИЙ 16

2. ПРОЕКТНАЯ ЧАСТЬ 19

2.1. ПРОЕКТИРОВАНИЕ МОДЕЛИ IDEF0 19

2.2. ПОСТРОЕНИЕ МОДЕЛИ ПОТОКОВ ДАННЫХ 21

2.3. РАЗРАБОТКА СХЕМЫ БАЗЫ ДАННЫХ 23

2.4. ГЕНЕРАЦИЯ БАЗЫ ДАННЫХ 24

2.5. РАЗРАБОТКА ПРИЛОЖЕНИЯ 25

3.ОЦЕНКА ЭКОНОМИЧЕСКОГО ЭФФЕКТА 34

ЗАКЛЮЧЕНИЕ 36

СПИСОК ЛИТЕРАТУРЫ 37

ПРИЛОЖЕНИЕ Б. ДИАГРАММА DFD 48

ПРИЛОЖЕНИЕ В. ДИАГРАММА ERD 53

ВВЕДЕНИЕ

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

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

Цель данной работы – спроектировать деятельность ресторана для повышения качества и прозрачности управления бизнес-процессами, разработать прототип приложения для автоматизации деятельности ресторана, произвести оценку экономического эффекта, закрепить навыки работы в программном продукте Borland Delphi 7 и CASE-средстве ERwin. Данная работа направлена на закрепление базовых знаний и навыков в области проектирования экономических информационных систем.

1. АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1. ПОСТАНОВКА ЗАДАЧИ

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

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

Исследовать предметную область;
Обосновать выбор инструментальных средств;
Формализовать бизнес-процессы (диаграммы IDEF-0), на базе полученных материалов обследования;
Формализовать потоки данных (диаграммы DFD), на базе выявленных бизнес-процессов;
Построить модель данных;
Сгенерировать модель данных в целевую СУБД;
Разработать прототип приложения;
Оценить экономический эффект.

1.2. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

В качестве объекта исследования было выбрано типовое предприятие общественного питания - ресторан «Капитан», занимающееся организацией приятного время препровождения посетителей, предоставления им возможности культурного отдыха, а также предоставление на выбор посетителей широкого списка изысканных блюд. Ресторан содержит в своем составе следующие подразделения: «Кухня», «Главный зал», «Финансы и производство». Структура предприятия представлена на рисунке 1.

Рисунок 1 – Структура предприятия

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

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

Ведение бухгалтерского учета;
Анализ поступающей информации от отделов «Кухня» и «Главный зал»;
Ведение взаиморасчетов с поставщиками;
Ведение налогового учета;
Формирование ежедневного меню;
Формирование заявок на закупку продуктов.

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

Для управления закупкой продуктов от отдела «Кухня» поступает список необходимых продуктов для заказа и на основании это списка формируется заявка на заказ продуктов поставщику. При поступлении продуктов на кухню администратор кухни передает в отдел «Финансы и производство» документы о поступлении продуктов.

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

Кухня – отдел представлен 3-4 поварами и одним администратором горячего цеха. Повара занимаются приготовлением блюд. Администратор кухни принимает заказы от официантов, анализирует их и формирует очередность приготовления блюд, как только блюдо готово администратор горячего цеха сообщает об этом официанту. Также администратор горячего цеха ведет отчетность об израсходованных продуктах, следит за их количеством и в случае необходимости формирует заявку на заказ продуктов, при поступлении продуктов администратор анализирует поступившие продукты, сравнивает поступившие продукты с заявкой и отчетные документы передает в отдел «Финансы и производство».

Главный зал – состоит из 3-4 официантов и одного администратора зала. Главная задача отдела сводится к обслуживанию посетителей. Процедура взаимодействия с посетителями выглядит следующим образом: посетитель приходит в ресторан и на основе меню формирует свой заказ, официант отправляет заказ на кухню и администратору зала, а после приготовления заказа подает его посетителю. Когда посетитель собирается уходить официант подает ему счет, который заранее подготовлен администратором зала и посетитель его оплачивает. Заказ посетителя переносится в общий журнал заказов.

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

Таблица 1 – Матрица организационных проекций

Оргзвенья		Функции
Отдел	Сотрудники	Обслуживание клиентов	Расчет посетителя	Управление деятельностью кухни	Формирование меню	Закупка продуктов	Управление финансами	Приготовление блюда
Финансы и производство	Финансист						Х
	Менеджер				Х
	Логист					Х
Кухня	Повара							Х
Кухня	Администратор горячего цеха			Х
Главный зал	Официанты	X
Главный зал	Администратор зала		Х

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

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

1.3. АНАЛИЗ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ РАЗРАБОТКИ И ПРОЕКТИРОВАНИЯ

Процесс проектирования необходимо организовать средствами автоматизированного проектирования. Современные СП могут быть разделены на две большие категории [7]. Первую составляют CASE-системы (как независимые (upper CASE), так и интегрированные с СУБД), обеспечивающие проектирование БД и приложений в комплексе с интегрированными средствами разработки приложений "клиент-сервер" (например, Westmount I-CASE+Uniface.Designer/2000+Developer/2000). Их основное достоинство заключается в том. что они позволяют разрабатывать всю ИС целиком (функциональные спецификации, логику процессов, интерфейс с пользователем и базу данных), оставаясь в одной технологической среде. Инструменты этой категории, как правило, обладают существенной сложностью, широкой сферой применения и высокой гибкостью.

Вторую категорию составляют собственно средства проектирования БД, реализующие ту или иную методологию, как правило, "сущность-связь" ("entity-relationship") и рассматриваемые в комплексе со средствами разработки приложений. К средствам этой категории можно отнести такие, как SILVERRUN+JAM, ERwin/ERX+PowerBuilder и др. Помимо указанных категорий, СП можно классифицировать по следующим признакам:

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

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

Vantage Team Builder (Westmount I-CASE);
Designer/2000+Developer/2000;
ERwin+BPwin.

Westmount I-CASE представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО, обеспечивающий выполнение следующих функций [8]:

графическое проектирование архитектуры системы (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент-сервер", анализ использования мониторов транзакций и особенностей функционирования систем в реальном времени);
проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;
генерация кода программ на 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;
программирование на языке С со встроенным SQL;
управление версиями и конфигурацией проекта;
генерация проектной документации по стандартным и индивидуальным шаблонам;
экспорт и импорт данных проекта в формате CDIF.

Westmount I-CASE можно использовать в конфигурации "клиент-сервер", при этом база проектных данных может располагаться на сервере, а рабочие места разработчиков могут быть клиентами. Westmount I-CASE функционирует на всех основных UNIX-платформах и VMS. В качестве целевой СУБД могут использоваться ORACLE, Informix, Sybase и Ingres.

CASE-средство Designer/2000 2.0 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE [9].

Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE*Method) - структурная методология проектирования систем, полностью охватывающая все этапы жизненного цикла ИС [8,9]. В соответствии с этой методологией на этапе планирования определяются цели создания системы, приоритеты и ограничения, разрабатывается системная архитектура и план разработки ИС. В процессе анализа строятся модель информационных потребностей (диаграмма "сущность-связь"), диаграмма функциональной иерархии (на основе функциональной декомпозиции ИС), матрица перекрестных ссылок и диаграмма потоков данных.

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

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

Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компоненты:

Repository Administrator - средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);
Repository Object Navigator - средства доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;
Process Modeller - средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR - Business Process Reengineering) и глобальной системы управления качеством (TQM - Total Quality Management);
Systems Modeller - набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм "сущность-связь" (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);
Systems Designer - набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);
Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;
Repository Reports - генератор стандартных отчетов, интегрированный с ORACLE Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.

Developer/2000 обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими средствами реализуется через механизм OLE и управляющие элементы VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API.

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

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

Ключевые характеристики ERwin:

Синхронизация моделей/баз данных
Автоматизированное создание структуры базы данных и обратное проектирование
Публикация моделей
Поддержка нотаций: IDEF1x, IE, Dimensional
Документирование структур баз данных
Перенос структур баз данных (но не самих данных) из одного типа СУБД в другой

Функциональные возможности ERwin:

Архитектура уровня проектирования имеет достаточную гибкость для разработки архитектуры связных моделей данных, полностью удовлетворяющей потребностям организации. Наряду с комбинированной логической/физической моделью поддерживаются раздельные логические и физические модели. Благодаря накоплению знаний об отношениях между компонентами связанных моделей и ведению журнала проектных решений пользователи могут быстро определять влияние изменений одного уровня проектирования на другой.
Технология трансформации. Физическая структура базы данных редко совпадает с исходной логической структурой. В целях повышения производительности бизнес-приложений часто требуется проводить денормализацию данных на физическом уровне модели. ERwin позволяет автоматизировать процесс трансформации модели, сохраняя в целости исходный проект.
Определение стандартов. Определение и поддержка стандартов обеспечивается с помощью словаря доменов Domain Dictionary, редактора стандартов именования Naming Standards Editor и редактора стандартов типов данных Datatype Standards Editor. Словарь доменов содержит многократно используемые атрибуты и обеспечивает непротиворечивость имен и определений в рамках модели. Редактор стандартов именования позволяет пользователям создавать словари разрешенных терминов, аббревиатур и правил именования, которые могут использоваться повторно в рамках модели. Редактор стандартов типов данных позволяет определять собственные правила соответствия между типами данных разных СУБД.
Поддержка нескольких нотаций моделирования. Для визуального проектирования систем обработки транзакций, витрин и хранилищ данных в единой интегрированной среде ERwin поддерживает три популярные нотации моделирования данных: Integration DEFinition for Information Modeling (IDEF1X), Information Engineering (IE), Dimensional Modeling (DM).
Управление большими моделями. ERwin облегчает управление большими корпоративными моделями за счет использования предметных областей (Subject Areas) и хранимых отображений (Stored Displays). Предметные области позволяют конкретным проектировщикам фокусировать внимание, разделяя модель на более мелкие, и за счет этого легче управляемые подмодели. Хранимые отображения предоставляют разные варианты графического представления модели или ее предметных областей, облегчая обмен информацией между специализированными группами пользователей.
Генерация структуры базы данных. ERwin позволяет автоматически сгенерировать структуру базы данных из модели. Входящие в продукт оптимизированные шаблоны триггеров ссылочной целостности и богатый макроязык, совместимый с различными типами баз данных, позволяют пользователю настроить триггеры и хранимые процедуры. Настраиваемые шаблоны облегчают генерацию законченной физической структуры базы данных и полных определений (для соответствующей целевой базы данных).
Графические объекты. С помощью графических объектов ERwin обеспечивает наглядное представление бизнес-правил. Графические объекты, например линии, эллипсы и другие, легко редактируются. Разработчики моделей могут также настраивать параметры шрифта и цвета объектов.
Создание отчетов и печать. Ключевым элементом, обеспечивающим коммуникацию и совместную работу пользователей в процессе моделирования, является способность визуализации и публикации данных. ERwin предоставляет гибкие, настраиваемые возможности создания отчетов и печати.

Поддерживаемые СУБД

Oracle
DB2/UDB (включая iSeries)
SQL Server
Teradata
ODBC
Sybase
Informix
Ingres
Progress
Access

Поддерживаемые ОС

Windows 2000
Windows XP
Windows 2003 Server

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

Таблица 2 – Таблица характеристик СП

	West-mount I-CASE+Uniface	Designer/2000+ Developer/2000	ERwin/ERX+ PowerBuilder
Поддержка полного жизненного цикла ИС	+	+	+
Обеспечение целостности проекта	+	+	-
Независимость от платформы	+ (ORACLE, Informix, Sybase, Ingres и др., dbf-файлы)	- (целевая СУБД - только ORACLE)	+ (ORACLE, Informix, Sybase и др., поддержка ODBC)
Одновременная групповая разработка БД и приложений	+	-	-

Анализ данных, приведенных в таблице, показывает, что из перечисленных СП наиболее мощным и качественным является комплекс Westmount I-CASE+Uniface, он наиболее полно удовлетворяет всем критериям, принятым в качестве основных. Так, например, в комплексе Westmount I-CASE+Uniface целостность базы проектных данных и единая технология сквозного проектирования ИС обеспечивается за счет использования интерфейса Westmount-Uniface Bridge. Но для автоматизации деятельности ресторана СП Westmount I-CASE+Uniface не подойдет, так как данный комплекс достаточно сложный и трудоемки в использовании, а так же является одним из наиболее дорогостоящих и при его использовании не будет получен нужный экономический эффект. От использования СП Designer/2000+Developer/2000 так же придется отказаться, так как данный комплекс поддерживает работу только с СУБД ORACLE, а данная СУБД не подходит для автоматизации деятельности ресторана.

Таким образом, для автоматизации деятельности ресторана целесообразно использовать пакет BPwin+ERwin, так как в данном комплексе поддерживается большое количество СУБД, пакет обладает относительно небольшой, по сравнению с Westmount I-CASE+Uniface, ценой, достаточно прост в освоении и менее трудоемок в использование нежели его аналоги.

1.4. ОБОСНОВАНИЕ ПРОЕКТНЫХ РЕШЕНИЙ

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

При анализе наиболее популярных СУБД было отобрано три основных кандидата:

Microsoft SQL Server;
MySQL;
Firebird.

Microsoft SQL Server – система управления реляционными базами данных, разработанная корпорацией Microsoft. Обычно используется для работы с базами данных большого размера. Лицензирование осуществляется на платной основе [3].

MySQL – свободная система управления базами данных. MySQL является собственностью компании Oracle Corporation, получившей её вместе с поглощённой Sun Microsystems, осуществляющей разработку и поддержку приложения. MySQL, является решением для малых и средних приложений. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. MySQL – получил широкое распространение благодаря повсеместному использованию данной СУБД при создании веб-сайтов [4].

Firebird (FirebirdSQL) – компактная, кроссплатформенная, свободная система управления базами данных (СУБД), работающая на Linux, Microsoft Windows и разнообразных Unix платформах [10].

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

Firebird используется в различных промышленных системах (складские и хозяйственные, финансовый и государственный сектора). Это коммерчески независимый проект программистов, технических советников и разработчиков мультиплатформенных систем управления базами данных, основанный на исходном коде, выпущенном корпорацией «Borland» 25 июля 2000 года в виде свободной версии Interbase 6.0.

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

Для разработки приложения был выбран – Borland Delphi 7. Выбор этого средства разработки неслучаен. Разрабатываемое приложение будет работать под управлением операционной системы Windows. Раннее Borland Delphi 7 использовался в учебном процессе и прекрасно себя зарекомендовал как средство быстрой разработки приложений.

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

CASE-средство BPwin+ERwin;
СУБД Firebird;
Пакет для разработки приложения Borland Delphi 7.

Требования, предъявляемые к информационной системе:

Эксплуатационные требования
1. Система должна обеспечить регистрацию порядка 100-150 операций в день (заказы посетителей, закупки, бронирование столиков, формирование меню и т.д.) с учетом ее срока эксплуатации 5 лет (моральный износ) и с учетом перспектив развития и некоторого запаса.
Требования к надежности
1. Система должна восстанавливаться после сбоя (например, отключение питания)
2. В программу должны быть встроены средства контроля ошибок:

Контроль ссылочной целостности при попытках удаления записей;
Анализ вводимой информации (запрет ввода текстовой информации в числовые поля)

Требования к интерфейсам
1. Программа должна быть сделана с использованием СУБД Firebird
2. Программа должна иметь стандартный интерфейс с пользователем в среде Windows (многооконность, подсказки, статусная строка)
Другие требования
1. Программа должна поддерживать работу по сети нескольких пользователей
2. Программа должна быть пригодной к сопровождению (модульность, понятность кода).

2. ПРОЕКТНАЯ ЧАСТЬ

2.1. ПРОЕКТИРОВАНИЕ МОДЕЛИ IDEF0

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

При анализе деятельности предприятия общественного питания было выделено три основные работы входящие в состав предприятия.

Рисунок 2 – Деятельность ресторана

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

Рисунок 3 – Декомпозиция «Обслуживание клиентов»

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

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

2.2. ПОСТРОЕНИЕ МОДЕЛИ ПОТОКОВ ДАННЫХ

Для того чтобы выделить потоки данных необходимо построить диаграмму DFD. При построении диаграммы мною были выделены две основные внешние сущности – поставщики и посетители.

Рисунок 4 – Диаграмма DFD. Деятельность ресторана.

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

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

Рисунок 5 – Диаграмма DFD. Обслуживание клиентов.

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

2.3. РАЗРАБОТКА СХЕМЫ БАЗЫ ДАННЫХ

После того как была построена модель потоков данных, можно приступить к созданию схемы данных[5]. Анализируя данные диаграммы (Рисунок 4) можно выделить два основных хранилища данных – меню и заказы. Эти хранилища послужат каркасом схемы базы данных, информация о данных сущностях будет храниться в соответствующих таблицах («Eda», «Zakaz»). Помимо информации о меню и заказах необходимо хранить данные о пользователях системы, необходимо хранить информацию о столиках, а так же информацию о забронированных столиках на определенную дату. Следовательно, необходимы еще как минимум три сущности, способных хранить необходимую информацию.

В результате проведенного анализа создана модель сущность-связь.

Рисунок 6 – Модель сущность-связь

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

2.4. ГЕНЕРАЦИЯ БАЗЫ ДАННЫХ

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

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

В своей курсовой работе в качестве CASE-средства был выбран программный продукт ERwin. ERwin обеспечивает генерацию схемы данных сущность-связь в физическую базу данных. Взаимодействие Case-средства и, в нашем случае, СУБД Firebird осуществляется по средствам использования драйвера ODBC («Open Database Connectivity»). Для корректной генерации схемы данных необходимо внести изменения в тексты шаблонов, используемые ERwin при создании таблиц и триггеров в целевой БД, а именно заменить двойные кавычки на одинарные в текстах используемых шаблонов. После того, как файлы шаблонов и сама схема БД готовы, необходимо воспользоваться методом «Forward Engineer\Schema Generation» - именно этот метод и осуществляет генерацию схемы данных в физическую существующую базу данных .

2.5. РАЗРАБОТКА ПРИЛОЖЕНИЯ

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

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

В этом разделе будет рассмотрена модель распределенного приложения БД, которая называется многозвенной (multitiered), и, в частности, ее наиболее простой вариант – трехзвенное распределенное приложение. Тремя частями такого приложения являются [2]:

собственно сервер базы данных;
сервер приложений (серверная часть приложения);
клиентская часть приложения.

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

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

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

Многозвенная архитектура приложений БД призвана исправить перечисленные недостатки.

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

Для передачи данных между сервером приложений и клиентами используется интерфейс AppServer, предоставляемый удаленным модулем данных сервера приложений. Этот интерфейс используют компоненты-провайдеры TDataSetProvider на стороне сервера и компоненты TClientDataSet на стороне клиента.

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

В первую очередь удаленное клиентское приложение должно обеспечить соединение с сервером приложений. Для этого используются компоненты соединений DataSnap – TSocketconnection, использующий сокеты Windows;

Компонент TSocketConnection обеспечивает соединение клиента с сервером приложений за счет использования сокетов TCP/IP. Для успешного открытия соединения на стороне сервера должен работать сокет-сервер.

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

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

Перейдем к рассмотрению программного интерфейса клиента и сервера.

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

Рисунок 7. Форма сервера

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

Рисунок 8. Форма авторизации.

При выборе пользователя «Официант» появляется форма официанта (рисунок 9).

Рисунок 9. Главная форма официанта.

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

Рисунок 10. Форма ввода количества.

Под таблицей текущего заказа расположены две кнопки: «Отмена» для удаления выбранного блюда из текущего заказа и кнопка «Счет» для занесения текущего заказа в журнал заказов и распечатывания документа «Счет» (рисунок 11).

Рисунок 11. Вид счета.

Так же на форме имеется кнопка «Забронировать столик», при нажатии на которую появляется форма с таблицей забронированных столиков и возможностью удалить бронь или сделать новую (рисунок 12).

Рисунок 12. Форма бронирования столика.

Кроме этого были проработаны функции других пользователей связанных с деятельностью официанта. Так для пользователя «Администратор» (рисунок 13) была проработана возможность редактирования таблицы меню (добавление, удаление, редактирование) (рисунок 14), печать меню (рисунок 15), а так же возможность просмотра всего журнала заказов (рисунок 16) и вывод его на печать (рисунок 17).

Рисунок 13. Форма администратора.

Рисунок 14. Форма добавления нового пункта меню.

Рисунок 15. Печать меню.

Рисунок 16. Форма просмотра журнала заказов.

Рисунок 17. Печать журнала заказов.

Для пользователя «Шеф-повар» была проработана форма просмотра текущих заказов и возможность сообщать официанту о готовности того или иного заказа (рисунок 18).

Рисунок 18. Форма администратора горячего цеха.

Особое внимание стоит уделить кнопке «Update». Данная кнопка является неактивной до тех пор, пока не произошло изменений в записях таблиц БД. Как только что-то изменилось (Например: администратор изменил меню, или шеф-повар сообщил о готовности блюда), кнопка начинает «моргать», это является сигналом к нажатию с целью обновления информации.

3.ОЦЕНКА ЭКОНОМИЧЕСКОГО ЭФФЕКТА

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

Рассмотрим показатели, оценивающие величину эксплуатационных стоимостных затрат за год по базовому (существующему) и предлагаемому вариантам (автоматизированному).

Глядя на модели AS-IS и AS-TO BE, сразу же заметно объединение функций менеджера и логиста и передача их менеджеру. После реинжиниринга бизнес процессов происходящих на предприятии и после введения автоматизированной ИС сократились расходы предприятия, уменьшилось время затрачиваемое на обслуживание посетителя и сократился докментооборот. В результате в суммарном выражении мы получили разницу, при условии месячного функционирования организации, в десять тысяч рублей.

Теперь мы можем рассчитать абсолютный показатель снижения стоимостных затрат:

(1)

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

(2)

Коэффициент (2) показывает на какую долю или процент снижаются затраты предлагаемого варианта по сравнению с базовым.

Индекс снижения стоимостных затрат

(3)

Индекс снижения стоимостных затрат показывает во сколько раз снижаются стоимостные затраты предлагаемого j-го варианта по сравнению с базовым.

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

В среднем на выписку одного счета уходит от трех до пяти минут. Заработная плата официанта составляет двенадцать тысяч рублей при 21 рабочем дне. Тогда стоимость одного рабочего часа официанта составляет

(4)

Теперь мы сможем рассчитать стоимость выписки одного документа работником

(5)

Внедрение системы позволит сократить затраты, на выписку одного документа в среднем на 30%. Тогда стоимость выписки одного документа кладовщиком составит

(6)

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

(7)

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

(8)

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

ЗАКЛЮЧЕНИЕ

Поставленная цель курсовой работы выполнена. В ходе курсовой работы были формализованы бизнес-процессы (Диаграммы IDEF-0 AS IS), проведен реинжиниринг бизнес-процессов. (Диаграммы IDEF-0 AS TO BE). Средствами прямого проектирования получена БД.

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

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

Разработанное приложение позволяет:

Ускорить процесс оформления заказа посетителя
Обеспечить полный контроль над формируемыми заказами
Упростить процесс бронирования столиков
Автоматизировать процесс расчета посетителей

СПИСОК ЛИТЕРАТУРЫ

Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие. – М.: Финансы и статистика, 2004. – 192с.
Н. Елманова, С. Трепалин, А.Тенцлер. Delphi и технология COM – СПБ.: Питер, 2003 – 698 с.
Роберт Виейра. Программирование баз данных Microsoft SQL Server 2005. Базовый курс = Beginning Microsoft SQL Server 2005 Programming. — М.: «Диалектика», 2007. — С. 832. — ISBN 0-7645-8433-2 Ссылка на литру.
Роберт Шелдон, Джоффрей Мойе MySQL: базовый курс = Beginning MySQL. — М.: «Диалектика», 2007. — С. 880. — ISBN 0-7645-7950-9 Ссылка на литру.
С.В. Маклаков. Создание информационных систем с ALLFusion Modelling Suite. М.,2003.
С.В. Маклаков. ERwin и Bpwin. CASE-средства разработки информационных систем.М.,1999.
Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений. "СУБД", 1995, №3.
Westmount I-CASE User Manual. Westmount Technology B.V., Netherlands, 1994.
Горчинская О.Ю. Designer/2000 - новое поколение CASE-продуктов фирмы ORACLE. "СУБД", 1995, №3.
Алексей Ковязин, Сергей Востриков «Мир InterBase. 3-е издание» 2005. C. 496.

ПРИЛОЖЕНИЕ А. ДИАГРАММЫ IDEF0

Blog