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

Таблица 4

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

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

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

Таблица 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 ошибка на десять тысяч строк кода.

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

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

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

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

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

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

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

Заключение

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

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