Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Автоматизация продажи билетов в кинотеатре Радуга кино г. Москва

Содержание:

Введение

В данной работе необходимо разработать предложения по автоматизации для продажи билетов в кинотеатре Радуга.

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

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

-A (VIP) — самые дорогие места с максимально комфортными для просмотра условиями;

-B (Comfort) —место меньшей, чем A, стоимости и комфортности, находящиеся в зоне наилучшего обзора, более удобные и соответственно дорогие чем C;

-C (Normal) – наиболее экономные места, без каких-либо выраженных преимуществ. В кинотеатре ведется учет состояния зрительных мест.

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

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

Также кинотеатр предоставляет возможность бронирования билетов.

Таким образом, в функционирование кинотеатра входит:

Продажа билетов;

Контроль наполняемости зала;

Предоставление информации о репертуаре кинотеатра;

Услуги бронирования билетов и снятия брони;

Возврат билетов.

В условиях перехода общественного развития в информационную эпоху, становится возможным создание электронной экономики, для которой характерны немного другие правила развития, по сравнению с классической экономикой. Развитие этого вида экономики напрямую зависит от развития всемирной сети Internet, которая составляет инфраструктуру этого вида экономики. Проявлением электронной экономики является электронный бизнес. Электронный бизнес - это то, что выходит, когда вы объединяете ресурсы традиционных информационных систем с широтой распространения Web и соединяете ключевые системы бизнеса через сети Intranet, Extranet и Web непосредственно с ключевыми целевыми аудиториями - потребителями, рабочими и поставщиками. В свою очередь, электронная коммерция является одной из разновидностей электронного бизнеса, основной сутью которой является возможность торговли через сеть.

1. Технико-экономическая характеристика предметной области и предприятия

1.1. Характеристика предприятия и его деятельности.

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

На сегодняшний день кинотеатр «Радуга кино» занимает достойное место среди кинотеатров Петербурга. Кинотеатр представляет собой мультиплекс, состоящий из 7 залов. В Москве кинотеатр «Радуга кино» не является самым большим мультиплексом, но зато значительно выигрывает в местоположении. В мультиплексе 4 зала класса «стандарт», каждый из которых вмещает по 130 человек. Все эти залы кинотеатра «Радуга кино» в Москве оборудованы мягкими креслами, снабженными откидными подлокотниками, регулируемыми спинками и держателями для стаканов.

В кинотеатре «Радуга кино» располагается один из самых удобных премьерных залов Москвы. Он рассчитан на 250 человек. Для премьер, фестивалей или же презентаций в зале построена сцена, оборудованная микрофонами и различной звуковоспроизводящей техникой. Так же кинотеатр «Радуга кино», обладает еще двумя уникальными залами: Малым залом и VIP-залом. В Малом зале располагаются 20 кожаных мягких кресел, снабженных регулируемыми спинками и держателями для напитков. VIP-зал рассчитан на 30 мест, в котором установлены мягкие бордовые диваны и перед каждым диваном расположен столик, оборудованный телефоном, по которому зрители могут сделать заказ в баре, находящемся в здании мультиплекса. Так же на территории мультиплекса располагается кино-бар, который именуется попкорн-баром, и коктейль-бар.

Генеральный директор определяет, формулирует, планирует, осуществляет и координирует все виды деятельности кинотеатра, руководствуясь "Положением о кинообслуживания" и другими нормативными материалами. А так же, организует работу кинотеатра, обеспечивает соответствие кинотеатра лучшим мировым образцам.Основные Технико-экономические показатели кинотеатра «Радуга» за 2015-2016 гг. представлены в таблице 1.

Таблица 1

Технико-экономические показатели объекта управления

№ п\п

Наименование характеристики (показателя)

Значение показателя на определённую дату либо за период

1

Выручка, тыс. руб.

1 кв. 2016г. – 253 734

2 кв. 2016г. – 213 534

3 кв. 2016г. – 230 213

4 кв. 2016г. – 206 563

2

Себестоимость (затраты), тыс. руб.

1 кв. 2016г. – 210 465

2 кв. 2016г. – 207 645

3 кв. 2016г. – 213 349

4 кв. 2016г. – 201 563

3

Прибыль, тыс. руб.

1 кв. 2016г. – 43 269

2 кв. 2016г. – 5 889

3 кв. 2016г. – 16 864

4 кв. 2016г. – 5 000

4

Чистая прибыль тыс. руб.

1 кв. 2016г. – 12 634

2 кв. 2016г. – 3 523

3 кв. 2016г. – 7 543

4 кв. 2016г. – 3 457


5

Рентабельность продаж,%

1 кв. 2016г. – 17,06

2 кв. 2016г. – 2,86

3 кв. 2016г. – 7,33

4 кв. 2016г. – 2,43

Проанализировав данные, можно сделать вывод: в разные сезоны года посещаемость кинотеатра разнообразная. Это объясняется, в основном, репертуаром. Количество зрителей зависит от того, какие кинопремьеры выходят на экран. Также это связано с праздниками: прибыль в первом квартале выше, чем в четвертом или во втором, поскольку на этот период приходятся такие праздники, как Новый год, День святого Валентина, Международный женский день и т.д. Высокую прибыль в третьем квартале можно объяснить тем, что у основной аудитории кинотеатра - школьников и студентов - каникулы в июле и августе.

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

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

1.2. Организационная структура управления предприятием.

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

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

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

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

.

Рисунок 1. Организационная структура кинотеатра «Радуга кино»

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

Высшее руководство предприятия может при этом сосредоточиться на постановке и решении стратегических задач.

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

1.Стабильность (наиболее эффективна в стабильной среде) 2. Экономия на управленческих расходах 3.Специализация и компетентность 4.Быстрое решение простых проблем, находящихся в компетенции одной функциональной службы 5.Ориентация на стабильную технологию и сложившийся рынок 6. Ориентация на ценовую конкуренцию1. Гибкость (наиболее эффективна в динамичной среде) 2. Оперативность принятия решений 3. Междисциплинарный подход 4. Быстрое решение сложных межфункциональных проблем 5. Ориентация на новые рынки и технологии 6. Ориентация на неценовую конкуренцию

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

1.3. Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов.

Характеристика задач, которые разрешаются на сервере

Код задачи Наименование задачи Назначение задачи Режим решения Периодичность решения

0810 Заказ билета .Оформление заказа покупателем .Интерактивный. По запросу клиента.

0812Формирование реестра заказов. Получение реестра заказов менеджером по продаже Интерактивный. Один раз в день.

Выбор и обоснование способа приобретения ИС для автоматизации задачи

Из-за того, что Internet-технологии в своем большинстве являются открытыми технологиями, для разработки самих дополнений можно использовать любой текстовый редактор. Но для разработки дополнений данной квалификационной работы использовался профессиональный пакет разработки Web-страниц Macromedia Dreamweaver MX, который соединяет в себе скорость визуальной разработки сайтов и точность ручной разработки. Кроме того этот пакет поддерживает разработку PHP-скриптов.

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

Для хранения и выборки данных используется СУБД Interbase компании Borland Software Corporation. Она зарекомендовала себя как легкая СУБД с достаточно высокими скоростными показателями и малой потребностью системных ресурсов. Кроме того, по сравнению со стандартной для решения задач данного типа СУБД MySQL, СУБД Interbase имеет достаточные функциональные возможности для последующей интеграции в подсистемы торговой организации. Это, прежде всего, объясняется поддержкой триггеров, процедур, которые сохраняются на сервере, и представлений.

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

Для разметки Web-страниц использовался язык гипертекстовой разметки HTML (HyperText Markup Language). Сам язык реализован в виде дескрипторов маркеров, которые описывают размещения элементов страницы, а также дополнительные характеристики каждого элемента.

Источниками информации для задачи, что разрешается, есть: отдел сбыта и бухгалтерия.

Входной информацией для задачи является информация справочников билетов и их описания.

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

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

Построение модели информационной системы начинается с описания функционирования системы в целом в виде контекстной диаграммы.

Рисунок 2 – Контекстная диаграмма «Продажа билетов в кинотеатре »

Взаимодействие системы с окружающей средой описывается с помощью входов («Обращения клиентов», «Репертуар» и «Расписание сеансов»), выходов («Билет», «Возврат билета», «Бронь» и «Снятие брони»), управления («Лицензия», «Нормы» и «Законы РФ»).

Клиенты – люди, создающие спрос на услуги Кинотеатра.

Репертуар – Набор фильмов или других товаров демонстрируемых в Кинотеатре.

Содержит:

- Наименование

- Описание

- Актеров

- Постер (картинка)

Расписание сеансов – Список всех проводимых Кинотеатром сеансов

Содержит:

- Наименование

- Дата и время начала сеанса

- Длительность

- Стоимость билетов класса A, B, C

- Зрительный зал в котором проводится сеанс

Законы РФ – законы по защите прав потребителя, и всероссийские нормы на осуществление коммерческой деятельности.

Билет – право Клиента на посещение конкретного сеанса

Возврат билета – случай, когда Клиент вернул билет Кинотеатру и получил затраченные на него денежные средства обратно

Бронь – закрепление места в зале за Клиентом. Изъятие места из продажи до срока пока оно не будет выкуплено Клиентом, или пока истечет срок бронирования

Снятие брони – освобождение места в зале. Внесение его в продажу.
Кассир – лицо исполняющее обязанности продажи билетов.

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

Рисунок 3 – Диаграмма декомпозиции «Продажа билетов в кинотеатре»

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

Предоставление информации - предоставление пользователю всей доступной информации о расписании и сеансах

Создание заказа - сведение всех требований Клиента в один заказ

Приобретение билета - совершение операции купли-продажи между Клиентом и Кассиром и закрепления за Клиентом билета

Проверка билета - операция по подтверждению действительности билета.

Произведем дальнейшее разбиение на подсистемы.

Рисунок 4 – Диаграмма декомпозиции «Предоставление информации»

Опишем процессы, представленные на данной диаграмме декомпозиции.

Получение информации – принятие клиентом решения получить информацию

Покупка билета – принятие клиентом решения приобрести билет на сеанс

Операции с бронью – принятие клиентом решения осуществить операцию с бронью

Вернуть билет - принятие клиентом решения вернуть приобретенный ранее билет

Рисунок 5 – Диаграмма декомпозиции «Создание заказа»

Опишем процесс создания заказа.

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

Требования Клиента – набор, заполненных Клиентом данных о сеансе которые однозначно его (сеанс) позиционирует.

Генерирование заказа – система формирует Заказ исходя из требований Клиента и Норм предприятия.

2.Информационное обеспечение задачи

2.1 Информационная модель и её описание

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

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

ФОМ работы отдела по работе с клиентами можно представить следующим образом (см. рисунок 5).

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

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

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

Рисунок 7 - Информационная модель кинотеатра «Радуга кино»

2.2 Используемые классификаторы и системы кодирования

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

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

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

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

- сортировка и поиск информации по ключевым признакам;

- разработка сводных отчетов по различным признакам;

- декодирование при переходе от кодов-признаков к их наименованиям при печати сводных отчетов.

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

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

Таблица 2

Используемые системы кодирования

Наименование кодируемого множества объектов

Значность кода

Система кодирования

Система классификации

Вид классификатора

Код протокола

Длинное целое

Порядковая

Отсутствует

Локальный

Код переданного дела

Длинное целое

Порядковая

Отсутствует

Локальный

Код граждан

Длинное целое

Порядковая

Отсутствует

Локальный

Код сотрудника

Длинное целое

Порядковая

Отсутствует

Локальный

2.3 Характеристика нормативно-справочной, входной и оперативной информации.

К формированию входных данных так же относится форма поиска (рисунок 8)

http://textarchive.ru/images/673/1344442/fa2db45c.png

Рисунок 8 - Макет формы Поиска

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

Для ввода прав доступа к документам используется форма Права (рисунок 8 )

http://textarchive.ru/images/673/1344442/49195e4f.png

Рисунок 3 - Макет формы Права

Рабочая зона разделена на 2 части.

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

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

Для создание более универсальных договоров используется форма Создание шаблона (рисунок 9)

http://textarchive.ru/images/673/1344442/d3a1f099.png

Рисунок 9 - Макет формы Создание шаблона

На форме находится многостраничное поле ввода для введение HMTL кода и кнопки Применить и Отмена.

Для создание договора на утверждение используется форма “Создание задачи и документа” (рисунок 10)

http://textarchive.ru/images/673/1344442/183858f6.png

Рисунок 10 - Макет формы Создание задачи и документа

На форме расположено выбор Шаблона, данные берутся из справочника Шаблоны, название шаблона и раздел в котором создаётся задача. При выборе шаблона, он подряжается в серую область на форме.

Для подписание на рассылки необходима форма Подпись на рассылки (рисунок 11)

http://textarchive.ru/images/673/1344442/11ad5a9c.png

Рисунок 11 -Макет формы Подпись на рассылки

На ней представлен выбор раздела форума к которому происходит привязка на рассылку, данной формой происходит добавление в справочник Подписка.

Сводная таблица по справочникам приведена в таблице 3

Таблица 3

Параметры справочников

Название справочника

Ответственный за ведение

Средний объём справочника в записях

Средняя

частота актуализации

( раз в год )

Средний объем актуализации в %

Шаблоны

Администратор

5

5

90

Рассылки

Менеджер

50

50

50

Пользователи

Администратор

10

10

80

Группы

Администратор

3

3

90

Реквизитный состав справочников следующий:

Справочник шаблоны имеет поле уникального номера, поле для ввода кода шаблонна договора.

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

Справочник Пользователи имеет поле уникального номера, номер группы к которой он относится, данные о фамилии имени отчестве и права доступа.

Справочник Группы имеет поле уникального номера, номер участника и номер его одногруппника.

Основными таблица сохраняющими результат ИС являются таблицы

Форумы и Файлы.

Таблица Форумы имеет следующие реквизиты

1) № Записи – номер уникальной записи в форуме

2) № сообщения – номер сообщения-комментария из таблицы Сообщения

3) Проверен – указывает на статус проверки

4) Согласован - указывает на статус согласования

5) Закрыто - указывает на статус закрытия документа, что запрещает его дальнейшее обсуждении

6) № файла – номер файл из таблицы Файлы

7) № пользователя – номер пользователя создавшего запись из таблицы

8) Права родителя – права создателя

9) Права группы – права группы

10) Права остальных – права всех остальных участников.

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

Макет экранной формы «Результат поиска» приведен на рисунке 12.

http://textarchive.ru/images/673/1344442/676ad048.png

Рисунок 12 - Макет экранной формы «Заявка»

На форме предоставлено поле, где мы вводили требуемый запрос, кнопка поиска и результативная искомая информация представленная в виде таблице с столбцами: №, ФИО, Комментарий. Данные формы создаются на основе таблицы форумы.

Так же системой генерируются файлы договоров по шаблону. Пример созданного документа можно посмотреть в Приложении 1. Файл формируется на основе введенных данных в форме “Создание задачи и документа”. Основные реквизиты файла:

1) Лицо в виде исполнителя

2) Лицо в виде заказчика

3) Перечень услуг

4) Права и обязанности сторон

Главной формой является форма утверждения договора ( рисунок 13)

http://textarchive.ru/images/673/1344442/7ccac269.png

Рисунок 13 - Макет экранной формы «Утверждение договора»

Форма имеет следующие реквизиты:

1) Название договора

2) Комментарий договора

3) Комментарии пользователей

4) Права участников

5) Текст для добавление комментария.

2.4.Характеристика результатной информации

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

1. «Отчет по согласованным заявкам»

Формируется на основе след таблиц и полей:

  • Дата создания заявки
  • Пользователь (заявитель)
  • Ответственная группа
  • Назначенный на заявку сотрудник
  • Статус
  • Приложенное исходное письмо (тема и тело письма в оригинале)

2. Отчет ”заявки по местоположению заявителя”:

Содержит таблицу со следующими полями:

  • Дата создания заявки
  • Даты писем по согласованию
  • Пользователь (заявитель)
  • Месторасположение(город)
  • Адрес (улица, дом, корпус, офис)
  • Ответственная группа
  • Текущий статус переписки и зарегистрирована ли заявка
  • Приложенное окончательное письмо (тема и тело письма в оригинале)

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

3.Программное обеспечение задачи

3.1 Общие положения (дерево функций и сценарий диалога)

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

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

Рисунок 14 Дерево функций

Опишем процессы, представленные на данной диаграмме.

Расписание сеансов и стоимость билетов - Клиент получает информацию о сеансах:

- Наименование

- Дата и время начала сеанса

- Длительность

- Стоимость билетов класса A, B, C

- Зрительный зал, в котором проводится сеанс

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

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

Возврат в выбор операций - решение пользователя вернуться к выбору операций

3.2 Характеристика базы данных.

База данных – это совокупность структурированных и взаимосвязанных данных, относящихся к определенной предметной области.

Для создания, хранения, обработки и коллективного использования информации применяются специальные программные системы, называемые системами управления базами данных (СУБД).

К основным функциям СУБД относятся следующие:

· физическое размещение в памяти данных и их описаний;

· поддержка баз данных в актуальном состоянии;

· механизмы поиска запрашиваемых данных;

· доступ к данным при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

· способы обеспечения защиты данных от некорректных обновлений и/или несанкционированного доступа.

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

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

СУБД использует следующие модели и описания:

· инфологическую;

· даталогическую;

· физическую.

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

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

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

В основе каждой СУБД лежит концепция модели данных, то есть некоторой абстракции представления данных. Изначально были успешными две конкурирующие модели – иерархическая и сетевая. Иерархическая БД состоит из упорядоченного набора деревьев. Корпорация IBM разработала и внедрила язык описания данных DL/I (Data Language One), который моделировал данные в иерархической форме (представление данных в форме деревьев). Эта модель была разработана совместно с промышленными предприятиями и предназначалась для хранения и поддержки данных, которые иерархически связаны между собой, например, сметы материалов и списки деталей. Типичным представителем иерархической СУБД является СУБД IMS (Information Management System) компании IBM, первая версия которой появилась в 1968 г.

Таблица 4 «Должности»

Имя поля

Тип данных

Код должности

Числовой

Наименование должности

Текстовый

Оклад

Денежный

Обязанности

Текстовый

Требования

Текстовый

Таблица 5 «Жанры»

Имя поля

Тип данных

Код жанра

Числовой

Наименование

Текстовый

Описание

Текстовый

Таблица 6 «Репертуар»

Имя поля

Тип данных

Код сеанса

Числовой

Дата

Дата/время

Время начала

Дата/время

Время окончания

Дата/время

Цена билета

Денежный

Таблица 7 «Фильмы»

Имя поля

Тип данных

Код фильма

Числовой

Наименование

Текстовый

Код жанра

Текстовый

Длительность

Числовой

Фирма производитель

Текстовый

Страна производитель

Текстовый

Актеры

Текстовый

Возрастные ограничения

Числовой

Рисунок 15 – Фрагмент сценария диалога в кинотеатре Радуга

А так же, следует отметить, информационная база организована в форме корпоративной базы данных, мне обязано привести Пример фрагмента ER моделиC:\Users\Тигр\AppData\Local\Microsoft\Windows\INetCache\Content.Word\asdhagsafg.jpg

Рисунок 16 – Фрагмент ER-модели кинотеатра «Радуга»

3.3 Структурная схема пакета (дерево вызова программных модулей)

Рисунок 17 – Дерево программных модулей

3.4 Описание программных модулей.

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

Таблица 4

Описание функций модулей

№ п/п

Наименование модуля

Функции модуля

1.

Модуль безопасности

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

2.

Модуль инициализации интерфейса программы

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

3.

Модуль управления деревом объектов

Содержит процедуры и функции, позволяющие управлять отображением дерева объектов и его элементами

4.

Модуль взаимодействия с базой данных

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

5.

Модуль справочной системы

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

6.

Модуль «Справочники»

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

7.

Модуль ввода данных «Заявки»

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

8.

Модуль «Отчеты»

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

9.

Модуль «Печать документов»

Обеспечивает предварительный просмотр, настройку параметров документов и печать на принтере





Техническая сложность проекта (TCF - Technical Complexity Factor) вычисляется с учетом показателей технической сложности. Все показатели приведены в табл.4.

Каждому показателю присвоено значение в диапазоне от 0 до 5 (0 помечает отсутствие значимости показателя для данного проекта, 5 - высокую значимость) и значение с условием веса показателя.

Таблица 5.

Показатели технической сложности

Показатель

Описание

Вес

Значение

Значение с учетом веса

T1

Распределённая система

2

2

4

T2

Высокая производительность (пропускная способность)

1

4

4

T3

Работа конечных пользователей в режиме он-лайн

1

5

5

T4

Сложная обработка данных

1

3

3

T5

Повторное использование данных

1

3

3

T6

Простота установки

0,5

4

2

T7

Простота использования|употребления|

0,5

5

2,5

T8

Переносная

2

5

10

T9

Простота внесения изменений|смен|

1

5

5

T10

Параллелизм

1

0

0

T11

Специальные требования к безопасности

1

4

4

T12

Непосредственный доступ к|до| системе со стороны внешних пользователей

1

5

5

T13

Специальные требования к обучению пользователей

1

0

0

Сумма

37,5

Значение TCF вычисляется по формуле:

Формула 2.2.

TCF=0,6+(0,01*(oTi*Вагаi))

Следовательно, рассчитаем значение TCF для модуля регистрации:

Формула 2.2.

TCF=0,6+(0,01*37,5) = 0,975

4. Контрольный пример реализации и его описание.

Спецификация требований к информационной системе «ПРОДАЖА БИЛЕТОВ В КИНОТЕАТРЕ РАДУГА»

Цель

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

Определения, акронимы и сокращения

Основные определения приведены в документе Glossary.doc.

Ссылки:

Сопутствующая информация представлена в следующих документах:

требованиях совладельцев (Пользовательские требования.doc);

глоссарии (Glossary.doc).

2. Обзор системы

2.1 Обзор прецедентов

Предположения и зависимости

Система будет использоваться на территориально сосредоточенном (без внешних филиалов) предприятии.

В случае изменений в формах документов АИС должна претерпеть малосущественные изменения (нужно будет модифицировать отчётные формы).

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

Описание требований

Краткие описания вариантов использования

Основное действующее лицо: Клиент.

Другие участники прецедента: нет

Связи с другими вариантами использования: отсутствуют

Краткое описание.

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

Основой для генерирования билета и послужит этот набор предпочтений – заказ, который Клиент составляет сам (для примера – выбирает на какой сеанс пойти, какое место в зале приобрести).

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

Основное действующее лицо: Клиент.

Другие участники прецедента: Кассир

Связи с другими вариантами использования: отсутствуют

Краткое описание.

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

Основное действующее лицо: Клиент.

Другие участники прецедента: нет.

Связи с другими вариантами использования: отсутствуют

Краткое описание.

Данный прецедент позволяет Клиенту получить необходимую и достаточную информацию о репертуаре театра для составления Заказа. Клиент смотрит информацию о:

Наименование

Время начала

Длительность

Информацию о сеансе

Зал проведения

Цена билета:

Класс A

Класс B

Класс C

Основное действующее лицо: Клиент.

Другие участники прецедента: Кассир.

Связи с другими вариантами использования: отсутствуют

Краткое описание.

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

Основное действующее лицо: Клиент.

Другие участники прецедента: Кассир

Связи с другими вариантами использования: отсутствуют

Краткое описание.

На основе сгенерированного ранее Заказа Клиент может закрепить за собой право на конкретный билет не совершая финансовую операцию с Кассиром. Бронь осуществляется по желанию Клиента. Бронирование действительно до того момента когда до начала сеанса остается более 20 минут. В случае если билет не выкуплен по истечению этого срока бронь автоматически снимается с целью вернуть билет в оборот купли-продажи. Если билет выкупается до этого срока, то Клиент становится обладателем билета, а Кинотеатр получает деньги.

Основное действующее лицо: Клиент.

Другие участники прецедента: Кассир

Связи с другими вариантами использования: отсутствуют

Краткое описание.

Клиент обращается к Кассиру с целью снятие с Билета брони. Билет возвращается в оборот купли-продажи. Клиент лишается права на этот Билет(Кроме как в случае если Клиент снова обратиться к Кассиру с целью Купить/Забронировать Билет).

3.2 Специальные требования

3.2.1 Функциональность

3.2.1.1F1. Авторизация и аутентификация пользователей в системе

В АИС должны быть представлены справочник ролей пользователей (Клиент, Кассир) и справочник пользователей. Должна быть возможность регистрации пользователя и назначения пользователю роли.

3.2.1.3F2. Ведение расписания

В АИС должны быть представлены средства управления расписание сеансов и информации о сеансах.

3.2.2Применимость

3.2.2.1U1. Удобство использования

Интерфейс АРМ «Клиент» и «Кассир» должен быть обладать свойствами удобства и интуитивной ясности и не требовать дополнительной подготовки пользователей.

3.2.2.2U2. Помощь в режиме online

Все АРМ должны поддерживать контекстную справку в форме стандартного help операционной системы.

3.2.3Надежность

3.2.3.1R1. Доступность

АРМ Клиента, Кассира быть доступны в рабочие дни в рабочее время (как правило, с 8 до 18, если иное не указано распоряжением по предприятию).

3.2.3.2R2. Наработка на отказ

Среднее время безотказной работы – 10 рабочих дней.

3.2.3.3R3. Норма дефектов

Максимальная норма ошибок или дефектов – 1 ошибка на десять тысяч строк кода.

1

Рисунок 18 – Экранная форма отчёта

3

Рисунок 19– Экранная форма чека

2

Рисунок 20 – Форма продажи билетов

4

Рисунок 21 – Экранная форма Кинозала

5

Рисунок 22 – Экранная формы ввода данных из вышеуказанных форм

https://pp.userapi.com/c845417/v845417825/fe57f/JefzWCF3pKc.jpg

Рисунок 23 – Форма документа "карточка сотрудника"

8

Рисунок 23 – Форму условий отчёта

Заключение

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

Кинотеатр — коммерческое предприятие с зрительными залами, оборудованными для показа фильмов. В зале располагается экран и зрительные места.
С точки зрения функционирования или структуры кинотеатра ,можно сказать, что он располагает зрительными местами с разным уровнем сервиса ,комфортности и, соответственно, оплаты. Места могут быть разных типов:
-A (VIP) — самые дорогие места с максимально комфортными для просмотра условиями;
-B (Comfort) —место меньшей, чем A, стоимости и комфортности, находящиеся в зоне наилучшего обзора, более удобные и соответственно дорогие чем C;
-C (Normal) – наиболее экономные места, без каких-либо выраженных преимуществ. В кинотеатре ведется учет состояния зрительных мест.
Все клиенты желающие приобрести билет должны указать на какой сеанс они хотят его приобрести и класс зрительного места и оплатить стоимость билета.
Любое место зрительного зала имеет номер, по которому ведется учет занято оно или свободно для продажи.
Также кинотеатр предоставляет возможность бронирования билетов.
Таким образом, в функционирование кинотеатра входит:
Продажа билетов;
Контроль наполняемости зала;
Предоставление информации о репертуаре кинотеатра;
Услуги бронирования билетов и снятия брони.

Список использованной литературы

1. Ricardo, Argenton Ramos AIRDoc – An Approach to Improve the Quality of Requirements Document / Ricardo Argenton Ramos. - М.: LAP Lambert Academic Publishing, 2017. - 128 c – Режим доступа: https://elibrary.ru – Загл. с экрана

2. Администратор информационных технологий / IT Manager, №2, 2013. - М.: ИТ Медиа, 2017. - 970 c. -– Режим доступа: https://biblioclub.ru – Загл. с экрана.

3. Администратор информационных технологий / IT Manager, №4, 2013. - М.: ИТ Медиа, 2016. - 312 c. - Режим доступа https://biblioclub.ru. – Загл. с экрана.

4. Алиев, В. С. Информационные технологии и системы финансового менеджмента / В.С. Алиев. - М.: ИНФРА-М, 2016. - 320 c.- Режим доступа: https://clarivate.com/products/web-of-science Режим доступа: – Загл. с экрана.

5. Андерсон, Джордж У. Лучшие практики внедрения SAP / Андерсон Джордж У.. - М.: ЛОРИ, 2017. - 899 c. – Режим доступа: https://biblio-online.ru – Загл. с экрана.

6. Брусакова, И. А. Информационные системы и технологии в экономике / И.А. Брусакова, В.Д. Чертовской. - М.: Финансы и статистика, 2017. - 352 c. - Режим доступа: https://clarivate.com/products/web-of-science/ – Загл. с экрана.

7. Данелян, Т. Я. Экономические информационные системы (ЭИС) предприятий и организаций / Т.Я. Данелян. - М.: Юнити-Дана, 2015. - 284 c. - КиноКафе.su | :: Ваш путеводитель по кинотеатрам, ресторанам и кафе города Ульяновска [Электронный ресурс]. – Режим доступа: https://elibrary.ru – Загл. с экрана.

8. Демистификация ИТ. Что на самом деле информационные технологии дают бизнесу. - М.: Альпина Паблишер, 2015. - 296 c. – Режим доступа: https://elibrary.ru – Загл. с экрана.