32
В результате обзора различных информационных ресурсов были
определены содержание сайта, его примерная структура, языки
программирования и СУБД как средства реализации проекта, намечен план
дальнейшей работы.
1.4.3. Обоснование проектных решений по техническому
обеспечению
Все данные приложения должны храниться в структурированном виде
под управлением реляционной СУБД. Исключения составляют файлы
данных, предназначенные для просмотра и печати (документы, планы,
отчеты). Такие файлы сохраняются в файловой системе, а в БД размещаются
ссылки на них.
Для реализации статических страниц и шаблонов должны
использоваться языки HTML5 и CSS3. Исходный код должен
разрабатываться в соответствии со стандартами W3C и пройти валидацию на
сайте https://validator.w3.org/.
Для реализации интерактивных элементов клиентской части должен
использоваться язык JavaScript.
Для реализации динамических страниц должен использоваться язык
PHP.
Все ссылки на сайте должны быть относительными (за исключением
внешних). Все рисунки и фото объемом более 1 kb (кроме элементов дизайна
страницы) должны быть выполнены с замещающим текстом. Все рисунки
должны быть в формате png или jpg.
Объем одной стандартной загружаемой страницы приложения в
среднем не должен превышать 300 kb.
Для функционирования приложения необходимо следующее
программное обеспечение:
Веб-сервер – Apache версии не ниже 2.0;
СУБД – MySQL версии не ниже 5.5;
33
Библиотека PHP: Smarty;
Возможность доступа к localhost по FTP протоколу;
Настроенный модуль PHPMyAdmin для административного
доступа к базе данных.
Сайт должен быть доступен для полнофункционального просмотра с
помощью следующих браузеров:
• MS IE 9.0 и выше;
• Opera 9 и выше;
• Mozilla Firefox 1.0 и выше.
ИТОГИ ПЕРВОЙ ГЛАВЫ
Таким образом, в ходе работы над теоретической частью были изучены
теоретические вопросы организации курьерской доставки предприятия «Two
sticks» Проанализированы бизнес-процессы предприятия, функции и задачи
работы менеджера по работе с клиентами. Была обоснована необходимость
автоматизации бизнес-процессов, касающихся его работы.
Также были изучены все плюсы и возможности существующей
информационной системы, проанализированы технические подходы для
наиболее качественного построения веб приложения, намечены пути
дальнейшей работы и реализации практической части проекта.
34
ГЛАВА 2. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СИСТЕМЫ
КУРЬЕРСКОЙ ДОСТАВКИ ПРЕДПРИЯТИЯ «TWO STICKS»
2.1. Разработка проекта автоматизации
Проведем анализ возможных рисков на этапах жизненного цикла
информационной системы. Данные представлены в таблице.
Тип (категория
риска)
Риск
Последствия
Меры по
предотвращению
Меры по
минимизации
последствий
Вероятн. риска [P]
Степень ущерба [L]
1
2
3
4
5
6
7
Проектны
й,
организац
ионный
Сбой в работе
программы из-
за
недоступности
базы данных
Приостановка
исполнения
заявок и
контроля за их
исполнением,
невозможность
создания новой
заявки
Установить
правильно
сервер БД,
вовремя
запускать
его.
Предупредить
аварийное
завершение
работы
программно.
Назначить
ответственног
о.
3
4
Коммерчес
кий,
организац
ионный
Утечка
информации в
результате
проникновения
внесанкционир
ованных
пользователей
Нарушение
корректности
работы системы
либо другие
непредсказуемы
е последствия
Установка
паролей.
Контроль за
конфиденци
альностью
личных
данных.
Регулярная
смена паролей.
Программная
защита от SQL
инъекций и тп.
2
8
Проектын
й,
технологи
ческий
Возникновение
ошибок и сбоев
в результате
некорректных
действий
пользователей
Зависание
системы,
сохранение в
базе данных
противоречивых
и некорректных
данных
Программно
е
предупрежд
ение
возникновен
ия ошибок.
Комментарии,
подсказки,
понятный,
простой
интерфейс,
предупреждаю
щие
сообщения и
запрет
дальнейшей
работы при
некорректност
и действий
4
4
35
Техническ
ий,
инструмен
тальный
Сбои в работе
аппаратного
обеспечения
Приостановка
исполнения
заявок и
контроля за их
исполнением,
невозможность
создания новой
заявки
Использоват
ь в качестве
сервера
надежную
машину.
Вовремя
исправлять
неполадки.
Иметь
резервные
копии данных.
5
5
Здесь вероятность риска и степень ущерба оценивается по 10 бальной
системе.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Основные этапы работы с клиентами по оформлению заказа можно
изобразить в виде схемы, представленной на рисунке 3.
Рисунок 1. Основные этапы работы с клиентами
Более детально бизнес-процесс формирования и обработки заказа
может быть изображен в виде схемы (рисунок 4).
36
Рисунок 2. Процесс обработки заказа
Из данных схем видна вся работа по взаимодействию с клиентами
менеджера компании от формирования заказа до отслеживания его доставки.
Промежуточными этапами являются обработка заказов, работа со счетами,
контроль оплаты, контроль и отслеживание статуса доставки товара,
формирование необходимой документации.
Главной задачей разрабатываемого приложения является обеспечение
поддержки клиентов и оформление заказов. Поэтому рассматриваем бизнес-
процесс Оформление заказов. Входными процессами могут быть звонки
клиентов на заказ, заказы он-лайн либо заказ товара очно непосредственно в
компании (рисунок 5).
Рисунок 3. Оформление заказа
37
Очевидно, что управление процессом оформления заказов
осуществляется с помощью правил и процедур оформления, необходимо
держать во внимании также стандарты на продукцию. Механизмом для
оформления заказов служит система оформления заказов. На выходе мы
должны получить бизнес процесс сформированный заказ клиента.
Рассмотрим детальнее процесс оформления заказа, произведя его
декомпозицию. После того как клиент принял решение сделать заказ,
менеджер организует все процессы по его приянтию и оформлению
соответствующих документов: регистрирует клиента, если тот еще не
зарегистрирован, в базе данных, вносит в базу данных все необходимые
параметры заказа, формирует и передает клиенту накладную, сверяет заказ и
его электронную версию, назначает курьера, обрабатывает заказ, получает
предоплату или оплату, внося сумму в базу данных, формирует заказ,
сохраняя его в базе данных, выводит на печать договор, обговаривает детали
доставки (рисунок 6).
Рисунок 4. Детализация процесса оформления заказа
В дальнейшем менеджер контролирует доставку, исполнение заказа,
своевременность оплаты, отмечает статус заказа, ведет мониторинговую
38
работу по заказам, анализируя спрос, анализирует целевую аудиторию
клиентов с целью планирования дальнейшей работы по привлечению
заказчиков, запросов и др.
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
Алгоритм работы приложения может быть представлен в виде блок
схемы. На начальном этапе проверяем, имеется ли в наличие данный товар.
Если нет, отклоняем заказ. Если товар в наличие имеется, согласовываем
условия доставки и способ оплаты. На данном этапе заказ находится в
статусе Оформения. Затем оформляется договор, товар доставляется, а заказ
переходит в статус Доставка. После доставки выставляем статус заказа
Доставлен, затем закрываем заказ, указав его статус Закрыт (рисунок 7).
39
Рисунок 1. Блок схема оформления заказа
2.3.2. Характеристика базы данных
Составим физическую и на ее основе логическую модели базы данных
– структуру таблиц и связей между ними.
Рассмотрим связанные между собой сущности в модели «сущность-
связь» (рисунок 8).
40
Рисунок 1. Модель «сущность-связь»
Виды товаров содержат типы товаров. Например, вид товара «горячие
блюда» содержит типы товара «горячие закуски», «супы», «ланчи» и др.
Типы товара содержат наименования товара. Например, тип товара «суши»
содержит «суши мидии», «суши угорь», «суши морской гребешок» и др.
Менеджеры оформляют заказы на продажу и доставку товара. Товар
поставляют курьеры. Клиенты оформляют заказы совместно с
менеджерами.
На основе модели «сущность-связь» построим логическую модель
базы данных (рисунок 9).
Рисунок 2. Логическая модель базы данных
41
Один вид товара содержит много типов, но один тип может
относиться только к одному виду товара. Данные сущности находятся в
отношении один ко многим. Один тип товара содержит много его
наименований, но один товар может относиться только к одному типу.
Менеджеры оформляют заказы с клиентами по покупке и доставке
товара. Один менеджер может оформить заказ по покупке нескольких
товаров и один товар может быть оформлен в нескольких заказах. Точно
также один клиент может заказать несколько товаров и один товар может
быть заказан несколькими клиентами. Аналогично курьер может поставить
несколько товаров и один товар могут поставлять несколько курьеров. Все
перечисленные сущности связаны отношениями много ко многим. Поэтому
здесь нужны связующие таблицы. Создадим одну связующую таблицу
ЗАКАЗЫ как для таблиц КЛИЕНТЫ, КУРЬЕРЫ, МЕНЕДЖЕРЫ и
ОБОРУДОВАНИЕ. Таким образом, родительская таблица КЛИЕНТЫ и
дочерняя таблица ЗАКАЗЫ отношением один-ко-многим. Один клиент
может сделать несколько заказов, но один заказ принадлежит только
одному клиенту. Точно также относятся таблицы КУРЬЕРЫ и ЗАКАЗЫ,
МЕНЕДЖЕРЫ и ЗАКАЗЫ и ТОВАРЫ и ЗАКАЗЫ. Первичный ключ
родительской таблицы номер_клиента будет связан с вторичным (или
внешним) ключом дочерней таблицы.
С учетом вышесказанного добавим связующие таблицы, распределим
атрибуты соответствующим образом и построим физическую модель
данных. Физическая модель базы данных представлена на рисунке 10.