Universidade Estadual de Campinas Faculdade de Tecnologia

Aysy Anne Andrade Duarte Willian Alves Barboza

Gerenciamento de Projetos Open Source

Limeira, 2010

Universidade Estadual de Campinas Faculdade de Tecnologia

Aysy Anne Andrade Duarte Willian Alves Barboza

Gerenciamento de Projetos Open Source

Trabalho apresentado Faculdade de Tecnologia da UNICAMP. Limeira, 2010

Resumo
Um desafio constante na produo de software , alm de atender as necessidades dos clientes, atend-las respeitando os prazos contratuais com qualidade no produto. Alguns trabalhos acreditam que para chegar ao software ideal seja necessrio seguir regras, metodologias. Por outro lado surgem projetos open source que geralmente no seguem essas regras, mas conseguem chegar ao objetivo final mostrando qualidade e segurana. Para se chegar nessa qualidade, alguns projetos open source utilizam a metodologia Bazar, que atravs da colaborao existente nas comunidades consegue chegar produo de um software de qualidade, e ainda transfere conhecimento para os demais membros, sem nenhuma remunerao financeira, mas sim pelo reconhecimento pessoal. Neste trabalho ser apresentada breve introduo ao termo open source em seguida uma descrio de como realizado o gerenciamento de projetos de open source, suas caractersticas, regras e aspectos como qualidade.

Abstract

A constant Challenge in software production is not just to see needs customers, but also assist it see the contractual deadline. Some works believe that to reach in "ideal software" is necessary to follow rules and metholologies. On the other hand appear open source projects that use the methodology Bazaar, which through the existing collaboration in open source communities not only to produce a quality software as well as transfer knowledge to other members without any financial remuneration and over by personal recognition.

Sumrio
Lista de Figuras .......................................................................................................................... vi 1.1 1.2 1.3 Motivao .................................................................................................................... 2 Objetivos...................................................................................................................... 2 Estrutura do Trabalho ................................................................................................... 2

Captulo 2: Processos de Desenvolvimento de Software .............................................................. 3 2.1 Modelos de Processos de Software ..................................................................................... 3 Captulo 3: Processo de Desenvolvimento de Software Open Source ........................................... 6 3.1 Definio ........................................................................................................................... 6 3.2 Caractersticas dos Projetos Open Source ........................................................................... 6 3.3 Organizao ....................................................................................................................... 7 Captulo 4. Gerenciamento de Projetos Open Source ............................................................. 10 4.1 Metodologia Bazar ........................................................................................................... 10 4.2 Qualidade ........................................................................................................................ 11 4.3 Desenvolvimento ............................................................................................................. 11 4.4 Especificar Requisitos ...................................................................................................... 11 4.5 Lanamento de verses .................................................................................................... 12 Concluses ................................................................................................................................ 13 Referncias Bibliogrficas ......................................................................................................... 14

Lista de Figuras
Figura 1. Diagrama do ciclo de vida cascata de Winston Royce na dcada de 70. ..................... 4 Figura 2. Modelo de desenvolvimento evolucionrio. ............................................................... 5 Figura 3. Possvel diagrama de um projeto open source. ........................................................... 7

1. Introduo

Verifica-se um constante desafio na produo de software, pois no essencial apenas atender as necessidades dos clientes, alm disso, necessrio atender os prazos, produzir software com qualidade e atender as normas contratuais que podem causar alteraes no valor final do software. Pensando em minimizar imprevistos durante o processo de produo, manuteno e finalizao do software, surgiram vrios estudos acadmicos que tratam como deve ser o processo de desenvolvimento de software. De acordo com Sommerville em (SOMMERVILLE, I. 2007, p.5), Engenharia de software uma disciplina de engenharia relacionada a todos os aspectos de produo de software, ou seja, ela abrange todas as etapas de desenvolvimento de software, atravs de teorias, regras, ferramentas e mtodos que iro auxiliar na produo. Atravs dessas metodologias pretende-se chegar ao software ideal, ou seja, realizar a produo de uma ferramenta que atenda aos interesses tanto dos desenvolvedores quanto dos clientes, sem que ocorra eventuais imprevistos. E para que essas metodologias sejam seguidas algumas bibliografias como (SOMMERVILLE, I. 2007) e (PRESSMAN, R. 1997) esboam possveis padres a serem seguidos. Essa padronizao vem sendo seguida em algumas equipes de desenvolvimento, onde cada um recebe uma funo ou cargo, tornando responsvel por determinada etapa do processo de desenvolvimento e assim dando origem a uma equipe. Entretanto, de acordo com (A Catedral e o Bazar Eric S. Raymond,) essa padronizao no a nica soluo para o sucesso de um software, pode-se alcanar o sucesso atravs de colaboraes de pessoas que no tenham qualquer funo determinada ou que no tenham que cumprir com prazos ou normas, mtodo que o autor denomina como Bazar. Verifica-se o uso dessa conduta principalmente nos projetos open source (FUGGETA, A. 2003), que em alguns projetos foi fundamental para garantir o sucesso, como por exemplo, o GNU/Linux, o Apache e o Mozilla. Mediante o sucesso dos projetos open source que utilizam a metodologia Bazar para o desenvolvimento, este trabalho ir descrever como se d esse processo de desenvolvimento ajudando na compreenso dessa metodologia.

1.1 Motivao
Verifica-se que nos ltimos anos houve um aumento no nmero de publicaes que buscam fornecer alternativas que demonstrem como as equipes voltadas para projetos open source, conseguem alcanar o sucesso, porm poucos conseguem abordar o assunto sobre o modelo e metodologia que so aplicados.

1.2 Objetivos
O objetivo desse trabalho mostrar atravs do levantamento das principais caractersticas dos projetos open source como alguns desses projetos conseguem obter sucesso fugindo dos processos considerados como clssicos por alguns autores. Dessa forma, alm de mostrar como esse modelo pode ajudar no gerenciamento desses projetos, mostram umas das formas de como ocorre o gerenciamento de alguns projetos open source.

1.3 Estrutura do Trabalho

No captulo 2 realizada uma breve descrio de alguns processos de software clssicos da literatura. O captulo 3 destinado explicao do termo open source e suas principais caractersticas. O capitulo 4 mostra o gerenciamento de projetos open source, atravs da exposio de ideias de alguns estudiosos desse tema, alm de fazer uma breve explicao dos modelos Catedral e Bazar e por ltimo a concluso deste trabalho.

Captulo 2: Processos de Desenvolvimento de Software

Sommerville (SOMMERVILLE, I. 2007, p.5), descreve processo de software como: Um conjunto de atividades cujo objetivo o desenvolvimento ou a evoluo do software , esse conjunto composto por atividades consideradas fundamentais para o desenvolvimento do software, das quais se destacam:

Especificao: atividade destinada a descobrir e definir as funcionalidades e limitaes que existiro no software, em alguns casos h a participao dos clientes para definir as funcionalidades. Desenvolvimento: atividade destinada programao do software, ou seja, inicia o desenvolvimento do cdigo fonte atravs de implementaes j determinadas de acordo com as especificaes que j foram definidas. Validao e verificao: atividade destinada para verificar se as funcionalidades do software esto de acordo com o especificado nos processos, para revisar as especificaes. Documentao: atividade realizada para documentar as funcionalidades, cdigo fonte e possveis alteraes no decorrer do desenvolvimento.

2.1 Modelos de Processos de Software

Existem alguns modelos elaborados por alguns autores como Winston Royce em (ROYCE, W., 1970. p. 19.), que prope o modelo cascata. Nesse modelo fica claro as divises entre as atividades envolvidas no desenvolvimento do projeto. A Figura 2 ilustra claramente o modelo cascata.

Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance

Figura 1.

Diagrama do ciclo de vida cascata de Winston Royce na dcada de 70.

J no modelo evolucionrio, no h uma sequncia linear, pois nesse modelo o software produzido e lanado gradualmente, sendo assim, para cada ciclo de lanamento realiza-se as atividades de acordo com as necessidades do projeto. Sommerville em (SOMMERVILLE, I. 2007, p.45), sugere que o modelo evolucionrio torna-se mais eficaz que o cascata, pois no modelo evolucionrio a especificao poder ser desenvolvida de forma incremental, conforme as necessidades dos usurios, porm esse modelo tem seus problemas, porque em alguns casos podem produzir sistemas com problemas estruturais. A Figura 2 (SOMMERVILLE, I. 2007, p.46) ilustra esse modelo.

Concurr ent activities Specification Initial version

Outline description

Development

Intermediate versions

Validation

Final version

Figura 2.

Modelo de desenvolvimento evolucionrio.

Outro modelo conhecido o modelo de sequncia, pois determina uma sequncia linear das atividades do projeto, de acordo com esse modelo trabalha-se primeiro com os requisitos para depois passar para codificao, testes e assim por diante. Entretanto um modelo que dificilmente tende a ser seguido, pois raramente surgem software desenvolvidos nesse modelo, porque muito difcil seguir uma sequncia linear das tarefas envolvidas no projeto.

Captulo 3: Processo de Desenvolvimento de Software Open Source 3.1 Definio

A discusso de sobre software open source inicia-se j na prpria definio, pois seu sentido pode variar de acordo com determinados contextos, porm no o foco desse trabalho gerar discusses filosficas. De acordo com Fuggetta, open source pode ser definido como: qualquer software cuja licena garante ao seu usurio liberdade relacionada 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 (Fuggetta, A.,2003, p.77), Dessa forma, ele define em poucas palavras a complexidade que existe em torno da definio desse termo.

3.2 Caractersticas dos Projetos Open Source

Embora existam vrias discusses filosficas em torno dos projetos open source, ele possui caractersticas bem definidas pela comunidade que o torna diferente dos projetos convencionais, essas caractersticas so: Planejamento: em virtude das atividades serem realizadas por diversos colaboradores de diferentes pases, nem sempre possvel realizar planejamento das atividades. Desenvolvimento voluntrio: Alguns desenvolvedores realizam trabalhos sem receber qualquer ajuda financeira, para essas pessoas, a recompensa vem atravs do aprendizado, interesses por novos desafios e o prazer de compartilhar o conhecimento na comunidade. Flexibilidade na escolha da funo: no existe uma regra que determine a funo do colaborador, o que existe nesse caso bom senso entre os colaboradores, dessa forma, na maioria das vezes colaboradores iniciantes so designados para exercerem funes mais bsicas, porm nada impede que um usurio mais experiente entre na comunidade gerenciando um projeto ou realizando programao avanada. 6

No existe horrio determinado: nesse caso, o prprio colaborador realiza e define a jornada de trabalho, alguns colaboradores j possuem um emprego fixo e colaboram nas horas de folga, alm disso, deve-se levar em conta o grande nmero de colaboradores que moram em diferentes pases de diferentes fusos, culturas e etnias. Lanamento constante de verses: por ter um trabalho voluntrio e sem compromisso com prazo ou normas contratuais, o software lanado quando a equipe determina que j seja uma verso funcional, solucionar seus erros e realizar melhorias ocorrem com o passar do tempo. Usurio colaborador: o prprio usurio do software pode sugerir melhorias e ideias para a comunidade, alm disso, ele pode tornar-se um colaborador em qualquer momento. Distribuio eletrnica ou por mdia: a distribuio pode ser realizada atravs da internet: por e-mail, sites ou mdias (CDR ou DVDR). Descentralizao: no h um local fsico especifico para reunir os colaboradores, dessa forma em alguns casos as discusses e sugestes so encaminhadas para uma lista de e-mail ou fruns de discusses voltados comunidade.

3.3 Organizao
Embora exista uma flexibilidade em determinadas caractersticas desse projeto, pode-se definir uma mnima organizao de como ocorre o desenvolvimento do software. A Figura3 (REIS, C., 2001 p. 15) ilustra como funciona a organizao de projetos open source.

Figura 3.

Possvel diagrama de um projeto open source.

Observa-se que h um repositrio onde todos os cdigos-fontes so armazenados e que os desenvolvedores pertencem ao grupo de usurios, pois conforme explicado anteriormente, nesse tipo de projeto os usurios podem exercer a funo de desenvolvedores tambm. O repositrio mantido atravs de ferramentas existentes na internet e possui um controle rigoroso de verses atravs de ferramentas especificas para o controle de verso, um exemplo o CVS atravs do auxilio dessa ferramenta possvel que vrios colaboradores trabalhem com o mesmo cdigofonte. Alm disso, as funcionalidades do CVS permitem que os colaboradores no precisem ficar conectados a internet enquanto realizam as correes ou aprimoramento do cdigo-fonte, sendo possvel que o colaborador realize as alteraes em uma cpia local. As alteraes realizadas nos arquivos sero notificadas no repositrio onde cada arquivo alterado receber uma identificao numrica, evitando assim eventuais confuses no repositrio, alm disso, o CVS permite que ocorra facilmente a comparao entre as alteraes realizadas nas cpias locais com qualquer outra verso que esteja no repositrio on-line. Outro fator muito importante na organizao de projetos open source so os eventuais papis que os colaboradores envolvidos no projeto exercem. Esses papis podem ser definidos como:

Usurios participativos: so usurios que alm de usarem o software desenvolvido pela comunidade, tambm contribuem para o projeto, atravs da informao de erros e de sugestes para melhorar ou implementar novas funcionalidades no software. Dessa forma esses usurios acabam exercendo a funo de testadores do software. Usurios no participativos: so usurios que no manifestam qualquer interesse em discutir, opinar ou ajudar no desenvolvimento do software, podem at encontrar erros ou desejarem modificaes, porm no informam, apenas usam o software. Desenvolvedores casuais: so usurios com conhecimentos em desenvolvimento de software e capazes de realizar alteraes no cdigo fonte, suas alteraes em alguns casos so alteraes de carter pessoal, ou seja, para ajudar em problemas que esto no dia-dia pessoal.

Desenvolvedores ativos: so pessoas que tem participao constante nos projetos, nesse caso verifica-se uma possvel responsabilidade com a comunidade, pois suas alteraes no cdigo fonte so mais complexas e extensas. Embora exista essa classificao de alguns papis, no se verifica nenhuma norma ou regra que proba a troca de papis entre os colaboradores, muito pelo cont rrio, essa troca no s permitida como uma das diferenciaes existentes nesse tipo de projeto em relao aos demais. Como nem todos os colaboradores se encontram no mesmo territrio, a marca registrada para comunicao entre eles a internet, pois ser atravs dela que muitos dos colaboradores iro se comunicar, discutir, opinar e sugerir novas ferramentas. A comunicao pode ser realizada atravs de e-mails, lista de discusses e fruns da comunidade, dessa forma elimina as barreiras geogrficas, culturais e tnicas. Alguns desses colaboradores dificilmente se encontraro pessoalmente, pois o foco nesse caso no reunir todos em um nico ambiente e sim possibilitar que cada colaborador possa contribuir por livre e espontnea vontade. Outra caracterstica marcante nesse tipo de projeto a disponibilidade do software para os usurios. O acesso pode vir atravs de download realizado em sites da prpria comunidade ou atravs da distribuio direta entre os colaboradores o que de certa forma, ajuda a popularizar os aplicativos e ao mesmo tempo torn-lo o mais acessvel possvel, alm disso, quanto maior o nmero de pessoas que utilizem o software e contribua para a comunidade, maior ser o sucesso do projeto.

Captulo 4. Gerenciamento de Projetos Open Source

Os projetos realizados na forma clssica ou Catedral conforme definio de Raymond em (RAYMOND, E. S., 1999. 2778 p.), so gerenciveis atravs de padres pr-estabelecidos de acordo com suas necessidades, sempre respeitando um padro hierrquico, onde os integrantes j possuem um papel definido e que prazos, cronogramas e metas devem ser cumpridas com rigor. inegvel que essas metodologias clssicas consigam sucesso, porm a metodologia empregada nos projetos open source so totalmente diferentes, pois no h preocupao com prazos, os papis so definidos pelos prprios integrantes, flexibilidade nos horrios de trabalho, em alguns casos nenhum tipo de comprometimento ou remunerao financeira e mesmo assim verifica-se um grande sucesso nesses projetos. Raymond no s enfatiza isso, como tambm (RAYMOND, E. S., 1999.), comenta sobre as caractersticas de gerenciamento de projetos open source, compartilha sua experincia pessoal ao elaborar um projeto seguindo esses moldes de produo.

4.1 Metodologia Bazar

Raymmond em (RAYMOND, E. S., 1999.), descreve o modelo Bazar como uma forma de trabalho descentralizada, atravs da participao de voluntrios e sem preocupao com prazos. Nesse modelo, a participao de pessoas voluntrias, que no recebem nenhum auxlio financeiro e esto no projeto apenas para cooperar e compartilhar seus conhecimentos. Nesse modelo no h uma definio formal dos papis, um modelo totalmente informal, no h prazos, h trocas constante de responsabilidades, as verses do software so disponibilizadas constantemente e os prprios membros utilizam e j relatam os erros e sugestes para serem implementadas.

10

4.2 Qualidade
Na parte de qualidade, os colaboradores designados para essa tarefa, ter como responsabilidade controlar a qualidade do software. Esse controle de qualidade inclui identificar problemas em geral no projeto, revisar e exercer uma auditoria. Caso seja uma pessoa seja responsvel por revisar o cdigo, ela poder exercer os seguintes papis: Moderadores: so os colaboradores responsveis dela gerencia de reviso; Revisores: colaboradores responsveis por encontrar os erros existentes no cdigo fonte; Documentadores: colaboradores responsveis por documentar e registrar os resultados obtidos na reviso do cdigo fonte; A realizao constante desse controle de qualidade muito provavelmente resultar na produo de software cada vez mais confivel.

4.3 Desenvolvimento
Nesta parte do projeto encontra-se a fase de produo do cdigo fonte, as correes de erros e implementaes de sugestes viveis. Alm disso, considera-se esta fase um pouco formal, pois cada tempo de desenvolvimento varia de acordo com o projeto.

4.4 Especificar Requisitos

Em alguns casos, software open source no se inicia depois da especificao formal de requisitos, e sim na fase de desenvolvimento. Os projetos que seguem as especificaes de requisitos tem uma vantagem considerada, pois os desenvolvedores j tem uma noo sobre as funcionalidades do software antes de sarem programando. O ideal nessa fase documentar todas as alteraes realizadas no cdigo fonte de forma que outro desenvolvedor que acesse essas alteraes, consiga identificar onde ocorreram as alteraes e, alm disso, deixar justificado o motivo de cada alterao. 11

4.5 Lanamento de verses

Essa fase do processo depende do colaborador que foi designado como gerente de release, nesse caso, ele ter a funo de construir mdulos dos projetos e realizar o controle de verso, atravs disso possvel encontrar os erros existente e que precisam ser solucionados para que depois consiga disponibilizar uma verso que apresente as funcionalidades essncias para a viabilidade do software. Depois se deve disponibilizar a verso para a comunidade, atravs de sites, servidores e mdias. E conforme usurios venham a utilizar o software e detectar possveis erros.

12

Concluses
Em virtude da grande popularizao e aceitao dos projetos open source (RAYMOND, E. S., 1999 p 2.) percebe-se que embora no funcione de acordo com as maiorias dos padres clssicos sugeridos para desenvolvimento, no deixa de ser um grupo de software de qualidade, e que o principal fator para essa popularizao a forma de como reunir vrias pessoas de diferentes localidades a colaborarem, disponibilizar seus conhecimentos e idias atravs de listas de e-mails. Verifica-se que em alguns casos h pessoas que realizam colaboraes em suas horas vagas e que no se preocupa com retorno financeiro, apenas em ajudar demais pessoas, ou em alguns situaes apenas para promover desafios pessoais. Por ser um projeto que envolva pessoas com diferentes problemas, projetos open source podem possuir um processo de evoluo constante, pois para alguns colaboradores determinada verses j atenderem as suas necessidades at o momento e para outros ainda precise de aperfeioamentos, e nada impede que essas incrementaes continuem. Sendo assim, pode-se definir que se trata de um estilo de desenvolvimento que valoriza principalmente a participao ativa de seus colaboradores, pois e atravs dessa atuaes que erros, sugestes e manuteno do software seja realizada rapidamente

13

Referncias Bibliogrficas
SOMMERVILLE, I. Engenharia de Software. 8th ed., Addison-Wesley, 2007. 5 7 p. SOMMERVILLE, I. Engenharia de Software. 8th ed., Addison-Wesley, 2007. PRESSMAN, R. S. Software Engineering: A practitioners approach. 4th. ed. McGrawHill,1997. 2253 p. FUGGETA, A. Open source software - an evaluation., Journal of Systems and Software. 7790 p. SOMMERVILLE, I. Engenharia de Software. 8th ed., Addison-Wesley, 2007. 5 7 p.
ROYCE, W. W. Managing the development of large software systems. In: Proceedings of IEEE WESCON. [S.l.: s.n.], 1970. p. 19.

SOMMERVILLE, I. Engenharia de Software. 8th ed., Addison-Wesley, 2007. SOMMERVILLE, I. Engenharia de Software. 8th ed., Addison-Wesley, 2007.45 p. FUGGETA, A. Open source software - an evaluation., Journal of Systems and Software. 7790 p. SOMMERVILLE, I. Engenharia de Software. 8th ed., Addison-Wesley, 2007. CHRISTIAN, R. Caracterizao de um Modelo de Processo para Projetos de Software , 2001. 15 p. RAYMOND, E. S. The Cathedral and The Bazaar. In: The Cathedral and The Bazaar. 1st ed. Sebastopol: OReilly and Associates, 1999. 2778 p. RAYMOND, E. S. The Cathedral and The Bazaar. In: The Cathedral and The Bazaar. 1st ed. Sebastopol: OReilly and Associates, 1999. 2 p.

14