II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Для разработки информационной системы был выбран стандарт быстрой разработки приложений RAD (Rapid Application Development). Это концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные приложения.
Практическое определение RAD — это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества программного обеспечения, чем это возможно при традиционном подходе к проектированию. RAD реализует спиральную модель жизненного цикла. Концепцию RAD также часто связывают с концепцией визуального программирования.
Жизненный цикл программного обеспечения по методологии RAD состоит из четырех этапов:
1. Анализ и планирование требований
2. Проектирование
3. Построение
4. Внедрение
На этапе анализа и планирования требований были определены наиболее важные функции, которыми должна обладать информационная система и которые должны были быть разработаны в первую очередь. Ограничивался масштаб проекта, определялись временные рамки для каждого из последующих этапов.
На этапе проектирования создавалось техническое проектирование системы, уточнялись и дополнялись требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматривались процессы системы. Каждый из процессов рассматривался детально и создавался частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определялись требования разграничения доступа к данным. На этой же фазе происходило определение набора необходимой документации. В результате данного этапа появились:
Общая информационная модель системы
Функциональные модели системы в целом
Точно определённые с помощью CASE средства интерфейсы
Построенные прототипы экранов, отчетов и диалогов
На этапе построения была выполнена непосредственно сама быстрая разработка плагина под OctoberCMS. После окончания работ была произведена постепенная интеграция данной части системы с основным сайтом, был сформирован полный программный код, а также было выполнено тестирование данной части приложения, а затем тестирование системы в целом.
В завершении физического проектирования системы:
Определялась необходимость распределения данных
Производился анализ использования данных
Производилось физическое проектирование базы данных
Определялись требования к аппаратным ресурсам
Определялись способы увеличения производительности
Завершалась разработка документации проекта
В результате этапа построения появилась готовая система, удовлетворяющая всем согласованным требованиям.
На этапе внедрения производилось обучение пользователей технической поддержки и параллельно с внедрением новой системы осуществлялась работа с существующей системой Oxygen, до полного внедрения новой. Была выбрана параллельная стратегия внедрения. Конечно же нагрузка на время этапа внедрения возросла на пользователей технической поддержки, но и несомненно можно выделить плюс параллельной стратегии, что если в системе была обнаружена ошибка, то пользователи технической поддержки просто перенаправляли пассажиров на старую систему Oxygen. Следует также отметить, что в очередной виток спирального подхода, когда система полностью удовлетворяла требованиям и не вызывала ошибок, был использована так называемая система внедрения «скачок» и новая система полностью заменила старую систему Oxygen.
Таким образом, бесспорно, можно отметить следующие преимущества стандарта RAD:
Быстрота продвижения программного продукта на рынок
Интерфейс, устраивающий пользователя
Легкая адаптируемость проекта к изменяющимся требованиям
Простата развития функциональности системы
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Риск – это всегда неопределённость. Чем больше размер проекта, тем выше степень его неопределённости. К счастью выбранный мною проект реализации информационной системы не такой уж большой, а соответственно и риски можно классифицировать следующим образом:
1. Технические риски. Разработка любого ИТ-проекта осуществляется с помощью специфического оборудования. В нашем случае это виртуальный персональный сервер, отказ которого мы можем получить в любой момент, либо его поломку, что может оказать влияние на сроки реализации проекта, частично приостановить работу над проектом, до его восстановления. Рекомендовано иметь резервную копию сервера, которую всегда можно восстановить в краткие сроки.
2. Риски оценки сроков. Для большинства веб-проектов характерны ошибки в определение сроков необходимых для реализации проекта. Часто это связано с недостаточностью проработки плана проекта, что приводит к появлению забытых работ и смещению сроков. Данный риск мы успешно ликвидируем выбором спиральной модели в разработке и с каждым новым витком увеличиваем функционал.
3. Риски непринятия продукта пользователем. Любой новый сервис – это, в первую очередь, изменение технологии работы. Эти изменения могут быть не приняты пользователями веб-продукта. Пользователь интернета не захочет читать справки сервиса, а поэтому пользовательский интерфейс не должен нести в себе перегруженности и обязательно должен быть интуитивно понятным. Стоит также всегда прислушиваться к мнению пользователей о сервисе, и пользоваться современными инструментами отслеживания поведений пользователя при работе с ИТ-продуктом.
4. Технологические риски. Каждый год в сфере интернета происходят революционные изменения, появляются кардинально новые разработки, меняющие вектор развития. Всегда необходимо оценивать успешность технологий на рынке, ее актуальность на протяжении жизненного цикла проекта, доступность аппаратного и программного обеспечения, его качество и частоту модернизации.
5. Риски несоблюдения технологии. Использование для реализации проекта новых, не опробованных технологий, может привести к затруднениям в реализации проекта. Версионность всего программного обеспечения, а также переход на новые версии, всегда должна учитываться, иначе разработанные функции на более старых версиях, могут совершенно неправильно работать, либо вообще вызвать ошибку, которая не позволит дальнейшее использование системы.
6. Коммерческие риски. Это риски, обусловленные неблагоприятными изменениями в экономике предприятия или экономике страны.
7. Недостаток трудовых ресурсов. Разработчики, которые создают продукт – это основной ресурс ИТ-проекта и один из основных рисков. Ограниченность этого ресурса приводит к срывам сроков реализации проекта. Также опрометчиво думать что участники проекта будут все своё время тратить на работу над проектом. Для этого есть ряд объективных причин. К списку наиболее распространённых причин этого относятся: сопровождение действующих систем, обучение и повышение квалификации, праздники, больничные, отпуска. Рекомендуется считать, что реальное время потраченное на проект, будет в районе 60-80% от всего рабочего времени.
8. Риски разработки. Зависят от квалифицированной подготовки программистов, знания ими продуктов, а также от выбранной стратегии и тактики разработки. Типичными ошибками могут быть: отсутствие, либо реально не работающая система контроля версий, не использование инструментов отладки кода, не регулируемые права доступа на тестовые, боевые или девелоперские серверы, работа всех сотрудников от root пользователя, отсутствие комментариев в коде.
2.1.3. Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации
Как уже было выше не раз подмечено, безопасности в компании Avia Traffic Company уделяют довольно значимое значение. Анализ показал, что все сервера строго доступны по определённым протоколам для пользователей. Для доступа же к администрированию используются разрешения на определённые 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’);
}
49
Метод 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 блокирует перехват злоумышленниками в одной сети конфиденциальной информации, такой как переменные сеанса, и регистрацию с ее помощью от имени жертвы.
50
Также стоит отметить, что все формы, с которыми работает пользователь – проходят верификацию, прежде чем будет продолжена работа, и о несоответствиях в формате, либо правиле применимом к той или иной форме ввода тут же сообщается пользователю красным цветом.
При ошибке кода, пользователю будет показана стандартная страница ошибки, а администратор будет оповещён по 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” установив который, данный город будет показываться на фронте в форме поиска авиабилета. Редактирование данной таблицы происходит крайне редко.
Национальности. Данная справочная таблица содержит в себе все возможные страны, как бы это странно не звучало. Так уж исторически
55
сложилось, что запрос в 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
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. Форма поиска.