Автор работы: Пользователь скрыл имя, 02 Июля 2013 в 13:51, реферат
Цель: cокращение времени на сбор и обработку информации по заявкам.
Задачи:
Изучение организационной структуры ДК «Нефтяник»;
Ознакомление с должностными обязанностями сотрудников;
Изучение программного обеспечения;
Выявление трудностей в работе.
Введение 3
Глава 1. Описание предметной области 5
1.1. Общая характеристика ДК «Нефтяник» 5
1.2. Краткая характеристика работы менеджера 5
1.3. Описание существующего бизнес - процесса работы менеджера по работе с клиентами 6
1.4. Обоснование необходимости автоматизации 7
Глава 2. Постановка задачи 8
2.1. Выбор объектов автоматизации 8
2.2. Требования к разрабатываемому проекту 8
2.3. Диаграмма потоков данных (DFD) 9
Глава 3. Проектирование информационного обеспечения 12
3.1. Модель «сущность-связь» (ERD) 12
3.2. Логическая модель данных IDEF1X 15
3.3. Физическая модель данных 17
Глава 4. Проектирование программных средств 18
4.1. Выбор средств разработки 18
4.2. Руководство пользователя 18
Заключение 22
Список литературы 23
Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. На DFD диаграммах потоки данных изображаются линиями со стрелками, показывающими их направление. Каждому потоку данных присваивается имя, отражающее его содержание.
Диаграммы
На рисунке 3.1 представлена контекстная диаграмма процесса «Учет заявок». Изображены внешние сущности: «Клиент», «Директор» и потоки данных, которыми они обмениваются с основным процессом.
Рисунок 3.1 - Контекстная диаграмма
На рисунке 3.2 изображена декомпозиция контекстной диаграммы. На диаграмме представлены хранилища данных: «Заявки», «Клиенты», а так же основные подпроцессы: «Добавление клиента», «Формирование заявки», «Согласование заявки», «Формирование отчетов».
Примеры отчетов, полученных на выходе системы, показаны в ПРИЛОЖЕНИИ 2.
Рисунок 3.2 – Декомпозиция контекстной диаграммы
Модель «сущность-связь» – концептуальная модель, представляющая собой описание основных сущностей (таблиц) и связей между ними. Она определяет значения данных в контексте их взаимосвязи с другими данными. С помощью ER-диаграммы осуществляется детализация хранилищ данных проектируемой системы.
Основные понятия – сущность, атрибут, связь. Сущность – это субъект, место, вещь, событие или понятие, содержащее информацию. Каждый экземпляр сущности обладает набором характеристик, которые называются атрибутами. Логические взаимосвязи представляют собой связи между сущностями. Они определяются глаголами, показывающими, как одна сущность относится к другой.
ER-диаграммы выполнены в нотации Чена. Множества сущностей изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов. Атрибуты изображаются в виде овалов и связываются линией с одним отношением или с одной сущностью.
Диаграммы
На рисунке 3.3 представлена глобальная ER-диаграмма, на которой отображены все хранилища данных, и показаны связи между ними.
Рисунок 3.3 – Глобальная ER-диаграмма
В таблице 3.1 описаны все сущности, выделенные в предметной области.
Таблица 3.1. Описание сущностей
Имя типа сущности |
Краткое описание |
Разновидность |
Клиент |
Определяет клиента |
Сильный |
Заявка |
Определяет заявку на проведение мероприятия |
Сильный |
Тип пользователя |
Определяет тип пользователя |
Сильный |
Тип мероприятия |
Определяет тип мероприятия |
Сильный |
Позиция шоу |
Определяет основные позиции шоу |
Слабый |
Статус заявки |
Определяет статус заявки |
Сильный |
Таблица 3.2 содержит информацию о связях между сущностями.
Таблица 3.2. Описание типов связей
Имя типа связи |
Краткое описание |
Степень связи |
Список типов сущностей, участвующих в связи | |
Содержит |
Связывает Клиента с Заявкой |
бинарная |
Клиент |
1 |
Заявка |
М | |||
Содержит |
Связывает Заявку с Типом мероприятия |
бинарная |
Заявка |
М |
Тип мероприятия |
1 | |||
Содержит |
Связывает Заявку со Статусом заявки |
бинарная |
Заявка |
М |
Статус заявки |
1 | |||
Содержит |
Связывает Заявку с Позицией шоу |
бинарная |
Заявка |
М |
Позиция шоу |
N | |||
Содержит |
Связывает Клиента с Типом пользователя |
бинарная |
Клиент |
М |
Тип пользователя |
1 |
В таблицах 3.2-3.7 описаны атрибуты сущностей.
Таблица 3.2. Сущность «Клиент»
Имя атрибута |
Домен |
Тип по составу |
Тип по значению |
Описание |
ФИО |
Текстовый |
простой |
однозначный |
ФИО лица с кем ведется диалог по поводу заявки |
Телефон |
Числовой |
простой |
однозначный |
Контактный телефон |
Электронная почта |
Текстовый |
простой |
однозначный |
Адрес электронной почты |
Город |
Текстовый |
простой |
однозначный |
Город,
где будет проводиться |
Таблица 3.3. Сущность «Заявка»
Имя атрибута |
Домен |
Тип по составу |
Тип по значению |
Описание |
Дата проведения |
Дата |
простой |
однозначный |
Планируемая дата проведения |
Время проведения |
Время |
простой |
однозначный |
Планируемое время |
Бюджет |
Числовой |
простой |
однозначный |
Планируемый бюджет |
Кол-во гостей |
Числовой |
простой |
однозначный |
Планируемое кол-во гостей |
Ср. возраст гостей |
Числовой |
простой |
однозначный |
Ср. возраст гостей |
Место проведения |
Текстовый |
простой |
однозначный |
Место проведения |
Пожелания |
Текстовый |
простой |
однозначный |
Пожелания |
Комментарий |
Текстовый |
простой |
однозначный |
Комментарий |
Время для встречи |
Текстовый |
простой |
однозначный |
Удобное время для встречи |
Таблица 3.4. Сущность «Тип пользователя»
Имя атрибута |
Домен |
Тип по составу |
Тип по значению |
Описание |
Название типа пользователя |
Текстовой |
простой |
однозначный |
Описание типа пользователя |
Таблица 3.5. Сущность «Тип мероприятия»
Имя атрибута |
Домен |
Тип по составу |
Тип по значению |
Описание |
Название мероприятия |
Текстовой |
простой |
однозначный |
Название мероприятия |
Таблица 3.6. Сущность «Позиция шоу»
Имя атрибута |
Домен |
Тип по составу |
Тип по значению |
Описание |
Название шоу |
Текстовой |
простой |
однозначный |
Название позиции шоу |
Таблица 3.7. Сущность «Статус заявки»
Имя атрибута |
Домен |
Тип по составу |
Тип по значению |
Описание |
Название статуса |
Текстовой |
простой |
однозначный |
Название статуса заявки |
Диаграмма выполнена в методологии IDEF1X. Методология основана на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме.
В данной методологии все сущности делятся на зависимые и независимые. Сущность независимая, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность зависимая, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности. Независимая сущность изображается в виде обычного прямоугольника, зависимая - в виде прямоугольника с закругленными углами.
Диаграмма
На рисунке 3.4 изображена модель данных в методологии IDEF1X, описывающая схему реляционной базы данных системы.
Рисунок 3.4 – Модель IDEF1X
Физическая модель данных определяет способ размещения данных в среде хранения и способы доступа к этим данным, которые поддерживаются на физическом уровне. Физическая модель содержит всю информацию, необходимую для реализации конкретной БД.
Диаграмма
На рисунке 3.5 изображена физическая модель данных.
Рисунок 3.5 – Физическая модель данных
Выбор системы управления базой данных (СУБД) представляет собой сложную задачу и является одним из важных этапов при разработке приложений баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, разработку программного обеспечения на ее основе, а так же обучения персонала.
Для разработки сайта используется приложение Denwer (PHP 5.3.3, MySQL 5.0.45)
Denwer - набор дистрибутивов
и программная оболочка, используемые
Web-разработчиками для
В качестве СУБД выбрана MySQL. MySQL - реляционная СУБД, которая характеризуется большой скоростью, устойчивостью и легкостью в использовании, является идеальным решением для малых и средних приложений. В качестве языка программирования выбран PHP. PHP – это скрипт-язык, который интерпретируется и выполняется на сервере. PHP является одним из наиболее популярных языков программирования, он также является одним из самых простых в освоении. PHP позволят ускорить процесс разработки приложений благодаря простой интеграции удаленных инструментов.
Рисунок 4.1 – Форма заполнения онлайн заявки
Рисунок 4.2 – Форма заполнения онлайн заявки (продолжение)
Рисунок 4.3 – Форма заполнения онлайн заявки (продолжение)
После того, как пользователь нажимает кнопку «Отправить заявку менеджеру», открывается новая страница, где будет указан номер заявки, по которому в дальнейшем можно отслеживать статус заявки.
Рисунок 4.4 – Форма с номером заявки
Далее можно нажать кнопку «Просмотреть», чтобы пользователь мог увидеть, какую заявку в итоге он отправил.
Рисунок 4.5 – Информация о заявке
Менеджер в свою очередь
может просматривать все
Рисунок 4.6 – Форма для отслеживания заявок менеджером
В ходе производственной практики я ознакомилась с деятельностью ГАУК ТО ДК «Нефтяник», усовершенствовала навыки работы с офисными приложениями и получила практику работы в коллективе и с начальством.
Во время работы у меня не возникло никаких сложностей с освоением программного обеспечения предприятия или с выполнением своих обязанностей.