Этапы разработки тестирования и ввода в эксплуатацию мобильных приложений (Основные этапы формирования мобильного приложения)

Содержание:

ВВЕДЕНИЕ

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

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

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

ОСНОВНЫЕ ЭТАПЫ ФОРМИРОВАНИЯ МОБИЛЬНОГО ПРИЛОЖЕНИЯ

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

Таким образом, существуют и основные этапы в разработке и выпуске програмного обеспечения в свет.

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

Проанализировать требования и определения спецификаций программного обеспечения путем выбора технологии проектирования. Здесь выбирается подход к проектированию программного обеспечения — структурный или объектно-ориентированный Каждый из подходов имеет свои преимущества и недостатки. При структурном подходе процессы и данные существуют отдельно друг от друга (как в модели деятельности организации, так и в модели программной системы), причем проектирование ведется от процессов к данным. Это является главным недостатком структурного подхода. В объектно-ориентированном подходе основная категория объектной модели — класс. Он объединяет в себе на элементарном уровне как данные, так и операции, которые над ними выполняются (методы). Разделение процессов и данных преодолено. Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы, поэтому объектно-ориентированные системы более открыты и легче поддаются внесению изменений. Кроме того, объектно-ориентированная модель наиболее адекватно отражает реальный мир, представляющий собой совокупность взаимодействующих объектов, взаимодействие происходит посредством обмена сообщениями между объектами. Однако на практике диаграммы, отражающие специфику объектного подхода (диаграммы классов и т.п.), гораздо менее наглядны и плохо понимаемы непрофессионалами, поэтому понимание заказчиком разработчика обеспечивается на сегодняшний день, в основном, структурными методами.

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

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

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

Формулировка задачи для программы – это само её объявление, её постановка. Но просто формулировка ничем не поможет программистам. Для этого и существует второй под этап – это анализ задачи.

Анализ задачи – это подробный просмотр задачи с определением и выявлением входной и выходной информации. (входная информация по задаче — это данные, поступающие на вход задачи и используемые для её решения, выходная информация – это результат.)

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

Еще одним методом анализа является введение математической модели. Для более четкого понимания рассмотрим определения математической модели, объявленные в разных (математических, физических, экономических и т.д.) источниках и попробуем создать собственное определение, подходящее для программирования.

«Математическая модель - система уравнений и концепций, используемых для описания и прогнозирования данного феномена или поведения объекта. Математические модели находят как практическое, так и теоретическое применение (иногда одновременно). Практические задачи, в которых используются математические модели, включают создание новых материалов, предсказание погоды, проверку прочности мостов, самолетов и тому подобного» - это определение используется в физике, химии и математической биологии.

«Математическая модель — это упрощенное описание реальности с помощью математических понятий. Существует два основных класса задач, связанных с математическими моделями: прямые и обратные. В первом случае все параметры модели считаются известными, и нам остается только исследовать её поведение. А во втором какие-то параметры модели неизвестны, и требуется их найти, сопоставляя поведение реальной системы с её моделью.» - данное определение используется в основном в экономике.

«Математическая модель — это математическое представление реальности» - это определение созданное математиками.

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

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

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

Для себя отмечу, что это очень сродне русской поговорке: «как назовешь корабль – так он и поплывет» - критичное авторское мнение.

ПРОЕКТИРОВАНИЕ И ДИЗАЙН

Здесь наша работа делится на два направления: проектирование UI (user iterface), и UI-дизайн, то есть дизайн привычном понимании.

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

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

В результате мы получаем:

• карта экранов;
• статичный или интерактивный прототип приложения;
• отрисованные экраны и элементы интерфейса.

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

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

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

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

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

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

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

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

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

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

В зависимости от масштаба проекта дизайн может занять одну неделю или несколько месяцев

РАЗРАБОТКА ПРОГРАММНОЙ ЧАСТИ

Программирование — один из главных этапов. Написание кода любого приложения делится на фронтенд и бэкенд.

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

На этапе бэкенда разрабатывают серверную часть приложения — она отвечает за передачу данных между пользователями или ресурсами.

Итогом всех этих процедур является первый релиз долгожданного приложения.

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

Нативные приложения написаны для конкретной мобильной платформы: iOS, Android, Windows. Язык программирования, который используется для написания таких сервисов, поддерживается только одной платформой. Например, Swift и Objective-C понимает только iOS, а Java — только Android.

Если приложение должно стать важной частью бизнеса и влиять на финансы тогда можно делать

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

Плюсы нативных приложений:

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

Минусы нативных приложений:

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

При создании кроссплатформенной разработки используются общие наборы средств разработки (SDK). Из-за этого кроссплатформенные сервисы не используют все нативные преимущества каждой платформы. Зато сделать такое приложение дешевле — это оптимальный вариант для проектов с ограниченным бюджетом.

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

Плюсы кроссплатформенных приложений:

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

Минусы кроссплатформенных приложений:

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

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

• Насколько быстрое и отзывчивое приложение вам нужно?
• Насколько важны бизнес-процессы, которые встроены в приложение?
• Насколько сложные функции будет выполнять ваше приложение?

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

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

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

ТЕСТИРОВАНИЕ

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

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

1. Объект испытаний;
2. Цель испытаний;
3. Состав предъявляемой документации;
4. Технические требования;
5. Порядок проведения испытаний;
6. Методы испытаний.

В первых трех разделах указывают: наименование, область применения, обозначение испытуемой программной системы; цель проведения испытаний; перечень документации, предъявляемой перед проведением испытаний. Раздел «Технические требования» может состоять из двух подразделов: 1) требования к программной документации; 2) требования к техническим характеристикам. В первом подразделе должны быть указаны требования к комплектности, содержанию и качеству предъявляемой документации; второй подраздел содержит описание требований к характеристикам программы применительно к условиям эксплуатации и требований к информационной и программной совместимости. «Порядок проведения испытаний» предполагает указания: на последовательность испытаний, четкий порядок проведения каждого испытательного эксперимента, состав и структуру технических средств, с помощью которых будут проводиться испытания, перечень дополнительных программных и технических средств, необходимых для проведения испытаний. В разделе «Методы испытаний» приводятся описания используемых методов проведения испытаний. Методы следует приводить в последовательности, соответствующей последовательности перечисления технических характеристик в разделе «Технические требования». При этом должны быть приведены описания проверок с указанием результатов проведения испытаний, к которым могут относиться: перечень тестовых примеров, контрольных распечаток самих примеров и их результатов, таблиц, графиков и т.п. Сами тестовые примеры (распечатки, таблицы, графики и т.п.) даются в приложении. Заключение Содержит анализ выполненной работы, выводы о значимости проекта, рекомендации по использованию проекта, рекомендации, касающиеся возможности дальнейшей доработки или модернизации проекта и т.д. Практическим результатом работы над курсовым проектом является работоспособная программа и пакет документации, включающий в себя программные документы «Пояснительная записка» и «Руководство пользователя». Кроме того, на магнитном носителе должен быть представлен текст программы (исходный код) с необходимыми комментариями. Для защиты курсового проекта создается презентация из 10— 12 слайдов, в которой отражаются требования к программной системе, основные этапы ее разработки, диаграммы, модели данных, выводы по работе.

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

Элементы модульного тестирования:

синтаксическая проверка — проверка с использованием некоторого инструментального средства для выявления синтаксических ошибок в программном коде;

проверка соответствия стандартам кодирования — проверка кода на соответствие стандартам кодирования компании;

технический обзор программного кода.

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

Элементы интеграционного тестирования:

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

проверка промежуточных результатов — проверка всех промежуточных результатов и файлов на наличие и корректность;

проверка интеграции — проверка корректности взаимной передачи модулями информации.

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

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

Элементы выходного тестирования:

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

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

В ходе тестирования, ошибки возникающие в приложении разделяются на разные виды:

• Синтаксические – выявляемые статистическим контролем и диагностикой компиляторами и компоновщиком
• Ошибки выполнения, выявляемые автоматически: переполнение, защита памяти несоответствие типов зацикливание обнаруживаемые динамическим контролем: аппаратурой процессора run-time системы программирования операционной системой — по превышению лимита времени
• Программа не соответствует спецификации – выявляется целенаправленным тестированием
• Спецификация не соответствует требованиям - идентифицируется

испытаниями, бета-тестированием.

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

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

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

Технология тестирования, которая применяется на этапе разработки программного обеспечения, называется тестированием «стеклянного ящика» (glass box). Иногда эту технологию еще называют тестированием «белого ящика» (white box) в противоположность классическому понятию «черного ящика» (black box). При тестировании «черного ящика» программа рассматривается как объект, внутренняя структура которого неизвестна. Тестировщик вводит данные и анализирует результат, но он не знает, как именно работает программа. Подбирая тесты, специалист ищет интересные, с его точки зрения, входные данные и условия, способные привести к нестандартным результатам. Интересны для него прежде всего те представители каждого класса входных данных, при которых с наибольшей вероятностью могут проявиться ошибки тестируемой программы. При тестировании «стеклянного ящика» ситуация совершенно иная. Тестировщик (в данном случае сам программист) разрабатывает тесты, основываясь на знании исходного кода, к которому он имеет полный доступ. В результате он получает следующие преимущества.

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

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

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

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

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

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

ВВОД В ЭКСПЛУАТАЦИЮ

На стадии реализации выполняется непосредственно разработка программного приложения. На основе полученных моделей, а также требований нефункционального характера (требований к надежности, производительности и т.п.) формируется программный код, выполняется модульное тестирование. Обоснованием выбора средств разработки дается обоснование выбора языка программирования, приводятся основные факторы, влияющие на выбор среды разработки (сравнительная пригодность языка программирования для данной задачи, избранная методология и т.д.). Описание основных программных модулей системы выполняется в соответствии с ГОСТ 19.701—90 (ИСО 5807—85) ЕСПД. В него включаются исходные коды программных модулей, схемы алгоритмов программ, описание используемых методов, описание структуры программы. При разработке программного обеспечения работа считается законченной, когда завершенный программный продукт попадает к тем, для кого он был предназначен. В случае мобильного программного обеспечения это означает развертывание созданного вами приложения на пользовательских устройствах. Окончательным мерилом качества продукта является полезность приложения и то удовольствие, которое работа с ним доставляет пользователям. Чтобы эти цели были достигнуты, мобильное приложение должно попасть на реальные целевые устройства, а это означает, что его необходимо предварительно упаковать, а затем развернуть на мобильных устройствах каждого пользователя.

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

Поскольку детали упаковки и развертывания приложений определяются спецификой используемых типов устройств и программных технологий, приводится лишь краткий обзор вопросов, имеющих отношение к данной теме. Отдельные шаги процедуры упаковки различны для различных технологий: J2ME/J2SE, .NET Compact Framework и ряд технологий, основанных на использовании собственных кодов, требуют для упаковки и развертывания приложений выполнения разных последовательностей шагов. Для разных типов устройств, например, PDA, смартфонов или каких-либо специализированных устройств, предусмотрены различные процедуры инсталляции программного обеспечения, отличающиеся своими деталями. Выдавая своим пользователям телефоны, операторы сетей мобильной связи часто предлагают программное обеспечение, предусмотренное для динамической загрузки на эти устройства; у этих операторов имеются собственные стратегии установки и инициализации программного обеспечения. Комплекты документации, соответствующие различным технологиям устройств и операторам сетей мобильной связи, часто можно загрузить из Web.

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

ПРОДВИЖЕНИЕ МОБИЛЬНОГО ПРИЛОЖЕНИЯ

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

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

Интегрированная реклама на других приложениях.

Для этого необходимо совершить следующие действия.

Коммуницировать с потенциальными клиентами в тех приложениях, которые они уже установили.

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

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

Внедрить баннеры. Такие возможности широко предоставляет Google AdWords.

3.Контент-маркетинг.

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

• записывать аудио-подкасты;

• создать видеоролик;

• проявлять активность в социальных сетях.

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

4. Работа с лидерами мнений.

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

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

5. Промо-сайт.

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

Наличие промо-сайта дает дополнительные преимущества при продвижении мобильного приложения. Широко используется:

• возможность визуализации его особенностей;

• инструкции по применению мобильных приложений;

• контекстная реклама

• таргетинг в социальных сетях.

Рассмотрим, как ранжируются приложения.

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

• Общее число установок.

• Динамика установок. В. Google Play расчетный период составляет 48 - 72 часа.

• Рейтинг или оценки пользователей.

• Число комментариев.

• Динамика удалений приложения с устройства.

• Количество запусков приложения пользователями.

Специалисты по продвижению приложений для операционной системы Android утверждают, что на позиции в Google Play также влияет цена продукта и внешние ссылки. Место приложения в поисковой выдаче магазина зависит от релевантности названия и описания запросам пользователей, а также от качества скриншотов и иконок.

Чтобы приложение попало в ТОП, его должно установить большое число пользователей впервые дни после добавления в магазин. Число установок варьируется в зависимости от региона, категории и магазина. Порядок числа - тысячи и десятки тысяч установок в сутки.

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

Рассмотрим инструменты мониторинга посещаемости мобильного приложения.

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

Среди инструментов мониторинга посещаемости мобильного приложения можно выделить следующие.

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

BuzzLook - это русскоязычный сервис мониторинга социальных медиа: Facebook, "В Контакте" Livejournal, Flickr, YouTube и Twitter. Данная система мониторинга социальных медиа позволяет: следить за репутацией вашего бренда; изучать деятельность конкурентов в сети; отвечать на вопросы ваших клиентов в их среде (социальных сетях); собирать предложения от ваших клиентов; поддерживать ваши on-line сообщества; работать с возражениями в сети; исследовать рынки; лучше продвигать ваш продукт.

Twitalyzer - аналитическая программа-клиент для Google Play, позволяющая отслеживать количество переходов, анализирует позитивные и негативные комментарии и настроения и сегментирует аудиторию. Интегрирована с Google Analytics, выводит интерактивные диаграммы и графические инструменты.

Google Analytics.Analytics позволяет анализировать влияние мобильных технологий на ваш бизнес. Если вы разрабатываете мобильные приложения, вы можете воспользоваться SDK для iOS и Android, чтобы получать данные об их использовании.

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

Проведенный анализ направления мониторинга посещаемости мобильного приложения выявлено, что в приложение будет встроено две системы: Analytics и Яндекс.Метрика. Благодаря этим системам выявим ряд недостатков реализации, функционирования и реализации приложения, включая несоответствие мобильного приложения целям продвижения услуг.

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

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

Комплекс мероприятий направлен на продвижение приложения среди потенциальных потребителей, которые являются жителями стран России и СНГ, т.к приложение в первую очередь направлена для получения точной информации и местах объектов.

Данный комплекс включает в себя следующие мероприятия.

. Регистрация приложения в системе Google Play.

. Внедрение счетчиков статистики посещения.

. Регистрация в социальных сетях.

. Создание промо-сайта.

. Регистрация приложения в бесплатных каталогах.

. Регистрация приложения на досках объявлений.

Рассмотрим их подробнее.

. Регистрация приложения в системе Google.

Регистрация проводится в три шага.

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Лекция «Этапы проектирование мобильных приложений» https://intuit.ru/studies/courses/574/430/lecture/9750?page
2. А. В. Рудаков Г. Н. Федорова «ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНЫХ ПРОДУКТОВ ПРАКТИКУМ» - http://b9509072.bget.ru/assets/book/3.pdf
3. Лекция «Основы тестирования и отладки Веб-приложений» https://intuit.ru/studies/courses/611/467/lecture/28808
4. Белов П.М. Основы алгоритмизации в информационных системах: Учебн. Пособие. Спб.: СЗТУ, 2003. http://www.ict.edu.ru/ft/005406/nwpi225.pdf
5. Основы алгоритмизации и программирования: Метод. указ. / Сост.: И.П. Рак, А.В. Терехов, А.В. Селезнев. Тамбов: Из во Тамб. гос. техн http://www.ict.edu.ru/ft/004758/terehov.pdf