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

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

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

Лей Вильямсон, инженер, Software Group, IBM

author photoЛей Вильямсон (Leigh Williamson), заслуженный инженер IBM, работает в лаборатории IBM в Остине (шт. Техас) с 1988 года. Он внес большой вклад выполнение важнейших проектов по созданию различных программных продуктов IBM, включая OS/2, DB2®, AIX® и WebSphere Application Server. В настоящее время он является членом группы Chief Technology Office по программным продуктам IBM Rational и принимает участие в формировании стратегий развития для продуктов с брендом Rational и в определении облика решений при разработке мобильных приложений. Л. Вильямсон имеет степень бакалавра по вычислительной технике, полученную в университете Nova, и степень магистра в области вычислительной техники, полученную в университете шт. Техас.



04.10.2013

Обзор

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

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

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

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

Корпорация IBM заслужила репутацию компетентного и ответственного партнера по разработке корпоративного программного обеспечения для заказчиков во многих отраслях. Основное внимание в этой статье уделяется всеобъемлющему подходу к созданию мобильных бизнес-приложений, которые используют значительные инвестиции в большие транзакционные системы, уже совершенные большинством компаний из списка Fortune 1000. Описываемый подход сочетает наилучшие типовые методики коллективного управления жизненным циклом программного обеспечения с более новыми уникальными требованиями, которые характерны для создания мобильных приложений. Этот подход призван оказать содействие всем категориям участников проекта по созданию мобильного бизнес-приложения для предприятия.

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

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

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

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

Форм-фактор и удобство пользования

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

Форм-фактор и технология ввода информации пользователем

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

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

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

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

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

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

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

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

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

Технологии и стратегия реализации.

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

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

Нативная реализация приложения

Нативная реализация — это написание приложения с использованием языка программирования и программных интерфейсов, предоставленных мобильной операционной системой устройства конкретного типа. Например, нативная реализация для iPhone будет написана с использованием языка Objective-C и API-интерфейсов операционной системы iOS, которые предоставляет и поддерживает компания Apple. Нативная реализация приложения имеет преимущество в том смысле, что она обеспечивает этому приложению наивысшую "верность" при его использовании на соответствующем мобильном устройстве. Поскольку используемые API-интерфейсы являются низкоуровневыми и привязаны к конкретному устройству, приложение способно полностью задействовать каждую функцию этого устройства и каждый представленный им сервис.

Нативные реализации мобильных приложений не могут быть портированы (перенесены) ни на какую другую мобильную операционную систему. Если нативное приложение для среды Apple iOS необходимо исполнять на устройстве под управлением Android, придется полностью переписать это приложение, а сопровождение обеих версий осуществлять параллельно. Это существенно повышает расходы на использовании такого способа реализации мобильного бизнес-приложения.

Веб-приложения

Более новые смартфоны и планшеты поставляются с заранее установленными на них усовершенствованными веб-браузерами. Вполне возможна реализация мобильного бизнес-приложения, которое будет представлять собой стандартное веб-приложение, дополненное специальной таблицей стилей для адаптации к мобильному форм-фактору и к специфике своего представления на мобильном устройстве. Мобильные приложения, реализованные на основе этого подхода, поддерживают максимально широкий ассортимент разнообразных мобильных устройств, поскольку веб-браузеры поддерживают технологии JavaScript и HTML5 вполне единообразным образом вне зависимости от устройства. Существует несколько библиотек для виджетов Web 2.0 (коммерческих и с открытым исходным кодом), таких как Dojo Mobile, которые оказывают содействие при использовании данного подхода. Кроме того, применение модели веб-программирования при реализации мобильного приложения предоставляет преимущество таким предприятиям, которые уже имею подготовленных разработчиков, владеющих языками и методами для создания веб-приложений.

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

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

Гибридная реализация мобильного приложения

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

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

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

Организационные аспекты реализации, создание приложения и коллективная деятельность.

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

Полный жизненный цикл проекта

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

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

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

Интеграция нескольких инструментов

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

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

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

Несмотря на наличие уникальных аспектов у разработки мобильного приложения, многие роли и задачи в рамках жизненного цикл разработки аналогичны соответствующим ролям и задачам при разработке других видов программного обеспечения корпоративного класса. В статье (см. раздел Ресурсы) под названием Measuring Agility and Architectural Integrity ее автор Уокер Ройс (Walker Royce) описывает ключевые приемы и методы эффективного создания программного обеспечения с использованием динамичной разработки и принципа test-first. Описанные в этой статье методы разработки программного обеспечения идеально подходят для проектов по созданию мобильных приложений.


Выбор подхода к созданию мобильного приложения

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

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

Коллективная деятельность в составе расширенной рабочей группы

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

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

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

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

Расширенный подход к разработке

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

Первый компонент — о котором сразу же вспоминает большинство людей, когда речь заходит о создании мобильного приложения – это код пользовательского интерфейса и клиентская логика, функционирующая на мобильном устройстве. Код пользовательского интерфейса в значительной степени будет состоять из кода на языках HTML, JavaScript и CSS, а клиентская логика также будет реализована на JavaScript. Платформа IBM Worklight Studio предоставляет функционально-насыщенную среду для редактирования этого уровня приложения. Она поддерживает традиционные инструменты для редактирования исходного кода, а также инструменты для визуального проектирования по методу drag-and-drop. Эти инструменты дополнены возможностью предварительного просмотра мобильного приложения, с помощью которой разработчик может моделировать облик приложения на различных мобильных устройствах. Кроме того, эта платформа способна имитировать возможности нативных устройств (напр., GPS-компонент, камера, сетевые средства). Это позволяет разработчикам выполнить надлежащую валидацию мобильного фронтенда до интеграции своих изменений в систему управления исходным кодом и до передачи своего кода остальным участникам группы разработки.

Теперь рассмотрим системы среднего (связующего) уровня. К примеру, у вас может иметься один или несколько WSDL-сервисов, исполняющихся в среде WebSphere Application Server. Эти сервисы представляются через SOAP-интерфейсы, которые в конечном итоге будет использовать программный код мобильного клиента. В данном случае можно применить продукт Rational System Architect для проектирования и моделирования этих сервисов или продукт Rational® Developer for zEnterprise® для разработки и тестирования реализаций сервисов. Оба продукта включают инструмент IBM Worklight Studio в состав оболочки Eclipse, что упрощает всю среду для разработчиков, занимающихся обоими аспектами мобильного приложения. Кроме того, при необходимости можно сочетать оба этих продукта.

Что касается вашего корпоративного бэкенда, то вполне вероятно, что на ваших z/OS-системах исполняются сервисы, которые вам потребуется использовать в рамках создаваемого решения. Например, у вас может иметься COBOL-приложение, состоящее из нескольких CICS-транзакций, которые представлены при посредстве RESTful-интерфейсов. В этом случае рекомендуется воспользоваться продуктом Rational Developer for zEnterprise для разработки COBOL-приложения или сервисных процессов, а также RESTful-интерфейса.

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

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

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

Тестирование в нескольких средах и в виртуальных средах

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

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

Тестирование мобильных приложений представляет собой качественный скачок по сложности и стоимости относительно более традиционных приложений.

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

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

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

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

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

Всесторонний подход к тестированию

Для всестороннего многоуровневого тестирования мобильного приложения необходима возможность выполнения более чем одного теста, которая должна использоваться и координироваться в рамках достижения единого результата – качества приложения. Программный продукт IBM Rational Quality Manager — это отличный инструмент для связывания и управления различными механизмами выполнения тестов, которые требуются для тестирования мобильного приложения. Такая среда тестирования позволяет предписать применение интеграционного подхода testing-first, который помогает устранять крупные проблемы на более ранних стадиях жизненного цикла и улучшать руководство экономическими аспектами. В упоминавшейся ранее статье Уокера Ройса под названием Measuring Agility and Architectural Integrity (см. раздел Ресурсы), подробно описывается методика для первоочередного тестирования наиболее трудных проблем.

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

Особую ценность для корпоративных мобильных приложений, потребляющих сервисы и данные из источников типа IBM System z, представляет возможность изолировать дорогостоящие бэкенд-интерфейсы System z и имитировать их при тестировании кода, исполняющегося на мобильных устройствах (по всей вероятности это будет происходить очень часто в результате непрерывной динамичной интеграции выходных сборок для кода мобильного приложения). Этот метод, известный под названием виртуализация тестирования, поддерживают такие продукты, как IBM Rational Test Workbench и IBM Rational Test Virtualization Server. С помощью такого решения группа тестирования сможет избавиться от необходимости настройки сред со сложным связующим программным обеспечением в тех случаях, когда ей нужно обеспечить исполнение теста для кода, работающего на мобильных устройствах. Продукт Rational Test Workbench способен эмулировать сервисы и протоколы связующего уровня и серверные сервисы и протоколы, что позволяет сконцентрировать исполнение теста на клиентском уровне мобильного приложения, который работает на мобильном устройстве.

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

Интегрированное управление изменениями, управление версиями программного обеспечения

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

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

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

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

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

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

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

Коллективный подход к управлению жизненным циклом

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

Программные инструменты для коллективной работы в составе группы динамичной разработки, такие как IBM® Rational Team Concert™, позволяют задать несколько коротких итераций в рамках всего проекта. Фрагменты работы могут быть с легкостью перемещены из списка невыполненных заданий в план соответствующей итерации.

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

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

Заключение

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

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

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

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

Прочтите приложение к данной статье: IBM System z case study

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational, Мобильные приложения, WebSphere
ArticleID=947252
ArticleTitle=Соображения относительно открытия мэйнфрейма для доступа со стороны мобильных устройств
publish-date=10042013