Aviso de defesa de dissertação de mestrado (CIn/UFPE)

Chegou minha vez de defender, assim, divulgo a todos.

Título: “DemoTool: ferramenta integrada em Plataforma de Desenvolvimento de Software de Celular para Reusar Aplicativos”

Aluno: Douglas Daniel Del Frari
Orientador: Silvio Romero de Lemos Meira
Sergio Soares (UFPE)
Jones Albuquerque (UFRPE)

Data e local: 11 de Setembro de 2009 às 08:15, no Centro de Informática da UFPE (auditório do CIn).

Resumo. Existe uma explosão do uso do celular em quase todos os cantos do mundo. A inovação no setor tem focado sobre o desenvolvimento da infra-estrutura de redes para os telefones celulares, sustentado pelas operadoras de celular, bem como a fabricação de dispositivos liderando o esforço, impulsionadas por seus fabricantes. Por conta das commodities do tráfego de voz, as empresas estão buscando ofertar conteúdos, como aposta de maior lucratividade. O que permite inferir que a tendência da indústria será incrementar o foco sobre a oferta de conteúdos, e o topo disso, é através das Plataformas de Software de Celular (PSC) e o hardware dos fabricantes.

Podemos observar que as empresas envolvidas nesta indústria requerem soluções que explorem novos modelos de negócio, voltado para aplicativos e conteúdos na forma de dados, e que tais soluções, são operacionalizadas através do desenvolvimento de software usando as PSC. As PSC permitem construir e canalizar as ofertas de dados, de acordo com as exigências dos usuários. Contudo, as empresas de mí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. Neste sentido, os desenvolvedores de software precisam se adaptar às diferentes tecnologias das PSC. Por exemplo, elas dão suporte à linguagens de programação diferentes, e por vezes, incompatíveis entre si, dificultando a curva de aprendizado, bem como, restringindo a portabilidade das aplicações produzidas. Além disso, existem muitas restrições que impedem, e dificultam, a manipulação dos recursos do celular usando as bibliotecas de software de programação (API)s. Se por um lado, existem diversas tecnologias das PSC disponíveis aos desenvolvedores, por outro, cada escolha impõe diferentes restrições, tais como: variedade de ambientes de desenvolvimento e incompatibilidade entre si.

A proposta deste trabalho caracteriza-se nas ferramentas de desenvolvimento (SDK), projetadas pela fabricante de celular Motorola, e sua PSC, voltada para o desenvolvimento de aplicativos da linguagem Java. Através da ferramenta proposta DemoTool, objetiva-se alcançar uma redução de esforço de assimilação e compreensão do processo de desenvolvimento de aplicativos para celular, realizado por desenvolvedores de terceiros, através do reuso de aplicativos, bem como, da integração no ambiente de desenvolvimento com PSC do fabricante. Esta dissertação também apresenta um estudo de caso envolvendo o DemoTool, assim como, uma pesquisa de campo com usuários de celular. Com base na análise realizada, DemoTool apresenta indícios de que seja uma ferramenta viável para reusar aplicativos.

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

Desenvolvimento de software para Celular - parte 1

Sempre que vou trabalhar com a disciplina de laboratório de programação (atualmente trabalhando com desenvolvimento de aplicativos para celular), abordo um pouco sobre as problemáticas existentes. Assim, este post objetiva dar uma visão geral sobre isso.

De forma geral, o desenvolvimento de software é um processo de criação de programas para quaisquer dispositivos computacionais, capaz de projetar e produzir tarefas automatizadas, sistematizadas ou pré concebidas, para realização de alguma atividade por meio do uso dos recursos de harware e software existentes.

O processo de desenvolvimento de sofware para celular tende a ser bastante influenciado pelas escolhas das tecnologias utilizadas, desde a Plataformas de Software de Celular (PSC) e dos seus dispositivos-alvos, bem como, de ferramentas de desenvolvimento utilizando tecnologias das Plataformas de Desenvolvimento de Celular (PDC). Podemos citar como exemplos os seguintes casos:

• PSC (ex. Symbian, Windows Mobile, iPhone OS, Android);
• PDC (ex. Java ME, BREW, Flash Lite).

Essencialmente, uma PDC é uma solução tecnológica para garantir compatibilidades
para implementações de software nas PSC. Embora, de maneira geral, portar aplicativos para outras PSC é um processo custoso.

O desenvolvimento de aplicativos para as PSC podem ser divididos de três diferentes formas:

• 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ão dependentes da tecnologia da PSC. Por exemplo, aplicações nativas de Symbian devem usar a linguagem Symbian C++, e o seu conjunto de bibliotecas disponíveis. Em geral, a vantagem é 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 portabilidade e compatibilidade das aplicações desenvolvidas nas diferentes PSC. Por outro lado, existem dificuldades para acessar todos os recursos do dispositivo, uma vez que cada fabricante oferece uma implementação de suporte para a PDC, sensivelmente diferentes ou específicas para um conjunto de hardware de seu portfólio. Isso acaba por restringir as possibilidades que um aplicativo poderia explorar, diante das aplicações nativas. O maior benefício deve-se à boa curva de aprendizado por parte dos desenvolvedores.

As limitações dos navegadores e o tamanho das telas fazem com que a maior parte dos aplicativos intermediários fiquem inutilizáveis. Ou seja, alguns tipos de aplicações como Gmail continuam acessíveis, enquanto que serviços como Google Talk, não.

Já os software que rodam dentro de navegadores (web), são conhecidos como widgets, e podem incluir serviços como Gmail, Meebo, entre outras, e são voltados para as PSC. Alguns exemplos bastante utilizados são widgets para iPhone e Opera Widgets. Os widgets são, em geral, aplicativos simples, que exibem algumas informações específicas. Alguns widgets, embora rodem dentro do navegador, substituem as funções e até mesmo, a aparência de aplicativos nativos, mas não permitem ir muito longe em termos de programação. A principal vantagem é a portabilidade, pois basta o celular ter um navegador compatível. Porém, será necessário conexão com a internet, pois os widgets são projetados para interações com serviços na web. De forma geral, para tarefas mais complexas, a melhor opção é desenvolver um aplicativo nativo.

O desenvolvimento de serviços e aplicações para celular 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 desenvolvimento específicas. Além disso, por conta da grande variedade de dispositivos, há uma grande diversidade de plataformas e, consequentemente, diferentes ferramentas de desenvolvimento.

O desenvolvimento de uma aplicação para celular possui algumas dependências e representa inúmeros desafios para os desenvolvedores. As dependências técnicas existentes são a principal fonte 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ífica de PSC, o dispositivo de celular, além da rede da operadora.

Existem pelo menos três maneiras diferentes para desenvolver aplicativos no celular:

1. via desenvolvimento de códigos nativos da PSC;
2. usando aplicações intermediárias através das PDC;
3. utilizando widgets para rodar pequenas aplicações dentro do navegador do celular.

Além disso, a escolha das tecnologias de PSC, os dispositivos-alvos e a infra-estrutura de rede
da operadora, influenciam positiva ou negativamente no desenvolvimento do software.

Em futuro post, apresentarei o ciclo de desenvolvimento de software para celular.

Uso da Orientação a Objetos com Java nas aplicações Móveis

Programar para celular usando a orientação a objetos pode prejudicar a performance da aplicação? Essa questão me ocorreu alguns anos atrás (2004-2005), quando os celulares eram bem mais limitados do que hoje. Mas a conclusão era que criar muitas classes poderiam prejudicar o desempenho por questões obvias da pouca memória disponível. Hoje no entanto, os celulares já tem mais recursos computacionais. Mas ainda requer cautela ao projetar tais aplicações usando OO para não abusar do bom senso. A menos que não deseje portar tal aplicação para nenhum outro dispositivo além do seu smartphone. :)

Segundo o wikipédia, "A orientação a objetos, também conhecida como Programação Orientada a Objetos (POO) ou ainda em inglês Object-Oriented Programming (OOP) é um paradigma de análise, projeto e programação de sistemas de software baseado na composição e interação entre diversas unidades de software chamadas de objetos."

Um video interessante sobre Orientação a Objetos que recomendaria para curiosos.


Não dá para sair criando muitos objetos como gostaríamos. :( Neste caso, eu penso que é mais vantagem tentar avaliar o custo de memória que sua aplicação tem e o projeto em si.

Mas como faço isso se não conheço muito bem as práticas de otimização? Preciso me tornar um JEDI na programação? A resposta é sim. :) Mas se anime, existe algumas coisas que pode fazer e que pode te ajudar. Um site interessante é: http://mr.dev.mobi

Esse site se propõe a testar sua aplicação para saber se está usando as melhores práticas e padrões da indústria móvel. Tem opções de análises gratuítas. Vale a pena dar uma olhada.

De qualquer forma é preciso usar o bom senso quanto ao projeto orientado a objetos para não prejudicar a performance de sua aplicação móvel. Ainda, tentar testar no celular real e procurar avaliar os resultados. É a melhor coisa a fazer na minha opinião.

Open source e sua influência no desenvolvimento de software – parte 2

No primeiro post desta série falamos sobre o que é open source no contexto da indústria de software. A pergunta principal foi: práticas open source no desenvolvimento de software aumentam a qualidade dos produtos derivados da engenharia de software? A resposta a essa questão ficou longe de se encerrar. Aqui, continuaremos a desenvolvê-la partindo da reflexão acerca dos aspectos da engenharia de software tradicional e compará-lo com algumas práticas open source.

Cenário da guerra do software (open source e sua influência na indústria)

Engenharia de Software Open Source

Desde o seu surgimento, a engenharia de software tem evoluído com o objetivo de construir produtos de maior qualidade, economizando tempo e recursos. Isto não é uma meta fácil de alcançar, pois muitas vezes qualidade está atrelada ao custo. Considerando práticas open source no projeto de software e em relação aos aspectos desejáveis da engenharia de software (otimização de recursos, qualidade e tempo), um projeto Open Source tende a ser organizado em comunidades, influenciando principalmente os seguintes aspectos:

• Minimizar o custo da produção; pois os membros da comunidade geralmente são voluntários e não há limites para a entrada de novos integrantes, o que normalmente, visam obter alta qualidade no produto final, o que leva conseqüentemente, alta qualidade no código produzido. Estando este disponível, pode ser revisado e alterado por qualquer programador, eliminando a dependência de uma empresa detentora da tecnologia que melhore as funcionalidades do software ou corrija os erros;
  
• Variação do tempo de desenvolvimento do software; normalmente os prazos não são bem definidos, pois a maioria do trabalho é voluntária, e dependerá do esforço coletivo e das lideranças envolvidas. No entanto o risco da descontinuidade dos projetos é baixo, pois qualquer desenvolvedor pode assumir e dar continuidade ao projeto [Beline, Menta e Salvi 2005].
  

Através de projetos distribuídos, a Indústria de software encontra dificuldades semelhantes aos projetos Open Source, por exemplo, problemas de comunicação e cultura entre as equipes que estão geograficamente distribuídas. Na tentativa de minimizar estes problemas é possível notar em [Hogan 2000], a importância do uso de ferramentas, tais como programas de mensagens instantâneas, voz sobre IP e vídeo documentação, no intuito de agilizar a comunicação; já para estreitar os laços culturais, foram criados embaixadores que realizavam intercâmbios entre as equipes.

O Source Forge é um exemplo de espaço compartilhado em projetos Open Source, sendo este o maior site mundial de hospedagem, com o objetivo de valorizar a comunidade oferecendo vários serviços e ferramentas web para o desenvolvimento colaborativo de sistema, suporte ao gerenciamento de projetos e downloads, manipulação de conteúdo, banco de dados, controle de versões e mecanismos de hospedagem e divulgação [Parreiras, Silva, Bastos e Brandão 2004].

Observando as diversas áreas da Engenharia de Software é possível estabelecer uma relação com o Open Source, considerando os seguintes pontos:

• Gerência de Projetos: Esta área já vem sofrendo modificações nas empresas que realizam projetos distribuídos, pois elas têm de compartilhar os seus recursos entre os projetos e garantir a entrega de um produto no menor tempo possível, dentro das especificações técnicas e orçamentos esperados para garantir a satisfação do cliente. Como os recursos são limitados, a indústria utiliza técnicas, tal como, a corrente crítica, de forma a não prejudicar o tempo de desenvolvimento do projeto [Quelhas e Barcaui 2005]. Entretanto, técnica como a citada anteriormente é colocada em cheque no Open Source, pois há uma abundância de recursos voluntários, dificultando a gestão tradicional (baseada em comandos e hierarquia) [Soares 2002]. Outro ponto delicado na gestão de um projeto Open Source é no caso dos integrantes da comunidade não aprovarem as decisões tomadas e criarem uma nova comunidade a partir dos códigos fontes já desenvolvidos.
  
• Teste: Esta área, conceitualmente, tem o objetivo de avaliar se o software se comporta conforme a sua especificação, isto é, através de uma execução controlada. Como o software possui características que possibilitam mudanças, aumento de complexidade e intangibilidade, testar torna-se um processo caro e não trivial [Crespo, Silva, Borges e etc 2004]. Porém, nos projetos Open Souce, geralmente, existem menos defeitos que os proprietários e o tempo entre identificar o defeito e repará-los são mais rápidos, ajudando no crescimento da confiabilidade nos projetos [Paulson, Succi e Eberlein 2004].
  

  Requisitos: A Engenharia de Requisitos é uma área da Engenharia de Software focada em analisar e documentar os requisitos, incluindo análise de necessidades e especificação de requisitos. Para isto, são fornecidos mecanismos que facilitam as atividades relacionadas [Lopes, Majdenbaum e Audy 2003] No Open Source, as etapas de elicitação, análise, especificação, validação e comunicação dos requisitos são feitos de maneira informal e sem suporte de notações especificas ou documentação formal. Apesar desta informalidade, os membros da comunidade ao utilizar e-mail, sites, fóruns e diretórios compartilhados de código fonte podem facilmente conhecer as exigências do projeto.
  

  
  

Colaborações de projetos open source em processo de desenvolvimento de software

Um processo de desenvolvimento de software se caracteriza por um conjunto de atividades necessárias para criação eficaz de um programa. [Pressman 2004]

Pode-se observar que as comunidades de software livre vivem com processo de desenvolvimento de software bastante simples, com poucas ferramentas, pouca documentação, sem muita preocupação com questões de usabilidade de interface e sem muito formalismo da etapa de testes de sistemas. Segundo [Reis 2004] alguns projetos nem possuem plano de teste.

[Herbsleb e Grinter 1999] terminou o seu artigo com a seguinte pergunta "Se o desenvolvimento distribuído é tão difícil, como é que projetos open source têm êxito, dada a relativa simplicidade do seu processo e das suas ferramentas?" [Barnett 2004] mostra (veja a tabela abaixo) uma comparação entre as fases de um ciclo de desenvolvimento de software de um processo tradicional e de um open source.

Tabela:. Comparação entre processo tradicional e open source.

	Tradicional	Open source
Documentação	A documentação significa controle de qualidade e ferramenta para gerência de projeto [Barnett 2004].	Na maioria dos projetos a documentação é escassa devido ao código fonte ser aberto e rico em comentários [Reis, Silva e Fortes 2004].
Requisitos	O analista de negócio transcreve a necessidade do usuário dentro do documento de requisito.	Normalmente os usuários são os desenvolvedores do software [Silveira, S.,(2004)].
Alocação de Pessoas	Os desenvolvedores estão alocados a um único projeto.	Os desenvolvedores estão alocados a projetos distintos com diferentes níveis de envolvimento.
Revisão em par	É aceita, porém não é largamente utilizada.	É uma necessidade e praticada quase de forma universal.
Planejamento dos Releases	Número grande de requisitos e poucos releases.	Releases muito freqüentes. [Raymond 2000]
Qualidade/Teste	Existe formalismo nesta etapa. O teste de sistema é planejado e executado antes do release formal. As auditorias de qualidade são feitas durante todo o processo de desenvolvimento de software na maioria dos todos os artefatos gerados.	Diferente do senso comum, não são realizadas muitas atividades de garantia de qualidade ao longo do desenvolvimento. Por exemplo, executar testes periódicos, possuir um plano de testes, um processo de revisão ou regras para integração de alterações no código. A disponibilização do código publicamente, por meio de releases alpha, beta e release candidates, visando a execução de testes pelo usuário final, é a principal atividade executada para garantir qualidade.
Distribuição do Trabalho	Diferentes partes do código são atribuídas para diferentes pessoas.	Qualquer pessoa pode modificar qualquer parte do código, porém apenas os "committers" podem fazer as modificações oficiais.

[Barnett 2004] menciona no seu artigo algumas atividades de um processo open source que podem ser aplicadas a ambientes coorporativos a fim que possam ajudar a produtividade e qualidade dos produtos. É possível exemplificar as seguintes tarefas:

• Envolvimento do usuário durante todas as fases do desenvolvimento do software. Nos projetos open source normalmente o desenvolver é também o usuário; Este tipo de situação facilita esclarecimento de dúvidas, antecipando correção de especificação.
  

• Staffing Model; Os desenvolvedores open source normalmente trabalham em mais de um projeto ao mesmo tempo, apesar de estar mais envolvido em um do que nos outros.
  
• Aumentar a transparência do andamento do trabalho para as pessoas que não fazem parte do projeto. Aumentando a transparência pode-se aumentar a responsabilidade e produtividade dos participantes, visto que o trabalho gerado fica disponível para toda comunidade validar.
  
• Recrutar alguns usuários para teste beta da aplicação
  para que seja possível detectar erros antes do release oficial.
  
• Adoção de processos ágeis, "Release early. Release often and listen to your customers." [Raymond 2000]. Liberando pacotes pequenos do software de forma rápida, é possível validar juntamente com o cliente o que está sendo desenvolvido evitando re-trabalho desnecessário.
  

A partir destes exemplos, podemos perceber que existem aspectos positivos do processo de desenvolvimento de software livre e se aplicados em um processo tradicional teremos ganhos de qualidade, produtividade e conseqüentemente redução dos custos do projeto.

No próximo post abordaremos o Open Source e seus efeitos na economia.

Referências:

Beline, W., Menta, E., Salvi, R., (2005) "EAD no mundo Open Source: construindo conhecimento com liberdade", II Secomp - Semana de Computação da Universidade Estadual de Londrina, v. 1, p. 1-10

Hogan, B.(2006) "Lessons learned from an extremely distributed project, IEEE Computer Society", agile , pp. 321-326

Parreiras, F., Silva, A., Bastos, J., Brandão, W. "Informação e cooperação nas comunidades de desenvolvimento de software livre: um panorama do cenário

brasileiro". In: CINFORM, Salvador. Anais. Salvador: UFBA

Soares, M. (2002) "O Processo e a (Des)organização da Produção de Software Livre"In: CONGRESSO BRASILEIRO DE COMPUTAÇÃO, Itajaí-SC. Univali

Crespo, A. Silva, O. Borges, C. Salviano, C. Argollo Junior, M. Jino, M., (2004)" Uma Metodologia para Teste de Software no Contexto da Melhoria de Processo.", III

Simpósio Brasileiro de Qualidade de Software, v. 3. p. 271-285

Paulson, J., Succi, G. Eberlein, A. (2004) "An Empirical Study of Open-Source and Closed-Source Software Products", IEEE Computer Society

Lopes, L.; Majdenbaum, A.; Audy, J.(2003) "Uma proposta para processo de requisitos em ambientes de desenvolvimento distribuído de software.", In: WER'03 – Workshop em Engenharia de Requisitos – SBC, Anais do WER'03, v. 1. p. 78-92

Pressman, R. (2004) "Engenharia de Software". 5ª Edição. McGraw-Hill Interamericana do Brasil

Reis, C., Silva, M., Fortes, R., (2004) "Levantamento sobre processo de Software Livre".

Barnett, L., (2004) "Applying Open Source Process in Corporate Development Organizations".

Silveira, S., (2004). "Software Livre – A luta pela liberdade de conhecimento". Editora Fundação Perseu – (Coleção Brasil Urgente).

Raymond, E., (2000). "The Cathedral and the Bazaar". Available at http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

Barnett, L., (2004) "Applying Open Source Process in Corporate Development Organizations".

Créditos desse estudo também se devem aos meus colegas:
Ana Carina M. Almeida, Cleyton C. da Trindade e Marcio M. de Souza