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

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

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

Введение

Начиная с 2000 года, мобильные технологии активно захватывают все новые и новые сферы человеческой деятельности. Совсем недавно, мобильный телефон для многих ассоциировался исключительно со средством для совершения деловых звонков. Сегодня более 50% покупок в США осуществляется с участием мобильного телефона http://internet2go.net/news/data-and-forecasts/global-survey-offers-more-data-shopping-and-smartphones, а в Москве и Петербурге внедряется система оплаты проезда в метро с помощью мобильных устройств. http://stepandstep.ru/catalog/your-news/119330/v-sankt-peterburge-testiruetsya-sistema-oplaty-metro-s-pomoschyu-mobilnogo-telefona.html

Тенденция последних лет - замещение традиционных устаревающих способов взаимодействия потребителя с окружающим миром на способы, предоставляемые мобильными инновациями. В прессе постоянно звучат новости о появлении систем мобильных платежей и прочих удобных сервисах http://kuban.kp.ru/daily/25693/896779/. Телефон скоро будет заменять человеку кошелек, видеокамеру, утреннюю газету, пропуск на работу. При этом, в каждом случае, при переносе в мобильный телефон, привычная нам вещь становится гораздо более удобной в обращении, нежели устаревший аналог. В случае с электронной газетой, например, есть возможность быстро узнать дополнительную информацию о персоне или прошедшем событии, просто кликнув на ссылку в статье.

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

Одна из вещей, которая еще не претерпела перенос в мобильный телефон - это привычная каждому карта лояльности. Большая часть жителей крупного города носит с собой довольно большое количество разнообразных скидочных карт. При этом, большая часть людей положительно отнеслась к идее носить все карты лояльности в телефоне http://www.adme.ru/research/romir-monitoring-bolee-poloviny-rossiyan-starayutsya-poseschat-tolko-te-magaziny-diskontnye-karty-kotoryh-u-nih-est-romir-monitoring-14672/.

С другой стороны, со стороны бизнеса также есть некоторая неудовлетворенность существующими устаревшими пластиковыми картами лояльности. Создание такой программы лояльности связано с большими затратами. Поддержка программы лояльности порой обходится еще дороже, когда приходится вносить изменения в существующую, уже запущенную, схему лояльности. Так, например, обновление программы лояльности для сети магазинов М.Видео обошлось этой организации более чем в 5 миллионов долларов и заняло длительное время. http://www.cityspb.ru/goto/153393/

Автором дипломной работы была предложена идея - перевести устаревающие программы лояльности на пластиковых картах на новый уровень развития, предложив потребителю держать карту лояльности в телефоне. На основе этой идеи был создан стартап-проект SmartKupon http://smartkupon.ru , представляющий собой сервис для создания накопительной программы лояльности на основе мобильных телефонов. В рамках этого проекта необходимо было разработать информационную систему, отвечающую довольно жесткому набору требований, предъявляемой текущей ситуацией на рынке программ лояльности. Для того чтобы быть востребованной, такая программа лояльности должна превосходить существующие пластиковые аналоги в десятки раз по эффективности и экономичности.

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

Предметная область, анализ существующих решений

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

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

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

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

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

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

Отметим основные минусы обычной пластиковой карты по сравнению с мобильной дисконтной:

· Пластиковая карта неинформативна, она не может передать владельцу никакой информации, кроме той, что на ней изображена;

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

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

В зависимости от назначения и уровня безопасности мобильные дисконтные карты могут быть разного вида:

· Представлять собой изображение со штрих-кодом и логотипом, которое можно передать с телефона на телефон. Изображение автоматически подбирается под размер экрана телефона в момент скачивания карты по ссылке, содержащейся в sms- или WAP-push-сообщении. Передача этой ссылки и есть передача карты; http://www.mdsrussia.com/card.html

· В некоторых случаях, карта выполнена в виде специального JAVA-приложения, которое устанавливается только на один телефонный аппарат и привязано к серийному номеру телефона либо коду подтверждения. Это позволяет надежно защитить карту от копирования. http://www.cardmobili.com/

Также существуют системы отправки купонов на мобильный телефон. Обычно для купонов срок действия добавляется штрих-код, получаемый абонентом. В коде купона зашифрована дата окончания его действия, и система учета в торговой точке может определить действительность купона. Ограниченное количество купонов можно рассылать в период проведения какой-либо акции. Пример такой системы можно наблюдать у американского провайдера CellFire http://www.cellfire.com/whatiscf.php.

Отдельно стоит упомянуть о технических требованиях к телефону клиента для участия в подобных мобильных программах лояльности. Для получения и отправки sms-сообщений абоненту специальных настроек не требуется. Для получения штрих-кода на мобильный телефон абоненту требуется поддержка WAP или GPRS-интернет.

Для считывания штрих-кода с экрана телефона касса должна быть оснащена сканером определенного типа. Однако не все торговые точки оснащены такими сканерами. В случае распространенных лазерных сканеров, считывание с экрана телефона невозможно, так как лучи лазера попросту отражаются от экрана телефона. Американская компания CardStar http://www.mycardstar.com/ разработала приложение для перевода дисконтных карт в мобильный телефон и в итоге данное рещение оказалось неработоспособным для большинства существующих торговых точек http://www.youtube.com/watch?v=ML2Vd3zPHKk.

Российский опыт.

В России мобильная технология впервые появилась в 2005 году и на сегодняшний день ее уже используют такие компании, как магазины одежды Fasshion Street и Silver Stone, аптеки «НольТри», крупнейшая московская сеть клиник «МедЦентрСервис», турагентства «Горячие туры», автосалоны «Автомир-Ростов» и многие другие. На очереди сеть спортивной одежды «Спортмастер» и еще несколько крупных торговых сетей.

Зарубежный опыт.

В 2001 году, в одной из статей рассылка мобильных купонов провозглашалась «новой и самой многообещающей тенденцией», а в 2006 году представитель американских интеграторов сообщил о рекордном уровне отклика по дистрибуции мобильных купонов на скидки - 29%.

Мировая сеть фастфуд McDonald's с 2006 года использует мобильные купоны и считает это направление перспективным. В Швеции, к примеру, мобильные купоны McDonald's были разосланы 2500 потребителям, и 25% их воспользовались предложением. Два гиганта - McDonald's и NTT DoCoMo - подписали соглашение об организации венчурного предприятия, которое будет затрагивать как интересы посетителей сети ресторанов McDonald's, так и абонентов самого крупного мобильного оператора Японии - NTT DoCoMo. У TT DoCoMo 52 млн абонентов. Ежегодно японские рестораны McDonald's посещают свыше 1,4 млрд человек. Что касается Японии в целом, то аналогичные технологии распространены там настолько широко, что давно никого не удивляют.

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

o Smarbucks http://www.starbucks.com/coffeehouse/mobile-apps/starbucks-card-mobile

o Domino Pizza http://www.pcworld.idg.com.au/review/mobile_phones/dominos-pizza/iphone_app_v1_1/326167

o Subway http://www.marketingweek.co.uk/subway-launches-mobile-device-loyalty-scheme/3014085.article

o Carl's Jr http://www.crunchgear.com/2010/12/27/carls-jr-and-hardees-lead-the-way-in-interactive-iphone-check-in-social-rewards/

o Pizza Hut http://www.pcworld.idg.com.au/article/339382/ipizza_pizza_hut_launches_iphone_app/

Уже существующие программы лояльности постепенно переходят в мобильный телефон:

o X5 Retail Group http://goo.gl/ygRGJ

o Малина http://malina.ru/promo/mobilecardnew

o Air Miles http://smr.newswire.ca/en/air-miles/new-air-miles-mobile-application

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

Наилучшей моделью для создания подобной системы лояльности является модель коалиционной программы лояльности http://en.wikipedia.org/wiki/Loyalty_program. С одной стороны, такая схема наиболее масштабируема и наиболее привлекательна для пользователя, а с другой стороны, создание информационной системы под такую программу лояльности на мобильных устройствах представляется довольно сложной задачей. При добавлении «мобильности» к уже существующей отлаженной схеме, разработка накопительной программы лишь усложняется. мобильный дисконтный пластиковый карта

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

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

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

При этом:

· Клиентские приложения должны быть разработаны под все основные мобильные платформы.

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

· Каждый пользователь системы имеет свой персональный счет - количество баллов.

· Должно быть разработано устройство для валидации мобильной карты лояльности с экрана телефона.

· Каждая операция, производимая клиентом, должна фиксироваться в системе и заноситься в статистику.

· Система должна нормально функционировать при высоких нагрузках.

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

· Учет транзакций, основанный на кодах валидации, должен быть защищен от мошенничества.

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

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

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

· Мобильные приложения должны иметь возможность работать автономно.

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

· Сбор функциональных требований к системе

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

· Разработка и внедрение процесса управления качеством

Сбор функциональных требований к системе

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

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

1. Собираются требования в упрощенной форме, основанные на опросах и отзывах пользователей

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

3. Каждый пункт этого документа комментируется разработчиками.

4. В результате появляется спецификация к выбранной функциональности.

5. По спецификации делаются тесты.

6. С помощью тестов проводится приемочное тестирование.

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

Стоит отметить, что способ написания и хранения спецификации был изначально выбран не самым лучшим способом. Для первых версий спецификации, использовалась концепция MindMap http://en.wikipedia.org/wiki/Mind_map и сервис CoMapping http://comapping.com (Рис 1). Данный подход был изначально привлекателен за счет возможности раскрытия и скрытия веток спецификации, но затем было принято решение отказаться от использования MindMap, когда спецификация сильно увеличилась в размерах и возникли сложности отсылки к какому-либо конкретному пункту спецификации.

Рис. 1

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

· Спецификация разделена на разделы. Каждый раздел соответствует некоторой отделимой функциональности.

· Каждая функциональность соответствует набору предложений в утвердительной форме. Это - правила, определяющие данную функциональность.

· Клиентское приложение считается готовым к использованию, ТОЛЬКО если оно соответствует какой-то из версий спецификации.

· Клиентское приложение считается соответствующим спецификации, если реализация всех его возможностей соответствует спецификации.

· Реализация функциональности на клиентском приложении считается готовой к выпуску определенному кругу пользователей, если все правила для нее выполняются (то есть каждое правило проверено тестами).

· Ссылки на пункты спецификации делаются следующим образом “по пункту 3.4 спецификации версии 1.0”. При этом 3 - это номер функциональности, а 4 - это номер правила.

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

· Для работы над спецификацией используется сервис google docs.

· Изначально документ со спецификацией НЕ является утвержденной спецификацией по причине того, что в этот документ постоянно могут вноситься дополнения и корректировки.

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

o ВСЕ, что не будет включено в следующую версию документа переносится вниз документа.

o Назначается собрание разработчиков. На собрании должны присуствовать все разработчики клиентов.

o На собрании вся спецификация зачитывается, разработчики высказывают комментарии, пожелания и возражения.

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

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

1. Если функциональность не охватывает все платформы, то к названию приписываются названия платформ, для которых функциональность будет реализована в виде: [только для: Android, iPhone, Windows Mobile, Symbian]

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

1. Синхронизация запускается при каждом запуске приложения, сворачивании/разворачивании приложения. Синхронизация не блокирует UI.

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

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

4. Если в ответе на запрос синхронизации приходит запрос “add” уже скачанного купона, то необходимо загрузить новые изображения и CouponInfo. Старые изображения и CouponInfo нужно удалить.

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

6. Если хотя бы какая-то часть данных, получаемых в процессе синхронизации содержит некорректные данные (например, в картинке BASE64=”123” или в тексте описания купона не закрыты теги HTML), клиент не должен показывать сообщение об ошибке. Клиент не должен показывать купон в списке доступных\взятых купонов и обязательно должен написать лог с ошибкой.

7. Изменения в списках купонов, которые требует сделать сервер должны применяться к списку текущих просматриваемых купонов моментально. Если возможно, в такой ситуации переводится обзор к следующему купону, иначе на предыдущий купон, а если и это не возможно (это был последний купон), то закрывается окно доступных купонов и показываем неблокирующее сообщение TEXT_NO_COUPONS

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

9. Клиент должен указывать, что все ответы от сервера должны приходить в сжатом виде согласно протоколу. Исключением являются картинки, которые сжимать не надо.

Стоит отметить, что в пункте 7 приведена ссылка на текст, (TEXT_NO_COUPONS). Все тексты, используемые в приложении были выделены в отдельный документ. Это позволило отделить разработку функциональности от разработки дизайна и usability.

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

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

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

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

В самом начале, были выделены две основные компоненты: сервер и клиентские приложения. На основе такой схемы был сделан первый простейший прототип. Сервер общался с клиентом iPhone через HTTP запросы (XML протокол). Сервер основан на TomCat. На этом этапе, клиентское приложение не сохраняло состояние.

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

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

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

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

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

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

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

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

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

На Рис. 2 представлен экран приложения под платформу Android. Как видно из рисунка, интерфейс данной платформы ориентирован на сенсорные экраны. По этой причине, приложение на этой платформе значительно похоже не приложение под iPhone.

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

Также стоит отметить, что интерфейс приложения для j2me предельно похож на интерфейс для платформы Android.

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

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

Разработка и внедрение процесса контроля качества

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

Стоит выделить два этапа контроля качества:

1. Во время разработки мобильных приложений

2. Во время эксплуатации системы

Во время разработки мобильных приложений, ситуация осложняется тем, что ведется разработка под множество платформ. Также проблемой является тот факт, что в случае с мобильным приложением, нет возможности полностью автоматизировать процесс тестирования так, как это сделано для сервера с помощью JMeter http://jakarta.apache.org/jmeter/. В итоге, время полного ручного тестирования приложения под одну платформу занимало более 5 часов.

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

Процесс контроля качества в момент разработки

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

Тестирование делалось на основе спецификации. Спецификация представляет собой список функциональностей приложения (например "Отображение купона"). Каждая функциональность содержит набор правил, которые должны выполняться, чтобы считалось что функциональность на клиенте «принята». Пример правила - "На купоне показывается количество монеток, соответствующее полю "price" в протоколе".

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

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

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

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

Вот пример правильного тест-кейса, созданного в рамках разработанного процесса контроля качества: ================================= Проверяем что 0 монеток правильно отобразиться на купоне: начальные условия: - На сервер закачан купон с price=0, купон выдается - Проведена синхронизация действия: - Найти обозначенный выше купон ожидаемый результат: - Купон будет отображаться и на нем будет 5 изображений монеток. =================================

Стоит отметить, что тест-кейсами невозможно покрыть абсолютно все случаи. Например, если значение price может быть от 0 до 100, то создавалось как минимум 3 тест-кейса: на 0 price, на 100 и на 66.

Когда для функциональности все правила расписаны и по ним написаны тест-кейсы - создавался ТЕСТ для приемки функциональности. Тест - это некая последовательность действий, совершаемая для проверки функционала на всех перечисленных тест-кейсах. По сути для создания теста, нужно взять все тест-кейсы, которые были выписаны для данной функциональности и объединить их в нечто единое. Действия могут быть 2х вариантов: "сделать что-то" и "проверить что что-то выполняется"

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

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

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

Пример теста:

============================= ТЕСТ: 1. Сбросить клиент и базу данных. 2. Добавить в базу 5 купонов: price=0, price=3, price=5, price=6, price=-1, 3. Запустить синхронизацию 4. Проверить что первый купон - с 0 монетами на купоне, второй - с тремя, третий с пятью, четвертый монеты не отобразил, пятый купон не показался на клиенте. =================================

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

На Рис. 8 представлен результат работы тестовой системы для одного из тестов:

Рис. 8

Для автоматизации процесса тестирования была создана система, схема которой изображена на Рис. 9.



Рис. 9

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

В итоге, разработанная система позволила значительно сократить время на тестирование одного клиентского приложения - с 5 часов до 20 минут.

Процесс контроля качества во время эксплуатации системы

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

Рис. 10

Как видно из Рис. 10, процесс контроля качества здесь начинался с этапа регулярных инспекций кода. На этом этапе, каждый «опасный» участок кода программы оборачивался в try/catch блок, и при возникновении исключения в таком месте, создавалась запись в логах с тегом ERROR. При этом каждому try/catch блоку присваивается уникальный идентификатор.

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

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

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

Заключение

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

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

На момент написания диплома, разработанная информационная система функционирует в режиме 24/7, продуктом можно воспользоваться.

Список литературы

1. Lessons Learned in Software Testing, Cem Kaner, James Bach, Bret Pettichord. Wiley; 1 edition (December 15, 2001)

2. The Mythical Man-Month: Essays on Software Engineering, Frederick Brooks, Addison-Wesley, 1995

3. Testing Extreme Programming, Lisa Crispin, Addison-Wesley Professional; 1 edition (November 4, 2002)

4. Succeeding with Agile: Software Development Using Scrum, Mike Cohn, Addison-Wesley Professional; 1 edition (November 5, 2009)

5. Information Systems Today: Managing the Digital World (4th Edition), Joseph Valacich, Prentice Hall; 4 edition (March 13, 2009)

6. Mobile Application Security, Chris Clark, McGraw-Hill Osborne Media; 1 edition (January 15, 2010)

Размещено на Allbest.ru

...