Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Разработка системы для автоматизации бизнес-процессов компании, оказывающей услуги выездной автомойки

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

Анализ существующих решений по оказанию услуг выездной автомойки. Расчет стоимости и сроки разработки информационной системы компании, оказывающей услуги выездной автомойки. Инструменты и технологии разработки системы. Тестирование созданной системы.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 03.09.2018
Размер файла 2,0 M
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

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

Оглавление

    • Введение
  • Глава 1. Аналитический обзор
    • 1.1 Мобильное приложение как инструмент для бизнеса
    • 1.2 Анализ существующих решений
    • 1.3 Постановка задачи
    • 1.4 Технико-экономическое обоснование
  • Глава 2. Проектирование системы
    • 2.1 Сценарии использования
    • 2.2 Диаграммы последовательности
    • 2.3 Диаграмма базы данных
    • 2.4 Алгоритм приема заказа
    • 2.5 Выбор инструментов и технологий реализации
  • Глава 3. Разработка системы
    • 3.1 Серверное приложение
  • 3.1.1 Настройка файла конфигурации
  • 3.1.2 Создание классов из модели данных
  • 3.1.3 Реализация функций
    • 3.2 Android-приложение для заказа услуг
    • 3.3 Android-приложение для автомойщиков
  • Глава 4. Тестирование системы
    • 4.1 Тестирование серверного приложения
    • 4.2 Функциональное тестирование приложения для заказа услуг
    • 4.3 Функциональное тестирование приложения для автомойщиков
  • Заключение
  • Библиографический список

Введение

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

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

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

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

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

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

1. Провести анализ бизнес-процессов компании.

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

3. Определить требования к разрабатываемой системе. Разработать техническое задание.

4. Рассчитать стоимость и сроки разработки информационной системы. Выполнить технико-экономическое обоснование разработки системы.

5. Выполнить проектирование системы. Выбрать инструменты и технологии разработки системы.

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

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

Методы исследования:

1. Сравнительный анализ существующих решений по оказанию услуг выездной автомойки.

2. Синтез требований к разрабатываемой системе.

3. Сравнительный анализ инструментов и технологий разработки.

4. Моделирование бизнес-процессов выездной автомойки и системы для их автоматизации.

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

1.1 Мобильное приложение как инструмент для бизнеса

автоматизация информационный бизнес автомойка

Автомойка выездного типа отличается от стационарной тем, что не имеет постоянного адреса, куда клиент должен приехать для мойки автомобиля. Это возможно благодаря другому способу мойки, без шлангов и воды. Работники выездной мойки используют специальное моющее средство. Сначала оно распыляется на кузов автомобиля, чтобы размягчить засохшую грязь. Затем тряпкой из микрофибры грязь стирается с кузова автомобиля. То есть для мойки автомобиля необходимы только моющее средство и несколько тряпок. Всё это помещается в рюкзак или багажник автомобиля, что позволяет работникам быть мобильными и мыть автомобиль в любом месте. Бывают исключения, когда мойка производится таким способом стационарно по постоянному адресу, но это является лишь дополнением к основной выездной деятельности. Процесс работы компании при поступлении заказа изображен на диаграмме (рис. 1.1), составленной согласно Business Process Model and Notation.

Рисунок 1.1. Диаграмма бизнес-процесса «Прием заказа»

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

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

После согласования с клиентом времени заказа оператор должен передать информацию о заказе назначенному автомойщику. Эта задача может быть выполнена как с помощью SMS-сообщений, так и через мобильные мессенджеры, например, Telegram, WhatsApp, Viber и другие. Но далее работа с этим сообщением для автомойщика неудобна, так как необходимо перенести адрес заказа на карту или в навигатор и запланировать маршрут, полагаясь на собственное чутье или сторонние приложения. При этом желательно выбрать оптимальный путь, чтобы избежать пробок и сэкономить топливо. А по приезде на место заказа нужно снова открыть сообщение от оператора, чтобы посмотреть информацию о машине, которую нужно вымыть. Мобильное приложение для работников автомойки должно объединить карту, на которой показан оптимальный маршрут до заказа, и информацию обо всех назначенных заказах. Таким образом, автомойщику не придется тратить время на использование сторонних приложений.

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

1. Клиентское приложение для заказа услуг должно:

1.1. Определять местоположение клиента и отображать его на карте.

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

1.3. Запросить у клиента ввод государственного регистрационного номера, марки, модели автомобиля; выбор вида услуги, точного времени или временного диапазона для выполнения мойки.

1.4. Предоставлять информацию о видах и стоимости услуг.

2. Приложение автомойщика должно:

2.1. Определять местоположение работника и отображать его на карте.

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

2.3. Отображать на карте местоположение следующего заказа.

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

3. Серверное приложение должно:

3.1. Принимать от клиентского приложения информацию о заказе.

3.2. Проверять возможность оказания услуги в указанном клиентом месте и в указанное время и возвращать результат клиентскому приложению.

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

3.4. Передавать назначенному специалисту информацию о заказе.

1.2 Анализ существующих решений

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

1. «Fast and Shine» - приложение одноименной международной компании, оказывающей услуги выездной автомойки. Данная компания расширяется с помощью франчайзинга, но в Перми она не имеет партнеров.

2. «Digital Moika» - приложение одноименной компании из Ростова-на-Дону, которая так же оказывает услуги выездной автомойки.

3. «Green Steams» - приложение американской компании, оказывающей услуги выездной автомойки.

4. «Spunje» - приложение американской компании, оказывающей услуги выездной автомойки.

5. «WashMap» - международное приложение-агрегатор для поиска свободной стационарной автомойки.

6. «Автомойки онлайн» - российское приложение-агрегатор для поиска свободной стационарной автомойки.

7. «АвтомойкиРУ» - международное приложение-агрегатор для поиска свободной стационарной автомойки.

8. «Вебмойка» - международное приложение-агрегатор для поиска свободной стационарной автомойки.

9. «Где мойка?» - российское приложение-агрегатор для поиска свободной стационарной автомойки.

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

Благодаря анализу (см. прил. А) подтвердилась необходимость реализации функций, перечисленных в начальных требованиях к системе. Более того, примеры реализации этих требований в существующих приложениях были рассмотрены и оценены с точки зрения удобства и эффективности. Например, к неудобной реализации относится необходимость пользователю полностью вводить марку и модель автомобиля в приложении «Digital Moika». Это неудобно, долго и при этом высока вероятность ошибки. Удобная реализация: предложить пользователю выбрать марку и модель автомобиля из списка. Также неудачным является требование к пользователю выбрать класс автомобиля (см. рис. 1.2), так как границы предложенных классов довольно условны и некоторые автомобили нельзя однозначно отнести к одному классу. Удачная реализация: не требовать этого от пользователя, а на основе выбранной марки и модели определять класс автомобиля.

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

Рисунок 1.2. Скриншот приложения «Автомойки онлайн»: выбор класса автомобиля

Еще одно удобное решение было замечено в приложении «Вебмойка». В нем для каждой услуги указанно время ее выполнения (см. рис. 1.3). При заказе выводится итоговое время выполнения всех выбранных услуг. То есть клиент может точно знать, через какое время от начала выполнения заказа его автомобиль будет чист и доступен для использования.

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

Рисунок 1.3. Скриншот приложения «Вебмойка»: список услуг и время их выполнения

Еще одно полезное решение, которое было замечено в нескольких приложениях - раздел «Акции». Как известно, акции способны временно увеличивать количество поступающих заказов, поэтому важно оповещать об этом пользователей. Следующее важное решение - возможность оплаты заказа в приложении с помощью банковской карты (см. рис. 1.4). Для кого-то эта возможность может быть решающей при выборе автомойки. Для других - просто более удобный способ оплаты.

Рисунок 1.4. Скриншот приложения «Fast and Shine»: добавление банковской карты

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

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

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

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

Разрабатываемая система должна использовать следующие сущности:

1. Автомобиль.

1.1. Марка.

1.2. Модель.

1.3. Класс.

1.4. Гос. номер.

1.5. Клиент - владелец авто.

2. Клиент.

2.1. Имя.

2.2. Номер телефона.

3. Заказ.

3.1. Дата и время, назначенные для исполнения заказа.

3.2. Адрес для исполнения заказа.

3.3. Автомобиль.

3.4. Заказанные услуги.

3.5. Назначенный работник для исполнения заказа.

4. Работник.

4.1. Фамилия.

4.2. Имя.

4.3. Отчество.

4.4. Должность.

4.5. Зарплата.

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

1. Клиентское приложение для заказа услуг должно:

1.1. Определять местоположение клиента и отображать его на карте.

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

1.3. Запросить у клиента ввод государственного регистрационного номера, марки, модели автомобиля; выбор необходимых услуг и указание точного времени для выполнения мойки.

1.4. Предоставлять информацию об услугах компании.

2. Приложение автомойщика должно:

2.1. Определять местоположение работника и отображать его на карте.

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

2.3. Отображать на карте местоположение следующего заказа.

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

3. Серверное приложение должно:

3.1. Принимать от клиентского приложения информацию о заказе.

3.2. Проверять возможность оказания услуги в указанном клиентом месте и в указанное время и возвращать результат клиентскому приложению.

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

3.4. Передавать назначенному специалисту информацию о заказе.

В соответствии с данными требованиями и типами данных составлено итоговое техническое задание для реализации системы (см. прил. Б).

1.4 Технико-экономическое обоснование

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

Для оценки экономической эффективности разработки данной системы применяется расчет трудоемкости по функциональным точкам, расчет стоимости разработки системы по методике COCOMO II и прогнозирование срока окупаемости затрат в зависимости от прибыли компании. Прежде всего, с помощью анализа функциональных точек оценивается размер разрабатываемой системы. Метод функциональных точек предполагает следующие шаги [2]:

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

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

3. Подсчет функциональных точек, связанных с данными.

Количество не выровненных функциональных точек (UFP) зависит от сложности данных, которая определяется на основании количества неповторяемых уникальных полей данных (DET - data element type) и количества логических групп данных (RET - record element type). Количество этих показателей оценивается самостоятельно исходя из требований к системе, и затем на основании матрицы [2] определяется сложность. Оценка данных в не выровненных функциональных точках подсчитывается по-разному для внутренних логических файлов (ILFs) и для внешних интерфейсных файлов (EIFs) и определяется по таблице [2].

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

Таблица 1.1. Оценка данных в системе

Название сущности

DET

RET

Сложность данных

Тип файла

Количество UFP

Автомобиль

6

2

Низкая

ILF

7

Клиент

2

1

Низкая

ILF

7

Работник

5

1

Низкая

ILF

7

Заказ

14

3

Низкая

ILF

7

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

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

Количество не выровненных функциональных точек зависит от типа транзакции и сложности. Различают 3 типа транзакции [2]:

1. EI (external inputs) -- внешние входные транзакции, элементарная операция по обработке данных или управляющей информации, поступающих в систему извне.

2. EO (external outputs) -- внешние выходные транзакции, элементарная операция по генерации данных или управляющей информации, которые выходят за пределы системы. Предполагает определенную логику обработки или вычислений информации из одного или более ILF.

3. EQ (external inquiries) -- внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF.

Сложность транзакции определяется по таблице [2] исходя из оценки количества различных файлов (информационных объектов) типа ILF и/или EIF, модифицируемых или считываемых в транзакции (FTR - file type referenced) и количества неповторяемых уникальных полей данных (DET).

В табл. 1.2 приведены транзакции согласно требованиям к системе.

Таблица 1.2. Оценка транзакций системы

Название транзакции

Тип

FTR

DET

Сложность транзакции

Количество UFP

Приложение для клиентов

Определить местоположение клиента и отобразить его на карте.

EQ

1

1

Низкая

3

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

EI

1

1

Низкая

3

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

EO

3

6

Средняя

5

Просмотреть информацию о видах, продолжительности и стоимости услуг.

EQ

1

1

Низкая

3

Приложение для автомойщиков

Определить местоположение работника и отобразить его на карте.

EQ

1

1

Низкая

3

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

EQ

2

1

Низкая

3

Просмотреть на карте местоположение следующего заказа.

EQ

2

1

Низкая

3

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

EO

2

1

Низкая

4

Получить сообщение о появлении/изменении заказа.

EO

2

1

Низкая

4

Серверное приложение

Принимать от клиентского приложения информацию о заказе.

EI

3

6

Высокая

6

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

EQ

2

6

Средняя

4

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

EQ

3

14

Средняя

4

Передавать назначенному специалисту информацию о заказе.

EO

3

6

Средняя

5

Итого транзакции разрабатываемой системы оцениваются в 50 функциональных точек. Суммарно выявлено 106 функциональных точек.

Для оценки трудоемкости и сроков проекта используется методика COCOMO II. Согласно ей, трудоемкость разработки вычисляется по формуле [7]:

Трудоемкость = A*(Size)B*ME

Коэффициент А для предварительной оценки считается равным 2,94. Size - это оцениваемый размер программного продукта в тысячах строк кода. Исходя из вычисленного количества функциональных точек и статистических данных по отрасли [3], размер разрабатываемой системы оценивается в 6,466 тысяч строк кода на языке Java. Степень B вычисляется по формуле:

Оценка факторов масштаба Wi проводится самостоятельно на основании характеристик проекта и его участников. Каждому фактору присваивается уровень его значимости для проекта: от очень низкого до сверхвысокого. Затем, в соответствии с этим уровнем, каждому фактору задается весовой коэффициент согласно таблице [3]. В данной таблице для каждого фактора и его уровня значимости приведен уникальный коэффициент, который отличается от коэффициентов других факторов. Оценка значимости факторов масштаба для данного проекта приведена в табл. 1.3.

Таблица 1.3. Оценка факторов масштаба

№ п/п

Название фактора

Уровень значимости фактора

Весовой коэффициент

1.

Прецедентность, наличие опыта аналогичных разработок

Очень низкий

6,20

2.

Гибкость процесса разработки

Высокий

1,01

3.

Архитектура и разрешение рисков

Очень низкий

7,07

4.

Сработанность команды

Очень высокий

1,10

5.

Зрелость процессов

Средний

4,68

В итоге показатель «B» для данного проекта составляет 1,1106. Множитель (Size)B равняется 7,18.

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

Таблица 1.4. Оценка уровня коэффициентов затрат

№ п/п

Название коэффициента

Уровень коэффициента

Значение коэффициента

1.

Квалификация персонала

Низкий

1,26

2.

Опыт персонала

Низкий

1,22

3.

Сложность и надежность продукта

Нормальный

1,00

4.

Разработка для повторного использования

Низкий

0,95

5.

Сложность платформы разработки

Нормальный

1,00

6.

Оборудование

Нормальный

1,00

7.

Требуемое выполнение графика работ

Низкий

1,14

Для разрабатываемой системы ME равен 1,6648.

В итоге трудоемкость разработки данной системы составляет 35 человеко-месяцев. Трудоемкость разработки в значительной степени зависит от компетенций и количества разработчиков. В данном случае в расчете учитывались низкие компетенции единственного разработчика, что увеличило трудоемкость.

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

Исходя из трудоемкости разработки и средней зарплаты специалиста в городе Пермь [8] равной 38620 рублей стоимость разработки системы составляет 1351700 рублей. Также, возможно, компания проведет маркетинговую кампанию для привлечения клиентов и мотивации к использованию данного программного продукта, но эти затраты в рамках данного проекта не рассматриваются. Кроме того, внедрение данной системы позволит компании снизить нагрузку на штат операторов, принимающих заказы, и, возможно, сократить какое-то количество операторов.

Срок окупаемости инвестиций зависит от размера прибыли компании. График (см. рис. 1.5) показывает прогнозируемый срок окупаемости инвестиций на разработку данной системы в зависимости от величины прибыли компании. Значения прибыли взяты из расчета реалистичных сроков окупаемости. То есть при величине прибыли 50 тысяч рублей и менее срок окупаемости инвестиций становится слишком большим, что говорит о нецелесообразности разработки данной системы. А при величине прибыли 150 тысяч рублей срок окупаемости составляет около 10 месяцев, и с увеличением прибыли срок уменьшается медленно и незначительно.

Как видно на графике, при чистой прибыли 50 000 рублей инвестиции на разработку окупятся через 38 месяцев, то есть 3 года и 2 месяца. При прибыли около 100 000 рублей окупаемость займет примерно полтора года, а при прибыли 200 000 рублей затраты на разработку окупятся за 10 месяцев.

Рисунок 1.5. Срок окупаемости в зависимости от прибыли компании

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

2. Проектирование системы

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

2.1 Сценарии использования

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

Рисунок 2.1. Сценарии использования системы для актора «Клиент»

На рис. 2.2 изображены сценарии использования мобильного приложения для автомойщиков.

Рисунок 2.2. Сценарии использования системы для актора «Автомойщик»

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

2.2 Диаграммы последовательности

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

Рисунок 2.3. Последовательность работы с приложением для клиентов

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

Рисунок 2.4. Последовательность работы с приложением для автомойщиков

2.3 Диаграмма базы данных

На рис. 2.5 изображена диаграмма базы данных Microsoft SQL Server, созданная согласно требованиям к типам данных системы [10].

Рисунок 2.5. Диаграмма базы данных Microsoft SQL Server

База данных состоит из десяти таблиц:

1. Таблица CarClass хранит информацию о сегментах автомобилей по классификации Европейской экономической комиссии: название сегмента и коэффициент к стоимости услуг.

2. Таблица CarBrand хранит названия автомобильных марок, для которых возможно совершить заказ.

3. Таблица CarModel хранит информацию о моделях автомобилей, для которых возможно совершить заказ: название модели, идентификатор марки, идентификатор сегмента автомобиля.

4. Таблица Client хранит информацию о клиентах компании: имя и номер телефона.

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

6. Таблица Order хранит информацию о заказах: время создания заказа, время начала исполнения заказа, адрес места заказа, стоимость всех заказанных услуг, идентификатор графика работы назначенного автомойщика, идентификатор автомобиля клиента.

7. Таблица OrderTypesInOrder хранит информацию о заказанных услугах: идентификатор заказа, идентификатор услуги.

8. Таблица OrderType хранит информацию об услугах, доступных для заказа: название, описание, базовая стоимость услуги.

9. Таблица DaySchedule хранит информацию о графиках работы автомойщиков: идентификатор автомойщика, время начала и завершения рабочего дня, количество заказов.

10. Таблица Employee хранит информацию о сотрудниках компании.

2.4 Алгоритм приема заказа

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

Рисунок 2.6. Блок-схема алгоритма приема заказа и подбора автомойщика

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

2.5 Выбор инструментов и технологий реализации

Для разработки мобильных приложений для операционной системы Android используется среда разработки Android Studio и язык программирования Kotlin. Они являются официальными средствами разработки [13] приложений для операционной системы Android [12]. Android Studio является современной средой разработки с удобным редактором макетов, статическим анализатором кода и встроенными шаблонами основных макетов и компонентов Android. В Android Studio 3.0 и выше включены инструменты языка Kotlin. Этот язык программирования подобен Java, но является более лаконичным и типобезопасным. Для коммуникации с сервером используется библиотека Retrofit, которая отправляет запросы на сервер, принимает ответы и преобразует их в объект указанного класса.

Для разработки серверного приложения используется фреймворк Windows Communication Foundation (WCF) и язык программирования C#. Эта технология позволяет создать сервер с архитектурным стилем REST (Representational State Transfer) для взаимодействия с клиентскими приложениями. Сервер отправляет ответы клиентским приложениям в текстовом формате JSON (JavaScript Object Notation), удобном как для чтения человеком, так и легким для передачи по сети.

Внутри серверного приложения для работы с базой данных Microsoft SQL Server используется Entity Framework. Эта технология позволяет сформировать на основе существующей базы данных модель Entity Data Model (EDM) и создать классы из сущностей данной модели. Для запросов к базе данных используется язык Language Integrated Query (LINQ). Для создания базы данных Microsoft SQL Server используется Microsoft SQL Server Management Studio.

Глава 3. Разработка системы

3.1 Серверное приложение

3.1.1 Настройка файла конфигурации

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

<service behaviorConfiguration="Default" name="CarWashService.Service1">

<endpoint address="" behaviorConfiguration="webBehavior" binding="webHttpBinding" contract="CarWashService.IService1" />

<host>

<baseAddresses>

<add baseAddress="http://localhost:9484/Service1.svc" />

</baseAddresses>

</host>

</service>

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

Атрибут «binding» задает способ связи клиентов с конечной точкой, включая используемый транспортный протокол (например, TCP или HTTP), используемое кодирование сообщений (например, текстовое или двоичное) и необходимые требования безопасности (например, безопасность сообщений SSL или SOAP). Для данной системы указан атрибут «webHttpBinding», который поддерживает HTTP- запросы. Это необходимо для реализации RESTful сервиса.

Атрибут «contract» показывает, какие функциональные возможности предоставляет клиенту конечная точка. Контракт указывает операции, которые может вызвать клиент, форму сообщения и тип входных параметров или данных, требуемых для вызова операции, а также тип обработки или ответного сообщения, которые может ожидать клиент. Атрибут «behaviorConfiguration» задает поведение конечной точки. Для привязки «webHttpBinding» было создано поведение <webHttp/> в подразделе <behaviors>.

3.1.2 Создание классов из модели данных

С помощью стандартных инструментов Visual Studio была создана модель данных (Entity Data Model - EDM) из существующей базы данных Microsoft SQL [9], спроектированной на предыдущем этапе. Получившаяся модель данных изображена на рис. 3.1.

Рисунок 3.1. Модель данных серверного приложения

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

3.1.3 Реализация функций

После создания классов системы был разработан интерфейс для обращения к данному WCF-сервису, то есть описание методов, которые система реализует: их названия, принимаемые параметры и типы возвращаемых данных. Для реализации архитектурного стиля REST в WCF-сервисе используется библиотека System.ServiceModel.Web и атрибуты методов «WebGet» и «WebInvoke». Значение параметра атрибута «UriTemplate» указывает шаблон универсального кода ресурса для обращения к методу из клиентских приложений. Внутри шаблона в фигурных скобках могут находится параметры, которые сопоставляются по имени с параметрами вызываемого метода. В параметре «Method» указывается тип HTTP-запроса: GET, POST, PUT или DELETE. Значения параметров «RequestFormat» и «ResponseFormat» указывают формат запроса к серверу и формат ответа сервера, соответственно. Для разрабатываемой системы выбран формат JSON, удобный для передачи объектов и понятный для чтения человеком. Ниже приведен код объявления одной из конечных точек интерфейса серверного приложения:

[WebInvoke(

Method = "GET",

UriTemplate = "/GetOrdersForWasher/{washerId}",

ResponseFormat = WebMessageFormat.Json)]

public List<Order> GetOrdersForWasher(string washerId)

После создания интерфейса сервера были реализованы объявленные в нем методы:

1. Метод «CreateSchedules» служит для создания графиков автомойщиков на новый день, не принимает параметры и возвращает строку с сообщением о результате.

2. Метод «GetCarBrands» получает из базы данных и возвращает в качестве результата список автомобильных марок; не принимает параметры.

3. Метод «GetOrderTypes» получает из базы данных и возвращает в качестве результата список услуг, доступных для заказа; не принимает параметры.

4. Метод «GetOrdersForWasher» служит для получения списка заказов, назначенных указанному автомойщику. Метод принимает в качестве параметра строку с идентификатором автомойщика и возвращает список объектов класса «Order» в виде JSON.

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

6. Метод «MakeOrder» реализует описанный в предыдущей главе алгоритм приема и обработки заказа и подбора автомойщика для исполнения заказа (см. прил. В). Метод принимает в качестве параметра объект вспомогательного класса «SupportOrder» в формате JSON. В данном объекте передаются необходимые данные для заказа: информация об автомобиле, время и адрес для исполнения заказа, желаемые услуги. Метод проверяет корректность данных, затем выбирает автомойщиков, свободных в указанное время, и среди них находит ближайшего. Расстояние между заказами для назначения ближайшего автомойщика вычисляется с помощью метода «DistanceTo» класса «Order». Данный метод принимает два строковых параметра - географические координаты в градусах: долгота и широта. Эти координаты сравниваются с координатами объекта, для которого вызван данный метод (см. прил. Г).

3.2 Android-приложение для заказа услуг

Основой для разработки Android-приложения был выбран шаблон «Navigation Drawer Activity». Он предоставляет основное окно, содержимое которого зависит от выбранного пункта во всплывающем боковом меню. Такая функциональность возможна благодаря использованию элемента «Fragment» [4, 11] в разметке основного окна приложения и класса «Fragment» для обработки взаимодействий с этим элементом. При выборе какого-либо пункта меню создается объект соответствующего класса, наследуемого от класса «Fragment», и отображается связанный с этим классом шаблон элемента «Fragment».

Боковое меню приложения содержит два пункта: «Карта» и «Услуги» (рис. 3.2). При запуске приложения боковое меню скрыто, выбран пункт «Карта» и отображается карта. При первом запуске приложение запрашивает доступ к данным о местоположении пользователя. Если запретить доступ, то приложение не сможет определить местоположение пользователя и сделать заказ будет невозможно. Для работы приложения необходимо включить определение местоположения и разрешить приложению доступ к данным о местоположении пользователя.

Рисунок 3.2. Боковое меню приложения для заказа услуг

Открытие бокового меню доступно по иконке «Гамбургер» в левом верхнем углу окна приложения (рис. 3.3). При выборе пункта меню «Карта», как и при старте приложения, отображается карта с текущим местоположением пользователя. В приложении используется стандартная карта от компании Google, для работы с ней были подключены следующие библиотеки [6]:

1. Библиотека «com.google.android.gms:play-services-maps» для отображения карты и поддержки взаимодействия с ней.

2. Библиотека «com.google.android.gms:play-services-location» для определения местоположения.

3. Библиотека «com.google.android.gms:play-services-places» для поиска по известным местам или адресу.

Рисунок 3.3. Окно приложения с картой и местоположением

Местоположение пользователя обозначается синей точкой с полупрозрачной окружностью голубого цвета, которая показывает погрешность при определении координат. Самая большая погрешность присутствует при использовании мобильной сети для определения местоположения. Наибольшая точность - при использовании GPS (Global Positioning System). Кроме того, в координатах пользователя автоматически ставится метка, которая обозначает место, где необходимо выполнить заказ пользователя. Пользователь может передвинуть эту метку и установить в необходимом месте, если его местоположение определено не точно или не совпадает с расположением автомобиля.

Внизу окна с картой имеется кнопка «Сделать заказ», которая открывает окно с формой заказа (рис. 3.4).

Рисунок 3.4. Окно приложения с формой заказа

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

1. Выбрать марку автомобиля из выпадающего списка.

2. Выбрать модель автомобиля из выпадающего списка.

3. Ввести государственный регистрационный номер автомобиля.

4. Выбрать время для выполнения заказа из выпадающего списка.

5. Отметить галочкой в предложенном списке необходимые услуги.

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

При выборе пункта меню «Услуги» отображается окно с названием и описанием услуг, которые доступны для заказа (рис. 3.5).

Рисунок 3.5. Окно приложения с информацией об услугах

Для работы с сервером через REST API используется библиотека Retrofit («com.squareup.retrofit2:retrofit») со вспомогательными библиотеками «com.squareup.retrofit2:adapter-rxjava2», «com.squareup.retrofit2:converter-gson» и «io.reactivex.rxjava2:rxandroid». Библиотека Retrofit позволяет посылать серверу HTTP_запросы, принимать ответы в виде JSON и преобразовывать их в объекты классов с помощью конвертера.

Для отправки запросов серверу был создан интерфейс, который содержит объявление конечных точек API, то есть методов, доступных для вызова через API сервера. Для каждой конечной точки указана аннотация с типом HTTP-запроса и адресом конечной точки. Адрес конечной точки добавляется к URL-адресу сервера, указанному в объекте класса «Retrofit». Ниже приведен пример объявления конечной точки сервера в интерфейсе на стороне клиентского приложения:

@POST("MakeOrder")

fun makeOrder(@Body order: Order): Call<String>

Аннотация «@Body» перед параметром метода «makeOrder» преобразует объект класса «Order» в JSON-объект, подлежащий передаче через HTTP-запрос. Также у методов указаны классы возвращаемых объектов. Эти классы являются POJO (Plain Old Java Object) и были созданы из JSON-объектов, которые отправляет сервер, с помощью плагина к Android Studio. Благодаря библиотеке Retrofit получаемые от сервера JSON_объекты преобразуются в объекты указанных классов POJO.

3.3 Android-приложение для автомойщиков

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

Рисунок 3.6. Вход в систему в приложении автомойщика

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

После успешной авторизации в системе открывается основное окно приложения. Аналогично приложению для заказа услуг, приложение для автомойщиков основано на шаблоне «Navigation Drawer Activity» c меняющимися элементами «Fragment» в основном окне приложения. Боковое меню приложения содержит два пункта: «Карта» и «Заказы». При выборе пункта «Карта» отображается карта с местоположением пользователя, обозначенным синей точкой. При открытии пункта «Заказы» пользователю доступен список с информацией о предстоящих заказах: время, данные об автомобиле, список заказанных услуг (рис. 3.7).

Рисунок 3.7. Список назначенных заказов

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

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

Рисунок 3.8. Карта с маршрутом до места исполнения заказа

4. Тестирование системы

4.1 Тестирование серверного приложения

Перед тестированием серверного приложения база данных была заполнена данными, чтобы иметь возможность полноценно проверить возвращаемые конечными точками результаты. Тестирование проводилось с помощью расширения POSTMAN для браузера Google Chrome. Данное расширение позволяет отправлять HTTP-запросы по указанному URL-адресу и получать ответы в формате JSON. Для тестирования разработанный WCF-сервис был развернут в локальной среде IIS (Internet Information Services). На скриншоте (рис. 4.1) показан ответ сервера при обращении к методу «GetOrderTypes».

Рисунок 4.1. Ответ сервера на запрос списка услуг

Метод «GetOrderTypes» вернул массив из трех объектов класса «OrderType», представляющих информацию об услугах компании, в формате JSON. Аналогично были протестированы остальные конечные точки серверного приложения (табл. 4.1).

Таблица 4.1. Тестирование серверного приложения

№ п/п

Относительный адрес конечной точки

Формат ответа

Ожидаемый ответ

Результат теста

1.

Ping

JSON

"Есть коннект!"

+

2.

CreateSchedules

JSON

"Расписания успешно созданы"

+

3.

GetCarBrands

JSON

Массив объектов класса CarBrand

+

4.

GetOrdersForWasher/{washerId}

JSON

Массив объектов класса Order

+

5.

GetOrderTypes

JSON

Массив объектов класса OrderType

+

6.

WorkerSignIn/{number}

JSON

Идентификатор работника

+

Проверка конечной точки «MakeOrder» для создания и обработки заказа и подбора автомойщика выполнялась с помощью программы «Fiddler», которая позволяет отправлять серверному приложению запросы с телом в формате JSON. На скриншоте (рис. 4.2) представлено окно программы с телом запроса.

После проверки конечных точек API серверного приложения было выполнено тестирование расчета расстояния и подбора ближайшего свободного автомойщика. Было создано шесть тестовых автомойщиков и графики работы для них. Затем было выбрано начальное место на карте, в котором будет создаваться тестовый заказ и от которого, соответственно, будет вычисляться расстояние. После этого вручную было создано шесть заказов: для каждого автомойщика по одному заказу в 9 часов с постепенным увеличением расстояния от начального места. Таким образом, автомойщик №1 был ближайшим к начальному месту, автомойщик №6 - самым отдаленным от начального места. Далее шесть раз создавался тестовый заказ на 10 часов в начальном месте и проверялось, в каком порядке будут назначены автомойщики. Правильный расчет расстояния означает назначение автомойщиков в порядке удаления от начального места. То есть первым назначается автомойщик №1, последним - автомойщик №6. Результаты тестирования приведены в прил. Д.

...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены