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

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 Разработка алгоритма функционирования СИП МРЗ

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

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

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

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

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

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

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

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

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