Автор работы: Пользователь скрыл имя, 31 Мая 2013 в 11:36, дипломная работа
На основе этой идеи был создан стартап-проект SmartKupon6, представляющий собой сервис для создания накопительной программы лояльности на основе мобильных телефонов. В рамках этого проекта необходимо было разработать информационную систему, отвечающую довольно жесткому набору требований, предъявляемой текущей ситуацией на рынке программ лояльности. Для того чтобы быть востребованной, такая программа лояльности должна превосходить существующие пластиковые аналоги в десятки раз по эффективности и экономичности.
Введение 4
Предметная область, анализ существующих решений 6
Постановка задачи 12
Сбор функциональных требований к системе 15
Разработка архитектуры системы 20
Разработка и внедрение процесса контроля качества 27
Заключение 35
Необходимо разработать
При этом:
В процессе разработки системы решалось большое количество задач, от создания команды разработчиков до организации процесса приемочного тестирования всей системы. Далее будет рассказано о трех содержательных этапах разработки системы, демонстрирующих специфику разрабатываемой информационной системы:
Основной задачей на этом этапе было изучение предметной области, формирование списка требований к разрабатываемым компонентам системы и создание спецификации. Данному направлению исследований было отведено особое внимание, так как лишь утвердив единые требования для компонент системы, можно создать единую спецификацию для разработчиков и тем самым обеспечить высокий уровень качества производимого ПО.
Приведем пример процесса сбора функциональных требований к мобильным приложениям:
Использованные методы оказались довольно эффективными, так как в итоге разработка на всех платформах шла параллельно, что позволило сократить временные расходы на переключение тестировщиков между задачами тестирвоания разных платформ.
Стоит отметить, что способ написания и хранения спецификации был изначально выбран не самым лучшим способом. Для первых версий спецификации, использовалась концепция MindMap21 и сервис CoMapping22 (Рис 1). Данный подход был изначально привлекателен за счет возможности раскрытия и скрытия веток спецификации, но затем было принято решение отказаться от использования MindMap, когда спецификация сильно увеличилась в размерах и возникли сложности отсылки к какому-либо конкретному пункту спецификации.
Рис. 1
В итоге, для составления спецификации на основе требований были сформулированы следующие правила (пример для мобильных приложений):
В результате, была разработана единая спецификация, описывающая общее поведение всех клиентских приложений. Ниже приведен пример такой спецификации, описывающей поведение приложений при синхронизации пакетов данных:
Стоит отметить, что в пункте 7 приведена ссылка на текст, (TEXT_NO_COUPONS). Все тексты, используемые в приложении были выделены в отдельный документ. Это позволило отделить разработку функциональности от разработки дизайна и usability.
Анализируя приведенный фрагмент спецификации, можно сделать вывод, что данный формат наиболее удобен как для разработчика, так и для тестировщика.
Подводя итог, можно сказать, что на этапе написания функциональных требований к системе был организован и внедрен процесс написания технической документации с учетом специфики разрабатываемой системы, специфики коллектива разработчиков и процесса разработки.
Уже на этапе обдумывания архитектуры, стало понятно, что конечная информационная система будет слишком сложна для того, чтобы реализовать все ее компоненты одновременно. Основной сложностью виделась как раз самая главная часть – единая электронная карта лояльности. По этой причине, было решено разрабатывать систему поэтапно, от самого примитивного состояния, до желаемой архитектуры. При этом на каждом промежуточном этапе это должна быть законченная информационная система, которую можно было тестировать на первых пользователях.
В самом начале, были выделены две основные компоненты: сервер и клиентские приложения. На основе такой схемы был сделан первый простейший прототип. Сервер общался с клиентом iPhone через HTTP запросы (XML протокол). Сервер основан на TomCat. На этом этапе, клиентское приложение не сохраняло состояние.
Следующим усложнением архитектуры было введение понятия состояния для клиентского приложения. В результате, у клиентского приложения появилась возможность работать автономно. При каждом соединении с сервером, клиент отсылал свое текущее состояние, а сервер отвечал на него с описанием действий, которые клиенту нужно совершить, чтобы привести его состояние в актуальное с точки зрения сервера.
Следующий этап – добавление в систему средства для валидации мобильных купонов. Здесь было введена сущность кода валидации – важнейшего элемента системы накопительной программы лояльности. Изначально, код валидации не был уникальным, для придания уникальности потребовалось довольно длительное время. Одновременно с кодами валидации был добавлен сайт для статистики и учета валидаций. Сервер валидации был выделен в отдельную сущность, так как имел особое стратегическое значение – если что-то случалось с сервером клиентского приложения, это не должно было сказаться на сервере валидации.
Далее в систему добавилась панель администратора для добавления контента. До этого, любое добавление контента делалось напрямую через базу данных с помощью MyPhpAdmin. Панель администратора по сути содержала два модуля – генерация контента, одинакового для всех пользователей и генерация персонального контента, такого как код валидации или количество накопленных баллов. В итоге клиент получал через протокол часть общей информации, загружаемой на сервер через административную панель, так и персональные данные, которые сервер генерировал индивидуально для каждого клиентского приложения. Авторизация мобильных приложений производилась на основе уникального идентификатора устройства.
Все серверные компоненты были объединены в одну базу с самого начала разработки, так как по сути все компоненты системы – от сайта до устройства для валидации так или иначе связаны.
По мере развития системы, увеличивалось количество клиентов, сложность системы возрастала и в нее добавились еще некоторые компоненты - например, компоненты для тестирования.
При разработке архитектуры системы, общие для мобильных приложений данные концентрировались на сервере. Например, даже список станций метро в городе отсылался клиентам по протоколу, а не писался разработчиками клиентов самостоятельно.
Лишь через значительное время в систему была добавлена сущность единой накопительной карты лояльности. При этом стоит отметить, что это добавление по сути не изменило архитектуру системы, был лишь немного модифицирован протокол. Это произошло, потому что архитектура изначально создавалась так, что вместо электронного купона могло бы быть что угодно – карта лояльности или даже кошелек для оплаты.
В качестве примера, доказывающего, что архитектура была разработана удачно, можно привести мобильные приложение и в особенности модуль карты проезда.
Благодаря тому, что спецификация клиентских приложений и система тестирования были разработаны своевременно, разработка приложений под разные платформы велась довольно быстро, так как каждый разработчик четко представлял как реализовать ту или иную функциональность.
На Рис. 2 представлен экран приложения под платформу Android. Как видно из рисунка, интерфейс данной платформы ориентирован на сенсорные экраны. По этой причине, приложение на этой платформе значительно похоже не приложение под iPhone.
Рис. 2
Самой сложной разработкой была разработка под платформу Java. Как видно из Рис. 3 и Рис. 4, в конечном итоге, удалось достичь тех же возможностей, что на платформах iPhone и Android. Для этого использовалась кросс-платформенная библиотека.
Рис. 3
На Рис. 5 показана работа приложения на платформе j2me на эмуляторе.
Рис. ХХ
Также стоит отметить, что интерфейс приложения для j2me предельно похож на интерфейс для платформы Android. (см. Рис. ХХ и Рис. ХХ)
Рис. 5
Одной из компонент, которая хорошо показывает верность принятого архтектурного решения – карты проезда. На Рис. 7 приведен пример работы библиотеки для центра Петербурга. Стоит отметить схожесть с картой от популярного сервиса google maps, показанного на Рис. 6. Было разработано средство для автоматической генерации карты в векторном формате. Благодаря этому, размеры файлов карт проезда уменьшились в сотни раз по сравнению с картами Google.