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

Разработка сайта кинотеатра (Описание предметной области)

Содержание:

Введение

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

В качестве цели данного курсового проекта выступает проектирование web-сервиса киноцентра и его разработка. Для достижения поставленной цели необходимо решить ряд задач:

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

Данный проект должен решать задачи выбора сеанса, места и бронирования билета.

При написании курсовой работы, для моделирования IDEF0, IDEF3, DFD моделей было использовано средство проектирования AllFusion ERwin Data Modeler, а для построения UML диаграмм использовался программный продукт StarUML.

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ - МОДЕЛЬ AS-IS

1.1. Описание предметной области

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

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

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

Факт проверки билета сотрудником отмечается им путем специальной части билета, предназначенной именно для этого.

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

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

1.2. Обследование предметной области

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

Опишем модель «AS-IS» («как есть») – модель существующей организации процесса продажи билетов, осуществляемые кассирами в кассе. Для более наглядного описания модели создадим матрицу проекций (Таблица 1.1).

Таблица 1.1 – Матрица проекций

AS-IS

Web-сайт киноцентра

Выяснение потребностей

Просмотр данных о сеансах

Выбор сеанса

Бронирование

Выбор места в зале

Бронирование билета

Для более полного представления о текущей организации процесса продажи билетов в киноцентре была создана функциональная модель AS-IS в нотации IDEF0. Данная модель представлена в приложении А.

После построение модели «как есть» была создана модель «как должно быть» (TO BE) в нотации IDEF0. На диаграммах данной модели (Приложение А) отображается организация процесса продажи билетов после разработки и внедрения web-сайта киноцентра.

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

Данные диаграммы отображают связи системы с внешними объектами, а также потоки данных внутри моделируемой системы. DFD-диаграммы проектируемой ИС представлена в приложении Б.

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

ГЛАВА 2. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ

2.1. Техническое задание по ГОСТ 34.602–89

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

Техническое задание на разработку ИС web-сайт киноцентра представлено в приложении Г.

.

2.2. С-требования и D-требования

Главной целью созданию web-сервиса киноцентра является снижение нагрузки на кассиров и увеличение клиентов за счет использования удобного для них способа покупки билетов.

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

Требования к разрабатываемому программному продукту принято делить на две категории: С-требования и D-требования.

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

Вторая категория требований (D-требования) составляются для разработчиков и включают развернутое описание технической стороны реализации программного продукта: требования к используемым технологиям и средам разработки, к входным и выходным данным, к безопасности и т.п.

Функциональные требования к web-сайту киноцентра со стороны заказчика (C-требования):

  • Возможность управления контентом сайта из панели администрирования: добавление, изменение, редактирование данных о транслируемых фильмах и сеансах;
  • Защита панели администрирования от несанкционированного доступа с помощью пароля;
  • Просмотр неавторизованными пользователями данных о фильмах и сеансах;
  • Просмотр неавторизованными пользователями данных о наличии свободных мест на выбранный сеанс в виде схемы зрительного зала;
  • Самостоятельная регистрация пользователей для покупки билета;
  • Возможность выбора свободного места на схеме зрительного зала и онлайн оплаты стоимости билета;
  • Электронный билет можно скачать в формате PDF-документа и распечатать. Если у пользователя нет технической возможности распечатать бумажную версию билета, то он может записать номер билета и введя данный номер в специальный автомат в киноцентре получить бумажную версию билета, либо обратившись в кассу, в случае, если ни один из других способов не подходит;
  • Все данные о купленных билетах сохраняются в базе данных, с которой работают кассиры в настоящий момент (для исключения продажи нескольких билетов на одно и то же место в зрительном зале.

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

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

Существуют несколько типов D-требований:

1. Функциональные требования, описаны выше (С-требования).

2. Нефункциональные требования.

  • Производительность. Требования к производительности определяют временные ограничения, которые должны быть выполнены в программе. Сайт должен реагировать на действия пользователя с высокой скоростью, максимальное время отклика сайта на действие пользователя не должно составлять более двух секунд.
  • Надежность и безопасность. Требования надежности определяют надежность в измеряемых величинах. Требования такого типа предполагают вероятность неидеальной работы программы и ограничивают область ее несовершенства. Доступ к панели управления контента сайта должен быть защищен от несанкционированного доступа с помощью пароля. Все пароли должны храниться в базе данных только в зашифрованном виде. Предъявляются следующие виды к сложности устанавливаемого пароля:
  • Длина не менее 6 символов;
  • В пароле должна использоваться минимум одна цифра;
  • В пароле должна использовать минимум одна буква.
  • Обработка ошибок. При возникновении любых ошибок пользователю должно быть выдано соответствующее сообщение, а данные об ошибке занесены в log-файлы сайта.
  • Интерфейсные требования. Интерфейсные требования описывают формат взаимодействия различных частей программного продукта. Для работы с БД используются SQL-запросы.

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

ГЛАВА 3. ЭСКИЗНЫЙ ПРОЕКТ

3.1. Предварительная оценка затрат

Для каждой выделенной функции высчитано количество факторов каждого типа (Таблица 3.1) [6]:

  1. Внешние входы (входы, которые по-разному влияют на выполняемую функцию);
  2. Внешние выходы (отдельно считаются выходы для существенно различных алгоритмов);
  3. Внешние запросы (каждый независимый внешний запрос 1);
  4. Внутренние логические файлы (каждая уникальная группа пользовательских данных считается за 1);
  5. Внешние логические файлы (каждая уникальная группа пользовательских данных считается за 1).

Таблица 3.1 – Сопоставление функций системы информационным характеристикам и сложности

Функция системы

Информационная характеристика

Сложность

Авторизация

Внешний ввод

Ссылок на файлы – 1

Элементы данных – (3)

Сложность низкая (3)

Введение данных о фильмах и сеансах

Внешний ввод

Ссылок на файлы – 1

Элементы данных – (7)

Сложность низкая (3)

Просмотр данных о сеансах

Внешний вывод

Ссылок на файлы –1

Элементы данных – (7)

Сложность низкая (3)

Просмотр данных о наличии свободных мест

Внешний вывод

Ссылок на файлы – 1

Элементы данных – (3)

Сложность низкая (3)

Регистрация

Внешний ввод

Ссылок на файлы – 1

Элементы данных – (3)

Сложность низкая (3)

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

Таблица 3.2 – используемые внутренние логические файлы

Описание файла

Информационная характеристика

Сложность

ТБ «Фильмы»

Внутренний логический файл

Типы данных – 3.

Элементы данных – 9

Сложность низкая (7).

ТБ «Сеансы»

Внутренний логический файл

Типы данных – 4.

Элементы данных – 7

Сложность низкая (7).

ТБ «Залы»

Внутренний логический файл

Типы данных – 2.

Элементы данных – 3

Сложность низкая (7).

ТБ «Места»

Внутренний логический файл

Типы данных – 2.

Элементы данных – 4

Сложность низкая (7).

ТБ «Билеты»

Внутренний логический файл

Типы данных – 2.

Элементы данных – 6

Сложность низкая (7).

ТБ «Отзывы»

Внутренний логический файл

Типы данных – 3.

Элементы данных – 5.

Сложность низкая (7).

ТБ «Пользователи»

Внутренний логический файл

Типы данных – 4.

Элементы данных – 7.

Сложность низкая (7).

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

Таблица 3.4 – Информационные характеристики

Имя характеристики

Количество

Низкий

Средний

Высокий

Итого

Внешние вводы

4x3=12

0x4=0

0x6=0

12

Внешние выводы

3x3=9

0x5=0

0x7=0

9

Внешние запросы

0x3=0

0x4=0

0x6=0

0

Внутренние логические файлы

7x7=49

0x10=0

0x15=0

49

Внешние интерфейсные файлы

0x5=0

0x7=0

0x10=0

0

Общее количество

70

Определение веса для 14 общих характеристик проекта:

  1. Обмен данными – 2;
  2. Распределенная обработка данных – 2;
  3. Производительность – 5;
  4. Ограничения по аппаратным – 3;
  5. Транзакционная – 1;
  6. Интенсивность взаимодействия с пользователем – 2;
  7. Эргономика – 4;
  8. Интенсивность изменения данных (ILF) – 4;
  9. Сложность обработки – 0;
  10. Повторное использование – 3;
  11. Удобство инсталляции – 2;
  12. Удобство администрирования – 5;
  13. Портируемость – 5;
  14. Гибкость – 5.

Расчет суммарного эффекта 14 системных характеристик (total degree of influence, TDI) осуществляется простым суммированием:

TDI = ∑ DI = 43, (1)

Расчет уточненного функционального размера:

VAF = (TDI *0.01) + 0.65 = (43 *0.01) + 0.65 = 1.08, (2)

Расчет количества выровненных функциональных точек (AFP):

AFP = UFP * VAF = 70*1.08=75.6, (3)

Оценка количества строк кода:

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

KLOC = (AFP*N)/1000 = (75.6* 50)/1000 = 3,780, (4)

Оценка затрат труда и продолжительности проекта:

Затраты в человеко-месяцах:

= 9.7, (5)

Количество месяцев:

= 5.93, (6)

Где a, b, c, d – коэффициенты для распространенных типов проектов (небольшие программные проекты, над которыми работает небольшая группа разработчиков с хорошим стажем работы, устанавливаются мягкие требования к проекту): a = 2,4, b = 1,05, c = 2,5, d = 0,38.

3.2. Диаграммы вариантов использования и деятельности системы в целом

Диаграмма вариантов использования (use case diagram) (или диаграмма прецедентов) описывает функциональное назначение системы, то есть то, что система должна делать исходя из цели её создания.

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

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

Диаграмма деятельности (activity diagram) представляет, по существу, блок-схему, которая показывает, как поток управления переходит от одной деятельности к другой.

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

3.3. Диаграммы состояний и последовательности

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

Автомат (State machine) – это описание последовательности состояний, через которые проходит объект на протяжении всего жизненного цикла, реагируя на события, - в том числе описание реакций на эти события.

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

Диаграмма состояний web-сайта киноцентра представлена в приложении Ж.

Диаграммы последовательности (sequence diagram) UML отражают поток событий, происходящих в рамках реализации конкретного варианта использования.

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

На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

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

Диаграммы последовательности приведены в приложении Е.

3.4. Диаграммы классов (ER-модель)

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

3.5. Диаграммы компонентов

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

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

Диаграммы компонентов представлены в приложении К.

ГЛАВА 4. ОПИСАНИЕ РАЗРАБОТКИ

4.1 Описание средств разработки

Для разработки системы использовалась база данных MySQL mariadb 10.1 и язык написания сайта php. Сайт размещен на хостинге hostia.ru.

4.2 Описание верстки сайта

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

Рисунок 1 – Подключение к БД

На рисунке 2 изображена форма авторизации. Для формы задан метод отправки POST.

Рисунок 2 – Форма авторизации

На рисунке 3 изображен java-script формирования текущей даты на клиенте.

Рисунок 3 – Формирования даты

На рисунке 4 изображен запрос списка фильмов.

Рисунок 4 – Запрос списка фильмов

На рисунке 5 изображена регистрация пользователя.

Рисунок 5 – Регистрация пользователя

На рисунке 6 изображен java-скрипт проверки заполнения полей.

Рисунок 6 – Скрипт проверки заполнения полей

4.3 Тестирование

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

Рисунок 7 – Главная страница сайта киноцентра

Рисунок 8 – Главная страница после авторизации/регистрации

На рисунке 9 изображена форма регистрации.

Рисунок 9 – Форма регистрации

На рисунке 10 изображены сообщения об ошибках при заполнении формы.

Рисунок 10 – Проверка обязательных полей на странице регистрации

Рисунок 11 – Список забронированных билетов

Рисунок 12 – Поиск сеансов для бронирования

Рисунок 13 – Действие при нажатии на бронирование сеанса

ЗАКЛЮЧЕНИЕ

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

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

В процессе проектирования web-сайта были созданы модели в нотациях IDEF0, IDEF3, DFD и UML для более наглядного представления задач сайта, его внутренней структуры и наполнения.

В результате моделирования были построены диаграммы:

  • Диаграммы IDEF0 для модели AS-IS;
  • ДиаграммыDFDдля модели AS-IS;
  • ДиаграммыIDEF3для модели AS-IS;
  • Общая диаграмма вариантов использования;
  • Диаграммы последовательностей;
  • Диаграммы состояний;
  • Диаграммы деятельности;
  • Диаграмма классов;
  • Диаграмма развёртывания.

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

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

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

  • Избачков Ю.С., Петров В.Н., Васильев А.А. Информационные системы: Учебник для вузов. – СПб.: Питер, 2017. – 544 с.
  • Каюмова А.В. Визуальное моделирование систем в StarUML: Учебное пособие/ А.В. Каюмова. Казань. – Казанский федеральный университет, 2018. – 104с.
  • Михеева В., Харитонова И. Microsoft SQL Server. - СПб.: БХВ – Санкт-Петербург, 2015, 1072с.
  • Исаев Г.Н. Проектирование информационных систем: учебное пособие/ Г.Н. Исаев – Москва. Омега-Л, 2015. – 424 с.
  1. Орлов С. Технологии разработки программного обеспечения: учебник / С. Орлов. – СПб. : Питер, 2016. – 464 с.
  2. Проектирование автоматизированных систем обработки информации и управления: Методические указания по курсовому проекту / ПРАСОИУ_КП.pdf // Сост. Мелихов А.Ю. – Ханты-Мансийск: Информационно-издательский центр ЮГУ, 2017. – 87 с.
  3. Проектирование автоматизированных систем обработки информации и управления: Краткий конспект лекций / ПРАСОИУ_ЛК.pdf // Сост. Мелихов А.Ю. – Ханты-Мансийск: Информационно-издательский центр ЮГУ, 2018. – 132 с.

ПРИЛОЖЕНИЕ А

(обязательное)

Диаграммы IDEF0 для модели AS-IS

Рисунок А.1. - Диаграмма IDEF0

Рисунок А.2. - Диаграмма декомпозиции IDEF0

ПРИЛОЖЕНИЕ Б

(обязательное)

Диаграммы DFD для модели AS-IS

Рисунок Б.1. - Диаграмма DFD

Рисунок Б.2. - Диаграмма декомпозиции DFD

ПРИЛОЖЕНИЕ В

(обязательное)

Функциональная диаграмма «TO-BE» модели по методологии IDEF3

Рисунок В.1. - Диаграмма IDEF3

Рисунок В.2. - Диаграмма декомпозиции

ПРИЛОЖЕНИЕ Г

(обязательное)

Техническое задание

“УТВЕРЖДАЮ”

__________________________

“___”_____июня______2020 г.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

на разработку программного обеспечения.

1. ВВЕДЕНИЕ

1.1. Наименование продукта: «Web-сайт киноцентра»

1.2. Краткая характеристика области применения:

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

2. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

2.1. Документ, на основании которого ведется разработка: Проектирование АСОИУ, методология SADT (метод IDEF0, метод, метод IDEF3, нотация в терминах DFD, язык моделирования UML), ГОСТ 34.602–89.

2.2. Организация, утвердившая документ:

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Югорский государственный университет.

3. НАЗНАЧЕНИЕ РАЗРАБОТКИ

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

4. ТРЕБОВАНИЯ К ИС

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

Бизнес - требования:

  • Сокращение сроков обработки информации;
  • Автоматизация поиска и переработки информации;

Функциональные требования:

Система должна формировать отчеты различных видов за любой период работы;

Система хранит данные, связанные с этапами работы по переработки информации;

Система генерирует отчеты, на основе входящих данных;

Требования надежности ИС.

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

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

Требования к режимам функционирования ИС.

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

Длительность и периодичность регламентных остановок ИС регулируется Заказчиком на основании внутренних регламентов Заказчика.

Требования к численности и квалификации пользователей.

Количество пользователей web-сайта не ограничено требованиями к ИС.

Требования квалификации пользователей по работе с ИС:

Умение работать в интернете посредством браузера.

Требования к защите информации от несанкционированного доступа.

Несанкционированный доступ к данным ИС должен быть ограничен следующими средствами:

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

Требование к техническому обеспечению.

Для работы с web-сайтом на компьютере пользователя должен быть установлен web-браузер с поддержкой javascript.

5. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ

Документация предоставляется Исполнителем Заказчику в электронном виде. Предоставляемая Заказчику документация должна быть на русском языке.

6. ПОРЯДОК ВНЕСЕНИЯ ИЗМЕНЕНИЙ

Настоящее Техническое задание может дополняться и изменяться в процессе разработки и внедрения ИС в установленном порядке по взаимному соглашению Заказчика и Разработчика ИС.

ПРИЛОЖЕНИЕ Д

(обязательное)

Общая диаграмма вариантов использования

Рисунок Д.1. - диаграмма вариантов использования UML

ПРИЛОЖЕНИЕ Е

(обязательное)

Диаграммы последовательностей

Рисунок Е.1. – диаграмма последовательностей для варианта использования «Авторизация»

ПРИЛОЖЕНИЕ Ж

(обязательное)

Диаграммы состояний UML

Рисунок Ж.1. – диаграмма состояний для варианта использования

ПРИЛОЖЕНИЕ З

(обязательное)

Диаграмма деятельности UML

Рисунок З.1. - диаграмма деятельности UML

ПРИЛОЖЕНИЕ И

(обязательное)

Диаграмма классов UML

Рисунок И.1. - ER-диаграмма

ПРИЛОЖЕНИЕ К

(справочное)

Диаграмма компонентов UML

Рисунок К.1. - Диаграмма компонентов

ПРИЛОЖЕНИЕ Л

(обязательное)

Руководство пользователя

Назначение информационной системы

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

Требования к программно-технической платформе

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

Запуск информационной системы

Для открытия web-сайта необходимо набрать его адрес в новом окне (или вкладке) браузера .

Выполняемые функции и задачи

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

  • Отображение актуальной информации о показываемых фильмах, датах и времени сеансов и наличии свободных мест на выбранный сеанс;
  • Возможность покупки билетов на свободные места для зарегистрированных пользователей;
  • Регистрация пользователей;
  • Управление контентом для администратора сайтом (данными показываемых фильмов).

Управление данными фильмов

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