Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software

M ICHEL DOS S ANTOS S OARES 1 Unipac - Universidade Presidente Antnio Carlos Faculdade de Tecnologia e Cincias de Conselheiro Lafaiete BR 482 Km 3 - Gigante CEP 36.400-000 - Conselheiro Lafaiete 1 michelssoares@yahoo.com.br Resumo. Este artigo faz uma comparao entre as metodologias tradicionais para desenvolvimento de software e as metodologias geis. Em particular feita a comparao da Extreme Programming (XP), uma metodologia gil muito usada, e o modelo Clssico ou Sequencial. As prticas da XP so apresentadas, enfatizando que suas caractersticas so ideais para projetos que devem ter um desenvolvimento rpido e que podem ter requisitos alterados constantemente pelos clientes. Palavras-Chave: Metodologias de Desenvolvimento, Extreme Programming, Modelo Clssico 1 Introduo

Metodologias geis tm sido apontadas como uma alternativa s abordagens tradicionais para o desenvolvimento de software. As metodologias tradicionais, conhecidas tambm como pesadas ou orientadas a planejamentos, devem ser aplicadas apenas em situaes em que os requisitos do sistema so estveis e requisitos futuros so previsveis. Entretanto, em projetos em que h muitas mudanas, em que os requisitos so passveis de alteraes, onde refazer partes do cdigo no uma atividade que apresenta alto custo, as equipes so pequenas, as datas de entrega do software so curtas e o desenvolvimento rpido fundamental, no pode haver requisitos estticos, necessitando ento de metodologias geis. Alm disso o ambiente das organizaes dinmico, no permitindo ento que os requisitos sejam estticos. Processos orientados a documentao para o desenvolvimento de software so, de certa forma, fatores limitadores aos desenvolvedores e muitas organizaes no possuem recursos ou inclinao para processos pesados de produo de software. Por esta razo, as organizaes pequenas acabam por no usar nenhum processo. Isto pode levar a efeitos desastrosos na qualidade do produto nal, alm de dicultar a entrega do software nos prazos e custos predenidos. Em particular, o modelo Clssico ou Sequencial ser apresentado como exemplo de metodologia tradicional. Dentre todas as metodologias geis existentes, uma que vem se destacando em nmero de adeptos e projetos a Extreme Programming (XP). As metodologias geis

surgiram com a proposta de aumentar o enfoque nas pessoas e no nos processos de desenvolvimento. Alm disso, existe a preocupao de gastar menos tempo com documentao e mais com resoluo de problemas de forma iterativa. Este artigo apresenta as vantagens e desvantagens do uso de metodologias geis em relao s tradicionais. Em particular so feitas comparaes entre o modelo Clssico e a Extreme Programming. 2 Processos de Software

Um processo de software (ou metodologia de desenvolvimento de software) um conjunto de atividades e resultados associados que auxiliam na produo de software. Dentre as vrias atividades associadas, existem por exemplo a anlise de requisitos e a codicao. O resultado do processo um produto que reete a forma como o processo foi conduzido. Embora existam vrios processos para o desenvolvimento de software, existem atividades fundamentais comuns a todos eles [Sommerville (2003)]: Especicao de Software: denio das funcionalidades (requisitos) e das restries do software. Geralmente uma fase em que o desenvolvedor conversa com o cliente para denir as caractersticas do novo software. Projeto e Implementao de Software: o software produzido de acordo com as especicaes. Nesta fase so propostos modelos atravs de diagramas,

e estes modelos so implementados em alguma linguagem de programao. Validao de Software: o software validado para garantir que todas as funcionalidades especicadas foram implementadas. Evoluo de Software: o software precisa evoluir para continuar sendo til ao cliente. Muitas organizaes desenvolvem software sem usar nenhum processo. Geralmente isso ocorre porque os processos tradicionais no so adequados s realidades das organizaes. Em particular, as organizaes pequenas e mdias no possuem recursos sucientes para adotar o uso de processos pesados. Por esta razo, muitas organizaes no utilizam nenhum processo. O resultado desta falta de sistematizao na produo de software a baixa qualidade do produto nal, alm de dicultar a entrega do software nos prazos e custos predenidos e inviabilizar a futura evoluo do software. Existem vrios processos de software denidos na literatura da Engenharia de Software. comum mesmo algumas organizaes criarem seu prprio processo ou adaptar algum processo sua realidade. Dentre os vrios processos existentes, existem as metodologias tradicionais, que so orientadas a documentao, e as metodologias geis, que procuram desenvolver software com o mnimo de documentao. 3 Metodologias Tradicionais

Definio de Requisitos Projeto do Software Implementao e Teste de Unidades Integrao e Teste do Sistema Operao e Manuteno

Figura 1: Modelo Clssico

As metodologias tradicionais so tambm chamadas de pesadas ou orientadas a documentao. Essas metodologias surgiram em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros [Royce (1970)]. Na poca, o custo de fazer alteraes e correes era muito alto, uma vez que o acesso aos computadores eram limitados e no existiam modernas ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de cdigo. Por isso o software era todo planejado e documentado antes de ser implementado. A principal metodologia tradicional e muito utilizada at hoje o modelo Clssico.
3.1 Modelo Clssico

O modelo Clssico ou Sequencial [Pressman (2001)] foi o primeiro processo publicado de desenvolvimento de software. Desde sua introduo tem sido muito utilizado. um modelo em que existe uma sequncia a ser seguida de uma etapa a outra. Cada etapa tem associada ao seu trmino uma documentao padro que deve

ser aprovada para que se inicie a etapa imediatamente posterior. De uma forma geral fazem parte do modelo Clssico as etapas de denio de requisitos, projeto do software, implementao e teste unitrio, integrao e teste do sistema, operao e manuteno. O problema do modelo em Cascata sua inexvel diviso do projeto em fases distintas, o que diculta possveis alteraes que so comuns no desenvolvimento de um projeto. um modelo que deve ser usado somente quando os requisitos forem bem compreendidos. A gura 1 ilustra gracamente o modelo Clssico. O modelo Clssico dominou a forma de desenvolvimento de software at o incio da dcada de 90, apesar das advertncias dos pesquisadores da rea e dos desenvolvedores, que identicaram os problemas gerados ao se adotar esta viso seqencial de tarefas. Por exemplo, Fred Brooks em seu famoso artigo No Silver Bullet: Essence and Accidents of Software Engineering, descreve que a idia de especicar totalmente um software antes do incio de sua implementao impossvel [Brooks (1987)]. Outro pesquisador, Tom Gilb, desencoraja o uso do modelo Clssico em grandes softwares, estimulando o desenvolvimento incremental como um modelo que apresenta menores riscos e maiores possibilidades de sucesso [Gilb (1999)]. Dados de 1995 [Standish Group, (1995)], utilizando como base 8380 projetos, mostram que apenas 16, 2% dos projetos foram entregues respeitando os prazos e os custos e com todas as funcionalidades especicadas. Aproximadamente 31% dos projetos foram cancelados antes de estarem completos e 52, 7% foram entregues, porm com prazos maiores, custos maiores ou com menos funcionalidades do que especicado no incio do projeto. Dentre os projetos que no foram nalizados de acordo com os prazos e custos especicados, a mdia de atrasos foi de 222%, e a mdia de custo foi de 189% a mais do que o previsto. Considerando todos os

projetos que foram entregues alm do prazo e com custo maior, na mdia, apenas 61% das funcionalidades originais foram includas. Mesmo os projetos cuja entrega feita respeitando os limites de prazo e custo possuem qualidade suspeita, uma vez que provavelmente foram feitos com muita presso sobre os desenvolvedores, o que pode quadruplicar o nmero de erros de software, segundo a mesma pesquisa. As principais razes destas falhas estavam relacionadas com o modelo Clssico. A recomendao nal foi que o desenvolvimento de software deveria ser baseado em modelos incrementais, o que poderia evitar muitas das falhas reportadas. 4 Metodologias geis

Feedback constante. Abordagem incremental. A comunicao entre as pessoas encorajada. O primeiro projeto a usar XP foi o C3, da Chrysler. Aps anos de fracasso utilizando metodologias tradicionais, com o uso da XP o projeto cou pronto em pouco mais de um ano [Highsmith et al., (2000)]. A maioria das regras da XP causa polmica primeira vista e muitas no fazem sentido se aplicadas isoladamente. a sinergia de seu conjunto que sustenta o sucesso de XP, encabeando uma verdadeira revoluo no desenvolvimento de software. A XP enfatiza o desenvolvimento rpido do projeto e visa garantir a satisfao do cliente, alm de favorecer o cumprimento das estimativas. As regras, prticas e valores da XP proporcionam um agradvel ambiente de desenvolvimento de software para os seus seguidores, que so conduzidos por quatro valores: comunicao, simplicidade, feedback e coragem [Beck (1999)]. A nalidade do princpio de comunicao manter o melhor relacionamento possvel entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicao. A comunicao entre os desenvolvedores e o gerente do projeto tambm encorajada. A forma de comunicao um fator chave na XP: procura-se o mximo possvel comunicar-se pessoalmente, evitandose o uso de telefone e o envio de mensagens por correio eletrnico. A simplicidade visa permitir a criao de cdigo simples que no deve possuir funes desnecessrias. Por cdigo simples entende-se implementar o software com o menor nmero possvel de classes e mtodos. Outra idia importante da simplicidade procurar implementar apenas requisitos atuais, evitandose adicionar funcionalidades que podem ser importantes no futuro. A aposta da XP que melhor fazer algo simples hoje e pagar um pouco mais amanh para fazer modicaes necessrias do que implementar algo complicado hoje que talvez no venha a ser usado, sempre considerando que requisitos so mutveis. A prtica do feedback constante signica que o programador ter informaes constantes do cdigo e do cliente. A informao do cdigo dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado. Em relao ao cliente, o feedback constante signica que ele ter freqentemente uma parte do software totalmente funcional para avaliar. O cliente ento constantemente sugere novas caractersticas e informaes aos desenvolvedores. Eventuais erros e no conformidades so rapidamente identicados e corrigidos nas prximas verses. Desta forma, a tendn-

O termo Metodologias geis tornou-se popular em 2001 quando dezessete especialistas em processos de desenvolvimento de software representando os mtodos Scrum [Schwaber e Beedle (2002)], Extreme Programming (XP) [Beck (1999)] e outros, estabeleceram princpios comuns compartilhados por todos esses mtodos. Foi ento criada a Aliana gil e o estabelecimento do Manifesto gil [Agile Manifesto (2004)]. Os conceitos chave do Manifesto gil so: Indivduos e interaes ao invs de processos e ferramentas. Software executvel ao invs de documentao. Colaborao do cliente ao invs de negociao de contratos. Respostas rpidas a mudanas ao invs de seguir planos. O Manifesto gil no rejeita os processos e ferramentas, a documentao, a negociao de contratos ou o planejamento, mas simplesmente mostra que eles tm importncia secundria quando comparado com os indivduos e interaes, com o software estar executvel, com a colaborao do cliente e as respostas rpidas a mudanas e alteraes. Esses conceitos aproximam-se melhor com a forma que pequenas e mdias organizaes trabalham e respondem a mudanas. Entre as metodologias geis a mais conhecida a Extreme Programming.
4.1 Extreme Programming

A Extreme Programming (XP) uma metodologia gil para equipes pequenas e mdias que desenvolvem software baseado em requisitos vagos e que se modicam rapidamente [Beck (1999)]. Dentre as principais diferenas da XP em relao s outras metodologias esto:

cia que o produto nal esteja de acordo com as expectativas reais do cliente. necessrio coragem para implantar os trs valores anteriores. Por exemplo, no so todas as pessoas que possuem facilidade de comunicao e tm bom relacionamento. A coragem tambm d suporte simplicidade, pois assim que a oportunidade de simplicar o software percebida, a equipe pode experimentar. Alm disso, preciso coragem para obter feedback constante do cliente. A XP baseia-se nas 12 prticas [Beck (1999)] a seguir: Planejamento: consiste em decidir o que necessrio ser feito e o que pode ser adiado no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, no em requisitos futuros. Alm disso, a XP procura evitar os problemas de relacionamento entre a rea de negcios (clientes) e a rea de desenvolvimento. As duas reas devem cooperar para o sucesso do projeto e cada uma deve focar em partes especcas do projeto. Desta forma, enquanto a rea de negcios deve decidir sobre o escopo, a composio das verses e as datas de entrega, os desenvolvedores devem decidir sobre as estimativas de prazo, o processo de desenvolvimento e o cronograma detalhado para que o software seja entregue nas datas especicadas. Entregas freqentes visa construo de um software simples, e conforme os requisitos surgem, h a atualizao do software. Cada verso entregue deve ter o menor tamanho possvel, contendo os requisitos de maior valor para o negcio. Idealmente devem ser entregues verses a cada ms, ou no mximo a cada dois meses, aumentando a possibilidade de feedback rpido do cliente. Isto evita surpresas caso o software seja entregue aps muito tempo e melhora as avaliaes do cliente, aumentando a probabilidade do software nal estar de acordo com os requisitos do cliente. Metfora so as descries de um software sem a utilizao de termos tcnicos, com o intuito de guiar o desenvolvimento do software. Projeto simples: o programa desenvolvido pelo mtodo XP deve ser o mais simples possvel e satisfazer os requisitos atuais, sem a preocupao de requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim que eles realmente existirem. Testes: a XP focaliza a validao do projeto durante todo o processo de desenvolvimento. Os progra-

madores desenvolvem o software criando primeiramente os testes. Programao em pares: a implementao do cdigo feita em dupla, ou seja, dois desenvolvedores trabalham em um nico computador. O desenvolvedor que est com o controle do teclado e do mouse implementa o cdigo, enquanto o outro observa continuamente o trabalho que est sendo feito, procurando identicar erros sintticos e semnticos e pensando estrategicamente em como melhorar o cdigo que est sendo implementado. Esses papis podem e devem ser alterados continuamente. Uma grande vantagem da programao em dupla a possibilidade dos desenvolvedores estarem continuamente aprendendo um com o outro. Refatorao: focaliza o aperfeioamento do projeto do software e est presente em todo o desenvolvimento. A refatorao deve ser feita apenas quando necessrio, ou seja, quando um desenvolvedor da dupla, ou os dois, percebe que possvel simplicar o mdulo atual sem perder nenhuma funcionalidade. Propriedade coletiva: o cdigo do projeto pertence a todos os membros da equipe. Isto signica que qualquer pessoa que percebe que pode adicionar valor a um cdigo, mesmo que ele prprio no o tenha desenvolvido, pode faz-lo, desde que faa a bateria de testes necessria. Isto possvel porque na XP todos so responsveis pelo software inteiro. Uma grande vantagem desta prtica que, caso um membro da equipe deixe o projeto antes do m, a equipe consegue continuar o projeto com poucas diculdades, pois todos conhecem todas as partes do software, mesmo que no seja de forma detalhada. Integrao contnua: a prtica de interagir e construir o sistema de software vrias vezes por dia, mantendo os programadores em sintonia, alm de possibilitar processos rpidos. Integrar apenas um conjunto de modicaes de cada vez uma prtica que funciona bem porque ca bvio quem deve fazer as correes quando os testes falham: a ltima equipe que integrou cdigo novo ao software. Esta prtica facilitada com o uso de apenas uma mquina de integrao, que deve ter livre acesso a todos os membros da equipe. 40 horas de trabalho semanal: a XP assume que no se deve fazer horas extras constantemente. Caso seja necessrio trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema s-

usando metodologias geis, uma vez que o ambiente Web muito dinmico. As metodologias pesadas devem ser aplicadas apenas em situaes em que os requisitos do software so estveis e requisitos futuros so previsveis. Estas situaes so difceis de serem atingidas, uma vez que os requisitos para o desenvolvimento de um software so mutveis. Dentre os fatores responsveis por alteraes Cliente presente: fundamental a participao do cli- nos requisitos esto a dinmica das organizaes, as alente durante todo o desenvolvimento do projeto. teraes nas leis e as mudanas pedidas pelos stakeO cliente deve estar sempre disponvel para sanar holders, que geralmente tm diculdades em denir o todas as dvidas de requisitos, evitando atrasos e escopo do futuro software. Estima-se que caso alguma at mesmo construes erradas. Uma idia inte- alterao tenha como custo 1x quando feita na fase ressante manter o cliente como parte integrante de requisitos, ela ter um custo de 60x a 100x quando da equipe de desenvolvimento. feita na fase de implantao [Pressman (2001)], ao se usar o modelo Clssico. Portanto, alteraes nos requiCdigo padro: padronizao na arquitetura do cdigo, sitos no modelo Clssico no so desejveis. para que este possa ser compartilhado entre todos Por serem relativamente novas, existem poucas feros programadores. ramentas disponveis que suportam o processo gil de desenvolvimento. Dentre as existentes, a maioria su5 Comparativo entre as metodologias porta apenas a Extreme Programming e ainda esto em fase de pesquisa e desenvolvimento. A XPlanner uma A maioria das metodologias geis nada possuem de novo ferramenta de cdigo livre muito conhecida que suporta [Cockburn et al., (2001)]. O que as diferencia das mea XP, principalmente auxiliando a fase de planejamento todologias tradicionais so o enfoque e os valores. A [XPlanner, (2004)]. O desenvolvimento desta ferramenta idia das metodologias geis o enfoque nas pessoas ainda est em progresso, mas j existe uma verso ese no em processos ou algoritmos. Alm disso, existe tvel para o gerenciamento de estrias do usurio, gerena preocupao de gastar menos tempo com documenciamento de tarefas, vericao de progresso do projeto tao e mais com a implementao. De certa forma, e gerenciamento das mtricas individuais e da equipe. apesar da XP ser uma metodologia nova e ser considDentre as funcionalidades futuras da ferramenta esto a erada por muitos como uma revoluo, ela no apreintegrao com outras metodologias geis, em especial senta muitos pontos revolucionrios. Na verdade, a XP a Scrum. agrupa uma srie de prticas que tm sido usadas desde A XP ideal para ser usada em projetos em que o incio da computao eletrnica, como a programao os stakeholders no sabem exatamente o que desejam em duplas e a propriedade coletiva do cdigo. Uma caracterstica das metodologias geis que elas e podem mudar muito de opinio durante o desenvolso adaptativas ao invs de serem preditivas. Com isso, vimento do projeto. Com feedback constante, posselas se adaptam a novos fatores decorrentes do desen- vel adaptar rapidamente eventuais mudanas nos requivolvimento do projeto, ao invs de procurar analisar sitos. Estas alteraes nos requisitos so muitas vezes previamente tudo o que pode acontecer no decorrer do crticas nas metodologias tradicionais, que no apresendesenvolvimento. Essa anlise prvia difcil e apre- tam meios de se adaptar rapidamente s mudanas. Um outro ponto positivo das metodologias geis so senta alto custo, alm de tornar-se um problema caso as entregas constantes de partes operacionais do softno se queira fazer alteraes nos planejamentos. Por exemplo, para seguir estritamente o planejamento, pode ware. Desta forma, o cliente no precisa esperar muito ser necessrio que a equipe trabalhe sobre presso e faa para ver o software funcionando, como nas metodolomuitas horas extras, o que prejudica a qualidade do soft- gias tradicionais. A integrao e o teste contnuos tambm possibiliware. Para ser realmente considerada gil a metodologia tam a melhora na qualidade do software. No mais deve aceitar a mudana ao invs de tentar prever o fu- necessrio existir uma fase de integrao de mdulos, turo. O problema no a mudana em si, mesmo porque uma vez que eles so continuamente integrados e evenela ocorrer de qualquer forma. O problema como re- tuais problemas so resolvidos constantemente. ceber, avaliar e responder s mudanas. Como exemplo, As metodologias geis ainda esto em sua infncia, as aplicaes baseadas em Web so melhor modeladas mas j apresentam resultados efetivos. Por exemplo,

rio no projeto que deve ser resolvido no com aumento de horas trabalhadas, mas com melhor planejamento, por exemplo. Esta prtica procura raticar o foco nas pessoas e no em processos e planejamentos. Caso seja necessrio, os planos devem ser alterados, ao invs de sobrecarregar as pessoas.

um artigo [Charette, R., (2001)] comparando mtodos geis com as metodologias tradicionais pesadas mostrou que os projetos usando os mtodos geis obtiveram melhores resultados em termos de cumprimento de prazos, de custos e padres de qualidade. Alm disso, o mesmo estudo mostra que o tamanho dos projetos e das equipes que utilizam as metodologias geis tm crescido. Apesar de serem propostas idealmente para serem utilizadas por equipes pequenas e mdias (at 12 desenvolvedores), aproximadamente 15% dos projetos que usam metodologias geis esto sendo desenvolvidos por equipes de 21 a 50 pessoas, e 10% dos projetos so desenvolvidos por equipes com mais de 50 pessoas, considerando um universo de 200 empresas usado no estudo. 6 Concluso

gerenciamento de projeto da Scrum sero integrados com as prticas da XP. Referncias [Agile Manifesto (2004)] Disponvel http://agilemanifesto.org/, acessado de Setembro de 2004. em em 25

[Beck (1999)] Beck, K. Programao Extrema Explicada. Bookman, 1999. [Brooks (1987)] Brooks, F. No Silver Bullet: Essence and Accidents of Software Engineering. Proc. IFIP, IEEE CS Press, pp. 1069-1076; reprinted in IEEE Computer, pp. 10-19, Apr. 1987. [Charette, R., (2001)] Charette, R. Fair Fight? Agile Versus Heavy Methodologies, Cutter Consortium E-project Management Advisory Service, 2, 13, 2001. [Cockburn et al., (2001)] Cockburn, A. e Highsmith, J. Agile Software Development: The Business of Innovation, IEEE Computer, Sept., pp. 120-122, 2001. [Gilb (1999)] Gilb, T. Principles of Software Engineering Management. Addison-Wesley, 1988. [Highsmith et al., (2000)] Highsmith, J. Orr, K. Cockburn, A. Extreme Programming. E-Business Application Delivery, Feb., pp. 4-17, 2000. [Pressman (2001)] Pressman, R. Engenharia de Software. McGraw-Hill, 2001. [Royce (1970)] Royce, W.W. Managing the development of large software systems: concepts and techniques. Proc. IEEE Westcon, Los Angeles, CA. [Schwaber e Beedle (2002)] Schwaber, K. and Beedle, M., Agile Software Development with Scrum, NJ, Prentice-Hall, 2002. [Sommerville (2003)] Sommerville, I. Engenharia de Software. Editora Addison-Wesley. 592p, 2003. [Standish Group, (1995)] CHAOS report, 586 Olde Kings Highway. Dennis, MA 02638, USA, 1995. [XPlanner, (2004)] XPlanner, http://www.xplanner.org/, de Outubro de 2004. disponvel em acessado em 20

O desao futuro das metodologias geis encontrar maneiras de eliminar alguns de seus pontos fracos, como a falta de anlise de riscos, sem torn-las metodologias pesadas. Na XP no existe a preocupao formal em fazer a anlise e o planejamento de riscos. Como riscos acontecem normalmente em projetos de desenvolvimento de software, este um ponto negativo da XP. Deve-se, portanto, procurar implementar uma estratgia de gesto de riscos sem tornar a metodologia muito complexa. Outro desao como usar essas metodologias geis em grandes empresas e equipes, uma vez que normalmente essas metodologias so baseadas em equipes pequenas. Neste caso, pelo menos necessrio resolver os problemas de comunicao internos na equipe, uma vez que comum em grandes empresas os funcionrios estarem separados geogracamente. Apesar do interesse crescente no uso das metodologias geis, ainda faltam casos de sucesso de seu uso em projetos grandes e crticos. Quanto mais organizaes usem as metodologias geis, melhores sero os resultados empricos em termos de vantagens, desvantagens, riscos e procedimentos para sua adoo nas organizaes. Mesmo assim, os resultados iniciais em termos de qualidade, conana, datas de entrega e custo so promissores. Atualmente o autor est coordenando um projeto de pesquisa com o uso de metodologias geis para desenvolvimento de sistemas baseados na plataforma Web. Como a Web um ambiente de desenvolvimento dinmico e com mudanas constantes, as metodologias tradicionais orientadas a documentao so menos adequadas que as metodologias geis. Uma idia a ser implantada futuramente neste projeto de pesquisa a integrao da XP com outras metodologias geis, como a Scrum. Neste caso, os aspectos de planejamento e