Análise da Fase 2

A Fase 2 é caracterizada pelos procedimentos envolvidos com a implementação do código até a sua finalização. A Tabela5.3, aresenta os pontos identificadas na fase de Codificar e Construir. O PEv-04 atesta a utilização da ferramenta DemoTool como suporte para escolher um demo existente, a fim de reusar uma infra-estrutura de código inicial, para economizar custos de tempo, bem como, de assimilação do processo.

Tabela 5.3 Pontos de Evidência identificadas na fase Codificar e Construir

Pontos Descrição

PEv-04 Reuso de código é uma prática utilizada

PEv-05 Exemplos de terceiros são fortemente analisadas PEv-06 Ferramentas de depuração de código são empregadas

PEv-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 de desenvolvimento (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 de software para celular.

Embora um aplicativo de terceiro tenha sido escolhido e reusado, há necessidade de validação, por parte do desenvolvedor, das funcionalidades e contextos de utilização do 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, sempre haverá necessidade de análise técnica profunda a fim de garantir as funcionalidades. Esse

5.1. ANÁLISE E RESULTADOS DO ESTUDO DE CASO

ponto-chave requer bastante esforço do desenvolvedor. No entanto, com as ferramentas de depuração presentes na IDE (PEv-06), esse trabalho de análise é facilitado e o tempo reduzido. Neste trabalho, abordamos a importância de mecanismos de depuração nos req- uisitos desejáveis para ferramentas de desenvolvimento (Capítulo3, Seção3.4, requisito 8).

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, pois eventualmente bugs são encontrados na fase seguinte, de testes, e ajustes são necessários no 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 Desenvolvimento de Celular (PDC) (apresentadas no Capítulo2e Capítulo3, respectivamente), existem várias incompatibilidades que normalmente poderiam ser melhor tratadas através do uso de tratamento de exceções (PEv-13). Essa realidade foi confirmada, sendo necessário re-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.4ilustra os PEv confirmados na fase de Testes.

Tabela 5.4 Pontos de Evidência identificadas na fase de Teste

Pontos Descrição

PEv-07 Emuladores cumprem bem o papel de testar aplicativos PEv-09 Ocorrem várias instalações do aplicativo em celulares-alvos PEv-10 Problemas comuns acontecem durante a execução no celular-alvo PEv-11 Existem limitações no celular que induzem o pensamento por

erros de código PEv-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 a proposta de testar e simular o game durante o seu desenvolvimento. A experiência foi satisfatória de acordo com as comparações dos SDKs (vide Capítulo3, Tabela3.2).

Durante a fase de Testes, foi confirmado o fato de ocorrerem várias instalações nos celulares-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 e testado no celular real. Embora, essa afirmação não possa ser provada devido a exemplos vivenciados nas práticas de desenvolvimento para celular, conforme podemos perceber emCho and Jeon(2007);Morimoto(2009), pois existem diferentes implementações das PDC, bem como, das PSC.

5.1. ANÁLISE E RESULTADOS DO ESTUDO DE CASO

Além disso, confirmou-se que o PEv-10 é verdadeiro, ou seja, as funcionalidades do jogo voltados para vários celulares-alvos é uma tarefa bastante custosa. Os dados da literatura 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 o início sempre ocorreram conforme esperado. Entretanto, quando o aplicativo foi testado em 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, pois projetar 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 seja reproduzir 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 seguem especificaçõ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 entre si. Desta forma, um aplicativo que roda no simulador da Motorola, pode não rodar no telefone 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 o pensamento 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 as APIs corretamente para utilizar determinados recursos? Consequentemente temos várias tentativas e repetições da fase Codificar e Construir e fase de Testes, destacado pelo PEv-14.

As situações indicadas pelos PEv-11 e PEv-14, fazem com que o desenvolvedor tente reproduzir os problemas vivenciados utilizando o recurso da PSC, tal como a depuração sobre o celular-alvo (PEv-17). Esse recurso é o mais indicado, pois permite reproduzir o software no ambiente real do hardware da PSC. Entretanto, diversas tecnologias impõem diferentes restrições, bem como, a curva de aprendizado é alta. Existem documentações té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 tantos acessos pela Internet aos portais focados para desenvolvedores.

Constatou-se que na Fase de Assinar (vide Tabela5.5), obteve-se um único ponto chave (PEv-08), pois nesta fase não havia a preocupação (contexto do estudo de caso)

5.1. ANÁLISE E RESULTADOS DO ESTUDO DE CASO

Tabela 5.5 Pontos de Evidência identificadas na fase Assinar

Pontos Descrição

PEv-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 certificadas visando obter garantias pelo fabricante, objetivando maior compatibilidade dos celulares comercializados pela operadora.

Entretanto, diante da atual oferta de dados (Seção 1.2.2), muitas aplicações estão sendo ofertadas (principalmente jogos), sem a necessidade de assinatura, pois as PSC não impedem a execução dos programas. A certificação, por outro lado é uma garantia do fabricante que o software funciona no celular de forma segura, bem como, para tentar revolver problemas tais como os mencionados pelo PEv-10.

Tabela 5.6 Pontos de Evidência identificadas na fase Distribuir

Pontos Descrição PEv-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 Tabela5.6), se caracterizou por investigações para tentar entender a razão pela qual o aplicativo desenvolvido somente executava no modelo de PSC Symbian. Após essa investigação procurou-se distribuir o aplicativo em algum canal de distribuição existente.

Embora tecnicamente o game estivesse pronto para distribuição, não havia respostas para justificar o problema de não funcionar nos telefones reais testados (exceto Nokia N95). 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 realizar depuração nas outras PSC testadas (PEv-16). Não era desejado distribuir o aplicativo sem compreender a causa, pois assim a portabilidade ficaria prejudicada, tornando o jogo restrito para PSC Symbian somente. Embora, o PEv-20 comprovou que existem vários opçõ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 portal escolhido (OVI da Nokia).

5.1. ANÁLISE E RESULTADOS DO ESTUDO DE CASO

Tabela 5.7 Pontos de Evidência identificadas na fase Pós

Pontos Descrição

PEv-18 Compatibilidades são confirmadas via testes do aplicativo nos celulares-alvos

PEv-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 vivenciados no experimento deste estudo de caso.

O PEv-18 confirmou o problema após testes de depuração diretamente na PSC dos celulares-alvos, permitindo determinar que a compatibilidade do game Mobile Piano Learning somente roda sobre PSC Symbian. Conformou-se ainda, que para garantir compatibilidades de outras plataformas não testadas, tais como as citadas no Capítulo2, 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 escolha interessante (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ão distribuir 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 Figura5.2ilustra 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),

5.1. ANÁLISE E RESULTADOS DO ESTUDO DE CASO

enquanto o outro apresenta o percentual observado em cada fase do processo (b). Considerando o gráfico da Figura5.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% das evidências, o que nos diz que fases antecedentes são atividades que requerem atenção do desenvolvedor, podendo desencadear bastante tempo, uma vez que, são nas fases iniciais que existem preocupações como a coleta de dados, identificação de requisitos, seguido por 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 PDC em momento de implementação. Pode-se confirmar que as práticas de reuso (através do DemoTool), permitiram desenvolver um game sem no entanto, ter que iniciar a codificação do zero. Partiu-se do aplicativo reusado e adaptou-se para uma realidade semelhante. Embora neste caso, o aplicativo ficou limitado ao cenário original (uma aplicação para demonstrar o uso da JSR-135), permitindo tocar sons de piano. Pode-se dizer 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íveis nas PDC (PEv-06), no qual são bem utilizadas. Porém, atividades nesta fase são repetidas vá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á certeza que o software irá se comportar nos celulares-alvos das PSC, tal como se comportou na simulação pelo emulador do fabricante da PDC. Assim, são requeridos esforços para testar o aplicativo também nos celulares-alvos (PEv-17).

A fase de Assinar, não se confirmou no desenvolvimento apenas como um passo opcional, tal como se apresenta na literatura (vide ciclo de desenvolvimento de Assinar Seção3.2), mas principalmente, por não ser uma prática necessária (PEv-08) frente ao novo paradigma da oferta de dados (vide Seção1.2.5).

Neste sentido, apresentam-se agora outros canais de distribuição e de comunicação na indústria de celular, tal como OVI (fabricante), e até mesmo em portais de conteúdos diversos para distribuir as aplicações. Antes, o controle da oferta de dados se dava pelas operadoras, que exigiam aplicações certificadas, agora, os aplicativos podem ser ofertados/distribuidos em qualquer repositório pela Internet, sem a intervenção das

5.1. ANÁLISE E RESULTADOS DO ESTUDO DE CASO

operadoras. Essa constatação foi evidenciado em nosso estudo de caso como uma tendência (Figura5.2a).