 |
Christian Reis
kiko@acm.org
Orientação:
Profa. Dra. Renata Pontin de Mattos Fortes
renata@icmc.sc.usp.br
Monografia apresentada ao Instituto de Ciências Matemáticas e de
Computação para o Exame de Qualificação, como parte
dos requisitos para a obtenção do título de Mestre na Área de
Ciências da Computação e Matemática Computacional.
São Carlos, São Paulo
Abril de 2001
Engenharia de Software e Software Livre são termos que são raramente abordados de forma associada em trabalhos científicos; no entanto, esforços combinados nestas áreas têm grande potencial para enriquecer o conhecimento geral do processo de desenvolvimento de software. Neste capítulo é feita uma breve apresentação dos temas e objetivos do trabalho.
A dependência e demanda crescentes da sociedade em relação à
Informática e, em particular, a Software, tem ressaltado uma série de
problemas relacionados ao processo de desenvolvimento de software: alto
custo, alta complexidade, dificuldade de manutenção, e uma disparidade
entre as necessidades dos usuários e o produto desenvolvido
[1,2,3].
Estes problemas afligem a área de Software desde sua criação; Pressman
os identifica como uma `aflição crônica', e não uma crise pontual
[4]. Para administrá-los, a comunidade de Engenharia de
Software, ao longo dos últimos 30 anos, estuda e implementa práticas de
desenvolvimento de software bem organizadas e documentadas.
Parte do trabalho dos pesquisadores envolvidos com a Engenharia de
Software tem sido descrever e abstrair modelos que descrevem processos
de software. Estes modelos permitem que se compreenda o processo de
desenvolvimento dentro de um paradigma conhecido. A existência de um
modelo é apontada como um dos primeiros passos em direção ao
gerenciamento e à melhoria do processo de software [5].
A maior parte dos modelos existentes é baseada em premissas bastante
tradicionais da área: uma divisão discreta das atividades do
processo de software, focando em gerenciamento, medidas e registros
destas atividades. No entanto, não existe um modelo uniforme que possa
descrever com precisão o que de fato acontece durante todas as fases da
produção de um software; os processos implementados são muito variados,
e as necessidades de cada organização diferem substancialmente
[6].
Além disso, na última década, um segmento crescente da comunidade de
Engenharia de Software vem defendendo a existência de problemas
fundamentais da aplicação sistemática e institucionalizada de processos
de software convencionais [7,8,9] . Estes
proponentes advogam processos simplificados, focados nas pessoas que
compõem o processo, e principalmente no programador. Nas palavras de
Bach:
``Nas conferências e nos periódicos, a atenção extraordinária dada ao
processo de desenvolvimento de software é mal dirigida. Demasiado é
escrito sobre processos e métodos para desenvolver software; muito pouco
sobre o cuidado e alimentação das mentes que de fato escrevem o
software.''
Na última década, a popularização de softwares classificados como
Software Livre [10], que são distribuídos livremente
acompanhados de código fonte, tem gerado curiosidade por parte de
pesquisadores e profissionais de alguma forma envolvidos com software.
Esta curiosidade em parte se deve à forma particularmente simples pela
qual estes softwares são produzidos.
Apesar de apresentarem alta confiabilidade, evolução rápida, e uma
comunidade produtiva [11,12,13], os projetos
de software livre apresentam um processo de desenvolvimento
aparentemente caótico, com algumas características particulares: total
descentralização, política liberal em relação a alterações, e discussão
aberta sobre todo assunto técnico pertinente ao projeto
[14]. Os projetos sobrevivem utilizando um mínimo de
infra-estrutura provida pela Internet, sendo o email a ferramenta mais
utilizada [15].
Em 1998, Raymond publicou um conjunto de artigos que descrevem
informalmente algumas características do processo de desenvolvimento que
muitos projetos seguem [14,16], as mais importantes
sendo: releases1.1 freqüentes, propriedade de
código compartilhada, e revisão e verificação de código maciça. Nestes
artigos, Raymond utiliza o termo ``Bazar" para descrever a forma de
organização dos projetos.
Os artigos de Raymond geraram uma série de críticas e respostas, e
ele é considerado um pioneiro por ser o primeiro a documentar, ainda
que informalmente, um processo para este tipo de software. Apesar da
recepção pela comunidade de Engenharia de Software aos conceitos
apresentados em [14] não ser totalmente positiva
[17,18,19], a indústria tem reconhecido o
potencial do software livre e apoiado substancialmente os principais
projetos.
Nos últimos anos, IBM, Apple, Sun, Netscape/AOL e Microsoft têm
reconhecido e investido em projetos de software livre
[20,21,22,13]. Em 2001, será realizada o primeiro
Workshop para Desenvolvimento Open Source como parte do International
Conference of Software Engineering, em Toronto, Canadá, e é a primeira
vez que a conferência tratará deste assunto em um fórum específico
[23].
O interesse da indústria e da comunidade acadêmica não é sem motivo: em
alguns segmentos importantes, projetos de software livre são líderes de
mercado. O servidor Web mais utilizado atualmente é o Apache HTTPD, que
é software livre [24]. Edwards atribui 80% do volume total
de email Internet ao Sendmail, um software livre para transmissão de
correio eletrônico [12]. O núcleo de sistema operacional
Linux, associado a um conjunto enorme de componentes de software livre,
tem mais de 10 milhões de instalações estimadas
mundialmente[25].
A popularização do Linux, associada à criação de um conjunto de
publicações e sites Web, gerou interesse por software livre em milhares
de desenvolvedores ao redor do mundo. O Freshmeat.net, um site Web
dedicado a projetos de software livre, atualmente arquiva uma lista de
mais de 1.000 projetos em desenvolvimento [26]. Este
conjunto de softwares representa um tema muito interessante para estudo,
especialmente levando em conta a natureza aberta e transparente destes
projetos.
O aparente paradoxo entre os aspectos positivos de software livre e sua estrutura pouco formal traz a tona uma questão fundamental: de que forma estes projetos se organizam, e como podem ter sucesso frente ao aparente caos em que existem?
Dos trabalhos científicos publicados que tratam do assunto Software
Livre, poucos abordam o assunto de modelo de processo e metodologia; no
entanto, deve existir algum processo pelo qual software deste tipo é
desenvolvido. Por este motivo, há oportunidade de realizar um trabalho
potencialmente inovador.
Como descrito na Introdução, o assunto é uma área fértil para pesquisa e
experimentalismo; existem centenas de projetos operando de forma aberta
e que podem ser analisados de forma conveniente. Além disso, a
comunidade tem se mostrado bastante aberta a pesquisadores interessados
em compreender o seu funcionamento [27].
Uma motivação adicional para o trabalho é tornar conhecido este processo entre os cientistas brasileiros. Software livre é um assunto que tem especial importância para países em desenvolvimento; no caso particular do Brasil, no entanto, é ainda pouco explorado. Se for possível reproduzir o sucesso destes projetos internacionais em empresas e instituições acadêmicas brasileiras, uma oportunidade para promover um avanço importante na área de software pode ser gerada.
Este trabalho tem como objetivo levantar as características principais ,
do ponto de vista do processo de software, a partir de um conjunto de
projetos de software livre. O trabalho busca determinar se estas
características bastam para compor um modelo de processo de software
para software livre, e caso seja possível, descrever este modelo.
Como conseqüência do levantamento destas características, devem ser identificadas, dentre o conjunto total de práticas aplicadas entre os diferentes projetos, uma coleção de melhores práticas de desenvolvimento de software livre. Além disso, será formada uma base de dados descrevendo o processo, permitindo que outros pesquisadores e organizações possam aproveitar o trabalho realizado.
Este texto está dividido em cinco capítulos principais, sendo o primeiro
esta Introdução. A revisão bibliográfica é abordada nos dois capítulos
seguintes: o segundo capítulo trata da teoria desenvolvida na área de
Processos de Software, dentro da Engenharia de Software; o terceiro
capítulo descreve, com base na literatura existente, os aspectos
principais referentes a software livre e o desenvolvimento de software
baseado neste princípio. Este capítulo traz um comentário dos trabalhos
relacionados.
O quarto e último capítulo descreve o projeto proposto, e aborda a
metodologia que se pretende utilizar para executar o projeto. Esta parte
inclui um detalhamento e cronograma das atividades essenciais.
Muito do que será investigado neste trabalho diz respeito a um Processo
de Software, e para defini-lo, cabe alguma discussão. Existe alguma
sobreposição em relação aos termos Processo, Modelo, Método e
Metodologia, gerando confusão em algumas circunstâncias. Embora não
sejam sinônimos, é comum observar na literatura o uso de um termo em
lugar do outro. Assim, é necessário buscar definições para fundamentar o
objetivo deste trabalho, que envolve o entendimento de um processo para
software livre.
Neste trabalho, é usada a palavra modelo para descrever um enfoque conceitual ao Processo de Software; é usado o termo metodologia para descrever uma seqüência de atividades práticas a ser executadas durante o desenvolvimento.
O Processo de Software é definido por Sommerville em [28]:
``[O processo é] um conjunto de atividades e resultados associados que produzem um produto de software.''
Pressman, em [29] oferece a seguinte definição:
``[...definimos um] processo de software como um framework para as tarefas que são necessárias para a construção de software de alta qualidade.''2.1
Estas definições oferecem uma idéia mais clara do que é considerado um processo. Diretamente delas, podemos retirar os seguintes pontos importantes:
Não há processo correto ou incorreto; dependendo da sua aplicação, ambiente e objetivo, o uso de um processo específico pode ser vantajoso ou não. Um ponto importante a ressaltar é que cada autor e organização coloca e classifica processos e atividades de forma diferente, tornando difícil uma uniformidade completa. As seções seguintes discutem visões alternativas, e se baseiam em características comuns encontradas na literatura para classificar.
Pela definição, podemos entender o que é o processo; no entanto, de que
fases é composto?
Em meados dos anos 70, Schwartz já apontava como fases principais do processo de produção de um sistema de software [30]:
A definição moderna oferecida por Sommerville [28] é similar; define as atividades como Especificação, Desenvolvimento, Validação e Evolução. Este último ponto não é descrito diretamente por Schwartz:
É interessante observar que é destacada a questão da longevidade do
software no ítem Evolução; neste contexto, podemos perceber que a
definição de Schwartz omite uma particularidade importante: o software
continua sendo desenvolvido mesmo depois de entregue. Pressman
[2] oferece uma visão compatível com esta, ainda que
simplificada: as fases descritas são Definição, Desenvolvimento e
Manutenção.
É importante ressaltar que não existe uma seqüencialidade obrigatória de
fases. Tradicionalmente, as fases tem sido vistas como passos discretos
e seqüenciais [31]; no entanto, diversos autores apontam a
natureza não-simultânea das fases como uma realidade na aplicação de
processos de software [32,33].
Além da questão de seqüencialidade, existem autores que defendem que o
processo de software é muito mais iterativo e cíclico do que a idéia de
fases simples pode sugerir. Em particular, Boehm, Davis, Rising et Al.,
e Beck sugerem processos onde existem ciclos contínuos e repetidos, onde
alguma forma de produto é desenvolvida a cada ciclo [34,32,35,8]. A extensão de cada ciclo, no entanto, não é
um consenso.
Para cada fase do processo de desenvolvimento de software existe uma série de atividades que são executadas. Estas atividades constituem um conjunto mínimo para se obter um produto de software, segundo Pressman [2]. Observando as fases individuais e suas atividades associadas, combinando classificações de Schwartz, Pressman e Sommerville [30,2,28], é possível identificar as seguintes atividades:
O Processo de Software pode ser visto como um gerador de produtos, sendo
que o produto final, ou principal, é o Software em si. É importante
perceber que existem subprodutos que são gerados para cada fase -- ao
final da fase de Especificação, por exemplo, é comum ter sido
desenvolvido e entregue um ou mais documentos que detalham os requisitos
do sistema. Estes subprodutos também são chamados na literatura de
deliverables.
Todo modelo de software deve levar em consideração as fases descritas; no entanto, cada um organiza estas fases de uma forma particular de acordo com sua filosofia de organização. Na próxima seção são analisados alguns modelos mencionados na literatura.
Existem alguns modelos teóricos desenvolvidos que buscam descrever a
forma com que as fases seguem e interagem. Nesta seção estão descritos
alguns dos modelos mais conhecidos [28,2,31,34]. Existe alguma flexibilidade no que diz respeito à definição do
termo ``modelo''; neste trabalho são considerados, dentre os modelos
descritos na literatura, os que têm um caráter estratégico, e não
específico. Em outras palavras, um modelo é uma filosofia do andamento
das fases, e não uma descrição de como cada atividade deve ser
executada.
A seção 2.5, por sua vez, descreve algumas metodologias, que são formas práticas de organizar o processo de desenvolvimento. Uma metodologia traz conceitos bastante específicos em relação ao desenvolvimento, como exemplifica Beck [8] em sua descrição da metodologia XP -- programação em pares, ciclos de 15 dias e equipes de menos de 10 pessoas.
Este modelo foi idealizado em 1970 por Royce, e tem como característica
principal a seqüencialidade das atividades: sugere um tratamento
ordenado e sistemático ao desenvolvimento do software. Cada fase
transcorre completamente e seus produtos são vistos como entrada para a
nova fase; o software é desenvolvido em um longo processo e entregue ao
final deste. O autor sugere laços de feedback, que permitem
realimentar fases anteriores do processo, mas em geral o modelo cascata
é considerado um modelo linear [31]. A figura
2.1 fornece uma descrição visual do modelo.
Críticas ao modelo Cascata sugerem a inadequação deste a processos reais; em geral, há muito intercâmbio de informações entre as fases, e raramente ocorrem projetos onde não há concorrência das fases em si. [32]. Além disso, o modelo Cascata não leva em consideração questões modernas importantes ao desenvolvimento: prototipação, aquisição de software e alterações constantes nos requisitos, por exemplo [8,36].
Boehm, em 1986, sugeriu um modelo evolucionário para o desenvolvimento
de software, baseado em uma seqüência de fases que culminam em
releases incrementais do software [34]. Esta característica
incremental é confirmada no conceito de prototipação de Brooks
[37], e em metodologias de processo mais modernas, como
descrito por Beck [8] e Rising [35].
Em geral, modelos incrementais têm o objetivo de lidar melhor com um
conjunto de requisitos incerto ou sujeito a alterações. Gancarz,
por exemplo, afirma que a filosofia original do Sistema Operacional Unix
leva em conta o fato de requisitos raramente se adequarem ao produto
inicial [38]. Por este motivo, o modelo espiral parece
melhor adequado a projetos reais que o modelo cascata -- em geral,
modela melhor a interação real entre cliente e fornecedor do software
[34]. A figura 2.2 apresenta um diagrama do
modelo.
O Modelo Espiral, ainda assim, assume que existe alguma seqüencia entre as fases: não há suporte para fases que ocorrem simultaneamente, ou que necessitam de intercomunicação contínua para operarem.
Embora Brooks, em [39], tenha defendido a compra de
componentes de software como um dos meios para melhorar a produtividade
substancialmente, Hirai e Saeki apontam como uma dificuldade
significativa, em projetos de software modernos, a interação da
organização desenvolvedora com seus fornecedores de software
[36]. Um dos maiores riscos de desenvolvimento apontados por
Lawson em [40] é a interdependência de um produto com
componentes de software produzidas em outras organizações, sobre as
quais não se tem controle algum.
O modelo proposto por Hirai e Saeki utiliza dois mecanismos externos que
não são contemplados nas fases tradicionais: um Sensor, que captura
informações da Internet que tratam de atualização e problemas nos
componentes comerciais utilizados; e um Controlador de Processo que
fornece aos membros do projeto informação relacionada aos componentes
utilizados. Existe uma base de dados onde ficam armazenadas informações
relacionadas aos componentes e ao seu uso na organização.
O Controlador alimenta todas as fases do desenvolvimento, da
Especificação à Integração e Teste, com dados referentes aos
componentes. Na fase de Especificação, por exemplo, o Controlador
fornece características e recursos dos componentes utilizáveis, para que
a equipe possa decidir pelo uso de algum. A figura 2.3 mostra uma
descrição simplificada este modelo.
Este modelo é interessante por abordar um fato até então ignorado nos modelos de processo: que componentes comercialmente disponíveis podem influenciar substancialmente o processo de desenvolvimento. Os padrões de qualidade, prazo e ritmo de lançamento dos componentes utilizados influem diretamente na forma com a qual o software é desenvolvido dentro de uma organização.
Davis e Sitaram defendem um outro ponto importante: o de que as fases de
um processo de desenvolvimento não ocorrem seqüencialmente, e sim,
concorrentemente. A descrição do modelo é feita usando um estudo de caso
modelado em Statecharts [32]. O mecanismo pelo qual o processo
ocorre é baseado em eventos que sinalizam alterações de estado dentro de
cada fase. O modelo representa atividades simultâneas de todos os
membros da equipe de desenvolvimento, e os eventos que alteram o estado
são gerados por necessidades do usuário, decisões da gerência, e
resultados de revisões técnicas.
Por exemplo, a fase de Especificação pode estar em um dentre diversos
estados: em desenvolvimento, completo, revisado, e controlado no
repositório. A criação, e toda revisão à especificação original, ativa a
fase de Desenvolvimento, de forma que há um ciclo constante entre os
estados. A figura 2.4 apresenta um diagrama de estados para
esta fase.
Embora o modelo apresente complexidade elevada, é bem adaptado a situações reais de desenvolvimento, onde realmente existe uma divisão temporal menos discreta entre as fases em execução. O modelo caótico, descrito a seguir, elabora em outro nível esta filosofia.
Este modelo foi sugerido por Racoon, que coloca o programador como a
figura mais importante do seu modelo de processo [33]. Este
sentimento é confirmado por DeMarco e Bach em seus trabalhos
[7,9].
A descrição do modelo é interessante e espirituosa. O princípio básico é
que cada uma das fases de desenvolvimento descritas na seção 2.2
consiste na realidade em um ciclo de vida completo. Cada fase do ciclo é
composta, por sua vez, de um conjunto de fases idênticos. Por exemplo, a
fase de Especificação é um ciclo onde consideramos como implementar a
especificação, a implementação em si, e a evolução desta especificação.
A figura 2.5 apresenta um ciclo para esta fase.
Além disto, Racoon coloca, ``cada fase ocorre em todas as fases''. Na
fase de Especificação, são analisados os requisitos para criar um
documento de requisitos; na fase de Implementação, são criados
requisitos de implementação; na fase de Manutenção, são revisados e
alterados os requisitos iniciais. Este padrão fractal se repete para
todas as fases.
Embora o autor seja informal em boa parte de sua descrição, seu enfoque é interessante no sentido de que enuncia a complexidade como uma realidade do processo de software, e não um problema a ser resolvido. Em parte, este é um motivo pelo qual as metodologias mais específicas focam em aspectos práticos do desenvolvimento, e não em questões filosóficas profundas. Na próxima seção são analisadas algumas metodologias de desenvolvimento, também chamadas de processos leves ( lightweight processes) ou processos ágeis [8,41].
Os modelos apresentados anteriormente têm como objetivo prover um mapa
conceitual do processo de desenvolvimento. Existe discussão até que
ponto modelar e especificar um processo é relevante [42,43]; o certo é que modelos abordam essencialmente questões
conceituais da organização do desenvolvimento. Fowler coloca em
[41] que as metodologias modernas de desenvolvimento, como XP
e SCRUM, são uma reação a modelos extremamente conceituais e a
metodologias ``monumentais'' [41]. Nas suas palavras:
```Estas metodologias [monumentais] existem há muito tempo. Elas não são
conhecidas por serem particularmente de sucesso [...] A crítica mais
freqüente a estas metodologias é que são burocráticas [...] Como uma
reação a estas metodologias, um grupo novo de metodologias apareceu nos
últimos anos [...] Estes novos métodos tentam estabelecer um compromisso
útil entre nenhum processo e processo demasiado, provendo apenas processo
suficiente para fornecer uma vantagem razoável.''
Nesta seção estão descritas metodologias práticas para o desenvolvimento, que são formas específicas de organizar o processo de software para obter vantagens de qualidade e produtividade. A metodologia se foca em especificar tarefas aplicando um conceito específico (refactoring e programação em pares em XP, por exemplo) a cada fase do desenvolvimento, e propor soluções práticas para problemas comuns.
O trabalho de Beck [8] descreve um processo minimalista onde
existe muito pouca burocracia envolvida no desenvolvimento. Equipes
pequenas, de até 10 desenvolvedores, trabalham em iterações curtas,
produzindo software incrementalmente, e analisando requisitos à medida
que são descritos pelo cliente.
XP se apóia em um contínuo refinamento do projeto e da implementação deste no código. Para realizar este refinamento, aplica alguns princípios básicos:
O interesse que XP tem gerado entre a comunidade de desenvolvimento -- este é o segundo ano em que a Extreme Programming Conference é realizada [44] -- pode ter relação com sua atitude de ``menor esforço'' face a problemas complexos do desenvolvimento. Por exemplo, a documentação do sistema deve ser mantida junto com o próprio código fonte, e deve ser mínima, forçando o desenvolvedor a escrever código auto-explicativo [45] e a evitar complexidade.
Uma outra metodologia de desenvolvimento que é classificada como ágil é
o SCRUM2.3. Esta metodologia foi criada na
Easel, e posteriormente desenvolvida por duas empresas em conjunto:
Advanced Development Methods e VMARK. Seu objetivo é fornecer um
processo conveniente para projeto e desenvolvimento orientado a objeto
[46].
A metodologia é baseada em princípios semelhantes aos de XP: equipes
pequenas, requisitos pouco estáveis ou desconhecidos, e iterações curtas
para promover visibilidade para o desenvolvimento. No entanto, as
dimensões em SCRUM diferem de XP.
SCRUM divide o desenvolvimento em sprints de 30 dias. Equipes
pequenas, de até 7 pessoas, são formadas de projetistas, programadores,
engenheiros e gerentes de qualidade. Estas equipes trabalham em cima de
funcionalidade (os requisitos, em outras palavras) definidas no início
de cada sprint. A equipe é responsável pelo desenvolvimento desta
funcionalidade.
Todo dia, é feita uma reunião de 15 minutos onde o time expõe à gerência
o que será feito no próximo dia, e nestas reuniões os gerentes podem
levantar os fatores de impedimento (bottlenecks), e o progresso
geral do desenvolvimento.
SCRUM é interessante porque fornece um mecanismo de informação de status que é atualizado continuamente, e porque utiliza a divisão de tarefas dentro da equipe de forma explícita. Uma discussão mais profunda do método é feita em [47].
Crystal/Clear faz parte, na realidade, de um conjunto de metodologias criado por Cockburn [48]. As premissas apresentadas para a existência deste conjunto são:
Crystal/Clear é uma metodologia direcionada a projetos pequenos, com
equipes de até 6 desenvolvedores. Assim como com SCRUM, os membros da
equipe tem especialidades distintas. Existe uma forte ênfase na
comunicação entre os membros do grupo, e a organização do espaço de
trabalho deve permitir este tipo de trabalho.
Toda a especificação e projeto são feitos informalmente, utilizando
quadros publicamente visíveis. Os requisitos são elaborados utilizando
use cases, um conceito similar às user stories em XP,
onde são enunciados os requisitos como tarefas e um processo para sua
execução. Os releases de software são feitos em incrementos
regulares de um mês, e existem alguns subprodutos do processo que são
responsabilidade de membros específicos do projeto.
Grande parte da metodologia é pouco definida, e segundo o autor, isto é proposital; a idéia de Crystal/Clear é permitir que cada organização implemente as atividades que lhe parecem adequadas, fornecendo um mínimo de suporte útil do ponto de vista de comunicação e documentos.
Nesta seção é retomada a descrição das atividades que são realizadas
durante um processo genérico de software; estas atividades se aplicam
tanto a modelos conceituais, quanto às metodologias práticas abordadas
na última seção.
Além das atividades envolvidas com a produção do software em si, existem
atividades auxiliares, citadas por Pressman [29] como
umbrella activities. Estas atividades existem com o objetivo de
garantir que o software construído seja de qualidade e bem documentado,
e que a produtividade do grupo de desenvolvimento seja mantida.
Atividades auxiliares do processo são aplicadas ao longo de todas as fases do desenvolvimento. O conjunto específico de atividades varia de acordo com cada organização, mas existe um consenso de que as seguintes atividades são importantes [29,49,28]:
Todo processo de software tem benefícios com a aplicação destas atividades, e em muitos casos, mesmo inconscientemente, estas são partes implícitas do desenvolvimento de software. Um projeto que utiliza uma ferramenta para controle de versão como o CVS [50] está, estritamente falando, gerenciando configuração; um projeto que mantém um cronograma público com atualizações freqüentes está acompanhando e gerenciando o seu processo.
Até a última década, a maior parte do software era desenvolvido em
grupos geograficamente reunidos, trabalhando como uma equipe altamente
coesa. No entanto, há uma tendência crescente por utilizar equipes
geograficamente dispersas para desenvolver software. Em parte, é
responsável por esta tendência o desejo de aproveitar ao máximo as
habilidades do pessoal disponível para o projeto, não importando sua
localização.
Esta alteração importante na organização da equipe de desenvolvimento exige alterações no processo de software [51]. Nesta seção são tratados aspectos da Engenharia de Software relacionados ao desenvolvimento de software descentralizado ou distribuído.
Grundy et al. apontam alguns problemas criados ou exacerbados por estas
alterações [52]. É interessante notar que, embora muito se
fale dos problemas, existe pouca discussão das vantagens que o
desenvolvimento distribuído oferece. A principal, e óbvia, é a
possibilidade de reunir em uma equipe um conjunto de desenvolvedores
geograficamente dispersos.
Os problemas apontados por Grundy são:
Estes problemas são tratados em diversos outros trabalhos da área [53,54], e algumas soluções são discutidas. O trabalho de Herbsleb et al., em particular, é um estudo de caso que faz uma análise bastante completa das dificuldades do desenvolvimento distribuído, e será discutido na próxima seção.
Herbsleb et. al realizaram um estudo de um projeto de desenvolvimento
de software, distribuído entre dois centros da Lucent na Alemanha e
Inglaterra, para o desenvolvimento de um software para comutação
telefônica. Neste estudo, é feita uma discussão interessante das
questões práticas enfrentadas pelas equipes [54].
Uma das questões que o artigo discute é a divisão em módulos de um
sistema. Os autores defendem que esta divisão reflete diretamente em uma
divisão do trabalho entre os grupos dispersos, o que torna a
responsabilidade dos módulos e suas interfaces muito importantes, e
freqüentemente, um fonte de problemas.
Outra questão é que o plano e o modelo de processo representam mal
aspectos informais que sustentam o desenvolvimento centralizado:
habilidade individual, criatividade, o uso de redes pessoas, e do espaço
físico. Um exemplo citado é a lanchonete da empresa, onde desenvolvedores
se encontram para discutir assuntos gerais informalmente; este ponto de
encontro serve como um mecanismo de troca de informação vital porem
informal dentro do grupo de desenvolvimento. Em projetos dispersos, não
há este tipo de recurso.
O estudo aponta dificuldades enfrentadas no projeto; entre elas estão as seguintes:
Os autores concluem com as seguintes observações:
Para os problemas apontados por Grundy, Herbsleb et al., existe
discussão em alguns trabalhos, sendo que as soluções são apresentadas em
dois níveis: primeiro, na elaboração de um processo que seja bem
adaptado às necessidades de desenvolvimento descentralizado
[55,56]; segundo, no desenvolvimento de ferramentas
específicas para apoiar projetos distribuídos [53,57].
Uma possibilidade de apoio ao processo é o uso de sistemas de workflow e
automação de processo; no entanto, a maior parte dos trabalhos estudados
aponta que sistemas de workflow não se adaptam bem ao
desenvolvimento de software. Grundy et al. descrevem o problema da
seguinte forma [52]:
``Sistemas de Workflow e planejamento de projeto [...] provêm
recursos mais acessíveis para modelar processos de trabalho, mas em
geral não dispõem da flexibilidade para especificar mecanismos de
coordenação de trabalho e integração de ferramentas.''
Cook descreve um mecanismo baseado em eventos para capturar informação de um projeto de software distribuído em [56], e neste trabalho ele levanta uma característica importante: se todo diálogo é registrável, é possível acumular dados e posteriormente analisá-los para compreender melhor o processo. Esta parece ser uma vantagem importante que projetos distribuídos têm: o fato de toda comunicação ser registrável e estruturável, já que é transmitida por canais passíveis de armazenamento e medição. A possibilidade de se utilizar este registro para levantar um histórico de alterações nos diferentes produtos de um projeto é bastante interessante.
Possivelmente porque seja tão importante um conjunto de ferramentas apropriadas para o tipo de tarefa [54] existe uma preocupação tão grande com o assunto de software de suporte a desenvolvimento distribuído. Fielding et al. apontam o surgimento da Internet como uma solução importante para o problema da Engenharia de Software em projetos descentralizados, e sugerem um conjunto de alterações à tecnologia Web para permitir bom suporte à engenharia de software:
Parte destes requisitos tem sido desenvolvidos pelo W3C [58] nos
últimos anos como parte do desenvolvimento de novos padrões para a Web.
Em particular, a tecnologia WebDAV, que existe para permitir autoria e
controle de versões para documentos Web, já está desenvolvida e é
utilizada em alguns produtos para Web[57].
Existem diversos projetos para desenvolver ferramentas colaborativas para Engenharia de Software através da Web, a exemplo dos citados em [52,55]. No entanto, parece faltar ainda um conjunto de ferramentas que seja pouco restritivo, multiplataforma, e que suporte os recursos mínimos necessários à colaboração de fato para o desenvolvimento de software descentralizado.
Grande parte das pesquisas feitas na área de Engenharia de Software, e
em particular no desenvolvimento de Processos de Software, continuam
sendo desenvolvidas e contribuindo para melhorias na construção de
produtos de software. No entanto, existe uma tendência atual para a
simplificação e pragmatização do processo para acomodar novas
necessidades de desenvolvimento; os requisitos e demandas por novos
sistemas são muito diferente dos conhecidos e estabelecidos nos anos 70
e 80.
Neste contexto, vem a tona uma nova forma de produção de software, baseada em elementos tradicionais de desenvolvimento aplicados à nova realidade de desenvolvimento descentralizado que a Internet traz. Esta nova forma é baseada em torno de código livremente disponível, Software Livre, e é abordada no próximo capítulo.
Neste capítulo é abordado o tópico principal do trabalho, que é a classe de softwares distribuídos como software livre. Para esclarecer a terminologia que será adotada neste trabalho, serão inicialmente apresentadas algumas definições importantes.
O termo Software Livre assume um conjunto de significados, dependendo do contexto. Pode significar:
Neste texto, vamos utilizar o primeiro significado, que é definido em
[10] como sendo Software que é distribuído acompanhado de código
fonte, e que pode ser livremente modificado e redistribuído. O termo tem
uma conotação filosófica marcante que, segundo Stallman [59], é
proposital: o aspecto a ser reforçado é a liberdade. Usaremos o termo
`não-livre' para descrever software que é fornecido em outros termos.
Um dos aspectos interessantes desta filosofia é que em nada restringe o preço do software. Isto significa que é perfeitamente possível cobrar um valor pelo software ou por sua distribuição. Na prática, o fato da redistribuição do software ser irrestrita resulta em um preço a baixo o suficiente para motivar as pessoas a não copiarem o software de alguém que já o tem. De qualquer forma, o que se observa é que existem duas formas principais de se adquirir o software:
O termo Open Source é bastante conhecido e descreve melhor a
forma de desenvolvimento que é aplicada em grande parte dos projetos de
software livre. Em português a tradução direta é Código Aberto; no
entanto, a definição é demasiado vaga para ser utilizada
consistentemente, e por isso será usada apenas a expressão Software
Livre neste trabalho.
Raymond define Open Source em [14]. O termo é usado para descrever software livre que é desenvolvido de forma colaborativa e aberta, e é aplicado como um sinônimo de Software Livre em muitos casos3.1.
A palavra Freeware sugere a idéia do software ser grátis. Como
exposto anteriormente, este termo se aplica mal a software livre, por
não reforçar a idéia de liberdade (que é a essência do software livre),
e por indicar preço zero [61]. A tradução imediata da palavra é
software gratuito.
Shareware é um termo que descreve software que pode ser
redistribuído de forma liberal, mas cujo uso é limitado a uma licença
que obriga o usuário a pagar após um período de tempo. Não se aplica a
software livre, que não inclui restrições deste caráter [61].
Domínio Público é uma classificação: todo software que não tem copyright (ou seja, cujo autor o abandonou voluntária ou automaticamente), e que pode ser utilizado e modificado sem nenhuma restrição, é classificado como Domínio Público. software livre não é sinônimo de Domínio Público, e usar o termo é incorreto [62]; a existência de um copyright associado ao software livre é um de seus fatores essenciais.
Software, como toda produção intelectual, é protegido por copyright, que
determina quem é seu proprietário. O dono do copyright tem total
controle sobre a forma com a qual seu bem pode ser distribuído, e este
controle é usado de uma maneira peculiar com software livre
[63].
A forma com a qual o dono do copyright permite o uso e distribuição do
seu bem é descrita através de uma Licença. No caso de software, existem
inúmeras licenças; o uso do software é ditado por regras descritas
nestas licenças3.2.
Software Livre utiliza licenças e copyright com o objetivo de garantir a
liberdade do software a seus usuários. Cada licença oferece alguns
detalhes diferentes, e existem hoje algumas dezenas
[64]. A tabela 3.1 apresenta as principais
diferenças entre as licenças mais utilizadas [65]. Feller faz
na sua introdução em [66] uma boa análise das questões
envolvidas com licenciamento.
|
O assunto de licenciamento é um tema bastante controverso dentro da comunidade de software livre, e a questão de compatibilidade é importante: em muitos casos, software distribuído com uma licença específica não pode ser usado em conjunto com software licenciado de forma incompatível. O que exatamente quer dizer `usado em conjunto', no entanto, é motivo de debate. Torvalds, por exemplo, decidiu que o Linux -- embora seja licenciado através do GPL -- não proibiria que chamadas do sistema fossem utilizadas por software não-livre. Isto, na prática, significa que software que executa no Linux não tem necessariamente que ser software livre [72].
Software Livre é um conceito bastante antigo, embora não tivesse este
nome específico. Software, durante as décadas de 60 e 70 era
desenvolvido de forma colaborativa e aberta em diversas instituições e
empresas; o Unix original é um exemplo desta tendência
[73]. Embora as licenças não explicitassem claramente
liberdade, a redistribuição do software era vista como positiva, e o
software geralmente era fornecido com o seu código fonte
[74,75]
A década de 80 trouxe uma alteração importante: a incremental mudança
para licenças restritivas, que não permitiam redistribuição. O software
fornecido, que até então era visto como uma combinação de código fonte
com código executável, passou a significar apenas o executável
[75]. O Unix, que era visto como um software único até
então, se dividiu entre uma série de fornecedores que introduziram suas
alterações proprietárias, reduzindo a sua interoperabilidade
[76].
Em 1985, Stallman criou o Free Software Foundation (FSF), cuja finalidade era
promover a criação de um sistema operacional completamente livre. Para
garantir esta liberdade, Stallman também criou uma licença para o
software, a GPL, descrita na seção 3.2. O sistema operacional
tinha o objetivo de ser compatível com Unix, e foi chamado de GNU. O
desafio de construir o sistema operacional envolvia não apenas a criação
de um núcleo de sistema operacional (que até hoje não se encontra em
estado de produção), mas a criação de uma coleção de aplicativos e
bibliotecas que permitissem ao sistema compatibilidade com o Unix
original. Durante esta década, o FSF trabalhou desenvolvendo entre
outros a suite de compiladores GCC [77], o editor de textos Emacs
[78] e as bibliotecas padrão libc e glibc [79].
Raymond reforça que grande parte do software livre desenvolvido até
então era desenvolvido de forma fechada e pouco colaborativa, e usa o
termo ``Catedral'' para descrever o processo de desenvolvimento
[14].
Em 1991, um estudante da Universidade de Helsinki, Linus Torvalds,
iniciou o desenvolvimento de um núcleo de sistema operacional, o Linux.
Este é considerado o mais importante exemplo moderno de um software
livre desenvolvido de forma aberta. Torvalds convidou outros
desenvolvedores a participarem ativamente da codificação e manutenção do
núcleo, e, de forma surpreendentemente rápida, este evoluiu para se
tornar um software com funcionalidade similar a núcleos Unix
comerciais [80].
Um fator que se considera importante para o sucesso do Linux do ponto de vista do processo de desenvolvimento é a escolha pela licença GPL, e pela decisão de utilizar a Internet como o canal principal de desenvolvimento.
Um detalhe interessante é que a cultura em torno de software livre é
bastante ligada à cultura em torno do Unix. Os motivos para esta
tendência parecem derivar de um longo histórico de uso pelos principais
representantes do movimento, e pela natureza exploracional e acadêmica
que o Unix original trouxe.
Um tema recorrente entre desenvolvedores é uma admiração pela filosofia do Unix original [81], que é sumarizada por Gancarz [38] como sendo composta dos seguintes pontos:
Os autores originais do Unix colocam estes pontos repetidas vezes como o motivo principal de sucesso do Unix [82,83]. Esta filosofia é adotada informalmente como a filosofia de grande parte dos projetos de software livre, e são citados em comunicações em listas de discussão de diversos projetos. Desta tradição Unix provavelmente deriva a grande concentração de software livre desenvolvida para esta plataforma e em seus derivados compatíveis.
Embora não exista publicada uma definição do que é um Projeto de
software livre, existe um consenso informal de que o software em
conjunto com seus desenvolvedores, usuários e repositórios de código e
documentos constitui um Projeto, e é usada esta nomenclatura neste
trabalho. A forma de categorização do software nos diretórios online de
software livre Freshmeat.net [26] e Sourceforge
[84] corroboram esta definição.
Em síntese, o Projeto de Software Livre, nesta visão, abrange:
É interessante perceber que todo o desenvolvimento e distribuição depende essencialmente do uso da Internet, e que esta é um pré-requisito para a existência de um projeto de software livre. Com base nesta explicação, serão fornecidos exemplos reais de projetos de software livre.
Existem hoje centenas projetos de software livre em algum estado de desenvolvimento [26], sendo que a maior parte destes já está em algum estado de implementação. Este volume já é suficiente para denotar a importância do conceito. Uma listagem recente de categorias do Freshmeat.net [26] é fornecida na tabela 3.23.3:
Dos diversos projetos de sucesso que existem hoje, existem alguns com pertinência especial por sua forma de organização, sua base de usuários, ou pela percepção subjetiva de qualidade. Para que se possa entender a difusão do conceito, foram escolhidos alguns projetos representativos para discussão na próxima seção.
Existe alguma ambiguidade quando é usada a palavra Linux, que pode tanto
se referir ao núcleo de sistema operacional como ao sistema operacional
como um todo, incluindo aplicações básicas e de sistema. Neste texto,
usaremos Linux para descrever o núcleo apenas.
O Linux [87] é um núcleo multi-tarefa preemptivo baseado na API
definida pelo grupo Posix do IEEE [88]. Foi inicialmente
implementado por Torvalds [72], e é inteiramente escrito em C
e Assembler. O núcleo é multi-plataforma; hoje suporta mais de dez
arquiteturas diferentes, a mais importante do ponto de vista do
desenvolvimento sendo a arquitetura ia32 da Intel [89].
O fato de ser o projeto de software livre mais famoso também faz com que muito se tenha estudado do ponto de vista de sua evolução e organização, e que existam diversos sites Web dedicados ao tema. O Linux, no entanto, é um dos projetos mais desprovidos de infra-estrutura de desenvolvimento: utiliza como ferramenta apenas formas de comunicação eletrônica -- listas de discussão e email. Não há repositório de informes de erros, e tampouco controle de versões público.
O tamanho do núcleo em linhas de código é motivo de algum debate; em [90] o núcleo 2.4, a versão estável atual, é medido em mais de 2 milhões de linhas de código. Wheeler fez um estudo que é um dos mais completos existentes do sistema operacional, e aponta o tamanho do núcleo 2.0, em 1999, em mais de 500.000 `linhas de código lógicas', o que implica contagem omitindo comentários e linhas em branco. [91]. Godfrey e Tu traçam um gráfico do crescimento do núcleo em [92] com detalhes individuais da evolução individual de cada módulo do núcleo; o crescimento foi classificado por eles como ``super-linear''.
Moon e Sproull fazem uma análise histórica do núcleo em [93] em
três diferentes perspectivas: dos indivíduos, do grupo e da comunidade;
neste trabalho, é colocada claramente a importância do desenvolvimento
em comunidade e fornecem estatísticas históricas da participação de
desenvolvedores externos no núcleo:
``...em duas semanas do anúncio de Torvalds [a respeito lançamento do
núcleo] em Outubro de 1991, 30 pessoas tinham contribuído cerca de 200
informes de erros, contribuições de utilitários e drivers e melhoras
para ser adicionadas ao núcleo [...] em Julho de 1995, mais de 15.000
pessoas de 90 países e 5 continentes tinham contribuído comentários,
informes de erro, correções, alterações, reparos e melhoras.''
Uma observação da lista de discussão principal do núcleo na semana de 16 de Abril de 2001 aponta 615 participantes em 1597 mensagens [94]. O tamanho da comunidade tem impacto direto sobre a liderança do núcleo, que é surpreendentemente convencional.
O núcleo hoje tem em Torvalds seu ``dono'', e ele decide quais alterações são aceitas e a filosofia geral do núcleo. No entanto, crescentemente a responsabilidade pelos módulos principais do núcleo tem sido atribuídos a outros, e de certa forma o núcleo tem diversos ``donos'' em um dado momento [14]. A manutenção da versão estável, há alguns anos, é responsabilidade de Alan Cox.
O outro exemplo importante é o núcleo FreeBSD. Este núcleo é um
derivado direto do núcleo BSD original, que originou como uma série de
alterações ao Unix AT&T original e eventualmente evoluiu para uma base
de código quase inteiramente nova [73].
O FreeBSD é administrado por um grupo de 9 pessoas, que faz a maior
parte da codificação. Há um grupo de mais 200 desenvolvedores que tem
acesso de escrita ao repositório de código do projeto. A maior parte das
alterações não-triviais são discutidas na lista de discussão antes de
integração, de qualquer forma, o que permite que seja feita revisão
técnica do projeto e da implementação da alteração.
O FreeBSD possui um conjunto de listas de discussão, um repositório de controle de versões público, e uma interface para informes de defeitos. O projeto é considerado mais conservador que o Linux por discutir mais profundamente nova funcionalidade e suporta a hardware, e este fator é apontado como um motivo para sua relativa lentidão a suportar dispositivos novos.
O Apache é um servidor HTTPD, desenvolvido a partir do servidor NCSA
original, e que é administrado por um grupo sem fins lucrativos. O
Apache é um dos projetos livres mais estudados [27,85] e sobre o qual existe bastante material descrevendo sua
organização.
O projeto de organiza em torno de um núcleo de desenvolvedores, que
fazem a maior parte da codificação. Estes desenvolvedores interagem
constantemente com os usuários e com os desenvolvedores secundários, que
tem suas alterações revisadas publicamente através de listas de
discussão. Não há um líder forte é o caso do Linux; o modelo de
liderança é semelhante ao do FreeBSD.
O Apache possui um sistema para informes de defeitos para a Web, uma série de listas de discussão, e um repositório CVS público. No último ano, houveram duas conferências Internacionais Apachecon, que tratam especificamente do servidor Web e seus usos [95].
O Mozilla é um projeto criado pela Netscape para desenvolver um
navegador Web. O projeto é um dos maiores entre os projetos de software
livre existentes, e é o que conta atualmente com maior apoio financeiro
formal.
Existe uma preocupação nítida com a garantia de qualidade no Mozilla
[96]; uma série de ferramentas de engenharia de software foi
desenvolvida internamente, e o conjunto de documentos detalhando
processo, autoridade e status [97] do projeto exemplifica
o interesse que o grupo tem pelo processo pelo qual o software é
desenvolvido.
O Mozilla conta com uma rede própria de IRC (descrito na seção
3.6.3), uma série de listas de discussão integradas com
Usenet3.4, e
um repositório de informes de defeitos bastante utilizado, o Bugzilla
[98].
A autoridade e responsabilidade no Mozilla é dividida. Existem
proprietários dos módulos principais do sistema [99], e
além disso existe um cargo de driver, que é um responsável por
decidir e incentivar o reparo dos defeitos mais importantes. Além
destes, há ainda um grupo que faz revisão técnicas das alterações
apresentadas, utilizando o Bugzilla integralmente.
Um ponto interessante com o Mozilla é que o desenvolvimento é dirigido pelos informes de erros, e as discussões em torno destes abrangem as salas de IRC e as listas de email. A participação de engenheiros da Netscape continuamente nestes meios de comunicação garante resposta rápida a dúvidas e problemas informados, e é interessante observar como a comunidade trabalha utilizando as ferramentas de forma integrada.
O Gimp é um editor bitmap avançado [100] , que em muito se
assemelha ao Adobe Photoshop. Possui um bom conjunto de ferramentas e
filtros, e uma arquitetura de plug-ins que permitem que seja estendido
livremente.
De todos os projetos descritos, o Gimp é um dos softwares mais completo de recursos; no entanto, seu processo de desenvolvimento é extremamente simples. É mantido por um conjunto de desenvolvedores pequeno, concentrados na Universidade da Califórnia em Berkeley. Embora tenha uma base de usuários muito grande, o Gimp não utiliza uma grande variedade de ferramentas de Engenharia de Software: utiliza as listas de discussão primordialmente para comunicação, e um canal de IRC para manter discussões em tempo real entre desenvolvedores e usuários. Não há um relatório público de status, e até pouco tempo não uma interface independente para informes de erro3.5.
De todos os projetos que foram analisados, e de publicações que tratam
do processo, é possível levantar algumas premissas básicas para o
desenvolvimento de software livre. Essas premissas não são uma regra
geral que deve ser seguida, mas um levantamento entre membros da
comunidade e seus projetos. Uma profundidade melhor desta análise, com
base em dados quantitativos, seria importante.
O primeiro tópico a ser abordado trata de atividades do processo. Deve ficar claro que a lista e o conteúdo das atividades descritas são ainda incompletas pelo fato de existir pouco literatura descritiva.
Existem algumas atividades básicas que são realizadas em grande parte dos projetos de software livre estudados. Estas atividades estão aqui classificadas de acordo com as fases descritas em 2.2.
De forma geral, há pequena ênfase do projeto em especificação de requisitos, e muito raramente há um documento formal de especificação [101]. São conhecidos três fatores principais que motivam esta tendência:
Da forma como estes fatores são colocados, é difícil determinar se a inexistência de requisitos formalizados é um fator negativo de importância para projetos de software livre.
Durante a fase de projeto, em geral se coloca um projeto a nível de
sistema para um software. No entanto, na maior parte dos sistemas de
software livre, não existe uma definição clara da arquitetura do sistema
[101]. Existe pouco material publicado discutindo esta
ausência, e aparentemente é uma falta grave.
É possível que a alta qualidade dos desenvolvedores envolvidos com os projetos, citada por Cook como o fator mais importante para o sucesso de software livre [18], ajude a minimizar este problema. O fato de existir um líder ou grupo de líderes com experiência nos projetos de sucesso, como listado acima, pode ser outra explicação. O fato resta de que existem produtos de software livre sem especificação clara de seu projeto, e no entanto, de sucesso impressionante, como é o caso do Linux.
A codificação de um software livre inicia em geral imediatamente após
sua idealização. Ecoando as idéias colocadas na seção 3.6.1, a
prototipação é uma prática comum, e existe grande impulso para se chegar
a uma versão funcional inicial.
O ponto mais importante em relação ao desenvolvimento a ser colocado é
que é feito integralmente por meio da Internet. Poucos projetos envolvem
desenvolvedores fisicamente próximos, e em geral estes utilizam a
infra-estrutura online para discutir suas idéias de qualquer forma.
Segundo o que se pode levantar do trabalho de Raymond [14], Yamauchi et al. [15], e o processo de codificação se dá da seguinte maneira:
É importante deixar claro que o desenvolvimento é visto como uma atividade bastante individual [102]. Isto significa que durante o processo de codificação de uma alteração, o desenvolvedor trabalha em isolamento; apenas quando deve ser feita a verificação e integração de sua alteração ao repositório de código principal é que entra o caráter colaborativo do software.
A seção anterior descreve implicitamente o que é uma característica
definitiva para software livre: O software está, em quase toda a sua
vida, em produção. A partir do primeiro lançamento, já existirão
usuários interessados (caso o projeto tenha despertado algum interesse)
e todo o impacto de uma versão lançada se aplica; em especial,
compatibilidade de interfaces, desatualização da documentação e
resistência a mudanças. Skillcorn et al. fazem uma revisão sobre o
efeito de alterações de requisitos sobre software em manutenção, e
colocam o problema da seguinte forma [104]:
``Adicionar novos requisitos, remover requisitos parcialmente
implementados, ou alterar significativamente requisitos existentes após
um conjunto mínimo de requisitos ter sido estabelecido, é um problema
comum em manutenção de software. Infelizmente, há poucos métodos,
ferramentas, ou enfoques que tratem do problema hoje...''
Um ponto importante a ser levantado é como projetos de software livre minimizam o impacto de alterações pós-lançamento, já que passam a maior parte de sua vida em manutenção.
Se as atividades básicas do processo de software estão descritas, ainda resta descrever os processos pelos quais estes projetos são controlados. Software Livre desenvolvido de forma colaborativa e distribuída, de acordo com o modelo ``Bazar'' proposto por Raymond [14] utiliza alguns mecanismos de garantia de qualidade. O artigo de Zhao e Elbaum é base importante para esta seção, e é o único estudo direcionado a atividades de qualidade em projetos de software livre [105].
A maior parte do software desenvolvido, hoje, na comunidade, é escrito em linguagens de alto nível [91]. O uso de linguagens de alto nível é apontado por Brooks como sendo um dos principais fatores para a melhora de qualidade e produtividade no desenvolvimento de software [39]. Grande parte dos projetos novos listados no Freshmeat.net [26] são desenvolvidos em Python, Java, PHP e Perl, todas estas sendo linguagens dinâmicas, interpretadas, modernas.
Grande parte dos projetos de software livre hoje utilizam alguma forma
de controle de versão [106], e a absoluta maioria utiliza apenas
uma ferramenta, o CVS [50]. O controle de versão é visto
como uma extensão natural do processo de desenvolvimento, e permite que
se possa paralelizar o desenvolvimento de forma conveniente,
especialmente se tratando de um conjunto muito grande de
desenvolvedores.
É interessante notar que o Linux até hoje não utiliza nenhuma forma oficial de controle de versões, e todas as alterações são trocadas por email [107]. Torvalds é conhecido por pessoalmente analisar a fundo as alterações que são enviadas e integrá-las ao seu repositório principal, embora parte desta tarefa seja hoje dividida com o chefe da versão estável, Cox.
Todos os projetos implementam extensivamente revisão de código. A
revisão acaba acontecendo quase automaticamente, já que as pessoas são
forçadas pela distância a enviar modificações a outras para integração.
Yamauchi et al. estudaram dois casos distintos de projetos de software,
e levantaram respectivamente as proporções de 14% e 34.4% do total de
comunicação como sendo referentes a contribuições a nível de alterações
(patches) ou resultados de testes [15].
Raymond coloca esta revisão de uma forma peculiar: ``Dado olhos
suficientes, todos os defeitos são rasos''. O sentido implícito na frase
é que, embora o desenvolvimento seja feito independentemente, a revisão
de código utiliza a seu favor a grande massa de interessados para
analisar alterações.
Yamauchi et al. colocam de forma interessante o mecanismo social pelo qual é feita a revisão de código: todas as decisões são negociadas com argumentos estritamente técnicos, e o processo de discussão é essencialmente racional. Os autores indicam que esta racionalidade equaliza os participantes e reduz a necessidade de uma hierarquia [15]. Certamente o que se observa nas listas de discussão é que grande parte das mensagens é repleta de justificativas técnicas para defender um ponto de vista.
O uso do termo Beta pode não ser estritamente correto, mas permite um
entendimento mais fácil do modelo de testes usado em projetos de
software livre. Em resumo, todo software é tratado como permanentemente
em Beta, e resultados e opiniões dos usuários são sempre recolhidos. A
natureza do desenvolvimento, que tem caráter contínuo em projetos
ativos, permite que esta atitude seja mantida ao longo do tempo. É muito
infrequente um cenário onde alterações estão expostas a um grupo pequeno
de desenvolvedores; em geral, qualquer usuário pode escolher usar a
versão que desejar [14].
Existe, no entanto, uma divisão ideal em muitos projetos entre uma versão estável, e uma versão instável. A versão estável permite apenas a inclusão de correções de defeitos, enquanto a versão instável permite adição de nova funcionalidade [92]. É possível que esta divisão torne aos usuários menos custoso, efetivamente, estar usando software em desenvolvimento (e portanto teste) contínuo.
Embora não seja uma regra geral, e projetos importantes como o Linux não
tenham um plano de testes formal, existe uma consciência de que o
software deve ser testado antes de seu lançamento. Em geral, este teste
é implementado através de uma suite de testes funcionais que é executada
de forma automática imediatamente antes da instalação do software.
Zhao e Elbaum apontam a ausência de um plano de testes como sendo uma fraqueza potencial do modelo de desenvolvimento utilizado. Segundo estes, a confiança no processo de Revisão de Código e Teste Beta pode não ser justificada, já seu estudo sugere que ocorre menos do que se acreditava previamente [105].
Os projetos de software livre que foram analisados nesta revisão
implementam o uso de pelo menos uma das ferramentas a seguir. É
interessante notar que existem muito poucas ferramentas, e grande
uniformidade entre os projetos de quais são aplicadas. Wilson coloca a
ausência de ferramentas apropriadas como um defeito grave do modelo de
desenvolvimento de software livre [108]; no entanto, Yamauchi
e Bollinger et al. concordam no ponto que o minimalismo auxilia e
simplifica o processo de desenvolvimento de software livre
[15,42].
Como visto na seção 2.7, que tratou de Desenvolvimento de Software Descentralizado, o uso de ferramentas é essencial para software que é desenvolvido desta forma. Toda comunicação tem que ser feita explicitamente por meio de alguma ferramenta, e a habilidade de controlar e verifificar o progresso de um dado projeto, também. As ferramentas discutidas a seguir não representam uma lista exaustiva; foram escolhidas pela sua popularidade e utilização em projetos importantes como o Linux, o Mozilla e o Apache.
A ferramenta de trabalho mais utilizada, e que é usada em todo e
qualquer projeto de software livre, é o email. Toda correspondência
direta entre desenvolvedores, e entre desenvolvedores e os usuários, é
feita desta forma [15].
O email é bastante utilizado por ser um bom denominador comum entre plataformas e línguas ; é esperado que qualquer desenvolvedor tenha acesso conveniente, e que possa se comunicar com clareza através deste meio. O email é utilizado para enviar alterações de código através de patches, e para posteriormente discutir estas mudanças [27].
Uma lista de discussão é um mecanismo de distribuição de emails para um
conjunto de emails de usuários assinantes. Grande parte dos projetos de
software livre tem uma ou mais listas associadas, e a lista se torna um
dos veículos mais importantes de comunicação com os desenvolvedores
[15].
Através das listas, usuários solicitam inovações e comunicam defeitos encontrados. A maior parte das listas é armazenada em um repositório indexado, de forma que é possível pesquisar uma solução nelas posteriormente [84].
Nos últimos dois anos, a comunidade de desenvolvimento de software livre
tem passado a utilizar o IRC como uma forma de comunicação instantânea.
O IRC é um serviço de comunicação em tempo real que implementa um
paradigma de salas (ou canais), onde membros de uma mesma sala podem
comunicar abertamente. Existem diversas redes de IRC, cada rede
suportando um conjunto de canais.
O IRC oferece a possibilidade de obter resposta e discutir assuntos relacionados ao desenvolvimento sem os problemas gerados pela natureza assíncrona do email. O projeto Mozilla utiliza extensivamente o IRC como ferramenta de projeto [98].
O CVS é um software para controle de versões. O CVS é um exemplo de
sucesso entre projetos de software livre; a maior parte dos projetos o
utiliza, e por as características de simplicidade e compatibilidade que
o email oferece [50]. Existe uma interface web para
consultar CVS chamada CVSWeb.
O CVS é largamente documentado e utilizado; no entanto, possui
limitações e inconveniências, como apontado por McDonald
[109]. A falta de integração com outras ferramentas também é
vista como um problema. No entanto, segue sendo largamente utilizado, e
após anos sem lançamentos, o desenvolvimento de uma nova versão foi
registrado recentemente [110]. O sucesso do CVS pode se dever à
sua característica de bom denominador comum, similarmente ao email.
Existem alguns softwares para controlar informes de erros que são
utilizados em projetos de software livre. O Bugzilla é um produto da
organização Mozilla, e é um mecanismo integrado de informes feito para a
Web [111]. O Bugzilla tem um interface interessante de
consultas, pode ser customizado à instalação, e utiliza uma base de
dados relacional associada. O Bugzilla permite controlar informes a
nível de módulos e produtos, tem um sistema integrado de comentários e
anexos, e fornece um mecanismo de controle de acesso.
O GNATS [112] é um outro sistema de controle de informes, sendo este baseado principalmente em email e ferramentas de comando de linha, com uma interface para geração de relatórios baseada na Web.
Existem alguns trabalhos científicos publicados que tratam software
livre do ponto de vista do processo pelo qual é construído:
Yamauchi et al. [15] fazem uma discussão da dependência de
projetos de software livre a meios eletrônicos limitados. Em seu
trabalho, caracterizam os tipos de meio usado nos projetos, e verificam
as formas pelas quais os projetos se coordenam, inovam e concordam
baseados nestes meios. Seu estudo de caso é realizado aplicando
entrevistas e monitoram correspondência dos desenvolvedores em dois
projetos de software livre.
Zhao e Elbaum [105] fazem uma análise das atividades de
qualidade em projetos de software livre, aplicando questionários aos
desenvolvedores e medindo defeitos para caracterizar o uso de testes,
inspeção, linguagens e ferramentas nos projetos estudados.
Cubranic apresenta um trabalho sintético em [113],
descrevendo alguns projetos, e fazendo críticas e elogios a
características específicas do modelo. No artigo, o autor apresenta
algumas sugestões de mudanças ao processo geral de desenvolvimento que
visam permitir a software livre ser aplicado a outros nichos que não
somente software básico.
Feller e Fitzgerald fazem uma análise da metodologia de desenvolvimento
de software livre em [66], utilizando um framework para
classificação de arquiteturas de Sistemas de Informação definido por
Zachman em [114]. Os autores ainda fazem uma breve comparação
entre o modelo RAD [2] e o processo de desenvolvimento de
software livre.
Godfrey e Tu realizam um estudo da evolução do núcleo Linux em
[92], usando medições sobre o código fonte deste. Sua
conclusão é que o perfil de crescimento é ``inesperadamente forte'', e
que o núcleo não apresenta os problemas comuns a projetos de software
tradicionais, como apresentado por Lehman3.7 em [115].
Mockus et al. analisam em [27] o servidor Apache, aplicando um questionário a líderes do projeto, e analisando listas de discussão e uma base de dados de defeitos. Os autores identificaram as métricas a ser usadas utilizando o método Goal Question Metric (GQM) de Basili e Weiss [116].
Existe ainda uma grande quantidade de projetos a ser analisada, de onde podem ser retiradas conclusões importantes sobre o processo pelo qual são desenvolvidos e administrados. Software Livre apresenta algumas características interessantes do ponto de vista dos produtos gerados, e na baixa dependência de infra-estrutura e recursos formais. Tendo em vista estes pontos, será apresentado no próximo capítulo o plano de trabalho, incluindo a metodologia a ser utilizada e as atividades previstas.
Revistos os tópicos relacionados a Processos de Software, e a Projetos de Software Livre, nesta seção são abordados o projeto e a metodologia propostos.
Como colocado na Introdução, o objetivo do projeto é caracterizar o
processo de desenvolvimento que projetos de Software Livre utilizam, e
verificado um processo homogêneo, descrever um modelo para este
processo.
O trabalho constitui um levantamento (survey) de atividades de Engenharia de Software para projetos de software livre. Existem trabalhos anteriores deste tipo; no entanto, são restritos a uma área específica da Engenharia de Software, como o trabalho de Zhao e Elbaum [105], que aborda questões relacionada à garantia de qualidade.
O trabalho aplicará pesquisa de campo na forma de observação direta
intensiva [117,118], de forma exploratória, para
levantar e analisar dados quantitativos e qualitativos a respeito dos
projetos. A intenção é obter dos líderes e participantes das
comunidades de desenvolvimento os aspectos particulares de cada projeto,
e correlacionar estes dados para sintetizar um conjunto comum de
atividades.
Para realizar o levantamento, é necessário definir o conjunto de projetos a ser estudados, e com este conjunto aplicar a pesquisa de campo. Os aspectos importantes que os projetos escolhidos devem contemplar foram determinados do conjunto de projetos apresentados no Capítulo 3. Estes aspectos são:
O levantamento poderá ser feito através de questionários aplicados
individualmente. Para identificar as métricas pode ser utilizada a
metodologia Goal Question Metric (GQM), que já foi aplicada
anteriormente a projetos de Software Livre com sucesso [27].
Definir a metodologia a ser aplicada é uma tarefa a ser cumprida já ao
início do trabalho.
Além do levantamento de dados através de entrevistas individuais, existe
a possibilidade de utilizar os repositórios de dados públicos de cada
projeto. Pode ser analisado e quantificado destes dados um conjunto de
padrões que podem corroborar as conclusões obtidas dos dados
individuais.
As atividades que deverão ser executadas para o cumprimento do trabalho seguem:
A tabela 4.1 detalha um cronograma para estas atividades; a data de início coincide com a entrega do monografia de qualificação, Abril de 2001.
wh1 lg0.5
Christian Reis 2001-05-27
