Комплекс мобильных приложений по оказанию автомобильной помощи на дорогах

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«ДОНСКОЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» (ДГТУ)

Факультет «Информатика и вычислительная техника»

Кафедра «Программное обеспечение вычислительной техники и автоматизированных систем»

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к выпускной квалификационной работе бакалавра на тему:

Комплекс мобильных приложений по оказанию автомобильной помощи на дорогах



Содержание

Введение

1. Аналитический обзор сферы интернет заказов автомобилей

1.1 Обзор процесса заказа эвакуатора

1.2 Обзор существующих приложений в сфере оказания автомобильной помощи

1.2.1 Приложение «Эвакуатор»

1.2.2 Приложение «Все эвакуаторы Петербурга»

1.3 Выводы по главе

1.4 Постановка задачи

2. Алгоритмическое конструирование комплекса мобильных приложений по оказанию автомобильной помощи на дорогах

2.1 Алгоритм авторизации пользователя

2.2 Алгоритм заказа эвакуатора

2.3 Алгоритм обновления информации о текущем местоположении

2.4 Алгоритм получения заказа оператором эвакуатора

2.5 Выводы по главе

3. Программное конструирование комплекса мобильных приложений по оказанию автомобильной помощи на дорогах

3.1 Обоснование выбора языка и среды разработки

3.2 Классы приложения для водителя автомобиля

3.2.1 Класс NavigationDrawerActivity

3.2.2 Класс CompaniesAdapter

3.2.3 Класс MainMapFragment

3.2.4 Класс CheckOrderStatusService

3.2.5 Класс CreateOrderAsync

3.2.6 Класс GetCompaniesAsync

3.3 Классы приложения для оператора эвакуатора

3.3.1 Класс MainMapFragment

3.3.2 Класс GetOrderServivce

3.3.3 Класс NavigationDrawerActivity

3.3.4 Класс MyLocation

3.4 UML - диаграмма классов приложения для водителя автомобиля

3.5 UML - диаграмма классов приложения для оператора эвакуатора

4. Тестирование работы комплекса мобильных приложений по оказанию автомобильной помощи на дорогах

4.1 Тестирование авторизации в приложении для водителя

4.2 Тестирование выполнения заказа

4.3 Выводы по главе

5. Экономическое обоснование работы

5.1 Основные аспекты реализации работы

5.2 Оценка потенциальной социально-экономической результативности внедрения разработки

5.3 Планирование разработки с использованием сетевого графика

5.4 Стратегический маркетинговый анализ целесообразности внедрения

5.5 Определение себестоимости разработки

5.6 Выводы по главе

6. Безопасность и экологичность работы

6.1 Анализ опасных и вредных производственных факторов

6.1.1 Микроклимат

6.1.2 Производственное освещение

6.1.3 Защита от шума и вибраций

6.1.4 Защита от электромагнитных полей, лазерных и ионизирующих излучений

6.1.5 Электробезопасность

6.2 Расчет системы искусственного освещения помещения

6.3 Организация рабочего места

6.4 Устойчивость к чрезвычайным ситуациям. Пожарная безопасность

6.5 Охрана окружающей среды

6.6 Выводы по главе

Заключение

Список использованных источников

Приложения

автомобильный помощь приложение мобильный



Введение

С развитием мобильных устройств, таких как смартфоны и планшеты, жизнь людей сильно изменилась. Мобильные устройства упростили выполнение ряда задач. На сегодняшний день существует огромное количество мобильных приложений, которые применяются в самых разнообразных сферах человеческой деятельности.

В социальной сфере приложения позволяют всегда оставаться на связи, общаться людям, которые находятся друг от друга на очень большом расстоянии и даже видеть друг друга благодаря функции видео связи. Новостные приложения с помощью своевременных уведомлений позволяют пользователю всегда быть в курсе последних произошедших событий.

Современные мобильные приложения предоставляют пользователям большие возможности для совершения покупок. Покупка с помощью смартфона перестала быть чем-то необычным. Теперь необязательно носить с собой множество пластиковых банковских карт. Можно оплатить покупку при помощи современных технологий защищенной беспроводной передачи данных. Приобрести товар можно в любом месте, где есть интернет и заказать удобное для вас время и место доставки.

Отправляясь в дорогу, многие туристы обязательно берут с собой какие-нибудь мобильные устройства. И это не удивительно, потому что обилие мобильных приложений в сочетании с аппаратными возможностями устройства дают пользователю такие возможности как определение своего текущего местоположения, отображение его на карте, отображение ближайших магазинов, автозаправочных станций, центров по оказанию медицинской помощи и так далее.

Использование мобильных приложений в повседневной жизни не обошло стороной и водителей автомобилей. Смартфон или планшет служит отличным навигатором, который строит маршрут до пункта назначения и с помощью голосовых подсказок озвучивает направление движения.

Однако, может произойти ситуация, когда автомобиль может выйти из строя по какой-либо причине и такой автомобиль необходимо доставить на станцию технического обслуживания. В данной ситуации водителю сломанного автомобиля необходимо найти компанию, предоставляющую услуги эвакуации автомобиля, при этом ему тяжело ориентироваться в многообразии таких фирм и их ценовой политики. Водителю будет не известно время прибытия эвакуатора, точный тариф, а также возможна ситуация, когда ему будет тяжело сформулировать свое текущее местоположение.

Поэтому будет актуальной задачей произвести анализ процесса заказа эвакуатора, разбиение его на этапы, и выполнить автоматизацию этих этапов, что позволит уменьшить человеческий фактор и повысить эффективность взаимодействия автомобилиста и оператора эвакуатора.

Создание мобильного приложения для автомобилиста и мобильного приложения для оператора эвакуатора может значительно упростить процесс взаимодействия сторон, путем снижения временных и денежных затрат, а также предоставления всей необходимой информацию для каждой из сторон.

Разрабатываемый комплекс мобильных приложений может найти применение в сфере заказов услуг эвакуирования автотранспортных средств.

1. Аналитический обзор сферы интернет заказов автомобилей

В данном разделе рассматриваются существующие приложения в сфере оказания автомобильной помощи, приводятся их особенности и недостатки. Определяется цель работы и задачи, которые необходимо решить для ее достижения.

1.1 Обзор процесса заказа эвакуатора

На сегодняшний день чтобы вызвать эвакуатор автомобилисту, у которого сломался автомобиль, необходимо выполнить несколько действий, которые включают в себя поиск компании, которая предоставляет услуги эвакуации, совершить звонок в эту компанию, узнать ценовой тариф и предоставить информацию о своем текущем местоположении. После того, как диспетчер компании получит необходимую информацию от водителя, он направляет ее свободному оператору эвакуатора, чтобы тот мог отправиться к месту назначения. Весь этот процесс занимает много времени и не очень удобен для водителя сломанного автомобиля.

В вышеописанной схеме взаимодействия существует ряд проблем. Во-первых, предоставление информации для водителя сломанного автомобиля. Водителю необходимо самостоятельно найти номер фирмы, при этом фирм, оказывающих необходимые услуги может быть несколько, позвонить в каждую из этих фирм, узнать и запомнить ценовой тариф. Выполнение данных действий занимает много времени и является не самым удобным способом получения нужной информации для водителя.

Во-вторых, во время звонка водителя диспетчеру, диспетчер не может предоставить информацию об ориентировочном времени прибытия эвакуатора. Данная информация станет доступна диспетчеру только после того как он передаст сведения о местоположении водителя сломанного автомобиля оператору эвакуатора. Затем диспетчер должен перезвонить водителю сломанного автомобиля, чтобы сообщить ориентировочное время прибытия эвакуатора. Так же после совершения заказа, водитель не имеет в своем распоряжении никакой информации о текущем местоположении эвакуатора.

В-третьих, водитель сломанного автомобиля не всегда может точно определить и описать свое текущее местоположение. Такая ситуация вполне возможна, если водитель находится, например, на трассе. В таком случае, при передаче информации от диспетчера фирмы оператору эвакуатора, может возникнуть недопонимание и водителю эвакуатора придется узнать у диспетчера номер телефона водителя сломанного автомобиля и самостоятельно позвонить ему, чтобы уточнить детали его местоположения.

Существуют смежные области, в которых подобные проблемы уже решены. Для решения этих проблем компании используют интернет сервисы, которые предоставляют пользователю всю необходимую информацию, а также возможность совершить заказ без участия посредника между пользователем и водителем такси. Одним из способов решения проблем, возникающих при заказе, являются мобильные приложения, которые в удобном и понятном виде отображают всю необходимую информацию для каждой стороны.

1.2 Обзор существующих приложений в сфере оказания автомобильной помощи

В ходе работы проанализированы бесплатно распространяемые мобильные приложения для операционной системы Android, такие как «Эвакуатор» и «Все эвакуаторы Петербурга». Для каждого приложения показаны его характерные особенности и присущие ему недостатки. Приведены скриншоты работы для каждого приложения.



1.2.1 Приложение «Эвакуатор»

Данное приложение определяет ваше текущее местоположение и отображает список ближайших к вам операторов эвакуаторов, их номер телефона и расстояние между вами как показано на рисунке 1.1.

Рисунок 1.1 - Список ближайших операторов эвакуаторов

Недостатками данного приложения являются:

невозможно уточнить свое текущее местоположение на карте;

отсутствует возможность совершить заказ из приложения;

местоположение эвакуатора не отображается на карте;

отсутствует информация о ценовом тарифе.

1.2.2 Приложение «Все эвакуаторы Петербурга»

Данное приложение предоставляет список фирм как показано на рисунке 1.2, которые предоставляют услуги эвакуации автомобилей, с возможностью совершить звонок в фирму, чтобы заказать эвакуатор. Для каждой фирмы указан минимальный ценовой тариф при совершении заказа.



Рисунок 1.2 - Список фирм приложения «Все эвакуаторы Петербурга»

Особенностью приложения является функция расширенного поиска, отображенная на рисунке 1.3, которая позволяет указать район, в котором вы находитесь, и район, в который будет необходимо эвакуировать автомобиль, а также отметить обязательное наличие у эвакуатора крана-манипулятора.

Рисунок 1.3 - Расширенный поиск приложения «Все эвакуаторы Петербурга»

Недостатками данного приложения являются:

отсутствует возможность указать свое точное местоположение;

отсутствует возможность произвести заказ из приложения;

отсутствует информация о расстоянии до ближайшего эвакуатора для каждой фирмы;

местоположение эвакуатора при выполнении заказа не отображается на карте;

приложение отображает информацию только для одного города.



1.3 Выводы по главе

Рассмотренные приложения для вызова эвакуатора имеют общий недостаток. Этим недостатком является отсутствие связующего мобильного приложения для оператора эвакуатора, которое бы позволило ему получать заказы на эвакуацию и всю необходимую о заказе информацию, а также получать данные о его текущем местоположении для того, чтобы эти данные были переданы водителю сломанного автомобиля, который ожидает эвакуатор.

В связи с этим, принято решение разработать комплекс мобильных приложений, который бы позволил удобно взаимодействовать водителю сломанного автомобиля и оператору эвакуатора. Для этого сформулирована постановка задачи.

1.4 Постановка задачи

Проанализировав возможные аналоги в виде мобильных приложений, а также приложения из смежных областей, было выявлено, что каждый сервис реализован через клиент серверную систему и не имеет в своем распоряжении клиентского приложения для оператора эвакуатора. Все рассмотренные приложения не предоставляют расчет итоговой стоимости услуги эвакуации и не полностью автоматизируют процесс заказа.

Целью данной разработки является автоматизация процесса вызова эвакуатора, снижение денежных и временных затрат, путем предоставления наилучших предложений на рынке как по цене, так и по времени, а также уменьшение количества участников процесса и их взаимодействия между собой.

Для достижения поставленной цели, необходимо решение ряда следующих задач:

провести анализ рынка существующих приложений;

сформировать требования к программному средству;

изучить способы взаимодействия со службами геолокации;

выполнить алгоритмическое конструирование приложений;

построить схему взаимодействия между приложениями;

выполнить программное конструирование приложений;

разработать модули программного средства, реализующие функциональные характеристики приложений;

провести тестирование приложений на выполнение заказа с помощью эмулятора мобильного устройства.

2. Алгоритмическое конструирование комплекса мобильных приложений по оказанию автомобильной помощи на дорогах

В данном разделе рассматриваются такие алгоритмы как алгоритм авторизации пользователя, алгоритм заказа эвакуатора, алгоритм обновления информации о текущем местоположении, алгоритм получения заказа оператором эвакуатора. Приведено их описание и схема работы.

2.1 Алгоритм авторизации пользователя

В начале работы с приложением пользователь вводит свой номер телефона. При этом существует ряд проверок вводимого номера телефона. Допускается ввод номера, состоящего только из цифр.

Если пользователь использует приложение впервые, то ему будет предложено ввести свое имя, марку и цвет своего автомобиля, а также подтверждающий код из отправленного ему смс сообщения. После успешного ввода всех данных пользователь авторизуется в приложении. Если пользователь уже был зарегистрирован, то после ввода своего номера телефона ему нужно будет ввести только подтверждающий код из смс сообщения. После успешного ввода кода, пользователь авторизуется в приложении.

Подход с использованием одноразового смс кода для авторизации является более удобным для пользователя, ведь ему не нужно придумывать и запоминать логин и пароль. Логином по факту является его номер телефона, а пароль он получает на свой мобильный телефон каждый раз новый, что является достаточно надежным способом авторизации. Работа алгоритма представлена на рисунке 2.1.



Рисунок 2.1 - Алгоритм авторизации пользователя

2.2 Алгоритм заказа эвакуатора

Пользователь отправляет свое текущее местоположение на сервер. Сервер подбирает список фирм, в каждой из которой есть хотя бы один оператор эвакуатора готовый принять заказ, и отправляет их обратно клиенту. Пользователь выбирает фирму из списка и нажимает кнопку «заказать». После этого пользователь ожидает либо подтверждения заказа оператором эвакуатора, либо отмены заказа. При поступлении заказа, оператор эвакуатора получает уведомление в статусной строке своего мобильного устройства. Если оператор эвакуатора подтвердил заказ, то пользователю отображается на карте его текущее местоположение и текущее местоположение оператора эвакуатора. Если заказ был отменен оператором эвакуатора, то пользователю выводится сообщение об этом. Работа алгоритма представлена на рисунке 2.2.



Рисунок 2.2 - Алгоритм заказа эвакуатора

2.3 Алгоритм обновления информации о текущем местоположении

Приложение циклично через каждые 10 секунд запрашивает от службы геопозиционирования, которая предоставляет информацию о местоположении мобильного устройства, координаты его текущего местоположения. Координаты в данном случае представляют собой пару вещественных чисел. Первое число показывает значение широты, второе число значение долготы местоположения.

Затем, происходит проверка информации о предыдущих сохраненных координатах. Если предыдущие сохраненные координаты отсутствуют, то новые полученные координаты сохраняются как предыдущие и отправляются на сервер. Если предыдущие сохраненные координаты есть, то координаты сравниваются между собой. Сравнение координат между собой происходит по значениям широты и долготы. Если новые полученные координаты отличаются от предыдущих координат, то новые значения записываются в предыдущие и отправляются на сервер. Если не отличаются, то отправка координат на сервер не происходит.

Данный алгоритм используется для обновления информации на сервере о текущем местоположении оператора эвакуатора. При этом, алгоритм учитывает, что если оператор эвакуатора находится на одном месте, то постоянного обновления его местоположения на сервере не происходит, а происходит только в том случае, если оператор эвакуатора находиться в движении.

Такой подход позволяет отправлять на сервер только изменения в текущем местоположении оператора эвакуатора, а также обеспечивает меньшее количество отправляемых запросов на сервер и как следствие меньшую нагрузку на него. Работа алгоритмы представлена на рисунке 2.3.

Рисунок 2.3 - Алгоритм обновления информации о текущем местоположении

2.4 Алгоритм получения заказа оператором эвакуатора

Данный алгоритм позволяет оператору эвакуатора получать информацию о заказе. Работа алгоритма представлена на рисунке 2.4.



Рисунок 2.4 - Алгоритм получения заказа оператором эвакуатора

Оператор эвакуатора отправляет запрос на сервер об изменении своего текущего статуса на «готов работать» Затем каждые 4 секунды на сервер отправляется запрос о наличии заказа для данного оператора эвакуатора.

Если заказ есть, то отображается информация о заказе, на основе которой оператор эвакуатора принимает решение о подтверждении или отмене заказа. Если оператора эвакуатора принял заказ, то отправляется запрос на сервер, который изменяет его статус.

После этого происходит отображение маршрута до места назначения на карте. Если оператор эвакуатора отменил заказ, то об этом отправляется запрос на сервер и выводится сообщение о том, что заказ был отменен.

2.5 Выводы по главе

В данном разделе были обозначены основные вопросы, касающиеся алгоритмического конструирования комплекса мобильных приложений по оказанию автомобильной помощи на дорогах.

Разработанные алгоритмы позволят корректно реализовать программное средство, которое будет удовлетворять всем необходимым требованиям. Представлены основные механизмы и алгоритмы работы, реализация которых рассматривается в следующем разделе.



3. Программное конструирование комплекса мобильных приложений по оказанию автомобильной помощи на дорогах

В данном разделе проводится описание структуры программного средства, описание классов и методов классов, которые реализуют необходимый функционал.

3.1 Обоснование выбора языка и среды разработки

Разрабатываемое программное средство является мобильными приложениями для операционной системы Android. Для написания удобных в использовании приложений, обладающих плавным интерфейсом, для данной операционной системы был выбран язык программирования Java [1].

Java - объектно-ориентированный язык программирования, разработанный компанией Sun MicroSystems. Язык Java подходит для широкого круга задач таких как создание веб-приложений, графических пользовательских приложений, игр и многого другого [2]. Java обладает большой стандартной библиотекой, обеспечивающей функциональность от стандартного ввода/вывода и сетевых протоколов до графических пользовательских интерфейсов. Также активно используется для создания мобильных приложений под операционную систему Android [3]. При этом программы компилируются в нестандартный байт-код, для использования их виртуальной машиной Dalvik (начиная с Android 5.0 Lollipop виртуальная машина заменена на ART) [4]. Для такой компиляции используется дополнительный инструмент, а именно Android SDK.

Для написания приложений для операционной системы Android была выбрана интегрированная среда разработки Android Studio. Android Studio, основанная на программном обеспечении IntelliJ IDEA от компании JetBrains является официальным средством разработки Android приложений [5].

Android Studio обладает рядом удобных в использовании функций, таких как [6]:

расширенный редактор макетов;

способность работать с UI компонентами при помощи Drag-and-Drop;

рефакторинг кода;

cтатический анализатор кода, позволяющий находить проблемы производительности, несовместимости версий и другое;

шаблоны основных макетов и компонентов Android.

В данной работе также использованы библиотека Maps Android API для работы с картографическим сервисом Google Maps и библиотек Retrofit 2 для создания и отправки запросов на сервер [7].

3.2 Классы приложения для водителя автомобиля

3.2.1 Класс NavigationDrawerActivity

Данные класс отвечает за отображение выдвигающегося бокового меню приложения.

Поля класса NavigationDrawerActivity представлены в таблице 3.1

Таблица 3.1 - Поля класса NavigationDrawerActivity

Название	Тип	Описание
fragmentTransaction	FragmentTransaction	Используется для выполнения транзакций фрагментов
isMapAttached	boolean	Хранит состояние карты
active	boolean	Хранит состояние активити
sharedPreferences	SharedPreferences	Используется для изменения настроек приложения
notifiationManager	NotifiationManager	Используется для работы с уведомлениями в строке состояния

Методы класса NavigationDrawerActivity представлены в таблице 3.2.



Таблица 3.2 - Методы класса NavigationDrawerActivity

Название	Входные параметры	Возвращаемое значение	Описание
onNavigationItemSelected	MenuItem item	boolean	Срабатывает при выборе пункта меню
changeUI	Без параметров	void	Меняет отображаемый экран, если GPS модуль выключен
exit	Без параметров	void	Выход из аккаунта

3.2.2 Класс CompaniesAdapter

Данный класс отвечает за связывание данных с интерфейсом для отображения списка компаний, которые могут принять заказ.

Поля класса CompaniesAdapter представлены в таблице 3.3.

Таблица 3.3 - Поля класса CompaniesAdapter

Название	Тип	Описание
items	List<Companies>	Список моделей компаний
context	Context	Контекст активити
sharedPreferences	SharedPreferences	Используется для изменений настроек приложения
broadcastReceiver	BroadcastReceiver	Обработчик событий для списка

Методы класса CompaniesAdapter представлены в таблице 3.4.

Таблица 3.4 - Методы класса CompaniesAdapter

Название	Входные параметры	Возвращаемое значение	Описание
onReceive	Context context, Intent intent	void	Обрабатывает события для списка
onCreateViewHolder	ViewGroup parent, int viewType	ViewHolder	Связывает элементы интерфейса с данным
onBindViewHolder	ViewHolder holder, int position	void	Заполняет данными каждый элемент списка



3.2.3 Класс MainMapFragment

Данный класс отвечает за работу с отображаемой картой. Является наследником класса Fragment. Реализует всю логику работы с геолокацией и определение текущего местоположения, отрисовку объектов на карте и изменение положения камеры карты [8].

Поля класса MianMapFragment представлены в таблице 3.5.

Таблица 3.5 - Поля класса MainMapFragment

Название	Тип	Описание
map	GoogleMap	Ссылка на объект отображаемой карты
googleApiClient	GoogleApiClient	Объект настрое для взаимодействия с Play Services
locationRequest	LocationRequest	Объект настроек информации о местоположении
isLocated	boolean	Хранит состояние местоположения пользователя
find_me_BTN	ImageButton	Кнопка по определению текущего местоположения
fragmentTransaction	FragmentTransaction	Используется для выполнения транзакций фрагментов
sharedPreferences	SharedPreferences	Используется для изменения настроек приложения
client	Client	Ссылка на объект Clinet, который хранит информацию о клиенте
worker	Worker	Ссылка на объект Worker, который хранит информацию об операторе эвакуатора
zoom	float	Уровень зума камеры карты
broadcastReceiver	BroadcastReceiver	Обработчик событий для карты

Методы класса MainMapFragment представлены в таблице 3.6.

Таблица 3.6 - Методы класса MainMapFragment

Название	Входные параметры	Возвращаемое значение	Описание
onMapReady	GoogleMap googleMap	void	Вызывается при полной загрузке карты
checkPermission	Без параметров	boolean	Проверяет разрешения для работы с геолокацией
checkPlayServices	Без параметров	boolean	Проверяет доступны ли Play Services на устройстве
createLocationRequest	Без параметров	void	Задает настройки работы с данными о местоположении
startLocationUpdates	Без параметров	void	Запускает сервис по получению информации о текущем местоположении
stopLocationUpdates	Без параметров	void	Останавливает сервис по получению информации о местоположении
getMyLocation	Без параметров	Location	Возвращает текущее местоположение
moveCameraToMyLocation	Без параметров	void	Перемещает камеру карты к текущему местоположению
showWorkerPosition	Без параметров	void	Отображает текущую позицию оператора эвакуатора
showOrderLocation	Без параметров	void	Отображает текущую позицию оператора эвакуатора во время выполнения заказа
onLocationChanged	Location location	void	Вызывается при изменении текущего местоположения
onReceive	Context context, Intent intent	void	Обрабатывает события для карты

3.2.4 Класс CheckOrderStatusService

Данный класс предназначен для проверки статуса заказа в фоновом режиме. В зависимости от статуса заказа, создается то или иное событие для карты.

Поля класса CheckOrderStatusService представлены в таблице 3.7.

Таблица 3.7 - Поля класса CheckOrderStatusService

Название	Тип	Описание
timer	Timer	Используется для цикличного выполнения задачи TimerTask
timerTask	TimerTask	Задает задачу для цикличного выполнения
worker	Worker	Ссылка на объект, который хранит информацию о операторе эвакуатора
api_key	String	Ключ запросов на сервер
order_id	int	Номер заказа, чей статус проверяется
sharedPreferences	SharedPreferences	Используется для изменения настроек приложения
notificationManager	NotificationManager	Используется для отправки уведомлений в строку состояния

Методы класса CheckOrderStatusService представлены в таблице 3.8.



Таблица 3.8 - Методы класса CheckOrderStatusService

Название	Входные параметры	Возвращаемое значение	Описание
onCreate	Без параметров	void	Вызывается при создании сервиса и инициализирует все поля класса
onStartCommand	Intent intent, int flags, int startId	int	Вызывается при запуске сервиса
Run	Без параметров	void	Метод по проверке статуса заказа

3.2.5 Класс CreateOrderAsync

Данный класс отвечает за асинхронный запрос на создание заказа.

Поля класса CreateOrderAsync представлены в таблице 3.9

Таблица 3.9 - Поля класса CreateOrderAsync

Название	Тип	Описание
client	Client	Ссылка на объект, который хранит информацию о водителе
worker	Worker	Хранит информацию об операторе эвакуатора
context	Context	Контекст активити
api_ley	String	Ключ для запросов на сервер

Методы класс представлены в таблице 3.10.

Таблица 3.10 - Методы класса CreateOrderAsync

Название	Входные параметры	Возвращаемое значение	Описание
onPreExecute	Без параметров	void	Выполняет настройку элемента интерфейса progressDialog
doInBackground	Без параметров	Response<OrderData>	Выполняет запрос на сервер в отдельном потоке
onPostExecute	Response<OrderData> resultResponse	void	Обрабатывает ответ от сервера

3.2.6 Класс GetCompaniesAsync

Данный класс отвечает за асинхронный запрос по получению списка компаний, предоставляющих услуги эвакуации автомобилей.

Поля класса GetCompaniesAsync представлены в таблице 3.11.

Таблица 3.11 - Поля класса GetCompaniesAsync

Название	Тип	Описание
context	Context	Контекст активити
api_key	String	Ключ для запроса на сервер
car_type	int	Тип автомобиля водителя
client	Client	Ссылка на объект, который хранит информацию о водителе

Методы класса GetCompaniesAsync представлены в таблице 3.12.

Таблица 3.12 - Методы класса GetCompaniesAsync

Название	Входные параметры	Возвращаемое значение	Описание
onPreExecute	Без параметров	void	Выполняет настройку элемента progressDialog
doInBackground	Без параметров	Response<List<Companies>>	Выполняет запрос на сервер в отдельном потоке
onPostExecute	Response<List<Companies>> resultResponse	void	Обрабатывает ответ от сервера

3.3 Классы приложения для оператора эвакуатора

3.3.1 Класс MainMapFragment

Данный класс отвечает за работу с отображаемой картой. Является наследником класса Fragment. Реализует всю логику работы с геолокацией и определение текущего местоположения, отрисовку объектов на карте и изменение положения камеры карты.

Поля класса MainMapFragment представлены в таблице 3.13.

Таблица 3.13 - Поля класса MainMapFragment

Название	Тип	Описание
map	GoogleMap	Ссылка на объект отображаемой карты
googleApiClient	GoogleApiClient	Объект настроr для взаимодействия с Play Services
locationRequest	LocationRequest	Объект настроек информации о местоположении
isLocated	boolean	Хранит статус местоположения
find_me_BTN	ImageButton	Кнопка по определению текущего местоположения
fragmentTransaction	FragmentTransaction	Используется для выполнения транзакций фрагментов
sharedPreferences	SharedPreferences	Используется для изменения настроек приложения
zoom	float	Уровень зума камеры карты
broadcastReceiver	BroadcastReceiver	Обработчик событий для карты
order	Order	Хранит информацию о заказе
myLocation	MyLocation	Хранит информацию о местоположении оператора эвакуатора
polylines	List<Polyline>	Список линий для отрисовки маршрута

Методы класса MainMapFragment представлены в таблице 3.14.

Таблица 3.14 - Методы класса MainMapFragment

Название	Входные параметры	Возвращаемое значение	Описание
onMapReady	GoogleMap googleMap	void	Вызывается при полной загрузке карты
checkPermission	Без параметров	boolean	Проверяет разрешения для работы с геолокацией
checkPlayServices	Без параметров	boolean	Проверяет доступны ли Play Services на устройстве
createLocationRequest	Без параметров	void	Задает настройки работы с данными о местоположении
startLocationUpdates	Без параметров	void	Запускает сервис для работы геолокации
stopLocationUpdates	Без параметров	void	Останавливает сервис для работы геолокации
getMyLocation()	Без параметров	Location	Возвращает текущее местоположение
moveCameraToMe	boolean flag	void	Перемещает камеру к текущему местоположению на карте
DrawRoute	boolean flag	void	Рисует маршрут заказа на карте
onLocationChanged	Location location	void	Вызывается при изменении местоположения
onReceive	Context context, Intent intent	void	Обрабатывает события для карты



3.3.2 Класс GetOrderServivce

Данный класс реализует сервис для получения заказа в фоновом режиме. Является наследником базового класса Service [9].

Поля класса GetOrderService представлены в таблице 3.15.

Таблица 3.15 - Поля класса GetOrderService

Название	Тип	Описание
timer	Timer	Используется для цикличного выполнения задачи TimerTask
timerTask	TimerTask	Задает задачу для цикличного выполнения
sharedPreferences	SharedPreferences	Используется для изменения настроек приложения
api_key	String	Ключ запросов на сервер
notificationManager	NotificationManager	Используется для отправки уведомлений в строку состояния
order	Order	Объект, который хранит информацию о заказе

Методы класса GetOrderService представлены в таблице 3.16.

Таблица 3.16 - Методы класса GetOrderService

Название	Входные параметры	Возвращаемое значение	Описание
onCreate	Без параметров	void	Вызывается при создании сервиса и инициализирует все поля класса
onStartCommand	Intent intent, int flags, int startId	int	Вызывается при запуске сервиса
Run	Без параметров	void	Метод для получения заказа с сервера

3.3.3 Класс NavigationDrawerActivity

Данный класс отвечает за отображение выдвигающегося бокового меню приложения.

Поля класса NavigationDrawerActivity представлены в таблице 3.17

Таблица 3.17 - Поля класса NavigationDrawerActivity

Название	Тип	Описание
fragmentTransaction	FragmentTransaction	Используется для выполнения транзакций фрагментов
isMapAttached	boolean	Хранит состояние карты
active	boolean	Хранит состояние активити
notificationManager	NotificationManager	Используется для управления уведомлением в статусной строке

Методы класса NavigationDrawerActivity представлены в таблице 3.18.

Таблица 3.18 - Методы класса NavigationDrawerActivity

Название	Входные параметры	Возвращаемое значение	Описание
onNavigationItemSelected	MenuItem item	boolean	Вызывается, когда пользователь выбирает элемент меню
changeUI	Без параметров	void	Меняет отображаемый экран, если GPS модуль выключен
exit	Без параметров	void	Выполняет выход из учетной записи пользователя

3.3.4 Класс MyLocation

Данный класс реализует паттерн проектирования singleton. Предназначен для хранения информации о текущем местоположении и статусе координат.

Поля класса MyLocation представлены в таблице 3.19.

Таблица 3.19 - Поля класса MyLocation

Название	Тип	Описание
latitude	double	Значение широты текущего местоположения
longitude	double	Значение долготы текущего местоположения
isNew	boolean	Статус текущих координат

Методы класса MyLocation представлены в таблице 3.20.

Таблица 3.20 - Методы класса MyLocation

Название	Входные параметры	Возвращаемое значение	Описание
getLatitude	Без параметров	double	Возвращает широту
getLongitude	Без параметров	double	Возвращает долготу
isNew	Без параметров	boolean	Возвращает статус

3.4 UML - диаграмма классов приложения для водителя автомобиля

UML - диаграмма классов приложения для водителя автомобиля представлена на рисунке 3.1.

Рисунок 3.1 - UML - диаграмма классов приложения для водителя автомобиля

3.5 UML - диаграмма классов приложения для оператора эвакуатора

UML - диаграмма классов приложения для оператора эвакуатора представлена на рисунке 3.2.



Рисунок 3.2 - UML - диаграмма классов приложения для оператора эвакуатора

3.6 Выводы по главе

В данном разделе были описаны классы для каждого мобильного приложения. Их основные поля и методы, благодаря которым реализуется корректная работа приложений и обработка разных сценарий использования.



4. Тестирование работы комплекса мобильных приложений по оказанию автомобильной помощи на дорогах

Для запуска приложений необходимы мобильные устройства с операционной системой Android 4.4.4 или выше. Тестирование приложений осуществлено на эмуляторах таких устройств с возможностью самостоятельно изменять информацию о текущем местоположении.

4.1 Тестирование авторизации в приложении для водителя

Запустив приложение первый раз, пользователь увидит начальный экран, предлагающий ему начать использование приложения. Для этого ему необходимо ввести номер своего телефона как показано на рисунке Б.1.

После того, как пользователь введет свой номер телефона перед ним в зависимости от того, был ли он зарегистрирован в приложении ранее или нет отобразится форма регистрации, представленная на рисунке Б.2 или форма для входа.

После того, как пользователь корректно ввел все необходимые данные, выполняется вход в приложение и отображается карта, отображающая его текущее местоположение и кнопка для поиска эвакуатора, как показано на рисунке Б.3.

Если пользователь ввел некорректные данные или оставил хотя бы одно поле не заполненным, то ему высветиться уведомление как показано на рисунке Б.4 о том, что для авторизации необходимо заполнить все поля.

4.2 Тестирование выполнения заказа

Первоначальным этапом формирования заказа является выбор водителем категории его автомобиля и указание его марки и цвета как показано на рисунке Б.5. Затем, нажав кнопку «найти эвакуатора», водителю предоставляется список фирм, показанный на рисунке Б.6, с информацией о ценовом тарифе, рейтингом фирмы и временем прибытия ближайшего эвакуатора от данной фирмы. Нажав кнопку «заказать», водитель будет ожидать подтверждения заказа от оператора эвакуатора как показано на рисунке Б.7.

Для того, чтобы оператор эвакуатора мог получать заказы, ему необходимо нажать кнопку «начать работать», чтобы его статус изменился на сервере как показано на рисунке Б.8.

После того, как для оператора эвакуатора появился заказ, ему высвечивает информация о заказе такая как дистанция до заказа, марка и цвет автомобиля. У оператора эвакуатора есть возможность принять заказ или отказаться от него, что продемонстрированно на рисунке Б.9.

Приняв заказ, оператору эвакуатора отображается метка и маршрут до водителя сломанного автомобиля как показано на рисунке Б.10. В этот момент водителю сломанного автомобиля отображается карта, которая изображена на рисунке Б.11, с меткой текущего местоположения оператора эвакуатора.

Прибыв на место назначения, оператор эвакуатора начинает непосредственное выполнение эвакуации автомобиля. На данном этапе ему предоставляется возможность завершить заказ по требованию водителя сломанного автомобиля как показано на рисунке Б.12.

После завершения заказа, водителю сломанного автомобиля предоставляется информация о заказе, в которую входит расстояние сумма заказа, а также предоставляется возможность оценить заказ как показано на рисунке Б.13.

Полностью завершив заказ, водителю сломанного автомобиля и оператору эвакуатора отображается их текущее местоположение, при этом оператор эвакуатора снова готов принимать заказы.



4.3 Выводы по главе

В данном разделе были протестированы основные функции комплекса мобильных приложений по оказанию автомобильной помощи на дорогах. Протестирована функция авторизации в приложении для водителя автомобиля, которая позволяет выполнить в зависимости от того, зарегистрирован водитель в приложении или нет, регистрацию или вход в приложение.

Протестированы функции формирования и отслеживания выполнения заказа для приложения водителя автомобиля. Протестированы функции получения и выполнения заказа для приложения оператора эвакуатора. Представлены рисунки выполнения основных этапов заказа. Приведен пример обработки одной из ошибочных ситуаций, которая может возникнуть при использовании приложения для водителя автомобиля.

На основании данных тестов, можно сделать вывод о том, что данный комплекс мобильных приложений корректно выполняет все заявленные функции.

5. Экономическое обоснование работы

5.1 Основные аспекты реализации работы

Целью выпускной квалификационной работы является создание информационной системы (ИС) - комплекса мобильных приложений по оказанию автомобильной помощи на дорогах. Функциональное назначение заключается в предоставлении мобильных приложений для осуществления взаимодействия между клиентом и исполнителем при оказании услуги эвакуирования автотранспортного средства.

В данной главе выполняются организационно-экономические расчеты, включающие в себя следующие разделы:

оценка потенциальной социально-экономической результативности;

планирование разработки с использованием сетевого трафика;

определение трудоемкости выполнения работ и затрат;

стратегический маркетинговый анализ целесообразности введения;

расчет плановой себестоимости разработки ИС;

определение экономической эффективности создания ИС.

5.2 Оценка потенциальной социально-экономической результативности внедрения разработки

Для оценки целесообразности внедрения разработки необходимо определить ее потенциальную социально-экономическую результативность.

Оценка потенциальной социально-экономической результативности производится с помощью коэффициента, рассчитываемого по формуле:



где КСЭ - коэффициент потенциальной социально-экономической результативности; Кзнi - коэффициент значимости i-го фактора, используемого для оценки; Кдуi - коэффициент достигнутого уровня i-го фактора; m - количество факторов социально-экономической результативности.

По каждому из факторов экспертным путем устанавливаются значения коэффициентов значимости и достигнутого уровня по данному фактору. Сумма коэффициентов значимости должна быть равна 1,0. Чем ближе КСЭ к 1,0, тем выше потенциальная социально-экономическая результативность внедрения разработки. Экономический эффект характеризуется выраженной в стоимостных показателях экономией различных видов затрат, полученной при использовании результатов разработки. Оценка социального эффекта носит прогнозный характер. Оценка потенциальной социально-экономической результативности представлена в таблице Б1.

Рассчитаем коэффициенты для оценки социально-экономической результативности:

Приведенные расчеты показали перспективность проводимой разработки. Полученное значение коэффициента социально-экономической результативности позволяет утверждать, что данная разработка теоретически может повлиять на деятельность организации.

5.3 Планирование разработки с использованием сетевого графика

Планирование работ с применением сетевого метода ведется в следующем порядке: составляется перечень событий и работ, строится сетевой график проекта, определяется продолжительность работ (tож), рассчитываются параметра сетевого графика, определяется продолжительность критического пути.

В перечне событий и работ указывают кодовые номера событий и их наименование, в последовательности от исходного события к завершающему, при расположении кодовых номеров и наименований работ перечисляются все работы, имеющие общее начальное событие. Исходные данные для расчетов получают методом экспертных оценок. Для работ, время выполнения которых неизвестно, исполнитель или другие специалисты, привлекаемые в качестве экспертов, дают в соответствии с принятой системой три вероятностные оценки продолжительности: tmin - минимальную, tmax - максимальную, tнв - наиболее вероятную или только первые две.

Свободный резерв показывает максимальное время, на которое можно увеличить продолжительность данной работы или изменить ее начало, не меняя ранних сроков начала последующих работ. В соответствии с вышеизложенной методикой проведем планирование разработки. Перечень событий и работ по каждому этапу приводятся в таблице В.2. Результаты экспертных оценок и расчетные величины трудоемкости этапов проведения работ приведены в таблице В.3. Перечень событий и работ приведен в таблице В.4.

На основании перечня событий и работ построен сетевой график работ, отображенный на рисунке 5.1.

Рисунок 5.1 - Сетевой график работ по разработке ИС

Кружки на графике обозначают события, стрелки - работы, номер над стрелкой - время, необходимое для выполнения данной работы. Параметры событий сетевого графика представлены в таблице В.5.

Каждый кружок, изображающий событие, делится на четыре сектора. В верхнем секторе располагается номер события, в левом секторе - ранний срок наступления события, в правом секторе - поздний срок окончания события. В верхнем секторе располагается резерв времени наступления события.

Продолжительность критического пути определяется после нахождения срока раннего начала работ и раннего окончания работ, которые ведут к завершающему событию. Найденная величина заносится в графу позднего срока окончания работ для всех работ, ведущих к завершающему событию. Параметры работ сетевого графика отображены в таблице В.6.

Сократить продолжительность критического пути можно перераспределением ресурсов между работами сетевой модели, состоящим в том, что часть ресурсов (рабочая сила) снимается с работ, не принадлежащих критическому пути и имеющих большие резервы времени, и распределяется на работы критического пути, сокращая их продолжительность.

В целях оптимизации возможно также привлечение сторонних специалистов для сокращения времени разработки. При текущем состоянии не требуется проведение оптимизации.

5.4 Стратегический маркетинговый анализ целесообразности внедрения

Для определения целесообразности применения ИС с позиций стратегического маркетинга необходимо провести SWOT и PEST анализы.

SWOT - метод анализа в стратегическом планировании, заключающийся в разделении факторов и явлений на четыре категории: сильные стороны, слабые стороны, возможности и угрозы [10]. В таблице В.7 представлен SWOT-анализ возможности внедрения.

Для оптимального представления результатов SWOT-анализа определяется взвешенная балльная оценка факторов SWOT, позволяющая количественно оценить значения элементов SWOT.

В результате проведенного SWOT-анализа было выявлено, что угрозы имеют достаточно весомое значение, поэтому можно считать необходимым создание в перспективе на основе ИС более универсального средства решения поставленной задачи. Сильные стороны и возможности имеют достаточно хорошее значение, что может давать некоторую гарантию успешного внедрения ИС для решения специальных задач. В таблице В.8 представлены взвешенная бальная оценка факторов SWOT.

PEST-анализ - это маркетинговый инструмент, предназначенный для выявления политических, экономических, социальных и технологических аспектов внешней среды, которые влияют на использование ИС [11].

Естественно, что внешняя среда многочисленна, разнообразна и неоднородна по своему составу. Почти все её компоненты влияют на компанию, разница только в степени, характере и периодичности их влияния. Поэтому все внешние факторы требуют пристального и регулярного изучения.

В целях определения степени влияния PEST-факторов на процесс внедрения, составляется матрица влияния факторов и ответной реакции на них, что представлено в таблице В.9.

В результате проведенного PEST-анализа было определено, что влияние экономических, социокультурных и технологических факторов в данном конкретном случае должно положительно влиять на результат внедрения ИС в организации.

В результате проведения стратегического маркетингового анализа целесообразности применения информационной системы, были получены результаты SWOT и PEST анализа. Таким образом, выявлено, что одним из важных факторов успешного внедрения ИС является наличие значительного числа сильных сторон и открывающихся возможностей для организации и практически отсутствие слабых. Кроме того, определено, что такие факторы, как политические, экономические, социокультурные и технологические - способны оказать благотворное влияние на организацию при внедрении информационной системы.

5.5 Определение себестоимости разработки

Плановая себестоимость определяется по следующим статьям расходов: материальные затраты; основная заработная плата исполнителя и руководителя; дополнительная заработная плата; страховые взносы в государственные внебюджетные фонды; накладные расходы. Смета затрат на материалы представлена в таблице В.10.

К статье «Основная заработная плата исполнителя и руководителя» относятся основная заработная плата работников, а также премии, входящие в фонд заработной платы. Расчет основной заработной платы выполняется на основе трудоемкости выполнения каждого этапа в человеко-часах и величине месячного должностного оклада исполнителя. Примем количество рабочих дней в месяце равным 22-м. Следовательно, заработная плата определяется делением размера оклада на количество рабочих дней в месяце с учетом восьмичасового рабочего дня. Расчет основной заработной платы приведен в таблице В.11.

Дополнительная заработная плата (Зд) определяется исходя из их основной заработной платы и норматива доплат (Нд) в процентах от основной заработной платы. Дополнительная заработная плата включает выплаты, предусмотренные законодательством о труде за неотработанное по уважительным причинам время: оплата очередных и дополнительных отпусков и т. п. (принимаем в размере 10% от суммы основной заработной платы). Расчет ведется по формуле:

Зд = Зо (Нд / 100%),

Зд = 63 000 * 0,1 = 6 300 (руб.).

Затраты по статье «Страховые взносы в государственные внебюджетные фонды» определяются в процентном отношении от суммы основной и дополнительной заработной платы (30%):

СВ = (63 000 + 6 300) * 0,3 = 20 790 (руб.).

К статье «Накладные расходы» относят расходы по содержанию зданий, оборудованию и другие. Накладные расходы составляют 50% от суммы основной заработной платы.

НР = 63 000 * 0,5 = 31 500 (руб.).

Калькуляция стоимости разработки приведена в таблице Б.12.

Экономическая эффективность ожидаемого внедрения любой разработки может оцениваться условно-годовой экономией от уменьшения управленческих расходов, а также сроком окупаемости капитальных вложений и другими показателями эффективности.

В настоящей работе рассчитать стоимостное выражение экономической эффективности разработки затруднительно, поскольку отсутствует объект внедрения.

5.6 Выводы по главе

В данном разделе были рассмотрены основные аспекты реализации работы. Представлена оценка потенциальной социально-экономической результативности внедрения разработки. Произведено планирование с использованием сетевого трафика. Определена себестоимость разработки.

6. Безопасность и экологичность работы

Рабочая деятельность программистов характеризуется значительным умственным напряжением, нервно-эмоциональной нагрузкой, высокой напряженностью зрительной работы и достаточно большой нагрузкой на мышцы рук при работе с клавиатурой ЭВМ. Также при работе за компьютером человек подвергается воздействию ряда опасных и вредных производственных факторов: электромагнитных полей, инфракрасного и ионизирующего излучений, шума и вибрации, статического электричества и прочее.

6.1 Анализ опасных и вредных производственных факторов

Рабочим местом является комната с длиной 6 м, шириной 4 м и высотой 3,5 м, в которой находится 7 рабочих мест, укомплектованные персональными компьютерами и принтером. План расположения оргтехники в комнате представлен на рисунке 6.1.

Рисунок 6.1 - План расположения оргтехники

6.1.1 Микроклимат

Микроклиматом называют совокупность факторов, характеризующих окружающие работника атмосферные условия. Для высокого уровня работоспособности микроклиматические условия должны обеспечивать ощущение теплового комфорта в течение рабочего дня.

Работа программиста по уровню энергозатрат относится к категории Iа (легкая). Разработка программного средства производится в теплое время года, поэтому допустимые величины показателей микроклимата должны быть следующие [12]:

температура воздуха 22,9-25,1°С;

температура поверхностей 20,0-29,0;

относительная влажность воздуха 15-75%.

Данные условия в офисе соблюдаются.

6.1.2 Производственное освещение

Рациональное освещение рабочего места является одним из важнейших факторов, влияющих на эффективность трудовой деятельности человека, предупреждающих травматизм и профессиональные заболевания. Правильно организованное освещение создает благоприятные условия труда, повышает работоспособность и производительность труда, снижает риски возникновения различных заболеваний глаз и возникновения быстрой утомляемости.

Вопрос освещенности рабочих мест, оборудованных персональными компьютерами (ПЭВМ) коротко, но очень четко изложен в СНиП 23-05-95 "Естественное и искусственное освещение" [13].

Показатели освещения в офисах представлены в таблице 6.1.

Таблица 6.1 - Нормы освещенности офисных помещений

Вид помещения	Норма освещенности согласно СНиП, Лк
Офис общего назначения с использованием компьютеров	200-300
Офис большой площади со свободной планировкой	400
Офис, в котором осуществляются чертежные работы	500
Архив	75

Рассматриваемая комната относится к офису общего назначения с использованием компьютеров. Применяется система комбинированного освещения в комнате. Схема освещения представлена на рисунке 6.2.

Рисунок 6.2 - Схема освещения

6.1.3 Защита от шума и вибраций

По своей физической сущности, шум - это звук. Шум может вызывать неприятные ощущения, однако решающую роль в оценке «неприятности» шума играет субъективное отношение человека к этому раздражителю.

На рабочем месте разработчика программного средства источниками шума являются персональные компьютеры и многофункциональные устройства.

Многофункциональные устройства используются по мере необходимости в течение рабочего дня. Шум от таких устройств - механический и непостоянный прерывистый.