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

Arena de celulares: GSMArena

Mais do que uma simples página da internet, o site GSM Arena (www.gsmarena.com) pode ser considerada uma comunidade em rede da WEB 2. Isto porque lá podemos obter informações técnicas de diferentes aparelhos, de diferentes fabricantes, avaliações com comentários dos usuários que conhecem o aparelho, vídeos relacionados, etc. Existe também o ranking dos mais votados, média de votos por aparelho, e um recurso super bacana que permite realizar comparações entre modelos de celulares.

Com tanta informação disponível percebe-se que o objetivo do site é permitir que as pessoas possam ter informações detalhadas do aparelho pretendido, sem que haja influência de grandes fabricantes, pois não é possível fazer a compra por esse site. Ali, todo o conhecimento está sendo construído pela comunidade.

Por exemplo, existe um ranking dos mais votados na página principal do site, mas só é considerado se o celular já está no mercado e já possui mais de 1000 votos.

Uso na prática do GSM Arena

Quando preciso obter os dados técnicos de um aparelho, ou quando estou na dúvida se comprarei o modelo X ou Y, vou lá e comparo os dois. Depois tomo a decisão baseado nas informações coletadas por lá. Tomamos como exemplo o desejo de querer comprar um Nokia N95 (http://www.gsmarena.com/nokia_n95_8gb-2088.php).

Então, se estiver querendo comprar um celular novo, através do site GSM Arena posso obter as dicas de outros usuários. Tem também o preço estimado para compra. Veja a imagem abaixo:
Na ilustração 1 da figura acima, podemos ler as revisões técnicas disponíveis, acessar a função de comparação, ver as imagens do aparelho, visão de 360 graus ("muito massa!"), ver videos e manuais associados deste aparelho.

Na ilustração 2 temos as principais características do dispositivo móvel, tais como: tamanho de tela, memória, informações da bateria, das features (aplicativos), etc. O comentário dos últimos usuários está logo abaixo desta seção.

Na ilustração 3 temos as lojas que possuem preços para vendas. E logo abaixo, um gráfico com a média das notas, baseado em critério de design, features e performance.

Conclusão
O GSM ARENA é um exemplo de portal informativo da web 2 para conhecer novos e velhos aparelhos, dito e avaliado por quem usa celulares no dia a dia. Recomendo.

Motorola divulga Guia do desenvolvedor Java ME

Quer saber como instalar um MIDlet? Como compilar e depurar uma aplicação? Leia este guia.

A Motorola divulgou este mês no seu site voltado para desenvolvedores, o guia do desenvolvedor para Java ME (Java ME Developer Guide for Motorola OS). Este guia contém informações de todos os telefones que usam o sistema operacional da Motorola, como MotoRazr2, V9 e MotoRizr Z3, tudo num simples documento.

Citando a seção que introduz o guia:

“This guide provides useful information for developers who want to develop JavaTM ME (Micro Edition) applications—known as MIDlets—for Motorola handsets running Motorola OS. It includes information on support APIs, details on developing and packaging applications for installation, as well as a step-by-step procedure for setting up a debug environment. It does not teach you about Java ME or provide basics on developing Java ME applications; we assume you already know how to do that. ”

Ou seja, várias informações úteis das APIs suportadas bem como um passo a passo de como rodar e depurar o ambiente de desenvolvimento.

Para baixar você precisa fazer um pequeno cadastro no site.

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

Práticas open source no desenvolvimento de software aumentam a qualidade dos produtos derivados da engenharia de software?

Revisão 001 (16/03/2008).

A popularidade de software open source está crescendo a cada dia que passa e diversos produtos de amplo conhecimento popular, tais como, sistema operacional Linux e servidor de aplicações Apache. Estes softwares estão sendo criados e mantidos, principalmente, baseados em práticas Open Source, e com a Internet, tornou-se um grande e dinâmico repositório de softwares livre/aberto em diversas áreas de negócios. Alguns estudos de Gacek e Arief (2004) confirmam que práticas open source é uma forma diferenciada de trabalho com impactos positivos às fábricas de software tradicionais.

Apresentarei aqui uma série de posts sobre resultados de um estudo em disciplina de mestrado realizado ano passado (2007), sobre as influências, os efeitos e colaborações do desenvolvimento de software open source na engenharia de software, processo de desenvolvimento e na economia. Estou aprofundando um pouco este estudo para posterior publicação em congressos da área, mas por hora, compartilho as principais idéias investigadas.

Algumas definições relevantes

Os pesquisadores citados acima afirmam que o termo Open Source refere-se, freqüentemente, a um processo de desenvolvimento de software que dá suporte a contribuições, via Internet, de desenvolvedores dispersos geograficamente e que, também, contém um requisito básico, o acesso ao código fonte.

Por outro lado, outros estudiosos como Elliott e Scacchi (2004) destacam uma verdade indispensável, um pacote de open source não necessariamente significa ser livre (no sentido de ser de graça, sem custo); um programa livre é aquele que pode ser usado, copiado, modificado e redistribuído, ou seja, é um sistema que dispõe de total liberdade para que seja realizada qualquer intervenção no código. Um software que é coberto por uma licença livre, não significa que esse software não terá custo para ser operacionalizado. Dependerá da lincença de uso. Assunto que será tratado mais a frente. Ter garantia de acesso ao código fonte e fazer com ele certas coisas é que está mais próximo da liberdade dita acima. Mas, como observou Patricia (ver comentários), nem todo opensource é software livre.

Open source possui várias peculiaridades que se modificam consideravelmente de projeto para projeto. Os estudos de Gacek e Arief (2004) propõem uma classificação em dois grupos de características nos projetos open source: as Comuns e as Variáveis.

Classificação de características de projetos open source segundo Gacek e Arief (2004)

Comuns	Variáveis	Característica
Aderência à definição de open source e a usuários-programadores		Esta significa que um desenvolvedor é um subconjunto dos usuários de open source e, desta forma, é correto afirmar que todos os desenvolvedores são usuários, mas a recíproca não é verdadeira. Aquela determina se a distribuição de um software, em particular, baseia-se nos critérios do OSI (Open Source Initiative).
	Pontos de Início de um Projeto	Um projeto de open source é iniciado de um já existente em código fechado (no geral).
	Motivação	É uma questão pessoal. Os desenvolvedores desejam ganhar respeito e reconhecimento através do reconhecimento da comunidade. Estudantes podem aumentar suas chances na carreira ganhando experiência no desenvolvimento de um projeto real.
	Comunidade	É organizada em estruturas restritas ou liberais, na qual ocorre a centralização ou descentralização na tomada de decisão a depender da composição escolhida. Quanto ao destaque de um componente numa organização deste tipo, a mesma ocorre quando há o reconhecimento do grupo, decorrente das contribuições realizadas por um indivíduo.
	Suporte ao Desenvolvimento de Software	Requer um processo similar aodesenvolvimento de software tradicional. Desta forma, é imprescindível que necessidades específicas geradas pelos desenvolvedores distribuídos tenham algum apoio efetivo, tais como: modularidade, visibilidade da arquitetura do software, documentação e teste, aceitação de submissões, ferramentas e suporte operacional.
	Licença	Vários tipos de licenças estão de acordo com a definição de open source OSI e vários destes, garantem que, se algum código for usado em outro software, o mesmo estará sob os termos da licença original.
	Tamanho	A dimensão da comunidade e da base de código varia fortemente de projeto a projeto.

Para melhor compreender um projeto open source temos que analisar o seu processo de desenvolvimento, ou seja, como o software open source se caracteriza por um conjunto de atividades necessárias para criação eficaz de um programa. Assunto este para o próximo post.

O Sistema Operacional Linux é o grande exemplo do que esse modelo pode construir. O video abaixa demonstra essa analogia. Obs. trata-se de um comercial da IBM.

Do ponto de vista prático, produtos ou serviços open source trazem oportunidades para empresas? Compartilhar seus produtos com as comunidades em rede, promove a marca e permite maior interesse dos usuários? essas e outras questões serão discutidos no decorrer dos próximos posts.

Para saber mais, procure no google e leia os seguintes artigos:

• The Many Meanings of Open Source - Gacek, Cristina e Arief, Budi. (2004), University of Newcastle Tyne, England, IEEE Software Computer Society.
  
• Open Source Definition - OSI, Open Source Initiative (2007) http://www.opensource.org/docs/definition.php.
  
• Mobilization of Software Developers: The Free Software Movement - Elliott, M. S. e Scacchi, W. (2004).

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

Desenvolvimento de software para celulares baseados em RCP: TITAN

Titan é a próxima geração da plataforma Java para desenvolvimento de softwares para SO Windows Mobile da americana Sprint, suportando aplicações de Java ME (MIDP), incluindo CDC/Foundation e o modelo do framework OSGi. Segundo o site, essa combinação provê uma fortíssima plataforma para distribuição dinâmica e colaboração de componentes e aplicações independente de software. Isso porque se usa o modelo já conhecido RCP (Rich Client Platform), o mesmo que o Eclipse IDE é construído e distribuído.

Denominado Embedded Rich Client (eRCP) que é um modelo de aplicação onde o software é escrito de forma de ricas aplicações GUI (interface gráficas de usuários) que podem rodar em múltiplas faixas de dispositivos e computadores (desktops). A plataforma inclui também APIs que deixam acessar as features específicas do telefone da Sprint. As ferramentas do Titan, instalado através do Eclipse, provê vários recursos para construir aplicações, tal como rodar, depurar e geração de pacotes de distribuição para diferentes telefones, além de fornecer ferramentas de gerenciamento de memória e editor baseado em GUI para telas gráficas.

Arquitetura do Sprint Titan, para mais detalhes técnicos veja a apresentação.

Alguns telefones que suportam Titan podem ser vistos aqui.

A grande vantagem desse modelo de RCP é a facilidade de construir aplicações ricas - boa aparência gráfica com bom desempenho. Atualmente estou desenvolvendo aplicações baseadas em RCP e acho que extender esse modelo para SO mobiles é excelente. O problema é que isso está por enquanto restrito a tecnologias para Windows Mobile, e da operadora Sprint Nextel.

O modelo da Open Handset Alliance - o Android é a minha aposta para o futuro por várias razões. A principal eu diria que é devido a parceria estratégica entre diferentes empresas e a segunda diz respeito ao modelo voltado para desenvolvedores, a arquitetura não está restrita a um SO proprietário (pois é Linux) e a tecnologia adotada é Java. Os fabricantes e operadoras podem ter menos gastos para usar esses telefones e os desenvolvedores poderão prestar melhores serviços se o mercado não ficar fechado. Ainda não se sabe como as operadoras vão explorar seus serviços.

Se o Titan tiver suporte em outros SOs no futuro, ai sim seria bom para nós desenvolvedores.

Mais informações interessantes sobre Titan:

• Um blog com post bem interessante sobre Titan;
  

• O que é RCP, por Wikipedia;
  

• Sobre a Sprint Nextel