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
iPhone da Apple
