Comparação entre Metodologias Ágeis e Tradicionaispara o Desenvolvimento de Software

MICHEL DOS SANTOS SOARES1

Unipac - Universidade Presidente Antônio CarlosFaculdade de Tecnologia e Ciências de Conselheiro Lafaiete

BR 482 Km 3 - Gigante CEP 36.400-000 - Conselheiro Lafaiete1michelssoares@yahoo.com.br

Resumo. Este artigo faz uma comparação entre as metodologias tradicionais para desenvolvimento desoftware e as metodologias ágeis. Em particular é feita a comparação da Extreme Programming (XP),uma metodologia ágil muito usada, e o modelo Clássico ou Sequencial. As práticas da XP são apresen-tadas, enfatizando que suas características são ideais para projetos que devem ter um desenvolvimentorápido e que podem ter requisitos alterados constantemente pelos clientes.

Palavras-Chave: Metodologias de Desenvolvimento, Extreme Programming, Modelo Clássico

1 Introdução

Metodologias ágeis têm sido apontadas como uma al-ternativa às abordagens tradicionais para o desenvolvi-mento de software. As metodologias tradicionais, co-nhecidas também como pesadas ou orientadas a plane-jamentos, devem ser aplicadas apenas em situações emque os requisitos do sistema são estáveis e requisitosfuturos são previsíveis. Entretanto, em projetos em quehá muitas mudanças, em que os requisitos são passíveisde alterações, onde refazer partes do código não é umaatividade que apresenta alto custo, as equipes são pe-quenas, as datas de entrega do software são curtas e odesenvolvimento rápido é fundamental, não pode haverrequisitos estáticos, necessitando então de metodolo-gias ágeis. Além disso o ambiente das organizações édinâmico, não permitindo então que os requisitos sejamestáticos.

Processos orientados a documentação para o desen-volvimento de software são, de certa forma, fatores li-mitadores aos desenvolvedores e muitas organizaçõesnão possuem recursos ou inclinação para processos pe-sados de produção de software. Por esta razão, as or-ganizações pequenas acabam por não usar nenhum pro-cesso. Isto pode levar a efeitos desastrosos na qualidadedo produto final, além de dificultar a entrega do soft-ware nos prazos e custos predefinidos. Em particular, omodelo Clássico ou Sequencial será apresentado comoexemplo de metodologia tradicional.

Dentre todas as metodologias ágeis existentes, umaque vem se destacando em número de adeptos e projetosé a Extreme Programming (XP). As metodologias ágeis

surgiram com a proposta de aumentar o enfoque naspessoas e não nos processos de desenvolvimento. Alémdisso, existe a preocupação de gastar menos tempo comdocumentação e mais com resolução de problemas deforma iterativa.

Este artigo apresenta as vantagens e desvantagensdo uso de metodologias ágeis em relação às tradicio-nais. Em particular são feitas comparações entre o mo-delo Clássico e a Extreme Programming.

2 Processos de Software

Um processo de software (ou metodologia de desenvol-vimento de software) é um conjunto de atividades e re-sultados associados que auxiliam na produção de soft-ware. Dentre as várias atividades associadas, existempor exemplo a análise de requisitos e a codificação. Oresultado do processo é um produto que reflete a formacomo o processo foi conduzido.

Embora existam vários processos para o desenvol-vimento de software, existem atividades fundamentaiscomuns a todos eles [Sommerville (2003)]:

Especificação de Software: definição das funcionali-dades (requisitos) e das restrições do software. Ge-ralmente é uma fase em que o desenvolvedor con-versa com o cliente para definir as característicasdo novo software.

Projeto e Implementação de Software: o software éproduzido de acordo com as especificações. Nestafase são propostos modelos através de diagramas,

e estes modelos são implementados em alguma lin-guagem de programação.

Validação de Software: o software é validado para ga-rantir que todas as funcionalidades especificadasforam implementadas.

Evolução de Software: o software precisa evoluir paracontinuar sendo útil ao cliente.

Muitas organizações desenvolvem software sem usarnenhum processo. Geralmente isso ocorre porque osprocessos tradicionais não são adequados às realidadesdas organizações. Em particular, as organizações pe-quenas e médias não possuem recursos suficientes paraadotar o uso de processos pesados. Por esta razão, mui-tas organizações não utilizam nenhum processo. O re-sultado desta falta de sistematização na produção desoftware é a baixa qualidade do produto final, além dedificultar a entrega do software nos prazos e custos pre-definidos e inviabilizar a futura evolução do software.

Existem vários processos de software definidos naliteratura da Engenharia de Software. É comum mesmoalgumas organizações criarem seu próprio processo ouadaptar algum processo à sua realidade. Dentre os váriosprocessos existentes, existem as metodologias tradicio-nais, que são orientadas a documentação, e as metodo-logias ágeis, que procuram desenvolver software com omínimo de documentação.

3 Metodologias Tradicionais

As metodologias tradicionais são também chamadas depesadas ou orientadas a documentação. Essas metodo-logias surgiram em um contexto de desenvolvimento desoftware muito diferente do atual, baseado apenas emum mainframe e terminais burros [Royce (1970)]. Naépoca, o custo de fazer alterações e correções era muitoalto, uma vez que o acesso aos computadores eram li-mitados e não existiam modernas ferramentas de apoioao desenvolvimento do software, como depuradores eanalisadores de código. Por isso o software era todoplanejado e documentado antes de ser implementado.A principal metodologia tradicional e muito utilizadaaté hoje é o modelo Clássico.

3.1 Modelo Clássico

O modelo Clássico ou Sequencial [Pressman (2001)]foi o primeiro processo publicado de desenvolvimentode software. Desde sua introdução tem sido muito uti-lizado. É um modelo em que existe uma sequência a serseguida de uma etapa a outra. Cada etapa tem associ-ada ao seu término uma documentação padrão que deve

Projeto do

Software

Definição de

Requisitos

Implementação e

Teste de Unidades

Integração e

Teste do Sistema

Operação e

Manutenção

Figura 1: Modelo Clássico

ser aprovada para que se inicie a etapa imediatamenteposterior. De uma forma geral fazem parte do modeloClássico as etapas de definição de requisitos, projeto dosoftware, implementação e teste unitário, integração eteste do sistema, operação e manutenção. O problemado modelo em Cascata é sua inflexível divisão do pro-jeto em fases distintas, o que dificulta possíveis altera-ções que são comuns no desenvolvimento de um pro-jeto. É um modelo que deve ser usado somente quandoos requisitos forem bem compreendidos. A figura 1ilustra graficamente o modelo Clássico.

O modelo Clássico dominou a forma de desenvolvi-mento de software até o início da década de 90, apesardas advertências dos pesquisadores da área e dos desen-volvedores, que identificaram os problemas gerados aose adotar esta visão seqüencial de tarefas. Por exem-plo, Fred Brooks em seu famoso artigo “No Silver Bul-let: Essence and Accidents of Software Engineering”,descreve que a idéia de especificar totalmente um soft-ware antes do início de sua implementação é impossível[Brooks (1987)]. Outro pesquisador, Tom Gilb, desen-coraja o uso do modelo Clássico em grandes softwares,estimulando o desenvolvimento incremental como ummodelo que apresenta menores riscos e maiores possi-bilidades de sucesso [Gilb (1999)].

Dados de 1995 [Standish Group, (1995)], utilizandocomo base 8380 projetos, mostram que apenas 16, 2%

dos projetos foram entregues respeitando os prazos eos custos e com todas as funcionalidades especificadas.Aproximadamente 31% dos projetos foram canceladosantes de estarem completos e 52, 7% foram entregues,porém com prazos maiores, custos maiores ou com me-nos funcionalidades do que especificado no início doprojeto. Dentre os projetos que não foram finalizadosde acordo com os prazos e custos especificados, a mé-dia de atrasos foi de 222%, e a média de custo foi de189% a mais do que o previsto. Considerando todos os

projetos que foram entregues além do prazo e com customaior, na média, apenas 61% das funcionalidades ori-ginais foram incluídas. Mesmo os projetos cuja entregaé feita respeitando os limites de prazo e custo possuemqualidade suspeita, uma vez que provavelmente foramfeitos com muita pressão sobre os desenvolvedores, oque pode quadruplicar o número de erros de software,segundo a mesma pesquisa. As principais razões destasfalhas estavam relacionadas com o modelo Clássico. Arecomendação final foi que o desenvolvimento de soft-ware deveria ser baseado em modelos incrementais, oque poderia evitar muitas das falhas reportadas.

4 Metodologias Ágeis

O termo “Metodologias Ágeis” tornou-se popular em2001 quando dezessete especialistas em processos dedesenvolvimento de software representando os méto-dos Scrum [Schwaber e Beedle (2002)], Extreme Pro-gramming (XP) [Beck (1999)] e outros, estabeleceramprincípios comuns compartilhados por todos esses méto-dos. Foi então criada a Aliança Ágil e o estabeleci-mento do “Manifesto Ágil” [Agile Manifesto (2004)].Os conceitos chave do “Manifesto Ágil” são:

Indivíduos e interações ao invés de processos e ferra-mentas.

Software executável ao invés de documentação.

Colaboração do cliente ao invés de negociação de con-tratos.

Respostas rápidas a mudanças ao invés de seguir pla-nos.

O “Manifesto Ágil” não rejeita os processos e ferra-mentas, a documentação, a negociação de contratos ouo planejamento, mas simplesmente mostra que eles têmimportância secundária quando comparado com os in-divíduos e interações, com o software estar executável,com a colaboração do cliente e as respostas rápidas amudanças e alterações. Esses conceitos aproximam-semelhor com a forma que pequenas e médias organi-zações trabalham e respondem a mudanças. Entre asmetodologias ágeis a mais conhecida é a Extreme Pro-gramming.

4.1 Extreme Programming

A Extreme Programming (XP) é uma metodologia ágilpara equipes pequenas e médias que desenvolvem soft-ware baseado em requisitos vagos e que se modificamrapidamente [Beck (1999)]. Dentre as principais dife-renças da XP em relação às outras metodologias estão:

• Feedback constante.

• Abordagem incremental.

• A comunicação entre as pessoas é encorajada.

O primeiro projeto a usar XP foi o C3, da Chrysler.Após anos de fracasso utilizando metodologias tradici-onais, com o uso da XP o projeto ficou pronto em poucomais de um ano [Highsmith et al., (2000)].

A maioria das regras da XP causa polêmica à pri-meira vista e muitas não fazem sentido se aplicadas iso-ladamente. É a sinergia de seu conjunto que sustenta osucesso de XP, encabeçando uma verdadeira revoluçãono desenvolvimento de software.

A XP enfatiza o desenvolvimento rápido do projetoe visa garantir a satisfação do cliente, além de favorecero cumprimento das estimativas. As regras, práticas evalores da XP proporcionam um agradável ambiente dedesenvolvimento de software para os seus seguidores,que são conduzidos por quatro valores: comunicação,simplicidade, feedback e coragem [Beck (1999)]. A fi-nalidade do princípio de comunicação é manter o me-lhor relacionamento possível entre clientes e desenvolve-dores, preferindo conversas pessoais a outros meios decomunicação. A comunicação entre os desenvolvedorese o gerente do projeto também é encorajada. A formade comunicação é um fator chave na XP: procura-se omáximo possível comunicar-se pessoalmente, evitando-se o uso de telefone e o envio de mensagens por cor-reio eletrônico. A simplicidade visa permitir a criaçãode código simples que não deve possuir funções des-necessárias. Por código simples entende-se implemen-tar o software com o menor número possível de classese métodos. Outra idéia importante da simplicidade éprocurar implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser importantesno futuro. A aposta da XP é que é melhor fazer algosimples hoje e pagar um pouco mais amanhã para fazermodificações necessárias do que implementar algo com-plicado hoje que talvez não venha a ser usado, sempreconsiderando que requisitos são mutáveis.

A prática do feedback constante significa que o pro-gramador terá informações constantes do código e docliente. A informação do código é dada pelos testesconstantes, que indicam os erros tanto individuais quantodo software integrado. Em relação ao cliente, o feed-back constante significa que ele terá freqüentemente umaparte do software totalmente funcional para avaliar. Ocliente então constantemente sugere novas característi-cas e informações aos desenvolvedores. Eventuais errose não conformidades são rapidamente identificados ecorrigidos nas próximas versões. Desta forma, a tendên-

cia é que o produto final esteja de acordo com as expec-tativas reais do cliente.

É necessário coragem para implantar os três valoresanteriores. Por exemplo, não são todas as pessoas quepossuem facilidade de comunicação e têm bom rela-cionamento. A coragem também dá suporte à simpli-cidade, pois assim que a oportunidade de simplificaro software é percebida, a equipe pode experimentar.Além disso, é preciso coragem para obter feedback cons-tante do cliente.

A XP baseia-se nas 12 práticas [Beck (1999)] a se-guir:

Planejamento: consiste em decidir o que é necessá-rio ser feito e o que pode ser adiado no projeto.A XP baseia-se em requisitos atuais para desen-volvimento de software, não em requisitos futuros.Além disso, a XP procura evitar os problemas derelacionamento entre a área de negócios (clientes)e a área de desenvolvimento. As duas áreas de-vem cooperar para o sucesso do projeto e cadauma deve focar em partes específicas do projeto.Desta forma, enquanto a área de negócios deve de-cidir sobre o escopo, a composição das versões eas datas de entrega, os desenvolvedores devem de-cidir sobre as estimativas de prazo, o processo dedesenvolvimento e o cronograma detalhado paraque o software seja entregue nas datas especifi-cadas.

Entregas freqüentes visa à construção de um softwaresimples, e conforme os requisitos surgem, há a atu-alização do software. Cada versão entregue deveter o menor tamanho possível, contendo os requi-sitos de maior valor para o negócio. Idealmentedevem ser entregues versões a cada mês, ou nomáximo a cada dois meses, aumentando a possi-bilidade de feedback rápido do cliente. Isto evitasurpresas caso o software seja entregue após muitotempo e melhora as avaliações do cliente, aumen-tando a probabilidade do software final estar deacordo com os requisitos do cliente.

Metáfora são as descrições de um software sem a uti-lização de termos técnicos, com o intuito de guiaro desenvolvimento do software.

Projeto simples: o programa desenvolvido pelo métodoXP deve ser o mais simples possível e satisfazeros requisitos atuais, sem a preocupação de requisi-tos futuros. Eventuais requisitos futuros devem seradicionados assim que eles realmente existirem.

Testes: a XP focaliza a validação do projeto durantetodo o processo de desenvolvimento. Os progra-

madores desenvolvem o software criando primeira-mente os testes.

Programação em pares: a implementação do códigoé feita em dupla, ou seja, dois desenvolvedores tra-balham em um único computador. O desenvolve-dor que está com o controle do teclado e do mouseimplementa o código, enquanto o outro observacontinuamente o trabalho que está sendo feito, pro-curando identificar erros sintáticos e semânticos epensando estrategicamente em como melhorar ocódigo que está sendo implementado. Esses pa-péis podem e devem ser alterados continuamente.Uma grande vantagem da programação em dupla éa possibilidade dos desenvolvedores estarem con-tinuamente aprendendo um com o outro.

Refatoração: focaliza o aperfeiçoamento do projeto dosoftware e está presente em todo o desenvolvimento.A refatoração deve ser feita apenas quando é ne-cessário, ou seja, quando um desenvolvedor da du-pla, ou os dois, percebe que é possível simplificar omódulo atual sem perder nenhuma funcionalidade.

Propriedade coletiva: o código do projeto pertence atodos os membros da equipe. Isto significa quequalquer pessoa que percebe que pode adicionarvalor a um código, mesmo que ele próprio não otenha desenvolvido, pode fazê-lo, desde que faça abateria de testes necessária. Isto é possível porquena XP todos são responsáveis pelo software in-teiro. Uma grande vantagem desta prática é que,caso um membro da equipe deixe o projeto antesdo fim, a equipe consegue continuar o projeto compoucas dificuldades, pois todos conhecem todas aspartes do software, mesmo que não seja de formadetalhada.

Integração contínua: é a prática de interagir e cons-truir o sistema de software várias vezes por dia,mantendo os programadores em sintonia, além depossibilitar processos rápidos. Integrar apenas umconjunto de modificações de cada vez é uma práticaque funciona bem porque fica óbvio quem devefazer as correções quando os testes falham: a úl-tima equipe que integrou código novo ao software.Esta prática é facilitada com o uso de apenas umamáquina de integração, que deve ter livre acesso atodos os membros da equipe.

40 horas de trabalho semanal: a XP assume que nãose deve fazer horas extras constantemente. Casoseja necessário trabalhar mais de 40 horas pela se-gunda semana consecutiva, existe um problema sé-

rio no projeto que deve ser resolvido não com au-mento de horas trabalhadas, mas com melhor pla-nejamento, por exemplo. Esta prática procura ra-tificar o foco nas pessoas e não em processos eplanejamentos. Caso seja necessário, os planosdevem ser alterados, ao invés de sobrecarregar aspessoas.

Cliente presente: é fundamental a participação do cli-ente durante todo o desenvolvimento do projeto.O cliente deve estar sempre disponível para sanartodas as dúvidas de requisitos, evitando atrasos eaté mesmo construções erradas. Uma idéia inte-ressante é manter o cliente como parte integranteda equipe de desenvolvimento.

Código padrão: padronização na arquitetura do código,para que este possa ser compartilhado entre todosos programadores.

5 Comparativo entre as metodologias

A maioria das metodologias ágeis nada possuem de novo[Cockburn et al., (2001)]. O que as diferencia das me-todologias tradicionais são o enfoque e os valores. Aidéia das metodologias ágeis é o enfoque nas pessoase não em processos ou algoritmos. Além disso, existea preocupação de gastar menos tempo com documen-tação e mais com a implementação. De certa forma,apesar da XP ser uma metodologia nova e ser consid-erada por muitos como uma revolução, ela não apre-senta muitos pontos revolucionários. Na verdade, a XPagrupa uma série de práticas que têm sido usadas desdeo início da computação eletrônica, como a programaçãoem duplas e a propriedade coletiva do código.

Uma característica das metodologias ágeis é que elassão adaptativas ao invés de serem preditivas. Com isso,elas se adaptam a novos fatores decorrentes do desen-volvimento do projeto, ao invés de procurar analisarpreviamente tudo o que pode acontecer no decorrer dodesenvolvimento. Essa análise prévia é difícil e apre-senta alto custo, além de tornar-se um problema casonão se queira fazer alterações nos planejamentos. Porexemplo, para seguir estritamente o planejamento, podeser necessário que a equipe trabalhe sobre pressão e façamuitas horas extras, o que prejudica a qualidade do soft-ware.

Para ser realmente considerada ágil a metodologiadeve aceitar a mudança ao invés de tentar prever o fu-turo. O problema não é a mudança em si, mesmo porqueela ocorrerá de qualquer forma. O problema é como re-ceber, avaliar e responder às mudanças. Como exemplo,as aplicações baseadas em Web são melhor modeladas

usando metodologias ágeis, uma vez que o ambienteWeb é muito dinâmico.

As metodologias pesadas devem ser aplicadas ape-nas em situações em que os requisitos do software sãoestáveis e requisitos futuros são previsíveis. Estas situ-ações são difíceis de serem atingidas, uma vez que osrequisitos para o desenvolvimento de um software sãomutáveis. Dentre os fatores responsáveis por alteraçõesnos requisitos estão a dinâmica das organizações, as al-terações nas leis e as mudanças pedidas pelos stake-holders, que geralmente têm dificuldades em definir oescopo do futuro software. Estima-se que caso algumaalteração tenha como custo “1x” quando feita na fasede requisitos, ela terá um custo de “60x a 100x” quandofeita na fase de implantação [Pressman (2001)], ao seusar o modelo Clássico. Portanto, alterações nos requi-sitos no modelo Clássico não são desejáveis.

Por serem relativamente novas, existem poucas fer-ramentas disponíveis que suportam o processo ágil dedesenvolvimento. Dentre as existentes, a maioria su-porta apenas a Extreme Programming e ainda estão emfase de pesquisa e desenvolvimento. A XPlanner é umaferramenta de código livre muito conhecida que suportaa XP, principalmente auxiliando a fase de planejamento[XPlanner, (2004)]. O desenvolvimento desta ferramentaainda está em progresso, mas já existe uma versão es-tável para o gerenciamento de estórias do usuário, geren-ciamento de tarefas, verificação de progresso do projetoe gerenciamento das métricas individuais e da equipe.Dentre as funcionalidades futuras da ferramenta estão aintegração com outras metodologias ágeis, em especiala Scrum.

A XP é ideal para ser usada em projetos em queos stakeholders não sabem exatamente o que desejame podem mudar muito de opinião durante o desenvol-vimento do projeto. Com feedback constante, é possí-vel adaptar rapidamente eventuais mudanças nos requi-sitos. Estas alterações nos requisitos são muitas vezescríticas nas metodologias tradicionais, que não apresen-tam meios de se adaptar rapidamente às mudanças.

Um outro ponto positivo das metodologias ágeis sãoas entregas constantes de partes operacionais do soft-ware. Desta forma, o cliente não precisa esperar muitopara ver o software funcionando, como nas metodolo-gias tradicionais.

A integração e o teste contínuos também possibili-tam a melhora na qualidade do software. Não é maisnecessário existir uma fase de integração de módulos,uma vez que eles são continuamente integrados e even-tuais problemas são resolvidos constantemente.

As metodologias ágeis ainda estão em sua infância,mas já apresentam resultados efetivos. Por exemplo,

um artigo [Charette, R., (2001)] comparando métodoságeis com as metodologias tradicionais pesadas mostrouque os projetos usando os métodos ágeis obtiveram me-lhores resultados em termos de cumprimento de pra-zos, de custos e padrões de qualidade. Além disso,o mesmo estudo mostra que o tamanho dos projetose das equipes que utilizam as metodologias ágeis têmcrescido. Apesar de serem propostas idealmente paraserem utilizadas por equipes pequenas e médias (até 12desenvolvedores), aproximadamente 15% dos projetosque usam metodologias ágeis estão sendo desenvolvi-dos por equipes de 21 a 50 pessoas, e 10% dos projetossão desenvolvidos por equipes com mais de 50 pessoas,considerando um universo de 200 empresas usado noestudo.

6 Conclusão

O desafio futuro das metodologias ágeis é encontrar ma-neiras de eliminar alguns de seus pontos fracos, comoa falta de análise de riscos, sem torná-las metodolo-gias pesadas. Na XP não existe a preocupação formalem fazer a análise e o planejamento de riscos. Comoriscos acontecem normalmente em projetos de desen-volvimento de software, este é um ponto negativo daXP. Deve-se, portanto, procurar implementar uma es-tratégia de gestão de riscos sem tornar a metodologiamuito complexa. Outro desafio é como usar essas me-todologias ágeis em grandes empresas e equipes, umavez que normalmente essas metodologias são baseadasem equipes pequenas. Neste caso, pelo menos é neces-sário resolver os problemas de comunicação internos naequipe, uma vez que é comum em grandes empresas osfuncionários estarem separados geograficamente.

Apesar do interesse crescente no uso das metodolo-gias ágeis, ainda faltam casos de sucesso de seu uso emprojetos grandes e críticos. Quanto mais organizaçõesusem as metodologias ágeis, melhores serão os resulta-dos empíricos em termos de vantagens, desvantagens,riscos e procedimentos para sua adoção nas organiza-ções. Mesmo assim, os resultados iniciais em termosde qualidade, confiança, datas de entrega e custo sãopromissores.

Atualmente o autor está coordenando um projeto depesquisa com o uso de metodologias ágeis para desen-volvimento de sistemas baseados na plataforma Web.Como a Web é um ambiente de desenvolvimento di-nâmico e com mudanças constantes, as metodologiastradicionais orientadas a documentação são menos ade-quadas que as metodologias ágeis. Uma idéia a ser im-plantada futuramente neste projeto de pesquisa é a in-tegração da XP com outras metodologias ágeis, comoa Scrum. Neste caso, os aspectos de planejamento e

gerenciamento de projeto da Scrum serão integradoscom as práticas da XP.

Referências

[Agile Manifesto (2004)] Disponível emhttp://agilemanifesto.org/, acessado em 25de Setembro de 2004.

[Beck (1999)] Beck, K. Programação Extrema Expli-cada. Bookman, 1999.

[Brooks (1987)] Brooks, F. No Silver Bullet: Essenceand Accidents of Software Engineering. Proc.IFIP, IEEE CS Press, pp. 1069-1076; reprinted inIEEE Computer, pp. 10-19, Apr. 1987.

[Charette, R., (2001)] Charette, R. “Fair Fight? Ag-ile Versus Heavy Methodologies”, Cutter Consor-tium E-project Management Advisory Service, 2,13, 2001.

[Cockburn et al., (2001)] Cockburn, A. e Highsmith, J.“Agile Software Development: The Business ofInnovation”, IEEE Computer, Sept., pp. 120-122,2001.

[Gilb (1999)] Gilb, T. Principles of Software Engineer-ing Management. Addison-Wesley, 1988.

[Highsmith et al., (2000)] Highsmith, J. Orr, K. Cock-burn, A. Extreme Programming. E-Business Ap-plication Delivery, Feb., pp. 4-17, 2000.

[Pressman (2001)] Pressman, R. Engenharia de Soft-ware. McGraw-Hill, 2001.

[Royce (1970)] Royce, W.W. Managing the develop-ment of large software systems: concepts andtechniques. 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 deSoftware. Editora Addison-Wesley. 592p, 2003.

[Standish Group, (1995)] CHAOS report, 586 OldeKings Highway. Dennis, MA 02638, USA, 1995.

[XPlanner, (2004)] XPlanner, disponível emhttp://www.xplanner.org/, acessado em 20de Outubro de 2004.