1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному обеспечению
Для нормального функционирования разрабатываемой информационной системы не требуется никаких входных документов. На выходе, заказчик, будет иметь только один документ в формате PDF – маршрут-квитанцию, которую пассажиру рекомендовано распечатать и взять с собой в аэропорт, для предоставления сотрудникам аэропорта, при возникновении каких-либо вопросов. Но это совершенно не обязательно делать, поскольку на данный момент все билеты являются электронными, а как известно электронный билет – это запись в базе данных авиакомпании информации о направлении и времени перелёта, данных пассажира, включая его паспортные данные и при желании службами аэропорта можно в два счёта уточнить информацию о наличии конкретного пассажира на конкретном рейсе.
В маршрутной квитанции должна содержаться следующая информация:
- Полетная информация (направление перелёта, дата и время вылета/прилёта, бесплатная норма провоза багажа)
- Персональная информация (ФИО пассажира, его паспортные данные)
- Отпечаток пункта продажи (кодификатор места, где был выпущен электронный билет)
- Тарифная информация
- Дополнительная информация (важные оповещения и некоторые выдержки из правил авиакомпании)
Что касается экранных форм, то выполнены они должны быть в стиле технологии Bootstrap. Главная форма поиска авиабилета должна содержать в себе пять элементов:
- Выбор направления вылета
- Выбор направления прилёта
- Дату рейса
- Дату обратного рейса (если необходимо и перевозка будет выполняться туда и обратно)
- Количество и типы пассажиров
Прототип формы поиска можно просмотреть на рисунке 9.
Рисунок 9. Прототип формы поиска авиабилетов.
Далее после выбора подходящего тарифа, пассажиру должно быть предложено заполнение данных пассажиров, которые состоят из следующих элементов:
- ФИО
- Дата рождения
- Гражданство
- Тип документа
- Номер документа
- Пол
Дополнительно должно быть предложено заполнить информацию и о заказчике, состоящую из двух полей – email заказчика и его телефон.
Пример прототипа данной формы можно просмотреть на рисунке 10.
Рисунок 10. Форма ввода информации о пассажире и заказчике.
Соответственно после успешной транзакции, формируется маршрут-квитанция, которая отправляется на почту заказчику, а также выводится ссылка для её непосредственного скачивания.
Стоит обратить внимание, что в разрабатываемой системе будет реализован международный авиационный классификатор городов, стран и гражданства согласно международной классификации IATA.
Локальный классификатор будет только один – у статуса заказа. Таким образом в базе данных будет содержаться цифирное значение статуса заказа:
- Забронирован
- Отменен
- Продан
- Произведён возврат
- Произведён частичный возврат
Разрабатываемая информационная система будет иметь интегрированную базу данных MySQL, которая является одной из самых распространённых Систем Управления Базами Данных (СУБД), поскольку в задачах, которые необходимо решить – присутствует также и скорость загрузки, а реализация информационной системы через хранение данных в файлах, нам, к сожалению, не может дать такой скорости загрузки как СУБД MySQL.
База данных будет состоять из следующих важных таблиц:
- Города (классификатор городов IATA)
- Расписание вылетов
- Национальности
- Заказы
- Пассажиры
- Пользователи
- Системы оплаты
- Метапоисковики
- Записки (важная информация для пассажиров)
- Файлы пользователей (стандартная таблица OctoberCMS)
Генерируемые маршрут-квитанции будут лежать физически в отдельной папке storage, но имя файла и путь к нему будет записано в таблице «Файлы пользователей». Таким образом мы сохраним быстроту и удобство работы с базой данных не раздув её, до критических размеров.
1.4.2. Обоснование проектных решений по программному обеспечению
По программной архитектуре, отображённой на рисунке 4, абсолютно отсутствуют какие-либо рекомендации, поскольку программное обеспечение на рабочих станциях стоит современное. Практически везде установлена операционная система Windows 10. Современная, качественная, быстрая и защищённая. Единственный отдел, в котором установлен WindowsXP – это отдел материально технического снабжения (ОМТС), но установка более современной операционной системы на то техническое оборудование, которое имеется в ОМТС не представляется возможным из-за низких технических характеристик.
Интересен тот факт, что каким-то образом специалисты нашли способ установить на iMac руководства операционную систему Windows 10. Данный факт несколько удивил, при проведении анализа программной архитектуры предприятия.
Что касается серверов предприятия, то и тут установлены современные операционные системы. Все важные обновления устанавливаются в срок. Помимо того, что на главном маршрутизаторе Kerio Control используется встроенный антивирус, также и на рабочих станциях используют антивирус Касперского для малого офиса, что является отличным средством защиты на сегодняшний день.
Для реализации разрабатываемой информационной системы
дополнительного программного обеспечения не потребуется. Информационная система будет разработана на языке PHP, который уже сейчас используются на сервере, который в свою очередь, обеспечивает работоспособность сайта авиакомпании. Для рабочих станций, также дополнительно не потребуется устанавливать ничего. Разрабатываемая информационная система будет успешно работать с любого современного браузера.
Разработка будет проводиться в Интегрированной среде разработки (Integrated Development Environment IDE) PhpStorm. Для разработки будет использоваться локальный сервер Open Server. Для доступа к базе данных, будет использовано такое средство, как HeidiSQL. Ну и отслеживаться вся разработка будет обязательно в GIT, при этом будет использована программа SourceTree.
Поскольку текущий сайт авиакомпании работает на системе управления контентом OctoberCMS, которая в свою очередь имеет «под капотом» знаменитый PHP Фреймворк Laravel, то соответственно и разработка новой информационной системы будет проходить в рамках этой системы управления сайтом в виде отдельного подключающегося плагина.
1.4.3. Обоснование проектных решений по техническому обеспечению
По технической архитектуре имеются следующие рекомендации.
Во-первых, серверная комната, не соответствует требованиям безопасности, не установлены сигнализаторы пожара, и нет оборудования, которое смогло бы остановить пожар, залив его пеной. А ведь на сервере хранятся жизненно важные данные авиакомпании.
Во-вторых, на рисунке 3 мы видим фотографию серверных стоек. Они сделаны собственноручно. Скорее всего, все это делалось для того, чтобы удешевить конечную стоимость серверной комнаты, но в таких стойках нет никакой защиты от пыли, которая со временем будет накапливаться не только на серверном оборудовании, но также и внутри него, что может иметь довольно негативные последствия, а возможно и приведёт к полной замене серверов.
Рекомендуется привести серверную комнату в порядок. Установить противопожарную систему, и оснастить сервер специализированным серверным шкафом со специальным охлаждением.
Также рекомендовал бы заменить рабочую стацию в ОМТС, на более современную, поскольку из за нехватки мощностей на данной рабочей станции возможна лишь установка устаревшей операционной системы Windows XP,
которая на данный момент имеет серьёзные бреши в безопасности, и может стать уязвимой для злоумышленников, которые в свою очередь могут нанести вред всей локальной сети авиакомпании.
Что касается виртуального персонального сервера (Virtual Personal Server VPS) авиакомпании, поскольку сайт авиакомпании стоящий на данном сервере теперь будет выполнять роль не просто визитной карточки, а иметь в себе информационную систему, то для него рекомендовано перейти на более дорогой тариф, для увеличения CPU с одного до четырех ядер и оперативной памяти с 512МБ до 4GB. Такая конфигурация гарантированно выдержит посещения сайтом двух тысяч человек в день.
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Для разработки информационной системы был выбран стандарт быстрой разработки приложений RAD (Rapid Application Development). Это концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные приложения.
Практическое определение RAD — это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества программного обеспечения, чем это возможно при традиционном подходе к проектированию. RAD реализует спиральную модель жизненного цикла. Концепцию RAD также часто связывают с концепцией визуального программирования.
Жизненный цикл программного обеспечения по методологии RAD состоит из четырех этапов:
- Анализ и планирование требований
- Проектирование
- Построение
- Внедрение
На этапе анализа и планирования требований были определены наиболее важные функции, которыми должна обладать информационная система и которые должны были быть разработаны в первую очередь. Ограничивался масштаб проекта, определялись временные рамки для каждого из последующих этапов.
На этапе проектирования создавалось техническое проектирование системы, уточнялись и дополнялись требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматривались процессы системы. Каждый из процессов рассматривался детально и создавался частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определялись требования разграничения доступа к данным.
На этой же фазе происходило определение набора необходимой документации.
В результате данного этапа появились:
- Общая информационная модель системы
- Функциональные модели системы в целом
- Точно определённые с помощью CASE средства интерфейсы
- Построенные прототипы экранов, отчетов и диалогов
На этапе построения была выполнена непосредственно сама быстрая разработка плагина под OctoberCMS. После окончания работ была произведена постепенная интеграция данной части системы с основным сайтом, был сформирован полный программный код, а также было выполнено тестирование данной части приложения, а затем тестирование системы в целом. В завершении физического проектирования системы:
- Определялась необходимость распределения данных
- Производился анализ использования данных
- Производилось физическое проектирование базы данных
- Определялись требования к аппаратным ресурсам
- Определялись способы увеличения производительности
- Завершалась разработка документации проекта
В результате этапа построения появилась готовая система, удовлетворяющая всем согласованным требованиям.
На этапе внедрения производилось обучение пользователей технической поддержки и параллельно с внедрением новой системы осуществлялась работа с существующей системой Oxygen, до полного внедрения новой. Была выбрана параллельная стратегия внедрения. Конечно же нагрузка на время этапа внедрения возросла на пользователей технической поддержки, но и несомненно можно выделить плюс параллельной стратегии, что если в системе была обнаружена ошибка, то пользователи технической поддержки просто перенаправляли пассажиров на старую систему Oxygen. Следует также отметить, что в очередной виток спирального подхода, когда система полностью удовлетворяла требованиям и не вызывала ошибок, был использована так называемая система внедрения «скачок» и новая система полностью заменила старую систему Oxygen.
Таким образом, бесспорно, можно отметить следующие преимущества стандарта RAD:
- Быстрота продвижения программного продукта на рынок
- Интерфейс, устраивающий пользователя
- Легкая адаптируемость проекта к изменяющимся требованиям
- Простата развития функциональности системы
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Риск – это всегда неопределённость. Чем больше размер проекта, тем выше степень его неопределённости. К счастью выбранный мною проект реализации информационной системы не такой уж большой, а соответственно и риски можно классифицировать следующим образом:
- Технические риски. Разработка любого ИТ-проекта осуществляется с помощью специфического оборудования. В нашем случае это виртуальный персональный сервер, отказ которого мы можем получить в любой момент, либо его поломку, что может оказать влияние на сроки реализации проекта, частично приостановить работу над проектом, до его восстановления. Рекомендовано иметь резервную копию сервера, которую всегда можно восстановить в краткие сроки.
- Риски оценки сроков. Для большинства веб-проектов характерны ошибки в определение сроков необходимых для реализации проекта. Часто это связано с недостаточностью проработки плана проекта, что приводит к появлению забытых работ и смещению сроков. Данный риск мы успешно ликвидируем выбором спиральной модели в разработке и с каждым новым витком увеличиваем функционал.
- Риски непринятия продукта пользователем. Любой новый сервис – это, в первую очередь, изменение технологии работы. Эти изменения могут быть не приняты пользователями веб-продукта. Пользователь интернета не захочет читать справки сервиса, а поэтому пользовательский интерфейс не должен нести в себе перегруженности и обязательно должен быть интуитивно понятным. Стоит также всегда прислушиваться к мнению пользователей о сервисе, и пользоваться современными инструментами отслеживания поведений пользователя при работе с ИТ-продуктом.
- Технологические риски. Каждый год в сфере интернета происходят революционные изменения, появляются кардинально новые разработки, меняющие вектор развития. Всегда необходимо оценивать успешность технологий на рынке, ее актуальность на протяжении жизненного цикла проекта, доступность аппаратного и программного обеспечения, его качество и частоту модернизации.
- Риски несоблюдения технологии. Использование для реализации проекта новых, не опробованных технологий, может привести к затруднениям в реализации проекта. Версионность всего программного обеспечения, а также переход на новые версии, всегда должна учитываться, иначе разработанные функции на более старых версиях, могут совершенно неправильно работать, либо вообще вызвать ошибку, которая не позволит дальнейшее использование системы.
- Коммерческие риски. Это риски, обусловленные
неблагоприятными изменениями в экономике предприятия или экономике страны.
- Недостаток трудовых ресурсов. Разработчики, которые создают продукт – это основной ресурс ИТ-проекта и один из основных рисков. Ограниченность этого ресурса приводит к срывам сроков реализации проекта. Также опрометчиво думать что участники проекта будут все своё время тратить на работу над проектом. Для этого есть ряд объективных причин. К списку наиболее распространённых причин этого относятся: сопровождение действующих систем, обучение и повышение квалификации, праздники, больничные, отпуска. Рекомендуется считать, что реальное время потраченное на проект, будет в районе 60-80% от всего рабочего времени.
- Риски разработки. Зависят от квалифицированной подготовки программистов, знания ими продуктов, а также от выбранной стратегии и тактики разработки. Типичными ошибками могут быть: отсутствие, либо реально не работающая система контроля версий, не использование инструментов отладки кода, не регулируемые права доступа на тестовые, боевые или девелоперские серверы, работа всех сотрудников от root пользователя, отсутствие комментариев в коде.
2.1.3. Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации
Как уже было выше не раз подмечено, безопасности в компании ООО «Бек Эйр» уделяют довольно значимое значение. Анализ показал, что все сервера строго доступны по определённым протоколам для пользователей. Для доступа же к администрированию используются разрешения на определённые IP адреса полномочных администраторов. Стоит отметить, что весь комплекс модулей системы Kerio Control является очень мощным ИТ элементом с точки зрения безопасности.
Что немаловажно, решением руководства, сайт авиакомпании вынесен в отдельный виртуальный персональный сервер, поскольку именно с сайтом работает множество пользователей, и сервер доступен для сети интернет из вне. Таким образом если вдруг случится взлом, то злоумышленники не получат доступ во всю внутреннюю ИТ инфраструктуру компании, а соответственно и доступ к более важным данным авиакомпании.
Безопасность является очень важным аспектом и при разработке вебприложений. Очень важно обеспечить защиту данных пользователей. Именно поэтому компанией была выбрана система управления контентом OctoberCMS, поскольку в ней реализованы все базовые политики безопасности такого мощного PHP фреймворка, как Laravel. Все эти функции предоставляют собой различные механизмы для защиты веб-сайта. Давайте рассмотрим некоторые из них.
Хранение паролей — Laravel предоставляет класс с именем «Hash», который обеспечивает безопасное кэширование Bcrypt. Пароль может быть закэширован следующим образом:
$password = Hash::make(‘secret’);
Функция make() принимает значение в качестве аргумента и возвращает хешированное значение. Хешированное значение можно проверить с помощью функции check() следующим образом.
Hash::check(‘secret’, $hashedPassword)
Вышеуказанная функция возвращает логическое значение. Если пароль совпадает, возвращается true, в противном случае — false.
Аутентификация пользователей. Еще одна основная функция безопасности в Laravel — аутентификация пользователя и выполнение определенных действий. Laravel позволяет выполнить эту задачу значительно проще, для этого мы можем использовать метод Auth::attempt следующим образом.
if (Auth::attempt(array(’email’ => $email, ‘password’ => $password))) { return Redirect::intended(‘home’);
}
Метод Auth::attempt принимает в качестве аргумента учетные данные и сравнивает их с учетными данными хранящимися в базе данных. Если данные совпадают, возвращается true, в противном случае — false.
Защита от CSRF (межсайтовой подделки запроса)/XSS кросс-сайтового скриптинга — атаки с использованием кросс-сайтового скриптинга осуществляются, когда злоумышленник имеет возможность разместить код JavaScript на стороне клиента на странице, просматриваемой другими пользователями. Чтобы защититься от подобного типа атак, мы всегда должны проверять пользовательские данные и не допускать добавления опасных сигнатур. В шаблонах Blade следует использовать синтаксис двойной привязки ({{$value}}), {!!$value!!} следует применять, когда вы уверены, что данные безопасны для отображения без обработки.
Противодействие SQL-инъекциям — уязвимость к SQL-инъекциям связана с вставкой нефильтрованных произвольных данных пользователя в SQLзапрос. По умолчанию Laravel защищает нас от такого типа атак, поскольку и конструктор запросов, и Eloquent используют класс объектов данных PHP (PDO). PDO использует подготовленные операторы, которые позволяют безопасно передавать любые параметры без необходимости их удаления и санации.
Cookies — безопасны по умолчанию — Laravel позволяет просто создавать, читать и отключать файлы cookie с помощью класса Cookie. В Laravel все файлы cookie автоматически подписываются и шифруются. Это означает, что если они будут подделаны, Laravel автоматически отвергнет их. Это также означает, что вы не сможете считать их на стороне клиента с помощью JavaScript.
Ещё одним важным методом защиты является принудительное использование HTTPS. При обмене конфиденциальными данными — HTTPS блокирует перехват злоумышленниками в одной сети конфиденциальной информации, такой как переменные сеанса, и регистрацию с ее помощью от имени жертвы.
Также стоит отметить, что все формы, с которыми работает пользователь – проходят верификацию, прежде чем будет продолжена работа, и о несоответствиях в формате, либо правиле применимом к той или иной форме ввода тут же сообщается пользователю красным цветом.
При ошибке кода, пользователю будет показана стандартная страница ошибки, а администратор будет оповещён по email, с указанием более подробной программной ошибки и местом её возникновения (файл и строка кода).
От инсайдерских же угроз, разработанное программное обеспечение по автоматизации продаж защищено наличием собственного GIT репозитория в компании, к которому имеет доступ лишь разработчик, то есть я. Да, копия проекта существует и на моём ноутбуке, который я могу потерять, либо он может быть украден, но в этом случае ноутбук тоже довольно таки защищен с помощью шифрования жесткого диска, и если будет подключен в другую систему для считывания информации, то вряд ли злоумышленник сможет расшифровать всё, что находится на нём, ведь без использования USB ключа – это невозможно.
Все важные функции разработанного приложения разграничены по правам доступа, их немного и все они показаны на таблице 3.
Таблица 3
Разграничение прав доступа
| Функц ии систем ы | Групп ы польз овате лей | Посетите ль сайта
| Зарегист рирован ный посетите ль сайта | Администра тор системы | Сотрудн ик коммер ческого отдела | Сотрудни к техническ ой поддержк и |
| Купить билет | Выполнен ие | Выполнен ие | — | — | Выполнени е | |
| Оформить возврат, обмен | — | Выполнен ие | — | — | Выполнени е | |
| Обратная связь | Создание | Создание | Просмотр, редактирован ие | — | Ответы | |
| Расписание | — | — | Загрузка, редактирован ие | — | — | |
| Ключ | — | — | Отправка, регистрация | — | — | |
| Классификатор ы | — | — | Загрузка, редактирован ие | — | — | |
| Заказы | Просмотр | Просмотр | Редактирован ие | — | Просмотр | |
| Системы оплат | — | — | Редактирован ие | — | — | |
| Оповещения | Ограниче н | Ограниче н | Редактирован ие | — | — | |
| Статистика | — | — | Просмотр | Просмотр | — | |
| Метапоисковик | — | — | Редактирован ие | — | — | |
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Рассмотрим таблицы базы данных:
Справочными таблицами являются: Города, Национальности, Расписание, Платежные шлюзы, Оповещения, Мета поисковики
Оперативными таблицами будут:
- Заказы
- Обращения
- Пользователи
Согласно этому списку, схема информационной модели предоставлена на рисунке 11.
Как видно на рисунке 11, все справочные таблицы, кроме таблицы оповещений, — вынесены в отдельный столбик, поскольку к ним есть доступ только у администратора системы. Что касается таблицы оповещений, то посетители сайта просматривают и имеют возможность удалять оповещения, предназначенные для них.
Далее на схеме показано, какие оперативные таблицы используются в основных представленных формах и какие формы (посредством разграничения доступа) управляют какими таблицами. Например, у сотрудника коммерческой службы всего одна форма – по которой он запрашивает выборку каких-либо статистических данных из таблицы заказов.
Рисунок 11. Схема информационной модели.
Рисунок 11. Продолжение.
Также, прошу обратить внимание, что на выходе только для роли посетитель, формируется PDF документ – маршрутная квитанция. Этот документ не является электронным билетом, но служит, как подтверждение полёта, для большего удобства пассажира
2.2.2. Характеристика нормативно-справочной, входной и оперативной информации
Как выше упоминалось, разработанная информационная система имеет шесть справочных таблиц. Ниже подробно рассмотрим каждую из них на предмет содержания.
Города. Данная таблица отображает в себе список всех городов, которые только возможны, с учетом кодов этих городов по международному авиационную стандарту IATA. Если данная таблица пустая, то предлагается загрузить эти данные через шлюз WS-Gate используя запрос “describe”. В результате вернётся xml документ со списком всех городов (3187шт). В таблице также существует флажок “is_active” установив который, данный город будет показываться на фронте в форме поиска авиабилета. Редактирование данной таблицы происходит крайне редко.
Национальности. Данная справочная таблица содержит в себе все возможные страны, как бы это странно не звучало. Так уж исторически сложилось, что запрос в WS-Gate при бронировании авиабилета несёт в себе параметр “nationality”, хотя по факту, в нём передаётся код страны, выпустившей документ (паспорт, свидетельство о рождении и т.д.) пассажира. Заполняется вручную администратором, с обязательным указанием кода страны по стандарту IATA. Редактирование данной таблицы происходит крайне редко. В таблице существует 23 записи.
Расписание. Несёт в себе актуальное расписание полётов авиакомпании с указанием номера рейса, направления, дат вылета/прилета, а также частотой выполнения рейса. Загружается в систему также через XML шлюз WS-Gate запросом “get_schedule”. Данная таблица участвует при генерации календаря для
выбора даты перелёта, и отсекает те даты, в которые полёт по данным направлениям невозможен, улучшая при этом показатель B2L. Загружается каждую неделю администратором и содержит в себе порядка 150-200 записей.
Платежные шлюзы. Данная таблица имеет информацию о подключённых платежных шлюзах. Заводится администратором. Редактируется крайне редко, поскольку для подключения дополнительных платёжных шлюзов, необходима доработка по платежной системе и интеграция предоставляемого платёжным шлюзом API, для корректной работы на сайте. На данный момент возможно подключение всего одного платёжного шлюза – Platron.
Оповещения. Содержит в себе справочную информацию – советы, которые показываются пассажиру при работе с системой. Заводится также администратором системы и редактируется крайне редко. На текущий момент в таблице значится шесть записей.
Мета поисковики. Таблица для настройки определения запроса на приобретение авиабилета с сайта партнёра – мета поисковика. Содержит в себе описание мета поисковика, строку для добавления комментария к брони (с целью последующего определения отделом бухгалтерии продажи и предоставления комиссионного вознаграждения сайту партнёру) и прочие настройки.
Редактируется крайне редко, и на текущий момент имеет всего одну запись о мета поисковике Avia Sales.
Для лучшего понимания работы шлюза WS-Gate в и в целях экономии места пример запроса на получение расписания и ответ WS-Gate на данный запрос приведён в приложении 2.
2.2.3. Характеристика результатной информации
В качестве результатной информации, помимо документа PDF – маршрутной квитанции, который предоставлен в приложении 3, логично отобразить экранную форму, которую получает пассажир, после приобретения авиабилета, показанную на рисунке 12.
Рисунок 12. Заказ пассажира.
Данная форма генерируется на основе таблицы заказов. В самом верху всегда отображён номер заказа, ниже находится его статус. Далее идет информация о перелёте, где дата перелёта выделена желтым цветом. Справа в углу находится информация о номере рейса, а ниже города вылета/прилёта и местное время каждого аэропорта.
Чуть ниже находится блок с пассажирами и билетами.
Вся информация очень наглядная. Интерфейс интуитивно понятный. Тоже самое касается и формы отправки сообщения в тех поддержку авиакомпании. В результате отправки такого сообщения, у посетителя сайта появляется информация об успешном принятии его обращения, и соответственно зарегистрированный номер обращения, по которому далее в спорной ситуации можно будет поднять всю историю действий технической поддержки.
Также, помимо так называемой фронтальной части, есть ещё и бэкендовская часть, которая доступна только для администратора системы, сотрудника технической поддержки, или сотрудника коммерческого отдела.
Бекендовская часть в целях безопасности закрыта логином и паролем, и чтобы попасть на главную страницу бекенд части показанную на рисунке 13, обязательно необходимо пройти авторизацию, показанную на рисунке 14.
Рисунок 13. Главная страница бэкенд части.
Рисунок 14. Авторизация в бекенд часть системы.
Благодаря системе управления контентом OctoberCMS, все бэкенд формы разрабатываются довольно быстро и легко. Все они имеют идентичный интерфейс, который является частью всей системы. В качестве примера, хотелось бы рассмотреть листинг таблицы заказов и форму добавления в какую-либо справочную таблицу.
К примеру, в листинге заказов, отображённом на рисунке 15, показаны следующие поля: общая стоимость заказа, сумма возврата, итоговая сумма, статус заказа, дата изменений, валюта заказа, таймлимит брони, номер заказа, email заказчика, к которому в последствии может быть привязан пользователь заказа, телефон заказчика, дата создания, IP адрес выполнявшего заказ билетов, ID заказа в платёжной системе, и мета маркер.
Рисунок 15. Листинг страницы с заказами.
Все листинги в программе имеют обязательное поле поиска, которое расположено справа вверху. Поиск осуществляется с применение технологии AJAX и проходит только по тем полям, которые указаны в найстройках к данной модели таблицы. Каждая таблица имеет свою собственную модель – PHP класс с его уникальными методами. А также YAML файлы fields.yaml – в котором происходит настройка формы добавления новой записи в таблицу, и columns.yaml – информация о полях, которые необходимы для размещения в листинге контроллера.
Ниже, на рисунке 16, рассмотрено добавление в таблицу расписания новой записи.
Рисунок 16. Добавление новой записи в расписание.
Таким образом, если нам необходимо, чтобы данная запись участвовала в правилах формирования городов на первом шаге поиска авиабилетов, то переключатель необходимо установить в активную позицию. Далее вводятся номер рейса, частота полётов по дням недели (например частота 14 обозначает, что данный рейс выполняется только по понедельникам и четвергам), задается период действия расписания, выбирается пункт отправления и прибытия, согласно таблицы городов, указывается локальное время вылета и прилёта, при надобности добавляется комментарий, который потом будет доступен на сайте в модуле расписания полётов.
Примерно таким образом работает каждая форма контроллеров в бэкэнде. Считается, что это довольно хороший подход в разработке OctoberCMS, поскольку все модули сторонних разработчиков, всегда будут иметь одинаковый интерфейс и похожую стандартную базовую функциональность. Стоит также отметить, что при таком подходе существенно ускоряется процесс разработки бэкенда.
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
Рисунок 17. Дерево функций.
На рисунке 17 представлено дерево функций. Как мы можем наблюдать – для двух разных частей сайта, где описана разная функциональность. В свою очередь далее функциональность делится на основную и служебную. Если взять фронт часть, то мы сможем наблюдать, что служебные функции, как бы помогают исполнению основных функций. Таким образом, к примеру, если взять функцию поиск и выбор рейса/тарифа, то мы можем при более детальном рассмотрении увидеть, что в данной функции собраны практически все служебные функции.
Далее, согласно разработке дерева функций, составлен сценарий диалога для основного меню фронт части сайта, которую необходимо доработать для размещения на ней нового плагина. Сценарий можно посмотреть на рисунке 18.
Рисунок 18. Сценарий диалога фронт части.
Тоже самое, касаемо сценария диалога для бекенд части, отображает и рисунок 19.
Рисунок 19. Сценарий диалога бекенд части.
2.3.2. Характеристика базы данных
ER модель базы данных отображена на рисунке 20.
Рисунок 20. ER-модель.
Ниже, для каждой из таблиц, приведено её соответствующее описание по полям.
Таблица 4
Таблица заказов
| Наименование поля | Идентификатор поля | Тип поля | Длина поля | Прочее | |||
| ID | id | INT | 10 | Ключевое поле | |||
| Номер заказа | pnr | VARCHAR | 6 | ||||
| Дата создания | created_at | TIMESTAMP | |||||
| Дата обновления | updated_at | TIMESTAMP | |||||
| Сумма заказа | total | DECIMAL | 10,2 | ||||
| Сумма возврата | refund | DECIMAL | 10,2 | ||||
| Баланс | total | DECIMAL | 10,2 | ||||
| Статус | status | INT | 11 | ||||
| Валюта | currency | VARCHAR | 255 | ||||
| Таймлимит | utc_timelimit | DATETIME | |||||
| Номер заказа англ | regnum | VARCHAR | 6 | ||||
| Продолжение таблицы 4 | |||||||
| Email заказчика | customer_email | VARCHAR | 255 | ||||
| Телефон заказчика | customer_tel | VARCHAR | 255 | ||||
| Имя заказчика | customer_firstname | VARCHAR | 255 | ||||
| Фамилия заказчика | customer_lastname | VARCHAR | 255 | ||||
| ID пользователя | user_id | INT | 11 | ключ | |||
| Слаг | slug | VARCHAR | 191 | ||||
| Первая фамилия пассажира | firstpaxname | VARCHAR | 255 | ||||
| Цены | prices | TEXT | |||||
| Сегменты | segments | TEXT | |||||
| ID платежа | payment_id | INT | 11 | ||||
| URL платежа | payment_url | VARCHAR | 255 | ||||
| Дата оплаты | payment_at | DATETIME | |||||
| Флаг неудачной оплаты | is_reject | TINYINT | 1 | ||||
| Путь до маршрут квитанции | receipt | VARCHAR | 255 | ||||
| IP адрес | purchase_ip | VARCHAR | 255 | ||||
| Оплачено | real_total | DECIMAL | 10,2 | ||||
| Маркер | marker | VARCHAR | 255 | ||||
| ID платёжной системы | pays_id | INT | 11 | ключ | |||
| Мета поисковик | meta_finder | VARCHAR | 255 | ключ | |||
| Мета маркер | meta_marker | VARCHAR | 255 | ||||
Таблица 5
Таблица платежных шлюзов
| Наименование поля | Идентификатор поля | Тип поля | Длина поля | Прочее |
| ID | id | INT | 10 | Ключевое поле |
| ID в системе оплаты Платрон | platron_merchant_id | INT | 11 | |
| Название системы оплаты | payment_gateway | VARCHAR | 255 | |
| Секретный ключ Платрона | platron_secret_key | VARCHAR | 255 | |
| Система оплаты Платрона | platron_payment_system | VARCHAR | 255 | |
| Результативный URL | platron_result_url | VARCHAR | 255 | |
| Успешный URL | platron_success_url | VARCHAR | 255 | |
| Описание системы оплаты | payment_gateway_description | VARCHAR | 255 | |
| Не удачный URL | platron_failure_url | VARCHAR | 255 |
Таблица 6 Таблица метапоисковиков
| Наименование поля | Идентификатор поля | Тип поля | Длина поля | Прочее |
| ID | id | INT | 10 | Ключевое поле |
| Название | name | VARCHAR | 255 | |
| Маркер | marker | VARCHAR | 255 | |
| Логин | partner | VARCHAR | 255 | |
| Тип профита | profit_type | VARCHAR | 255 | |
| Значение профита | profit_value | DECIMAL | 10,2 | |
| Пароль | password | VARCHAR | 255 |
Таблица 7
Таблица национальностей (кодов стран)
| Наименование поля | Идентификатор поля | Тип поля | Длина поля | Прочее |
| ID | id | INT | 10 | Ключевое поле |
| Название | title | VARCHAR | 191 | |
| Код | code | VARCHAR | 191 |
Таблица 8
Таблица пользователей
| Наименование поля | Идентификатор поля | Тип поля | Длина поля | Прочее | ||||
| ID | id | INT | 10 | Ключевое поле | ||||
| Имя | name | VARCHAR | 255 | |||||
| VARCHAR | 255 | Уникальное | ||||||
| Пароль | password | VARCHAR | 255 | |||||
| Активационный код | activation_code | VARCHAR | 255 | Ключ | ||||
| Проверочный код | persist_code | VARCHAR | 255 | |||||
| Код для сбрасывания пароля | reset_password_code | VARCHAR | 255 | Ключ | ||||
| Права доступа | permissions | TEXT | ||||||
| Флаг активирования | is_activated | TINYINT | 1 | |||||
| Дата активации | activated_at | TIMESTAMP | ||||||
| Дата последнего посещения | last_login | TIMESTAMP | ||||||
| Дата создания | created_at | TIMESTAMP | ||||||
| Дата редактирования | updated_at | TIMESTAMP | ||||||
| Имя пользователя | username | VARCHAR | 255 | Ключ | ||||
| Фамилия | surname | VARCHAR | 255 | |||||
| Дата удаления | deleted_at | TIMESTAMP | ||||||
| Дата последнего действия | last_seen | TIMESTAMP | ||||||
| Флаг гостя | is_guest | TINYINT | 1 | |||||
| Флаг суперпользователя | is_superuser | TINYINT | 1 | |||||
| Дисконт | discount | INT | 11 | |||||
| IP адрес создателя | created_ip_address | VARCHAR | 191 | |||||
| Последний используемый IP Адрес | last_ip_address | VARCHAR | 191 | |||||
| Токен для API приложения | api_token | TEXT | ||||||
| Активационный код для приложения | activation_code_app | VARCHAR | 191 | |||||
Таблица 9
Таблица оповещений
| Наименование поля | Идентификатор поля | Тип поля | Длина поля | Прочее |
| ID | id | INT | 10 | Ключевое поле |
| Css класс для отображения | css | VARCHAR | 255 | |
| Код использования | where | VARCHAR | 255 | |
| Текст оповещения | text | TEXT | ||
| Флаг активности | is_active | TINYINT | 1 |
Таблица 10
Таблица расписания
| Наименование поля | Идентификатор поля | Тип поля | Длина поля | Прочее |
| ID | id | INT | 10 | Ключевое поле |
| Номер рейса | flight | INT | 11 | |
| Дата начала выполнения | period_start | DATE | ||
| Дата конца выполнения | period_end | DATE | ||
| Частота | freq | VARCHAR | 255 | |
| Вылет из | dep | VARCHAR | 255 | ключ |
| Время вылета | dep_time | TIME | ||
| Сдвиг вылета | dep_offset | INT | 11 | |
| Прилёт в | arr | VARCHAR | 255 | ключ |
| Время прилёта | arr_time | TIME | ||
| Сдвиг прилета | arr_offset | INT | 11 | |
| Код компании | company | VARCHAR | 255 | |
| Комментарий | comment | VARCHAR | 191 | |
| Флаг активности | is_active | TINYINT | 1 |
Таблица 11
Таблица городов
| Наименование поля | Идентификатор поля | Тип поля | Длина поля | Прочее |
| ID | id | INT | 10 | Ключевое поле |
| Название города на русском языке | town_name_ru | VARCHAR | 255 | |
| Код города на русском языке | town_code_ru | VARCHAR | 255 | |
| Код города на англ языке | town_code_en | VARCHAR | 255 | |
| Флаг активности | is_active | TINYINT | 1 | |
| Часовой пояс | timezone | VARCHAR | 255 | |
| Название города на англ языке | town_name_en | VARCHAR | 255 | |
| Код страны на русском | country_ru | VARCHAR | 255 | |
| Код страны на англ | country_en | VARCHAR | 255 | |
| Родительский ID | parent_id | INT | 11 |
Таблица 12
Таблица обращений пользователей
| Наименование поля | Идентификатор поля | Тип поля | Длина поля | Прочее |
| ID | id | INT | 10 | Ключевое поле |
| Имя | name | TEXT | ||
| Вопрос | question | TEXT | ||
| Ответ | answer | TEXT | ||
| Флаг показа | show | TINYINT | 1 | |
| Информация об ответе | sended_at | TEXT | ||
| Категория | category | TEXT | ||
| VARCHAR | 100 | |||
| Время создания | created_at | TIMESTAMP | ||
| Время редактирования | updated_at | TIMESTAMP |
2.3.3. Структурная схема пакета (дерево вызова программных модулей)
Для наглядности все модули системы представлены в таблице 13.
Таблица 13
Модули системы
| № п/п | Наименование модуля | Функции модуля |
| 1 | Модуль обратной связи | Отправка обращения в техническую поддержку, ответ пользователям, возможность размещения FAQ на сайте |
| 2 | Модуль обмена XML сообщениями с шлюзом WS-Gate | Отправляет сообщения на шлюз WS-Gate Сирены Трэвел и получает ответы на них |
| 3 | Модуль обмена XML сообщениями с платёжным шлюзом Platron | Отправляет сообщения на шлюз Platron и получает ответы на них |
| 4 | Модуль поиска вариантов перелёта | Уточняет таймлимит, ищет через модуль обмена XML сообщениями с шлюзом WS-Gate подходящие варианты перелётов, генерирует форму для ввода пассажиров, производит бронирование, делает запрос в Platron через модуль обмена XML сообщениями с платежным шлюзом Platron, создаёт новый заказ, инициализирует возврат, отменяет произведения возврата, производит денежный возврат, через Platron и Сирену-Трэвел, открывает заказ |
| 5 | Модуль поиска заказа | Редиректит с данными поиска в модуль поиска вариантов перелёта |
| 6 | Модуль авторизации | Производит регистрацию пользователя, дает возможность входа в личный кабинет, восстановить пароль, генерирует меню пользователя |
| 7 | Модуль ответа на запросы Platron | Отвечает в XML формате на запросы с платёжного шлюза Platron после транзакции пользователя. Изменяет заказ, посылает через модуль обмена сообщениями с Сиреной Трэвел информацию о статусе заказа |
| 8 | Модуль формы поиска авиабилета | Редиректит в модуль поиска и вариантов перелёта |
| 9 | Модуль аккаунта пользователя | Показывает аккаунт пользователя, запрашивает последние заказы пользователя и предоставляет быстрые ссылки на них |
| 10 | Модуль пользователей (бекенд) | Просмотр, создание, удаление, редактирование пользователей. Возможность зайти на фронт часть пользователем. |
| 11 | Модуль городов (бекенд) | Просмотр, создание, удаление, редактирование городов |
| 12 | Модуль заказов (бекенд) | Просмотр заказов, выполнение отмены, возврата и обмена заказа |
| 13 | Модуль расписания (бекенд) | Просмотр, создание, удаление, редактирование расписания |
| 14 | Модуль управления (бекенд) | Показ оперативной информации по баллам, отправка ключа в Сирену Трэвел. Просмотр информации о ключе. Загрузка справочников |
| 15 | Модуль оповещений (бекенд) | Просмотр, создание, удаление, редактирование оповещений |
| 16 | Модуль метапоисковиков (бекенд) | Просмотр, создание, удаление, редактирование мета поисковиков |
| 17 | Модуль систем оплаты (бекенд) | Просмотр, создание, удаление, редактирование систем оплаты |
| 18 | Модуль национальностей (бекенд) | Просмотр, создание, удаление, редактирование стран |
2.3.4. Описание программных модулей
В качестве описания программного модуля, ниже предоставлена блоксхема самого большого модуля системы: Модуль поиска вариантов перелёта. Листинг этого же модуля представлен в приложении 4.
Пожалуй, в формате листа А4, довольно трудно отобразить блок схему, поэтому вся блок схема будет разбита на части, для лучшего понимания. Первая часть её проходит при загрузке модуля и отображена на рисунке 21:
Рисунок 21. Блок схема, часть 1.
Далее на рисунке 22, продолжение блок-схемы.
Рисунок 22. Блок схема, часть 2.
Наконец, третья часть блок-схемы показана на рисунке 23.
Рисунок 23. Блок схема, часть 3.
2.4. Контрольный пример реализации проекта и его описание
В контрольном примере, хотелось бы показать, как происходит бронирование авиабилета с фронта, а также как добавляется в бекенде в справочник расписания информация.
Заполнение формы поиска показано на рисунке 24.
Рисунок 24. Заполнение формы поиска.
Далее на рисунке 25 мы видим выбор необходимого нам варианта:
Рисунок 25. Выбор варианта перелёта.
После чего, на рисунке 26 нашему вниманию предоставлен результат валидации, когда мы не заполнили поле с именем пассажира. Поле выделяется красным цветом, и ниже поля показана ошибка.
Рисунок 26. Результат валидации формы.
После успешного исправления ошибки, мы можем забронировать билет. На рисунке 27 полностью верно заполненная форма.
Рисунок 27. Форма заполнения данных пассажира.
Далее на рисунке 28 показан результат бронирования авиабилета. Бронь держится пол часа, о чем сигнализирует счётчик в правом углу формы.
Рисунок 28. Отображение заказа.
Далее на рисунке 29, показа форма, для оплаты заказа банковской картой
Рисунок 29. Форма для оплаты.
Также, предлагаю рассмотреть пример работы со справочником Расписания и городов.
На рисунке 30, показана форма для добавления тестового города, под названием «Тестовый вылет».
Рисунок 30. Форма для добавления записи в справочник городов.
Тоже самое действие проведём для города «Тестовый прилёт», и после чего заведём в справочнике расписания новое расписание с этими городами, показанное на рисунке 31.
Рисунок 31. Форма для добавления записи в справочник расписания.
После чего на фронте проверим, как сработает теперь форма поиска. При выборе города «тестовый вылет» у нас появится город «тестовый прилёт», а календарь покажет возможность выбрать только вторники и пятницы, согласно справочнику расписания. Пример показан на рисунке 32.
Рисунок 32. Форма поиска.
III Обоснование экономической эффективности проекта
3.1 . Выбор и обоснование методики расчёта экономической эффективности
Цель деятельность любого коммерческого предприятия — максимизация прибыли. Чтобы постоянно улучшать этот показатель, необходимо провести расчет экономической эффективности.
Стоит отметить, что при работе на Oxygen, страницы загружались очень долго. Было пять шагов для совершения покупки. Пользователи просто закрывали страницу не дойдя до самого бронирования. Все это вызывало также и негативные отзывы на страницах социальных сетей, что крайне плохо сказывалось на имидже компании в целом.
При работе на новой системе, страницы загружается довольно быстро. Нет необходимости оплачивать за хостинг и аренду программного модуля в целом. Нет необходимости ждать ответа от технической поддержки, вся административная работа выполняется довольно быстро собственными силами авиакомпании.
Ниже представлены расчёты следующих трудовых показателей:
Абсолютное снижение трудовых затрат (ΔT) в часах в год, который рассчитывается по формуле ΔТ = Т0 – Т1.
ΔT = 3600 – 1200 = 2400 часов в год.
Коэффициент относительного снижения трудовых затрат (КТ) составит:
КТ = ΔТ / Т0 * 100% = 2400 / 3600 * 100% = 66,6%
Индекс снижения трудовых затрат (YT) будет:
YT = T0 / T1 = 3.
Чтобы просчитать стоимостные затраты, необходимо учитывать тот факт, что стоимость предоставления некоторых услуг, изменилась. Таким образом, в таблице 14, отобразим эти данные:
Таблица 14
Стоимостные оценки
| Услуга | Oxygen | Новая разработка |
| За 1 успешную бронь | 25 руб. | 0 руб. |
| Единовременная установочная плата | 40 000 руб. | 0 руб. |
| Разработка | 0 руб. | 200 000 руб. |
| Процессинг | 1% | Отсутствует |
| Эквайринг | 2,8% | 1,8% |
| Увеличение продаж благодаря метапоиску | Отсутствует | На 25%. |
| Метапоиск | Отсутствует | 2,4% |
| Увеличение продаж, благодаря уменьшению шагов и увеличению скорости загрузки страниц | — | На 30% |
Итого, если учитывать что в среднем в месяц на Oxygen проходило около 3000 покупок, то складывается такая общая картина по стоимостным показателям:
Д0 = 3000 * 13000 руб (средний счёт) * 12 месяцев – (3000 * 25 руб * 12 месяцев) — (3000 * 13000 руб (средний счёт) * 12 месяцев) * 3.8% — 40 000руб = 468 000 000 руб – 17 784 000 руб – 40 000 руб = 450 176 000 руб
Д1 = 3000 * 13000 руб (средний счёт) * 12 месяцев + 30% + 25% —
200000руб – (3000 * 13000 руб (средний счёт) * 12 месяцев + 30% + 25% ) * 1.8% — (3000 * 13000 руб (средний счёт) * 12 месяцев) * 25% * 2.4% = 468 000 000 руб + 140 400 000 руб + 117 000 000 руб – 200 000 руб – 13 057 200 руб – 2 808 000 руб = 709 334 800 руб.
Таким образом, абсолютное снижение стоимостных затрат в год составит
ΔС = 17 824 000 – 16 065 200 = 1 758 800 рублей / год
Коэффициент относительного снижения стоимостных затрат составит
КС = 9.8%
Индекс снижения стоимостных затрат
YС = 1.1
Кроме всего прочего, стоит отметить тот факт, что увеличение прибыли составит 57.5%.
При этом срок окупаемости затрат на внедрение проекта составит
ТОК = КП / ΔС = 200 000 / 1 758 800 = 0.1
Получается, что проект окупится в первый же месяц своей работы.
3.2. Расчёт показателей экономической эффективности проекта
Расчёт показателей экономической эффективности проекта предоставлен на рисунка 33-35.
Рисунок 33. Диаграмма изменения трудовых затрат.
Рисунок 34. Диаграмма изменения стоимостных затрат.
Рисунок 35. Диаграмма изменения дохода.