Оптимизация процесса ведет к совершенству

Проведение предварительного исследования

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

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

Вот некоторые аспекты, которые стоит учесть:

Маркетинг

• Сколько потребители готовы заплатить за приложение или за другие услуги (такие как передача данных)?
• Где продавать? Каким образом пользователи находят и покупают приложение, и потребуются ли дополнительные расходы, чтобы покупатели проще находили продукт?
• Каким образом происходит оплата покупки? Каких дополнительных операционных затрат можно ожидать?
• Будут ли предоставляться бесплатные пробные и демо-версии?

Разработка

• Достаточен ли уровень собственной технической компетентности?

Контроль качества

• Будет ли приложение проходить проверку с помощью стандартной программы тестирования и сертификации, такой как Symbian Signed или Java Verified™ Program? Сколько стоит проверка?
• Нужно ли получить Certificate ID, который является обязательным для Symbian Signed? Получение сертификата может занять некоторое время. Поэтому, если вы планируете сертифицировать свое приложение, следует отправить заявку заранее.

Текущее обслуживание и поддержка

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

Разработка концепции

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

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

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

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

• Что делает приложение?
• Какими качествами обладает приложение?
• Какие зависимости приложения известны?

Требование также дает руководства для всех последующих стадий проекта, включая продвижение
Хорошее требование включает в себя следующие характеристики:

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

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

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

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

• Требования безопасности платформы. Безопасность платформы для операционной системы Symbian включает такой вопрос, как экранирование данных, которое должно быть предусмотрено дизайном архитектуры приложения. Приложения Flash Lite от Adobe должны также содержать механизм защиты, выбор которого зависит от используемой версии Flash. Крайне важно на ранней стадии разработки принять во внимание эти механизмы безопасности и предусмотреть, как они будут встроены в приложение.

• Требования платформы. Чтобы уменьшить проблемы на стадии тестирования, заранее учтите требования платформы S60 и критерии сертификации Symbian Signed или Java Verified Program. Критерии тестирования для Symbian Signed и Java Program доступны на http://www.symbiansigned.com и http://www.javaverified.com.

Дизайн взаимодействия и создание прототипов

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

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

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

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

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

Визуальный и информационный дизайн

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

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

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

Внедрение

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

Независимо от методологии, необходимо помнить следующее:

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

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

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

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

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

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

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

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

Совет: Nokia Energy Profiler – это автономная система тестирования и измерения для устройств на платформе S60 от Nokia. Используйте этот инструмент для тестирования и контроля потребляемой приложением энергии в режиме реального времени на целевом устройстве. Обратитесь к руководству Quick Start для более подробной информации.

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

Системное тестирование

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

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

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

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

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

Tестовые данные могут содержать большое количество информации, однако все они должны иметь:

• Название;
• Описание или инструкции по тестированию;
• Описание ожидаемых результатов.

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

Тестирование на целевых устройствах
Когда приложение уже почти готово, его можно протестировать на настоящем целевом устройстве (или устройствах). Установите приложение и запустите определенные тестовые данные. Forum Nokia предлагает сервис Удаленный доступ к устройству, который позволяет тестировать приложения на различных устройствах Nokia Symbian удалённо через Интернет. Сервис бесплатный и доступен всем членам Forum Nokia.

Обратите внимание, что если ваша цель протестировать или внедрить приложения для операционной системы Symbian, использующие возможности конфиденциальности устройства, вам необходимо в первую очередь подать заявку на Symbian Signed Developer Certificate, чтобы получить возможность проверить приложение на целевом устройстве. Дополнительная информация доступна на www.symbiansigned.com.

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

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

Для более подробной информации ознакомьтесь со следующими документами:

• Nokia Test Criteria for Symbian C++ Applications
• Nokia Test Criteria for Java™ ME Applications
• Testing and signing section of the S60 5th Edition C++ Developer's Library

Сертификация

Различные каналы распространения приложений требуют наличие сертификата либо Java Verified Program, либо Symbian Signed. Эти широко распространенные программы тестирования и сертификации гарантируют целостность приложения для мобильных устройств. В дополнение, программы сертификации тестируют приложение на соответствие общепринятым критериям и повышают его безопасность за счет сертификации источника приложения.

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

Подпись обязательна для всех базовых приложений C++. Механизм защиты операционной системы Symbian v9 предусматривает несколько уровней доверия и, соответственно, несколько видов сертификатов, обеспечивающих доступ к уровням защиты.

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

Java Verified Program
Java Verified По инициативе промышленных компаний организована программа Java Verified Program по организации централизованного тестирования приложений Java™ Platform, Micro Edition (Java™ ME) applications. Access, Motorola, Nokia, LG, Orange, Samsung, Sony Ericsson, Sun, и Vodafone объединили усилия и предложили разработчикам и их потребителям унифицированные критерии тестирования.

Механизм защиты для Java™ ME
MIDP 2.0 использует специальный механизм защиты, который выделяет четыре предметные области. Характеристики и функции, доступ к которым может получить приложение, различаются в каждой области. Цифровая подпись приложений настроена на доверие к корневому сертификату, который назначается для определенного домена. Таким образом, если корневой сертификат был назначен для области А, все приложения, настроенные на доверие к этому сертификату, будут получать преимущества области А.

Для более подробной информации о механизмах защиты приложений Java ME смотрите Testing and signing section of the S60 5th Edition C++ Developer's Library и MIDP 2.0: Signed MIDlet Developer's Guide.

Примечение: Ovi Store требует Java Verified Program или статус Thawte для приложений Java ME и статус Symbian Signed для любого приложения в формате .sis. Подробную информацию вы можете найти на https://publish.ovi.com.

Для более подробной информации ознакомьтесь со следующими документами:

• MIDP 2.0: Signed MIDlet Developer's Guide
• Testing and signing section of the S60 5th Edition C++ Developer's Library

Текущее сопровождение и постпроизводство

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

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

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

Важно: убедитесь, что пользователи не могут скачать нерабочие версии или варианты вашего приложения. Если же всё-таки такое случилось, крайне важно убедиться, что им не пришлось платить за эти загрузки.

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

Контроль качества и экспертиза

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

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

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

Продвижение приложения

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

• Какие существуют возможные каналы сбыта?
• Есть ли возможность совместных рекламных проектов с другими участниками рынка, например с мобильными операторами?
• Каким образом и когда работа по созданию концепции разработки и прототипов может повлиять на продвижение продукта?
• Какова история приложения с точки зрения создания бренда? Какое маркетинговое обращение создать? Что сделает приложение неповторимым

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

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

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

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

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

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

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