Дипломная работа: Разработка средств информационной поддержки менеджмента ресторанного зала

1.5 Постановка задачи дипломного проекта

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

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

1)  получение данных о наличии продуктов для приготовления блюд со склада;

2)  получение данных со склада об изменении стоимости готовых блюд в соответствии с изменением стоимости отдельных индигриентов;

3)  ввод заказов;

4)  передачу заказа на кухню и в бар;

5)  передачу заказа на кассу для расчета клиента;

6)  учет всего ассортимента продаваемых блюд: название, индигриенты, вес, цена;

7)  учет занятых и свободных мест в ресторане;

8)  расчет остатка порций;

9)  учет рабочей смены;

10)  учет ответственных официантов за конкретный столик;

11)  учет рабочих часов каждого сотрудника;

12)  доступ к рецептам блюд и напитков;

13)  разделение меню информационного обеспечения «Ресторатор» на модули: официант, бармен, менеджер, кассир;

14)  передача ежедневных отчетов о проданной продукции на склад;

15)  предоставление отчетов о количестве отработанных часов по сотрудникам в центральный офис через электронную почту.

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

· увеличением скорости обслуживания одного клиента;

·  увеличением производительности труда сотрудников зала;

·  уменьшением затрачиваемого времени на обработку документов в ресторане;

·  уменьшение затрачиваемого времени на бухгалтерскую обработку документов.

2. Проектный раздел

2.1    Информационно-программная часть

2.1.1          Обоснование проектных решений по информационному обеспечению

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

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

В соответствии с ГОСТ-ом 34.601-90 «Автоматизированные системы. Стадии создания» проектирование ИО СИП МРЗдолжнотвключать 7 стадий:

1.      Исследование и обоснование создание системы;

2.      Разработка ТЗ;

3.      Создание эксплуатационного проекта;

4.      Технический проектирование;

5.      Рабочее проектирование;

6.      Ввод в действие;

7.      Функционирование, сопровождение, модернизация.

1Основные этапы проектирования информационной системы «Ресторатор»:

¾  Сбор материалов обследования (анализ: работы официантов, порядка распределения заказов, экономической ситуации);

¾  Анализ материалов обследования;

¾  Разработка ТЭО необходимости проектирования ИО;

¾  Разработка ТЗ.

2.      Техно-рабочее проектирование:

−      техническое проектирование;

−      рабочее проектирование.

Техническое:

−      логическая разработка (разработка инфологической и даталогической модели данных);

−      выбор наилучших вариантов проектных решений;

−      оформление технического проекта.

Рабочее:

−      физическая реализация выбранного варианта проекта;

−      разработка рабочего проекта.

3.      Внедрение проекта:

−      подготовка проекта к внедрению проекта ИС;

−      опытное внедрение;

−      сдача в промышленную эксплуатацию.

4.      Эксплуатация и сопровождение:

−      эксплуатация проекта;

−      сопровождение;

−      модернизация (может и не быть).

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

Каскадная модель

Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Этапы проекта в соответствии с каскадной моделью:

1.  Формирование требований;

2.  Проектирование;

3.  Реализация;

4.  Тестирование;

5.  Внедрение;

6.  Эксплуатация и сопровождение.

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

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

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

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

Перечень недостатков каскадной модели более обширен, чем перечень ее достоинств:

 существенная задержка получения результатов;

 ошибки и недоработки на любом из этапов выясняются, как правило, на последующих этапах работ, что приводит к необходимости возврата на предыдущие этапы;

 сложность распараллеливания работ по проекту;

 сложность управления проектом;

 высокий уровень риска и ненадежность инвестиций.

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

2.1.2 Разработка инфологической модели предметной области

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

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

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

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

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

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

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

Связь сущностей характеризуется идентификацией и степенью.

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

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

Неидентифицирующая связь, обозначаемая штриховой линией, соединяет сущность-родителя с независимой сущностью-потомком и представляет степень связи 1:N (или 1:1).

 На данной диаграмме показана связь между сущностями «Меню» и «Рецепт». Атрибутами сущности «Меню» является: наименования блюда, его цена и его категория (блюдо или напиток). Атрибутами сущности «Рецепт» является: наименования блюда и имя файла. Степень связи многие к одному.

На следующей диаграмме показана связь между сущностями «Меню» и «Заказ». Атрибуты сущности мы рассмотрели в предыдущей диаграмме. Атрибутами сущности «Заказ» являются: №заказа, № столика, наименования блюда, количество порций, ФИО официанта, дата. Связь между сущностями один ко многи.  

2.1.3 Разработка даталогической модели базы данных

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

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

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

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

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

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

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

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

2.1.4 Функциональная структура СИП МРЗ

Характеризуя структуру системы, можно выделить несколько основных элементов:

-  Модуль хранения. Собственно БД, включая запросы, формы, отчеты, хранимые на сервере.

-  Модуль «Администратор».

-  Модуль «Официант».

-  Модуль «Кассир».

-  Модуль «Повар».

-  Модуль «Бармен».

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

Модуль «Администратор». Администратор заносит информацию по персоналу (ФИО персонала, количество отработанных часов, должность), которая попадает в БД, а в БД формируется отчет по персоналу, который передается в ЦО.

Модуль «Официант». Официант получает из БД все наименования блюда. Заполняя формы, официант вносит в БД информацию о заказе (номер заказа, номер столика, наименования заказанного блюда, количество порций, дату).

Модули «Повар» и «Бармен» работают одинаково. Повар и бармен получают информацию из БД (наименования блюда, количество порций, рецепт).

2.1.5 Разработка алгоритма функционирования СИП МРЗ

Алгоритм - это

·  описание последовательности действий для решения задачи или достижения поставленной цели;

·   правила выполнения основных операций обработки данных;

·  описание вычислений по математическим формулам.

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

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

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

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

Рассмотрим алгоритмы работы каждого из модуля.

Начнем с модуля «Официант» . После того как карта отсканирована и принята происходит ввод данных о заказе. Затем идет проверка категории заказа (блюда или напиток). Если это напиток, то происходит подбор файлов-рецептов напитков. Если это блюдо, то подбор файлов-рецептов блюд. Затем идет формирование счета и вывод его на кассу.

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

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

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

2.1.6 Разработка пользовательского интерфейса

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

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

1)  Меню;

2)  Вход;

3)  Информация;

4)  Список;

5)  Логическое.

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

1)  Меню действий и нисходящее меню;

2)  Тело формы;

3)  Область функциональных клавиш.

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

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

Некоторые формы будут иметь меню действий, а другие нет.

Меню действий и нисходящее меню обеспечивают два замечательных преимущества для пользователей.

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

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

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

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

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

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

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

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

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

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

Страницы: 1, 2, 3, 4, 5, 6