1. Совокупность основополагающих принципов для успешной разработки программного обеспечения. На этих принципах основана методология разработки программного обеспечения.
2. Среда многоразового содержимого метода и строительных блоков процесса. Определенное и усовершенствованное Rational Software на постоянной основе, семейство RUP модулей метода определяет среду метода, в которой создаются собственные конфигурации метода и специализированные процессы. Это определение подчёркивает, что методология относится к разряду Agile методологий, то есть гибких методологий.
3. Лежащий в основе язык определения методов и процессов. В основе всего лежит унифицированная метамодель архитектуры метода.  Эта модель предоставляет язык описания процессов и содержимого методов. Этот новый язык представляет собой объединение различных языков разработки методов и процессов, включая язык моделирования UML.

На рисунке 1 представлена краткая история развития методологии RUP.

Рисунок 1. История развития RUP

Развитие RUP с 1995 по 1998 года представлена на рисунке 2.

 Рисунок 2. Генеалогическое дерево RUP

Методология разработки программного обеспечения является приемником Rational Objectory Process версии 4.

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

Данная методология позволяет интегрировать функции инструментальных средств Rational Software.

В результате объединения в 1995 году двух корпораций Rational Software Corporation и Objectory AB появилась методология Rational Objectory Process, являющаяся результатом интеграции двух продуктов Rational Approach и Objectory process версии 3.

Методология Objectory process создана в 1987 в Швеции Иваром Якобсоном в процессе его работы в шведской компании Ericsson, занимающейся производством телекоммуникационного оборудования.

В результате он применил методологию Objectory process для создания его продукта в компании Objectory AB. В основе этой методологии лежала концепция применения вариантов использования и объектно-ориентированный метод проектирования.

В 1992 года Якобсон задокументировал процесс разработки программного обеспечения, который получил название OOSE. Благодаря этому эта методология быстро получило признание в индустрии разработки ПО. Она была адаптирована и интегрирована многими известными компаниями в области разработки. Упрощенная версия методологии Objectory process была описано в книге Ивара Якобсона в 1992.

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

Джеймс Рамбо известен своей работой над созданием технологии объектного моделирования (OMT) и языка моделирования UML.

Иван Якобсон, Град Буч и Джеймс Рамбо совместно разработали язык моделирования UML. Впоследствии на основе OMT, OOSE и метод Буча они разработали единую методологию Rational Unified Process (RUP). В 2003 году ее приобрела корпорация IBM.

В истории RUP важным элементом является развитие нотации UML, которое представлено на рисунке 3.

 Рисунок 3. История развития UML

В истории UML выделяют три основных периода: до UML 1.x, UML 1.x, UML 2.x.

Цели методологии включают в себя следующее:

1. Гарантировать высокое качество программной системы, отвечающей потребностям Заказчиков, в пределах предсказуемого бюджета и графика
2. Предоставить общий каркас (framework) процесса разработки ПО
3. Обеспечить возможность формирования процесса разработки на базе адаптации RUP под конкретный проект
4. Реализовать промышленный подход к выпуску ПО на основе многократного использования рабочих методик, описывающих общий каркас
5. Гарантировать четкий контроль хода выполнения проекта на основе информационной поддержки всех фаз ЖЦ за счет дисциплины управления проектами и уменьшения плана итераций
6. Снять барьеры непонимания между участниками проекта за счет единой терминологии
7. Привести документооборот к стандарту ISO 9000 на основе предоставления специальных шаблонов документов

Выделяют десять основных приоритетов методологии:

1. Разработка концепции.
2. Создание плана.
3. Идентификация и смягчение рисков.
4. Установка и отслеживание проблем.
5. Анализ прецедентов.
6. Разработка компонентой структуры.
7. Инкрементное создание и тестирование продукта.
8. Проверка и оценка результатов.
9. Управление и контроль изменений.
10. Обеспечение поддержки пользователей.

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

Применение классического подхода разработки ПО может привести к следующим проблемам:

• Проекты почти никогда не укладываются в запланированные сроки и бюджет.
• Созданные в результате этого процесса система почти никогда полностью не удовлетворяют требованиям пользователей.
• Исследовательская компания Standish Group оценивает процент успешности разработки проекта порядка 26 %.

Источники и причины таких проблем:

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

Для решения вышеописанных проблем методология RUP предлагает использовать лучшие практики в качестве решения проблем. Лучшие практики (Best Practices) – это набор проверенных на практике принципов, методов и процессов качественной и производительной работы над проектами по созданию ПО

Примеры реализации с использованием этих практик:

1)    Rational Unified Process (IBM Rational)

2)    MSF (Microsoft Solutions Framework)

3)    ALM (Borland Application Lifecycle Management)

4)    Enterprise Component Modeling (Platinum Technology)

Лучшие практики включают в себя следующее:

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

В данный момент на рынке представлено довольно много различных систем, методов и технологий, предназначенных для навигации [1]. Однако большая часть таких технологий предназначена для работы не внутри зданий, а на открытом воздухе. Среди таких систем можно выделить: GPS, Galileo, ГЛОНАСС, iBeacon, WPS и др. В свою очередь для обработки навигационных данных, предоставленных с помощью вышеуказанных технологий используются такие сервисы, как: Google Maps, NAVIMIND, 2GIS.

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

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

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

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

• единое ядро для мобильного и веб-приложения;
  
• использование 2D и 3D – карт;
  
• построение наиболее простых и понятных маршрутов;
  
• упрощение взаимодействия клиентов (посетителей) и зданий;
  
• возможность пользовательского развития, когда пользователи имеют возможность вносить (после модерации) оперативные изменения в планы помещений;
  
• предоставление актуальной информации, такой как график работы, контактная информация и т.п.
  

Задачи прокладки эффективных маршрутов внутри зданий можно отнести к классическим задачам трассировки с линейными и пространственными ограничениями, которые хорошо проработаны и эффективно применяются в радиоэлектронике [2-9].

1 ТРЕБОВАНИЯ К НАВИГАЦИОННОЙ СИСТЕМЕ

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

Для пользовательского приложения:

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

Для приложения администратора:

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

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

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

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

• серверная ОС Linux Ubuntu 14.04;
  
• база данных MongoDB 3.0.6;
  
• веб-серверное ПО NodeJS 4.0.0;
• мобильные приложения для платформ Android и iOS.

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

2 ТЕХНИЧЕСКАЯ СТРУКТУРА СИСТЕМЫ

2.1 Архитектура системы

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

Рисунок 1: – Архитектура системы

Основные данные системы хранятся на сервере БД под управлением СУБД MongoDB. Вывод и изменение необходимых пользователям данных осуществляется с помощью веб-сервера Nginx под управлением NodeJS. Клиенты в свою очередь взаимодействуют с системой с помощью специальных мобильных приложений, работающих как на платформе Android, так и на iOS.

2.2 Структура программы

Программная часть системы indoor-навигации реализуется в виде набора приложений на языке программирования JavaScript, основанном на ECMAScript 5. Помимо этого используется фреймворк AngularJS, который позволяет разделить систему на модули.
Приложение администрирования поделено на 5 основных модулей: «Аккаунт», «Статистика», «Управление», «Здание» и «Граф». Связь этих модулей в системе показана на рисунке 2.

Рисунок 2: – Модульная структура системы

Объекты класса «Статистика» играют роль транзакций в данной системе. Они отражают факты того, что пользователь A, авторизовавшийся в системе под своим аккаунтом B, в здании C запросил маршрут D. Эта информация в дальнейшем используется для формирования отчётности.

На диаграмме пакетов изображены связи между модулями приложения администрирования. Модули «Граф», «Здание» и «Клиент» напрямую связаны с соответствующими базами данных. Они нужны для хранения справочных данных.

Модуль «Маршрут» использует данные о зданиях, полученные через обращения к базе данных, для формирования маршрута и записи в статистику. Модуль «Управление системой» имеет доступ к модулю «Здание» и «Граф» для обеспечения актуальности информации и осуществления изменений.

2.3 Описание логической структуры

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

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

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

2.4 Связи между составными частями программ

Связи между объектами навигационной системы показаны на рисунке 3. Центральным звеном является объект «Аккаунт», т.к. все перечисленные выше действия могут выполняться только с привязкой к конкретному пользователю.

Рисунок 3: – Связь модулей системы

Взаимодействие объектов «Аккаунт» и «Маршрут», как видно на диаграмме, является наиболее активным. Для обеспечения быстрой работы системы необходимо использовать высокоскоростные интерфейсы к БД в виду частых обращений как к данным аккаунта, так и к данным зданий.

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

Структура данной системы сразу несколькими важными преимуществами:

• простота реализации;
  
• использование открытого ПО;
• работа на широком спектре устройств

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

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

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

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