“DemoTool: ferramenta integrada em Plataforma de ... · celulares, sustentado pelas operadoras de...

“DemoTool: ferramenta integradaem Plataforma de Desenvolvimento

de Software de Celular paraReusar Aplicativos”

Por

Douglas Daniel Del Frari

DISSERTAÇÃO DE MESTRADO

Universidade Federal de PernambucoCentro de Ciências Exatas e da Natureza

Recife – PE11 de setembro de 2009

Universidade Federal de PernambucoCentro de Ciências Exatas e da Natureza

Centro de Informática

Douglas Daniel Del Frari

“DemoTool: ferramenta integrada em Plataforma deDesenvolvimento de Software de Celular para Reusar

Aplicativos”

Trabalho apresentado ao Programa de do Centro de Infor-mática da Universidade Federal de Pernambuco como req-uisito parcial para obtenção do grau de Mestre em Ciênciada Computação.

A Dissertação de Mestrado presented to the Federal Univer-sity of Pernambuco in partial fulfillment of the requirementsfor the degree of M.Sc. in Computer Science.

Orientador: Silvio Romero de Lemos Meira

Recife – PE11 de setembro de 2009

Dedico esse trabalho ao Centro de Estudos e SistemasAvançados do Recife (C.E.S.A.R) e a minha família.

Agradecimentos

Agradeço primeiramente a Deus, fonte de energia, sabedoria e constante Fé na minhavida.

Um especial agradecimento a minha esposa Denise Boff, que testemunhou todasas dificuldades, alegrias e conquistas, desde a nossa vinda para Pernambuco até estemomento. Com seu apoio conquistamos muitas coisas, embora a maior conquista seja ofruto do nosso amor, nossa amada filha Maria Eduarda.

Aos meus pais Olynto e Nelcinda, que mesmo estando tão longe, sempre me apoiarame me permitiram voar com as próprias asas. O meu muito obrigado!

Aos colegas de trabalho do CESAR, que proporcionam desafios e conhecimentosúnicos pela troca de experiências, ajudando a perceber o quanto essas interações sãorelevantes e prazerosas. Sem citar nomes, obrigado a todos desta família!

Obrigado a minha sócia Kátia Barbosa Feitosa, que aceitou minha ausência nosnegócios para finalizar essa etapa da minha vida.

Meus agradecimentos aos meus queridos alunos, que cada vez mais, me ajudama aprender quando me fazem perguntas, me deixando orgulhoso quando demonstramcoragem e prática para trilhar seus caminhos.

Ao professor orientador Silvio Meira, meus agradecimentos e admiração. Ele con-tribuiu para minha volta ao mestrado, sempre se colocando a disposição para fazerperguntas e abrir a mente. Ensinou-me que trabalhar em grupo pode ser melhor do quesozinho, mas me mostrou também, que quando fazemos o que gostamos, e houver energiapara persistir, resultados são possíveis e merecedores.

As secretárias da pós-graduação do CIn/UFPE que tive contato (Leila, Maria Liliae Socorro), que diante do acúmulo de atividades, da enorme quantidade de alunos, nosajudam a efetivar os processos burocráticos necessários da instituição, meus sincerosagradecimentos.

Finalmente, as amizades que fiz aqui em Pernambuco, que me fizeram gostar tantodesta terra, tal como sinto pelo Estado de origem (RS). Agradeço a todos e espero podercompartilhar e construir juntos, momentos de alegria e tristeza que estão por vir.

vi

Cada um que passa em nossa vida,passa sozinho, pois cada pessoa é única e nenhuma substitui a outra.

Cada um que passa em nossa vida, passa sozinho, masquando parte, nunca vai só nem nos deixa a sós. Leva um

pouco de nós, deixa um pouco de si mesmo.Há os que levam muito, mas há os que não levam nada.

—KALIL GIBRAM

Resumo

Existe uma explosão do uso do celular em quase todos os cantos do mundo. A inovaçãono setor tem focado sobre o desenvolvimento da infra-estrutura de redes para os telefonescelulares, sustentado pelas operadoras de celular, bem como a fabricação de dispositivosliderando o esforço. Por conta das commodities do tráfego de voz, as empresas estãobuscando ofertar conteúdos como aposta de maior lucratividade. O que permite inferirque a tendência da indústria será incrementar o foco sobre a oferta de conteúdos, e otopo disso são através das tecnologias das Plataformas de Software de Celular (PSC) e ohardware dos fabricantes. Podemos observar que as empresas envolvidas nesta indústriarequerem soluções que explorem novos modelos de negócio, voltados para aplicativose conteúdos na forma de dados, e que tais soluções são operacionalizadas através dodesenvolvimento de software usando as PSC. As PSC permitem construir e viabilizar asofertas de dados, de acordo com as exigências dos usuários. Contudo, as empresas demídia envolvidas utilizam as PSC em ambiente confuso, várias plataformas existentes,dispositivos diferentes, e que competem por definições de padrões na indústria. Nestesentido, os desenvolvedores de software precisam se adaptar às diferentes tecnologias dasPSC. Por exemplo, elas dão suporte às linguagens de programação diferentes, e, por vezes,incompatíveis entre si, dificultando a curva de aprendizado, bem como, restringindo aportabilidade das aplicações produzidas. Além disso, existem muitas restrições queimpedem e dificultam a manipulação dos recursos do celular usando as bibliotecasde software de programação (API)s. A proposta deste trabalho objetiva-se mostrar aferramenta DemoTool, voltada para o desenvolvimento de aplicativos da linguagem Java,proposta e construída para reusar aplicativos e integrar o ambiente de desenvolvimentoda fabricante de celular Motorola,Inc. Essa dissertação apresenta um estudo de casousando o DemoTool, exemplificando e listando algumas problemáticas relacionadas aoprocesso de desenvolvimento de aplicativos para celular, realizado por desenvolvedoresde terceiros, assim como, uma pesquisa de campo com usuários de celular no contexto daoferta de dados.

Palavras-chave: Reuso de Software, Computação Móvel, Oferta de Dados para Celular,Plataforma de Software

viii

Abstract

There is an expansion of mobile phone usage in almost all corners of the world. Theinnovation in the sector has focused on the development of infrastructure networks formobile phones, supported by mobile carrier and device manufacturers that lead the effort,driven by their makers. Because of commodities in voice traffic, companies are makingan effort in offering contents as the most profitable bet. This allows the supposition thatthe industry trend will increase the focus on the provision of content; on top of that, thereare the Mobile Software Platforms (MSP) and the hardware manufacturers. We can seethat the companies involved in this industry require solutions that explore new businessmodels, focusing on applications and content in the form of data, and that such solutionsare operated through the development of software using the MSP. The MSP allowsbuilding and channeling data offerings, according to the requirements of users. However,the media companies involved in using of MSP do so in a confusing environment, withseveral existing platforms, different devices, and competing definitions of standards in theindustry. In this sense, software developers need to adapt to different MSP technologies.For example; they support the different programming languages that sometimes areincompatible, making the learning curve very high, as well as restricting the portability ofthe applications produced. Moreover, there are many restrictions that prevent and hinderthe handling of the phone’s features using the libraries of programming software (API)s.The proposal of this work aims to show the tool DemoTool, toward the development ofJava applications, proposed and built for reuse applications and integrate the environmentdevelopment of mobile phone manufacturer Motorola, Inc. This dissertation presentsa case study using the DemoTool, illustrating and listing some problems related to thedevelopment process applications for mobile, performed by third-party developers, aswell as a field research with mobile phone users in the context of supply data.

Keywords: Software Reuse, Mobile Computing, Mobile Data, Software Platform

ix

Sumário

1 Introdução 11.1 Contexto e Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 O Ecossistema da Indústria de Celular . . . . . . . . . . . . . . . . . . 4

1.2.1 A Oferta de dados no Ecossistema . . . . . . . . . . . . . . . . 41.2.1.1 Conectividade . . . . . . . . . . . . . . . . . . . . . 51.2.1.2 Entretenimento . . . . . . . . . . . . . . . . . . . . 71.2.1.3 Produtividade . . . . . . . . . . . . . . . . . . . . . 7

1.2.2 Atual oferta de dados . . . . . . . . . . . . . . . . . . . . . . . 81.2.3 Operadoras de Celular . . . . . . . . . . . . . . . . . . . . . . 131.2.4 Fabricantes de Celulares . . . . . . . . . . . . . . . . . . . . . 161.2.5 Provedores de Conteúdo e o Novo Paradigma . . . . . . . . . . 18

1.3 Questões de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4 Objetivos e Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.4.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.4.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . 211.4.1.2 Objetivos Específicos . . . . . . . . . . . . . . . . . 21

1.4.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.5 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . 22

2 Plataformas de Software de Celular 242.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2 Plataformas de Software de Celular . . . . . . . . . . . . . . . . . . . 272.3 Plataformas de Celulares . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3.1 Plataformas baseadas em Symbian . . . . . . . . . . . . . . . . 332.3.2 Plataformas baseadas em Linux . . . . . . . . . . . . . . . . . 362.3.3 Plataformas baseadas em Windows Mobile . . . . . . . . . . . 392.3.4 Plataformas baseadas em iPhone . . . . . . . . . . . . . . . . . 412.3.5 Plataformas baseadas em Android . . . . . . . . . . . . . . . . 442.3.6 Plataforma Java ME . . . . . . . . . . . . . . . . . . . . . . . 46

2.4 Características Desejáveis . . . . . . . . . . . . . . . . . . . . . . . . 492.5 Comparações das Plataformas . . . . . . . . . . . . . . . . . . . . . . 50

x

3 O Desenvolvimento de Software na Indústria de Celular 533.1 Desenvolvimento de Aplicativos para Celular . . . . . . . . . . . . . . 533.2 Ciclo de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 573.3 Desafios para aplicações e ferramentas . . . . . . . . . . . . . . . . . . 593.4 Requisitos desejáveis para ferramentas de desenvolvimento móveis . . . 633.5 Ferramentas de Desenvolvimento de Software . . . . . . . . . . . . . . 65

3.5.1 SDK da Nokia . . . . . . . . . . . . . . . . . . . . . . . . . . 663.5.2 SDK da SUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.5.3 SDK da Motorola . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.6 Comparativo entre os SDKs . . . . . . . . . . . . . . . . . . . . . . . 70

4 DemoTool 734.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.2 Desenvolvimento do DemoTool . . . . . . . . . . . . . . . . . . . . . 75

4.2.1 Contexto de Implementação . . . . . . . . . . . . . . . . . . . 774.2.2 Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.2.3 Fase de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . 794.2.4 Fase de Análise . . . . . . . . . . . . . . . . . . . . . . . . . . 804.2.5 Fase de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 824.2.6 Fase de Implementação e Teste . . . . . . . . . . . . . . . . . . 844.2.7 Fase de Implantação . . . . . . . . . . . . . . . . . . . . . . . 85

4.3 Estudo de Caso: Mobile Piano Learning . . . . . . . . . . . . . . . . . 864.3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.3.2 Apresentação do Problema Estudado . . . . . . . . . . . . . . . 884.3.3 Criando uma Aplicação para Celular . . . . . . . . . . . . . . . 89

4.3.3.1 Fase 1: uso do DemoTool . . . . . . . . . . . . . . . 894.3.3.2 Fase 2: ciclo de desenvolvimento do aplicativo . . . . 91

4.3.4 Resumo dos Pontos-Chave Identificados . . . . . . . . . . . . . 94

5 Estudos e Resultados 965.1 Análise e Resultados do Estudo de Caso . . . . . . . . . . . . . . . . . 96

5.1.1 Análise dos Pontos-Chave . . . . . . . . . . . . . . . . . . . . 965.1.2 Análise da Fase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 975.1.3 Análise da Fase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 1005.1.4 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . 106

5.2 Estudo Adicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

xi

5.2.1 Objetivos e Premissas . . . . . . . . . . . . . . . . . . . . . . 1075.2.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.2.3 Público-Alvo e Métodos . . . . . . . . . . . . . . . . . . . . . 1095.2.4 Análise da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . 1115.2.5 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . 116

5.3 Limitações do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6 Considerações Finais 1186.1 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206.3 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1216.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

A Apêndice A: Bibliotecas de Java ME 131

B Apêndice B: Questionário de Pesquisa 132

C Apêndice C: Resultado da Pesquisa 135

D Apêndice D: Respostas Relevantes da Pesquisa Qualitativa 137

E Apêndice E: Contexto de Uso 139

F Apêndice F: Requisitos do DemoTool 140

xii

Lista de Figuras

1.1 Evolução das tecnologias de redes de celular no Brasil (fonte: Teleco) . 61.2 Atividade dos celulares por uso de mídias nos EUA em 2009 (fonte:

comScore) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Principais conteúdos por gêneros via browser nos EUA em 2009 (fonte:

comScore) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4 Universo de celulares ativos nos EUA em 2008 (fonte: comScore) . . . 161.5 Novo paradigma de inovação na indústria de celular (fonte: Ziv (2005);

Ziv and Mulloth (2007)) . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1 Evolução geral do telefone por funcionalidades (fonte: Neufeld (2009b)) 252.2 Arquitetura de uma plataforma de software de celular (fonte: Cho and

Jeon (2007)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3 Diagrama da plataforma de software Symbian S60 (fonte: Cho and Jeon

(2007)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4 Modelos celulares baseados em Symbian S60 e UIQ (Nokia E51 e Sony

P1) (fonte: Cho and Jeon (2007)) . . . . . . . . . . . . . . . . . . . . . 352.5 Plataforma Linux da Motorola / Geração seguinte da plataforma Linux

da Motorola (fonte: Cho and Jeon (2007)) . . . . . . . . . . . . . . . . 382.6 Modelos baseados em Linux (MotoRIZR Z6 / MotoMing A1200) (fonte:

Cho and Jeon (2007)) . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.7 Modelo baseado em Windows Mobile 6.1 (Motorola Q11) (fonte: Mori-

moto (2009)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.8 Modelo baseado no iPhone (iPhone 3GS) (fonte: Morimoto (2009)) . . 422.9 Modelo baseado na plataforma Android (HTC G1) (fonte: Morimoto

(2009)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.10 Arquitetura geral da plataforma Java ME (fonte: Keogh (2003); Muchow

(2001)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.1 Camadas da Engenharia de Software (Pressman (1995)). . . . . . . . . 543.2 Dependências do desenvolvimento de aplicações e conteúdos para celular 573.3 Ciclo geral de desenvolvimento de aplicações para celulares . . . . . . 583.4 Desafios a serem superados no contexto do desenvolvimento para celular 603.5 Interface de usuário SDK S60 . . . . . . . . . . . . . . . . . . . . . . 663.6 Interface de usuário da Sun Java Wireless Tool Kit 3.0 . . . . . . . . . 67

xiii

3.7 MOTODEV Studio rodando uma aplicação demo . . . . . . . . . . . . 693.8 Resultado da Comparação dos SDKs segundo requisitos desejáveis . . . 71

4.1 Modelo de inovação no ecossistema considerando o desenvolvedor (adp-tado de Ziv and Mulloth (2007) . . . . . . . . . . . . . . . . . . . . . . 74

4.2 Visão geral da ferramenta DemoTool . . . . . . . . . . . . . . . . . . . 764.3 DemoTool integrado no Motodev Studio/J executando o demo no emulador 784.4 Casos de Uso do DemoTool (fonte: Product Requirements for DemoTool) 814.5 Diagrama de Classes do modelo da Arquitetura . . . . . . . . . . . . . 824.6 O modelo de suporte de plugins do Eclipse (adptado de Gallardo (2002)) 834.7 Diagrama de Componentes do modelo da arquitetura . . . . . . . . . . 844.8 Portal Motodev Studio/J da Motorola, Inc. com destaque para DemoTool 864.9 Testando aplicativo Mobile Piano Learning no emulador . . . . . . . . 924.10 Mobile Piano Learning rodando no modelo Nokia N-95 . . . . . . . . . 93

5.1 Pontos chave identificados sobre às fases de desenvolvimento ao longodo tempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.2 Gráficos em relação a tendências (a) e participação (b) no desenvolvi-mento do game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.3 Relevância nos setores do Ecossistema da Indústria de Celular . . . . . 112

xiv

Lista de Tabelas

1.1 Receita média mensal por usuário (ARPU) em Reais (fonte: Teleco) . . 51.2 Dez aplicações de iTunes mais baixadas em fevereiro 2009 (fonte: adap-

tada de Neufeld (2009a) ) . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 Celulares ativos em operadoras no Brasil (milhares) (fonte: Teleco) . . . 13

2.1 Participação de mercado mundial 2008/2007, por fabricantes de Smart-phones (fonte: Canalys (2008)) . . . . . . . . . . . . . . . . . . . . . . 32

2.2 Participação de mercado de smartphones no mundo 2008/2007 (fonte:Canalys (2008)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3 Requisitos desejáveis das plataformas de celular (adaptado de Oliver(2008)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.1 Tecnologias de Desenvolvimento de Software para Celular . . . . . . . 553.2 Requisitos desejáveis das Ferramentas de Desenvolvimento de Celular

(adaptada de Kurkovsky (2009); Loureiro et al. (2003); Economou et al.

(2008)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.1 Pontos de Melhoria do DemoTool e relacionados . . . . . . . . . . . . 944.2 Pontos de Evidência identificadas do Estudo de Caso . . . . . . . . . . 95

5.1 Pontos de Evidência identificadas na fase Pré . . . . . . . . . . . . . . 985.2 Agrupamento de Pontos de Melhoria por status de criticidade . . . . . . 995.3 Pontos de Evidência identificadas na fase Codificar e Construir . . . . . 1005.4 Pontos de Evidência identificadas na fase de Teste . . . . . . . . . . . . 1015.5 Pontos de Evidência identificadas na fase Assinar . . . . . . . . . . . . 1035.6 Pontos de Evidência identificadas na fase Distribuir . . . . . . . . . . . 1035.7 Pontos de Evidência identificadas na fase Pós . . . . . . . . . . . . . . 1045.8 Resultado comparativo de pesquisas sobre a oferta de dados para celular

2007/2009 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

E.1 Popularidade e contextos de uso do celular nos EUA em 2009 (comScore)139

xv

“O tempo é o melhor autor - sempre encontra um finalperfeito.”

Charles Chaplin 1Introdução

O objetivo deste capítulo é introduzir o tema global da pesquisa no contexto da engenhariade software, mais especificamente para o desenvolvimento de aplicativos para a indústriade celular. Inicialmente, são apresentados o contexto e a motivação que gerou estetrabalho, mostrando a importância da oferta de dados para os celulares e alguns dos seusimpactos no desenvolvimento de software, destacando o paradigma que se apresenta naatual conjuntura do setor. Logo depois, os objetivos e as principais contribuições sãoapresentados.

1.1 Contexto e Motivação

Dados divulgados por Miner (2008); UNCTAD (2007); Fulgoni (2008), atestam queexistem aproximadamente 6,5 bilhões de pessoas no mundo, sendo que cerca de 45%já possui telefone celular, ou seja, 2,7 bilhões de pessoas. No Brasil, segundo dados daAgência Nacional de Telecomunicações (Anatel), o número de assinantes de serviçosmóveis chegou a marca de 159,6 milhões ANATEL (2009) (referentes a junho 2009).

Além do grande crescimento de novos usuários de celulares no mundo e no Brasil,outro dado relevante é que o número de pessoas que acessam a Internet no mundo atingiumais de 840 milhões em 2008 Fulgoni (2008); Miner (2008). Segundo relatório daOrganização das Nações Unidas UNCTAD (2007), esses números indicam que o abismodigital entre países ricos e pobres está diminuindo à medida que o uso de telefonescelulares e Internet torna-se mais acessível para as pessoas.

No entanto, o mesmo relatório aponta que países emergentes ainda estão muito atrásdos países desenvolvidos. Na África, por exemplo, têm sido maior o aumento do númerode usuários de telefones celulares, mostrando que esta tecnologia pode melhorar a vidaeconômica da população como um todo. A América Latina aparece com a terceira maior

1

1.1. CONTEXTO E MOTIVAÇÃO

taxa de crescimento no número de celulares entre as outras partes do mundo, sendoresponsável por 75% dos novos assinantes (de celulares) da região. O estudo relataainda que telefones celulares são a principal ferramenta de comunicação para pequenosnegócios em países em desenvolvimento, reduzindo custos e aumentando a velocidade detransações.

Diante desse cenário, percebe-se que existe uma explosão do uso do celular emquase todos os cantos do mundo. Segundo Miner (2008), a importância do celular paraas pessoas é bastante significativa em números, pois quando comparado com outrossetores, tais como: automóveis (800 milhões); telefones fixos (1,3 bilhões); TVs (1,5bilhões); cartões de crédito (1,4 bilhões); computadores pessoais (850 milhões); usuáriosde internet (1,1 bilhões), percebemos a relavância e dimensões que eles representam naconjuntura mundial. Além disso, são vendidos 200 milhões de computadores pessoais(PC) a cada ano, contra 1 bilhão de celulares comercializados anualmente.

Com relação ao desenvolvimento de software, Loureiro et al. (2003) questiona seo Brasil será competitivo diante de um mercado que cresce rapidamente e tende a serdominado pelos países que detém e usam as tecnologias de infra-estrutura de comunicaçãosem fio, como redes celulares 3G e outras. A resposta a esse questionamento é afirmadocategoricamente por Loureiro et al. (2003): “...é necessário que os potenciais usuários

tenham serviços e aplicações “interessantes"”.Para Loureiro et al. (2003), as tecnologias para prover serviços e aplicações são

desenvolvidas por ferramentas que, na maior parte dos casos, não existem ou estão sendoprojetadas. Porém, podemos perceber que as tais ferramentas referidas são as tecnologiasusadas para desenvolver software, voltada para os celulares, que, segundo Ziv (2005),existem desde o início de nossa década e são conhecidas como Plataformas de Softwarede Celular (PSC).

Para Ziv (2005); Ziv and Mulloth (2007), a inovação no setor tem focado sobreo desenvolvimento da infra-estrutura de redes para os telefones celulares, sustentadopelas operadoras de celular, bem como a fabricação de dispositivos liderando o esforço,impulsionados por seus fabricantes. Afirma ainda que, por conta das commodities dotráfego de voz, as empresas estão buscando ofertar conteúdos, como aposta de maiorlucratividade. O que permite inferir que a tendência da indústria será incrementar o focosobre a oferta de conteúdos, e o topo disso, segundo Ziv (2005); Ziv and Mulloth (2007);Morimoto (2009); Verkasalo (2009), são através das PSC e o hardware dos fabricantes.

Podemos observar que as empresas envolvidas nesta indústria requerem soluçõesque explorem novos modelos de negócio, voltado para aplicativos e conteúdos na forma

2

1.1. CONTEXTO E MOTIVAÇÃO

de dados, e que tais soluções, segundo Ziv (2005), são operacionalizadas através dodesenvolvimento de software usando as PSC.

As PSC permitem construir e canalizar as ofertas de dados, de acordo com as ex-igências dos usuários. Contudo, não está claro como algumas das empresas envolvidas,como os provedores de conteúdo e operadoras, podem se beneficiar (financeiramente)da criação de conteúdos. Além disso, a indústria de mídia utiliza as plataformas decelular em ambiente confuso, várias plataformas existentes, dispositivos diferentes, e quecompetem por definições de padrões na indústria.

Segundo Miner (2008), as principais dificuldade envolvidas no ecossistema da indús-tria de celular são:

• a): Confusão no relacionamento entre as OEM1’s e as operadoras;

• b): Não há um entendimento de software;

• c): Pouca liberdade para desenvolvedores.

Esse trabalho trata da problemática do item (c) da listagem (pouco poder ou liberdadepara desenvolvedores). Neste sentido, os desenvolvedores de software precisam seadaptar às diferentes tecnologias das PSC. Por exemplo, elas dão suporte à linguagensde programação diferentes, e por vezes, incompatíveis entre si, dificultando a curva deaprendizado, bem como, restringindo a portabilidade das aplicações produzidas.

Além disso, segundo Oliver (2008), existem muitas restrições que impedem, e di-ficultam, a manipulação dos recursos do celular usando as bibliotecas de software deprogramação (API)s (dependendo da PSC usada pelo desenvolvedor).

Se por um lado, existem diversas tecnologias das PSC disponíveis aos desenvolve-dores, por outro, cada escolha impõe diferentes restrições, tais como: variedade deambientes de desenvolvimento e incompatibilidade entre si.

Com o aumento da demanda por conteúdos “interessantes” para os usuários, aumenta-se a necessidade de agregar mais serviços e funcionalidades para o celular. Sobre tudo,segundo Cho and Jeon (2007); Yamakami (2005); Verkasalo (2009), os avanços dosnovos aparelhos, faz com que os usuários, cada vez mais, busquem aproximações com osmodelos de aplicativos operados em PCs.

Diante disso, temos softwares cada vez mais complexos nos aparelhos e nos serviçosoferecidos. No entanto, conforme Cho and Jeon (2007); Oliver (2008), as capacidades

1Original Equipment Manufacturer: uma empresa que produz hardware para ser comercializado poroutra empresa.

3

1.2. O ECOSSISTEMA DA INDÚSTRIA DE CELULAR

atuais das PSC estão aquém das demandas atuais. A principal razão para isso, segundoMorimoto (2009), é porque os usuários esperam que o celular se torne algo como um“canivete suíço”, ou seja, com muitas funcionalidades integradas (multi-tarefas).

Segundo Miner (2008); Cho and Jeon (2007); Morimoto (2009), por conta da de-manda por software, o custo do projeto vem aumentando gradualmente (menor para oscomponentes de hardware e maior para o software), impactando tanto na fabricação dostelefones celulares, bem como em suas PSC. Justamente por incorporar muitos recursose funcionalidades em um único dispositivo. Esse custo, segundo Cho and Jeon (2007),depende da agilidade e rapidez com o qual são desenvolvidos seus aplicativos.

1.2 O Ecossistema da Indústria de Celular

As empresas envolvidas no ecossistema da indústria de celular são os fabricantes deaparelhos, as operadoras de celular e os provedores de conteúdo. Todas essas entidadesfazem parte direta e/ou indiretamente do paradigma da computação móvel e são analisadassobre a ótica da oferta da dados para celulares. Além disso, discuti-se o paradigma que seapresenta na atual conjuntura do setor de mobilidade.

1.2.1 A Oferta de dados no Ecossistema

De acordo com Quintella and Rodrigues (2005), o mercado brasileiro de comunicaçãomóvel está caminhando para sua maturidade. A densidade de celulares ativos nas op-eradoras (quantidade de celulares por 100 habitantes), saltou de 41,09% em junho de2005 (Quintella and Rodrigues (2005) apud ANATEL), para 83,47% (com 159.613.507celulares) em junho 2009 (Teleco (2009b); ANATEL (2009)). Um crescimento de 42,38%nos últimos quatro anos, o que nos leva a constatar que a densidade de celulares ativosainda apresenta um crescimento bastante expressivo. Embora, a tendência seja que a basede celulares ativos cresça a uma taxa cada vez menor nos próximos anos, tornando-se ummercado maduro.

O crescimento do número de celulares fez com que a receita média mensal por usuário(ARPU - Average Revenue per user2) das operadoras, caísse.

A Tabela 1.1 mostra os dados da ARPU das operadoras do Brasil, demonstrandotendência para quedas nas respectivas receitas no período anual por trimestres. SegundoQuintella and Rodrigues (2005), a penetração cada vez maior implica em agregar a base

2ARPU é obtida dividindo-se a receita líquida de serviços pelo número médio de celulares no período epelo número de meses do período.

4


de clientes das camadas de mais baixa renda, que apresentam uma menor receita para asoperadoras.

Tabela 1.1 Receita média mensal por usuário (ARPU) em Reais (fonte: Teleco)R$ 1T08 2T08 3T08 4T08 1T09 2T09Vivo 29,5 28,8 29,4 29,1 27,0 26,3Claro 26,0 26,0 25,0 25,0 23,0 23,0TIM 29,5 29,8 29,7 29,9 26,0 26,6Oi 21,7 22,0 21,4 22,7 21,9 Não DivulgadoBrT 29,8 29,2 28,8 28,6 24,0 Não DivulgadoARPU Brasil 27,5 27,3 27,1 27,2 24,8 Não Divulgado

Neste sentido, as operadoras de celular enfrentam o desafio de encontrar novasformas de geração de valor para elevação das receitas por usuário, de forma a equilibrarcrescimento e rentabilidade.

Segundo Ziv (2005), por conta das commodities do tráfego de voz e deste amadurec-imento do mercado, as empresas do setor de celular estão buscando ofertar conteúdos,como aposta de recuperação de lucratividade.

Portanto, de acordo com alguns estudos, tais como Quintella and Rodrigues (2005);Ziv (2005); Zhang et al. (2008); Ziv and Mulloth (2007); Yamakami (2005); Verkasalo(2009), os serviços de comunicação de dados são determinantes para o crescimento esustentação do ARPU das operadoras. Não obstante, o crescimento futuro do mercadomóvel no Brasil não será resultado apenas do aumento do número de assinantes, masprincipalmente, do aumento da geração da receita através do oferecimento de novosserviços de comunicação móvel de dados.

Segundo Junquera and Gnius (2005), os serviços de dados através das redes decelulares se dividem em três áreas principais: Conectividade; Entretenimento; e Produ-tividade.

1.2.1.1 Conectividade

No contexto da computação, a conectividade refere-se às redes de comunicação ou aoato de comunicar entre computadores e terminais de usuários finais. A Internet fixa porexemplo, é um negócio baseado na conectividade.

Em princípio, a conectividade foi oferecida de maneira básica. Conforme afirmaJunquera and Gnius (2005), as operadoras do Brasil lançaram a oferta de serviços simul-taneamente à oferta de conectividade. Dessa forma, tentou-se evitar que a conectividade

5


se transformasse em uma commodity para as operadoras, tentando evitar que seu valorcaísse rapidamente com a concorrência.

Assim, no início da oferta da conectividade na América Latina, conforme Junqueraand Gnius (2005), a qualidade ofertada das transmissões de dados eram muito lentas,devida principalmente, a limitações tecnológicas das redes de transmissão de dados(Figura 1.1). Além disso, os modelos de negócio das operadoras cobravam por tempo deuso, sem nenhuma outra opção, fazendo com que usuários se sentissem fraudados, poispagavam altas somas devido à lentidão da rede em conectar o usuário com o conteúdo.

Figura 1.1 Evolução das tecnologias de redes de celular no Brasil (fonte: Teleco)

A Figura 1.1 ilustra um quadro evolutivo das redes de celular no Brasil por quantidadede milhares, ao longo da década, conforme Teleco (2009b). As duas principais tecnologiassão o GSM e o CDMA. As novas gerações de tecnologias de infra-estruturas de redes,como às redes 2,5G (GPRS3, EDGE4) e 3G (UMTS5 ) são, respectivamente, evolução dopadrão GSM.

O negócio de conectividade é muito importante para as operadoras, pois a novageração de tecnologias de rede oferecem uma conectividade robusta, que pode ser adotadapor muitos usuários. Segundo Junquera and Gnius (2005), o segredo do êxito de umaoperadora para serviços de dados começa com uma conectividade robusta, e depois aoferta de serviços e aplicações.

3General Packet Radio Service: taxa máxima encontrada na prática: 26 a 40 kbit/s.4Enhanced Data rates for Global Evolution: taxa máxima encontrada na prática de 384Kbps e uma

média de 110 a 120 kbps em uma rede carregada Teleco (2009b)5Universal Mobile Telecommunications System: o termo adotado para designar o padrão de 3ª

Geração estabelecido para a rede das operadoras de celular

6


1.2.1.2 Entretenimento

Com as novas estruturas de redes mais robustas, pode-se oferecer uma grande variedadede serviços e aplicações para entretenimento, desde conteúdos mais simples até TV ouvídeos (on-demand) pelos celulares. As principais aplicações e serviços oferecidos nasoperadoras são Junquera and Gnius (2005):

• Ringtones: são arquivos de formatos de música para celulares. Geralmente naforma de tons monofônicos e/ou polifônicos, além de formato MP3;

• Wallpapers: são papéis de parede para o celular ou skins personalizados. Um dosprodutos mais consumidos pelos usuários;

• Jogos: um dos tipos de aplicações que desperta grande interesse nos usuários.Grandes empresas de games como Microsoft (XBox), Sony (Play Station) e Nin-tendo (Wii), tendem a desenvolver seus títulos com a possibilidade de jogar emrede (melhora na infra-estrutura). A novidade são jogos 3D.

Essa categoria de entretenimento tende a dominar o cenário e a oferta de dados naindústria de celular, liderando estatísticas de downloads e receitas. Entretanto, devidoao fato de que para a utilização de serviços mais avançados, como TV ou serviços devídeo (Youtube), os usuários necessitam contar com celulares capazes de reproduzir essesconteúdos (através dos Smartphones). Além disso, segundo Junquera and Gnius (2005),os planos praticados pelas operadoras de oferta de conectividade, precisam rever os seusmodelos de negócio, para baratear o custo atualmente praticados no Brasil.

1.2.1.3 Produtividade

No geral, produtividade no contexto da indústria de celular, são aplicativos corporativos oupessoais, ou ainda, aplicações com ênfase em produtividade ou para órgãos corporativos.Como exemplo podemos citar o desenvolvimento usando widgets. Widgets são aplicativosque geralmente rodam no navegador de internet no celular.

Começam a ser um componente importante para as operadoras, embora, as operadoraslatino americanas, concentram suas operações em público de massivo (80%). Diminuindoessa oferta.

Uma observação importante, de acordo com Junquera and Gnius (2005), o pro-cesso que sustenta o desenvolvimento das aplicações de entretenimento é diferente das

7


aplicações corporativas. No entretenimento, as aplicações se desenvolvem para a quan-tidade máxima possível de celulares compatíveis, enquanto que as corporativas podemdesenvolver-se para um só dispositivo e segmento.

Entretanto, esse tipo de venda é bastante atraente para ambos os envolvidos: operado-ras e desenvolvedores; pois a operadora ganhará na exploração da conectividade, atravésdo tráfego de dados, enquanto que o desenvolvedor ganhará na venda do aplicativo. Nesteponto, as operadoras podem identificar empresas parceiras para produzir conteúdos ouaplicativos para seus clientes, utilizando essa rede de desenvolvedores.

De forma geral, as aplicações mais comuns para o setor corporativo são:

• E-mail: permite os usuários gerenciarem seus e-mails. O Blackberry da RIM é umexemplo que está tendo bastante penetração no setor corporativo;

• Serviços de localização: aplicações LBS (Serviços Baseado em Localização) têmsido utilizado para o segmento de frotas de veículos;

• Câmeras remotas de vídeo: usada para vigilância de casas ou inclusive pessoas;

• Machine-to-machine (M2M): aplicação para controle de equipamentos a dis-tância, tal como medidores de energia elétrica. São normalmente utilizados emhorários quando a rede de transmissão de dados está livre de congestionamento (ànoite). São aplicações que não requerem grande largura de banda.

1.2.2 Atual oferta de dados

Nos dias atuais, no entanto, existem diversas outras aplicações que são caracterizadaspor uma mistura das divisões citadas anteriormente (conectividade, entretenimento eprodutividade).

Como exemplos, podemos citar os aplicativos e dados disponibilizados nos recentesportais dos fabricantes da Apple (Seção 2.3.4, Apple Store), Nokia (Seção 2.3.1,OVIStore) e Android(Seção 2.3.5, Android Market), bem como, os recursos de aplicativospré-instados nos dispositivos dos recentes celulares smartphones, que oferecem váriosrecursos, tais como: tocadores de música e navegação na internet.

Além disso, existem expectativas positivas para comércio eletrônico via celular,através do comércio móvel (Mobile Commerce), conhecido como m-commerce Tarnachaand Maitland (2006), visto que, diferente de seu antecessor - comércio eletrônico, m-commerce traz maior confiança para os consumidores Siau et al. (2004), segurança

8


Jarvenpaa et al. (2003), maior usabilidade nos dispositivos Lee and Benbasat (2003) emodelos de negócio adequados Gressgård and Stensaker (2006).

Não obstante, segundo pesquisas da empresa comScore Neufeld (2009a), no mercadonorte americano, a maioria dos usuários de celular usam seus aparelhos mais do queapenas para falar, pois os celulares inteligentes vêm proporcionando um ritmo de consumopor conteúdos móveis cada vez maior. Neste sentindo surgem algumas dúvidas tais como:

• (1) O que o mercado da internet para celular representa hoje?

• (2) Acessos do PC e celular - onde eles se sobrepõem, quais são as tendências?

• (3) Downloads de aplicativos iPhone - principais títulos, categorias chaves, quaissão as grandes aplicações (killer applications)?

A Figura 1.2 mostra um gráfico sobre as atividades atuais dos celulares de usuáriospor uso de mídias, de acordo com dados Neufeld (2009a) apud MobiLins6 (jan 2009).Por Mídia de Celular (MC), considerou-se qualquer coisa relacionado com dados e nãovoz, tais como, navegadores, downloads ou uso de aplicações, porém, excluindo texto(SMS).

Figura 1.2 Atividade dos celulares por uso de mídias nos EUA em 2009 (fonte: comScore)

Podemos perceber que os usuários de celular não estão somente fazendo ligaçõesde voz, confirmando tendências de uso do celular para consumo de dados. Por outrolado, a pesquisa revelou também, que 6 a cada 10 donos de celulares, não utilizam MC, e

6pesquisa realizada em média de 3 meses, nos EUA, com total de 35.629 usuários de celular (fonte:comScore)

9


somente 4 a cada 10, utilizam o celular para MC (excluídos aqueles que utilizam apenaspara texto).

Os navegadores (browsers) dos celulares, aplicações e downloads de dados (MCs),estão crescendo de forma constante Neufeld (2009a). Atualmente, são mais de 35% deusuários de celular dos EUA que estão usando serviços de MC que conectam na rede. Ouso de SMS, MMS ou voz, representa o resto.

A razão principal para o crescimento da penetração do uso de MC como um todo,segundo Neufeld (2009a), deve-se a melhoria nas tecnologias dos telefones. Segundodados da pesquisa, quase 50% dos usuários que possuem um dispositivo móvel, o adquiriua 6 meses atrás ou menos, e estão usando agora os seus celulares para acessar as MC(navegação, download ou uso de aplicações). Quando novos modelos são lançados, comnovos recursos, há um aumento respectivo do acesso as MC.

Além disso, outro aspecto que tem permitido aumetar a oferta de dados no cenárioatual de MC, são relacionados com a conectividade da infra-estrutura de redes, os planosde dados por exemplo. Segundo Neufeld (2009a), assim como a Internet teve suaaceleração quando os usuários deixavam as conexões discadas para planos de banda larga,nos celulares, a tendência atual demonstra isso também.

Quando a velocidade da rede fica mais rápida (3G) e os custos estão sob controle(planos de dados) a probabilidade das pessoas utilizarem os serviços móveis aumenta.Os dados da pesquisa comScore (2009) apontam que 80.1% dos assinantes de celularutilizam planos de dados ilimitados, voltados para MC. Além disso, 49,3% dos donos decelulares utilizam redes com tecnologia 3G, representando 35,3% do mercado total deMC.

Existem muitos serviços disponíveis voltados para os celulares. A Tabela E.1 (videApêndice E), segundo Neufeld (2009a), apresenta uma listagem do ranking por popu-laridade do celular sobre os seus contextos de utilização nos EUA em 2009. Podemosobservar que os serviços de SMS, o uso da câmera e o serviços de mensagens instantâneas(MI) são os atrativos mais populares.

Com relação as MC, o download e uso de jogos (games) são o topo do gênero deconteúdos. Além disso, há um forte crescimento em todas as categorias, em especial aosserviços conectados com a rede, por exemplo, uso do navegador (browser), e-mail e MIs.

A Figura 1.3 mostra um gráfico com os principais conteúdos por gênero, acessadosvia navegador do celular. Alguns tipos de acesso começam a se destacar frente aos maispopulares, tais como as transações bancárias, sites de leilões, bem como pagamentoson-line. As informações locais também, como mapas, listagens de filmes e notícias em

10


Figura 1.3 Principais conteúdos por gêneros via browser nos EUA em 2009 (fonte: comScore)

geral.Segundo Neufeld (2009a), a combinação de serviços locais e de transações diversas

de outros segmentos, como bancárias, trará novos modelos de negócios. Os sites e asfortes marcas conhecidas da Web, como Google, Yahoo, etc, continuam a liderar as suasposições dominantes no celular.

As aplicações disponibilizadas em portfólios como AppStore (Apple) têm grandepotencial para alavancar e dissiminar aplicações e conteúdos para MC. Segundo Neufeld(2009a), os primeiros 8 meses da AppStore funcionando, já ofertava 25 mil aplicações,gerando mais de 800 milhões de downloads.

O modelo de negócio da Apple, portanto, atingiu um excelente resultado em poucotempo. Em decorrência de tal sucesso, outros fabricantes criaram seus próprios portfóliostambém, tais como: Android Marketplace (Google); SkyMarket (Microsoft WindowsMobile); Blackberry App World (RIM); e Ovi Store (Nokia).

A Tabela 1.2 apresenta as dez aplicações mais baixadas pela sua porcentagem depenetração de instalações de acordo com Neufeld (2009a) apud comScore iTunes AppReport.

Analisando as aplicações mais baixadas (vide Tabela 1.2), pode-se observar o per-fil dos consumidores e seus interesses nos aplicativos particulares e/ou categorias deaplicativos.

Os dados do estudo mostram que usuários que acessam o portal de aplicativos iTunespor celulares, estão acessando mais conteúdos que usuários da internet dos PCs. Algumas

11


Tabela 1.2 Dez aplicações de iTunes mais baixadas em fevereiro 2009 (fonte: adaptada deNeufeld (2009a) )

Aplicação Penetração de Categoria Empresa dede instalações Desenvolvimento

Tap Tap Revenge 32% Games Tapulous, Inc.Backgrounds 27% Entretenimento Stylem MediaTouch Hockey: FS5 26% Games FlipSide5, Inc.Facebook 26% Redes Sociais Facebook, Inc.Pac-Man 24% Games NamcoiBowl 24% Games SGNMySpace Mobile 23% Redes Sociais MySpace.comGoogle Earth 22% Viagem (Travel) Google Inc.Labyrinth 22% Games Codify ABPandora 21% Música Pandora Media, Inc.

considerações:

• Os 35% dos usuários que baixaram aplicações declararam uma renda familiar demais de U$ 100.000 por ano, contra 32% de usuários que baixaram da internet viaPC;

• Mais da metade (54%) são usuários provenientes de famílias com renda de U$75.000 por ano;

• Os acessos somam na média, pelo menos 3 vezes mais do que a média de usuáriosque visitam os sites de games pelo PC, tais como: Ultimate-guitar.com; IGNEntertainment; GamStop; Addicting Games; Xbox.com; Blizzard Entertainment;SourceForge; EA.com; além dos sites de entretenimento e comunicação, tais como:AOL Instant Messenger; Hulu; Twitter.com; Digg.com; iMeem; MTV.com;

Em resumo, as principais características que estão permitindo o aumento da ofertapor conteúdos e aplicações para celular são:

• Novos celulares (smartphones);

• Conectividade das redes com infra-estrutura de tecnologias (3G) que tornam anavegação rápida;

• Planos de dados ilimitados e/ou com custos controlados;

• Celulares estendem a capacidade de acesso on-line;

12


• Aplicações para celulares provem novas oportunidades (aumentar lucratividade nossegmentos das operadoras e promoção das marcas)

1.2.3 Operadoras de Celular

As operadoras são empresas de telefonia responsáveis pelo fluxo de chamada telefônicadentro do território do país de atuação. A Tabela 1.3 apresenta as operadoras de celularcom atuação no Brasil, bem como, a quantidade de celulares habilitados no ano de 2009.

Tabela 1.3 Celulares ativos em operadoras no Brasil (milhares) (fonte: Teleco)Milhares 1T08 2T08 3T08 4T08 1T09 2T09Vivo 38.309 40.435 42.277 44.945 45.641 46.819Claro 31.182 33.112 35.668 25,0 38.731 39.587TIM 32.533 33.814 35.206 36.403 36.097 37.826Oi 18.737 20.299 21.867 24.390 25.884 Não DivulgadoBrT 4.578 5.015 5.246 5.605 5.951 Não DivulgadoCTBC 387 406 433 27,2 447 Não Divulgado

De acordo com Ziv and Mulloth (2007), com o passar do tempo e da evolução dastecnologias de infra-estrutura, as operadoras começam a reconhecer e a re-pensar os seusmodelos de negócio, observando que uma das chaves para o sucesso da adoção e difusãodas aplicações móveis, é prover conteúdos e serviços para sua base de clientes.

Uma operadora pioneira neste sentido foi a NTT DoCoMo, subsidiaria da NipponTelephone e Telégrafo do Japão, que possibilitou que seus usuários tivessem acesso aose-mails, a websites e acessassem muitas aplicações, tal como m-commerce Ziv (2005).

Uma estratégia foi o desenvolvimento com as empresas de conteúdo. A DoCoMo fezum acordo com a Disney para oferecer conteúdos para o público infantil. A Vodafone,com seu portal Vodafone Life7, também agiu neste sentido, oferecendo um portal dedados para telefones celulares voltado para jovens. A Vodafone fez acordos com 250parceiros, incluindo Sony Pictures Mobile, uma divisão da Sony Picture Digital Networkse Reuters, para um serviço de notícias.

No Brasil, temos a operadora Vivo, que através do Vivo Live 8, oferece um pacote dedados para seus usuários com possibilidade de acesso aos portais Hotmail, Messenger eSpaces, da Microsoft, através de modelos de celular da Motorola.

7http://www.vodafonelive.co.za/8http://www.vivo.com.br/windowslive/

13

http://www.vodafonelive.co.za/

http://www.vivo.com.br/windowslive/


Neste plano, o custo da navegação e do tráfego de dados para download são gratuitospara o uso destes serviços. Para contratar o serviço, os clientes precisam adquirir o pacote(8.90 R$ mensais), tanto para planos pós-pagos como para pré-pagos.

Esse modelo de negócio oferece novas possibilidades para os usuários da operadoraVivo experimentarem a utilização dos serviços de dados, uma vez que para muitos clientesque já usavam os serviços pela Internet via PC, torna-se uma comodidade a mais, podendoacessar seus emails, MSN ou rede social de qualquer lugar, a qualquer hora.

Interessante destacar que, tanto a operadora (Vivo), que oferece a conectividadeda rede, o fabricante de celular (Motorola), que oferece os aparelhos, bem como, aempresa que oferece os serviços de Internet (Microsoft), realizaram uma tríplice aliança,oferecendo conteúdos de dados para usuários de celulares.

As operadoras trouxeram um diferencial competitivo no setor ao prover conteúdos eserviços para sua base de usuários. As empresas deste setor, por outro lado, controlama estrutura dos preços/custos de cada conteúdo, bem como as margens de lucro (rev-

enues). Normalmente existem acordos entre as empresas envolvidas, que em geral, são aspróprias operadoras e empresas provedoras de conteúdo (content provider) , geralmenteda indústria de mídia (ex. UOL, Disney, Univesal).

No decorrer dos últimos anos, segundo Ziv (2005); Ziv and Mulloth (2007), as oper-adoras se mantem na direção de liderar o desenvolvimento da tecnologia de conectividadee infra-estrutura de redes, enquanto que os fabricantes continuam projetando dispositivoscom aplicações multi-funcionais. No entanto, o tráfego de voz é a maior fonte de receitaspara as operadoras, porém, está iniciando mais uma commodity.

O custo cobrado pelas operadoras, tem sido baixo considerando variações das oper-adoras e sua base de clientes, com planos de preços diferenciados e oferecendo telefones“sem custo” para o usuários Ziv (2005) apud e G. Yuki (2004). Para muitas operadoras, olucro de serviços de dados está iniciando a superação do tráfego de voz. Um exemploé a operadora NTT DoCoMo que está adquirindo mais clientes para sua base, tirandoclientes de seus concorrentes oferecendo um modelo de negócio voltado para oferta dedados, tornando-se mais competitiva.

No modelo de negócio das operadoras observou-se que elas tentam garantir o recebi-mento de partes das receitas gerado pelo conteúdo, compartilham em termos de receitascorrentes, partes dos lucros para seus parceiros de conteúdo. Neste aspecto, operadoras daEuropa, por exemplo, desejam faturar 50% ou menos das receitas provindas de conteúdos,enquanto que a NTT DoCoMo, visa 90% de receitas geradas de conteúdos.

Operadoras como NTT DoCoMo, Verizon e Vodafone utilizam modelos de assinatura

14


para conteúdos descartáveis, tais como mensagens SMS e downloads únicos Ziv (2005).Ou seja, operadoras também determinam o preço do conteúdo e o modelo de negóciosdestes produtos.

O modelo de negócios das operadoras é semelhantes a empresas provedores deconteúdo voltados para Internet (ex. UOL), no qual provê um limite, excluindo certosconteúdos oferecidos aos seus clientes. Segundo Ziv (2005), trata-se de uma abordagemde controle de provisionamento de conteúdo do mercado, chamado de Walled Garden,que deu às operadoras o poder de decidir como o conteúdo foi colocado sobre o top

deck da tela do dispositivo, onde normalmente os assinantes acessam primeiro. Umaproblemática é definir um modelo de negócio de como monetizar os conteúdos paradistribuição sobre as plataformas móveis.

Pesquisas de Quintella and Rodrigues (2005), propõem alguns fatores críticos desucesso para as operadoras considerarem quanto ao lançamento de novos serviços decomunicação de dados. Os fatores considerados válidos e plausíveis, de acordo com avisão dos usuários (VU) e na visão das operadoras (VO), são: Propaganda Informativa(VU e VO); Inovação no desenvolvimento dos serviços (VU); Qualidade do serviço(VU); Facilidade de utilização do serviço (VU); Aplicabilidade do serviço (VU e VO);Disponibilidade do serviço (VU); Atendimento Call Center (VU e VO); Clareza nacomunicação sobre o serviço (VU); Quantidade de terminais de celulares compatíveis(VU); Taxa de transmissão (VU); Abrangência do serviço (VU); Disponibilidade doServiço do ponto de vista de cobertura (VU); Atendimento nos pontos de venda (VO);Comprometimento de fornecedores e parceiros (VO); Definição de modelos de negóciocom parceiros (VO); Educação do mercado (VO); Ofertar Serviços da concorrência (VO);Posicionamento da empresa (operadora); Qualidade do Serviço: Aspectos técnicos (VO).

O suporte e pontos de vendas são fatores chaves. Um fator imprescindível é a

qualidade do atendimento aos clientes, seja via Call Center ou nos pontos de venda.

A clareza na comunicação, bem como, informações com relação a preços, taxas de

transmissão, cobertura, e qualquer outra vantagem ou restrição do serviço deve ser

comunicada de forma clara aos usuários. Além disso, a qualidade dos serviços com

relação à cobertura, disponibilidade das plataformas que suportam os serviços, taxa

de transmissão, etc, é um fator crítico para o sucesso do lançamento. Experiências

negativas podem criar resistência à sua utilização Quintella and Rodrigues (2005).

15


1.2.4 Fabricantes de Celulares

Os fabricantes são os grandes distribuidores dos celulares produzidos. Conforme abor-damos no início do capítulo 2 (vide a Figura 2.1), o telefone deu origem ao celular, quepor sua vez, pouco a pouco vem incorporando novas funcionalidades.

No mercado norte americano, por exemplo, especificamente dos EUA, segundo Muoio(2009) apud comScore MobILens (novembro 2008), podemos observar que a maioria doscelulares produzidos são do tipo Features Phones (89%), com penetração de celularesSmartphones (11%), vide a Figura 1.4.

Figura 1.4 Universo de celulares ativos nos EUA em 2008 (fonte: comScore)

Exemplos conhecidos de empresas citadas por Ziv (2005), estão atuando em difer-entes partes do mundo no ecossistema da computação móvel. Nos EUA por exemplo,as operadoras de telecomunicações Verzon, Sprint e ATT, todas investem recursos sig-nificativos em redes sem fio (wireless). Primeiro na infra-estrutura para acomodar eincrementar a demanda por serviços de rede, agindo como provedores de serviços (videSeção 1.2.3). Outras empresas como Nokia e Ericsson na Europa e Sansung na Coréiadesenvolvem dispositivos móveis e são conhecidas como fabricantes de celulares (Device

Manufactures).As principais empresas envolvidas no ecossistema de celular e que estão a frente no

mercado são: Nokia; Apple; Motorola e RIM (BlackBerry).Segundo Teleco (2009d), a Nokia é o maior fabricante de telefones celulares do mundo.

Fornece também equipamentos, sistemas e soluções para operadores de telecomunicações.Ela atua através de quatro unidades de negócio:* Telefones Celulares (Mobile Phones): Dispositivos móveis centrados em voz;

16


* Multimídia (Multimedia): dispositivos móveis avançados e aplicações;* Soluções para Empresas (Enterprise Solutions): produtos e soluções para o mer-

cado corporativo;* Redes (Nokia Siemens Networks): equipamentos, sistemas e soluções para oper-

adores de telecomunicações.De acordo com Morimoto (2009), a Nokia representa mais de 50% das vendas

mundiais, tanto de telefones Smartphones, feature phones, como os celulares “limitados”.A Apple, segundo Teleco (2009a), fez a revolução do computador pessoal nos anos

70 e reinventou o computador pessoal nos anos 80 com o Macintosh. Além disso, hoje, aApple continua liderando a indústria com inovações nos seus computadores e aplicativosprofissionais. A Apple também liderou a evolução da música digital com o iPod. Entrouno mercado de celular em 2007, com o iPhone (vide Seção 2.3.4). No segundo trimestrede 2009, foram vendidos cerca de 5,2 milhões de iPhones, um crescimento de 37,3%se comparado ao trimestre anterior, e de 626,4% se comparado ao mesmo período doano anterior quando foram vendidas 717 mil unidades. Em jul/08 a empresa começou acomercializar o iPhone 3G e em jun/09 o iPhone 3GS, o que explica o grande crescimentonestes períodos. Em 2008 , a Apple vendeu cerca de 13,7 millhões de iPhones. Umaumento de 269,2%, se comparado à 2007.

Já a Motorola, de acordo com Teleco (2009c), é o segunda maior fabricante detelefones celulares do mundo, fornecendo também produtos e equipamentos, sistemase soluções para operadores de telecomunicações. A Motorola anunciou em 26/03/2008que iria se dividir em duas empresas: Mobile Devices (Telefones Celulares) e Broadband& Mobility. Alguns fatos interessantes: Motorola no 2T09 vendeu 14,8 milhões detelefones celulares no 2T09, mantendo-se praticamente estável enfrentando o grandedesafio de recuperar o crescimento entre os vendors; a Motorola no 1T09 vendeu 14,7milhões de telefones celulares no 1T09, confirmando a tendência de queda, agravada pelacrise financeira internacional; e a Motorola no 4T08 anunciou em 14/01/09 uma reduçãode 4 mil pessoas na sua força de trabalho e resultados preliminares para o 4T08.

Por fim, a Research In Motion Limited (RIM), conforme Teleco (2009e), é umaempresa de tecnologia canadense (fundada em 1984), voltada ao mercado de smartphones,sendo conhecida por fabricar os telefones Blackberry. Segundo Morimoto (2009), aRIM produz um volume pequeno de aparelhos, mas, em compensação, é uma dasmaiores dentro do segmento de smartphones, justamente por produzir apenas smartphones,chegando a ter mais de 50% das vendas nos EUA, mas, em contrapartida, é bem menospopular em outras partes do mundo, incluindo Brasil, onde o uso do aparelho é restrito a

17


alguns nichos, muito embora venha crescendo lentamente.

1.2.5 Provedores de Conteúdo e o Novo Paradigma

Segundo Ziv (2005); Ziv and Mulloth (2007), existem problemáticas no setor da indús-tria de mídia, especificamente dos provedores de conteúdo, com relação a produçãode conteúdos para celular, pois sua utilização se dá em ambiente confuso, em cenáriocom diferentes plataformas disponíveis, diferentes dispositivos, com diferentes dificul-dades para conseguir acessar tais mídias. Não obstante, tais plataformas competem pordefinições de padrões na indústria. Isso impõe dificuldades para empresas provedoras deconteúdo, dificuldades para criação e produção, bem como, utilização e uso das PSC.

Outro fator importante para as empresas provedoras de conteúdos é que no mercadoda indústria de celular, não está muito claro como as grandes empresas podem se ben-eficiar financeiramente da criação e exploração, uma vez que, as operadoras provêm aconectividade e assim, limitam as possibilidades. Entretanto, Ziv (2005) mostra que asempresas engajadas em muitos projetos experimentais que estão utilizando as PSC, têmprovido a liderança nos provedores de conteúdo para as operadoras (vide Seção 1.2.2).

Quando as primeiras redes sem fio (wireless) emergiram como plataformas, nãohavia muitos conteúdos disponíveis para os usuários em geral e o uso do celular ficoulimitado para efetuar chamadas de ligações. O caminho de adoção desta inovação foisimilar ao ocorrido com a WWW, onde inicialmente havia escassez de conteúdos paraintegrar usuários. O celular era uma plataforma enfraquecida, com pouco conteúdo queos usuários necessitavam para acessar.

Um fator importante a considerar neste contexto, mencionado nos trabalhos de Ziv(2005); Ziv and Mulloth (2007); Augustin (2004), foi que usuários deixaram de serleitores passivos tornando-se uma comunidade presente significativa. Diante disso, umdesafio é desenvolver conteúdos adequados para os celulares.

Muitas empresas de conteúdo vêm explorando esse contexto através de ambienteson-line da web, por simplesmente ter o seu conteúdo em algum website, ou portando seuconteúdo HTML para versões simplificadas, evitando assim ter que redesenhar conteúdosexistentes (vide Seção 1.2.2).

Em ambiente wireless dos dias atuais, a plataforma tecnológica é muito mais complexa.Há uma vasta faixa de dispositivos como PDAs, telefones celulares smartphones, e outrosdispositivos híbridos no mercado (tal como Kindle9), e existe uma competição por padrõesde plataformas.

9um pequeno equipamento, criado pela empresa Amazon, que tem a função principal de ler e-books

18


Produzir conteúdos para dispositivos móveis enfrenta cenários diferentes, quandocomparado com os PCs, celulares tem diferentes tamanhos de telas, cores e capacidadesgráficas diferentes, e principalmente, poder computacional variado. Isso dificulta aportabilidade de conteúdos, ou seja, é desejável que um conteúdo possa ser acessado emigualdade de condições pelos usuários, mas isso é muito difícil diante da vasta variedadede tecnologias de dispositivos.

Segundo Ziv and Mulloth (2007), o ecossistema inicial para a oferta dados na indústriade celular colocava as operadoras no centro do sistema, com as fornecedores de conteúdoe fabricantes de celulares sobre um lado, oferecendo seus produtos para as operadoras eos usuários do outro lado, acessando serviços e conteúdos por meio da operadora. Nesteparadigma, as operadoras ofertam os conteúdos para os celulares e os usuários têm poucocontato com os fabricantes de celular.

Embora esse modelo se manteve desde a origem da condução desta indústria, com odesenvolvimento de novos tipos de conteúdo para celular, foi sugerido por Ziv (2005),que o modelo que se apresentava poderia inibir a inovação de conteúdos em todos oslados das entidades envolvidas.

Figura 1.5 Novo paradigma de inovação na indústria de celular (fonte: Ziv (2005); Ziv andMulloth (2007))

Diante disso, se faz necessário um novo modelo de negócio, um paradigma maisligado à rede de dados (networked), conforme a Figura 1.5, caracterizado pela contínuainteração entre os diferentes fornecedores de conteúdo, diferentes fabricantes de celular,bem como, maior envolvimento dos usuários.

Os chamados integradores de conteúdo fornecem serviços de assistência técnica aos

19

1.3. QUESTÕES DE PESQUISA

serviços ligados a ambos os fornecedores de conteúdo e operadoras, além de criar ospróprios portais de conteúdos. Essas ligações são componentes importantes no novoparadigma e servem como base teórico deste trabalho.

A proposta do paradigma propõe que os fornecedores de conteúdo compartilhem aresponsabilidade de desenvolver conteúdos para as operadoras, que podem estruturar omodelo tarifário (preço) de seus conteúdos e compartilhar as margens de lucro com osfornecedores de conteúdo diversos.

1.3 Questões de Pesquisa

Dado que o software assumiu um papel mais importante, surgem então muitas dúvidas,tais como:

Q1. O que de fato torna um serviço ou aplicação “interessante” para os usuários decelular?

Q2. Como empresas envolvidas no ecossistema da indústria de celular, provem conteú-dos e serviços para seus usuários e o que leva à fidelização de clientes?

Q3. Como se dá a satisfação dos usuários que usam os serviços de dados?

Q4. Quais são os serviços de dados existentes e quem é responsável por produzir(ofertar) os aplicativos?

Q5. Grande parte dos usuários utilizará seu celular para acessar a rede de dados, aInternet?

Q6. O uso do celular continuará a ser voltado principalmente para comunicação de voz?

Q7. Como os desenvolvedores de software se inserem neste contexto e quais são suasdificuldades?

Q8. As PSC permitem aos desenvolvedores criarem aplicações de forma a “cobrir"asdemandas dos usuários por aplicativos?

Além das questões acima, percebe-se outro fator que também deve ser considerado.Há um interesse e crescente uso do celular para acessar a Internet, por parte dos usuários.Mas será que o custo (da infra-estrutura de redes), dos pacotes de dados cobrados pelasoperadoras, favorece para essa realidade?

20

1.4. OBJETIVOS E CONTRIBUIÇÕES

Esses questionamentos iniciais, nos provocam e nos motivam a refletir como funcionao mercado nesta indústria e como se dá, principalmente, a oferta de conteúdos e os seusimpactos no desenvolvimento de software no setor.

1.4 Objetivos e Contribuições

Diante do exposto, nota-se a importância do tema de estudo e, neste sentido, as propostasdesta dissertação são: compreender as dificuldades e oportunidades do desenvolvimentode software para celular, dos desenvolvedores individuais e de terceiros, bem como,desenvolver uma ferramenta capaz de reusar aplicativos (denominado DemoTool), per-mitindo a integração do ambiente de desenvolvimento (IDE) com a PSC do fabricanteMotorola.

O DemoTool é uma ferramenta projetada para reusar aplicativos demonstrativos(demos), cuidadosamente elaborados e com seus respectivos códigos fontes, cenáriose funcionalidades no qual se propõe, voltada para o desenvolvimento de aplicativos dalinguagem Java, que funciona integrada no ambiente de desenvolvimento Motodev Studiofor Java ME, da fabricante de celular Motorola,Inc.

Neste contexto, essa pesquisa desenvolveu e avaliou a ferramenta DemoTool parareusar, de forma amigável, aplicativos demos para um projeto de programação no ambi-ente Motodev Studio for Java ME.

1.4.1 Objetivos

Com o objetivo de realizar estudo na área de Engenharia de Software, especificamente nodesenvolvimento de software para celular, apresenta-se, nesta dissertação, uma propostade ferramenta para reuso de aplicativos e integração no ambiente de desenvolvimentocom a plataforma de software de celular do fabricante Motorola.

1.4.1.1 Objetivo Geral

Mostrar a utilização da ferramenta DemoTool para reusar aplicativos voltados para celular.

1.4.1.2 Objetivos Específicos

• Permitir aos desenvolvedores de terceiros assimilar rapidamente as possibilidadesde criação de aplicativos para celular;

21

1.5. ORGANIZAÇÃO DA DISSERTAÇÃO

• Promover de forma mais amigável, a integração dos aplicativos demos com oambiente de desenvolvimento da PSC da Motorola;

• Desenvolvimento de uma solução para promover a realização de testes diretamentena PSC, através da integração com o ambiente Motodev Studio for Java;

• Descrever a importância dos aplicativos no contexto da computação móvel;

• Demonstrar as problemáticas envolvidas no processo de desenvolvimento de soft-ware de celular a partir da implementação, testes e distribuição.

1.4.2 Contribuições

• Levantamento bibliográfico das áreas da Engenharia de Software e ComputaçãoMóvel, voltadas para desenvolvimento de software para celular;

• Descrição das principais características dos setores impactados no ecossistemada indústria de celular, no contexto da oferta dados: desenvolvedores e suasferramentas; fabricantes de aparelhos e as operadoras de celular;

• Explicações de como as empresas envolvidas no ecossistema da indústria móvelprovêm conteúdos e serviços para seus usuários;

• Comparações dos principais recursos entre as diferentes tecnologias das PSCexistentes.

1.5 Organização da Dissertação

A presente dissertação está estruturada como descrito a seguir:

• Capítulo 2 apresenta os conceitos básicos sobre computação móvel e das platafor-mas de software de celular, bem como, suas características tecnológicas e impli-cações no desenvolvimento de software;

• Capítulo 3 mostra o ciclo de desenvolvimento de software para celular e discuteas características das ferramentas de desenvolvimento consideradas no trabalho;

• Capítulo 4 apresenta a ferramenta DemoTool, seu projeto de construção de soft-ware até a fase de implantação do produto. Além disso, apresenta-se o estudo decaso para demonstrar a utilização do DemoTool, em contexto da criação de umaplicativo para celular;

22

1.5. ORGANIZAÇÃO DA DISSERTAÇÃO

• Capítulo 5 discute os resultados decorrentes da análise do estudo de caso, assimcomo, os resultados das investigações que guiaram a pesquisa nos setores doecossistema da Indústria de Celular, através de uma pesquisa de campo comusuários de celular;

• Capítulo 6 apresenta as conclusões e considerações finais sobre o trabalho real-izado, destacando as contribuições, as limitações e os pontos de extensão parafuturas pesquisas na área.

23

“A dúvida é o princípio da sabedoria.”

Aristóteles 2Plataformas de Software de Celular

O objetivo deste capítulo é apresentar os conceitos básicos sobre computação móvel e dasplataformas de software de celular, bem como, suas características tecnológicas e impli-cações no desenvolvimento de software. Ao final, demonstramos algumas comparaçõesentre plataformas investigadas, bem como, suas análises.

2.1 Introdução

O mercado de celulares está em franco crescimento mundial uma vez que cada vez maisestes aparelhos estão aptos a serem equipamentos para a Internet e oferecendo um con-junto de aplicativos e serviços que antes somente estavam disponíveis em computadorespessoais.

Os telefones celulares no contexto da Computação Móvel (Móbile Computing) sãodefinidos de forma diferente por pesquisadores. Segundo Augustin (2004), há uminteresse crescente da academia e indústria pela computação móvel, o que pode serobservado pelo número de trabalhos que surgiram na literatura e pelo lançamento deperiódicos como Pervasive Computing, Mobile and Ubiquitous Computing (IEEE) e IEEETransaction on Mobile Computing. Além disso, a Computação Móvel está adquirindomaior popularidade à medida que dispositivos móveis tornam-se disponíveis e oferecemfacilidades de uso para seus usuários.

Para ISAM (2007); Yamim (2004), computação móvel pode ser vista, na sua formamais geral, a computação onde todos os elementos do sistema têm a propriedade demobilidade. O termo computação móvel não é um conceito ainda bem definido, e envolveelementos como hardware, dados, aplicações e usuários que têm a capacidade de semoverem para diferentes localizações durante o curso da computação. Portanto, segundoISAM (2007), dependendo dos elementos que podem se mover, tem-se diferentes cenários

24

2.1. INTRODUÇÃO

na computação móvel:

• (1) o hardware pode se mover (nomadic computing);

• (2) usuário pode se mover entre um conjunto fixo de estações conectadas à rede(wireless computing);

• (3) a aplicação pode se mover (mobile computation: mobile code / mobile agent); e

• (4) o usuário, portando um equipamento portátil (hardware), executando aplicaçõescom dados e código móvel, se locomove (pervasive computing).

Para Loureiro et al. (2003), computação móvel é vista como um paradigma computa-cional que tem como objetivo prover ao usuário acesso permanente a uma rede fixa oumóvel independente de sua posição física. É a capacidade de acessar informações emqualquer lugar e a qualquer momento.

Os celulares conhecidos hoje, surgiram a partir dos telefones fixos, e gradualmente,foram incorporando as funcionalidades e recursos da computação móvel. Isso permitiuusá-lo em movimento, sem a necessidade de fios para utilizá-lo.

O nome celular, segundo Morimoto (2009), vem da forma como as redes das oper-adoras são organizadas, através de torres de transmissão menores, chamadas de células,espalhadas pelas cidades e transmitindo sinais de frequência que são captadas pelosdispositivos.

Figura 2.1 Evolução geral do telefone por funcionalidades (fonte: Neufeld (2009b))

25

2.1. INTRODUÇÃO

A Figura 2.1 ilustra um quadro evolutivo do telefone por suas principais funcionali-dades ao longo do século, conforme Neufeld (2009b).

Na época inicial, o telefone podia somente realizar e receber chamadas para outrostelefones, e somente de um ponto fixo. A partir dos anos 80, já se podia utilizá-lo emmovimento. Nos tempos atuais, o celular (do inglês mobile phone), incorporou váriasfuncionalidades, tais como conhecemos hoje. Na prática, conforme Morimoto (2009),os recursos incorporados foram gradualmente, sendo “copiados"de outros aparelhoseletrônicos, tais como: agendas eletrônicas; câmeras digitais; mp3player; navegadores deGPS; modems USB.

Na ilustração da Figura 2.1, a título de curiosidade, temos a esquerda, Antonio Meucci(reconhecido como o verdadeiro inventor do telefone Schiavo (1958)), no centro, MichaelDouglas (ator norte-americado), e a direita, Steven Jobs (criador da Apple,Inc e PixarAnimations Studios).

Podemos classificar os celulares conforme os seguintes tipos:

• limitados: são aparelhos baratos, feito para pessoas que não tem poder aquisitivomais elevado, e que desejam uma interface mais simples possível;

• feature phones: são considerados aparelhos intermediários, que suportam a insta-lação de aplicativos Java e incluem navegadores Web.

• smartphones: no geral, incluem um sistema operacional.

Segundo Morimoto (2009), traçar uma linha divisória entre os telefones “limitados” eos smartphones é um pouco complicado. As características mais comuns e popularmenteaceitas são que um smartphone deve ser capaz de:

• Rodar um SO completo e permitir a instalação de aplicativos nativos (e não apenaswidgets ou aplicativos em Java);

• Comunicar-se com o PC via USB e Bluetooth;

• Conectar-se à web via GPRS, EDGE ou de preferência 3G;

• Rodar um navegador com bons recursos, oferecer um cliente de e-mails, IM eoutros aplicativos de comunicação;

• Tocar MP3, exibir vídeos e executar jogos.

A seguir, apresentamos as temáticas relacionadas com as plataformas de software decelular.

26

2.2. PLATAFORMAS DE SOFTWARE DE CELULAR

2.2 Plataformas de Software de Celular

Segundo Sangiovanni-Vincentelli and Martin (2001), o conceito de plataforma tem sidodiscutido por anos, mas muitas definições tornam sua interpretação confusa. O conceitode plataforma pode ser entendido conforme citação: “...a platform is an abstraction that

covers several possible lowerlevel refinements. Every platform gives a perspective from

which to map higher abstraction layers into the platform and one from which to define

the class of lower-level abstractions that the platform implies” Sangiovanni-Vincentelliand Martin (2001). Ou seja, no sentido mais amplo, uma plataforma é uma abstração queabrange várias pequenas partes de refinamentos.

As partes representam uma perspectiva de maior captação para mapear camadas, apartir da qual, define para a plataforma as classes de menor nível de abstrações que aplataforma implica.

No contexto da computação, podemos considerar que uma plataforma é uma expressãoutilizada para denominar a tecnologia empregada em determinada infra-estrutura detecnologia da informação, garantindo facilidade de integração dos diversos elementosdessa infra-estrutura.

Para Ziv (2005), a Plataforma de Software de Celular (PSC) é responsável pelaprodução de soluções computacionais no contexto da computação móvel. Ou seja, asplataformas têm impacto no aspecto tecnológico envolvendo celulares.

As plataformas de software de celular têm relação com os sistemas embarcados.Aqueles sistemas com propósitos bem específicos e bem definidos. A essência de umprojeto de sistema embarcado é programar um conjunto específico de funções enquantoatende necessidades como: desempenho, custo, consumo de energia, tamanho e peso.A escolha da arquitetura de implementação destes sistemas embarcados, determinam seo projeto tenderá para se especializar como um componente de hardware ou como umsoftware executando sobre um componente programável Sangiovanni-Vincentelli andMartin (2001).

Ainda segundo Sangiovanni-Vincentelli and Martin (2001) nos últimos anos, asfunções exigidas para projetos de sistemas embarcados, aliada a constante evolução dasespecificações, tornou o desenvolvimento bastante complexo, difícil de prever e controlar.Como consequência, os projetos consideram suas implementações intrinsecamente maisflexíveis, voltadas para componentes programáveis. Por essa razão, e também porque ociclo de fabricação do hardware é mais expansivo em relação ao tempo, implementaçõesde sistemas embarcados baseados em software se tornaram mais populares. Além disso,

27


o incremento do poder computacional dos processadores e a diminuição correspondenteao tamanho e custo, permitiram os projetos embarcados direcionarem as funcionalidadespara software.

Há uma similaridade intrínseca entre a plataforma de software de celular e o sistemaoperacional do sistema embarcado do dispositivo Morimoto (2009). Podemos com-preender essa semelhança ao analisar uma típica problemática dos projetos de sistemasembarcados: a escrita de código de baixo nível.

Segundo pesquisas de Sangiovanni-Vincentelli and Martin (2001), para lidar com asrestrições de desempenho e o custo embutido na maioria dos sistemas, programadoresescrevem os códigos usando linguagens de baixo nível, como C e Assembly. As ferra-mentas de criação e depuração são basicamente as mesmas que as ferramentas padrões desoftware: compiladores, interpretadores, depuradores e cross-compilers. A diferença é aqualidade: A maioria das ferramentas de software são bastante primitivas, em comparaçãocom ferramentas equivalentes para plataformas mais ricas. Assim, devido às limitações dedesempenho, compatibilidade e requisitos de memória, sistemas embarcados tornam-sedependentes do sistema operacional no qual foi projetado.

Desejar essas ferramentas em sistemas de software embarcados também requer suportedo hardware para depuração e avaliação de desempenho, no qual são importantes para osprojetos de sistemas embarcados.

A proximidade entre um sistema embarcado e uma plataforma de software de celular,conforme discutida anteriormente, se dá à medida que, os sistemas embarcados dire-cionam os seus projetos para um software executando sobre um componente programável,estendendo funcionalidades para assemelhar-se com os recursos de um sistema opera-cional. Razão pela qual, segundo Sangiovanni-Vincentelli and Martin (2001), quando osoftware embarcado foi simples, não era necessário mais sofisticações no sistema. Noentanto, com o aumento da complexidade por aplicações em sistemas embarcados, apresente abordagem primitiva tornou-se o gargalo.

Considerando que existem similaridades entre a plataforma de software e o sistemaoperacional de um sistema embarcado no celular, os conceitos se fundem para formar umaplataforma de software de celular Verkasalo (2009); Morimoto (2009). Essa plataformapode ser considerada sinônimo para um sistema operacional de celular Verkasalo (2009).Ou seja, essencialmente uma plataforma de software funciona sobre o topo no qualaplicativos podem executar.

Em Morimoto (2009), ressalta-se que há vantagens nesta centralização dos compo-nentes de hardware e software como plataforma para usuário, porque há mais garantias

28


que os aparelhos realmente funcionem como esperado, pois havendo necessidade de in-stalação de aplicativos, o usuário não precisa instalar drivers ou se preocupar em resolverdependências de software para tratar incompatibilidades indesejáveis (como no caso dosPCs). Mas por outro lado, salienta que isso restringe um pouco sua liberdade de uso.

De acordo com Cho and Jeon (2007), uma PSC provê um ambiente para desenvolvi-mento e execução de aplicativos, criando novas aplicações para o celular. Para Verkasalo(2009), a contribuição chave de uma PSC é sua capacidade de programação, agregandotanto softwares padrões já embutidos no sistema, como novas aplicações que podem serinstaladas e usadas. Segundo Morimoto (2009), as PSC, tais como os smartphones, são oresultado de um longo processo de evolução e convergência de dispositivos. Por exemplo,os telefones celulares são hoje multifuncionais, capazes de executar uma ampla variedadede aplicações, ambos para uso empresarial e para o consumidor final.

“É comum que os telefones inteligentes (do inglês smartphones) sejam chamados

de “plataformas”, indicando justamente esta combinação intrínseca entre o hardware, o

sistema operacional e o conjunto de aplicativos que rodam sobre ele”Morimoto (2009).Os celulares smartphones incluem recursos tais como voz, GPS, câmera, música,

vídeo, jogos 3D e serviço Bluetooth. Muitas vezes agregam mais funcionalidades reunidasdo que os PCs. Por essa razão os celulares deste tipo são frequentemente vistos por seususuários como uma extensão para o seu próprio PC. Embora, conforme Oliver (2008),eles tenham várias restrições de poder computacional, tais como: pouco processamento,limitada memória RAM e memória de armazenamento.

Figura 2.2 Arquitetura de uma plataforma de software de celular (fonte: Cho and Jeon (2007))

A Figura 2.2 apresenta uma arquitetura típica de uma plataforma de software decelular segundo Cho and Jeon (2007), que consiste na representação do hardware do

29


dispositivo na base, o sistema operacional1 (SO), um middleware 2 e aplicações no topo,sendo que as separações são divididas por camadas inter-relacionadas.

Podem existir diferentes aplicações, mas todas precisam rodar em algum middlewareque fará a ponte com o sistema operacional. As responsabilidades de cada camada sãoCho and Jeon (2007):

• SO: o sistema operacional gerencia os recursos de hardware e o controle de apli-cações quando os processos usam os recursos do sistema. Os principais SO dostelefones celulares são: Symbian OS, Linux, RIM e Windows Mobile; iPhone OS;Android (Linux);

• Middleware: conectam aplicações com o SO. Recebe as requisições de umaaplicação e envia as requisições para o SO. Os maiores middlewares em telefonescelulares são S60, UIQ, BREW, Qt Cho and Jeon (2007);

• Aplications: são os aplicativos pelos quais os usuários interagem com o SO. Asmaiores aplicações em telefones celulares são serviços de interface de usuário (UIService), serviço de chamada de voz, SMS, serviço de rede de internet, serviço demultimídia, audio/video, serviço de GPS, serviço e agenda eletrônica, etc.;

• Mobile Phone Hardware: componentes físicos de hardware do dispositivo.

Para ilustrar as implicações práticas para os usuários referente à centralização derecursos de um smartphone, recorre-se a analogia citando (Morimoto (2009), p.15): “Ao

comprar um smartphone baseado no S60, você fica restrito aos aplicativos escritos

para o S60; ao comprar um com o Windows Mobile, fica restrito aos aplicativos do

Windows Mobile, e assim por diante". Ou seja, a escolha da plataforma de software ébastante importante, pois a instalação de aplicativos dependerá do suporte que o sistemaoperacional do celular oferecerá bem como a sua oferta de aplicativos. Por outro lado, aenorme variedade de modelos e plataformas diferentes torna difícil ter uma visão geraldas opções existentes.

O trabalho de Cho and Jeon (2007) mostra que a grande demanda dos usuários detelefones celulares está requerendo não somente serviços de voz e SMS, mas também

1do inglês operation system (OS), responsável pelo gerenciamento e coordenação de atividades ecompartilhamento de recursos do computador. Silberschatz et al. (1988)

2Middleware é definido como uma camada de software que reside em cada máquina, situada entreo sistema operacional e as aplicações distribuídas, com o propósito de esconder a heterogeneidade dasplataformas cooperativas e de prover uma maneira simples, consistente e integrada do ambiente deprogramação distribuída. Batista (2008)

30


vários serviços como aplicações multimídias e acesso a redes e Internet, exigindo aexecução de forma concorrente (vários ao mesmo tempo) sem nenhum problema técnico.Diante disso, é cada vez maior as categorias de smartphones que permitem às pessoasusarem diferentes aplicativos para várias necessidades. Seja para o acesso e navegaçãona Internet, para consulta de e-mail, mensagens instantâneas, bem como trabalhar comdocumentos, lista de contatos e muito mais. Deve-se destacar que essa demanda acelerao desenvolvimento de aplicações para celulares.

Uma das grandes vantagens dos smartphones segundo (Verkasalo (2009), p.2) éque eles combinam funções off-line, como gerenciamento de informações pessoais ouaplicações de escritório, com serviços on-line como comunicação pessoa-a-pessoa ounavegação de internet. Efetivamente os celulares estão evoluindo na direção de simplescomunicadores para tornarem-se computadores. Portanto, com a explosão de funcional-idades providas pelos celulares smartphones e similares, aumentou significativamentea demanda por funcionalidades tais como usados hoje nos PCs Cho and Jeon (2007);Yamakami (2005); Verkasalo (2009); Ziv and Mulloth (2007); Oliver (2008).

Por outro lado, conforme expõem Cho and Jeon (2007), as demandas atuais deaplicações excedem as capacidades atuais das plataformas de software instaladas noscelulares. Isso motiva os fabricantes de celulares a encontrar uma forma mais eficientepara evoluir as plataformas de software para a próxima geração de infra-estrutura de redesde comunicação e dos dispositivos celulares.

Os usuários finais continuam a demandar a fabricação de novos celulares para provercontinuamente novos serviços e aplicações para suas necessidades. Porém, não tendo asaplicações esperadas, muitos usuários sentem desejos de consumir novas tecnologias.

O sistema operacional do smartphone é uma escolha crucial para os usuários Mo-rimoto (2009); Oliver (2008), pois será através de sua plataforma que os aplicativospoderão ser instalados e utilizados. Essa escolha, para muitos dos casos é mais importantedo que os recursos de hardware do aparelho. Estas observações também são destacadaspor Ziv (2005); Ziv and Mulloth (2007), mas referindo-se as operadoras e aos provedoresde conteúdo, que precisam estar atentas a essas tecnologias para atender seus clientes.

A seguir apresentamos as principais plataformas usadas no mercado e consideradasneste trabalho, suas características e peculiaridades.

31

2.3. PLATAFORMAS DE CELULARES

2.3 Plataformas de Celulares

Historicamente, a inovação sobre PSC teve foco sobre o desenvolvimento da infra-estrutura e dispositivos. A ênfase foi exclusivamente sobre a tecnologia, permitindoque um aplicativo não fosse finalizado quando uma ligação precisasse ser atendido ourealizada. Com o passar do tempo e da evolução das tecnologias de infra-estrutura, as PSCtornaram-se mais robustas, com maiores velocidades de transmissão de dados, melhorqualidade do serviço, além de mais sofisticados dispositivos. A chamada rede sem fiode terceira geração (3G) tem possibilitado maiores quantidades de tráfego de dados epermitindo que usuários acessem uma variedade de aplicações de negócios, bem comoentretenimento Ziv (2005); Ziv and Mulloth (2007).

Hoje existem várias plataformas de software sendo usadas nos diferentes celularesproduzidos. Isto se deve porque cada tecnologia da PSC usada no celular, têm suascaracterísticas, interferindo desde o período de desenvolvimento, até o desempenho dosistema. Essa tecnologia tem um importante papel para os fabricantes, o que impactadiretamente no forte e competitivo mercado dos celulares Cho and Jeon (2007).

Existem várias plataformas consolidadas atualmente, de vários fabricantes. A Tabela 2.1,apresenta os principais fabricantes e sua participação em vendas no mercado mundial desmartphones, referentes ao terceiro trimestre de 2008 em comparação com 2007.

Tabela 2.1 Participação de mercado mundial 2008/2007, por fabricantes de Smartphones (fonte:Canalys (2008))

As principais plataformas, fabricantes de celular e suas participações de mercado sãoapresentadas na Tabela 2.2 e Tabela 2.1. Plataformas como Symbian, Windows Mobile,iPhone (Apple) e Android estão transformando a indústria tal como foi a evolução do PCVerkasalo (2009).

O Symbian mantém a liderança das plataformas comercializadas no mercado (

32


Tabela 2.2), sua participação no terceiro trimestre de 2008 (46,3%), seguido por iPhoneda Apple, que deixou a quinta posição em 2007 (3,6%) para segunda posição em 2008(17,3%). A RIM (BlackBerry) ocupando a terceira posição (15,2%), seguido pelo quarta equinta posições, Windows Mobile da Microsoft (13,6%) e Linux (5,1%) respectivamente.

Tabela 2.2 Participação de mercado de smartphones no mundo 2008/2007 (fonte: Canalys(2008))

Segundo Verkasalo (2009), as plataformas abertas criarão um novo cenário de ino-vação de serviços para celular, com oferta de aplicativos diversos. Assim, espera-se focara inovação dirigida para usuário, com APIs abertas e conectividade com a Internet, sendofatores-chave para sustentar essa evolução, juntamente com os smartphones com as PSCabertas servindo como catalisadores da evolução.

Tal cenário permitiria que desenvolvedores espalhados pelo mundo pudessem nãosomente criar novas aplicações, mas portar aplicações existentes para as plataformas desoftware de celular. Com o aumento da oferta de aplicativos poderia melhorar a demandaexistente hoje Verkasalo (2009); Ziv and Mulloth (2007).

A seguir apresenta-se as PSC baseadas em Symbian, Linux, Windows Mobile, iPhonee Android. Também discuti-se a plataforma de execução de aplicativos para celular JavaME e sua relevância no mercado de desenvolvimento de software.

2.3.1 Plataformas baseadas em Symbian

O desenvolvimento da plataforma Symbian foi baseada no Sistema Operacional EPOC daempresa Psion, rodando somente em processadores ARM. As versões mais recentes desseSO deram origem ao Symbian, que foi projetado para considerar os recursos do sistemacom pouca memória e baixo consumo de energia. Atualmente o número total de telefonescom Symbian ultrapassou 70 milhões de celulares no mundo, segundo estudos de Cho

33


and Jeon (2007) apud Coverity (2006). A plataforma Symbian podem usar o middlewareS60 ou UIQ Oliver (2008), em aparelhos da Nokia, Samsung e Sony Ericsson.

Os middlewares S60 e UIQ são interfaces que rodam sobre Symbian, incluindoaplicativos e bibliotecas de desenvolvimento, enquanto que Symbian é o SO, que incluidrivers e bibliotecas de funções. A principal diferença entre S60 e UIQ era a sua interface.UIQ era baseado no uso de teclas touchscreen3 e da stylus. O S60 era controlado atravésdas teclas. Os dois middlewares tradicionalmente eram parcialmente incompatíveis, jáque de um lado o S60 (desenvolvido pela Nokia e alguns poucos modelos da Samsungentre outros), e o UIQ (alguns aparelhos da Sony Ericsson e Motorola). O S60 segundoMorimoto (2009) sempre foi o mais usado, porque recebia maiores investimentos naplataforma e vendia um volume muito maior de aparelhos no mercado.

As vantagens do Symbian são o fato de ele ser desenvolvido com apoio de váriosfabricantes e de ele ser um sistema leve, possibilitando a fabricação de aparelhos maiscompactos, sem que as funções ou autonomia da bateria fossem comprometidas Morimoto(2009).

O SO desta plataforma gerencia os recursos físicos (memória e CPU) do telefone efaz as aplicações executarem de forma estável e efetiva no celular. Possui um conjunto deextensões que foram definidos para expandir os recursos e as capacidades dos dispositivos,oferecendo um conjunto de APIs do Symbian. O serviço de middleware S60 da plataformaSymbian (Figura 2.3) Cho and Jeon (2007) é a camada no qual os serviços básicos dodispositivo são incluídos.

A camada chamada S60 Platform Services inclui internamente vários outros serviços,tal como o Application frame service que permite aplicações e o servidor ser executadocomo segue: o framework de serviço de UI controla a interface de usuário do dispositivo,o serviço gráfico é desenhado na tela do dispositivo, o serviço de localização controla osdados relacionados com informações de localização, serviços baseados em Web são con-trolados pelo serviço Web e assim por diante. Os serviços de multimídia são controladosem camada própria, reconhecendo áudio/vídeos suportados. Serviços multimídia incluemrecursos de gerenciamento de direitos autorias (DRM) Cho and Jeon (2007).

O middleware S60 inclui a camada Java ME e Java Technology for the Wireless Indus-

try (JTWI). Este recurso permite desenvolvedores de terceiros incluírem suas aplicaçõesprogramando aplicativos usando a linguagem Java. Cho and Jeon (2007) O S60 incluitrês suportes de linguagens de programação: C++, Java e Python. Symbian foi projetado

3touchscreen é a capacidade de detectar a presença e localização da área que foi pressionada na regiãoda tela

34


Figura 2.3 Diagrama da plataforma de software Symbian S60 (fonte: Cho and Jeon (2007))

em C++ e a S60 fornece bibliotecas (API) em C++, o que permite desenvolvedoresotimizarem suas aplicações em seus telefones desta plataforma. A Nokia disponibilizavários SDKs4 em seu site 5 para desenvolvedores criarem suas aplicações.

Figura 2.4 Modelos celulares baseados em Symbian S60 e UIQ (Nokia E51 e Sony P1) (fonte:Cho and Jeon (2007))

Em 2008 Morimoto (2009), quando a Nokia (então detentora de 48% das açõesdo Symbian) comprou a maioria das ações restantes tornando-se sócio majoritário datecnologia, incluindo direitos sobre o sistema. Em seguida anunciou abertura do códigofonte e a transferência do desenvolvimento para uma fundação neutra, a Symbian Foun-dation. Pouco tempo depois, a Sony anunciou a paralisação do desenvolvimento do UIQe cancelou o lançamento de diversos modelos baseados nele. Diante disso, a S60 torna-se

4Software Development Kit (SDK): conjunto de ferramentas que permitem desenvolver aplicativospara a plataforma

5www.forum.nokia.com

35

www.forum.nokia.com


a interface principal da plataforma Symbian.A plataforma de software baseada em Symbian oferece maior abertura do que outras

plataformas de celular existentes Cho and Jeon (2007). Devido às características deplataforma aberta, fabricantes de celulares que usam essa plataforma têm mais probabili-dades de encontrarem desenvolvedores de aplicações. Se os fabricantes de dispositivosadotarem a plataforma Symbian eles podem fazer aplicações para seus aparelhos de formamais fácil e rápida. Plataformas como Symbian incrementam a competição mercadológicado consumo de celulares e despertam o desejo e interesse de usuários finais.

2.3.2 Plataformas baseadas em Linux

Linux foi desenvolvido por Linus Tovalds em 1991. Ele tem sido mantido como projetoopen source por desenvolvedores ao redor do mundo. Hoje vários processadores sãoportados para Linux tais como: Intel x86, AMD x86-64, ARM, Compaq Alpha, CRIS,DEC VAX, H8/300, HP PA-RISC, IBM S/390, Intel IA-64, MIPS, Motorola 68000,PowerPC, SPARC, Ultra SPARC, e v850 Cho and Jeon (2007).

Uma das vantagens de usar Linux em sistemas embarcados é que ele é livre deroyalties, permitindo reduzir custos de fabricação e da matéria-prima essencial (Bill of

materials - BOM6).Linux também permite aos desenvolvedores desenvolver e depurarar aplicações

através de ferramentas já conhecidas. Isso possibilita aos desenvolvedores construíremaplicações rapidamente. Linux possui muitas APIs que são usadas no desenvolvimento deaplicações de várias formas, oferecendo flexibilidade para construção de várias aplicaçõescom alta qualidade. Os fabricantes podem portar essas aplicações baseadas em POSIX

dentro do Linux em seus celulares e usá-los.A Motorola comercializou no mercado chinês o modelo de celular A760 em 2003,

com plataforma baseada em Linux. Esse modelo foi o primeiro celular no mundo a usar oLinux. Depois o fabricante ofertou outros modelos tais como: A768, A768i, A780, A910,E680, E680i, MING, RAZR2, ROKR E2, ROKR E6, e RIZR Z6 (Cho and Jeon (2007),p.3).

A plataforma EZX baseada em Linux da Motorola, também fez bastante sucessoem outros países asiáticos, com os modelos A1200i e o A1200E. O EZX utiliza umkernel Linux otimizado pela Montavista7, rodando uma interface proprietária, baseado na

6 BOM: no sentido mais amplo, significa uma lista de partes ou componentes necessários para construirum produto NEMI (2002).

7MontaVista Software é uma empresa desenvolvedora de software especializada em sistemas embarca-

36


biblioteca Qt (Morimoto (2009), p.57) .Devido à característica básica do sistema operacional Linux, uma plataforma baseada

nele pode reduzir o custo de desenvolvimento, teste e atualização de um telefone celular,reduzindo também o seu tempo de lançamento no mercado e suas aplicações, provendouma flexível e estável tecnologia para acelerar a inovação no desenvolvimento de softwarepara celular. Por essa característica o fabricante Motorola decidiu usar a plataforma Linuxno desenvolvimento de seus celulares.

Por outro lado, o EZX pouco evoluiu de 2003 a 2007, o que fez com que ele ficasserapidamente ultrapassado em relação a outras plataformas. Segundo Morimoto (2009),as razões disso é que não foram desenvolvidos muitos aplicativos para a plataforma, jáque a Motorola nunca disponibilizou um SDK para ele. Outras razões, em termos gerais,faltaram investimentos no desenvolvimento do sistema da plataforma e pouco estimulopara criação de aplicativos. Isso acabou por negar a principal vantagem de utilizar oLinux, que são a possibilidade de portar aplicativos de outras plataformas, reaproveitaremcódigos e criar uma comunidade em torno do sistema.

A Figura 2.5 (esquerda), exibe um diagrama representando a plataforma Linux usadapor celulares Linux da Motorola. Esse diagrama é similar a estrutura geral do SO Linux.O kernal do Linux que a Motorola usa em sua plataforma de software é a mobilinux, sobreo SO da Montavista. A camada de Services, localizado acima da camada do kernel, recebeas requisições das aplicações do dispositivo e entrega as requisições traduzidas para okernel do Linux. Essa camada inclui bibliotecas de chamadas de sistema. TAPI, DRM,Framework, codecs de aúdio, codecs de imagens e serviços de mensagem. A camadamais acima são relativas as aplicações executadas pelos usuários finais. As aplicaçõesincluem ligações, tocadores de música, calculadora, SMS, aplicações Java VM, câmera,games, etc.

A plataforma Linux representada pela Figura 2.5 (esquerda), suporta somente ambi-ente de desenvolvimento voltado para o próprio fabricante, enquanto que atual plataformade software baseada em Linux (Figura 2.5 (direita), busca tornar a plataforma menosfechada, tentando concorrer com as plataformas abertas Cho and Jeon (2007). A diferençaestá na adição de uma camada Application Framework, que permite gerenciar a criaçãode aplicações, registrar e remover aplicativos.

A plataforma de software como demonstrada na figura Figura 2.5 (direita), permiteaos desenvolvedores de terceiros, criarem suas aplicações e adicioná-las para determi-nado aparelho. Como resultado, fabricantes de celulares podem construir e incentivar

dos para Linux

37


Figura 2.5 Plataforma Linux da Motorola / Geração seguinte da plataforma Linux da Motorola(fonte: Cho and Jeon (2007))

desenvolvedores construírem aplicações.A Motorola tem padronizado a plataforma Linux através da iniciativa LiMo. O LiMo,

que é mais aberto, isto é, seu código fonte acessível, que o EZX, é mantido por umafundação que inclui empresas como a NEC, Panasonic, Samsung Eletronics, Vodafone,NTT DoCoMo Morimoto (2009); Cho and Jeon (2007). A iniciativa da fundação, como projeto LiMo, busca prover benefícios de baixo custo de desenvolvimento, alta flexi-bilidade, além de incentivar o ecossistema em torno da plataforma Linux. A Figura 2.6mostra dois modelos da plataforma da Motorola baseados em Linux.

Figura 2.6 Modelos baseados em Linux (MotoRIZR Z6 / MotoMing A1200) (fonte: Cho andJeon (2007))

A parceria de vários empresas em torno da plataforma Linux (do projeto LiMo), gerouespectativas e especulações, e como resultado, acredita-se que vários outros aparelhoscom a plataforma Linux serão lançados no futuro Cho and Jeon (2007).

O LiMo foi usado como base para a plataforma “MotoMAGX” Morimoto (2009).Nesta iniciativa, o fabricante Motorola disponibilizou seu SDK para a plataforma (oMotodev Studio8). Entretanto, a Motorola acabou desistindo de continuar o seu de-

8 http://developer.motorola.com

38

http://developer.motorola.com


senvolvimento, alegando cortar custos e partindo para investir na plataforma WindowsMobile e Android, além dos telefones de seus modelos antigos (plataforma P2K), com-prometendo o futuro do LiMo.

Há ainda o projeto que visa criar uma plataforma para smartphone totalmente aberta(SO e hardware), baseada em Linux, chamada OpenMoko (Open Mobile Free9), organi-zado pela FIC (fabricante de hardware).

Segundo Morimoto (2009), “. . . os smartphones baseados em Linux ainda são a

exceção dentro de um mercado dominado pelo S60, pelo Windows Mobile e, em menor

grau, pelo IPhone. Entretando, a disponibilidade em maior escala de aparelhos com

o Android pode começar a mudar as estatísticas a partir de 2009.” Ou seja, há umtendência de aumento de plataformas baseadas em Linux no mercado dos smartphonescom a chegada do Android.

2.3.3 Plataformas baseadas em Windows Mobile

Windows Mobile (WM) é uma plataforma de celular da Microsoft para smartphones.Atualmente a plataforma vem diminuindo sua participação de mercado, com apenas13,6% de participação total (Tabela 2.2), embora já atue no ramo desde 1997. As versõesiniciais da plataforma foram voltadas para handhelds10 (com SO Windows CE).

Segundo Morimoto (2009), “ . . . a concepção inicial foi que os aparelhos servissem

como opções mais leves e mais baratas que os notebooks, permitindo editar documentos

e executar outras tarefas básicas.” Um dos problemas foi que tais aparelhos eram caros,limitados e muito lentos. Além disso, não havia muitos softwares para a plataforma, nãoatingindo muita aceitação. Embora fabricantes como HP continuaram lançando modelosaperfeiçoados, contribuindo para com maior popularidade, porém, sem grandes sucessosde venda.

Com a chegada da versão da plataforma WM 5.0, houve avanços principalmente namídia de armazenamento, introduzindo a memória Flash (persistent storage), que segundoMorimoto (2009), a mudança simplificou o design dos aparelhos, havendo possibilidadesde utilizar baterias removíveis. Isso possibilitou que os dados não fossem mais perdidosna remoção da bateria e, adicionalmente, permitia instalar aplicativos diretamente nocartão de memória.

A plataforma WM tornou-se um SO compacto, combinando uma suíte de aplicaçõesbásicas para dispositivos celulares. O seu desenvolvimento, segundo Zhang et al. (2008)

9http://www.openmoko.org10Computador de mão, também conhecido como PDA, Pocket PC ou Palm top

39

http://www.openmoko.org


tem sido gradualmente acelerado com ajuda da API Win32 (típica das versões do SOWindows para Desktop), bem como bibliotecas para interface de usuário ricas, ou seja,com mais recursos disponíveis e fácil utilização, providas pelo framework compacto.NET.

Além disso, o desenvolvimento para celular nesta plataforma WM pode ser implemen-tado usando o compilador do Visual Studio 2005, em conjunto com o SDK Mobile 5.0para Pocket PC emulador de smartphone e software de sincronização ActiveSync. Todosem conjunto com a IDE (Integrated Development Environment) da Microsoft. Zhanget al. (2008) destaca que o desenvolvedor pode usar aplicações GUI, desenvolvimentode consoles com aplicações de Windows Forms, web sites e web services. Por outrolado, sabemos que tais recursos nesta plataforma consomem razoável capacidade deprocessamento e memória, diminuindo a vida útil da bateria. Mesmo assim, conformecitado por Becher et al. (2007), o WM destacou-se em relação a outros sistemas opera-cionais da época, pois o processador roda sobre arquitetura ARM, aumentando o poderde processamento.

Figura 2.7 Modelo baseado em Windows Mobile 6.1 (Motorola Q11) (fonte: Morimoto (2009))

A Figura 2.7 demonstra um aparelho Windows Mobile 6 Standard, do fabricanteMotorola. Além das mudanças na interface e nos componentes do sistema, há diferençascom relação a grade de aplicativos compatíveis, ou seja, aplicativos da versão standardpara funcionarem na profissional devem ser adaptados Morimoto (2009).

A partir da versão da plataforma WM 6, a Microsoft mudou a nomenclatura dasedições conforme segue:

• Windows Mobile 6 Standard: sem recurso de touchscreen;

• Windows Mobile 6 Profissional: com suporte a recurso de touchscreen.

40


• Windows Mobile 6 Classic: destinado a palmtops sem funções de smartphone.

As versões mais recentes do sistema (versão 6), trazem as principais mudanças queforam feitas na interface e nos aplicativos integrados, melhorando a compatibilidade entreos novos aparelhos e os aplicativos desenvolvidos para o WM 5 Morimoto (2009). Poroutro lado, apresentam também as principais críticas que são a interface complexa e odesempenho, considerado inferior a outras plataformas concorrentes.

O ganho do WM é a sua facilidade de desenvolver aplicativos para a plataforma Mori-moto (2009); Zhang et al. (2008); Oliver (2008). Embora o seu modelo de licenciamentodo SO acaba aumentando o custo para o fabricante interessado. Diante de plataformasmais rápidas e com interfaces mais elaboradas, a tecnologia já dá sinais de tendência deperda de mercado (Tabela 2.2).

2.3.4 Plataformas baseadas em iPhone

O iPhone é a plataforma da Apple. O celular mais recente é chamado de iPhone 3GS(Figura 2.8), e tem obtido bastante exposição e crescido em popularidade. Os pontos fortessão a interface e a grande variedade de aplicativos, que são comercializados através daAppStore11. Apesar de não ter teclado, o iPhone da Apple oferece uma forma convenientede entrada de texto usando um teclado sensível ao toque (touchscreen), que funciona bemgraças a combinação da sua interface otimizada com um bom recurso de sensibilidadeMorimoto (2009).

Segundo Zhai et al. (2009), por usar o recurso completo de interface de usuáriotouchscreen, o iPhone tornou-se um sucesso fenomenal. A digitação textual no celular,por exemplo, é um grande avanço proporcionado pela plataforma e uma excelente opor-tunidade para conduzir em escala mundial a experiência de escrever com recursos deShapeWriter12, que é uma tecnologia desenvolvida em laboratório e resultado de muitosanos de pesquisa no campo de Interface Homem-Computador (IHC).

Segundo Morimoto (2009), o iPhone usa uma versão reduzida do SO MacOS X(baseado no Unix BSD), portada para processadores ARM (iPhone OS), personalizadapara rodar com restrições de poder computacional, pouca memória e processamento.Além disso, o iPhone possui um acelerômetro que é bem aproveitado pelo software, isto é,

11AppStore é uma loja virtual para comercializar ou ofertar dados e aplicativos para produtos Applecompatíveis

12Um recurso para entrada de dados textuais usando sensores, selecionando teclas e arrastando uma comas outras até formar a palavra (http://www.youtube.com/watch?v=WtlyuuYmFN0)

41

http://www.youtube.com/watch?v=WtlyuuYmFN0


um sensor que permite determinar movimento, cujas funções de interface são acionadaspor gestos.

Figura 2.8 Modelo baseado no iPhone (iPhone 3GS) (fonte: Morimoto (2009))

Para Morimoto (2009), a grande sacada da Apple foi reunir no iPhone recursos básicoscomo a possibilidade de navegar, ler os e-mails, escutar músicas, assistir vídeos, acessaro Google Maps, instalar aplicativos adicionais de forma acessível às pessoas sem muitosconhecimentos técnicos, associado a um grande esforço de marketing para divulgação doproduto.

Na pesquisa de Oliver (2008), observou-se que após sair da caixa (equipamento recémadquirido), tanto o celular iPhone bem como o seu SDK são extremamente limitados,em relação aos requisitos da lista desejável (Seção 2.4), ou seja, o SDK não permiteaplicações iniciarem recurso de WiFi ou recuperar informações sobre alguma torre decelular, embora, permite as aplicações detectarem se o iPhone tem conectividade WiFi,no entanto, as mesmas aplicações não podem transmitir em mais de uma rede específica.Além disso, Apple proíbe transferências em redes para instalação de aplicativos, nempermite rodar aplicações de terceiros em segundo plano (limitações no suporte multitarefa)Oliver (2008); Morimoto (2009).

Essas características restritivas do iPhone se dão mais por razões estratégicas (modelode negócios) propriamente dito, do que limitações tecnológicas Morimoto (2009). Essarestrição, no entanto, foi quebrada graças aos membros da comunidade de desenvolve-dores do iPhone, através de uma ferramenta chamada ’Jail Breaking’. Após desbloquearessas restrições, segundo Oliver (2008), a plataforma apresentou todas as capacidades deum sistema Unix padrão. Por exemplo, muitas aplicações que usam APIs para manipularrecursos específicos do iPhone, tal como: conexões em redes diferentes (WiFi/antenas detorres de celular); recursos para pesquisar energia da bateria (status de carregamento);voltagem; instalação de aplicativos de terceiros; etc., antes bloqueados, agora funcionam

42


conforme esperado (Seção 2.4).Entretanto, conforme ressaltado em Morimoto (2009), desbloquear o iPhone acarreta

em quebra do sistema de DRM13 da Apple, podendo permitir à empresa processar osseus usuários. (DMCA14 no EUA e a lei de Cybercrimes no Brasil).

Originalmente o modelo de negócios do iPhone, em relação ao desenvolvimento deaplicativos por terceiros, foi completamente fechado. O SDK da Apple não era acessível,a não ser para um seleto grupo de parceiros ou empresas de desenvolvimento específicas.A única forma autorizada de instalação de aplicativos adicionais no iPhone é através doportal AppStore, que é controlada pela Apple.Morimoto (2009) Assim, todos os softwarespassam pela revisão da Apple e apenas os aplicativos aprovados são disponibilizadosatravés da loja. Alguns software são oferecidos gratuitamente, enquanto outros precisamser pagos para baixar. Os preços são reduzidos e a renda é dividida entre a Apple e osdesenvolvedores ou provedores de conteúdo (content providers).

Esse modelo de negócio permite à Apple ganhar muito dinheiro, pois somando arenda proveniente da venda de aplicativos, mais a renda vinda da venda de músicas eoutros conteúdos da loja iTunes15, pode-se faturar mais do que simplesmente vendertelefones celulares (iPhone) ou tocadores de MP3 (iPod). Por outro lado, diferente deoutras plataformas, a Apple decidiu não dar suporte as tecnologias Java e FlashLite, poisassim, não há como instalar aplicativos de terceiros sem passar pelo AppStore. Issoporque tanto Java como FlashLite permitem aos usuários instalar e rodar aplicativos ejogos.

“. . . o Iphone é um aparelho inovador em muitas áreas, mas que tem, por outro lado,

uma série de limitações óbvias, introduzidas pela cultura centralizadora da Apple”.Morimoto (2009) A plataforma, quando sai de fábrica, apresenta algumas limitaçõesrestritivas, que dificultam a inovação na área de desenvolvimento de aplicativos queexplorem todos os recursos esperados (Seção 2.4), além de dificultar os usuários quedesejam instalar aplicativos de terceiros sem passar pelo AppStore. Por outro lado, essemodelo é bastante promissor para manter um negócio como a Apple deseja. Partesdesse modelo estão sendo copiados por outras empresas, como veremos a seguir com aplataforma Android.

13Digital Rights Management: sistema de gerenciamento dos direitos autorais de mídias, conteúdos esoftwares.

14Digital Millennium Copyright Act é uma lei que criminaliza a produção e a distribuição de tecnologiaque permita evitar medidas de proteção dos direitos autorais Gillespie (2004)

15http://www.apple.com/br/itunes/

43

http://www.apple.com/br/itunes/


2.3.5 Plataformas baseadas em Android

Em 2005 a Google comprou uma empresa de desenvolvimento de sistemas embarcados,dando origem a especulações sobre um projeto “Google Phone”. Enquanto todos esper-avam mais um projeto de um celular smartphone, foi anunciado em 2007, que se tratavade uma SO open-source para celular, baseada no Linux Morimoto (2009).

Figura 2.9 Modelo baseado na plataforma Android (HTC G1) (fonte: Morimoto (2009))

O primeiro modelo lançado no mercado da plataforma Android é o HTC G1 (Figura 2.9),que possui um tela 480x320, que favorece a navegação web. Segundo observações deMorimoto (2009), a versão Android incluida no G1 é ainda uma versão bastante limitada,que desempenha bem as funções básicas, mas fica devendo recursos de sincronizaçãocom PC.

Essa plataforma foi batizada de nome Android e, pouco depois, o desenvolvimentofoi transferido para uma fundação chamada Open Handset Alliance (OHA). A parceriaestratégica, envolveo várias empresas do setor, como fabricantes de celular, operadoras eempresas de desenvolvimento de software.

A plataforma Android prega idéias opostas ao modelo do iPhone, isto é, não imporrestrições aos desenvolvedores, como faz a Apple, que inclusive, controla os canais dedistribuição dos aplicativos. A Google incentiva a livre distribuição e desenvolvimentode software em sua plataforma aberta, oferecendo inclusive prêmios em dinheiro16.

A estratégia do Android, segundo Morimoto (2009), é centrada no desenvolvimentode aplicativos por parte de outras empresas e desenvolvedores independentes. Essaestratégia foi adotada porque a Google e parceiros perceberam que, assim como nos PCs,

16Android Developer Challenge: http://code.google.com/android/adc/

44

http://code.google.com/android/adc/


as plataformas dos smartphones estão se consolidando e o mais importante passou a seros aplicativos, e não somente os recursos básicos do sistema e o hardware.

Tornar o desenvolvimento de aplicativos para Android menos restritivo, mais trans-parente e mais ágil tem sido a estratégia inicial, incentivando de forma agressiva ascomunidades de desenvolvimento em torno da plataforma. Para isso, as parcerias estratég-icas com operadoras e fabricantes (da OHA), são essenciais para alavancar a produçãodestes aparelhos.

Inspirados no modelo do AppStore da Apple, a Google resolveu criar o portfólioAndroid Market17, o canal de distribuição de aplicativos e conteúdos da plataformaAndroid. A diferença com relação ao AppStore da Apple, é que no Android Market osdesenvolvedores podem publicar suas aplicações diretamente, sem precisar de aprovaçãoMorimoto (2009). Nele existem conteúdos pagos e gratuitos que são ofertados, assim, damesma forma que AppStore trata a divisão dos lucros dos aplicativos que são pagos, oAndroid Market divide os custos para ambas as partes.

A tendência de longo prazo é que a oferta de aplicativos da plataforma Android sejamaior, porém, esse modelo pode acarretar em resistências das operadoras em apoiar ainiciativa, pois seus usuários poderiam usar redes WiFi para baixar aplicativos, ficando“livres” dos altos custos referente ao tráfego de dados (comercializados hoje). Por outrolado, esse modelo pode forçar mudanças de paradigmas nos modelos de negócios dasoperadoras. Embora, para algumas operadoras de celular, não se sabe ao certo, comoessas plataformas impactariam seus negócios, pois ainda hoje as principais receitas advêmdas ligações Ziv and Mulloth (2007).

Uma vantagem para fabricantes que pretendem usar Android, é que ele é livre delicenciamento, reduzindo o custo para sua operacionalização. Enquanto que para asplataformas Symbian S60 e Windows Mobile, precisa-se licenciá-los (pagando royalties).Além disso, como o sistema é open-source, existe também a possibilidade de portá-lopara outras plataformas de hardware, como por exemplo, para os PCs microportáteis. Umgrande fabricante que vem demonstrando interesse é a Intel, baseados em processadoresx86 Morimoto (2009).

Para a Google, investir na plataforma Android é uma questão de estratégia a médio elongo prazo, pois permitirá levar seus produtos e serviços como o Gmail, o Google Maps eo Google Docs, além do seu mecanismo de buscas, a uma quantidade maior de aparelhos,atingindo um público maior. Porém, esse sucesso está atrelado a disponibilidade deconexões de banda larga a custos mais acessíveis do que os praticados hoje.

17http://www.android.com/market/

45

http://www.android.com/market/


É consenso para Morimoto (2009); Oliver (2008); Canalys (2008); Cho and Jeon(2007), que a plataforma Android, pela sua característica, tende a crescer bastante nospróximos anos.

2.3.6 Plataforma Java ME

Java Micro Edition (Java ME), também conhecido como J2ME, é uma plataforma deexecução de aplicativos Java para sistemas embarcados em geral. Diferente de outrasPSC, anteriormente abordadas, Java ME não implementa um SO, mas sim, uma máquinavirtual (Java Virtual Machine - JVM), projetada para dispositivos com restrições dememória, limitações de tela e pouco poder de processamento.

Java ME pode ser considerada uma Plataforma de Desenvolvimento para as PSCs(PDC), pois provê uma plataforma comum para programar em dispositivos como: celu-lares; pages; PDAs; Set-top box18, definido por um conjunto padronizado de config-urações, perfis e bibliotecas opcionais, permitindo aos desenvolvedores escreveremaplicações para uma grande faixa de dispositivos Nokia (2008).

A PDC Java ME possui uma coleção de APIs do Java, definidas através da JCP19

(Java Community Proccess), cujo membros da indústria de celular, implementam asespecificações de cada API, definidas conjuntamente, de acordo com a sua tecnologiade hardware do dispositivo ou da sua PSC. Com isso, todos que desejam fornecerdeterminados recursos, implementem os requisitos da especificação da biblioteca deforma similar. Dessa forma, aplicações de terceiros podem ser portadas para dispositivosde diferentes fabricantes. Além disso, em teoria, também poderão funcionar em outrosaparelhos que seguem as mesmas especificações.

A Figura 2.10, apresenta a visão da arquitetura da platorma Java ME. Basicamente, deacordo com Keogh (2003); Muchow (2001), uma aplicação em Java ME funciona atravésda execução do aplicativo sobre a JVM (conhecida também como K Virtual Machine),respeitando a versão da configuração (Configuration) e o perfil (Profile), permitindoassim, acessar os recursos que o aparelho dá suporte.

De forma sintetizada, as camadas têm as seguintes responsabilidades:

• Aplicações: é o pacote da distribuição do software propriamente dito;

• OEM APIs: outras APIs que possibilitam a utilização de recursos avançados ouespecíficos para determinados clientes ou grupos;

18Set-top box: um dispositivo eletrônico que é conectado em um canal de comunicação e produz saídasobre uma tela de TV.

19http://jcp.org

46

http://jcp.org


Figura 2.10 Arquitetura geral da plataforma Java ME (fonte: Keogh (2003); Muchow (2001))

• Pacotes Opcionais: bibliotecas com recursos específicos. Na prática são aquelasimplementações provindas das especificações da JCP; Um conjunto ou pacote op-cional de bibliotecas que fornecem classes funcionais adicionais. A inclusão destespacotes no Java ME podem variar porque depende da capacidade do dispositivo;

• Perfis: fornecem bibliotecas da API de interface com o usuário, persistência emensagens, entre outros recursos;

• Configurações: a configuração define um ambiente de execução básico do sis-tema. Isto define as características das bibliotecas principais, da máquina virtual,segurança e comunicação em rede;

• Sistema Operacional do Dispositivo: interface com o SO nativo do celular.

Os pacotes opcionais são bibliotecas que são conhecidas como JSRs20, que permitemestender as funcionalidades básicas da plataforma Java ME. Alguns exemplos são: JSR-82 (Java APIs for Bluetooth Wireless Technology), para utilizar Bluetooth na aplicação;JSR-135 (Mobile Media API), que serve para tocar sons, músicas e videos com formatosdiferentes; etc.

Existem algumas variações das versões das bibliotecas de configurações e perfis, taiscomo:

• CDC (Connected Device Configuration): usada em dispositivos com maior capaci-dade computacional (ex. CDC 1.0 e 1.1.2);

• CLDC (Connected Limited Device Configuration): usada para menor capacidadecomputacional (ex. CLDC 1.0 e 2.0);

20Java Specification Request (JSR) descrição da proposta ou versão final da especificação da API de Java

47


• MIDP (Mobile Information Device Profile): define o perfil (ex. MIDP 1.0, 2.0 e2.1).

Cada variação adiciona algumas funcionalidades ou restringe outras. Por exemplo,um celular que suporta CLDC 1.1, poderia utilizar a funcionalidade de ponto flutuante(uso do tipo primitivo float), entre outras.

Uma das vantagens da CLDC Java ME, de forma geral, é que vem sendo utilizadoem larga escala em todo o mundo. Segundo Loureiro et al. (2003), a linguagem deprogramação Java tem sido mais usada para programação para celulares no mundo. Alémdisso, conforme SunMicrosystems (2009), a plataforma, inclui 2,1 bilhões de telefonescelulares e outros dispositivos portáteis e possui mais de 6 milhões de desenvolvedores.

Muitos fabricantes incorporaram essa tecnologia nos seus aparelhos por oferecerum custo/benefício relativamente baixo para implementá-lo, e assim, possibilitando odesenvolvimento de aplicativos usando uma linguagem de programação já conhecidapelos desenvolvedores. Dessa forma, a maioria dos fabricantes e, consequentemente, asprimeiras operadoras adotaram esta plataforma para a oferta de serviços de dados.

Os desenvolvedores, segundo Junquera and Gnius (2005), por sua vez, com a ajuda dosfabricantes de celulares, conseguiram ter acesso às ferramentas para criar aplicações Javapara celulares a custos muito baixos, fomentando a criação de uma ampla comunidade dedesenvolvedores. Além do mais, os desenvolvedores viram como todos os fabricantesde celular incorporavam esta tecnologia em seus dispositivos, o que lhes facilitou umacomunidade importante de possíveis clientes.

Por outro lado, um das limitações da PDC Java, segundo Junquera and Gnius (2005), éque a plataforma é utilizada principalmente em três aplicações muito concretas: ringtones,wallpapers e jogos. Um dos desafios de PDC Java ME é estender essas categorias,oferecendo aplicações de outros tipos, tais como aplicações corporativas, de produtividadee torná-las acessíveis às operadoras.

Outro desafio de Java ME é que existe uma fragmentação da plataforma, pois cadafabricante implementou uma versão da arquitetura, ligeiramente diferente e com certasferramentas particulares de seus dispositivos, o que, segundo Junquera and Gnius (2005);Tarnacha and Maitland (2006), força os serviços de valor agregado nas redes de celular(desenvolvedores) a criar a mesma aplicação segundo os requisitos do dispositivo e aversão particular de Java do telefone segundo o fabricante.

48

2.4. CARACTERÍSTICAS DESEJÁVEIS

2.4 Características Desejáveis

Um novo aparelho de celular demora vários meses para ser produzido. Durante o períodode seu desenvolvimento têm sido incrementado gradualmente o desenvolvimento de novosrecursos tecnológicos. O período de desenvolvimento de um novo celular depende dequão rápido são desenvolvidos para o mercado as suas aplicações, tal como a sua interface(User Interface - UI). Como resultado, temos uma plataforma de software que prove todoo ambiente de desenvolvimento de aplicações tornando o mercado de desenvolvimentode celulares mais forte e competitivo. Cho and Jeon (2007) As plataformas permitemacelerar o desenvolvimento de software por permitir integrar os aplicativos facilmente.

Segundo Oliver (2008), as PSC devem oferecer APIs para os desenvolvedores deaplicações de terceiros, permitindo manipular o acesso aos recursos disponíveis do celular.No entanto, observa-se que as plataformas tem diferentes tratamentos para esses recursos,limitando o uso para programadores e especialistas. Diante disso, foi proposto por Oliver(2008) e eliciado um conjunto de requisitos considerados ideais, para que as PSC possamoferecerem funcionalidades para o desenvolvimento ou alterações na própria plataforma.

Os requisitos desejáveis segundo Oliver (2008) são (nomes originais foram mantidos):

• a) Network scanning: espera-se permitir a descoberta de novas redes em torresde celular próximas, permitindo aplicações de terceiros, encontrarem celulares deoutros usuários;

• b) Interface selection: permitir que uma aplicação possa gerenciar automatica-mente a troca de redes (WiFi e Bluetooth);

• c) Bluetooth I/O: um recurso básico e essencial para troca de dados entre osdispositivos próximos (inter-devices);

• d) Interface control: espera-se poder habilitar/desabilitar através do uso de bib-liotecas, o controle de interfaces de rede (recurso que consume bastante energia dabateria);

• e) Background processing: permitir rodar aplicações em segundo plano é umacaracterística essencial para tornar o celular multi-tarefa tal como os PCs;

• f) Energy monitoring: permitir maximizar a vida útil da bateria é essencial.Espera-se mensurar o consumo da bateria do celular via API de programação;

49

2.5. COMPARAÇÕES DAS PLATAFORMAS

• g) Power saving control: permitir via API de programação, ativar/desativar econtrolar os recursos que consomem poder de processamento;

• h) Low-level memory management: permitir gerenciar os recursos de memóriaRAM utilizados a fim de otimizar o seu uso, via API de programação;

• i) Persistent storage: permitir acessar o sistema de arquivos de forma menosrestritiva;

• j) Location sensing: permitir realizar localização via API, tal como as novastécnicas de localização via triangularização de torres de celular ou GPS.

Essa listagem de requisitos proposta por Oliver (2008), foram concebidas idealmente,levando em consideração os recursos atuais das plataformas existentes, bem como suaslimitações. As características desejáveis citadas permitem principalmente aos desenvolve-dores de software de terceiros, ampliar as possibilidades de criação de software para ocelular nas diferentes tecnologias de plataformas atuais (Tabela 2.2).

2.5 Comparações das Plataformas

Nesta seção, faremos algumas comparações sobre as plataformas estudadas, em relaçãoas suas características e peculiaridades. Principalmente o seu impacto para o desenvolvi-mento de software.

A Tabela 2.3 apresenta um resumo comparativo das diferentes plataformas vistas nestecapítulo, com relação aos requisitos desejáveis propostas por Oliver (2008), apresentadasna (Seção 2.4).

Legenda: Satisfaz: :) ; Satisfaz parcialmente: :| ; Não satisfaz: :( .A plataforma Windows Mobile da Microsoft satisfaz todas os requisitos nesta com-

paração (Oliver (2008)). O seu SO provê facilidades para buscar outros dispositivos(Bluetooth), redes WiFi, estabelecer conexões com redes específicas, habilitar e desabili-tar interfaces, determinar a localização atual usando GPS, suporte de multi-tarefa (rodaraplicações em segundo plano). No uso da API do WM para manipular Bluetooth, osdispositivos não precisam estar pareados (paired). por outro lado, isso pode acarretarriscos de segurança.

Android tem um rico conjunto de APIs, mas sem suporte (ainda) para manipular osrecursos do Bluetooth. BlackBerry (plataforma não abordada neste estudo), segundo oautor da pesquisa Oliver (2008), é uma plataforma bastante robusta e fácil de desenvolver.

50


Tabela 2.3 Requisitos desejáveis das plataformas de celular (adaptado de Oliver (2008))Android Black iPhone Symbian Windows Java(Linux) Berry Mobile ME

Network scanning :) :| :) :( :) :(Interface selection :| :) :) :) :) :(Bluetooth I/O :| :) :| :) :) :)Interface control :) :) :| :| :) :(Background processing :) :) :) :) :) :(Energy monitoring :) :) :) :) :) :(Power saving control :) :) :( :) :) :|Low-memory management :) :) :) :) :) :|Persistent storage :) :) :) :) :) :)Location sensing :) :( :) :) :) :)

O iPhone possui muitas funcionalidades, porém, limitadas ao sair de fábrica. Ter quedesbloqueá-lo para usar todo o seu potencial torna mais difícil o seu desenvolvimento edepuração de aplicações.

Symbian inclui um conjunto de ferramentas de desenvolvimento (SDKs), e a suaplataforma suporta muitos outros requisitos não considerados Seção 2.4. Entretanto, aplataforma Symbian é a mais difícil de desenvolver, o que contribui por se rejeitar muitasde suas vantagens. O Windows Mobile possui um conjunto bastante rico de APIs. Porém,segundo Morimoto (2009), é um sistema pesado.

A plataforma Java ME, por não ser considerada uma PSC, não possui força secomparada com as demais plataformas apresentadas neste capítulo. Porém, alguns dosrequisitos desejáveis (Seção 2.4) são plenamente satisfeitos. Podemos observar algunspontos atingidos satisfatoriamente, tais como:

• Java ME possui bibliotecas para manipular Bluetooth (JSR 82 - Bluetooth);

• Recursos para localização (JSR-179 Location API);

• Recursos para persistência (JSR 75 - PDA File Connection)

Um fator que não foi considerado na comparação, mas que merece destaque, é que,dentro de todas as tecnologias das PSC, nenhuma favorece o quesito portabilidade entreas diferentes plataformas. Java ME oferece essa condição, com ressalvas, conformeapresentado na Seção 2.3.6. Assim, mesmo diante dos requisitos não atendidos, Java MEoferece grandes oportunidades para desenvolvedores de software ofertarem conteúdosusando essa tecnologia.

51


Java é uma tecnologia aberta, o que facilita a criação de aplicações. Isto faz com queo mercado tenha uma variedade de desenvolvedores, desde aqueles com uma oferta deprodutos e qualidade elevados, até outros com menos produtos e qualidades inferiores.

Segundo Oliver (2008), nenhuma plataforma investigada satisfaz plenamente todosos requisitos desejados. A escolha da plataforma depende sobre tudo, das necessidadesdo consumidor. Espera-se que as plataformas evoluam para atender as expectativasdos consumidores e que as novas APIs ofereçam para os desenvolvedores de software,recursos cada vez menos restritivos, incentivando a inovação e criatividade no setor.

Para um consumidor geral, cada plataforma é funcionalmente equivalente. Todossuportam recursos para fazer ligações, salvar arquivos, tirar fotos, e outras tarefas comuns.Porém, para os desenvolvedores, cada plataforma tem o seu ambiente de desenvolvimento,que suporta um conjunto de APIs e linguagens de programação diferentes.

52

“Perder o entusiasmo, provoca rugas na alma.”

Samuel Ulman 3O Desenvolvimento de Software na

Indústria de Celular

O objetivo deste capítulo é apresentar o ciclo de desenvolvimento de software paracelular e discutir as características das ferramentas de desenvolvimento consideradasneste trabalho.

3.1 Desenvolvimento de Aplicativos para Celular

De forma geral, o desenvolvimento de software é um processo de criação de programaspara quaisquer dispositivos computacionais, capaz de projetar e produzir tarefas automa-tizadas, sistematizadas ou pré-concebidas, para realização de alguma atividade por meiodo uso dos recursos de hardware e software existentes.

Segundo Pressman (1995), nos últimos 50 anos, o software evoluiu. Passou de umferramental especializado em solução de problemas e análise de informações para umproduto de indústria. Isso porque, com o surgimento da Engenharia de Software, foipossível focar na melhora da qualidade e aumento da produtividade no processo dedesenvolvimento de software.

De acordo com Brookshear (2000), o ciclo de desenvolvimento de software clássicocompreende as fases de análise, projeto, implementação e teste. Tais modelos, conformeexpõe Bourque and Dupuis (2004), servem como uma definição genérica das fases queacontecem durante o desenvolvimento de software. Estes modelos são utilizados paradescrever as atividades e as formas como elas se relacionam, fornecendo uma visão geraldo projeto a equipe de desenvolvimento, porém esses modelos não apresentam definiçõesdetalhadas.

Segundo Fernandes (2007) apud Sami (1998), a indústria de software tem progredido

53

3.1. DESENVOLVIMENTO DE APLICATIVOS PARA CELULAR

através de uma série de ondas e tendências. A primeira onda foi caracterizada pelomodelo de ciclo de vida representado pelo modelo cascata e pelos métodos estruturados.A segunda onda é o movimento de maturidade do processo, ou seja, abrange todos osaspectos do processo de desenvolvimento de software e atividades de suporte. A terceiraonda, segundo Fernandes (2007) apud Bergey et al. (1998), impulsionada pelo amadurec-imento do paradigma da orientação a objetos, trás a evolução do desenvolvimento desoftware para linhas de produção.

Figura 3.1 Camadas da Engenharia de Software (Pressman (1995)).

Conforme Pressman (1995), a Engenharia de Software (ES) é uma tecnologia emcamadas (Figura 3.1). E a base de todas essas camadas é o foco na qualidade do softwaredesenvolvido. Assim sendo, é interessante estudarmos a ES em suas camadas de Processo,Métodos e Ferramentas.

Este trabalho aborda a problemática com ênfase na camada de Ferramentas, razãopela qual, o desenvolvimento de software para celular é fortemente impactado.

O processo de desenvolvimento de sofware para celular, portanto, tende a ser bastanteinfluenciado pelas escolhas das tecnologias utilizadas, desde a Plataforma de Softwarede Celular (PSC) e dos seus dispositivos-alvos, conforme abordado no capítulo anterior(Seção 2.5), bem como, de ferramentas de desenvolvimento utilizando tecnologias dasPlataformas de Desenvolvimento de Celular (PDC).

Essencialmente, uma PDC é uma solução tecnológica para garantir compatibilidadespara implementações de software nas PSC (ex. Java ME, Seção 2.3.6). Embora, demaneira geral, portar aplicativos para outras PSC é um processo custoso Tarnacha andMaitland (2006); Kurkovsky (2009); Loureiro et al. (2003).

Neste trabalho, adotamos as seguintes nomenclaturas para diferenciar as tecnologiasde celular, ilustradas pela Tabela 3.1 a seguir:

A combinação de pelos menos uma de cada tecnologia citada são necessárias paradesenvolver aplicativos em celulares . No entanto, as PDCs não devem ser confundidascom as IDEs (Integrated Development Environments), e os SDK (Software Development

54


Tabela 3.1 Tecnologias de Desenvolvimento de Software para CelularSigla Tecnologia ExemplosIDE Ambiente de Eclipse, NetBeans,

Desenvolvimento Integrado Visual Studio.NET, Motodev StudioSDK Kit de Desenvolvimento Sun Wireless Toolkit,

de Software (emuladores) Openwave, S60 SDKPSC Plataforma de Software Symbian, Android, Windows Mobile

de Celular iPhone, Linux, BREWPDC Plataforma de Java ME,

Desenvolvimento de Software Flash Lite

Kits), popularmente conhecidos como emuladores de celular.O desenvolvimento de aplicativos para as PSC podem ser divididos de três diferentes

formas, segundo Morimoto (2009):

• aplicações nativas: aplicações voltadas exclusivamente para a PSC;

• aplicações intermediárias: voltada para PDC;

• aplicaçoes Web (widgets): rodam dentro dos navegadores web dos dispositivos.

Os aplicativos nativos, são tecnicamente mais complexos de desenvolver, e sãodependentes da tecnologia da PSC. Por exemplo, aplicações nativas de Symbian devemusar a linguagem Symbian C++, e o seu conjunto de bibliotecas disponíveis. Em geral, avantagem é que todos os recursos do celular podem ser utilizados sem quaisquer restrições.Porém, a principal desvantagem recai sobre a curva de aprendizado das PSC específicas,bem como, a dificuldade de portabilidade futura.

As aplicações intermediários são voltados para as PDC, propondo melhorar a portabil-idade e compatibilidade das aplicações desenvolvidas nas diferentes PSC. Por outro lado,existem dificuldades para acessar todos os recursos do dispositivo, uma vez que cadafabricante oferece uma implementação de suporte para a PDC, sensivelmente diferentesou específicas para um conjunto de hardware de seu portfólio. Isso acaba por restringir aspossibilidades que um aplicativo poderia explorar, diante das aplicações nativas. O maiorbenefício deve-se à boa curva de aprendizado por parte dos desenvolvedores.

De acordo com Morimoto (2009), as limitações dos navegadores e o tamanho dastelas fazem com que a maior parte dos aplicativos intermediários fiquem inutilizáveis. Ouseja, alguns tipos de aplicações como Gmail continuam acessíveis, enquanto que serviçoscomo Google Talk, não.

55


Já os software que rodam dentro de navegadores (web), são conhecidos como widgets,e podem incluir serviços como Gmail, Meebo1, entre outras, e são voltados para as PSC.Alguns exemplos bastante utilizados são widgets para iPhone e Opera Widgets2.

Os widgets são, em geral, aplicativos simples, que exibem algumas informaçõesespecíficas. Alguns widgets, embora rodem dentro do navegador, substituem as funçõese até mesmo, a aparência de aplicativos nativos, mas não permitem ir muito longe emtermos de programação. A principal vantagem é a portabilidade, pois basta o celularter um navegador compatível. Porém, será necessário conexão com a internet, pois oswidgets são projetados para interações com serviços na web. De forma geral, para tarefasmais complexas, a melhor opção, segundo Morimoto (2009), é desenvolver um aplicativonativo.

O desenvolvimento de serviços e aplicações para celular, de acordo com Loureiro et al.

(2003), são baseados em arquiteturas específicas, usando componentes não-reutilizáveis.Em razão disso, faz-se necessário considerar a PSC, o celular-alvo e, ferramentas de desen-volvimento específicas. Além disso, conforme Tarnacha and Maitland (2006); Kurkovsky(2009), por conta da grande variedade de dispositivos, há uma grande diversidade deplataformas e, consequentemente, diferentes ferramentas de desenvolvimento.

O desenvolvimento de uma aplicação para celular, segundo Tarnacha and Maitland(2006); Karvonen and Warsta (2004), possui algumas dependências e representa inúmerosdesafios para os desenvolvedores. As dependências técnicas existentes são a principalfonte dos problemas, e estão presentes na cadeia de valor de uma aplicação de celular.Ou seja, tipicamente uma aplicação de celular é restrita para uma combinação específicade PSC, o dispositivo de celular, além da rede da operadora. A Figura 3.2 ilustra asdependências no desenvolvimento de aplicativos e conteúdos, de acordo com Tarnachaand Maitland (2006).

Primeiramente, temos várias PDC que são suportadas por diferentes fabricantes dedispositivos e operadoras de celulares. Por exemplo, BREW3 é suportado pela operadoraVerizon Wireless (EUA) e, nos vários pontos de venda, são comercializadas por diferentestefelones celulares com BREW habilitado. Não obstante, em segundo lugar, devido aorápido avanços tecnológicos nas funcionalidades dos aparelhos, versões adicionais dePDC são criadas para inúmeras versões, sendo usadas por diferentes celulares.

Para contornar esse problema, segundo Tarnacha and Maitland (2006), os desen-

1Meebo: um aplicativo para mensagens instantâneas, suportando múltiplos clientes como: Yahoo!Messenger, GTalk, MSN. . .

2http://widgets.opera.com/3Binary Runtime Environment for Wireless: uma PSC para dispositivos CDMA da Qualcomm.

56

http://widgets.opera.com/

3.2. CICLO DE DESENVOLVIMENTO

Figura 3.2 Dependências do desenvolvimento de aplicações e conteúdos para celular

volvedores usam uma versão base das PDC, permitindo assim, acessar diferentes redesde comunicação, dispositivos específicos de uma PSC, utilizando as APIs para desen-volver suas aplicações. Entretanto, criaram assim, muitas dependências que as PDCse propuseram a reduzir. O fabricante de celular Nokia, por exemplo, ao perceberessa dependência, disponibilizou ferramentas integradas de desenvolvimento, inclusive,definindo a padronização de suas ferramentas para celulares (baseados na Nokia Series60), como linha principal de investimentos.

Diante do exposto, pecebe-se que existem pelo menos três maneiras diferentes paradesenvolver aplicativos no celular (veja a Tabela 3.1): (1) via desenvolvimento de códigosnativos da PSC; (2) usando aplicações intermediárias através das PDC; e ainda, (3)utilizando widgets para rodar pequenas aplicações dentro do navegador do celular. Alémdisso, a escolha das tecnologias de PSC, os dispositivos-alvos e a infra-estrutura de rededa operadora, influenciam positiva ou negativamente no desenvolvimento do software. Aseguir, apresentamos o ciclo de desenvolvimento de software para celular.

3.2 Ciclo de Desenvolvimento

Conforme abordado na Seção 3.1, a ênfase deste trabalho é sobre as ferramentas e os seusimpactos no desenvolvimento de software para celular. O ciclo de desenvolvimento desoftware aqui discutidos, em geral, se aplicam no contexto de utilização de ferramentasdas PDC sobre as PSC.

De forma geral, o processo do ciclo de desenvolvimento de software passa pelasseguintes fases: (a) codifição e construção; (b) teste; (c) assinatura; e (d) distribuição. AFigura 3.3 ilustra o processo como um todo.

De acordo com Cho and Jeon (2007), o desenvolvedor precisa instalar uma IDEapropriada para possibilitar desenvolver os aplicativos, considerando um determinado

57

3.2. CICLO DE DESENVOLVIMENTO

Figura 3.3 Ciclo geral de desenvolvimento de aplicações para celulares

dispositivo pretendido. Em seguida, o programador codifica o código da solução usandobibliotecas da PDC (ex, Java ME), no caso de desenvolvimento para aplicações inter-mediárias, ou usando APIs da PSC (ex. aplicativos Symbian), para desenvolvimento deaplicações nativas. Então constrói (builder) o aplicativo (passo a), podendo iniciar oprocesso de teste em seguida (b).

Porém, o processo pode ser percorrido de forma iterativa e incremental, conformeexplicado por Abrahamsson et al. (2002), onde a saída de um incremento é especialmentepara revisão dos objetivos das iterações sucessivas, ou seja, a saída de uma iteração éexaminada para modificação. Neste caso, os passos fundamentais do processo estão eminiciar o desenvolvimento com um subconjunto simples de Requisitos de Software eiterativamente alcançar evoluções subseqüentes das versões até o sistema todo estar imple-mentado. A cada iteração, as modificações de projeto são feitas e novas funcionalidadessão adicionadas.

Após percorrer os passos básicos ( a e b), espera-se distribuir o aplicativo para osusuários finais. No entanto, conforme Junquera and Gnius (2005); Symbian (2008),havia uma preocupação com aspectos ligados à pirataria. Não só para impedir quedesenvolvedores vissem sua propriedade roubada por terceiros, mas também para impedirque os usuários finais compartilhassem aplicações compradas das operadoras e dosdesenvolvedores.

Neste sentido, segundo Nokia (2008); Junquera and Gnius (2005); Symbian (2008),por razões de segurança dos dispositivos e de suas aplicações distribuídas, um mecanismopara permitir que as operadoras e usuários adquirissem aplicações certificadas e aprovadasfoi desenvolvido. Esse mecanismo, portanto, representa um passo adicional no processode desenvolvimento (passo c), conhecido como processo de assinatura (assigned). NaPDC para Java ME, o processo foi chamado de programa de certificação de aplicações

58

3.3. DESAFIOS PARA APLICAÇÕES E FERRAMENTAS

Java (Java Verified), desenvolvido pela Sun Microsystems. Já na PSC da Nokia, porexemplo, foi batizada de Symbian Signed.

Conforme Symbian (2008), ambos os procedimentos de assinaturas são esquemaspara permitir criar e gerenciar uma assinatura digital para a aplicação. Assim, pode-se garantir todas as compatibilidades necessárias para o software executar conformeesperado. No caso do esquema de assinaturas da PSC da Symbian, há suporte tanto paraJava Verified como Symbian Signed, pois os recursos da plataforma dão suporte tambémpara a PDC Java. Já a PDC Java ME, não suporta o esquema do Symbian.

O ciclo de assinatura da aplicação (passo c), de acordo com Symbian (2008), poroutro lado, não é um procedimento obrigatório, pois uma aplicação poderia ser instaladano celular sem essa assinatura digital (também conhecida como certificação), e funcionarda mesma forma. Entretanto, não há garantias do fabricante que tal aplicação funcionaria,deixando a responsabilidade para o próprio usuário assumir os riscos. Não obstante,conforme Junquera and Gnius (2005); Symbian (2008), muitas operadoras exigem essacertificação para ofertarem aplicações compatíveis dos diferentes terminais de celularesque são comercializados pelas operadoras na sua base de clientes.

Por fim, temos o passo de distribuir a aplicação para utilização (passo d). Nesteponto, o desenvolvedor tem diferentes possibilidades para distribuição. Em geral, asaplicações são comercializadas com as operadoras ou nos recentes portfólios dos fabri-cantes como OVI4 (Nokia), AppStore (Apple), Android Market (Open Handset Allience),bem como, diretamente para usuários finais, em portfólios de terceiros ou dos própriosdesenvolvedores.

A seguir, apresentam-se alguns requisitos desejáveis para aplicações de celulares esuas ferramentas emuladores das PDC, bem como, algumas ferramentas estudas.

3.3 Desafios para aplicações e ferramentas

Existem vários desafios que devem ser considerados para projetar aplicações no desen-volvimento de software para celular. Alguns deles já foram discutidos no início destecapítulo (vide Figura 3.2), porém, faz-se necessário também, considerar as implicaçõesdos desafios quanto as definições de requisitos desejáveis para atender a problemáticado desenvolvimento de software no contexto do celular. A seguir apresenta-se resumida-mente os desafios, bem como, alguns requisitos desejáveis.

A Figura 3.4, ilustra os principais desafios a serem vencidos conforme pesquisas

4https://store.ovi.com/

59

https://store.ovi.com/


de Loureiro et al. (2003), que são: (1) tipos e formas de uso; (2) diferentes celulares;(3) aplicação do serviço ou aplicação; (4) estratégia de mobilidade; (5) usabilidade; (6)segurança; e (7) conhecimentos técnicos.

Figura 3.4 Desafios a serem superados no contexto do desenvolvimento para celular

Quanto aos tipos de celulares e formas de uso (vide Figura 3.4, [1 e 2]), pode-mos percebê-los conforme classificação dos seus diferentes tipos (vide Capítulo 2,Definição 2.1), e também, pelas suas formas de uso. As formas convencionais de uso docelular são as mais diversas, em vários ambientes, desde locais comuns até em locaisnão habitáveis, tais como a utilização em residências ou no trabalho, no deserto ou emalguma situação de emergência. Um ponto negativo, pode-se usá-lo em momentos nãorecomendados, tal como durante algum deslocamento dirigindo um automóvel ou meiode transporte, aumentando o risco de acidentes. As formas de utilização são inúmeras, enão se restringem mais apenas com propósito para se comunicar. Ao longo do capítuloanterior (vide Capítulo 2, Figura 2.1), apresentamos alguns de seus recursos bem comoformas de uso.

Quanto as aplicações e serviços de celular (vide Figura 3.4, [3]), podemos considerarque nem todas os softwares são desenvolvidos e consequentemente, são apropriados paraambientes de celular. Assim, devemos avaliar sua adequação seguindo alguns pontos:

• Analisar o fluxo de dados e requisitos de conectividade da aplicação específica;

• Identificar os requisitos do modelo de uso da aplicação (conexão intermitente oupermanente);

• Avaliar o tipo de infra-estrutura de comunicação sem fio necessária, ou disponível

60


para a aplicação (LAN, telefonia 2,5G, 3G e seus impactos na largura da banda,área de abrangência, atraso);

• Definir a região de cobertura que a aplicação deve estar disponível;

• Identificar requisitos de segurança que aplicação deve ter (autenticação e crip-tografia);

• Estimar o custo de desenvolvimento e manutenção da aplicação;

• Identificar características dos celulares necessários à execução da aplicação;

• Identificar o segmento de mercado da aplicação ou serviço (mercado de consumo).

No âmbito geral, quanto a estratégia de mobilidade (vide Figura 3.4, [4]), de acordocom pesquisas de Economou et al. (2008); Loureiro et al. (2003); Karvonen and Warsta(2004), para desenvolver aplicações para celulares, deve-se considerar um conjunto derequisitos, que precisam ser considerados nos processos de negócios, a fim de desenvolveruma estratégia de mobilidade para uma empresa.

Assim, pode-se avaliar os vários processos dentro do negócio e identificar aquelesque podem ser implantados com o paradigma da computação móvel. De acordo comLoureiro et al. (2003), os principais pontos que devem ser considerados são:

• A forma como as informações, documentos, mensagens, etc. são trocadas entre osfuncionários (papél, meio eletrônico);

• Qual é o processo para passar essas informações?

• Que/Onde/Como/Quando informação / aplicação é importante para os diferentestipos de funcionários da empresa?

• Que novos processos devem ser criados com uma estratégia móvel?

Assim, quando uma nova tecnologia com diferentes capacidades e requisitos é uti-lizada, tal como as PSC e as PDC, os processos devem ser revistos considerando essatecnologia. Se a tecnologia é simplesmente aplicada sem nenhuma consideração, oresultado final poderá ser ineficiente.

Num processo específico de negócio, segundo Loureiro et al. (2003), alguns critériosdevem ser definidos para avaliar a utilização das aplicações no cenário da computaçãomóvel, tais como:

61


1) A tecnologia irá fornecer novas capacidades/funcionalidades e o quanto elas valem?Ou seja, a tecnologia irá permitir fazer atividades que não são possíveis sem ela?Existem outros retornos indiretos em se ter essas funcionalidades?

2) A tecnologia irá melhorar a produtividade? Ou seja, o que será melhorado com amesma quantidade de recursos? Os ganhos previstos são maiores que os custos comtreinamento, gerenciamento e uso do sistema? Como a curva de aprendizagem datecnologia irá afetar a produtividade?

3) A tecnologia irá melhorar a eficiência? Ou os novos passos introduzidos no processodo negócio irão diminuir a eficiência como um todo?

4) A tecnologia irá melhorar a qualidade? Os erros irão diminuir ou aumentar devidoàs opções limitadas de entrada de dados dos celulares? Os resultados do processo donegócio serão melhores?

5) O uso da tecnologia irá afetar os custos? Quais os novos custos que serão criados?Mesmo se a tecnologia provê um aumento na receita, o seu uso deve ser consideradoem função dos custos atuais.

Estas questões permitem orientar empresas e desenvolvedores de terceiros nos projetosde aplicações para celular, bem como, vislumbrar a melhor maneira de adequar osprocessos de negócio da empresa ao contexto que as tecnologias dos celulares estãoinseridas.

Em relação ao aspecto de Usabilidade (vide Figura 3.4, [5]), primeiramente a pre-missa principal é que os celulares são completamente diferentes dos PCs (desktops). Aexperiência de usuário no celular é bastante limitada, se comparada aos recursos dos PCs,que por muitos anos já têm telas e resoluções maiores, uso de mouse e teclados acessíveisàs mãos. Os recursos computacionais dos celulares são limitados. Por outro lado, novasinterfaces com recursos como touchscreen e uso de sensores de acelerômetros (comoiPhone), já estão permitindo uma melhor experiência dos usuários no uso das interfacesdos celulares. As principais estratégias de usabilidades devem considerar:

• Esquema de interação (modelo navegacional e fluxo de informação);

• Mapa de serviço (diagramas mostrando a estrutura e interações dos diferentesserviços envolvidos);

• Guias de estilo (guiar os projetistas, regras de navegação, controles, mensagens deerros, atalhos. . . );

62

3.4. REQUISITOS DESEJÁVEIS PARA FERRAMENTAS DE DESENVOLVIMENTOMÓVEIS

• Interface do usuário (considerar interações com teclas e sensíveis ao toques).

O desafio de Segurança (vide Figura 3.4, [6]), deve garantir acesso à informaçãoem qualquer lugar e qualquer momento, considerando que, cada vez mais, aplicaçõescorporativas usarão o celular no dia a dia, para realizar transações bancários e param-commerce Heikkinen and Still (2008).

O último aspecto, mas não o último desafio da computação móvel, tem relação comos desafios técnicos (vide Figura 3.4, [7]). Por se tratar de uma área com múltiplas apli-cabilidades, em diferentes áreas de atuação, temos uma visão horizontal de conhecimento.Neste sentido, os conhecimentos que frequentementes são usados são:

• Tecnologias das PDCs, como Java ME (vide Seção 2.3.6), BREW, FlashLite, entreoutras;

• Protocolos de comunicações (tal como WAP, HTTP);

• Processos de desenvolvimento de software (vide Seção 3.2), considerando ascaracterísticas dos ambientes do celular-alvo e princípios de usabilidade;

• Tecnologias das PSCs, como as descritas no capítulo anterior (Seção 2.2)

3.4 Requisitos desejáveis para ferramentas de desenvolvi-mento móveis

Segundo Kurkovsky (2009); Loureiro et al. (2003); Economou et al. (2008), as tecnologiasdas PDC, devem atender alguns requisitos, tais como:1) Extensibilidade: a ferramenta deve ser extensível, possibilitando que novas inter-

faces, novas aplicações e novos dispositivos sejam incorporados facilmente, sem anecessidade de reescrever códigos;

2) Portabilidade: capacidade de implementar aplicações independente do celular-alvo;3) Inserção de código: permitir extensões de códigos próprios ou de terceiros (plugins

instaláveis ou similares; APIs externas);4) Interface aberta (XML, Java): reuso de componentes padronizados, especificações

abertas e bem definidas, bem como, linguagens e paradigmas de programação con-hecidos;

5) Sincronização de aplicações: a ferramenta deve prover facilidades e mecanismos desincronização (online), bem como, a geração de stubs (para aplicações offlines);

63

3.4. REQUISITOS DESEJÁVEIS PARA FERRAMENTAS DE DESENVOLVIMENTOMÓVEIS

6) Suporte a protocolos: oferecer ferramentas ou APIs para manipular dados por meiode protocolos de comunicação (TCP/IP, WAP...);

7) Importação de dados: incorporar às ferramentas a possibilidade de incorporar oacesso a novas fontes de dados (como banco de dados ou padrões via XML);

8) Depuração: verificação e depuração da aplicação passo-a-passo nas ferramentasdas PDC, permitindo a inclusão de pontos de verificação (checkpoints) ou parada(breakpoints), são essenciais;

9) Internacionalização: permitir recursos de internacionalização (em vários idiomas)sem muito esforço;

10) Curva de aprendizado aceitável: as ferramentas não devem exigir um conheci-mento muito avançado para permitir a sua utilização;

11) Rápida Codificação e Construção: as ferramentas devem permitir a codificação econstrução de forma rápida (desenvolvimento rápido implica em mínimo esforço ecusto de implementação);

12) Ferramentas para projetos com GUIs: permitindo utilizar ferramentas GUI5, tantopara desenvolvedores como para designers, permitindo um nível de personalizaçãoe expressividade maior, facilitando a criação de conteúdos interativos, com recursosmultimídias de acordo com o perfil do usuário (tal concepção poderia exceder asexpectativas do cliente e otimizar o conteúdo de entrega);

13) Suporte para diferentes celulares: idealmente, suportar a simulação de dispositivosde fabricantes diferentes (PSC diferentes);

14) Suporte restrição poder computacional: capacidade de simular as restriçoes depoder computacional do celular-alvo em tempo de execução (através de APIs);Além dos requisitos técnicos voltados para as ferramentas das PDC, temos outros

fatores, apontados por Economou et al. (2008), que implicam no desenvolvimento eestão relacionados com às ferramentas, tais como, as habilidades de programação dodesenvolvedor. As habilidades reduzem o esforço de desenvolvimento e os conhecimentostécnicos necessários para realizar o projeto.

Dada a variedade de configurações e celulares existentes, deseja-se que a plataformapossa se adaptar facilmente de modo a permitir estender-se aos vários tipos de ambiente.Assim, dos requisitos listados, a capacidade de estensibilidade da PDC é um dos principaisrequisitos.

5Graphical User Interface: uma interface de usuário baseado em gráficos e não textuais

64

3.5. FERRAMENTAS DE DESENVOLVIMENTO DE SOFTWARE

3.5 Ferramentas de Desenvolvimento de Software

Nesta seção, apresentamos as principais ferramentas das PDCs investigadas neste trabalhoe suas principais características.

Desenvolvedores podem testar sua aplicação através de emuladores (SDKs), quesão aplicações que simulam o aplicativo dentro de um ambiente próximo ao dispositivodo celular-alvo. Normalmente, segundo Cho and Jeon (2007); Morimoto (2009), osemuladores não substituem o ambiente das funcionalidades do celular real (restrições dememória, processamento e recursos), mas desempenham bem, por outro lado, objetivosde teste do software, percorridos nos computadores pessoais. Além disso, pode reduzirbastante o tempo de desenvolvimento da aplicação, pois elimina a necessidade de possuirfisicamente o equipamento de celular.

Entretanto, a experiência prática nos ensina que testes precisam ser percorridos nosdiferentes celulares reais que pretendemos distribuir o software, visando a garantia totaldas suas funcionalidades. Porém, conforme já discutido na Seção 3.1, portar aplicativospara outras PSC é um processo custoso.

Há uma grande demanda por ferramentas capazes de facilitar o desenvolvimento desoftware para os diversos celulares e que possam atender às várias formas de aplicações.Conforme Loureiro et al. (2003), essa característica é extremamente desejável paraprovedores de conteúdo e desenvolvedores de novos serviços para celulares.

Além disso, espera-se que tais ferramentas, atendam os requisitos desajáveis, aborda-dos na Seção 3.4, permitindo aos desenvolvedores de aplicações de celular, enfrentaremtodos os desafios vistos (Seção 3.3), bem como, melhorar a produtividade de software,minimizando os custos envolvidos e a dificuldade do seu desenvolvimento.

As ferramentas escolhidas neste trabalho, têm em comum, o fato de permitir osuporte da tecnologia Java ME, bem como, funcionarem como emuladores de software.Os emuladores visam, entre outras, permitir a execução do aplicativo de celular emquestão, reproduzindo o seu comportamento, como se estivesse rodando em um ambientede celular-alvo próximo do real. As aplicações são executadas sobre um conjuntode funcionalidades e ferramentas de desenvolvimento, reunidas pelo SDK da PDC,em conjunto com os ambientes de desenvolvimento (IDE), fornecido por fabricantesconsiderados, bem como, as empresas do setor.

As PDCs investigadas são: SDK da Nokia; SDK da Sun; e o SDK da Motorola. Aseguir, apresentamos cada ferramenta, respectivamente.

65


3.5.1 SDK da Nokia

A ferramenta da Nokia é chamada de S60 3rd Edition SDK for Symbian OS Support-

ing Feature Pack 1, for MIDP (S60 SDK). Uma das mais completas ferramentas paradesenvolvimento Java ME e aplicações Symbian disponíveis.

Com o S60 SDK o desenvolvedor pode implementar aplicações Java ME para aplataforma de smartphones S60 utilizando o PC. Juntamente com a IDE, o SDK fornecetodas as funcionalidades necessárias para isso, inclusive APIs, exemplos de códigos e todaa documentação necessária para o desenvolvimento de novas aplicações S60 MIDlets6,isto é, as aplicações que estão em conformidade com o perfil MIDP (vide Seção 2.3.6).

A Figura 3.5, apresenta a interface principal do emulador S60 da Nokia. O emuladorS60 permite visualizar e testar aplicações no PC antes de instalar no celular real. Uma dasgrandes vantagens dessa ferramenta, em comparação com outras do mesmo propósito, éque a simulação do aplicativo é muito próximo das funcionalidades do celular real, sendoo seu grande diferencial.

Figura 3.5 Interface de usuário SDK S60

Uma série de exemplos de MIDlets são fornecidos junto com o SDK. Os MIDletsdemonstram a variedade de aplicações que podem ser executados nos celulares da S60. Odesenvolvedor pode criar e executar os MIDlets no emulador S60, bem como utilizá-losna criação de suas próprias aplicações. No entanto, essas aplicações ficam escondidas

6MIDlet: é o nome dado para as aplicações de Java ME

66


por assim dizer. O desenvolvedor precisa ler a documentação técnica para encontrar taisdemos.

O emulador S60 SDK tem sido testado sobre o SO Microsoft Windows 2000 (SP4)e Microsoft Windows XP (SP2). Esses sistemas são oficialmente recomendados pelofabricante Nokia, outros sistemas, como Windows Vista, podem funcionar mas não sãogarantidos.

A interface de comunicação suportada pelo emulador para interação com outrasaplicações incluem: (1) suporte da especificação Universal Emulator Interface (UEI),permitindo rodar aplicativos diretamente da IDE; suporte para OTA7, muito utilizadopara simular a instalações de aplicativos via sites externos.

As principais APIs suportadas pela S60 SDK de Java ME são apresentadas noApêndice A. Os recursos identificados por letras de (a até o) são suportadas por essatecnologia.

3.5.2 SDK da SUN

A Sun Java Wireless Tool Kit (conhecido como J2ME WTK), é um conjunto de ferramen-tas para criar aplicações Java que rodam sobre dispositivos genéricos, de acordo com asespecificações da indústria da (Java Technology for the Wireless Industry - JTWI, JSR

185) e da (Mobile Service Architecture (MSA, JSR 248). Essa ferramenta, basicamnte éum conjunto de pequenos utilitários e dispositivos para simulação.

Figura 3.6 Interface de usuário da Sun Java Wireless Tool Kit 3.0

O foco desta ferramenta é a simulação, construção e a geração de código (deployment).Usando a sua interface de usuário (Figura 3.6), relativamente simples, pode-se criar,

7Over The Air: refere-se qualquer tecnologia de comunicação via rede

67


compilar e gerar o pacotes de distribuição, além disso, pode-se também, simular umaaplicação com assinatura digital, executar e depurar aplicações em tempo real.

A PDC Java ME da Sun é uma ferramenta bastante popular no meio dos desenvolve-dores Economou et al. (2008); Cho and Jeon (2007), pois ela serve como referência paraaprendizado da tecnologia Java ME. O SDK provê suporte de ferramentas e exemplos deimplementações para as últimas APIs suportadas conforme a lista da JCP.

O SDK suporta integração com o dispositivo real sobre Windows Mobile ou emu-ladores de terceiros. O desenvolvedor pode usar o SDK para gerar aplicações e distribuirnos telefones reais, além dos recursos de depuração.

O SDK contém vários exemplos demos, assim como a SDK da Nokia. A listacompleta de APIs suportadas deste SDK encontra-se no Apêndice A.

3.5.3 SDK da Motorola

O SDK da Motorola, chamado de MOTODEV Studio for Java ME, é um conjuntode ferramentas para desenvolvimento, baseado na IDE Eclipse 3.4 (conhecido como’Ganymede’) Motorola (2009), projetado para aplicações em Java ME.

Essa ferramenta unifica a IDE e o SDK da PDC dos produtos da PSC da Motorola.Com isso, o desenvolvedor pode implementar, testar e gerar aplicações para um grandeleque de dispositivos da Motorola, integrados numa única ferramenta de desenvolvimento,que incluem as seguintes plataformas:- Produtos SO Motorola: voltados para PSC proprietária P2K (ex. MOTO Z9/Z9n,

MOTORAZR V3, W510) ;- Produtos SO Linux : voltados para PSC baseado em Linux (ex. A910/A910i, MO-

TOMING A1200/e/i/r, ROKR EM35);- Produtos Motorola Symbian (UIQ): voltados para PSC baseado em Symbian UIQ

da Motorola (ex. MOTO Z8 e MOTO Z10);- Produtos SO Windows: voltados para PSC baseados em WM (ex. MOTO Q 11,

MOTO Q 9h Family);- Dispositivos Embarcados (Embedded Devices): voltados para sistemas embarcados

(ex. EM330/MOTOROKR EM28, G24-J HMI).Além disso, o ambiente oferece um conjunto de ferramentas, serviços e documen-

tações integrados para o desenvolvedor simular as aplicações. Entre as principais fun-cionalidades podemos destacar:- Demo Tool: permite visualizar informações e screenshots dos demo MIDlets disponíveis,

bem como, importa-los diretamente para dentro da IDE como um projeto Java ME;

68


- Network Monitor: permite monitorar e analisar os pacotes de dados de vários proto-colos de comunicação;

- Suporte MTJ8: com editor de configuração usando UI;- Deployment Too: permite enviar e instalar aplicações nos celulares reais;- On-Device Debugging: permite realizar depuração diretamente no celular real (platafor-

mas Motorola OS e Linux);- Multiplataforma: versões para Windows, Mac OS X, e Linux;- Java ME Emulator: utiliza a JVM SE para simular aplicações Java ME no PC,

utilizando skins para cada celular;- Bluetooth Service: habilita simular a comunicação Bluetooth com múltiplos celulares;- WMA Test Server: permite múltiplos celulares simularem o envio e recebimento de

mensagens (SMS e MMS);- Signing Tool: permite importar certificados e assinar aplicações MIDlets;- Config Tool: provê funcionalidades para habilitar/desabilitar recursos de telefones

reais (ex. habilitar depuração).

Figura 3.7 MOTODEV Studio rodando uma aplicação demo

A Figura 3.7 apresenta o ambiente Motodev em execução. O ambiente MOTODEVcontém vários exemplos demos (distribuídos via DemoTool). A lista completa de APIssuportadas deste ambiente encontra-se no Apêndice A. Os recursos identificados por letras

8Mobile Tools for Java (MTJ): um plugin com especificação aberta que permite integrar o SDK coma IDE, executar e testar aplicações MIDlets

69

3.6. COMPARATIVO ENTRE OS SDKS

de (a até o) são suportadas por essa tecnologia, no entanto, existem diferentes variações.A Motorola contém uma documentação interna chamada Device Matrix, contendo todasas compatibilidades.

3.6 Comparativo entre os SDKs

Nesta seção, faremos algumas comparações sobre as ferramdas das PDC estudadas, comrelação às suas características. A Tabela 3.2 apresenta um resumo comparativo das trêsferramentas vistas neste capítulo (SDK S60, WTK e Motodev Studio), com relação aosrequisitos desejáveis propostas e apresentadas na (Seção 3.4).

Legenda: Satisfaz: :); Satisfaz parcialmente: :|; Não satisfaz: :(.

Tabela 3.2 Requisitos desejáveis das Ferramentas de Desenvolvimento de Celular (adaptada deKurkovsky (2009); Loureiro et al. (2003); Economou et al. (2008))

Requisitos desejáveis SDK S60 SDK WTK SDK Motodev1) Extensibilidade :| :) :(2) Portabilidade :) :| :|3) Inserção de código :) :) :)4) Interface aberta :) :) :)5) Sincronização :| :) :|6) Suporte a protocolos: :) :) :)7) Importação de dados :| :) :(8) Depuração :) :) :)9) Internacionalização :| :) :)10)Curva de aprendizado :| :) :)11) Rápida Codificação e Construção :| :) :)12) Ferramentas GUIs p/ projetos :( :) :)13) Suporte diferentes celulares :) :| :)14) Suporte restrição poder comput. :) :) :|

Do requisito 1 (estensibilidade), pode-se dizer que o WTK é a melhor opção para odesenvolvedor, por não possuir celulares reais, e portanto, não haver preocupações decompatibilidades. O Motodev da Motorola, que possui cinco tipos de PSCs diferentes,tem vários riscos de ter problemas para considerar estensibilidade. O S60 se mantémna posição neutra (satisfaz parcialmente), pois também possui problemas de compatibil-idades com seus celulares. Porém, as suas APIs e seu emulador são mais estáveis porreproduzirem fielmente o comportamento da aplicação.

Percebe-se uma similaridade comum entre os requisitos 3, 4, 6, 8 e 13, entre todas as

70


ferramentas. Embora esse último (suporte diferentes celulares) não se deva considerar oWTK, já que o mesmo não possui celulares reais.

Os pontos negativos ficaram nos requisitos 1 e 7, do Motodev Studio, pois no caso daMotorola, existem muitos dispositivos com muitas PSC, e isso dificulta a estensibilidade,além de sua tecnologia ser bastante voltada para recursos básicos. Da mesma forma, orequisito 12 prejudica a PSC do S60, pois não há muitas ferramentas ao não ser o próprioemulador.

Figura 3.8 Resultado da Comparação dos SDKs segundo requisitos desejáveis

A Figura 3.8 ilustra o resultado da comparação das ferramentas estudas e seus req-uisitos desejáveis. A ferramenta WTK obteve a melhor porcentagem para o critériosatisfaz.

Sem dúvida, de forma geral, atende bem o papel de proporcionar aos desenvolvedoresquase todos os recursos esperados por uma ferramenta voltada para as PDC Java. Poroutro lado, o fato de não haver celulares reais fazem com que o WTK seja sugeridoapenas para testes da aplicação, enquanto estiver em fase de desenvolvimento. Fasesseguintes sugere-se testar na PDC do celular-alvo.

Observa-se ainda, que a ferramenta S60 SDK demonstra ser a mais estável, comrelação a soma dos critérios Satisfaz e Satisfaz Parcialmente.

No caso dos emuladores (SDKs) investigados para as PDCs, mostram-se bastante úteis.Permitem que testes sejam executados localmente, ainda no ambiente de desenvolvimento,além de serem capazes de oferecer recursos extras (difíceis de reproduzir nos dispositivosreais) que facilitam a depuração.

A plataforma WTK, segue a risca as especificações de Java e provê o melhor suporte

71


das APIs disponíveis para o desenvolvedor. Por outro lado, tem suporte apenas a PSC doWindows Mobile. Logo, as execuções no seu emulador não garantirão portabilidade paraoutras plataformas. O WTK tem propósito geral para realizar testes de simulação usandoseu emulador. Neste sentido, a ferramenta atinge bem os objetos. Por outro lado, nãoreproduz o comportamento com exatidão de celulares-reais.

O emulador S60 possui excelente documentação técnica, e reproduz muito bem asaplicações MIDlets, tal como se fosse ao celular real. Porém, os requisitos computacionaismínimos para rodar a ferramenta no PC, são bem elevados, exigindo uma máquina comum bom processador para execução do emulador.

A integração com a IDE da ferramenta da Motorola é excelente, pois a mesma já vemde fábrica com todas as ferramentas integradas. Além disso, possui versões para váriossistemas operacionais, enquanto o WTK e S60 SDK, somente para Windows, apesar deter versões de Linux para o WTK (versão antiga).

Por fim, um critério não considerado, mas importante, são a quantidade de exemplosdisponíveis (os demos) e a forma como eles são ilustrados para o desenvolvedor.

O WTK possui 28 demos e permite que o desenvolvedor (através da página inicial,vide Figura 3.6), escolha o demo, clicando no link. O programa demo então é aberto o oemulador executa o mesmo imediatamente.

No S60 SDK são 21 demos, porém, o desenvolvedor só sabe que eles existem seler a documentação técnica pelo help do sistema. Ou acessar pelo filesystem a suaslocalizações. Não há integração com IDE automática sem instalar plugins acidentais.

No Motodev Studio, existe a ferramenta DemoTool, que permite o desenvolvedorlistar os demos e importar o mesmo para um projeto da IDE. No total são 23 demos.

Em avaliação de PDC similar, segundo Economou et al. (2008), a escolha da tecnolo-gia adequada depende de fatores relacionados aos conhecimentos técnicos dos desen-volvedores, dos requisitos da aplicação, do celular-alvo, bem como, do cronograma eorçamento do projeto.

O capítulo seguinte apresenta a ferramenta DemoTool, concebida com base nasanálises e comparações das características apresentadas (vide Tabela 3.2) e integrada noSDK Motodev Studio for Java ME, da fabricante Motorola, Inc..

72

“O segredo da felicidade não é fazer sempre o que se quer,mas querer sempre o que se faz.”

Leon Tolstoi 4DemoTool

Este capítulo apresenta a ferramenta DemoTool. Inicialmente são apresentados os requi-sitos que devem ser atendidos pela ferramenta, seguido pelas fases de análise, projeto,implementação e implantação. Depois, apresenta-se o desenvolvimento de um demo paraentretenimento e aprendizado de notas musicais, intitulado Mobile Piano Learning. Elefoi construído com base no DemoTool, mostrando a maneira de como usar cada recursoproduzido pela proposta, servindo como um estudo de caso.

4.1 Introdução

Existem hoje muitas aplicações de celulares disponíveis com diferentes propósitos econtextos de uso (vide Apêndice E). As diferentes formas de utilização podem sercomplementadas através do desenvolvimento de aplicativos que permitam, cada vez mais,expandir os usos e capacidade dos dispositivos, tornando ainda mais acessível a utilizaçãoda computação para a sociedade.

Devido ao aumento crescente do tamanho e da complexidade dos sistemas computa-cionais, das problemáticas e desafios desta área (vide Seção 3.3), cada vez mais há anecessidade por parte dos desenvolvedores de aplicações móveis, utilizar ferramentas dedesenvolvimento para minimizar o esforço de implementação, o custo e a complexidade.O uso de ferramentas, como emuladores, tende a trazer grandes benefícios como, porexemplo, testar os aplicativos dos celulares, sem no entanto, ter que possuir o celular-alvoda aplicação durante o processo de desenvolvimento.

Não obstante, a oferta de dados para celulares, tais como as que se apresentam nosdias atuais (vide Seção 1.2.2), faz com que haja demandas por aplicativos e conteúdosmóveis. Neste sentido, as Plataformas de Software de Celular (PSC) têm grande im-portância estratégica para empresas que desejam prover conteúdos, bem como, para os

73

4.1. INTRODUÇÃO

desenvolvedores de terceiros, pois são através dessas tecnologias que muitos serviços econteúdos são construídos e ofertados para usuários de celular.

De maneira geral, os desenvolvedores de software e empresas do ramo, desejam quesuas aplicações cheguem ao maior número possível de usuários de celular, no entanto,devido as diferentes tecnologias de celular existentes (vide Capítulo 2), essa meta torna-secada vez mais custosa, pois requer portar o software em ambientes incompatíveis entre si.Entretanto, o uso das ferramentas das Plataformas de Desenvolvimento de Software deCelular (PDC) contribuem para minimizar as dificuldades (vide Capítulo 3).

A proposta desse trabalho se fundamenta no novo tipo de modelo de inovação noecossistema de negócios para celular (vide Capítulo 1.2), observada por Ziv (2005); Zivand Mulloth (2007), considerando as relações dos usuários com as principais entidadesenvolvidas no ecossistema da indústria de celular: os fabricantes de celular (Seção 1.2.4),as operadoras de celular (Seção 1.2.3) e os provedores de conteúdo (Seção 1.2.5).

Neste sentido, uma das questões abordadas aqui visa investigar a relação das ferra-mentas de desenvolvimento (fornecidas por fabricantes de celular) e sua utilização nocontexto da computação móvel, no qual acredita-se que os desenvolvedores utilizam asPDCs de maneira natural e de forma intuitiva, pois é inerente às práticas de conhecimentodesses profissionais o manuseio de tais tecnologias. No entanto, os programadores inici-ais, ou aqueles que iniciam práticas de programação, tem maior chance de encontraremdificuldades para produzir soluções, bem como, para resolver problemas da computaçãomóvel através da utilização das PDC.

Figura 4.1 Modelo de inovação no ecossistema considerando o desenvolvedor (adptado de Zivand Mulloth (2007)

74

4.2. DESENVOLVIMENTO DO DEMOTOOL

A Figura 4.1 ilustra o modelo de inovação que se apresenta no ecossistema da indústriade celular (vide Seção 1.2.5) considerando o desenvolvedor de software, com ênfase nassuas interações nos setores impactados. Desta maneira, o desenvolvedor pode interagirde forma menos restritiva com outras entidades relacionadas na indústria.

Por exemplo, o desenvolvedor pode ofertar um aplicativo ou serviço de dados paraalguns usuários e realizar transações de dados sem requerer, necessariamente, autorizaçãodas operadoras dos clientes ou fabricante de celular dos usuários que estão usando oserviço interessado. Usuários podem então, instalar aplicações utilizando a rede dasoperadoras como uma ponte, no intuito de acessar a Internet, e assim, instalar diferentesaplicativos ou consumir diversos dados de provedores de conteúdo distintos. Da mesmamaneira, a fabricante Motorola pode disponibilizar vários aplicativos para a comunidadede desenvolvedores, incentivando o desenvolvimento de aplicativos para usuários deseus celulares. Através deste cenário, pode-se aproximar o usuário desenvolvedor com afabricante de celular utilizando essa ferramenta.

Investiga-se ainda, qual a importância dos fabricantes de celular para os desenvolve-dores de software, ao mesmo tempo em que, os desenvolvedores requerem as tecnologias(PSC, PDC, SDKs) para ofertar aplicativos diante deste paradigma. A construção daparceria das diferentes entidades envolvidas no ecossistema da indústria, junto com osdesenvolvedores de software é de fundamental relevância para corroborarem entre si.

Assim, procuramos investigar o processo de desenvolvimento de aplicações paracelular, como ilustrado na Figura 4.1, acompanhando o uso do ferramental necessárioe suas ferramentas de apoio. Foi proposto, desenvolvido e distribuído mundialmente,através do SDK da Motorola - Motodev Studio for Java (vide Seção 3.5.3), o DemoTool,uma ferramenta que visa auxiliar a descoberta de aplicativos, permitindo integração doambiente IDE com a PDC do fabricante.

O restante deste capítulo mostra o desenvolvimento da ferramenta DemoTool para ocenário acima descrito e do desenvolvimento do jogo Mobile Piano Learning, construídoa partir do uso dessa ferramenta, servindo como um estudo de caso.

4.2 Desenvolvimento do DemoTool

O nome DemoTool1 vem da característica que a ferramenta foi concebida, e no qual sepropõe, ou seja, permitir a integração de demos2 no ambiente de desenvolvimento.

1DemoTool pode ser executado instalando o ambiente Motodev Studio for Java http://developer.motorola.com/docstools/motodevstudio/javame/

2demos: pequenos aplicativos elaborados de forma didática para desenvolvedores de software

75

http://developer.motorola.com/docstools/motodevstudio/javame/



O DemoTool é um sistema para reuso de aplicações demos cujo objetivo é minimizaro esforço necessário para assimilar o processo de desenvolvimento de software paracelular. Além disso, esse sistema possibilita a descoberta de aplicativos demonstrativos(na forma de demos), apresentando suas funcionalidades e recursos, bem como, permitira integração do demo com o ambiente de desenvolvimento SDK do fabricante Motorola(Motodev Studio for Java ME - Seção 3.5.3).

A utilização deste sistema possibilita a redução do tempo necessário para a assimilaçãodo processo de desenvolvimento da PSC da Motorola, diminuindo a curva de aprendizadopara familiarização do processo de desenvolvimento de software para celular. Isso ocorreporque o DemoTool permite reusar o conhecimento contido nos exemplos de aplicativosdemonstrativos.

Os aplicativos demonstrativos foram cuidadosamente elaborados, com propósitosdidáticos e com os seus respectivos códigos fontes, permitindo ao desenvolvedor estudarcomo os recursos foram implementados utilizando as diferentes bibliotecas (APIs), bemcomo, os vários contextos e cenários no qual se propõe.

Figura 4.2 Visão geral da ferramenta DemoTool

A Figura 4.2 apresenta a interface principal do DemoTool com as suas principaisfuncionalidades, que são listadas a seguir:

• Listagem dos demos (A): os demos são visualizados no lado esquerdo da interface.

76


Cada demo é representado por um ícone personalizado, ilustrando o possívelcontexto de uso. Quando o usuário clicar sobre o ícone, as informações sãovisualizadas na tela principal (B);

• Informações do demo (B): está tela permite visualizar as informações relevantesdo demo selecionado, tais como: a versão, o tamanho do aplicativo, o distribuidor,a versão da configuração (CLDC) e do perfil (MIDP), bem como, as APIs queforam utilizadas neste demo. Além disso, uma breve descrição contextualiza o quea aplicação demo faz;

• Visualização de screenshots (C): esse recurso abre uma janela que permite avisualização das telas (screenshots) do demo selecionado, permitindo uma visãoprévia da sua interface gráfica de usuário (GUI). Somente é acessado da telaprincipal (B);

• Importação do demo (D): permite importar o demo para a IDE Motodev Studiofor Java, adicionando os seus arquivos para um projeto no ambiente de desenvolvi-mento. Este recurso somente está disponível sobre o demo selecionado;

• Filtragem por funcionalidades (E): limita a visualização da listagem dos demos(A), permitindo usar um critério de filtragem por API ou por funcionalidades. Paraver todos os demos que usam a JSR-135, por exemplo, deve-se selecionar o filtropor este critério e a listagem (A) será atualizada exibindo somente os demos queusam a biblioteca escolhida;

• Importação de vários demos (F): localizado no canto direito superior da tela, essafuncionalidade exibe uma janela com a listagem de todos os demos disponíveis,permitindo que o usuário selecione quais demos o usuário deseja importar.

A Figura 4.3 mostra o DemoTool integrado no ambiente Motodev Studio for Java,executando um aplicativo demo recentemente importado para o projeto da IDE MotodevStudio for Java e rodando o emulador para executar o demo.

4.2.1 Contexto de Implementação

A implementação desta ferramenta se insere no contexto da participação de um projetoOffshore3, patrocinada pela Motorola, Inc., e executado pela fábrica de software do Centro

3Offshore: designa os serviços prestados para clientes fora de suas fronteiras nacionais Fernandes(2007).

77


Figura 4.3 DemoTool integrado no Motodev Studio/J executando o demo no emulador

de Estudos e Sistemas Avançados do Recife (C.E.S.A.R), bem como, das atividades deengenharia de software exercidas nesta empresa.

O C.E.S.A.R é um instituto privado de inovação, classificado como uma associaçãocivil sem fins lucrativos, cujo suas principais frentes de atuação são a execução de projetosde inovação, pesquisa e desenvolvimento, bem como, a incubação de empresas. Com sedeem Pernambuco e outras unidades de negócio nos outros Estados do Brasil, desenvolvesistemas para clientes da iniciativa privada nacional e internacional e para organizaçõespúblicas CESAR (2009).

4.2.2 Escopo

A ferramenta DemoTool foi projetada para mostrar aplicações (MIDlets) dentro doproduto Motodev Studio for Java, permitindo download de aplicativos do portal dos de-senvolvedores da Motorola4 e possibilitando uma maneira para o desenvolvedor submetersuas aplicações para o site do portfólio do fabricante. A solução é composta por doismódulos independentes:

• (1) DemoTool client: Essa aplicação provê as funcionalidades para visualizar as

4http://developer.motorola.com

78

http://developer.motorola.com


informações das aplicações demos (MIDlet), filtrando por diferentes categorias eimportando o demo para dentro da IDE;

• (2) DemoTool server: Este módulo gerencia um repositório de demos e permitemostrar na Web e para o DemoTool client, todos os demos disponíveis. Permite aodesenvolvedor realizar downloads e uploads de aplicativos para compartilhar coma comunidade.

Embora o escopo desta aplicação contemple dois módulos, por decisão da Motorola,somente o DemoTool client (1) foi desenvolvido no quarto trimestre de 2008, sendo queo DemoTool server (2), ficou contemplado nos planos futuros da empresa (roadmap).

Neste trabalho portanto, consideramos a implementação do DemoTool client, con-hecido como DemoTool. A seguir apresentamos as principais fases da engenharia desoftware percorridos para o desenvolvimento desta aplicação.

4.2.3 Fase de Requisitos

A função primordial do DemoTool é possibilitar o reuso de demos permitindo a integraçãocom a ferramenta de desenvolvimento de software, bem como, a facilidade da descobertados diferentes aplicativos de propósito didático. Para obter isso, os requisitos principaisdo DemoTool foram construidos com base nos objetivos da proposta deste trabalho (verSeção 1.4.1). Os requitos funcionais (RF) do software DemoTool, bem como, os seusrequisito não funcionais (RNF), podem ser vistos no (vide Apêndice F).

Para realizar a produção de requisitos, algumas técnicas foram empregadas taiscomo um estudo de viabilidade, prototipação e workshops de requisitos Kotonya andSommerville (1998); Pressman (1995).

O estudo de viabilidade foi percorrido a partir das ferramentas relacionadas (Seção 3.5),bem como, uma análise considerando as questões abordadas do item de Estratégia deMobilidade (Capítulo 3, Seção 3.3).

O uso de prototipagem foi percorrido nesta fase do processo, onde uma versão inicialdo sistema, baseada em requisitos ainda pouco definidos, foi rapidamente implementadapara validar as idéias. Com o protótipo parcialmente desenvolvido, pode-se validaraspectos técnicos envolvidos, bem como, discutir as suas funcionalidades, através darealização do Workshop de Requisitos.

A técnica de workshop de requisitos consiste na tentativa de obter um conjunto derequisitos bem definidos, no qual é percorrido através de uma reunião com as parteschaves envolvidas no negócio.

79


Por fim, um documento de especificação de requisitos (Client Software Requirements

Specification) foi elaborado ao final da fase de requisitos e enviado para o cliente (Mo-torola), solicitando sua aprovação, bem como feedbacks. De acordo com Kotonya andSommerville (1998), o propósito serve para confirmar a completude dos requisitos epropor alterações nos requisitos produzidos.

4.2.4 Fase de Análise

O sistema foi projetado usando notação UML (Unified Modeling Language), recomen-dadas por Pressman and Ince (2005) para especificação de produtos de sistemas computa-cionais e atualmente é um padrão da indústria de software.

Foram utilizados nas fases de análise e projeto do DemoTool, as técnicas do paradigmada orientação a objetos, utilizando a UML para descrever e documentar os modelos.Assim, inicialmente foram produzidos na fase de análise os artefatos de casos de uso(Use-Cases) e de projeto, usando o diagrama de classes.

Na fase de análise como um todo, o sistema foi concebido de acordo com as necessi-dades documentadas nos requisitos (vide Seção 4.2.3).

A Figura 4.4 apresenta os casos de uso desenvolvidos do sistema. A descrição doscasos de uso permite que a equipe de testes do projeto realize e produza planos de teste,bem como, permite visualizar as principais ações do usuário no sistema. Segundo Boochet al. (2005), podemos considerar que um Caso de Uso é um “. . . documento narrativo

que descreve a sequência de eventos de um ator que usa um sistema para completar

um processo". O Diagrama de Caso de Uso descreve a funcionalidade proposta para oDemoTool.

O projeto pode ser definido como: “. . . o processo de se aplicar várias técnicas e

princípios ao propósito de se definir um dispositivo, um processo ou um sistema com

detalhes suficientes para permitir sua realização.” (Pressman (1995) apud Taylor (1959),pg. 415), sendo o primeiro passo para a fase de desenvolvimento do DemoTool.

Inicialmente foi projetado um modelo que abstrai o sistema como um todo, permitindoo entendimento e a comunicação entre as entidades envolvidas na aplicação do DemoTool.Optou-se por projetar o sistema de forma que favorecesse a comunicação (modelo maissimplificado), em contrapartida da complexidade dos detalhes técnicos (melhor precisão).Assim, optou-se por definir um modelo de diagrama de classe simplificado, de alto nível,para deixar documentado a solução proposta, bem como, para permitir o entendimentodos engenheiros da equipe (futuras consultas).

Como especificado pelos requisitos na Seção 4.2.3, o DemoTool tem como carac-

80


Figura 4.4 Casos de Uso do DemoTool (fonte: Product Requirements for DemoTool)

terística ser uma ferramenta para reuso de demos e direcionado para o sistema MotodevStudio/J, como explicitado por [RF-3 e RNF-2]. Assim, um dos desafios técnicos consis-tiu em projetar um mecanismo que possa descobrir os aplicativos e exibi-los, de formaamigável para o usuário. A Figura 4.5, apresenta o diagrama de classes do modeloprojetado para resolver esse problema.

Foram definidos um conjunto de classes que foram agrupadas em três visões decomponentes. Cada visão tem as seguintes responsabilidades:

• Extension point: este grupo de classes define um ponto de extensão, responsáveispor fornecer um conjunto de regras para aplicações externas se integrarem com oDemoTool;

• Base: este grupo define as regras de negócio que tratam da descoberta das apli-cações demos. O mecanismo de prover e integrar as aplicações no Motodev Studiosão definidas aqui. Além disso, um mecanismo de leitura de XML e dos arquivos

81


Figura 4.5 Diagrama de Classes do modelo da Arquitetura

JAD (MIDlets), foram projetadas nesta visão;

• GUI: essa visão representa todos os recursos de interface de usuário, o tratamentode eventos e demais funcionalidades normalmente utilizada por “Views” do Eclipse.

Esse esquema se assemelha com arquitetura em camadas. No entanto, o sistemanão foi concebido desta maneira, pois foi baseado na plataforma eclipse, no qual requerutilizar plugins para definição de seus componentes, bem como, a utilização de pontos deextensão.

4.2.5 Fase de Projeto

O ambiente Motodev Studio for Java é baseado no Eclipse (3.4), que trabalha sobre umaplataforma conveniente para estender e utilizar as suas funcionalidades e recursos, atravésda abordagem de programação de plugins.

Um plugin para a plataforma Eclipse, pode prover vários recursos, não somente deprogramação, mas permitir acessar quaisquer recursos do ambiente. Pode-se acessar emanipular documentos, usar diferentes recursos já existentes, alterar menus, esconder ehabilitar funcionalidades extras, etc. Neste sentido, a IDE Eclipse foi personalizada paraintegrar as diferentes ferramentas da Motorola.

82


Segundo Gallardo (2002), a chave para permitir a integração transparente de ferramen-tas com o Eclipse se dá através do uso de plug-in. Um plug-in desenvolvido integra-seao Eclipse em exatamente da mesma maneira que outros plug-ins da plataforma, con-sequentemente, todos os recursos são criados de forma igual. Além disso, um plug-inrequer um ponto de extensão ao qual, deve-se conectar para que funcione.

Figura 4.6 O modelo de suporte de plugins do Eclipse (adptado de Gallardo (2002))

A Figura 4.6 ilustra como o DemoTool pode ser incluído na plataforma Eclipse. Ocomponente Workspace contém pontos de extensão que permitem interagir com recursos,incluindo projetos e arquivos. Além disso, permitem que o DemoTool, na forma deplug-in estenda a interface com o usuário do Eclipse com seleções de menu e botões dabarra de ferramentas, para solicitar notificação de diferentes tipos de eventos e para criarnovas visualizações.

Para contemplar o requisito [RNF-2] (Apêndice F), a arquitetura da ferramenta foiconcebida para usar uma abordagem que evita acoplamento entre os componentes, ouseja, modularizar o sistema de forma que ele funcione com o mínimo de dependênciasentre as visões listados no diagrama de classes (vide Figura 4.5). A plataforma Eclipsefornece os pontos de extensão para isso. Uma maneira de integrar diferentes plugins emnossa aplicação sem a necessidade de mudanças na infra-estrutura básica.

A Figura 4.7 apresenta o diagrama de componentes do sistema da aplicação, ilustrandoo uso do ponto de extensão (extension point). Desta forma, temos a definição de pontode extensão (chamado demos.finder), que define as regras básicas que qualquer demoprecisa ter e implementar se quiser se integrar no DemoTool.

Em termos práticos, a funcionalidade se dá da seguinte maneira:

• Quando a aplicação DemoTool for executada o plugin demos.finder irá prover oseu ponto de extensão;

83


Figura 4.7 Diagrama de Componentes do modelo da arquitetura

• O plugin local demo tool irá implementar as funcionalidades do ponto de extensão(carregando todas as instâncias dos demos), mantendo-se registrado neste serviço(ou plugado);

• O plugin da interface gráfica demotool vai requerer todos os plugins registradosno ponto de extensão dos demos e recuperar uma lista de objetos do tipo “Demo”;

• Dessa forma, pode-se ter outros componentes (plugins de terceiros por exemplo)registrados no sistema, que o DemoTool poderá exibi-los da mesma maneira.

4.2.6 Fase de Implementação e Teste

Seguindo o que foi definido na especificação da ferramenta pelas fases de requisitos(Seção 4.2.3), análise e projeto (Seção 4.2.4 e Seção 4.2.5), a implementação do De-moTool se deu utilizando as mesmas características de desenvolvimento presentes noambiente Motodev Studio for Java, pois o DemoTool está integrado ao seu ambiente,funcionando como uma ferramenta adicional.

As tecnologias que se seguem foram utilizadas para desenvolver o DemoTool:

• Linguagem de Programação: O DemoTool foi desenvolvido utilizando a lin-

84


guagem de programação Java5 (Java SE 1.5). A escolha dessa linguagem deve-se aexpertise dos desenvolvedores, bem como dos requisitos do MotoDev Studio, querequer rodar o sistema em três versões de SO (Windows, Linux e Mac OS);

• Framework Eclipse: o Eclipse6 é uma IDE desenvolvida pela IBM que possuivários recursos extensíveis, sendo utilizado para unificar todas as ferramentas SDKsda Motorola, para a sua PDC de Java;

• Motodev Studio for Java: é a PDC da Motorola. É uma extensão da plataformaEclipse integrada com o Mobile Tools for Java (MTJ)7, bem como, diversas ferra-mentas para desenvolvimento;

• Motorola’s Java ME Emulator: ferramenta que permite emular aplicativos decelular no PC, permitindo desenvolvedores de terceiros criarem aplicações em JavaME;

A fase de testes foi percorrida de duas formas: testes de caixa branca, usando técnicasde testes de unidade (Unit Test), realizado pelo próprio desenvolvedor; e testes formaisde caixa preta. Foram realizados ainda, testes formais de integração, bem como, testes desistema, todos executados pela equipe de testes do projeto (Seção 4.2.1).

De forma geral, segundo Pressman (1995), os testes de unidade é a fase em que setestam as menores unidades de software desenvolvidas (pequenas partes ou unidades dosistema), propícia ao desenvolvedor. Os testes de integração, objetiva-se encontrar falhasprovenientes da integração interna dos componentes de um sistema; e por fim, os testessistemas visam executar o software considerando todas as funcionalidades (considerandotodos os requisitos) em busca de falhas, sob ponto de vista de seu usuário final.

4.2.7 Fase de Implantação

O aplicativo desenvolvido foi incorporado ao produto Motodev Studio for Java após acorreção dos bugs encontrados nos testes realizados, bem como, a data do fechamento daversão de entrega (release) ter sida alcançada.

A Figura 4.8 apresenta o site http://developer.motorola.com/docstools/motodevstudio/javame/, no qual o desenvolvedor pode requisitar o download do

5http://java.sun.com/6http://www.eclipse.org7http://www.eclipse.org/dsdp/mtj/

85



http://java.sun.com/

http://www.eclipse.org

http://www.eclipse.org/dsdp/mtj/

4.3. ESTUDO DE CASO: MOBILE PIANO LEARNING

Figura 4.8 Portal Motodev Studio/J da Motorola, Inc. com destaque para DemoTool

ambiente Motodev Studio for Java (requer cadastro gratuíto pelo site). Obsevamos que aferramenta produzida obteve destaque do site do fabricante.

O DemoTool foi aceito na homologação do cliente e incorporado no Motodev Studiofor Java (release da versão 2.2), oficialmente publicado e disponibilizado no seu portal(20/April/2009), sendo distribuído de duas formas pelo fabricante Motorola:

• Via Update Site: essa forma permite que os usuários com versões anterioresrealizem apenas uma atualização via ferramenta de atualização (update manager)(40 MB);

• Via Instalação do Sistema: a versão binária do instalador do sistema MotodevStudio for Java (114 MB).

4.3 Estudo de Caso: Mobile Piano Learning

Esta seção apresenta um estudo de caso sobre o desenvolvimento do game intituladoMobile Piano Learning, seguindo o processo de desenvolvimento de celular, abordado no

86


Capítulo 3 (Seção 3.2). Desta forma, as fases de codificar e construir, testar e distribuirsão realizadas para a elaboração do aplicativo.

4.3.1 Introdução

A realização do estudo de caso aplicado em nosso contexto permite um meio de avaliar asproblemáticas em termos práticos. Segundo Yin (1994), os estudos de casos se constituemna estratégia preferida quando o “como"e/ou o “por que"são as perguntas centrais, tendoo investigador um pequeno controle sobre os eventos, e quando o enfoque está em umfenômeno contemporâneo dentro de algum contexto de vida real.

Em nosso contexto de pesquisa, o fenômeno se refere ao desenvolvimento de softwarede celular (Capítulo 3), no contexto da atual oferta de dados na indústria de celular(Capítulo 1.2, Seção 1.2.2).

Optou-se por realizar esse estudo de caso como forma de aprofundar a percepçãodo processo do desenvolvimento de software para celular, bem como, das demais ev-idências investigadas do Capítulo 1.2. Procurou-se vivenciar a problemática abordada(principalmente do Capítulo 3), permitindo enriquecer a experiência desta pesquisa.

O método de coleta de dados foi baseado na observação participante, ou seja, o“. . . método em que o observador participa da vida diária das pessoas em estudo, tanto

abertamente no papel de pesquisador, como assumindo papéis disfarçados, observando

fatos que acontecem, escutando o que é dito e questionando as pessoas ao longo de um

período de tempo."Yin (1994). Esse método permite envolvimento do pesquisador, esendo assim, pode-se cobrir situações a medida que os fatos vão acontecendo.

Segundo Yin (1994), entre as vantagens (V) e desvantagens (D) de usar esse método,podemos destacar as que mais se aproximam da nossa pesquisa:

• Realidade (V1) : observa eventos do mundo real à medida em que acontecem;

• Contextual (V2): cobre o contexto do evento;

• Motivação (V3): Boa visão das motivações e comportamentos interpessoais;

• Percepção (V4): Percepção da realidade do ponto de vista interno ao ambiente emestudo - retrato mais fiel.;

• Custo (D1): consome muito tempo;

• Seletividade (D2): cobertura limitada;

• Falhas/desvios (D3): provocados por manipulação de eventos feita pelo pesquisador.

87


4.3.2 Apresentação do Problema Estudado

No contexto do cenário presente, sabe-se que o desenvolvedor conhece algumas dasnecessidades de seus usuários, principalmente, por também ser um usuário de celu-lar (a maioria8). Porém, como os desenvolvedores utilizam as ferramentas e quais asdificuldades encontradas são algumas das questões observadas neste estudo de caso.

O objetivo deste estudo de caso, portanto, é investigar a questão (Q7), apresentado naintrodução desta dissertação (Seção 1.1):

Como os desenvolvedores de software se inserem no contexto do desenvolvimentode software para celular e quais são suas dificuldades?

Para isso, podemos proceder assumindo o papel de um desenvolvedor de softwarede celular (de terceiros), e buscar criar e distribuir a sua aplicação. É neste cenário queapresentamos o processo vivenciado na prática, tentando desenvolver uma aplicaçãomóvel que possa se inserir no contexto da indústria de celular, conforme abordado emcapítulos anteriores. Não obstante, é oportuno avaliar também a ferramenta DemoTool,de forma a testar se os objetivos serão atingidos, ou seja, serão validados. Assim, ostestes estratégicos (T) considerados para este estudo de caso são:

T1. Utilizar o DemoTool para reusar aplicativos demos permite simplificar a compreen-são do desenvolvimento de software para celular.

T2. A escolha e reuso de um aplicativo demo bem projetado permite simplificar oprocesso de Análise e Projeto do aplicativo a ser implementado.

Podemos considerar que os demos incorporados pelo DemoTool foram bem pro-jetados, pois fazem parte de um projeto antigo da Motorola (disponível no site desde2005 - vide Figura 4.8), cujo objetivo era desenvolver aplicativos demonstrativos paradesenvolvedores iniciantes, e assim, foram cuidadosamente elaborados com propósitosdidáticos (ajudar o desenvolvedor no entendimento dos aplicativos). Cada demo passoupor um processo próprio de desenvolvimento e foi cuidadosamente documentado paratorna-se o mais didático possível para desenvolvedores de terceiros.

Neste estudo, também consideram-se perspectivas alternativas, ou seja, os testesestratégicos contrários (TC), dos quais podemos destacar:

TC1. Utilizar o DemoTool para reusar aplicativos demos não facilita a compreensão enem possibilita ganhos no desenvolvimento.

8deduzido a partir dos números crescentes de usuários com celulares no Brasil (com mais de 159milhões ANATEL (2009)) e mundiais (2,7 bilhões UNCTAD (2007))

88


TC2. A escolha e reuso de um aplicativo demo bem projetado dificulta o processo deAnálise e Projeto do aplicativo a ser implementado, tornando-o mais complexo.

Para realizar análises posteriores, destacamos os Pontos de Melhoria (PM), assimcomo os Pontos de Evidência (PEv) no decorrer do estudo de caso. Além disso, estestestes estratégicos serão percorridos e avaliados, e então classificados como plausíveisou implausíveis.

4.3.3 Criando uma Aplicação para Celular

Este estudo de caso está dividido em duas fases: a Fase 1 compreende o uso do DemoToolcomo ferramenta de descoberta de aplicativos; e a Fase 2 busca experimentar a criação desoftware de celular em ambiente real e cotidiano.

4.3.3.1 Fase 1: uso do DemoTool

Inicialmente, procurou-se refletir que tipo de aplicação seria interessante desenvolver,e como posteriormente poderia distribuir o aplicativo no mercado de celular (PEv-01).Considerando as aplicações mais baixadas do portal iTunes do AppStore (vide Tabela 1.2),podemos observar que dos 10 mais baixadas, 5 são da categoria de games. Assim ficouresolvido que o aplicativo eleito deveria ser também um jogo.

Considerando o ciclo de desenvolvimento de software para celular (vide Seção 3.2),devemos percorrer inicialmente pelas fases de codificação e construção. No entanto,surge a necessidade de planejar o game que se pretende implementar antes de iniciar oprocesso de codificação (PEv-02, PM-01).

Através do DemoTool, pode-se observar que existem aplicações demos, e que estes,podem ser testados para avaliar o seu uso. Entretanto, usando o Motodev Studio for Java,no qual o DemoTool foi incorporado, em nenhum momento essa informação é transmitidapara o desenvolvedor, não permitindo assimilar que tal ferramenta estáacessível (PM-02).Essa percepção foi evidenciada no contexto de utilização dos primeiros cenários de uso(PM-03). Em consequência, faz com que o desenvolvedor tenha que descobrir por contaprópria (PEv-03).

Quando a ferramenta do DemoTool foi executada pela primeira vez, observou-se quea posição inicial da tela (também conhecido no Eclipse como View) encontra-se na áreainferior da janela principal da IDE. Essa perspectiva ilustra e destaca bem a sua aparição.Entretanto, quase não se percebe que existe uma lista de demos no canto esquerdo daview do DemoTool (PM-04). Ao clicar sobre um demo (por exemplo AcronymSearch

89


MIDlet Suite), não se pode notar todas as informações da tela conforme a (Figura 4.2)(PM-05). Esse cenário, impossibilita a leitura das informações descritivas dos exemplosde aplicativos de quaisquer demos subsequentes, e por mais que se clique nos outrosdemos existentes, não se pode perceber que tais informações estavam escondidas (PM-06).Redimensionando o tamanho da área da View do DemoTool, pode-se então, perceber queexistem vários demos, e que eles possuem várias descrições.

Diante da necessidade de desenvolver o jogo, procurou-se na listagem existente, quetipo de aplicações demos havia no sistema. Observou-se que existem 23 demos, sendoque 5 podem ser considerados exemplos de jogos. Porém, para descobrir essa informaçãofoi necessário abrir e executar todos os demos para somente então, enquadrá-los nestacategoria, de acordo com a expertise do desenvolvedor (PM-07).

Durante o processo de procura nos demos existentes, observou-se o recurso descreenshots, que permite ver uma prévia do aplicativo, sem a necessidade de ter queimportar o demo. Todos os demos têm telas (de screenshots), porém, todos iniciamexibindo a tela de “launch", que é a tela inicial que o emulador exibe durante a simulaçãodo aplicativo (PM-08). Constatou-se que as telas de screenshots mais interessantesaparecem como última opção de escolha, o que acaba por escondê-las dos usuários(PM-09).

Ao percorrer a listagem dos demos, foi utilizado o botão central de rolagem do mouse(a fim de obter a rolagem da tela), para tentar descer e subir nas opções disponíveis. Masaconteceu a mudança na opção de “Filter By", e não no lugar esperado (lista de demos)(PM-10). O recurso de filtragem então foi descoberto (PM-11).

Após utilizar o recurso de “Filter By”, sentiu-se falta de nomes mais apropriados.Ao invés de “jsr-75”, poderia usar os nomes das API (neste caso “File Connection API(jsr-75)”) (PM-12).

De todos os demos consultados o MobilePiano MIDlet Suite foi escolhido por suacaracterística de um game de entretenimento, com uso de som e imagem, tal como umjogo utiliza. O recurso de importar o demo específico foi utilizado. Neste momento, aoclicar no botão “import”, observou-se que a barra de progresso não aparece (PM-13),deixando o desenvolvedor confuso por determinado tempo. Mas em seguida, o demo foiimportado corretamente para dentro da IDE.

A partir desse ponto, podemos encerrar a Fase 1 deste estudo. Foram encontrados13 Pontos de Melhoria e 3 Pontos de Evidência. Os pontos observados são analisadosno próximo capítulo. Além disso, como resultado desta fase optou-se por fazer um jogovoltado para entretenimento (descrito na próxima seção). A seguir, apresentamos a Fase

90


2, que apresenta o ciclo de desenvolvimento do jogo em ambiente real.

4.3.3.2 Fase 2: ciclo de desenvolvimento do aplicativo

Nesta seção, buscamos vivenciar as experiências reais no processo do ciclo de desenvolvi-mento de software para celular, conforme abordado na Seção 3.2.

Após ter importado o demo MobilePiano MIDlet Suite para dentro da IDE MotodevStudio for Java, iniciou-se a fase de codificação e construção (a). Decidiu-se que onome original do demo deveria ser alterado para Mobile Piano Learning. O nome foiformulado a partir do reuso da funcionalidade do demo anterior (PEv-04) e do seu nomeproposto (“Mobile Piano)”, e estendido para tornar-se mais atrativo.

O demo permite reproduzir os sons de um piano, permitindo que o usuário toquesons usando o recurso de touchscreen. O demo foi cuidadosamente analisado pelodesenvolvedor (PEv-05), pois todo o seu ciclo de vida precisou ser entendido. Através daferramenta de depuração (PEv-06) do Eclipse, pode-se tirar vários dúvidas dos pontos decódigo de complexidade alta (devido ao uso da JSR-135 - Mobile Media API).

Em seguida optou-se por transformar o demo em um jogo para aprendizado de notasmusicais usando o piano e reusando suas funcionalidades básicas (idem PEv-04). Dentrodas novas funcionalidades implementadas, destacamos a possibilidade do usuário usartambém as teclas numéricas do dispositivo, bem como, visualizar a nota musical queestá sendo tocada (Do, Ré, Mi, Fá, Só, Lá, Si e sustenidos respectivos). Foi adicionadotambém, uma tela de Sobre (About), com uma descrição do que o MIDlet faz e uma fotodo desenvolvedor.

A fase de teste (b), foi percorrida sem maiores dificuldades através da execuçãodo emulador (PEv-07). A Figura 4.9, exibe o aplicativo sendo simulado no emuladorda Motorola. As funcionalidades foram testadas e implementadas de acordo com asfuncionalidades reusadas e planejadas.

As fases seguintes foram assinatura (c) e distribuição (d). A fase assinatura (c), nãorequerer obrigatoriamente a sua utilização, que consiste na assinatura digital do aplicativo,assim, passou-se para a etapa seguinte (PEv-08): a distribuição (d) do aplicativo.

Tentou-se instalar o aplicativo desenvolvido em diferentes modelos de celular (PEv-09). As tentativas percorridas, bem como, os seus resultados são descritos a seguir:

• Nokia N95 (Symbian): Sucesso de instalação e execução do aplicativo. Porém, aúltima tecla (#), não tocou o som conforme esperado (nota “Si”);

91


Figura 4.9 Testando aplicativo Mobile Piano Learning no emulador

• ROKR EM35 (Motorola Linux OS) : Sucesso de instalação e insucesso na exe-cução (PEv-10);

• W510 (P2K ou Motorola OS): Sucesso de instalação e insucesso na execução(idem PEv-10);

• Moto Q 9h (Windows Mobile): Sucesso de instalação e insucesso na execução(idem PEv-10).

Com as execuções falhando nos diferentes celulares citados (PEv-10), inicialmentepensou-se que o aplicativo estivesse com algum bug (PEv-11). Então o aplicativo foinovamente para a fase de codificação e construção (PEv-12), visando re avaliar e analisaros pontos críticos. Foi observado que não havia um tratamento de exceções adequado(PEv-13). O jogo então foi remodelado para contemplar o tratamento de exceções(amigável).

As fases de codificar e construir, bem como testar, precisam ser percorridas novamente(PEv-14). Após realizar alguns testes no emulador e gerar uma versão atualizada doaplicativo, foi percorrido as instalações nos celulares reais novamente (PEv-15). Noentanto, descobriu-se que para tocar o som da JSR-135 (Mobile Media API), a PSC dofabricante requer o suporte de codecs9 de áudio específicos.

9codecs: tipo de formato de arquivo que é suportado pelo sistema para a sua execução

92


Para garantir que essa era mesmo a razão do problema do aplicativo, levou-se maisum tempo de investigação em fóruns técnicos, bem como, documentações específicasencontradas na internet (site especializados como o forum.nokia.com), para confirmar arazão técnica (PEv-16). Foi confirmado que a versão do Symbian do celular N-95 possuíasuporte ao codec necessário para a execução do aplicativo, justificando o fato de ter sidoo único modelo testado que funcionou (vide Figura 4.10).

Figura 4.10 Mobile Piano Learning rodando no modelo Nokia N-95

Os demais modelos de celular testados não funcionaram exatamente no momento deinstanciar o recurso da JSR-135 (Mobile Media), especificamente no uso da instrução( Manager.createPlayer(. . . ) ). Para se descobrir tal fato, foi necessário estudar asdocumentações técnicas do fabricante Motorola a fim de entender o processo de depuraçãodiretamente dentro do celular real (debugging on a device) (PEv-17).

Sabemos que o jogo desenvolvido Mobile Piano Learning somente possui compat-ibilidade com os dispositivos da Série 60 (com versão da PSC Symbian 9.2) (PEv-18).Entretanto, outras plataformas não testadas, tais como as abordadas no Capítulo 2, pre-cisam ser testadas em seus diferentes dispositivos para garantir portabilidade nessastecnologias (PEv-19).

Por fim, tentou-se ofertar o aplicativo nos canais conhecidos de distribuição edisponibilizá-lo em canais gratuitos ou a custos reduzidos (PEv-20).

Um desses canais de compartilhamento gratuito de aplicativos foi o portal NokiaMosh (http://mosh.nokia.com/). No entando, a Nokia encerrou as atividadesdo portal, informando que o site foi descontinuado, centralizando as operações no OVI(http://store.ovi.com/). Um fato curioso, segundo informado no site do portalMosh, o número de download atingiu a marca de 137.623.934 downloads de aplicativos.

93

http://mosh.nokia.com/

http://store.ovi.com/


Ao acessar o portal OVI, observou-se a necessidade de realizar um cadastro (na formade contrato), onde o desenvolvedor paga uma taxa inicial. Após a efetividade do acordo,os uploads de aplicativos ficam liberados (PEv-21). O aplicativo desenvolvido não foidistribuído.

4.3.4 Resumo dos Pontos-Chave Identificados

O estudo de caso identificou alguns pontos-chave e oportunidades para melhorias doDemoTool sobre o Motodev Studio/J (vide Tabela 4.1), bem como, foi evidenciado algunspontos abordados nos Capítulos 3 e 4 , e confirmados pelo estudo (vide Tabela 4.2).

Tabela 4.1 Pontos de Melhoria do DemoTool e relacionadosPontos DescriçãoPM-01 Incentivar Educação/Aprendizado do desenvolvedor (Motodev Studio/J)PM-02 Informes especiais dos novos recursosPM-03 Mecanismo de últimas notícias permanente (Motodev Studio/J)PM-04 Pouco destaque na listagem dos demosPM-05 Disposição padrão da view DemoTool (pouca altura)PM-06 Informações das descrições dos demos ficam escondidas (PM-05)PM-07 Falta de Categorização e classificação dos DemosPM-08 Screenshots com ênfase para imagens inrrelevantesPM-09 (idem PM-08), mas com remoção de imagensPM-10 Lista de Demos com rolagem inadequado (com o mouse)PM-11 Pouco destaque da opção “Filter By"PM-12 Nomes mais apropriados (relacionado ao PM-11)PM-13 Função de ‘import"demo sem barra de progresso

As análises deste estudo são apresentados no capítulo seguinte.

94


Tabela 4.2 Pontos de Evidência identificadas do Estudo de CasoPontos DescriçãoPEv-01 Dúvidas sobre o serviço ou aplicativo “interessantes"a se fazerPEv-02 Necessidade de planejamento prévioPEv-03 Ferramentas disponíveis são assimiladas em práticas de usoPEv-04 Reuso de código é uma prática utilizadaPEv-05 Exemplos de terceiros são fortemente analisadasPEv-06 Ferramentas de depuração de código são empregadasPEv-07 Emuladores cumprem bem o papel de testar aplicativosPEv-08 Fase de Assinar (Signed) do aplicativo não é uma práticaPEv-09 Ocorrem várias instalações do aplicativo em celulares-alvosPEv-10 Problemas comuns acontecem durante a execução no celular-alvoPEv-11 Existem limitações no celular que induzem o pensamento por

erros de códigoPEv-12 As fases do ciclo de desenvolvimento são percorridas muitas vezes

durante o processo de desenvolvimento (excluíndo assigned)PEv-13 Falta de tratamento de exceções no código são corriqueirasPEv-14 (idem PEv-12)PEv-15 (idem PEv-09)PEv-16 Consulta em documentações e fóruns técnicos são comuns

(principalmente pela Internet)PEv-17 Processo de depuração sobre o celular-alvo (difícil execução)PEv-18 Compatibilidades são confirmadas via testes do aplicativo nos

celulares-alvosPEv-19 Dificuldades para testar em todos os aparelhos (PSC diferentes)PEv-20 Canais de distribuição de aplicativos estão se consolidandoPEv-21 Existem custos para distribuir os aplicativos nos canais dos

fabricantes (OVI suporta a PSC Java ME)

95

“Quem pensa pouco erra muito.”

Leonardo da Vinci 5Estudos e Resultados

Neste capítulo é apresentado os resultados decorrentes da análise do estudo de casoanterior, assim como, os resultados das investigações que guiaram a pesquisa nos setoresdo ecossistema da indústria de celular, através da aplicação de um questionário em grupode usuários.

5.1 Análise e Resultados do Estudo de Caso

Conforme apresentado anteriormente (Capítulo 4, Seção 4.3), o estudo de caso tevecomo objetivo vivenciar o desenvolvimento de um game para celular (Mobile Piano

Learning), permitindo acompanhar a utilização do DemoTool como ferramenta de apoioao processo, bem como, buscando evidenciar algumas das problemáticas vivenciadas pordesenvolvedores, procurando respostas para a questão (Q7) deste trabalho.

Esta seção apresenta os resultados do estudo de caso de acordo com os pontos-chaveidentificados e sintetizados pelas seguintes tabelas:

• Pontos de Melhoria do DemoTool (Tabela 4.1) ;

• Pontos de Evidência identificadas (Tabela 4.2).

5.1.1 Análise dos Pontos-Chave

Diante dos testes estratégicos apresentadas (vide Seção 4.3.2) busca-se agora investigar avalidade das mesmas, realizando análise dos pontos-chave identificados.

Os Pontos de Melhoria (PM) observados para o DemoTool, bem como, para oMotodev Studio for Java, durante a execução do estudo de caso, foram consideradosna perspectiva de um desenvolvedor de software em momento que antecede (Pré) e

96

5.1. ANÁLISE E RESULTADOS DO ESTUDO DE CASO

procede (Pós) as fases do ciclo padrão de desenvolvimento de celular, ou seja, às fases deCodificação e Construção, Testes, Assinatura e Distribuição. Sendo assim, alguns PMssão mais críticos, podendo prejudicar o propósito da ferramenta, e outros, no entanto, sãorelativamente simples de resolver, de caráter de pequenos ajustes ou bugs por corrigir.

Os Pontos de Evidência (PEv) no estudo de caso, assim como, as problemáticaspercebidas ao longo das fases do desenvolvimento, são relativos ao processo como umtodo e servem como base para confrontar os argumentos da teoria, vistas no decorrer destetrabalho, com as constatações das situações chave percebidas. Diante disso, observou-sediversas dificuldades e percepções que são apresentadas a seguir em ordem cronológica.

Figura 5.1 Pontos chave identificados sobre às fases de desenvolvimento ao longo do tempo

A Figura 5.1 apresenta a distribuição dos pontos chave descobertos durante o ciclode desenvolvimento do jogo Mobile Piano Learning. Os dados estão dispostos pelasfases com suas respectivas PMs e PEv. A seguir apresenta-se as análises das duas fasesinvestigadas no estudo de caso.

5.1.2 Análise da Fase 1

Observando a distribuição dos pontos-chave sobre as fases expostas, podemos considerarque o uso da ferramenta DemoTool se dá na fase inicial do processo de desenvolvimento,ou seja, a fase Pré. Foram confirmados 13 Pontos de Melhoria, de acordo com a Tabela 4.1e 3 Pontos de Evidência (vide Tabela 5.1).

97


Tabela 5.1 Pontos de Evidência identificadas na fase PréPontos DescriçãoPEv-01 Dúvidas sobre o serviço ou aplicativo “interessantes"a se fazerPEv-02 Necessidade de planejamento prévioPEv-03 Ferramentas disponíveis são assimiladas em práticas de uso

O primeiro ponto chave identificado foi o PEv-01, que aborda uma questão pertinenteno desenvolvimento de software, não somente voltado para celular, mas também pode-se considerá-lo como um desafio para a computação em geral - que software seria

interessante de se fazer? Constatou-se que o PEv-01 é uma das primeiras dúvidas quesurgem antes de iniciar o desenvolvimento propriamente dito. Podemos constatar issocitando as observações de Pressman sobre a importância do software e as dimensões queele assume: “. . . o software é uma das poucas tecnologias-chave que causaram impacto

sobre quase todos os aspectos da sociedade... sendo fundamental em quase todos os

aspectos dos negócios. ” (Pressman (1995), pg. 1011).Além disso, na computação móvel, de acordo com Loureiro et al. (2003) é necessário

projetar aplicações e serviços na área de celular, que sejam interessantes para os usuários,para então, superar os desafios presentes. Entretanto, quais serviços são interessantes?Conforme listamos algumas categorias e exemplos de aplicativos (vide Tabela 1.2 eFigura 1.3), que têm recebido maior destaque e interesse das pessoas, pois são maisrequisitadas em números de downloads, tal qual a categoria de games Neufeld (2009a).

O PEv-02 tem relação com a educação e aprendizado do desenvolvedor sobre osseus conhecimentos de Engenharia de Software e de conhecimentos da área móvel. Aquestão que se apresentou foi que tipo de software poderia ser interessante a se fazer. Aresposta a essa pergunta é um dos grandes desafios da computação, portanto, podemosconsiderar uma questão difícil e comum na área. Porém, a ferramenta como um todo(Motodev Studio/J) não contribui para ajudar o desenvolvedor nesses pontos específicos,pois estão mais ligados a conhecimento prévio do desenvolvedor. Segundo Passos(2006), a utilização de recursos interativos no processo de ensino-aprendizagem torna-seimprescindível.

Foi identificado durante à execução do Motodev Studio/J, o primeiro ponto de mel-horia (PM-01) sobre a ferramenta, pois não ficou perceptível para o desenvolvedor (aprimeira vista), instruções referentes a problemática da PEv-02. Um dos lugares paradescobrir as funcionalidades existentes é lendo a documentação técnica, mas para isso ousuário precisa acessar o Help Content. São poucos os usuários que acessam os menus de

98


ajuda. Tem-se notado que qualquer dúvida busca-se diretamente na Internet (“perguntar aGoogle”). Uma oportunidade para a ferramenta aproximar o desenvolvedor oferecendorecursos e links externos que indiquem boas referências, artigos técnicos e fóruns, deforma a incentivar a educação do desenvolvedor. O portal Fórum Nokia1 é um bomexemplo dessa iniciativa.

Tabela 5.2 Agrupamento de Pontos de Melhoria por status de criticidadeStatus Pontos Sugestões açõesImportante PM-01 Focar em Educação/Aprendizado;Essencial PM (02,03 e 04) Destaques e Notícias (RSS)Desejável PM (05, 06, 07, 08, 09) Aspectos de UsabilidadeDesejável PM (10,11, 12 e 13) Melhorias gerais e correções bugs

A Tabela 5.2 apresenta um resumo dos PM identificados e classificados por critériode criticidade (Desejável, Importante e Essencial), com sugestões de ações.

Os pontos de melhoria (PM-02 e PM-03) propõem mecanismos de notícias (talcomo leitores de Feeds RSS), embutido na IDE, visando melhorar a comunicação dodesenvolvedor de celular, com as informações e notícias atualizadas do fabricante daPDC, acessadas toda vez que o ambiente for executado pela primeira vez. Essa ponte éimportante e tem sido destacada por Ziv and Mulloth (2007) (Figura 1.5). Já o PM-04dá ênfase ao pouco destaque que ferramenta DemoTool assumiu quando foi executado aprimeira vez, principalmente por ter pouco destaque na listagem dos demos presentes nalista. Dada a importância desses PMs, considera-se como essenciais a serem melhorados.

Alguns aspectos de usabilidade foram constatados no PM-06, no qual estão presentesna ferramenta DemoTool. Entretanto, originalmente a tela se apresentou bem pequena(com pouco destaque), consequentemente, pouca atenção do desenvolvedor foi percebida.Assim, sugere-se considerar aspectos de usabilidade conforme abordado no Capítulo 3(Seção 3.3). Expandindo a tela do DemoTool para cima, tem-se uma visualizaçãomelhorada das informações na tela.

Já o ponto PM-07 observou-se a necessidade que cada aplicação demo poderiaestar categorizado, de acordo com o tipo de aplicação e contexto de utilização (Game,Música, exemplos diversos. . . ), para permitir uma opção de filtragem adicional pelodesenvolvedor.

No PEv-03 foi verificado que o desenvolvedor só percebe as ferramentas disponíveisa medida que tem necessidade de usá-las, bem como, requer descoberta por conta própria

1www.forum.nokia.com

99

www.forum.nokia.com


os recursos disponíveis. Como exemplo podemos citar o DemoTool, que foi localizadopor iniciativa do desenvolvedor, sem nenhum indicativo do ambiente por divulgar asferramentas existentes, suas possibilidades e contextos de uso. Tais dificuldades foramabordadas no Capítulo 3, dentre os desafios técnicos (vide Seção 3.3) que se apresentamcomo diferentes tecnologias e ferramentas (PDC, PSC, protocolos de comunicaçãoetc). Diante disso, observa-se que os ambientes devem buscar usar recursos didáticospresentes da IDE, tal como a plataforma Eclipse oferece como: “Tips and tricks"e “Cheat

Sheets”; que são dicas e truques e uma ajuda guiada passo a passo, respectivamente. Taisfuncionalidades devem ser consideradas.

5.1.3 Análise da Fase 2

A Fase 2 é caracterizada pelos procedimentos envolvidos com a implementação do códigoaté a sua finalização. A Tabela 5.3, aresenta os pontos identificadas na fase de Codificare Construir. O PEv-04 atesta a utilização da ferramenta DemoTool como suporte paraescolher um demo existente, a fim de reusar uma infra-estrutura de código inicial, paraeconomizar custos de tempo, bem como, de assimilação do processo.

Tabela 5.3 Pontos de Evidência identificadas na fase Codificar e ConstruirPontos DescriçãoPEv-04 Reuso de código é uma prática utilizadaPEv-05 Exemplos de terceiros são fortemente analisadasPEv-06 Ferramentas de depuração de código são empregadasPEv-12 As fases do ciclo de desenvolvimento são percorridas muitas vezes

durante o processo de desenvolvimento (excluíndo assigned)PEv-13 Falta de tratamento de exceções no código são corriqueiras

A funcionalidade identificada no PEv-04 foi confirmada por permitir ao desenvolvedor,dentre diversas opções de demos, escolher a que melhor se aplicou à necessidade dedesenvolvimento (produzir um game) e importá-la para seu ambiente de produção (IDE),ou seja, o DemoTool permitiu reusar aplicações no contexto do desenvolvimento desoftware para celular.

Embora um aplicativo de terceiro tenha sido escolhido e reusado, há necessidadede validação, por parte do desenvolvedor, das funcionalidades e contextos de utilizaçãodo demo, pois não há garantias que o aplicativo reusado atenda as necessidades esper-adas. O PEv-05 foi identificado mostrando que independente do demo escolhido, semprehaverá necessidade de análise técnica profunda a fim de garantir as funcionalidades. Esse

100


ponto-chave requer bastante esforço do desenvolvedor. No entanto, com as ferramentasde depuração presentes na IDE (PEv-06), esse trabalho de análise é facilitado e o temporeduzido. Neste trabalho, abordamos a importância de mecanismos de depuração nos req-uisitos desejáveis para ferramentas de desenvolvimento (Capítulo 3, Seção 3.4, requisito8).

Outros fatores confirmados na fase de Codificação e Construção foram os pontos(PEv-12 e PEv-13). A evidência (PEv-12) é esperada e são comuns no processo, poiseventualmente bugs são encontrados na fase seguinte, de testes, e ajustes são necessáriosno aplicativo, voltando-se para a fase inicial. Entretanto, dada as diferenças das tecnolo-gias das Plataformas de Software de Celular (PSC) e das Plataformas de Desenvolvimentode Celular (PDC) (apresentadas no Capítulo 2 e Capítulo 3, respectivamente), existemvárias incompatibilidades que normalmente poderiam ser melhor tratadas através do usode tratamento de exceções (PEv-13). Essa realidade foi confirmada, sendo necessáriore-escrever o aplicativo reusado para conceber tratamento de exceções em alguns pontos.

A seguir apresentam-se os pontos-chave da fase de Testes. A Tabela 5.4 ilustra osPEv confirmados na fase de Testes.

Tabela 5.4 Pontos de Evidência identificadas na fase de TestePontos DescriçãoPEv-07 Emuladores cumprem bem o papel de testar aplicativosPEv-09 Ocorrem várias instalações do aplicativo em celulares-alvosPEv-10 Problemas comuns acontecem durante a execução no celular-alvoPEv-11 Existem limitações no celular que induzem o pensamento por

erros de códigoPEv-14 (idem PEv-12)PEv-17 Processo de depuração sobre o celular-alvo (difícil execução)

Pode-se confirmar, através do PEv-07, que a PDC da Motorola corresponde bem aproposta de testar e simular o game durante o seu desenvolvimento. A experiência foisatisfatória de acordo com as comparações dos SDKs (vide Capítulo 3, Tabela 3.2).

Durante a fase de Testes, foi confirmado o fato de ocorrerem várias instalações noscelulares-alvos disponíveis (PEv-09), uma vez que, para o desenvolvedor existe a crença(“certeza”) que o software irá funcionar conforme esperado, contanto que seja instalado etestado no celular real. Embora, essa afirmação não possa ser provada devido a exemplosvivenciados nas práticas de desenvolvimento para celular, conforme podemos perceberem Cho and Jeon (2007); Morimoto (2009), pois existem diferentes implementações dasPDC, bem como, das PSC.

101


Além disso, confirmou-se que o PEv-10 é verdadeiro, ou seja, as funcionalidadesdo jogo voltados para vários celulares-alvos é uma tarefa bastante custosa. Os dados daliteratura também comprovam isso (Tarnacha and Maitland (2006); Kurkovsky (2009);Loureiro et al. (2003)), bem como, a experiência de desenvolvimento do pesquisador.Nos testes realizados com a plataforma Nokia (Symbian com suporte a Java ME), desde oinício sempre ocorreram conforme esperado. Entretanto, quando o aplicativo foi testadoem outras plataformas diferentes, em diferentes modelos (vide Fase 2 do estudo de caso),ocorreram falhas na execução do software. Esse ponto é crítico para a fase de Testes, poisprojetar aplicativos para diferentes celulares torna-se trabalhoso e custoso.

Há um dilema observado nesta fase do desenvolvimento, confirmado pelo PEv-11,pois para realizar e obter garantias da qualidade do aplicativo, é preciso testar nos am-bientes reais de uso e não somente nos simuladores. Embora, a idéia do simulador sejareproduzir o máximo das restrições e funcionalidades das APIs utilizadas pelo desen-volvedor. O que ocorre, portanto, é que as tecnologias das PDC, que tecnicamente seguemespecificações padronizadas (às JSRs para o caso da tecnologia Java ME), possuem im-plementações diferentes, com bugs, limitações e até recursos que são incompatíveis entresi. Desta forma, um aplicativo que roda no simulador da Motorola, pode não rodar notelefone real da sua própria PSC correspondente. Foi o que ocorreu em nossa avaliação.

No PEv-11 constatou-se que tais limitações e incompatibilidades das PSCs descober-tas no cenário da fase de Testes, quando aplicado em celulares reais, tendem a confundir opensamento dos desenvolvedores, pois os seus aplicativos funcionavam nos simuladores.Então surgem questões tais como: será que meu código está certo? Estou usando asAPIs corretamente para utilizar determinados recursos? Consequentemente temos váriastentativas e repetições da fase Codificar e Construir e fase de Testes, destacado peloPEv-14.

As situações indicadas pelos PEv-11 e PEv-14, fazem com que o desenvolvedor tentereproduzir os problemas vivenciados utilizando o recurso da PSC, tal como a depuraçãosobre o celular-alvo (PEv-17). Esse recurso é o mais indicado, pois permite reproduzir osoftware no ambiente real do hardware da PSC. Entretanto, diversas tecnologias impõemdiferentes restrições, bem como, a curva de aprendizado é alta. Existem documentaçõestécnicas que podem ser consultadas para auxiliar esse processo, mas como já foi evidenci-ado, requer que o desenvolvedor descubra como fazer. Talvez por isso que existem tantosacessos pela Internet aos portais focados para desenvolvedores.

Constatou-se que na Fase de Assinar (vide Tabela 5.5), obteve-se um único pontochave (PEv-08), pois nesta fase não havia a preocupação (contexto do estudo de caso)

102


Tabela 5.5 Pontos de Evidência identificadas na fase AssinarPontos DescriçãoPEv-08 Fase de Assinar (Signed) do aplicativo não é uma prática

de distribuir o aplicativo para operadoras de celular. Segundo Junquera and Gnius(2005); Symbian (2008), normalmente as operadoras requerem aplicações certificadasvisando obter garantias pelo fabricante, objetivando maior compatibilidade dos celularescomercializados pela operadora.

Entretanto, diante da atual oferta de dados (Seção 1.2.2), muitas aplicações estãosendo ofertadas (principalmente jogos), sem a necessidade de assinatura, pois as PSCnão impedem a execução dos programas. A certificação, por outro lado é uma garantiado fabricante que o software funciona no celular de forma segura, bem como, para tentarrevolver problemas tais como os mencionados pelo PEv-10.

Tabela 5.6 Pontos de Evidência identificadas na fase DistribuirPontos DescriçãoPEv-15 (idem PEv-09)PEv-16 Consulta em documentações e fóruns técnicos são comuns

(principalmente pela Internet)PEv-20 Canais de distribuição de aplicativos estão se consolidando

Inicialmente a Fase Distribuir (vide Tabela 5.6), se caracterizou por investigaçõespara tentar entender a razão pela qual o aplicativo desenvolvido somente executava nomodelo de PSC Symbian. Após essa investigação procurou-se distribuir o aplicativo emalgum canal de distribuição existente.

Embora tecnicamente o game estivesse pronto para distribuição, não havia respostaspara justificar o problema de não funcionar nos telefones reais testados (exceto NokiaN95). Assim, alguns testes foram realizados (PEv-15) em telefones reais visando en-tender o problema. Foi procurado em várias fontes de estudo para saber como realizardepuração nas outras PSC testadas (PEv-16). Não era desejado distribuir o aplicativosem compreender a causa, pois assim a portabilidade ficaria prejudicada, tornando o jogorestrito para PSC Symbian somente. Embora, o PEv-20 comprovou que existem váriosopções de canais de distribuição de aplicativos, principalmente dos fabricantes de celular,conforme apresentou-se em capítulos anteriores. O aplicativo não foi publicado no portalescolhido (OVI da Nokia).

A Fase Pós (vide Tabela 5.7), tem proximidades com a fase anterior, mas foi consider-

103


Tabela 5.7 Pontos de Evidência identificadas na fase PósPontos DescriçãoPEv-18 Compatibilidades são confirmadas via testes do aplicativo nos

celulares-alvosPEv-19 Dificuldades para testar em todos os aparelhos (PSC diferentes)PEv-21 Existem custos para distribuir os aplicativos nos canais dos

fabricantes (OVI suporta a PSC Java ME)

ado como separadas para ficar de acordo com os acontecimentos cronológicos vivenciadosno experimento deste estudo de caso.

O PEv-18 confirmou o problema após testes de depuração diretamente na PSC doscelulares-alvos, permitindo determinar que a compatibilidade do game Mobile PianoLearning somente roda sobre PSC Symbian. Conformou-se ainda, que para garantircompatibilidades de outras plataformas não testadas, tais como as citadas no Capítulo 2,devem ser percorridas testes de forma semelhante em todas quanto possível (PEv-19).Entretanto, não havendo recursos disponíveis essa informação não foi evidenciada.

Para distribuir o aplicativo constatou-se que o portal OVI da Nokia é uma escolhainteressante (PEv-21), pois permite ao desenvolvedor remunerar o seu aplicativo e assim,obter ganhos financeiros quando usuários realizarem download. Além disso, a infra-estrutura do OVI permite facilitar para o desenvolvedor publicar seu software, caracterizá-lo e torná-lo conhecido dentro do portfólio do fabricante. No entanto, optou-se por nãodistribuir o game desenvolvido em consequência às problemáticas (PEv-18 e 19).

Figura 5.2 Gráficos em relação a tendências (a) e participação (b) no desenvolvimento do game

A Figura 5.2 ilustra dois gráficos a partir dos pontos-chave (PEv) do estudo de caso.Um ilustra a tendência ocorrida no processo de desenvolvimento como um todo (a),

104


enquanto o outro apresenta o percentual observado em cada fase do processo (b).Considerando o gráfico da Figura 5.2 (a), podemos perceber que existe uma tendência

para encontrarmos os pontos de evidência principalmente nas fases de implementação(Codificar e Construir) e Teste, que juntas representam 53% do total (gráfico b).

A fase Pré, cenário em que a ferramenta DemoTool foi utilizada, representou 14% dasevidências, o que nos diz que fases antecedentes são atividades que requerem atenção dodesenvolvedor, podendo desencadear bastante tempo, uma vez que, são nas fases iniciaisque existem preocupações como a coleta de dados, identificação de requisitos, seguidopor análise e projeto. Além disso, são nas fases iniciais que se apresenta as dúvidas(PEv-01) e os desafios técnicos (PEv-02).

A fase Codificar e Construir se caracteriza pela utilização das ferramentas das PDCem momento de implementação. Pode-se confirmar que as práticas de reuso (atravésdo DemoTool), permitiram desenvolver um game sem no entanto, ter que iniciar acodificação do zero. Partiu-se do aplicativo reusado e adaptou-se para uma realidadesemelhante. Embora neste caso, o aplicativo ficou limitado ao cenário original (umaaplicação para demonstrar o uso da JSR-135), permitindo tocar sons de piano. Pode-sedizer ainda, que reusar aplicativos requer entendimento destes por parte do desenvolvedor(PEv-05), o que é realizado com sucesso através dos recursos das ferramentas disponíveisnas PDC (PEv-06), no qual são bem utilizadas. Porém, atividades nesta fase são repetidasvárias vezes (PEv-12).

A principal característica da fase de Teste, no qual apresentou 29% das evidências,são que os emuladores das PDC cumprem bem o papel de simular os aplicativos no PC(PEv-07), entretanto, geram ao mesmo tempo insegurança (PEv-11), pois não há certezaque o software irá se comportar nos celulares-alvos das PSC, tal como se comportou nasimulação pelo emulador do fabricante da PDC. Assim, são requeridos esforços paratestar o aplicativo também nos celulares-alvos (PEv-17).

A fase de Assinar, não se confirmou no desenvolvimento apenas como um passoopcional, tal como se apresenta na literatura (vide ciclo de desenvolvimento de AssinarSeção 3.2), mas principalmente, por não ser uma prática necessária (PEv-08) frente aonovo paradigma da oferta de dados (vide Seção 1.2.5).

Neste sentido, apresentam-se agora outros canais de distribuição e de comunicaçãona indústria de celular, tal como OVI (fabricante), e até mesmo em portais de conteúdosdiversos para distribuir as aplicações. Antes, o controle da oferta de dados se davapelas operadoras, que exigiam aplicações certificadas, agora, os aplicativos podem serofertados/distribuidos em qualquer repositório pela Internet, sem a intervenção das

105


operadoras. Essa constatação foi evidenciado em nosso estudo de caso como umatendência (Figura 5.2 a).

5.1.4 Resultados Obtidos

Após a análise dos PEv e das problemáticas discutidas no estudo de caso, considerando-seos testes estratégicos elaboradas para a investigação do problema da pesquisa, obtivemosos seguintes resultados:

• Teste Estratégico 1: Considerado plausível de acordo com interpretações dasanálises dos pontos de evidência (PEv-01, 02, 03, 04, 05, 07, 12, 14, 15).

• Teste Estratégico 2: Considerado plausível de acordo com interpretações dasanálises (PEv-04 e 05).

• Teste Estratégico Contrário 1: Considerado implausível de acordo com interpre-tações das análises (PEv-03, 04, 05, 07,12).

• Teste Estratégico Contrário 2: Considerada implausível de acordo com interpre-tações das análises (PEv-02, 10, 11, 13, 19)

Através do uso do DemoTool e da escolha de um aplicativo em contexto próximo doque se pretendia fazer, houve boa percepção sobre os pontos de evidência (PEv-01, 02 e03), considerados mais complexos pela engenharia de software. Reusando um aplicativobem projetado, puderam-se auxiliar o processo de abstrair algumas das complexidades taiscomo o levantamento de requisitos e análise do software. Embora o cenário favorecesseessa circunstância porque o demo reusado foi bem projetado anteriormente pela Motorola.Se essa realidade fosse contrária os resultados poderiam ser contrários. Além disso,reusando um aplicativo demo pode-se “adiantar” percepções e complexidades técnicas decomo funciona um jogo e como utilizar os recursos da PDC escolhida (PEv-04 e 05).

Os emuladores oferecem meios práticos para o desenvolvedor simular o aplicativona IDE, aproximando-o de sua realidade de trabalho (ambiente de produção usandoferramentas conhecidas de programação), permitindo assimilação do processo de desen-volvimento voltado para celular (PEv-07 e 12). Não obstante, o processo impõe testes emcelulares-alvos, possibilitando instalar e testar em ambiente real (PEv-09).

Entretanto, acredita-se que somente pode-se considerar tal fato se a escolha doaplicativo, bem como o seu contexto de utilização, coincidir com os propósitos que

106

5.2. ESTUDO ADICIONAL

se pretende projetar. Neste sentido, pode-se investigar o teste estratégico 1 sobre essacircunstância e avaliar os resultados.

O Teste Estratégico Contrário 2 foi negado, pois diante das necessidades de planeja-mento prévio (PEv-02), dos problemas comuns que acontecem nos celulares-alvos (PEv-10), dos erros induzidos a interpretações equivocadas (PEv-11), da falta de tratamentode exceções em códigos de terceiros (PEv-13), e pela dificuldade em testar aplicativosem todas as PSC (PEv-19), fica claro que o aplicativo demo a ser reusado, não pode serqualquer programa. Precisa ser cuidadosamente planejado pelo fabricante, para então odistribuí-lo com seu código fonte, cuidadosamente pensado e documentado para incen-tivar a educação do desenvolvedor, exemplificando as melhores práticas da Engenhariade Software atuais, frente os recursos disponíveis (APIs), e levando em consideração ointeresse da atual oferta de dados.

Dada a quantidade de demos oferecidos pelas diferentes ferramentas (SDKs) estu-dadas (vide o final da Seção 3.6), o desenvolvedor precisa ser criterioso para não reusarsoftware que não seja do escopo do seu problema. No estudo de caso, o jogo Mobile

Piano, da Motorola, inspirou a criação do Mobile Piano Learning, pois havia neste demoas características esperadas e desejadas.

5.2 Estudo Adicional

Nesta seção, apresentam-se os resultados das investigações que guiaram a pesquisa noecossistema da indústria de celular, bem como, a metodologia utilizada e a sua execuçãopara a aplicação de um questionário em grupo de usuários de celular, a fim de identificarpercepções no contexto da oferta de dados e serviços móveis.

O objetivo deste estudo é situar o leitor na perspectiva da discussão do Capítulo 1.2,de forma mais ampla, visando a possibilidade de aplicação de suas conclusões a outroscontextos, relacionados ao desenvolvimento de software para celular e seus impactospara a oferta de dados e serviços móveis de celular. O problema da pesquisa, portanto,consistiu na identificação da percepção dos usuários que utilizam o celular para uso deaplicativos de mídias de celular, bem como, dos serviços de comunicação móvel de dadosdo Brasil, relacionada com a oferta de dados.

5.2.1 Objetivos e Premissas

Os seguintes objetivos foram estabelecidos:

107


• Verificar a percepção dos usuários com relação a oferta de conteúdos e aplicativosno mercado de celular;

• Verificar a utilização do celular com relação a tendência de uso para acesso aInternet;

• Verificar a percepção dos usuários com relação a relevância dos setores envolvidosno ecossistema da indústria de celular;

• Verificar se os custos do tráfego de dados é um fator determinante para maioradesão de serviços móveis de dados no Brasil.

Uma vez definidos os objetivos para a pesquisa, foram elaboradas quatro premissaspara a confirmação do problema. O levantamento das premissas partiu da visão de Ziv(2005); Ziv and Mulloth (2007) sobre o novo paradigma presente na indústria de celular(vide Seção 1.2.5), bem como, do papel que as PSCs têm na criação de aplicativos móveiscomo novos nichos de mercado, conforme apresentados por Verkasalo (2009). Estaspremissas serão testadas, e então classificadas como plausíveis ou implausíveis.

As premissas (T) elaboradas foram:

T1. O celular frequentememte está sendo usado para instalação de Mídias de Celular;

T2. Usuários de celular não instalam mais aplicações por não encontrarem aplicaçõesconsideradas “interessantes”;

T3. No ecossistema da indústria de celular considera-se mais relevante o papel dosfabricantes de celulares, provedores de conteúdo e empresas de Internet;

T4. A oferta de dados para os celulares irá aumentar de forma significativa quando oscustos de transmissão de dados se aproximarem do modelo dos PCs com acesso aInternet.

5.2.2 Metodologia

De acordo com Quintella and Rodrigues (2005) apud Marconi and Lakatos (2003), ométodo científico pode ser definido como um conjunto das atividades sistemáticas eracionais que permitem alcançar o objetivo - conhecimentos válidos e verdadeiros -traçando o caminho a ser seguido, detectando erros e auxiliando as decisões do cientista.

108


O método científico utilizado nesta pesquisa foi o método hipotético-dedutivo. Estemétodo pressupõe que a partir das premissas formuladas, deduz-se a solução do prob-lema. Segundo Quintella and Rodrigues (2005), “ . . . este método propugna que o único

conhecimento genuíno é o obtido pelos caminhos da ciência. As únicas verdades seguras

são as que se pode avaliar objetivamente, independentemente do observador. Deduz

resultados a partir da formulação de premissas. Submete as premissas a testes, e busca

regularidade e relacionamentos causais entre seus elementos’’.As técnicas de pesquisa utilizadas neste trabalho podem ser classificadas como

uma pesquisa de campo, quantitativo-descritiva e qualitativo. Uma pesquisa de campo,de acordo com Quintella and Rodrigues (2005) é resultado de observações de fatos efenômenos ocorridos no real, objetivando à coleta, análise e interpretação dos dadoscoletados, com base numa fundamentação teórica, acerca de um problema de pesquisapara o qual se procura uma resposta, ou de hipótese que se queira compreender e explicar.Essa pesquisa se caracteriza como pesquisa de campo por realizar o levantamento nomercado da indústria de celular das percepções dos usuários sobre os serviços de dados eaplicações existentes.

A pesquisa quantitativo-descritiva, de acordo com Quintella and Rodrigues (2005)apud Marconi and Lakatos (2003), consiste em investigações empíricas, que objetivama análise das principais características, a avaliação de programas ou ainda o isolamentode variáveis principais ou chave. Neste tipo de estudo são empregadas técnicas comoentrevistas e questionários, e procedimentos de amostragem.

A pesquisa qualitativa de acordo com Flick (2004) . . . é orientada para análise

de casos concretos em sua particularidade temporal e local, partindo das expressões

e atividades das pessoas em seus contextos locais”. A pesquisa qualitativa apresentauma maior flexibilidade no trato com o campo de pesquisa e possibilita o surgimentode dados e informações não esperados inicialmente. Para esta pesquisa é utilizadaferramenta qualitativa de pesquisa, sendo suportadas por um levantamento bibliográfico(Capítulo 1.2) e possíveis verificações quantitativas no decorrer das observações.

5.2.3 Público-Alvo e Métodos

O público-alvo da pesquisa foi constituído por usuários de celular habilitados em op-eradoras no Brasil. Para essa população foi extraída uma amostra. Segundo Quintellaand Rodrigues (2005) apud Marconi and Lakatos (2003), uma amostra é uma partepertencente a uma população, escolhida segundo algum critério de representatividade. Ainformação recolhida para uma amostra é depois generalizada a toda a população.

109


A amostra é assim caracterizada: Cem (100) usuários de celulares participaram dapesquisa, sendo que a amostragem foi realizada por conveniência. O questionário foidisponibilizado na Internet, e através da distribuição do link para alguns contatos ealgumas listas de discussões2 conhecidas, o mesmo foi sendo divulgado a outros usuários.Este tipo de amostragem foi escolhido devido a limitações na realização de outro tipo deamostragem, como falta de recursos e tempo necessário à sua realização.

O instrumento de coleta de dados utilizado nesta pesquisa foi o questionário auto-preenchido, com exceção da última questão, que se apresenta como pergunta aberta,visando obter dados qualitativos. Essa questão pode ser classificada tal como as entre-vistas qualitativas centradas no problema em questão. Segundo Flick (2004), questõescentradas no problema apresentam o interesse do pesquisador na forma de questõesdirecionadas. O questionário desenvolvido pode também ser classificado como medi-anamente estruturado e não disfarçado. Os pesquisados responderam a perguntas fixas,sendo algumas respostas determinadas e outras livres, e tiveram total conhecimento sobreos propósitos da pesquisa. Permitiu-se que a questão qualitativa fosse opcional para não“forçar” respostas consideradas não válidas.

Quanto aos métodos de análise da questão qualitativa, uma vez coletados os dados, énecessário refiná-los e analisá-los frente ao contexto da pesquisa para então se obter delesa informação necessária. O uso de métodos de análise é vital para o fluxo de pesquisa,pois é através deles que é possível extrair informação relevante dos dados coletados.Assim, após a finalização do questionário, foi realizada a categorização dos dados obtidos.Nesta etapa do trabalho, o software NVivo3 foi utilizado para fazer a categorização e aanálise de conteúdo.

O NVivo é um sistema orientado a análise de dados qualitativos, lida basicamente comfontes textuais decorrentes do processo de pesquisa em campo. Permite a classificação deporções de textos para a construção de um quadro organizacional das informações emtópicos ou eixos temáticos. Este tipo de programa é adotado para dar suporte a pesquisasqualitativas por viabilizar principalmente a análise, relativamente rápida, de grandesmassas textuais.

Entende-se como análise de conteúdo um conjunto de técnicas que, através de pro-cedimentos sistemáticos e objetivos de descrição do conteúdo das mensagens, obtémindicadores (quantitativos ou qualitativos) que permitem ao pesquisador fazer inferênciasacerca do conteúdo manifesto durante as entrevistas.

2J2ME-l [email protected] e SBC-l [email protected] http://www.softwaresales.bham.ac.uk/az/nvivo.shtml

110

[email protected]

[email protected]

http://www.softwaresales.bham.ac.uk/az/nvivo.shtml


O Sistema de Categorias é uma das técnicas mais utilizada na Análise de Conteúdo.O processo de categorização se dá através do agrupamento de elementos da mensagem, apartir de características comuns Mayring (2002). O processo de construção das categoriasde análise, segundo Mayring (2002), deve seguir as seguintes características, entre outras:

• Exclusão Mútua: os dados não podem ser classificados em mais de uma categoria;

• Pertinência: as categorias devem atender às questões propostas na investigação;

• Objetividade: descrição sumária dos elementos a que se refere cada categoria.

A partir da análise dos instrumentos de coleta de dados e dos métodos de avaliaçãodos mesmos foi desenvolvido o modelo de questionário (vide Apêndice B). Através desteinstrumento foi possível recolher todos os dados necessários ao desenvolvimento dotrabalho.

5.2.4 Análise da Pesquisa

Nesta seção, apresenta-se a análise dos resultados obtidos da pesquisa, as análises daquestão qualitativa bem como, uma comparação com os resultados obtidos por Verkasalo(2009) é percorrida.

Ao todo, foram 83% dos usuários que dizem instalar aplicações no celular, sendo que36% instalam freqüentemente e apenas 17% disseram não instalar (vide Apêndice C).

Com relação às formas de instalação utilizadas pelos usuários, podemos observar quea maneira mais comum de instalação de aplicativos é via download da Internet, utilizandoo uso do computador pessoal como meio (foram 67% dos usuários que confirmaraminstalar aplicativos usando o PC), e para instalar no celular, usaram a porta USB (63%)e/ou via Bluetooth (35%). Além disso, uma parcela significativa dos usuários (47%)dizem realizar download de aplicativos diretamente pelo celular.

A principal forma utilizada pelo usuário de celular para encontrar aplicações, da nossaamostra, foi usando o navegador de celular para acessar a Internet (70%), seguido porindicações de amigos, colegas de trabalho ou familiares (41%).

O motivo apontada por não haver maior interesse por downloads de aplicativos pelosusuários no mercado de celular, deve-se ao fato dos usuários não encontrarem aplicaçõesjulgadas interessantes por eles (55%), seguido do custo cobrado pelas operadoras paratráfego de dados (36%). As dificuldades técnicas normalmente encontradas por usuáriosde celular, como difícil instalação de aplicativos e/ou receios às questões de segurança,representaram apenas 7% somadas, não sendo um ponto de preocupação dos usuários.

111


Além disso, os usuários demonstraram que 32% estaria disposto a aceitar receber entregade conteúdo baseado em propaganda no seu celular, contra 30% que não aceitaria, alémde 36% que talvez aceitaria.

Figura 5.3 Relevância nos setores do Ecossistema da Indústria de Celular

A Figura 5.3 ilustra a relevância atribuída pelos usuários quanto a importância dossetores do ecossistema da indústria de celular. As empresas de Internet e os fabricantesde celulares são considerados os mais importantes atores para produzir e prover serviçosde dados para celulares (62%, 61% somando-se 5 e 4).

Observa-se que existe uma tendência por considerar as empresas de Internet ocupandoum papel bastante importante para os usuários para ofertar conteúdos e serviços móveisde dados no Brasil. Em contrapartida, as operadoras e empresas de mídia/provedoras deconteúdo, demonstram ter pouca relevância para os usuários neste papel.

A Tabela 5.8 apresenta uma comparação dos dados obtidos da pesquisa de Verkasalo(2009), realizadas em 2007, com amonstragem de 606 usuários (dados do estudo Finnish

smartphone panel study 2007), com os dados coletados nesta pesquisa.Analisando a questão 1 (Instalou aplicativos?), constata-se que o Brasil está chegando

nos mesmos patamares alcançados pelos usuários norte-americanos em 2007, com relaçãoa frequência de instalação de aplicativos. Tal fato permite-nos inferir que o celular não éusado somente para comunicação de voz.

Temos ainda, duas divergências se compararmos os dados da tabela de 2007 frentea 2009, sobre a questão 4 (Por que parou de Instalar?) e 6 (Impotância da Indústria).Os dados da questão 4 refletem às razões que fizeram o usuário não baixar mais os

112


Tabela 5.8 Resultado comparativo de pesquisas sobre a oferta de dados para celular 2007/2009Questão Respostas % 2007 % 2009

EUA Brasil1) Instalou aplicativos?

Sim, frequentemente 35% 36%Sim, as vezes 49% 47%Não 16% 17%

2) Métodos de instalação?Download da Internet pelo PC 70% 67%Instalação transferindo via USB 66% 63%Download da Internet pelo celular 57% 47%

3) Como encontrou aplicativos?Navegador Internet pelo PC 85% 70%Navegador Internet pelo celular 29% 24%Sugestões amigos. . . 42% 41%

4) Por que parou instalar?Não achei interessante 62% 55%Não sabia que outros tipos de 28% 8%aplicações estam disponíveisAs aplicações são caras . . . 31% 20%

6) Importância da indústria(consideram muito importantes)

Fabricantes Celulares 31% 28%Operadoras 26% 17%Provedores Conteúdo 6% 20%Empresas Internet 10% 32%

aplicativos. No caso dos dados de Verkasalo (2009), foi constatado que o segundo fatormais apontado foi o custo dos aplicativos, ou seja, o seu valor de compra. No Brasil, noentanto, nossa pesquisa adicionou outro fator que foi considerado (o custo do tráfego dedados das operadoras, vide Apêndice C), assim, obteve-se 36% para esse fator no Brasil,contra 20% do fator comparado na tabela. Podemos considerar que no Brasil, o custo dotráfego de dados é um fator importante para os Brasileiros.

Outra questão a considerar como divergente é a 6, pois no caso da pesquisa de 2007foi considerado duas unidades de medida (considerado Muito Importante e Importante),enquanto que em nosso caso, consideramos uma escala (1 a 5), para identificar os dados(faixa de pouco importante para muito importante) apresentados no Figura 5.3. Entretanto,nessa situação considerou-se, para efeitos de comparação, as atribuições de peso 5 paraconsiderar a medida (Muito Importante).

Neste sentido, podemos perceber que hoje, diante da crescente oferta de serviços de

113


dados, bem como, da tendência de usar o celular para navegação na Internet, como sefosse o PC, há uma valorização do setor das Empresas de Internet, tal como ilustrado naFigura 5.3, justificando o percentual obtido (32%).

Por fim, chegamos à questão 10 deste trabalho, no qual se planejou uma questão aberta,com caracterização qualitativa centrada no problema em questão, ou seja, elaborou-seuma pergunta direcionando a premissa que se pretende validar. A premissa avaliada pelaquestão 10 aborda a premissa 4 (T4). Assim, a questão foi elaborada demonstrando oponto de vista do pesquisador, solicitando a opinião voluntária do usuário participante,sendo elaborada da seguinte maneira: “10) Acreditamos que a oferta de dados para os

celulares irá aumentar de forma significativa quando os custos de transmissão de dados

se aproximarem do modelo dos computadores pessoais com acesso a Internet. Qual a

sua opinião a respeito?”.Diante da aplicação da questão e da coleta das respostas respectivas, foram consider-

adas como respostas válidas, aquelas que constituíram o mínimo de argumentação, ouque demonstraram pontos de vista contrários ou afavores. Questões não respondidas nãoforam consideradas, bem como, afirmações ou negações vagas, tais como, “concordoplenamente", “discordo", etc., sem no entanto, justificar a resposta. Entretanto, quantita-tivamente algumas foram consideradas por questões de estatística. Assim, de um totalde 100 participações, consideramos 53 respostas válidas. O Apêndice D, apresenta umasíntese de algumas respostas consideradas pertinentes para essa pesquisa.

Conforme apresentado na Seção 5.2.3, este trabalho utilizou técnicas de categorizaçãopara melhor filtrar as respostas obtidas. O processo de categorização nos levou àsseguintes principais categorias, agrupadas por ordem de repetição:

• Custo de transmissão de dados: altos custos de transmissão, decorrentes dosplanos atuais das operadoras;

• Custo de aparelhos compatíveis: dificuldade de aquisição de celulares (smart-phones) por custo elevado;

• Modelo de negócio das operadoras: diferentes formas de cobrança, mas nogeral, cobram elevados valores tanto por tempo de uso como por dados trafegados.Custos não acessíveis para usuários pré-pagos principalmente; baixar o custo não érentável para as operadoras, pois é difícil competir com as fibras óticas; franquiasde celulares comercializados são caros;

• Processamento celular: poder computacional baixo dos celulares;

114


• Interface do celular: telas inadequadas do ponto de vista da usabilidade, bemcomo, da facilidade de encontrar conteúdos (não somente para usuários maistécnicos); personalização necessária; tornar a navegação mais usual;

• Conectividade aprisionada: dependência da infra-estrutura das operadoras paraacesso a internet; Modelo WiFi já demonstra solução para isso;

• Cobertura 3G: infra-estrutura 3G ainda em expansão, requerendo melhor posi-cionamento para equilibrar os custos; velocidade atual precisa aumentar;

• Cultura das pessoas: educação das pessoas como um todo para melhor utilizaçãoe conhecimento (a TV digital foi citada como exemplo);

• On-line 24h: usuários desejam permanecer conectados o tempo todo; o celularcomo meio de acesso rápido as informações;

• Aplicações úteis: oferta de aplicativos para celular é alta, porém, faltam aplicaçõese serviços úteis, ao invés de “mobile clones” de aplicações para Desktop;

• Baixo poder aquisitivo: pessoas não tem muitas condições financeiras para com-prar celulares adequados;

• Baixo custos de aplicações: conteúdos e serviços de dados são relativamenteacessíveis, porém, outros fatores impactam a adesão (listados acima);

• Custo da comunicação de voz: acaba por suprimir os outros, tornando mais difíciladesão de serviço de dados por exemplo;

Podemos citar ainda, aparelhos capacitados mais baratos, melhor cobertura 3G equeda nos preços nos serviços de voz, proporcionariam adesão maciça aos serviços dedados. Porém, existe um limite de banda da infra-estrutura atual, o que limita a quantidadede usuários de celular que acessam ao mesmo tempo as redes de dados. Não obstante, arede de dados 3G está sendo fortemente compartilhada com planos de dados para PCs,através do uso de modem 3G.

Do ponto de vista do desenvolvimento de software, foi observado que falta umaplataforma mais homogênea, o que acaba formando nichos de mercado menores, comoJava ME, iPhone, Symbian, Android. . . Como exemplo, podemos fazer analogia como PC, que é uma plataforma que integra diferentes tecnologias para acessar conteúdos.O grande problema dos celulares atuais é que as suas PSC estão “presas” às suas APIsdistribuídas pelos fabricantes.

115


5.2.5 Resultados Obtidos

Após o tratamento e análise dos dados obtidos, considerando-se as premissas (T) elabo-radas para solução do problema da pesquisa, obtemos os seguintes resultados:

• Premissa 1: Considerada plausível de acordo com a amostra dos usuários decelular;

• Premissa 2: Considerada plausível de acordo com a amostra;

• Premissa 3: Considerada implausível de acordo com a amostra;

• Premissa 4: Considerada implausível de acordo com a amostra;

Os dados obtidos da amostra confirmaram que os usuários de celular estão frequente-mente instalando aplicações, mais até do que o usando para comunicação de voz. Usuáriosde celular não instalam mais aplicações porque não encontram mídias de celular de seuinteresse.

A tendência da indústria de celular é incrementar a oferta de dados para tentar “sanar”essa necessidade. Entretanto, ficou evidente que o uso do celular, cada vez mais, tendea ser utilizado como meio para acessar a Internet. Neste sentido, o celular passa a serassimilado com as funcionalidades do PC, mesmo descoberto de poder computacional, oque limita bastante a sua utilização com esse propósito.

O papel mais importante para oferta de aplicativos e serviços de dados móveis, nossetores da indústria de celular foram consideradas às empresas de Internet e os Fabricantesde Celular, e não os provedores de conteúdo tal qual a premissa desta pesquisa. Alémdisso, o fator determinante na oferta de dados não é somente a questão do custo do tráfegode voz, mas principalmente, um conjunto de fatores, mas não os únicos, tais como:

• Celulares preparados (smartphones) para acessar dados e aplicativos;

• Conectividade acessível financeiramente (através de planos de dados);

• Expansão das redes 3G para melhorar a infra-estrutura e baixar os custos;

• Diminuição dos custos dos serviços de voz para evitar a não adesão dos serviços eplanos de dados;

116

5.3. LIMITAÇÕES DO ESTUDO

5.3 Limitações do Estudo

Essa pesquisa tratou da problemática do desenvolvimento de software para celular, abor-dando aspectos da utilização das PDC, em conjunto com uma ferramenta desenvolvidapara reusar aplicações demos, visando a melhoria da compreensão e assimilação doprocesso de desenvolvimento neste contexto. O estudo de caso procurou evidenciar arealidade, bem como as problemáticas envolvidas neste processo. Entretanto, muitas situ-ações não foram cobertas por não haver um acompanhamento em fábrica de software real,ou ainda, com iniciantes de programação. Dessa forma, as evidências aqui observadaspodem ter um caráter particular e restrito, do seu contexto de utilização, não podendo sergeneralizado para todos os casos. Embora, os dados evidenciados indicam que estejamcorretos e foram provados no contexto de utilização.

O estudo adicional, percorrido através da formulação de uma pesquisa com usuáriosde celular, não teve a preocupação de detalhar o estudo, através da descoberta do perfil daamostra, suas classes sociais, modelos de celulares usados, operadoras a que pertencem,idade, região do país, etc. Além disso, a quantidade da amostra (100 usuários) é muitopequena diante de mais de 159 milhões de usuários no país.

117

“Espere o melhor, prepare-se para o pior e recebe o quevier.”

Provérbio chinês 6Considerações Finais

O objetivo deste capítulo é apresentar as conclusões e considerações finais sobre otrabalho realizado, destacando as contribuições, as limitações e os pontos de extensãopara futuras pesquisas na área, bem como, destacar as implicações deste estudo sobreáreas correlatas.

6.1 Conclusão

A atual conjuntura da Indústria de Celular é composta por vários setores chaves, dos quais,destacamos ao longo desta dissertação, os Fabricantes de Celular e as suas tecnologias, asOperadoras de Celular e a conectividade oferecida, as empresas que ofertam conteúdos,dos quais há interesses coletivos por estes, e atualmente, as empresas com foco na Internet,provendo serviços que se tornaram indispensáveis para muitas pessoas. Cada qual visaatuar no mercado da indústria de celular, cujos clientes estão se espalhando ao redor domundo em ritmo crescente, buscando oferecer serviços e tecnologias para essa Indústria,competindo entre si, ao mesmo tempo em que, requerem cooperação para atuarem nesteecossistema.

Não obstante, temos os usuários de celular, que cada vez mais, aderem aos diferentesdispositivos, adquirindo tecnologias que inicialmente permitiram se comunicar, interagire transpuser barreiras de tempo e espaço, mas que agora, apresenta-se unificando idéias econceitos, em um único dispositivo portátil, que verdadeiramente está sendo usado porbilhões de pessoas.

Neste contexto, o celular deixou de ser um aparelho projetado somente para comu-nicação de voz, tornando-se um pequeno computador portátil (limitado ainda), fazendocom que as pessoas o utilizem como tal. Diante disso, o software assumiu um papel maisrelevante para usuários de celular, que desejam utilizá-lo para acessar informações assim

118

6.1. CONCLUSÃO

como nos PCs. Entretanto, existem várias implicações na área de celular que precisamser superadas, dentre as quais, o celular não é um PC e não possui poder computacionalequivalente.

Por conta das commodities do tráfego de voz, as operadoras de celular estão buscandoofertar conteúdos como aposta de maior lucratividade, e consequentemente, empresasdo setor estão adaptando os seus portfólios, produtos e serviços para prover conteúdospara os pequenos dispositivos, chamado de mídias de celular. Neste sentido, considerou-se que o modelo proposto por Ziv (2005); Ziv and Mulloth (2007), representa bem aproblemática existente, pois contextualiza a atual oferta de dados, mostrando que asoperadoras deixaram de ocupar a posição centralizadora para ofertar conteúdos, dandolugar a maior interação com outras empresas e usuários. Empresas provedoras de conteúdoe com foco na Internet, passassem a competir mais fortemente neste mercado.

Há, portanto, um interesse pelo celular e seus recursos, e mais ainda, pela utilizaçãodestes recursos para fazer coisas tal como o fazemos usando um PC. A complexidadeenvolvida por trás das tecnologias de celular é conhecida como Plataformas de Softwarede Celular (PSC), que entre outras coisas, estão aquém das demandas atuais dos usuáriosCho and Jeon (2007); Oliver (2008). Porém, devido à demanda por software, oportunizou-se o desenvolvimento de novas tecnologias, permitindo assim, que desenvolvedores desoftware de terceiros pudessem contribuir mais fortemente, e de maneira mais rápida, nodesenvolvimento de soluções para atender às demandas.

As Plataformas de Desenvolvimento de Celular (PDC)s vêm para contribuir nestadireção, simplificando um pouco as dificuldades impostas pelas PSC, que impõemrestrições tecnológicas, que inclusive, afeta a cadeia de valor de uma aplicação decelular, pois restringe o software para uma combinação específica de tecnologia da PSC,do hardware do celular e da rede da operadora o qual o aplicativo pode rodar.

Conclui-se que tanto a PSC, bem como a PDC, são as tecnologias que servem comobase para criar aplicativos, e para tal, permite manipular os recursos que o celular oferece.Além do mais, são as únicas maneiras atuais para empresas e desenvolvedores de terceirosatuarem na prestação de serviços sem dependerem do envolvimento do fabricante decelular. Existem, porém, uma variedade de tecnologias diferentes, a escolha da tecnologiaadequada depende de fatores como a expertise do desenvolvedor além do projeto o qualestá inserido.

Diante disso, essa dissertação mostrou a ferramenta DemoTool, que tem por obje-tivo reusar aplicativos demonstrativos e a sua integração com a ferramenta da PDC daMotorola, o Motodev Studio for Java.

119

6.2. CONTRIBUIÇÕES

Observou-se que a ferramenta DemoTool tende a se aproximar do seu objetivo, porém,sem nenhuma garantia, pois permite, após sua utilização, melhorar o entendimento dealguns aspectos do processo de desenvolvimento de software para celular, tais comoas problemáticas e práticas vivenciadas nas situações reais de uso, principalmente nasfases de análise e projeto, teste e distribuição do aplicativo. Embora, constatou-se quetais resultados positivos tendem a ocorrer através do reuso de demos bem projetadospreviamente, bem como, quando o desenvolvedor possuir alguns conhecimentos prévios.

Constatou-se via pesquisa qualitativa que a principal barreira para aquisição de novosaparelhos (smartphones), considerados prontos para a atual oferta de dados, são os altoscustos dos dispositivos, bem como, os valores de suas franquias de utilização (custopara comunicação de voz), os quais influenciam indiretamente para maior penetração docelular como meio para acessar e baixar aplicativos da Internet, assim como, da utilizaçãodos diferentes conteúdos e serviços de comunicação móvel de dados.

A realização da pesquisa qualitativa permitiu uma melhor compreensão sobre opúblico alvo da pesquisa e das hipóteses formuladas. Por exemplo, inicialmente, acreditou-se que o custo do tráfego de dados era o único responsável por restringir o acesso asredes e serviços de comunicação de dados no celular, entretanto, a pesquisa qualitativa,em conjunto com a quantitativa, mostrou e enriqueceu essa visão sobre o problemainvestigado.

Ademais, a pesquisa permitiu que todas as decisões tomadas durante a concepçãodo produto DemoTool, ainda em fases de análise, tivessem um embasamento, em vezde serem tomadas a partir de opiniões pessoais. Esta mesma compreensão elevou onível dos nossos testes e procedimentos de avaliação, uma vez que nossos requisitosapresentaram-se melhor descritos e compreendidos.

6.2 Contribuições

A principal contribuição dessa dissertação para a literatura se dá através do estudo dasprincipais tecnologias existentes no mercado de celular, das áreas da Engenharia deSoftware e Computação Móvel, no contexto da mudança de paradigma no ecossistema daindústria de celular, bem como, da implementação e aplicação da ferramenta DemoTool,como ferramenta de reuso de aplicativos aplicada para o desenvolvimento de software decelular.

A ferramenta DemoTool permite ao usuário desenvolvedor integrar exemplos deaplicativos de terceiros, podendo reusar os demos, incorporando em novos projetos da

120

6.3. LIMITAÇÕES

IDE e executá-lo através do emulador da PDC do fabricante. Com isso, pode-se usar aferramenta com propósitos de treinamento com desenvolvedores iniciantes, por exemplo,a fim de obter ganhos do entendimento sobre programação para celular usando a PDCvoltada para Java.

O DemoTool foi integrado na IDE de desenvolvimento Motodev Studio for Java, dofabricante Motorola,Inc., recebendo destaque no seu site MOTODEV (developer.motorola.com), voltado para a comunidade de desenvolvedores da PSC da Motorolae disponibilizado para download com abrangência internacional.

O processo de desenvolvimento vivenciado no estudo de caso permite compreenderas principais dificuldades dos desenvolvedores iniciantes, bem como, as problemáticasexistentes na área, servindo como um case para entendimento, principalmente das fasesde implementação e testes. Sugere-se utilizá-lo quando o propósito for reusar aplicativosde terceiros.

A pesquisa de campo realizada contribui para confirmar a tendência de que o celularestá sendo usado para acessar aplicativos e serviços de dados na Internet. Os dadoscoletados podem ser usados por empresas do setor, bem como, pela comunidade científica,a fim tomar decisões ou complementar a pesquisa.

6.3 Limitações

Além das limitações dos estudos, já abordados no capítulo anterior, destacamos ainda asseguintes limitações:

• Utilização e acompanhamento da ferramenta DemoTool por desenvolvedores nocontexto de fábrica de software;

• Desenvolvimento e reuso de demos de aplicações quaisquer;

• Desenvolvimento de aplicativos sem reuso;

• Utilizar ferramentas relacionadas realizando comparações de funcionalidades;

• Estudos com maior ênfase nas fases do desenvolvimento de Assinatura e Dis-tribuição;

• Publicar o aplicativo desenvolvido em portais dos fabricantes e acompanhar aquantidade de downloads tentando obter feedback de usuários.

121

developer.motorola.com

developer.motorola.com

6.4. TRABALHOS FUTUROS

6.4 Trabalhos Futuros

No decorrer do desenvolvimento desta dissertação, surgiram várias idéias que não forampercorridas, mas que se sugere dar continuidade, pois pode-se cobrir boa parte daslimitações anteriormente descritas. Destacamos as seguintes:

• Verificar a aplicabilidade do DemoTool em laboratório de programação de umainstituição de ensino superior para estudantes de programação;

• Verificar o uso do DemoTool para reuso de aplicações demos no contexto deaprendizado do desenvolvimento de projetos de software para celular;

• Verificar o nível de relevância do DemoTool para reuso de aplicações e o grau desatisfação dos usuários;

• Validar se o reuso de aplicativos demos quaisquer e específicos, permite facili-tar a compreensão do desenvolvimento de software para celular do iniciante deprogramação e engenheiros profissionais;

• Verificar o reuso de aplicativos demos, através do DemoTool e ferramentas cor-relatas, acelera o tempo de desenvolvimento do projeto de software de celular,diminuindo seu custo.

• Realizar pesquisas de campo com usuários que realizaram downloads de aplicativosespecíficos nos portais de distribuição dos fabricantes.

• Desenvolver a solução do servidor de compartilhamento de aplicações demos (videCapítulo 1.2, Seção 4.2.2), disponibilizado via portal do fabricante, permitindo ainserção e descoberta de aplicativos de terceiros de todas as partes, entendendo oDemoTool para encontrar as aplicações do portal;

• Avaliar a interação Desenvolvedor e Fabricante de Celular apontando pontos fracose fortes para ambos os atores envolvidos;

• Realizar um experimento empírico controlado para avaliar melhor o impacto daferramenta.

Não obstante, usar o DemoTool para realizar novos projetos de software para celular,tende a influenciar a escolha do desenvolvedor inspirada no conjunto de demos existentese não o contrário, ou seja, os demos exercem forte influência nos novos projetos. Se

122

6.4. TRABALHOS FUTUROS

não tiver um demo que possa atender a necessidade do problema, o seu uso tende a nãoser utilizado. Novas investigações podem partir desse ponto de raciocínio para futurasanálises com usuários.

Portanto, esse trabalho apresenta uma solução para o problema da compreensão dodesenvolvimento de software para celular, através do reuso de aplicações bem projetadase integração amigável em ambiente de desenvolvimento.

123

Referências Bibliográficas

Abrahamsson, P., Salo, O., Ronkainen, J., and Warsta, J. (2002). Agile software develop-ment methods. Relatório Técnico, Finlândia. 3.2

ANATEL (2009). Telefonia celular alcança 159,6 milhões de assinantes emjunho. Agência Nacional de Telecomunicações (ANATEL), Notícia em por-tal: http://www.anatel.gov.br/Portal/exibirPortalNoticias.do?acao=carregaNoticia%codigo=18577. 1.1, 1.2.1, 8

Augustin, I. (2004). Abstrações para uma linguagem de programação visando aplicações

móveis em um ambiente de Pervasive Computing. Ph.D. thesis, Universidade Federaldo Rio Grande do Sul. Curso de Pós-Graduação em Ciência da Computação. 1.2.5, 2.1

Batista, V. B. (2008). SPONTANEOUSWARE: Um Framework de Middleware para

Redes Móveis Ad Hoc. Master’s thesis, Universidade Federal de Pernambuco. 2

Becher, M., Freiling, F. C., and Leider, B. (2007). On the effort to create smartphoneworms in windows mobile. In Proc. IEEE SMC Information Assurance and Security

Workshop IAW ’07, pages 199–206. 2.3.3

Bergey, J., Clements, P., Cohen, S., Donohoe, P., Jones, L., Krut, B., Northrop, L.,Tilley, S., Smith, D., and Withey, J. (1998). Product line practice workshop report.Technical Report CMU/SEI-98-TR-007, Software Engineering Institute, CarnegieMellon University. 3.1

Booch, G., Rumbaugh, J., and Jacobson, I. (2005). Unified Modeling Language User

Guide, The (Addison-Wesley Object Technology Series). Addison-Wesley Professional.4.2.4

Bourque, P. and Dupuis, R. (2004). Guide to the software engineering body of knowledge2004 version. Guide to the Software Engineering Body of Knowledge 2004 SWEBOK,1(1), i–D–7. 3.1

Brookshear, J. G. (2000). Ciência da computação: uma visão abrangente. Bookman,Porto Alegre, 5 edition. 3.1

Canalys (2008). Global smart phone shipments rise 28 Canalys press release,http://www.canalys.com/pr/2008/r2008112.htm. (document), 2.1, 2.2, 2.3.5

124

REFERÊNCIAS BIBLIOGRÁFICAS

CESAR (2009). Faq (institucional). C.E.S.A.R Centro de Estudos e Sistemas Avançadosdo Recife, http://www.cesar.org.br/node/29. 4.2.1

Cho, Y. C. and Jeon, J. W. (2007). Current software platforms on mobile phone. InProc. International Conference on Control, Automation and Systems ICCAS ’07, pages1862–1867. (document), 1.1, 2.2, 2.2, 2.3, 2.3.1, 2.3.1, 2.3, 2.4, 2.3.1, 2.3.2, 2.3.2, 2.5,2.6, 2.3.2, 2.3.5, 2.4, 3.2, 3.5, 3.5.2, 5.1.3, 6.1

Coverity (2006). Symbian case study. Coverity,http://www.coverity.com/casestudies/symbian.html.2.3.1

e G. Yuki, Y. N. (2004). Wireless firms look at phones as limitless. The Washington Post,Fev. 2004. 1.2.3

Economou, D., Gavalas, D., Kenteris, M., and Tsekouras, G. (2008). Cultural applica-tions for mobile devices: Issues and requirements for authoring tools and developmentplatforms. (document), 3.3, 3.4, 3.4, 3.5.2, 3.2, 3.6

Fernandes, A. A.; e Teixeira, D. S. (2007). Fábricas de Software: implementação e gestão

de operações. Atlas, São Paulo, 3 edition. 3.1, 3

Flick, U. (2004). Uma introdução à pesquisa qualitativa. Porto Alegre: Bookman. 5.2.2,5.2.3

Fulgoni, G. (2008). Online is the new primetime. Web site comScore, Inc.http://www.comscore.com/PressEvents/PresentationsW hitepapers/2008/OnlineistheNewPrimetime/.1.1

Gallardo, D. (2002). Desenvolvendo plug-ins do eclipse: Como criar, depurar e instalar seuplug-in. http://www.ibm.com/developerworks/br/library/os-ecplug/. (document), 4.2.5,4.6

Gillespie, T. (2004). Copyright and commerce: The dmca, trusted systems, and thestabilization of distribution. The Information Society, 20(4), 239–254. 14

Gressgård, L. J. and Stensaker, I. (2006). The mobile service industry: strategic challengesand future business models. IJMC, 4(5), 509–531. 1.2.2

Heikkinen, M. T. and Still, J. (2008). Benefits and challenges of new mobile servicedevelopment in R&D network. Personal and Ubiquitous Computing, 12(1), 85–94. 3.3

125


ISAM, P. (2007). Definição de computação móvel projeto. ISAM- Infraestrutura de Suporte às Aplicações Móveis Distribuídas,http://www.inf.ufrgs.br/ isam/paginaDefComputacaoMovel.html. 2.1

Jarvenpaa, S. L., Lang, K. R., Takeda, Y., and Tuunainen, V. K. (2003). Mobile commerceat crossroads. Commun. ACM, 46(12), 41–44. 1.2.2

Junquera, R. A. and Gnius, J. (2005). Serviços de valor adicionado nas redes móveislatino-americanas. Technical report, Tele-Semana e Signals Telecom Consulting. 1.2.1,1.2.1.1, 1.2.1.1, 1.2.1.2, 1.2.1.3, 2.3.6, 3.2, 5.1.3

Karvonen, J. and Warsta, J. (2004). Mobile multimedia services development: value chainperspective. In MUM ’04: Proceedings of the 3rd international conference on Mobile

and ubiquitous multimedia, pages 171–178, New York, NY, USA. ACM. 3.1, 3.3

Keogh, J. (2003). J2ME: the complete reference. Osborne. (document), 2.3.6, 2.10

Kotonya, G. and Sommerville, I. (1998). Requirements engineering. Wiley Chichester.4.2.3

Kurkovsky, S. (2009). Engaging students through mobile game development. In SIGCSE

’09: Proceedings of the 40th ACM technical symposium on Computer science education,pages 44–48, New York, NY, USA. ACM. (document), 3.1, 3.1, 3.4, 3.2, 5.1.3

Lee, Y. E. and Benbasat, I. (2003). Interface design for mobile commerce. Commun. ACM,46(12), 48–52. 1.2.2

Loureiro, A., Sadok, D., Mateus, G., Nogueira, J., and Kelner, J. (2003). Comunicaçãosem fio e computação móvel: Tecnologias, desafios e oportunidades. In Congresso da

Sociedade Brasileira de Computação, Campinas, São Paulo. (document), 1.1, 2.1, 2.3.6,3.1, 3.1, 3.3, 3.3, 3.4, 3.5, 3.2, 5.1.2, 5.1.3

Marconi, M. and Lakatos, E. (2003). Fundamentos de metodologia científica. 5.2.2, 5.2.3

Mayring, P. (2002). Introdução à Pesquisa Social Qualitativa. Uma introdução para pensar

qualitativamente, volume 5a. Weinheim: Beltz. 5.2.3

Miner, R. (2008). Android: Building a mobile platform to change the industry. ComputerSystems Colloquium (EE 380),http://www.youtube.com/watch?v=WUrMI9ZGxQ8. 1.1

126


Morimoto, C. E. (2009). Smartphones, Guia Prático. GDH Press e Sul Editores, 1 edition.(document), 1.1, 1.2.4, 2.1, 2.1, 2.2, 2.2, 2.3.1, 2.3.1, 2.3.2, 2.3.2, 2.3.2, 2.3.3, 2.7, 2.3.3,2.3.4, 2.8, 2.3.4, 2.3.5, 2.9, 2.3.5, 2.5, 3.1, 3.5, 5.1.3

Motorola (2009). Get started with motodev studio for java me. 3.5.3

Muchow, J. (2001). Core J2ME technology and MIDP. Prentice Hall PTR Upper SaddleRiver, NJ, USA. (document), 2.3.6, 2.10

Muoio, K. (2009). Key trends in mobile content usage & mobile advertising.http://www.comscore.com/PressEvents/PresentationsW hitepapers/2009/.1.2.4

NEMI (2002). In search of the perfect bill of materials(bom). National Electromnics Manufacturing Inititative Inc.,http://thor.inemi.org/webdownload/newsroom/Articles/BoMwhitepaper.pdf. 6

Neufeld, B. J. . E. (2009a). The next big things: Mobile in-ternet & applications - gaining momentum. comScore Webinar,http://www.comscore.com/layout/set/popup/request/Presentations/. (document),1.2.2, 1.2.2, 1.2.2, 1.2, 5.1.2

Neufeld, E. (2009b). Wired: Connecting to themobile marketing revolution. comScore Mobile,http://www.comscore.com/PressEvents/PresentationsW hitepapers/.(document),2.1

Nokia (2008). Java me development/midp basics. Nokia,http://sw.nokia.com/id/0265fd77-4a28-4bb7-b466-8a0430651862/JavaMEDevelopmentT rainingCoursev10en.pd f .2.3.6,3.2

Oliver, E. (2008). A survey of platforms for mobile networks research. SIGMOBILE Mob.

Comput. Commun. Rev., 12(4), 56–63. (document), 1.1, 2.2, 2.2, 2.3.1, 2.3.3, 2.3.4, 2.3.5,2.4, 2.5, 2.5, 2.3, 6.1

Passos, M. J. d. S. (2006). Análise de software educativo multimédia : um estudo sobre a

morfofisiologia dos sistemas humanos. Master’s thesis, Universidade do Minho. Disser-tação de Mestrado em Educação - Área de especialização : Supervisão Pedagógica emEnsino das Ciências. 5.1.2

Pressman, R. (1995). Engenharia de Software; tradução José Carlos Barbosa dos Santos.São Paulo: Makron Books. (document), 3.1, 3.1, 4.2.3, 4.2.4, 4.2.6, 5.1.2

127


Pressman, R. and Ince, D. (2005). Software engineering: a practitioner’s approach.McGraw-Hill New York. 4.2.4

Quintella, H. and Rodrigues, S. (2005). Fatores críticos de sucesso para o lançamento deserviços de comunicação móvel de dados. Relatórios de Pesquisa em Engenharia de

Produção, 5(20), 1–16. 1.2.1, 1.2.1, 1.2.3, 5.2.2, 5.2.3

Sami, Z. (1998). Software process improvement, practical guidelines for business success.3.1

Sangiovanni-Vincentelli, A. and Martin, G. (2001). Platform-based design and softwaredesign methodology for embedded systems. IEEE Design Test of Computers, 18(6),23–33. 2.2

Schiavo, G. (1958). Antonio Meucci: inventor of the telephone. Vigo Press. 2.1

Siau, K., Sheng, H., Nah, F. F.-H., and Davis, S. A. (2004). A qualitative investigation onconsumer trust in mobile commerce. IJEB, 2(3), 283–300. 1.2.2

Silberschatz, A., Galvin, P., Gagne, G., and Silberschatz, A. (1988). Operating system

concepts. Addison-Wesley New York. 1

SunMicrosystems (2009). Sobre o java. http://java.com/ptBR/about/.2.3.6

Symbian (2008). What is symbian signed? https://www.symbiansigned.com/app/page/overview/faq.3.2, 5.1.3

Tarnacha, A. and Maitland, C. F. (2006). Entrepreneurship in mobile application devel-opment. In ICEC ’06: Proceedings of the 8th international conference on Electronic

commerce, pages 589–593, New York, NY, USA. ACM. 1.2.2, 2.3.6, 3.1, 3.1, 3.1, 5.1.3

Taylor, E. S. (1959). An interim report on engineering design. Technical report, Mas-sachusetts Institute of Technology. 4.2.4

Teleco (2009a). Apple (seção: Teleco world). http://www.teleco.com.br/vendors/apple.asp.1.2.4

Teleco (2009b). Crescimento do celular em jun/09. http://www.teleco.com.br/ncel.asp.1.2.1, 1.2.1.1, 4

Teleco (2009c). Motorola (seção: Teleco world).http://www.teleco.com.br/vendors/motorola.asp. 1.2.4

128


Teleco (2009d). Nokia (seção: Teleco world). http://www.teleco.com.br/vendors/nokia.asp.1.2.4

Teleco (2009e). Rim (seção: Teleco world). http://www.teleco.com.br/vendors/RIM.asp.1.2.4

UNCTAD (2007). United nations conference on trade and develoment (unctad). In Informa-

tion Economy Report 2007-2008, page 386. United Nations Publications. Digital Library.1.1, 8

Verkasalo, H. (2009). Open mobile platforms: Modeling the long-tail of application usage.In Proc. Fourth International Conference on Internet and Web Applications and Services

ICIW ’09, pages 112–118. 1.1, 1.2.1, 2.2, 2.2, 2.3, 2.3, 5.2.1, 5.2.4, 5.2.4, 5.2.4

Yamakami, T. (2005). Mobile application platform strategies: business model engineeringfor the data intensive mobile age. In Proc. International Conference on Mobile Business

ICMB 2005, pages 333–339. 1.1, 1.2.1, 2.2

Yamim, A. C. (2004). Arquitetura para um Ambiente de Grade Computacional Direcionado

às Aplicações Móveis, Distribuídas e Conscientes do Contexto da Computação Pervasiva.

Ph.D. thesis, Instituto de Informática/UFRGS, Porto Alegre. 2.1

Yin, R. K. (1994). Case study research: design and methods. Sage, Thousand Oaks, CA.4.3.1

Zhai, S., Kristensson, P. O., Gong, P., Greiner, M., Peng, S. A., Liu, L. M., and Dunnigan, A.(2009). Shapewriter on the iphone: from the laboratory to the real world. In CHI EA ’09:

Proceedings of the 27th international conference extended abstracts on Human factors in

computing systems, pages 2667–2670, New York, NY, USA. ACM. 2.3.4

Zhang, Y., Duan, X., Wang, J., and Zhang, L. (2008). Design and implementation of wirelessmonitoring system based on windows mobile. In Proc. 4th International Conference on

Wireless Communications, Networking and Mobile Computing WiCOM ’08, pages 1–4.1.2.1, 2.3.3, 2.3.3

Ziv, N. D. (2005). Toward a new paradigm of innovation on the mobile platform: redefiningthe roles of content providers, technology companies, and users. In Proc. International

Conference on Mobile Business ICMB 2005, pages 152–158. (document), 1.1, 1.2.1,1.2.3, 1.2.4, 1.2.5, 1.5, 2.2, 2.2, 2.3, 4.1, 5.2.1, 6.1

129


Ziv, N. D. and Mulloth, B. (2007). The evolution of a mobile services provider in a globalcontext: Upoc as a case in point. In Proc. International Conference on the Management

of Mobile Business ICMB 2007, page 18. (document), 1.1, 1.2.1, 1.2.3, 1.2.5, 1.5, 2.2,2.3, 2.3, 2.3.5, 4.1, 4.1, 5.1.2, 5.2.1, 6.1

130

AApêndice A: Bibliotecas de Java ME

a) JSR-234: Advanced Multimedia Supplements for J2ME- versão parcialmente imple-mentada;

b) JSR-82: Bluetooth API 1.0 (incluindo Push e Obex suporte);c) JSR-75a: FileConnection Optional Package 1.0;d) JSR-75b: Personal Information Management (PIM) Optional Package;e) JSR-172: J2ME Web Services API;f) JSR-139: Java Connected Limited Device Configuration 1.1;g) JSR-118: Java Mobile Information Device Profile 2.0;h) JSR-185: Java Technology for the Wireless Industry 1.0;i) JSR-179: Location API for J2ME;j) JSR-184: Mobile 3D Graphics API for J2ME;k) JSR-135: Mobile Media API 1.1;l) JSR-226: Scalable 2D vector graphics;m) JSR-177: Security and Trust Services API for J2ME;n) JSR-180: SIP API for J2MEo) JSR-205: Wireless Messaging API 2.0p) JSR 211: Content Handler APIq) JSR 229: Payment APIr) JSR 238: Mobile Internationalization APIs) JSR 239: Java Binding for OpenGL ES APIt) JSR 248: Mobile Service Architectureu) JSR 256: Mobile Sensor APIv) JSR 280: XML API for Java ME

Detalhes de cada API podem ser consultados no site da Java Community Process:http://www.jcp.org.

131

http://www.jcp.org

BApêndice B: Questionário de Pesquisa

132

CApêndice C: Resultado da Pesquisa

Resultados da pesquisa sobre a oferta de dados para celulares no Brasil (Julho/2009)

135

DApêndice D: Respostas Relevantes da

Pesquisa Qualitativa

“10) Acreditamos que a oferta de dados para os celulares irá aumentar de forma sig-nificativa quando os custos de transmissão de dados se aproximarem do modelo doscomputadores pessoais com acesso a Internet. Qual a sua opinião a respeito?”.

Usuário 04 “. . . Concordo, mas alem do custo, a interface do celular nao é adequada

para a navegação de forma adequada; ela vale para pequenos recados, mensagens, mas

nao a acho agradavel para aplicaçoes maiores”.Usuário 11 “. . . A oferta de aplicativos para celulares á alta. O que é baixo é o poder

aquisitivo dos consumidores diante dos altos preços dos aparelhos compatíveis. Um

bom “smartphone"custa no mínimo R$ R1300,00. Veja o caso do Iphone. A oferta de

aplicativos é muito alta e o preço de cada aplicativo é baixo ou mesmo zero. O problema

é adquirir um Iphone no Brasil! Para pagar R$ 1000,00 por este aparelho, o consumidor

precisa pagar uma franquia de R$ 150,00 por pelo menos 12 meses. Isso é muito caro

perto do preço do serviço de dados em si e dos aplicativos ”.Usuário 16 “. . . Concordo, porém acho utópica essa visão da aproximação real da

banda larga, acredito sim que a redução dos custos de pacotes de dados reflitam em um

maior interesse e utilização dos serviços que hoje são bastante caros, por exemplo, pacote

de 1Gb celular TIM custa R$70 mensais, o que é um absurdo e completamente fora da

realidade para a maioria das pessoas que desejariam usar os recursos disponíveis.”.Usuário 41 “. . . Concordo em partes, a oferta irá aumentar sim, com mais aplicativos

e conteúdos produzidos exclusivamente para celular. No entanto, no ritmo tecnológico

em que o celular vem se desenvolvendo, acredito que com o passar do tempo, quase

nenhuma distinção será feita entre conteúdo para celular e conteúdo para desktop. Já

tenho um browser no celular (Opera) que interpreta tanto páginas web feitas para celular

137

quanto as feitas para browsers desktop.”.Usuário 42 “. . . Discordo dessa afirmação. Atualmente a internet móvel pode ser

usada tanto via celular, quanto celular + laptop, além de modem + laptop, e os custos

estão reduzidos. Na minha opinião, a baixa oferta de aplicações realmente úteis é o

fator limitante. Vide a quantidade de aplicações de todos os gêneros disponíveis para

palmtops (em especial PalmOS), já a muitos anos no mercado, é infinitamente superior à

oferta de aplicações para celulares/smartphones, apesar da popularização de celulares

symbian.”.Usuário 54 “. . . Não basta apenas baratear o custo da transmissão de dados, é

preciso também tornar o valor dos aparelhos 3G mais acessivel.”.Usuário 78 “. . . Os custos de transmissão/recepção de dados em redes celulares

sempre serão maiores do que os custos em redes fixas, pois a largura de banda das

primeiras é um recurso escasso. . . . ”.Usuário 80 “. . . Concordo. Além disso os modelos adotados pela Apple (iTunes) e

Google (Android Market) de lançarem aplicações (jogos, utilitários) de baixo custo irão

atrair cada vez mais consumidores. Mas por lado isso demandará um aumento gigantesco

da infra-estrutura (Celular, Wi-Fi, Wi-MAX) pois na atual situação existe um limite para

o número de usuário conectados ao mesmo tempo. É preciso que o governo interfira de

alguma forma barateando os custos de implamantação dessa infra-estrutura.”.Usuário 98 “Concordo a respeito, pois sabemos que vivemos num país, isso se

referindo específicamente ao Brasil, onde a maioria da população não é de classe alta.

Sendo assim, a redução desse custo irá atrair mais essa camada social para esse tipo

de serviço o que pode propocionar uma grande proliferação de aplicativos dos mais

diversos para celulares.”.

138

EApêndice E: Contexto de Uso

Tabela E.1 Popularidade e contextos de uso do celular nos EUA em 2009 (comScore)Ranking Atividade quatd. usuários % usuários % crescimento

Mercado Total 230,000,000 5.0 %1 Enviar SMS 131,850,414 57.3% 25.7%2 Tirar fotos 102,637,691 44.6% 27.5%3 Mídias Celular (MC) 81,197,792 35.3% 30.1%4 Usando serviços da rede 131,850,414 57.3% 25.7%

para enviar fotos/vídeos5 Enviar foto diretamente 64,836,829 28.2% 46.6%

para outro celular6 Mudar o tipo de toque 64,006,803 27.8% 23.4%

(ringtone) padrão7 Propaganda por SMS 57,372,866 24.9% 36.4%

(num. recebido/mês)8 Mudar tema padrão 57,181,097 24.9% 33.0%9 Jogando games 56,325,549 24.5% 19.6 %

10 Mudar tema padrão 55,347,818 24.1% 22.4%com câmera

11 Lendo notícias/informações 45,909,797 20.0% 59.7%via browser

12 Transferindo fotos 45,874,895 19.9% 48.0%para o PC

13 Filmando com 40,872,968 17.8% 54.5%câmera de vídeo

14 Acessando e-mail 40,710,038 17.7% 54.2%(trabalho ou pessoal)

15 Enviando foto por e-mail 39,514,195 17.2% 55.1%

139

FApêndice F: Requisitos do DemoTool

Legenda: Requitos Funcionais (RF); Requisito Não Funcionais (RNF).

• [RF-1] O DemoTool deve mostrar as informações do demo MIDlet: O sistemaprecisa mostrar todas as informações sobre a suíte de MIDlet, tais como: screen-shots do aplicativo MIDlet; o nome, o tamanho, nome do distribuidor, lista deMIDlets (quando tiver mais um MIDlet na mesma suíte); exibir informações doperfil/configuração do aplicativo; e as bibliotecas (APIs) utilizadas;

• [RF-2] O DemoTool permite filtrar os demos: o sistema permite o usuário filtraros demos que estão sendo oferecidos pelos seguintes critérios: por APIs e porfuncionalidades (touchscreen e push);

• [RF-3] Permitir importar demos para dentro do workspace da IDE : o sistemaprecisa prover um mecanismo para o usuário importar os demos para dentro daIDE. Em seguida, permitir o usuário rodar e/ou modificar o aplicativo;

• [RF-4] Permite executar um MIDlet Suite da GUI: a aplicação precisa prover umaforma para o usuário poder executar o demo pela interface gráfica de usuário.

• [RNF-1] Usabilidade: a aplicação precisa considerar uma interface gráfica deusuário de acordo com os padrões das ferramentas existentes no Motodev Studiofor Java, ao mesmo tempo em que, ilustra de maneira simples e didática, os recursosque cada demo possui, diminuindo a quantidade de cliques para acessar os recursospropostos;

• [RNF-2] Integração e Performance: a aplicação precisa ser integrada no ambienteMotodev Studio for Java e executar com a performance de acordo com os padrõesestabelecidos pelo sistema como um todo.

140

“DemoTool: ferramenta integrada em Plataforma de ... · celulares, sustentado pelas operadoras de...

Documents

Transcript of “DemoTool: ferramenta integrada em Plataforma de ... · celulares, sustentado pelas operadoras de...