VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

Uma experincia na implantao de processo em uma fbrica de software livre

Regiane Brito, Patrcia Ferreira, Kleber Silva, Vanilson Burgio, Ivan Leite Centro de Informtica Universidade Federal de Pernambuco (UFPE) Caixa Postal 7851, 50732-970, Recife PE Brazil
{rab3,pmf,khfts,vaab,iobl}@cin.ufpe.br

Abstract. Nowadays, the OSS (Open Source Software) development model had gained the attention of TI market, because it appears as a possible estrategic choice that promisses to transform the global software market. However, the firms have been encontering difficulties in the adoption of this model. In these times, didnt exist many experiences that evaluate the efficience of this open source approach as bussiness model. The purpose of this paper is to present a academic experience based on the concept of a distributed software factory [Aaen, 1997] using a development process adapted to the OSS model. Resumo. Ultimamente, o modelo de desenvolvimento OSS (Open Source Software) tem atrado a ateno do mercado de TI, pois surge como uma possvel alternativa estratgica que promete revolucionar a indstria de software mundial. Entretanto, as empresas vm encontrando dificuldades na adoo deste modelo. At hoje, ainda so poucos os experimentos que avaliam com preciso a eficcia da abordagem open source como modelo de negcio. O objetivo deste artigo apresentar um experimento acadmico baseado no conceito de fbrica de software [Aaen, 1997] distribuda utilizando um processo de desenvolvimento adaptado para o modelo OSS.

Introduo

Ultimamente, o modelo de desenvolvimento OSS (Open Source Software) tem atrado a ateno do mercado de TI, tanto no mbito das empresas pblicas quanto das privadas, pois surge como uma possvel alternativa estratgica que promete revolucionar a indstria de software mundial. Alguns acreditam que o desenvolvimento open source ser capaz de transformar a indstria de manufatura de software para uma indstria de software baseada em servios [Sharma, 2002]. Metas como rapidez no desenvolvimento com baixo custo e alta qualidade, que podem ser alcanadas atravs do modelo OSS, tm servido de motivao para que algumas empresas de software busquem adot-lo. Entretanto, as empresas vm encontrando dificuldades na adoo deste modelo, principalmente, por se tratar de um modelo que acarreta uma mudana de paradigma tanto do ponto de vista estrutural e cultural, quanto de processos, o que pode levar a uma modificao profunda no seu modelo de negcios. At hoje, ainda so poucos os experimentos que avaliam com preciso a eficcia da abordagem open source como modelo de negcio [Sharma, 2002]. As dificuldades para realizao desses experimentos vo desde a criao de um adequado processo de desenvolvimento at a criao e manuteno de uma comunidade open source com suas contribuies. 119

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

O objetivo deste artigo apresentar um experimento acadmico baseado no conceito de fbrica de software [Aaen, 1997] distribuda utilizando um processo de desenvolvimento adaptado para o modelo OSS. Este experimento simulou um cenrio com uma caracterstica peculiar, que foi a presena de um cliente com um projeto real a ser executado, obedecendo a cronogramas com prazos bem definidos. Esse tipo de cenrio diferente daqueles comuns do modelo OSS, onde as contribuies so feitas de acordo com a escolha do colaborador. Aqui precisamos utilizar mecanismos para delegao e controle do desenvolvimento, alm de um forte esquema de acompanhamento gerencial para atendimento dos prazos. O projeto em questo ser detalhado posteriormente. Na segunda seo apresentado o contexto relacionado a fbricas de software livre. A terceira seo descreve como a fbrica foi definida. Na quarta seo, so detalhadas caractersticas da aplicao desenvolvida. Na quinta seo apresentada a execuo do processo. Na sexta seo so descritos em quais aspectos o processo evoluiu. Na stima seo, so apresentadas as consideraes finais e na stima seo, as referncias.

Fbricas de Software Livre

Software livre um termo usado para indicar que o software desenvolvido e distribudo sob algum tipo de licena que garanta ao seu usurio liberdades relacionadas ao uso, alterao e redistribuio. Seu aspecto fundamental o fato do cdigo fonte estar livremente disponvel para ser lido, estudado ou modificado por qualquer pessoa interessada [Reis, 2003]. Um projeto de software livre uma organizao composta por um conjunto de pessoas que usa e desenvolve um nico software livre, contribuindo para uma base comum de cdigo-fonte e conhecimento. Este grupo ter sua disposio ferramentas de comunicao e trabalho colaborativo, e um conjunto de experincias e opinies tcnicas que usam para discutir o andamento do projeto [Reis, 2003]. Uma fbrica de software uma organizao que prov servios de desenvolvimento de sistemas com qualidade, a baixo custo e de forma rpida, utilizando um processo de desenvolvimento de software bem definido e com apoio de tecnologias de mercado, alm de reconhecer e lidar com oportunidades de melhoria do processo [Herbsleb, 1999]. Nesse contexto, uma fbrica de software livre aquela que desenvolve projetos de software livre, em sua totalidade ou em parte, e possui um modelo de negcios diferente do modelo tradicional, onde o cdigo fonte do produto no disponibilizado. Hecker (2000) apresenta diferentes modelos de negcio para que empresas interessadas em software livre possam obter lucro.

Definio da fbrica

Eric Raymond (1999) em The Cathedral and the Bazaar, comparou o modelo de programao comercial denominado Catedral e o modelo de desenvolvimento com cdigo aberto denominado Bazaar. Neste ltimo, qualquer um com acesso a Internet e habilidades de programao pode integrar o processo de desenvolvimento do software. 120

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

A proposta do experimento era a construo de uma fbrica de software para o desenvolvimento de projetos de software livre. Para isso, foi necessria a definio do processo a ser utilizado. Por opo da fbrica, foi construda uma Catedral e a integrao com a comunidade foi definida atravs de uma interface externa. O processo foi baseado no RUP (Rational Unified Process) e possua as gerncias de qualidade, configurao e projetos sendo desempenhadas exclusivamente por membros da fbrica. 3.1 Participantes

A fbrica contava com 11 pessoas, entre estudantes e profissionais de Tecnologia da Informao. Com exceo dos papis de gerncia, a mesma pessoa assumiu por vezes um outro papel. Essas pessoas foram divididas de acordo com suas experincias, como mostrado na tabela a seguir.
Tabela 1. Composio da fbrica de software Papel Analista de negcios Arquiteto de software Programador Gerente de Projeto Gerente de Configurao Gerente de Qualidade Responsabilidades Quant.

Elicitar os requisitos com o cliente e garantir que o sistema seja 1 implementado de acordo como foi especificado. Definir a arquitetura do sistema de maneira adequada e 1 acompanhar os programadores nas suas atividades. Implementar o que foi especificado pelo analista de negcios, de 6 acordo com a arquitetura definida. Gerenciar e acompanhar todas as fases do projeto e negociar 1 prazos e entregas com o cliente. Configurar o ambiente de desenvolvimento do projeto, atravs 1 da nomenclatura e localizao dos artefatos gerados. Assegurar que o processo est sendo seguido e criar meios para 1 garantir a qualidade dos artefatos gerados.

3.2

Modelo do processo

As atividades de suporte (configurao, qualidade e projeto) atuam para garantir que o projeto seja realizado como foi esperado, dentro do oramento e prazo definidos. Alm disso, a qualidade do produto deve tentar ser alcanada e o desenvolvimento do projeto deve ser feito de maneira ordenada. Para que todos esses requisitos sejam atendidos, as gerncias de configurao, qualidade e projeto possuam um conjunto de artefatos, onde os principais so o plano de projeto, configurao e qualidade que devem ser preparados to logo o projeto seja iniciado e devem ser seguidos por todas as pessoas envolvidas. O processo de desenvolvimento contm as atividades que compem o ciclo de vida do desenvolvimento de um software [Rocha, 2001]. O modelo do processo de desenvolvimento definido est representado na figura 1. Esse modelo foi construdo de acordo com a notao SPEM (Software Process Engineering Metamodel). Os papis envolvidos so: analista de negcios, arquiteto de software, programador, integrante da comunidade e integrador. O integrante da comunidade uma 121

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

pessoa que est participando no desenvolvimento do projeto atravs da interface com a comunidade de software livre e o integrador a pessoa responsvel por receber as contribuies (internas da fbrica ou da comunidade) e integrar ao produto, podendo ser um integrante da fbrica ou um integrante da comunidade que tenha recebido mrito no desenvolvimento (atravs, por exemplo, de sucessivas contribuies). Esse estilo de premiao visa incentivar a participao da comunidade e conhecido como meritocracia [Raymond, 1999]. Os artefatos obrigatrios previstos so documento de requisitos, documento de arquitetura, resultado de testes e o produto em si. Em relao contribuio da comunidade externa, a mesma deve ser feita da seguinte forma. Um integrante se cadastra como participante do projeto, faz o download do cdigo fonte e documentos disponibilizados. Ento, pode submeter alguma contribuio (informe de bugs ou implementao de nova funcionalidade). Essa submisso vai ser verificada pelo integrador para ver se est de acordo com o que foi especificado no processo. Se a contribuio for relevante e estiver no formado adequado, a mesma ser incorporada ao sistema.

Figura 1 Processo de desenvolvimento

122

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

Projeto Canto Livre: caractersticas e necessidades

O projeto Canto Livre surgiu com o objetivo de criar um espao de convergncia do contedo artstico do Brasil. Do ponto de vista de pesquisadores e amantes das artes, pode ser visto como um local onde possvel encontrar, de forma simples e rpida, grande parte do que foi e produzido no cenrio artstico brasileiro. Do ponto de vista do artista, um meio simples, seguro e igualitrio de criar, produzir, divulgar e distribuir sua arte, sem que seja restrito aos interesses comerciais dos detentores dos j escassos meios de produo, divulgao e distribuio artsticas, incapazes de satisfazer s necessidades dos artistas e dos consumidores das artes. Para isso o sistema deve permitir que os usurios possam cadastrar sua produo artstica e intelectual, assim como localizar e manipular a produo de outros usurios. Alm disso, o sistema deve prover mecanismos para controles autorais, definidos pelos prprios usurios, alm de mecanismos para integrao dos mesmos. Em relao arquitetura, o projeto Canto Livre composto por dois softwares, que, integrados, formam uma rede ponto-a-ponto centralizada (possui servidor). Um dos softwares, mdulo cliente, ser usado diretamente pelos usurios, como aplicaes locais, de onde eles podem inserir e recuperar informaes, ou seja, a produo artstica e intelectual dos prprios usurios. As vrias aplicaes do mdulo cliente podem se comunicar e trocar informaes, da a caracterstica ponto-a-ponto. O segundo software, mdulo servidor, deve controlar o acesso de usurios rede Canto Livre e centralizar o sistema de busca O projeto em si abrange muitas outras funcionalidades, alm de uma ampla discusso sobre o seu contexto de aplicao. O escopo do projeto na fbrica se restringiu s funcionalidades de cadastro e consulta de dados, servio de mensagem instantnea e controle autoral de obras, atravs do uso das licenas Creative Commons [Creative, 2004]. Tambm foi prevista a definio da arquitetura do sistema. A figura 2 descreve a estrutura geral do sistema. O servidor, como centralizador de consultas e os clientes como verdadeiros responsveis pelo controle de arquivos e suas licenas de uso.

Figura 2 Viso Geral da Rede Canto Livre

123

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

O cdigo-fonte do software cliente ser distribudo pela licena CC-GNU GPL (traduo da distribuio do General Public License, da Free Software Foundation para Creative Commons). Como a licena prev, esse cdigo poder ser utilizado em quaisquer outros sistemas no comerciais. O cdigo-fonte do servidor tambm ser distribudo pela licena CC-GNU GLP. Porm, as melhorias sero feitas de forma mais restrita. As modificaes visando melhoria s podero ser feitas por usurios com mrito no desenvolvimento do software cliente.

Desenvolvimento do projeto

Um processo de software particular, da forma como implementado por uma organizao, algo concreto e individualizado: cada equipe de desenvolvimento instancia sua verso. Uma descrio de um processo de software especfico oferece uma forma de entender e avaliar seus objetivos, foras e fraquezas [Reis, 2003]. O desenvolvimento foi dividido em duas fases, a primeira com um projeto pilo e a segunda para o projeto principal. Essa seo descreve como ocorreu o desenvolvimento e a instanciao do processo em relao s duas fases do projeto, fornecendo tambm um histrico desse desenvolvimento em relao colaborao entre os membros da equipe, e destes com o cliente. Para que a fbrica pudesse testar e validar seu processo, primeiramente foi proposto o escopo da fase piloto, cuja premissa era ter um conjunto reduzido de funcionalidades. Na RFP (Request for Proposal) recebida, o cliente solicitava algumas funcionalidades em um sistema existente (descrito na seo 4). A fbrica deveria inserir cadastro de arquivo e usurio e discutir e implementar modelos de segurana para evitar que ocorresse a pirataria em transferncias de arquivos utilizando o sistema. A fbrica teve cinco semanas entre apresentao de propostas tcnica e comercial e entrega do sistema para o cliente. Dificuldades foram encontradas durante o desenvolvimento do projeto piloto. A seguir uma lista de algumas delas: Falta de um gerenciamento eficaz; Falha de comunicao entre os membros da equipe; Falta de conhecimento do processo por todos os integrantes da fbrica; Falta de documentao do projeto desenvolvido a priori pelo cliente; Complexidade do projeto piloto, por se tratar de uma aplicao peer to peer e a fbrica no possuir know how na tecnologia utilizada. Aps um perodo dedicado a ajustes no processo, a fbrica recebeu uma nova RFP referente segunda fase do projeto, onde o cliente solicitava melhorias no cdigo atual (refactory, modularidade e robustez), suporte s licenas do Creative Commons e insero de um servio para troca de mensagens instantneas. Problemas continuaram a ocorrer, em virtude da pouca disponibilidade de alguns membros da equipe que estavam envolvidos com outras atividades. No entanto, o desenvolvimento deste segundo projeto foi mais bem controlado, pois a fbrica passou a 124

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

ter um gerente de projetos dedicado e a equipe j possua conhecimento na tecnologia utilizada. Este desenvolvimento durou oito semanas. A seo 5.1 apresenta questes referentes comunicao e a seo 5.2 discute as ferramentas adotadas pela fbrica. 5.1 Comunicao

Em desenvolvimento distribudo, onde os participantes no esto fisicamente prximos, surgem alguns problemas de comunicao. Herbsleb ( 1 9 9 9 ) d e s c r e v e a l g u n s problemas que prejudicam a comunicao efetiva em equipes distribudas:

Perda d e contato no planejado: o c o r r e em s i t u a e s como encontros no c o r r e d o r o u d u r a n t e o h o r r i o d o almoo, p o r exemplo. Nesses encontros d i s c u t e s e m u i t a c o i s a , i n c l u s i v e a s s u n t o s r e f e r e n t e s a o p r o j e t o em desenvolvimento. Nessas o c a s i e s , podem-se e s c l a r e c e r dvidas s o b r e o p r o j e t o ; Dificuldade em saber quem procurar sobre um problema: o responsvel p o r uma p a r t e d o p r o j e t o ( a r q u i t e t u r a , p o r exemplo) e s t i d e n t i f i c a d o em algum documento ou s i t e e existe um tempo gasto at sua localizao; Custo para i n i c i a r oc o n t a t o : r e f e r e n t e a o f a t o d o desenvolvedor procurar s a b e rs eoo u t r oe s t d i s p o n v e l ;

Perda de confiana para comunicar abertamente: o que leva na maioria das vezes a reunies estritamente formais. Visando diminuir os problemas de comunicao em equipes totalmente distribudas (e porque nesse caso todos os integrantes estavam em uma mesma localidade), os membros da fbrica se reuniam duas vezes por semana para planejar novos passos e acompanhar o progresso dos projetos. Alm dessas reunies presenciais, ferramentas para troca de mensagens instantneas e email tambm eram utilizadas para reunies virtuais e eventuais discusses ou tomada de decises. Tambm foi utilizada uma ferramenta de colaborao via web, onde era possvel atualizar as informaes sobre o projeto. Nessa ferramenta, foram construdas duas vises: uma para o processo, e outra para o projeto. A viso do processo apresentava detalhes de todo o processo que foi definido, possuindo links que permitiam o download dos templates definidos, possibilitando assim sua fcil utilizao. A viso do projeto possua todo o planejamento do gerente do projeto, grficos de acompanhamento, cronograma de atividades, download dos artefatos produzidos. Durante a segunda fase, o cliente passou a acompanhar a entrega dos artefatos a partir desta viso, mais precisamente a partir de links disponibilizados no cronograma. Dessa forma, a fbrica conseguiu acabar com o problema da falta de visibilidade, que foi uma das reclamaes do cliente em relao primeira fase. Outra ferramenta utilizada no desenvolvimento foi o Issue Tracker disponibilizada no site do Tigris, onde estava hospedado o projeto. Atravs dessa 125

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

ferramenta, era possvel controlar as atividades em desenvolvimento na fbrica, sejam elas atividades de correo de bugs ou implementao de novas funcionalidades e at atividades que no envolvessem codificao, por exemplo, gerar o documento de requisitos. A importncia da utilizao dessa ferramenta, aliada as atividades de gerncia s foi percebida aps o desenvolvimento do projeto piloto, onde a fbrica teve problemas em acompanhar a evoluo do desenvolvimento do sistema. Depois que a fbrica passou a utiliz-la, cada desenvolvedor sabia exatamente as atividades que estavam associadas a ele e podia reportar quando a mesma fosse concluda. 5.2 Ferramentas de suporte

Essa seo descreve algumas ferramentas essenciais no desenvolvimento da aplicao. O critrio para escolha das ferramentas que fossem free. Apesar dessa opo por ferramentas free no ter sido imposta, a fbrica se props a testar a viabilidade dessas ferramentas no desenvolvimento de um projeto real. Atlassian Confluence: utilizado como ferramenta de colaborao, onde os membros da fbrica atualizavam o status do projeto e faziam ajustes no processo se necessrio. Essa ferramenta gratuita para projetos open source. Issue Tracker: utilizado para controle de itens a fazer (implementao, correo de bugs). Essa ferramenta est disponvel no Tigris (2004), que uma comunidade open source com intuito de construir melhores ferramentas para o desenvolvimento de software colaborativo. Cada projeto est relacionado com uma das reas de interesse da comunidade. ArgoUML: Ferramenta para modelagem UML. Eclipse: Ambiente de desenvolvimento de aplicaes Java. WinCVS: Cliente da ferramenta de controle de verso. 5.3 Integrao com a comunidade livre

Apesar da proposta de construir uma Fbrica de Software Livre, no houve tempo para receber contribuies de desenvolvedores da comunidade. No entanto, todo o trabalho produzido est disponvel atravs do site do Tigris, onde essa contribuio pode eventualmente ocorrer. Krishnamurthy (2002) e Hecker (2004) apresentam discusses sobre o problema de como fazer com que desenvolvedores participem de um projeto de software livre. Ele apresenta cinco fatores que motivam os participantes de projetos open source: Participar de um projeto intelectualmente estimulante; Melhorar suas habilidades; Ter a oportunidade de trabalhar com um projeto open source; Fornecer suporte ou distribuir o produto; Interesse em customizar o software.

126

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

Evoluo do processo

Nos dias de hoje a competitividade entre as empresas tm levado com que essas procurem melhorar a qualidade dos seus produtos de software. O processo de software tem se mostrado o fator determinante para a qualidade do produto final [Rocha, 2001]. Dessa forma, necessrio que o processo seja constantemente avaliado na tentativa de atingir seu modelo ideal. A seo 6.1 apresenta uma descrio mais detalhadas dos problemas enfrentados em relao a execuo do processo para cada rea e a seo 6.2 como esses problemas foram resolvidos e contriburam para a evoluo do processo. 6.1 Problemas

Durante o desenvolvimento do projeto piloto, foram percebidas algumas dificuldades na utilizao do processo, principalmente porque o mesmo estava muito sobrecarregado de atividades e a fbrica no possua pessoal disponvel para sua execuo. Devido a isso, alguns processos no foram completamente executados. A seguir uma descrio dos principais problemas por rea: Vendas: Houve falta de apoio tcnico para auxiliar o vendedor na definio do escopo do projeto, causando uma definio incompleta e gerando atrasos na entrega final. Ainda, houve pouco contato com o cliente para esclarecimentos e falta de comunicao com a equipe para auxlio na estimativa de esforo, o que gerou uma estimativa menor que o necessrio. Gerncia de projetos: Este processo no foi executado completamente devido a indisponibilidade do gerente de projetos. Alm disso, no houve um acompanhamento da equipe, levando a uma falta de controle sobre o status do projeto. Garantia de qualidade: O processo de garantia da qualidade foi parcialmente seguido. As revises no foram realizadas formalmente em todos os artefatos. Ainda, a auditoria dos processos realizada envolveu uma pequena parte da fbrica e a auditoria de produto no foi realizada. O relatrio de post-mortem tambm no foi realizado, pois a equipe estava concentrada na finalizao do produto. Gerncia de Configurao: O software para controle de mudanas, Atlassian Jira [Jira, 2004] apresentou vrios problemas e teve que ser substitudo pelo Issue Tracker da Collabnet (disponvel atravs do site do Tigris). Essa mudana no trouxe maiores problemas porque a equipe ainda no havia comeado a utilizar o Jira. O principal problema dessa rea foi a falta de um treinamento eficaz para todos os integrantes da fbrica e a falta de compromentimento da equipe em ler e seguir o plano de configurao. Desenvolvimento: Foi o processo mais prejudicado, devido, principalmente, ao atraso na concluso dos planos de configurao e projeto, falta de acompanhamento do gerente de projeto e erros na estimativa de esforo. Este projeto foi parcialmente executado e sua execuo no foi linear, uma vez que a equipe de desenvolvimento teve de se deter mais na codificao para

127

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

conseguir atender aos prazos estabelecido, levando a insatisfao e sobrecarga dos integrantes dessa equipe. 6.2 Calibragem

Devido ao fato que apenas alguns processos foram completamente executados, a avaliao adequada de todos os processos definidos foi prejudicada. No entanto, para todos os processos, a equipe conseguiu identificar oportunidades de melhoria atravs dos problemas enfrentados. Na fase de calibragem do processo, foram definidos ajustes onde algumas atividades ficaram como opcionais e outras foram retiradas, adequando tambm alguns templates dos artefatos propostos. A seguir as principais alteraes no processo, por rea: Vendas: As atividades de vendas passaram a ser realizadas por um analista de negcios, e o escopo do sistema passou a ser mais bem definido. Alm disso, muitos dos artefatos foram descartados, deixando apenas as propostas tcnica e comercial. Gerncia de projetos: Houve a necessidade da criao de alguns artefatos, como a matriz de rastreabilidade. Alm disso, a utilizao de uma ferramenta de colaborao via web [Atlasian, 2004] tornou mais efetivo o acompanhamento da equipe distribuda. Gerncia de configurao: Passou-se a adotar um modelo mais rgido de integrao de cdigo fonte que abrangesse contribuies da comunidade de software livre. Esse novo modelo passou a adotar o papel de um integrador, semelhante como ocorre nas comunidades de software livre. Essa pessoa responsvel por receber, analisar e incorporar as submisses. Esse processo foi simulado com os integrantes da prpria fbrica, durante o desenvolvimento da segunda fase do projeto. Garantia de qualidade: Foram retirados alguns artefatos que tornavam o processo lento, sem impacto nas atividades definidas. A reviso tambm se tornou mais gil atravs da utilizao da ferramenta de Issue Tracker para controle de revises e da insero de comentrios no prprio documento que estava sendo revisado. Desenvolvimento: O documento de requisitos foi modificado e passou a conter tambm a definio dos casos de uso. Alm disso, houve a verticalizao da rea atravs da definio de responsveis por cada grupo (codificao, anlise, arquitetura e teste). Os responsveis de cada rea eram encarregados de distribuir as tarefas. Alm das alteraes citadas acima, a fbrica passou a adotar uma pesquisa semanal de satisfao do cliente sob a responsabilidade da equipe de qualidade, para que possveis problemas fossem detectados e corrigidos antes da concluso do projeto. A figura 3 apresenta essa evoluo no decorrer do desenvolvimento.

128

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

Figura 3 Acompanhamento do nvel de satisfao do cliente

Aps esses ajustes, o desenvolvimento do projeto principal pde ser mais bem controlado. Alm disso, devido fbrica estar mais experiente em relao ao processo, modificaes dinmicas puderam ser propostas e incorporadas.

Consideraes Finais

Esse artigo apresentou a experincia de uma equipe formada por estudantes e profissionais de TI na concepo de uma Fbrica de Software Livre, onde houve a definio de um processo de software e desenvolvimento de projetos para um cliente real. Ou seja, simulou-se um ambiente real com presses (de prazos, cronograma, entregas) e problemas (entre os membros da fbrica e entre esses e o cliente) tambm reais onde todos tiveram muitas lies aprendidas. Em relao a um processo de software para projetos open source para cliente reais, pde-se perceber que este deve ser o mais simples possvel e adaptvel (ajustvel) de acordo com as necessidades do projeto em desenvolvimento. O processo definido teve pontos considerados positivos: Apesar da resistncia inicial na utilizao do processo de gerncia de configurao, a garantia de que sempre a fbrica tinha uma verso pronta para ser entregue (pois o integrador garantia isso) justifica sua utilizao; A existncia de um gerente dedicado e realizando acompanhamentos imprescindvel em qualquer projeto; Pesquisas com clientes servem como indicativos de que o processo precisa evoluir. Aps uma anlise dos problemas enfrentados e do processo como um todo, pontos negativos tambm foram encontrados, em especial: No houve treinamento e divulgao adequada do processo no startup da fbrica; O processo no cobria planos de contingncia; 129

VI Simpsio Internacional de Melhoria de Processos de Software

So Paulo, SP Brasil 24-26/11/2004 www.simpros.com.br

No havia um padro ou template para atribuio das issues e notificao de bugs, o que essencial quando se trata de uma equipe distribuda. Contudo, a experincia adquirida na concepo dessa fbrica de software foi bastante importante, principalmente por ser uma experincia prtica pouco convencional em cursos de ps-graduao. No entanto, ainda h muito que definir em relao a Fbricas de Software Livre, principalmente em relao integrao desta com comunidades livres.

Referncias

Aaen, I., Bottcher, P. and Mathiassen, L. (1997). The Software Factory: Contributions and Illusions. In: Proceedings of the Twentieth Information Systems Research Seminar in Scandinavia, Oslo. ArgoUML (2004), http://argouml.tigris.org/, Agosto. Atlassian Confluence (2004), http://www.atlassian.com/software/confluence/, Agosto Atlassian Jira (2004), http://www.atlassian.com/software/jira, Outubro. Creative Commons (2004),http://www.creativecommons.org, Agosto. Eclipse (2004). Eclipse, http://www.eclipse.org/, Agosto. Hecker, F. (2004). Setting Up Shop:The Business of Open-Source Software, http://www.hecker.org/writings/setting-up-shop.html, Novembro. Herbsleb, J. D., Grinter, R. E. (1999). Splitting the Organization and Integrating the Code: Conways Law Revisited. In: Proceedings of ICSE. Los Angeles: IEEECSP, 1999. p. 8595 Krishnamurthy, S (2002). Cave or Community? An Empirical Examiniation of 100 Mature Open Soruce Projects. First Monday, v. 7, n. 6 http://www.firstmonday.dk/issues/issue7 6/krishnamurthy/, Junho. Raymond, Eric S.(1999) The cathedral and the Bazaar. Sebastopol, CA, USA: OReilly. Reis, C. (2003). Caracterizao de um processo de software para projetos de software livre Dissertao de mestrado do ICMC de So Paulo. Rocha, A. R, Maldonado, J.C, Weber, K. C. (2004) Qualidade de Software: Teoria e Prtica. Prentice Hall Sharma, S., Sugumaran, V. and Rajagopalan, B. (2002) A framework for creating hybrid-open source software communities. Software Process Engeneering Metamodel, Version 1.0 http://www.omg.org/technology/documents/formal/spem.htm, Outubro. WinCVS (2004). WinCVS, http://www.wincvs.org/, Agosto. (2004),

Tigris.org (2004). Open Source Software Engineering, http://www.tigris.org, Agosto.

130