37
1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному
обеспечению
Для нормального функционирования разрабатываемой информационной
системы не требуется никаких входных документов. На выходе, заказчик, будет
иметь только один документ в формате PDF – маршрут-квитанцию, которую
пассажиру рекомендовано распечатать и взять с собой в аэропорт, для
предоставления сотрудникам аэропорта, при возникновении каких-либо
вопросов. Но это совершенно не обязательно делать, поскольку на данный
момент все билеты являются электронными, а как известно электронный билет –
это запись в базе данных авиакомпании информации о направлении и времени
перелёта, данных пассажира, включая его паспортные данные и при желании
службами аэропорта можно в два счёта уточнить информацию о наличии
конкретного пассажира на конкретном рейсе.
В маршрутной квитанции должна содержаться следующая информация:
Полетная информация (направление перелёта, дата и время
вылета/прилёта, бесплатная норма провоза багажа)
Персональная информация (ФИО пассажира, его паспортные
данные)
Отпечаток пункта продажи (кодификатор места, где был выпущен
электронный билет)
Тарифная информация
Дополнительная информация (важные оповещения и некоторые
выдержки из правил авиакомпании)
Что касается экранных форм, то выполнены они должны быть в стиле
технологии Bootstrap. Главная форма поиска авиабилета должна содержать в
себе пять элементов:
Выбор направления вылета
Выбор направления прилёта
38
Дату рейса
Дату обратного рейса (если необходимо и перевозка будет
выполняться туда и обратно)
Количество и типы пассажиров
Прототип формы поиска можно просмотреть на рисунке 9.
Рисунок 9. Прототип формы поиска авиабилетов.
Далее после выбора подходящего тарифа, пассажиру должно быть
предложено заполнение данных пассажиров, которые состоят из следующих
элементов:
ФИО
Дата рождения
Гражданство
Тип документа
Номер документа
Пол
Дополнительно должно быть предложено заполнить информацию и о
заказчике, состоящую из двух полей – email заказчика и его телефон.
Пример прототипа данной формы можно просмотреть на рисунке 10.
39
Рисунок 10. Форма ввода информации о пассажире и
заказчике.
Соответственно после успешной транзакции, формируется маршрут-
квитанция, которая отправляется на почту заказчику, а также выводится ссылка
для её непосредственного скачивания.
Стоит обратить внимание, что в разрабатываемой системе будет
реализован международный авиационный классификатор городов, стран и
гражданства согласно международной классификации IATA.
Локальный классификатор будет только один – у статуса заказа. Таким
образом в базе данных будет содержаться цифирное значение статуса заказа:
1. Забронирован
2. Отменен
3. Продан
4. Произведён возврат
5. Произведён частичный возврат
Разрабатываемая информационная система будет иметь
интегрированную базу данных MySQL, которая является одной из самых
распространённых Систем Управления Базами Данных (СУБД), поскольку в
задачах, которые необходимо решить – присутствует также и скорость загрузки,
а реализация информационной системы через хранение данных в файлах, нам, к
сожалению, не может дать такой скорости загрузки как СУБД MySQL.
40
База данных будет состоять из следующих важных таблиц:
Города (классификатор городов IATA)
Расписание вылетов
Национальности
Заказы
Пассажиры
Пользователи
Системы оплаты
Метапоисковики
Записки (важная информация для пассажиров)
Файлы пользователей (стандартная таблица OctoberCMS)
Генерируемые маршрут-квитанции будут лежать физически в отдельной
папке storage, но имя файла и путь к нему будет записано в таблице «Файлы
пользователей». Таким образом мы сохраним быстроту и удобство работы с
базой данных не раздув её, до критических размеров.
1.4.2. Обоснование проектных решений по программному обеспечению
По программной архитектуре, отображённой на рисунке 4, абсолютно
отсутствуют какие-либо рекомендации, поскольку программное обеспечение на
рабочих станциях стоит современное. Практически везде установлена
операционная система Windows 10. Современная, качественная, быстрая и
защищённая. Единственный отдел, в котором установлен WindowsXP – это отдел
материально технического снабжения (ОМТС), но установка более современной
операционной системы на то техническое оборудование, которое имеется в
ОМТС не представляется возможным из-за низких технических характеристик.
Интересен тот факт, что каким-то образом специалисты нашли способ
установить на iMac руководства операционную систему Windows 10. Данный
факт несколько удивил, при проведении анализа программной архитектуры
предприятия.
41
Что касается серверов предприятия, то и тут установлены современные
операционные системы. Все важные обновления устанавливаются в срок.
Помимо того, что на главном маршрутизаторе Kerio Control используется
встроенный антивирус, также и на рабочих станциях используют антивирус
Касперского для малого офиса, что является отличным средством защиты на
сегодняшний день.
Для реализации разрабатываемой информационной системы
дополнительного программного обеспечения не потребуется. Информационная
система будет разработана на языке PHP, который уже сейчас используются на
сервере, который в свою очередь, обеспечивает работоспособность сайта
авиакомпании. Для рабочих станций, также дополнительно не потребуется
устанавливать ничего. Разрабатываемая информационная система будет
успешно работать с любого современного браузера.
Разработка будет проводиться в Интегрированной среде разработки
(Integrated Development Environment IDE) PhpStorm. Для разработки будет
использоваться локальный сервер Open Server. Для доступа к базе данных, будет
использовано такое средство, как HeidiSQL. Ну и отслеживаться вся разработка
будет обязательно в GIT, при этом будет использована программа SourceTree.
Поскольку текущий сайт авиакомпании работает на системе управления
контентом OctoberCMS, которая в свою очередь имеет «под капотом»
знаменитый PHP Фреймворк Laravel, то соответственно и разработка новой
информационной системы будет проходить в рамках этой системы управления
сайтом в виде отдельного подключающегося плагина.
1.4.3. Обоснование проектных решений по техническому обеспечению
По технической архитектуре имеются следующие рекомендации.
Во-первых, серверная комната, не соответствует требованиям
безопасности, не установлены сигнализаторы пожара, и нет оборудования,
42
которое смогло бы остановить пожар, залив его пеной. А ведь на сервере
хранятся жизненно важные данные авиакомпании.
Во-вторых, на рисунке 3 мы видим фотографию серверных стоек. Они
сделаны собственноручно. Скорее всего, все это делалось для того, чтобы
удешевить конечную стоимость серверной комнаты, но в таких стойках нет
никакой защиты от пыли, которая со временем будет накапливаться не только на
серверном оборудовании, но также и внутри него, что может иметь довольно
негативные последствия, а возможно и приведёт к полной замене серверов.
Рекомендуется привести серверную комнату в порядок. Установить
противопожарную систему, и оснастить сервер специализированным серверным
шкафом со специальным охлаждением.
Также рекомендовал бы заменить рабочую стацию в ОМТС, на более
современную, поскольку из за нехватки мощностей на данной рабочей станции
возможна лишь установка устаревшей операционной системы Windows XP,
которая на данный момент имеет серьёзные бреши в безопасности, и может стать
уязвимой для злоумышленников, которые в свою очередь могут нанести вред
всей локальной сети авиакомпании.
Что касается виртуального персонального сервера (Virtual Personal Server
VPS) авиакомпании, поскольку сайт авиакомпании стоящий на данном сервере
теперь будет выполнять роль не просто визитной карточки, а иметь в себе
информационную систему, то для него рекомендовано перейти на более дорогой
тариф, для увеличения CPU с одного до четырех ядер и оперативной памяти с
512МБ до 4GB. Такая конфигурация гарантированно выдержит посещения
сайтом двух тысяч человек в день.
43
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Для разработки информационной системы был выбран стандарт быстрой
разработки приложений RAD (Rapid Application Development). Это концепция
создания средств разработки программных продуктов, уделяющая особое
внимание быстроте и удобству программирования, созданию технологического
процесса, позволяющего программисту максимально быстро создавать
компьютерные приложения.
Практическое определение RAD — это жизненный цикл процесса
проектирования, созданный для достижения более высокой скорости разработки
и качества программного обеспечения, чем это возможно при традиционном
подходе к проектированию. RAD реализует спиральную модель жизненного
цикла. Концепцию RAD также часто связывают с концепцией визуального
программирования.
Жизненный цикл программного обеспечения по методологии RAD
состоит из четырех этапов:
1. Анализ и планирование требований
2. Проектирование
3. Построение
4. Внедрение
На этапе анализа и планирования требований были определены наиболее
важные функции, которыми должна обладать информационная система и
которые должны были быть разработаны в первую очередь. Ограничивался
масштаб проекта, определялись временные рамки для каждого из последующих
этапов.
На этапе проектирования создавалось техническое проектирование
системы, уточнялись и дополнялись требования к системе, которые не были
выявлены на предыдущей фазе. Более подробно рассматривались процессы
44
системы. Каждый из процессов рассматривался детально и создавался
частичный прототип: экран, диалог, отчет, устраняющий неясности или
неоднозначности. Определялись требования разграничения доступа к данным.
На этой же фазе происходило определение набора необходимой документации.
В результате данного этапа появились:
Общая информационная модель системы
Функциональные модели системы в целом
Точно определённые с помощью CASE средства интерфейсы
Построенные прототипы экранов, отчетов и диалогов
На этапе построения была выполнена непосредственно сама быстрая
разработка плагина под OctoberCMS. После окончания работ была произведена
постепенная интеграция данной части системы с основным сайтом, был
сформирован полный программный код, а также было выполнено тестирование
данной части приложения, а затем тестирование системы в целом. В завершении
физического проектирования системы:
Определялась необходимость распределения данных
Производился анализ использования данных
Производилось физическое проектирование базы данных
Определялись требования к аппаратным ресурсам
Определялись способы увеличения производительности
Завершалась разработка документации проекта
В результате этапа построения появилась готовая система,
удовлетворяющая всем согласованным требованиям.
На этапе внедрения производилось обучение пользователей технической
поддержки и параллельно с внедрением новой системы осуществлялась работа с
существующей системой Oxygen, до полного внедрения новой. Была выбрана
параллельная стратегия внедрения. Конечно же нагрузка на время этапа
внедрения возросла на пользователей технической поддержки, но и несомненно
45
можно выделить плюс параллельной стратегии, что если в системе была
обнаружена ошибка, то пользователи технической поддержки просто
перенаправляли пассажиров на старую систему Oxygen. Следует также отметить,
что в очередной виток спирального подхода, когда система полностью
удовлетворяла требованиям и не вызывала ошибок, был использована так
называемая система внедрения «скачок» и новая система полностью заменила
старую систему Oxygen.
Таким образом, бесспорно, можно отметить следующие преимущества
стандарта RAD:
Быстрота продвижения программного продукта на рынок
Интерфейс, устраивающий пользователя
Легкая адаптируемость проекта к изменяющимся требованиям
Простата развития функциональности системы
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Риск – это всегда неопределённость. Чем больше размер проекта, тем
выше степень его неопределённости. К счастью выбранный мною проект
реализации информационной системы не такой уж большой, а соответственно и
риски можно классифицировать следующим образом:
1. Технические риски. Разработка любого ИТ-проекта осуществляется
с помощью специфического оборудования. В нашем случае это
виртуальный персональный сервер, отказ которого мы можем получить
в любой момент, либо его поломку, что может оказать влияние на сроки
реализации проекта, частично приостановить работу над проектом, до
его восстановления. Рекомендовано иметь резервную копию сервера,
которую всегда можно восстановить в краткие сроки.
2. Риски оценки сроков. Для большинства веб-проектов характерны
ошибки в определение сроков необходимых для реализации проекта.
Часто это связано с недостаточностью проработки плана проекта, что
приводит к появлению забытых работ и смещению сроков. Данный
46
риск мы успешно ликвидируем выбором спиральной модели в
разработке и с каждым новым витком увеличиваем функционал.
3. Риски непринятия продукта пользователем. Любой новый сервис –
это, в первую очередь, изменение технологии работы. Эти изменения
могут быть не приняты пользователями веб-продукта. Пользователь
интернета не захочет читать справки сервиса, а поэтому
пользовательский интерфейс не должен нести в себе перегруженности
и обязательно должен быть интуитивно понятным. Стоит также всегда
прислушиваться к мнению пользователей о сервисе, и пользоваться
современными инструментами отслеживания поведений пользователя
при работе с ИТ-продуктом.
4. Технологические риски. Каждый год в сфере интернета происходят
революционные изменения, появляются кардинально новые
разработки, меняющие вектор развития. Всегда необходимо оценивать
успешность технологий на рынке, ее актуальность на протяжении
жизненного цикла проекта, доступность аппаратного и программного
обеспечения, его качество и частоту модернизации.
5. Риски несоблюдения технологии. Использование для реализации
проекта новых, не опробованных технологий, может привести к
затруднениям в реализации проекта. Версионность всего программного
обеспечения, а также переход на новые версии, всегда должна
учитываться, иначе разработанные функции на более старых версиях,
могут совершенно неправильно работать, либо вообще вызвать
ошибку, которая не позволит дальнейшее использование системы.
6. Коммерческие риски. Это риски, обусловленные
неблагоприятными изменениями в экономике предприятия или
экономике страны.
7. Недостаток трудовых ресурсов. Разработчики, которые создают
продукт – это основной ресурс ИТ-проекта и один из основных рисков.
Ограниченность этого ресурса приводит к срывам сроков реализации