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



Оглавление

Введение

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

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

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

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

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

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

  1. Провести анализ бизнес-процессов компании.
  2. Провести анализ существующих решений по оказанию услуг выездной автомойки.
  3. Определить требования к разрабатываемой системе. Разработать техническое задание.
  4. Рассчитать стоимость и сроки разработки информационной системы. Выполнить технико-экономическое обоснование разработки системы.
  5. Выполнить проектирование системы. Выбрать инструменты и технологии разработки системы.
  6. Разработать систему для автоматизации бизнес-процессов компании, оказывающей услуги выездной автомойки.
  7. Провести тестирование системы для автоматизации бизнес-процессов компании, оказывающей услуги выездной автомойки.

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

  1. Сравнительный анализ существующих решений по оказанию услуг выездной автомойки.
  2. Синтез требований к разрабатываемой системе.
  3. Сравнительный анализ инструментов и технологий разработки.
  4. Моделирование бизнес-процессов выездной автомойки и системы для их автоматизации.

  1. Аналитический обзор
    1. Мобильное приложение как инструмент для бизнеса

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

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

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

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

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

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

  1. Клиентское приложение для заказа услуг должно:
    1. Определять местоположение клиента и отображать его на карте.
    2. Позволять клиенту самостоятельно выбрать на карте местоположение автомобиля, где необходимо выполнить мойку.
    3. Запросить у клиента ввод государственного регистрационного номера, марки, модели автомобиля; выбор вида услуги, точного времени или временного диапазона для выполнения мойки.
    4. Предоставлять информацию о видах и стоимости услуг.
    1. Приложение автомойщика должно:
      1. Определять местоположение работника и отображать его на карте.
      2. Предоставлять информацию о назначенных заказах: время, местоположение, вид услуги, данные об автомобиле.
      3. Отображать на карте местоположение следующего заказа.
      4. Отображать на карте оптимальный путь до следующего заказа.
      1. Серверное приложение должно:
        1. Принимать от клиентского приложения информацию о заказе.
        2. Проверять возможность оказания услуги в указанном клиентом месте и в указанное время и возвращать результат клиентскому приложению.
        3. Подбирать наиболее подходящего специалиста для выполнения заказа.
        4. Передавать назначенному специалисту информацию о заказе.
          1. Анализ существующих решений

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

  1. «Fast and Shine» – приложение одноименной международной компании, оказывающей услуги выездной автомойки. Данная компания расширяется с помощью франчайзинга, но в Перми она не имеет партнеров.
  2. «Digital Moika» – приложение одноименной компании из Ростова-на-Дону, которая так же оказывает услуги выездной автомойки.
  3. «Green Steams» – приложение американской компании, оказывающей услуги выездной автомойки.
  4. «Spunje» – приложение американской компании, оказывающей услуги выездной автомойки.
  5. «WashMap» – международное приложение-агрегатор для поиска свободной стационарной автомойки.
  6. «Автомойки онлайн» – российское приложение-агрегатор для поиска свободной стационарной автомойки.
  7. «АвтомойкиРУ» – международное приложение-агрегатор для поиска свободной стационарной автомойки.
  8. «Вебмойка» – международное приложение-агрегатор для поиска свободной стационарной автомойки.
  9. «Где мойка?» – российское приложение-агрегатор для поиска свободной стационарной автомойки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Автомобиль.
    1. Марка.
    2. Модель.
    3. Класс.
    4. Гос. номер.
    5. Клиент – владелец авто.
    1. Клиент.
      1. Имя.
      2. Номер телефона.
      1. Заказ.
        1. Дата и время, назначенные для исполнения заказа.
        2. Адрес для исполнения заказа.
        3. Автомобиль.
        4. Заказанные услуги.
        5. Назначенный работник для исполнения заказа.
        1. Работник.
          1. Фамилия.
          2. Имя.
          3. Отчество.
          4. Должность.
          5. Зарплата.

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

  1. Клиентское приложение для заказа услуг должно:
    1. Определять местоположение клиента и отображать его на карте.
    2. Позволять клиенту самостоятельно выбрать на карте местоположение автомобиля, где необходимо выполнить мойку.
    3. Запросить у клиента ввод государственного регистрационного номера, марки, модели автомобиля; выбор необходимых услуг и указание точного времени для выполнения мойки.
    4. Предоставлять информацию об услугах компании.
    1. Приложение автомойщика должно:
      1. Определять местоположение работника и отображать его на карте.
      2. Предоставлять информацию о назначенных заказах: время, местоположение, заказанные услуги, данные об автомобиле.
      3. Отображать на карте местоположение следующего заказа.
      4. Отображать на карте оптимальный путь до следующего заказа.
      1. Серверное приложение должно:
        1. Принимать от клиентского приложения информацию о заказе.
        2. Проверять возможность оказания услуги в указанном клиентом месте и в указанное время и возвращать результат клиентскому приложению.
        3. Подбирать наиболее подходящего специалиста для выполнения заказа.
        4. Передавать назначенному специалисту информацию о заказе.

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

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

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

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

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

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

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

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

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

DET

RET

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

Тип файла

КоличествоUFP

Автомобиль

6

2

Низкая

ILF

7

Клиент

2

1

Низкая

ILF

7

Работник

5

1

Низкая

ILF

7

Заказ

14

3

Низкая

ILF

7

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

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

Количество не выровненных функциональных точек зависит от типа транзакции и сложности. Различают 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.. Оценка транзакций системы

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

Тип

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.. Оценка факторов масштаба

№ п/п

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

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

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

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

Очень низкий

6,20

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

Высокий

1,01

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

Очень низкий

7,07

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

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

1,10

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

Средний

4,68

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

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

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

№ п/п

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

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

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

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

Низкий

1,26

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

Низкий

1,22

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

Нормальный

1,00

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

Низкий

0,95

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

Нормальный

1,00

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

Нормальный

1,00

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

Низкий

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. Проектирование системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок .5. Диаграмма базы данныхMicrosoftSQLServer

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

  1. Таблица CarClass хранит информацию о сегментах автомобилей по классификации Европейской экономической комиссии: название сегмента и коэффициент к стоимости услуг.
  2. ТаблицаCarBrand хранит названия автомобильных марок, для которых возможно совершить заказ.
  3. ТаблицаCarModel хранит информацию о моделях автомобилей, для которых возможно совершить заказ: название модели, идентификатор марки, идентификатор сегмента автомобиля.
  4. ТаблицаClient хранит информацию о клиентах компании: имя и номер телефона.
  5. ТаблицаClientCar хранит информацию об автомобилях клиентов компании: идентификатор клиента, идентификатор модели автомобиля, государственный регистрационный номер автомобиля.
  6. ТаблицаOrder хранит информацию о заказах: время создания заказа, время начала исполнения заказа, адрес места заказа, стоимость всех заказанных услуг, идентификатор графика работы назначенного автомойщика, идентификатор автомобиля клиента.
  7. ТаблицаOrderTypesInOrder хранит информацию о заказанных услугах: идентификатор заказа, идентификатор услуги.
  8. ТаблицаOrderType хранит информацию об услугах, доступных для заказа: название, описание, базовая стоимость услуги.
  9. ТаблицаDaySchedule хранит информацию о графиках работы автомойщиков: идентификатор автомойщика, время начала и завершения рабочего дня, количество заказов.
  10. ТаблицаEmployee хранит информацию о сотрудниках компании.
    1. Алгоритм приема заказа

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

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

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

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

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

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

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

Разработка системы

  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>.

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

С помощью стандартных инструментовVisualStudio была создана модель данных (EntityDataModelEDM) из существующей базы данныхMicrosoftSQL [9], спроектированной на предыдущем этапе. Получившаяся модель данных изображена на рис. 3.1.

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

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

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

После создания классов системы был разработан интерфейс для обращения к данному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». Данный метод принимает два строковых параметра – географические координаты в градусах: долгота и широта. Эти координаты сравниваются с координатами объекта, для которого вызван данный метод (см. прил. Г).
    1. Android-приложение для заказа услуг

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

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

Рисунок .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. Окно приложения с картой и местоположением

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

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

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

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

  1. Выбрать марку автомобиля из выпадающего списка.
  2. Выбрать модель автомобиля из выпадающего списка.
  3. Ввести государственный регистрационный номер автомобиля.
  4. Выбрать время для выполнения заказа из выпадающего списка.
  5. Отметить галочкой в предложенном списке необходимые услуги.

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

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

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

Для работы с сервером черезRESTAPI используется библиотека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")

funmakeOrder(@Bodyorder: Order): Call<String>

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

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

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

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

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

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

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

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

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

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

  1. Тестирование системы
    1. Тестирование серверного приложения

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

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

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

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

№ п/п

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

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

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

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

Ping

JSON

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

+

CreateSchedules

JSON

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

+

GetCarBrands

JSON

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

+

GetOrdersForWasher/{washerId}

JSON

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

+

GetOrderTypes

JSON

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

+

WorkerSignIn/{number}

JSON

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

+

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

Рисунок .2. Создание запроса к серверу в программе «Fiddler»

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

  1. Функциональное тестирование приложения для заказа услуг

Целью функционального тестирования является проверка правильности выполнения всех функций приложения согласно установленным требованиям к приложению. Тестирование проводилось по методике «Черный ящик», что означает отсутствие знаний о внутреннем устройстве системы и действие исходя из пользовательских сценариев использования приложения. Тестирование проводилось в локальной сети при помощи персонального компьютера, где развернуто серверное приложение, и мобильного телефона с установленным приложением для заказа услуг. Перед тестированием база данных была заполнена необходимыми данными для полноценного функционирования системы. На мобильном телефоне было включено определение местоположения с помощьюGPS. Для тестирования были составлены сценарии [5], соответствующие вариантам использования приложения и определенным ранее функциональным требованиям к приложению. Пример тестового сценария приведен в табл. 4.2.

Таблица .2. Сценарий тестирования приложения для заказа услуг

Номер: 4

Название: заполнение формы и совершение заказа.

Действие

Ожидаемый результат

Фактический результат

Предусловия

Выполнить тест №2

Открыто приложение, отображается карта с местоположением пользователя, красная метка установлена в нужном месте.

Выполнено

Шаги теста

1. Нажать кнопку «Сделать заказ».

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

Выполнено

Действие

Ожидаемый результат

Фактический результат

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

Отображается сообщение на экране «Заказ принят!».

Выполнено

Постусловия

1. Нажать на иконку «гамбургер» в левом верхнем углу окна приложения.

Отображается боковое меню приложения.

Выполнено

2. Нажать пункт меню «Карта»

Отображается карта с местоположением пользователя и красной меткой.

Выполнено

Полный список сценариев тестирования приведен в прил. Е. Все функции приложения для клиентов были покрыты тестовыми сценариями и успешно проверены.

  1. Функциональное тестирование приложения для автомойщиков

Аналогичным образом и в тех же условиях было протестировано мобильное приложение для автомойщиков. Были разработаны сценарии тестирования для проверки всех требований к приложению (табл. 4.3). Все тесты были пройдены успешно. Полный список сценариев тестирования приведен в прил. Ж.

Таблица .3. Сценарий тестирования приложения для автомойщиков

Номер: 3

Название: просмотр маршрута проезда до места исполнения заказа.

Действие

Ожидаемый результат

Фактический результат

Предусловия

Выполнить тест №2

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

Выполнено

Шаги теста

1. Нажать на любой заказ в списке.

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

Выполнено

Постусловия

Отсутствуют.

Заключение

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

  1. Проведен анализ бизнес-процессов компании и выявлены задачи, подлежащие автоматизации: прием заказа, поиск и назначение автомойщика для выполнения заказа, передача автомойщику информации о назначенных заказах.
  2. Исходя из предыдущего этапа были сформированы требования к типам данных и функциям системы, разработано техническое задание.
  3. Проведено технико-экономическое обоснование разработки системы, в результате которого были рассчитаны срок и стоимость разработки системы, а также спрогнозирован срок окупаемости в зависимости от прибыли компании.
  4. Спроектирована база данных, диаграммы прецедентов и последовательности. Выбраны технологии и инструменты для реализации:VisualStudio иWindowsCommunicationFoundation для серверного приложения, Android Studio и язык программирования Kotlin дляAndroid-приложений.
  5. Реализованы серверное приложение,Android-приложение для заказа услуг клиентами компании иAndroid-приложение для отслеживания назначенных заказов автомойщиками компании.
  6. Выполнено тестированиеAPI серверного приложения и расчета расстояния между заказами. Составлено 10 сценариев тестирования согласно требованиям к системе и проведено функциональное тестирование разработанных приложений. Все тесты были пройдены успешно.

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

  1. Регистрация и авторизация клиентов в системе.
  2. Добавление и сохранение данных об автомобилях в профиле клиента.
  3. Просмотр прошедших и будущих заказов в приложении клиента.
  4. Поддержка акций и скидок, просмотр их в приложении клиента.

Библиографический список

  1. Аудитория пользователей интернета в России в 2017 году составила 87 млн. человек // Анализ рекламы: сравнительный анализ рынка рекламы в России –Mediascope.URL:http://mediascope.net/press/news/744498/ (дата обращения: 09.12.2017).
  2. Архипенков С. Обзор метода функциональных точек // Лекции по управлению программными проектами.URL:http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml (дата обращения: 24.03.2018)
  3. Архипенков С. Основы методикиCOCOMOII // Лекции по управлению программными проектами.URL:http://citforum.ru/SE/project/arkhipenkov_lectures/13.shtml (дата обращения: 24.03.2018)
  4. Гриффитс Дон, Гриффитс Дэвид.HeadFirst. Программирование для Android. СПб: Питер, 2016. 704 с.
  5. Куликов С. Тестирование программного обеспечения. Базовый курс. Минск: Издательство «Четыре четверти», 2017. 312 с.
  6. Майер P. Android 4: программирование приложений для планшетных компьютеров и смартфонов. М.: Эксмо, 2011. 672 с.
  7. Метрики ПО // НОУ ИНТУИТ | Лекция | Управление разработкой ПО.URL:https://www.intuit.ru/studies/courses/64/64/lecture/1896?page=6 (дата обращения: 09.04.2018)
  8. Пермь // Статистика.URL:https://stats.hh.ru/?region=72 (дата обращения: 09.04.2018)
  9. Троелсен Э. Язык программирования C# 5.0 и платформа .NET 4.5, 6е издание. М.: ООО «И.Д. Вильямс», 2013. 1312 с.
  10. Фаулер М. Архитектура корпоративных программных приложений. М.: Издательский дом «Вильямс», 2006. 544 с.
  11. Филлипс Б., Стюарт К., Марсикано К. Android. Программирование для профессионалов. СПб: Питер, 2017. 688 с.
  12. Google добавила Kotlin в качестве официального языка программирования для Android // Все самое интересное из мираIT-индустрии.URL:https://3dnews.ru/952400 (дата обращения: 09.04.2018)
  13. Meet Android Studio // Android Developers. URL:https://developer.android.com/studio/intro/ (дата обращения: 09.04.2018)




Похожие работы, которые могут быть Вам интерестны.

1. Выбор информационной системы для автоматизации бизнес-процессов в малом бизнесе производства одежды

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

3. Автоматизация взаимодействия бизнес-процессов коммерческого и IT департаментов компании Ин Плат

4. Возможность автоматизации закупочной деятельности компании X с использованием ERP системы

5. Разработка рекомендаций по оптимизации бизнес-процессов ООО Specia

6. Повышение эффективности логистических процессов компании за счет информационной аналитической системы

7. Разработка информационно-управляющей системы автоматизации Теплообменника

8. Разработка системы автоматизации управления научной библиотекой

9. Разработка системы автоматизации составления расписания образовательного учреждения

10. РАЗРАБОТКА СИСТЕМЫ АВТОМАТИЗАЦИИ ДЕМОНСТРАЦИОННОГО ОБОРУДОВАНИЯ ВЫСТАВОЧНОГО ЗАЛА