Файл: Проектирование реализации операций бизнес-процесса «Реализация билетов через розничные кассы» (Характеристика предприятия).pdf
Добавлен: 01.04.2023
Просмотров: 60
Скачиваний: 1
СОДЕРЖАНИЕ
1. Технико-экономическая характеристика предметной области и предприятия
2. Используемые классификаторы и системы кодирования
3. Характеристика нормативно-справочной, входной и оперативной информации
4. Программное обеспечение задачи
4.1. Общие положения (дерево функций и сценарий диалога)
4.2. Характеристика базы данных
4.3. Структурная схема пакета (дерево вызова программных модулей)
Условно-постоянная информация будет храниться в справочниках. В системе потребуются следующие справочники:
- Справочник «Места»;
- Справочник «Матчи»;
- Справочник «Билеты»;
- Справочник «Концерты»;
- Справочник «Спортивные мероприятия»;
- Справочник «Команды»;
- Справочник «Исполнители».
Формы для ввода справочников должны позволять просматривать, добавлять, редактировать, удалять записи. При проектировании макетов форм ввода справочников применим анкетную форму расположения реквизитов, удобную для ввода и актуализации справочников.
Все экранные формы должны быть удобными, понятными, эргономичными. Общий цвет информационной части должен быть спокойных тонов, не вызывающих усталости пользователя. Цвет полей, подлежащих вводу с клавиатуры, должен отличаться от цвета информационной части. Каждое поле должно быть снабжено подсказкой, которую следует выдавать на экран при неправильных действиях пользователя. Должна быть обеспечена возможность исправления ошибок во введенных данных.
3) Система классификации и кодирования. В системе необходимо учесть принятую на предприятии систему кодирования документов, а именно: документы одного типа нумеруются последовательно с начала года. Система кодирования артикулов товара также используется существующая на предприятии, т.к. она достаточна, привычна, и используется не только в автоматизируемом подразделении, но и в других отделах предприятия.
Необходимо разработать локальную систему классификации и кодирования для следующих объектов учета:
- билетов;
- матчей;
- мест;
- спортивных мероприятий
4) Информационная база. Центральным компонентом информационного обеспечения является информационная база (ИБА), представляющая собой организованную определенным способом совокупность данных, хранимых в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. [1]
Существуют следующие способы организации информационной базы: совокупность локальных файлов, поддерживаемых функциональными пакетами прикладных программ, и интегрированная база данных, основанная на использовании универсальных программных средств загрузки, хранения, поиска и ведения данных, то есть системы управления базами данных (СУБД).
Локальные файлы обеспечивают более быстрое время обработки данных, однако при таком способе организации ИБ в информационной системе наблюдается высокая степень дублирования данных, несогласованность данных, отсутствие гибкости доступа к информации. Интегрированная база данных – это совокупность взаимосвязанных, хранящихся вместе данных при такой минимальной избыточности, которая допускает оптимальное их использование в различных приложениях.
Для решения поставленной задачи требуется интегрированная база данных.
Основными способами организации БД являются создание централизованных и распределенных БД. [4] В рассматриваемой задаче не предполагается распределенная структура ИС, т.к. задача небольшая по объему данных и по количеству пользователей.
Таким образом, для решения поставленной задачи необходима интегрированная централизованная база данных.
3. Характеристика нормативно-справочной, входной и оперативной информации
При решении задач подсистемы обрабатываются следующие документы/информация:
Входные:
- Ежедневно в начале рабочего дня заполняется документ, в котором указываются данные о билетах, которые есть в наличии. Таким образом , в течении дня заполняется выходной документ, где будет содержаться информация о проданных билетах, абонементах и сданных билетах. По окончанию рабочего дня или определенного периода менеджер по продажам произведет сравнение полученных данных.
Выходные:
- Занесение в отчет ведомости о продаже билета, которая содержит:
серийный номер билета;
дата/время продажи билета;
категория билета;
номер кассы;
дата и время матча;
название и тип матча;
цена билета.
- Ведомость о сдаче документа, которая содержит:
серийный номер билета;
дата/время продажи билета;
дата/время сдачи билета;
категория билета;
номер кассы;
дата и время матча;
название и тип матча;
цена билета;
размер комиссии при сдаче билета;
сумма денег, возвращенная клиенту;
причина сдачи.
- Ведомость об обмене билета, которая содержит:
дата/время обмена билета;
серийный номер билета 1
категория билета 1;
серийный номер билета 2;
категория билета 2;
разница в цене;
номер кассы.
- Ведомость о продаже абонемента, которая содержит:
серийный номер абонемента;
дата приобретения;
номер кассы;
список названий и дат матчей;
цена абонемента;
ФИО клиента.
- Отчет о работе касс на опр.период:
дата создания отчета;
тип отчета;
собственно сам отчет;
- Карта свободных мест:
- дата и время;
- карта свободных мест.
Анализ накапливаемой количественно-суммовой информации в базе данных проводится в модуле аналитики с последующим выводом выходных данных в виде графических диаграмм. Параметры обрабатываемой информации должны корректироваться в зависимости от устанавливаемого пользователем интервала времени и конкретного магазина или итоговая информация за весь период по всему предприятию.
Система должна иметь возможность последующей реорганизации и расширения для улучшения её возможностей или добавления функций. Должен обеспечиваться контроль ввода данных при отсутствии избыточности, а также надежное хранение и целостность базы данных.
4. Программное обеспечение задачи
4.1. Общие положения (дерево функций и сценарий диалога)
При разработке ИС, решающей задачи автоматизации документооборота, важным этапом является описание иерархии функций управления и обработки данных разрабатываемого программного продукта
Дерево функций представляет собой иерархическую структуру действий, реализованных в ИС. Все действия (функции) программного продукта можно разделить на два основных подмножества:
1) служебные функции – идентичны для всех автоматизированных систем управления предприятием на современном уровне развития аппаратных и программных средств. Функции этого вида призваны обеспечить безопасность ввода, обработки и хранения информации, облегчить работу с системой, сделать ее наиболее удобной и незатруднительной для конечного пользователя.
2) основные функции управления и обработки данных – свойственны как информационным системам любой специализации, так и именно данной ИС. Они отражают особенности процесса обработки информации, получения результатов, ведения информационной базы проекта. Эти функции организованы в том порядке и в том составе, которые продиктованы условиями обработки и управления данными в конкретной предметной области.
Состав и классификация функций разрабатываемого программного продукта представлены в виде дерева функций (рис.4.1).
Рис.4.1. Дерево функций ИС
На данном этапе разработки проекта ИС необходимо также выбрать язык общения системы с конечным пользователем.
Диалог – это процесс обмена сообщениями между пользователем и ИС, при котором осуществляется постоянная смена ролей информатора и реципиента (пользователя, принимающего информацию), причем смена ролей достаточно оперативна.
В процессе диалога возможно:
- двустороннее управление на базе языка типа «запрос-ответ»,
- одностороннее управление со стороны ИС с языком общения типа «меню», «заполнения шаблона», ответа по «подсказке»,
- одностороннее управление со стороны пользователя с использованием языка директив (команд).
При использовании для общения языка «меню» в диалоговой системе должна присутствовать система планирования и управления диалогом, в функции которой входит:
- управление процессом диалога,
- обеспечение интерфейса пользователя,
- обеспечение выполнения сервисных или справочных функций,
- анализ и обработка ошибочных ситуаций,
- вызов обрабатывающих программ.
При разработке данного проекта система общения с пользователем организована таким образом, что основная часть диалога ведется на языке типа «меню», а заполнение форм входных документов – по «шаблону». Таким образом, происходит одностороннее управление процессом обработки данных со стороны ИС.
Структура сценария диалога в совокупности с деревом функций, которое отражает состав и иерархию функций системы, дает возможность определить состав кадров диалога, содержание каждого кадра и их соподчиненность.
Сценарий диалога предусматривает возможность обеспечения следующих функций управления ходом решения поставленных задач:
- возможность работы с экранными формами входных документов,
- формирование выходных документов,
- корректировка вводимых данных,
- просмотр введенной информации,
- работа с таблицами нормативно-справочной информации,
- протоколирование действий пользователя,
- помощь на всех этапах работы.
Сценарий диалога представлен на рисунке 4.2.
Рисунок 4.2. Сценарий диалога с ИС
Сценарий диалога состоит из двух логически связанных частей:
1) Основные меню, относящиеся к головному, то есть те экраны меню, которые видит пользователь, прежде чем приступить к выполнению основных функций, согласно дереву функций. Основные меню предполагают обязательные действия пользователя при работе с ИС.
2) Сервисные меню, которые становятся доступны конечному пользователю после того, как выдана на экран соответствующая форма документа. Сервисные меню предполагают возможные действия, одно из которых может являться необязательным к выполнению.
4.2. Характеристика базы данных
В таблице 4.1 представлено описание полей таблицы «Билеты». Данная таблица служит для хранения информации по билетам.
Таблица 4.1
Структура таблицы «Билеты»
Название |
Тип |
Размер поля |
Описание |
Код_билета |
счетчик |
5 |
Уникальный ключ записи |
код места |
числовой |
5 |
Идентификатор места |
код спортивного мероприятия |
числовой |
5 |
Идентификатор спортивного мероприятия |
код матча |
числовой |
5 |
Идентификатор матча |
код концерта |
числовой |
5 |
Идентификатор концерта |
В таблице 4.2 представлено описание полей таблицы «Места». Данная таблица служит для хранения информации по наличию мест на то или иное мероприятие.
Таблица 4.2
Структура таблицы «Места»
Название |
Тип |
Размер поля |
Описание |
Код_места |
счетчик |
Длинное целое |
Уникальный ключ записи |
номер места |
числовой |
номер места |
В таблице 4.3 представлено описание полей таблицы «Матчи». Данная таблица служит для хранения информации о матчах.
Таблица 4.3
Структура таблицы «Матчи»
Название |
Тип |
Размер поля |
Описание |
Код матча |
Счетчик |
Длинное целое |
Уникальная запись |
Дата и время проведения |
Дата/время |
Дата проведения матча |
|
Код команды1 |
Числовой |
5 |
Код команды участника-1 |
Код команды 2 |
Числовой |
5 |
Код команды участника-2 |
В таблице 4.4 представлено описание полей таблицы «Концерты».
Таблица 4.4
Структура таблицы «Концерты»
Цена |
Тип |
Размер поля |
Описание |
Код концерта |
Числовой |
5 |
Идентификатор |
Код исполнителя |
Числовой |
20 |
Идентификатор исполнителя |
Дата и время проведения |
Дата/время |
20 |
Дата и время проведения концерта |