Curso de Engenharia de Computação ABORDAGENS SOBRE...
66
Curso de Engenharia de Computação ABORDAGENS SOBRE MÉTODOS DE DESENVOLVIMENTO DE SOFTWARE Jeferson Teixeira Campinas – São Paulo – Brasil Dezembro de 2008
-
Upload
truongliem -
Category
Documents
-
view
216 -
download
0
Transcript of Curso de Engenharia de Computação ABORDAGENS SOBRE...
Curso de Engenharia de Computação
ABORDAGENS SOBRE MÉTODOS DE DESENVOLVIMENTO
DE SOFTWARE
Jeferson Teixeira
Campinas – São Paulo – Brasil
Dezembro de 2008
Curso de Engenharia de Computação
ABORDAGENS SOBRE MÉTODOS DE DESENVOLVIMENTO
DE SOFTWARE
Jeferson Teixeira
Monografia apresentada à disciplina de Trabalho de Conclusão do Curso de Engenharia de Computação da Universidade São Francisco, sob a orientação do Prof. Doutor Adalberto Nobiato Crespo, como exigência parcial para conclusão do curso de graduação. Orientador: Prof. Doutor Adalberto Nobiato Crespo
Campinas – São Paulo – Brasil
Dezembro de 2008
Abordagens sobre métodos de desenvolvimento de software
Jeferson Teixeira
Monografia defendida e aprovada em 11 de Dezembro de 2008 pela
Banca Examinadora assim constituída:
Professor Dr. Adalberto Nobiato Crespo (Orientador)
USF – Universidade São Francisco – Campinas – SP.
Professor M.Sc. Claudio Maximiliano Zaina
USF – Universidade São Francisco – Campinas – SP.
Professor Esp. Ricardo César Boaretto
USF – Universidade São Francisco – Campinas – SP.
Dedico este trabalho a minha noiva e futura
esposa, Elisa Alonso, por me apoiar em todos os
momentos.
Dedico também a meus pais, Jair Teixeira e
Jocely Rodrigues Teixeira, por todo o carinho e
dedicação em toda minha vida.
v
.Agradecimentos
Agradeço a Deus por me ter guiado até aqui e por ter me dado a oportunidade
de ser quem eu sou.
Agradeço a minha noiva e futura esposa, Elisa Alonso, por sempre
demonstrar seu amor, apoio e dedicação.
Agradeço a meus pais por todo carinho e dedicação em todos os momentos
da minha vida, sempre estando prontos para me ajudar e me orientar.
Agradeço a todos os professores que tive durante toda a minha vida, que me
ensinaram valores que levarei comigo para sempre.
Agradeço, finalmente, a meu orientador, Prof. Doutor Adalberto Nobiato
Crespo, por ter aceitado me orientar e me conduzir durante toda a realização deste
trabalho.
vi
Sumário
Lista de Siglas ......................................................................................................................................vii
Lista de Figuras...................................................................................................................................viii
Resumo ..................................................................................................................................................ix
Abstract ...................................................................................................................................................x
1 Introdução........................................................................................................................................1 1.1 Contextualização .......................................................................................................................1 1.2 Objetivo ......................................................................................................................................4 1.3 Estrutura do Texto .....................................................................................................................5
2 Métodos de desenvolvimento de software...................................................................................6 2.1 Metodologias tradicionais de desenvolvimento de software .....................................................8
2.1.1 Método cascata ............................................................................................................... 10 2.1.2 Método espiral ................................................................................................................. 13 2.1.3 Outros métodos tradicionais de desenvolvimento de software....................................... 15
2.1.3.1 Prototipação ..............................................................................................................15 2.1.3.2 RUP ...........................................................................................................................15
2.2 Métodos ágeis de desenvolvimento de software.....................................................................17 2.2.1 Origem dos métodos ágeis de desenvolvimento de software......................................... 18 2.2.2 Valores ágeis ................................................................................................................... 21 2.2.3 Características comuns entre métodos tradicionais e métodos ágeis ............................ 25 2.2.4 Scrum .............................................................................................................................. 27 2.2.5 XP .................................................................................................................................... 33 2.2.6 Outros métodos ágeis...................................................................................................... 37
2.2.6.1 Crystal Methods.........................................................................................................37 2.2.6.2 Feature-Driven Development (FDD) .........................................................................38 2.2.6.3 Dynamic Systems Development Method (DSDM) ....................................................38
3 Projeto Desenvolvido ...................................................................................................................40 3.1 Levantamento de necessidades e requisitos...........................................................................40 3.2 Interação com o cliente............................................................................................................41 3.3 Número de indivíduos que compõe a equipe de desenvolvimento.........................................42 3.4 Grau de maturidade dos indivíduos que compõe a equipe de desenvolvimento....................42 3.5 Prazos e custos da construção de um software ......................................................................43 3.6 Testes e entrega do software para o cliente............................................................................44 3.7 Manutenção do software em produção ...................................................................................44 3.8 Conclusão ................................................................................................................................46
3.8.1 Vantagens dos métodos ágeis em relação aos métodos tradicionais ............................ 46 3.8.2 Desvantagens dos métodos ágeis em relação aos métodos tradicionais ...................... 49 3.8.3 Características necessárias que uma equipe de desenvolvimento de software deve ter para utilizar métodos ágeis ............................................................................................................ 50
3.9 Contribuições ...........................................................................................................................53 3.10 Trabalhos futuros .....................................................................................................................54
Referências Bibliográficas ..................................................................................................................55
vii
Lista de Siglas
CMMI Capability Maturity Model Integration
DSDM Dynamic Systems Development Method
FDD Feature-Driven Development
MPS.BR Melhoria de Processos de Software Brasileiro
RAD Rapid Application Development
RUP Rational Unified Process
UP Unified Process
XP Extreme Programming
viii
Lista de Figuras
Figura 1 – Histórico de publicação de metodologias de desenvolvimento de software..........................7
Figura 2 – Método cascata....................................................................................................................11
Figura 3 – Método Espiral......................................................................................................................14
Figura 4 – Fases e volume de atividades para cada atividade do RUP................................................16
Figura 5 – Comparação de custo de mudança entre cascata e XP......................................................22
Figura 6 – Ciclo de desenvolvimento do Scrum....................................................................................31
Figura 7 – Valores e práticas de XP......................................................................................................35
Figura 8 – Esquema do Crystal Methods..............................................................................................37
ix
Resumo
Este trabalho descreve os princípios básicos do métodos tradicionais e dos métodos ágeis de
desenvolvimento de software, apresentando suas principais características e definições.
Os métodos tradicionais de desenvolvimento de software são abordados nesse trabalho
devido a sua grande utilização na indústria de software e também devido a sua importância histórica,
por se tratarem dos primeiros métodos de desenvolvimento de software criados, em especial o
método cascata, que foi o primeiro método de desenvolvimento de software utilizado pela indústria de
software e, em alguns lugares, é utilizado até hoje.
Continuando o enfoque em relação aos métodos tradicionais, é descrito o método Espiral,
que foi o primeiro método que utilizou técnicas iterativas e incrementais, e também são brevemente
citados os outros métodos tradicionais de desenvolvimento (Prototipação e RUP).
Já em relação aos métodos ágeis de desenvolvimento de software, é descrita a origem
desses métodos bem como os valores ágeis, definidos através do Manifesto Ágil, que compõe quatro
definições básicas dos métodos ágeis de desenvolvimento de software.
Os métodos Scrum e XP são apresentados e detalhados, dando enfoque em suas principais
características. Os dois métodos foram escolhidos por serem atualmente os mais utilizados entre os
adeptos aos métodos ágeis de desenvolvimento.
O trabalho se encerra com a comparação entre os métodos tradicionais e os métodos ágeis,
analisando algumas de suas características comuns. Também é feita a análise em relação as
vantagens e desvantagens de se utilizar métodos ágeis de desenvolvimento de software.
Por fim, são levantadas as características básicas que uma equipe de desenvolvimento de
software deve ter para que a utilização de métodos ágeis seja viável e garanta a qualidade do
software gerado ao final do processo de desenvolvimento
PALAVRAS-CHAVE: Desenvolvimento de Software, Métodos ágeis, Métodos Tradicionais, Scrum,
XP, Cascata, Espiral.
x
Abstract
This paper describes the basic principles of traditional methods and agile methods of software
development, presenting their main characteristics and settings.
Traditional methods of software design are discussed in this work because of their great use in
the software industry and also because of its historical importance, they were the first methods of
developing software created, especially the cascade method, which was the first method of developing
software used by the software industry and in some places, is used today.
Continuing the focus on the traditional methods, the method is described Spiral, which was the
first method that used techniques recursive and incremental, and are also briefly mentioned the other
traditional methods of development (Prototyping and RUP).
Already in the methods of agile software development, is described the origin of such methods
as well as the values agile, defined by the Manifesto agility, which comprises four categories of basic
methods of agile software development.
The methods Scrum and XP are presented and detailed, focusing on its main features. The
two methods were chosen because they are currently the most widely used among supporters of agile
methods of development.
The paper concludes with a comparison between traditional methods and agile methods to
analyze some of their common characteristics. It's also done the analysis on the advantages and
disadvantages of using agile methods of software development.
Finally, it raised the basic features that a team of software design must have for the use of
agile methods to be viable and ensure the quality of software generated at the end of the development
process.
KEY WORDS: Software development, Agile methods, Traditional methods, Scrum, XP, Waterfall,
Spiral
1
1 INTRODUÇÃO
1.1 Contextualização
Os avanços tecnológicos vistos no último século e no início do século atual fizeram com que o
software tenha papel imprescindível em diversos segmentos de atividades da sociedade atual. Cada
vez mais equipamentos eletrônicos, que utilizam softwares de vários tipos para controlarem seu
funcionamento, têm feito parte do cotidiano das pessoas, tanto na indústria, como no comércio e em
domicílios.
Essa crescente demanda por novos produtos tecnológicos aumenta proporcionalmente a
demanda por desenvolvimento de novos softwares e conseqüentemente implica na busca por novas
maneiras mais apropriadas de desenvolvê-los.
Visto isto, torna-se claro que o aumento do mercado de software seja um fato consumado na
sociedade atual. O aumento desde mercado também o tornou mais competitivo, fazendo com que as
necessidades para desenvolvimento de software evoluam cada vez mais rapidamente e exigindo
cada vez mais a necessidade de se adaptar a essas mudanças.
A falta de envolvimento e comprometimento das pessoas que retinham o conhecimento sobre
o problema, aliado a coleta de requisitos muito instáveis, ocasionou na constatação de que vários
métodos de desenvolvimento de software se demonstrassem impróprios.
No CHAOS Report de 1994 [Chaos], 365 empresas colaboraram com a avaliação de 3682
projetos, demonstrando que 83,2% foram cancelados ou entregues excedendo o orçamento ou o
prazo estimado. Dentre esses projetos, o custo foi em média 89% acima do previsto e o atraso médio
foi de 122% além do planejado. Os participantes também declararam as principais razões para esses
resultados e apenas seis fatores representaram juntos a 60,35% das possíveis causas. Esses fatores
são: requisitos incompletos, falta de envolvimento de usuários, mudanças de requisitos e
especificações, falta de apoio da equipe de negócios, falta de recursos e expectativas não-realistas
[Filho2008].
A Engenharia de Software tem como intuito principal buscar melhores formas de se projetar e
desenvolver software para que problemas com relação a cumprimento de prazos e controle de custos
de projetos de software sejam cada vez mais otimizados.
2
Uma grande quantidade de pessoas tem trabalhado em pesquisas de metodologias que
auxiliam a equipe de projeto de um determinado software a gerenciar todos os aspectos que
envolvem a sua produção.
É inegável que grandes evoluções têm surgido nessa área, mas com as constantes
mudanças do mercado de software mundial � a necessidade de se desenvolver software com alta
qualidade, baixo custo e em prazos cada vez mais curtos � exigem que novas metodologias de
desenvolvimento sejam projetadas, estudadas e implementadas para atender essas mudanças.
Várias comunidades de desenvolvimento de software espalhadas pelo mundo, com a
consciência de que a qualidade dos softwares desenvolvidos estava muito aquém do necessário,
fizeram várias tentativas de melhorar o desenvolvimento de softwares, resultando em modelos tais
como: Unified Process (UP), Cleanroom Software Engineering e Rapid Application Development
(RAD) que apostaram em alternativas que se baseiam em processos pré-definidos. Também foram
criados modelos de certificação para validar a aplicação dos processos. Nesse quesito se destacam o
Capability Maturity Model Integration (CMMI), ISO 9000-3 e o modelo de Melhoria de Processos de
Software Brasileiro (MPS.BR). Mas “apesar das boas intenções dessas iniciativas, todas abordam o
desenvolvimento de software como um processo que pode ser repetido mecanicamente, tentando
enquadrá-lo em uma linha de produção.” [Filho2008]
Um dos grandes problemas das metodologias desenvolvidas no início da história da
Engenharia de Software é o grande formalismo nos modelos de processos propostos, que vão à
contramão do desenvolvimento de software exigido atualmente � software de qualidade, com
desenvolvimento rápido e de baixo custo.
Apesar de hoje em dia ser facilmente possível adquirir um software em lojas de shopping
center, supermercados e até mesmo em bancas de jornal, o desenvolvimento de um software segue
padrões muito diferentes do desenvolvimento da maioria dos bens de consumo, como um avião, por
exemplo. No caso de um avião, as maiores necessidades são em relação à matéria prima necessária
e quais ferramentas utilizar. Após construir a primeira unidade de um avião é possível determinar
quais ferramentas serão utilizadas e a quantidade de matéria prima necessária para se construir um
novo avião. Além disso, a replicação de um avião pode seguir uma linha de montagem
completamente automatizada, sem necessidade de intervenção humana. Já no caso de software, o
problema não está relacionado com a replicação do mesmo, já que depois de pronto, um software
3
pode ser facilmente replicado a custo praticamente zero. O grande problema do software está em seu
desenvolvimento, já que não há matéria prima palpável para tal.
Na década de 90 começaram a surgir pesquisas em relação a metodologias de
desenvolvimento de software que resultou no surgimento do que hoje são chamados métodos ágeis
de desenvolvimento de software.
As metodologias desenvolvidas anteriormente ao surgimento dos métodos ágeis tinham como
fundamento básico a documentação e a previsibilidade dos processos. Elas buscavam levantar todas
as necessidades e requisitos do software e entender todo o domínio do problema antes de iniciar o
desenvolvimento. Depois que todas as necessidades e requisitos do sistema são levantados e
analisados, é feito um planejamento para gerenciar todas as mudanças que podem ocorrer durante o
processo de desenvolvimento do software.
Já os métodos ágeis de desenvolvimento de software optam pela adaptabilidade. Métodos
ágeis partem do pressuposto de que é praticamente impossível levantar todas as necessidades e
requisitos de um software antes do início do seu desenvolvimento. Nos métodos ágeis os requisitos
são levantados no decorrer do andamento do projeto e o planejamento é sempre contínuo, de modo
que as adaptações as alterações dos requisitos possam ocorrer. Os métodos ágeis compreendem
vários processos para desenvolvimento de software, levando em conta técnicas iterativas e
incrementais baseadas em equipes auto organizadas, auto gerenciáveis e multifuncionais. A
interação social entre os indivíduos que desenvolvem o software, o pleno funcionamento do software
acima de uma documentação compreensível e a rápida resposta as mudanças ao invés de se seguir
um plano previamente determinado são premissas básicas dos métodos ágeis de desenvolvimento de
software.
Levando-se em conta que os métodos ágeis têm como foco principal pequenas equipes e que
85% das empresas de software dos EUA – maior produtor mundial de software – são consideradas
pequenas [Filho2008], a pesquisa e o aprimoramento desses métodos tem se tornado cada vez mais
constante e importante.
4
1.2 Objetivo
O principal objetivo deste trabalho é comparar métodos tradicionais e métodos ágeis de
desenvolvimento de software e demonstrar quais as vantagens e desvantagens que os métodos
ágeis têm em relação aos métodos tradicionais.
Também é objetivo deste trabalho apresentar quais características uma equipe de
desenvolvimento de software deve ter para que a utilização de métodos ágeis seja viável e garanta
que o software entregue tenha a qualidade esperada pelo cliente
A comparação entre os métodos apresentados será realizada analisando uma série de
características comuns que os dois métodos têm para o desenvolvimento de um projeto de software.
Essas características comuns compreendem o ciclo completo de desenvolvimento de um
software, passando pelas fases de análise, projeto, desenvolvimento, testes e manutenção de um
software. As características comuns que serão comparadas neste trabalho são: levantamento de
requisitos e necessidades, necessidade de interação com o cliente, número de indivíduos que
compõe a equipe de desenvolvimento, grau de maturidade desses indivíduos, prazos e custos da
construção de um software, testes e entrega do software para o cliente e, por fim, a manutenção do
software já completamente disponibilizado e em produção.
No capítulo que contém os resultados e a conclusão do trabalho serão apresentadas e
detalhadas as vantagens e as desvantagens que os métodos ágeis têm em relação aos métodos
tradicionais de desenvolvimento de software através da análise realizada de cada característica
comum apresentada.
Também serão apresentadas quais são as características necessárias que uma equipe de
desenvolvimento de software deve ter para que a utilização de métodos ágeis seja viável e garanta a
qualidade do software gerado ao final do processo de desenvolvimento.
No final do trabalho serão apresentados dois temas que poderão ser desenvolvidos em
estudos futuros, utilizando-se como base os resultados deste trabalho.
5
1.3 Estrutura do Texto
Para ajudar o leitor na leitura do texto, o mesmo está dividido da seguinte maneira:
O capítulo 2 faz uma abordagem geral sobre métodos de desenvolvimento de software.
O item 2.1 define os métodos tradicionais de desenvolvimento de software, dando ênfase
para os métodos Cascata no item 2.1.1 e o método Espiral no item 2.1.2, enquanto no item 2.1.3. são
brevemente descritos outros métodos tradicionais
Já no item 2.2 são definidos os métodos ágeis de desenvolvimento de software. No item 2.2.1
é descrita a origem dos métodos ágeis. Os valores ágeis definidos no Manifesto Ágil são descritos no
item 2.2.2 e no item 2.2.3 são definidas as características comuns entre os métodos ágeis e os
métodos tradicionais. Em relação à métodos ágeis, no item 2.2.4 é detalhado o método Scrum,
enquanto no item 2.2.5 é detalhado o método XP, deixando para o item 2.2.6 uma breve descrição de
outros métodos ágeis.
O capítulo 3 contém o desenvolvimento do projeto, com as explanações sobre os objetivos
apresentados, utilizando os itens descritos no capitulo 2 para apresentar os argumentos que
justificam as conclusões obtidas em relação aos objetivos definidos no início do trabalho. É feita a
comparação entre os métodos tradicionais e os métodos ágeis de desenvolvimento, bem como as
vantagens e desvantagens de se utilizas métodos ágeis de desenvolvimento de software e também
quais as características necessárias uma equipe de desenvolvimento de software deve ter para
utilizar métodos ágeis durante um projeto de software.
O capítulo 4 contém a conclusão do trabalho, onde são mostrados os resultados obtidos pela
comparação entre os métodos tradicionais e os métodos ágeis de desenvolvimento. Também são
mostradas as vantagens e desvantagens de se utilizar métodos ágeis de desenvolvimento de
software e, por fim, são concluídas quais são as características necessárias uma equipe de
desenvolvimento de software deve ter. No item 4.1 são apresentadas as contribuições que este
trabalho oferece para os seus leitores e no item 4.2 são apresentados trabalhos futuros que podem
utilizar este trabalho como base para o seu desenvolvimento.
6
2 MÉTODOS DE DESENVOLVIMENTO DE SOFTWARE
Neste capítulo descreveremos algumas das principais metodologias de desenvolvimento de
software utilizadas por empresas na construção de softwares. Será dada uma visão geral nessas
principais metodologias, sem se aprofundar em detalhes específicos de cada metodologia. Caso o
leitor se interesse em se aprofundar em alguma metodologia citada, poderá utilizar as referências
citadas durante o texto para tal.
Primeiramente faremos um breve relato sobre métodos tradicionais de desenvolvimento de
software, já que as mesmas têm um papel importantíssimo na história da Engenharia de Software,
por ainda serem amplamente utilizadas em empresas de desenvolvimento de software desde o início
da utilização de técnicas metodológicas para desenvolvimento de software.
Por fim, aprofundaremos com mais intensidade em métodos ágeis de desenvolvimento de
software; que tem ganhado grande espaço em empresas de desenvolvimento de software nos últimos
anos e que será o tema principal deste trabalho.
A Figura 1 mostra cronologicamente a evolução dos métodos de desenvolvimento de
software mais conhecidos pela indústria de software. Na Figura 1 podemos ver que a maioria dos
métodos ágeis surgiu antes mesmo do Manifesto Ágil [ManifestoAgil2001]. Neste trabalho falaremos
abordaremos dois métodos tradicionais de desenvolvimento de software: Cascata, que é o primeiro
método de que se tem conhecimento e tem importância histórica significativa. Também será abordado
o método Espiral, por sem amplamente utilizado atualmente. Já em relação aos métodos ágeis de
desenvolvimento, serão abordados os métodos XP e Scrum, por serem atualmente os mais
pesquisados no meio acadêmico e mais utilizados pela indústria.
7
Figura 1. Histórico de publicação de metodologias de desenvolvimento de software. [Filho2008]
8
2.1 Metodologias tradicionais de desenvolvimento de software
No início dos anos 70 a indústria de software passou a utilizar métodos de engenharia
durante o desenvolvimento de software com o intuito de descrever processos que pudessem
posteriormente ser replicados.
“Os métodos de engenharia proporcionam detalhes de ‘como fazer’ para construir um
software. Os métodos envolvem um amplo conjunto de tarefas que incluem: planejamento e
estimativa de projeto, análise de requisitos de software e de sistema, projeto da estrutura de dados,
arquitetura de programa e algoritmo de processamento, codificação, teste e manutenção. Os métodos
da engenharia de software muitas vezes introduzem uma notação gráfica ou orientada à linguagem
especial e introduzem um conjunto de critérios para a qualidade de software.” [Pressman2004]
Como visto na definição acima, métodos de engenharia têm como principal função descrever
detalhes de “como fazer” um software. Para tal, o uso de ferramentas e modelos que pudessem
representar graficamente esse “como fazer” foram sendo desenvolvidos com o tempo. Diagramas
UML, especificações, cenários de uso, planos de trabalho, definições de teste, relatórios, análises,
entre outros, são algumas das formas de definir artefatos utilizados em cada fase do desenvolvimento
de um software.
Para cada fase do desenvolvimento de software uma série de artefatos é definida para
detalhar como aquela fase será executada, de modo que a fase seguinte do desenvolvimento possa
utilizá-los na continuação do desenvolvimento. Assim que a fase é concluída, a fase seguinte obtém
os artefatos desenvolvidos anteriormente, os atualiza e produz novos artefatos que serão utilizados
pela fase seguinte. Esses passos se repetem até que o produto final tenha sido finalizado.
A documentação gerada é fortemente utilizada na comunicação e na interação entre as
pessoas alocadas no projeto a ser desenvolvido. É também utilizada na comunicação com pessoas
que estão fora do processo de desenvolvimento, tais como clientes e usuários. O uso da
documentação detalhada serve para demonstrar para o cliente aquilo que será desenvolvido.
O uso da documentação pressupõe que um grupo vasto de pessoas possa desenvolver o
mesmo projeto sem que se dividam o mesmo ambiente de trabalho, sem se relacionarem
verbalmente ou, até mesmo, sem ao menos se conhecerem.
Mas o que vemos na prática é que apenas o uso de uma documentação detalhada não
substitui a interação entre as pessoas envolvidas no processo de desenvolvimento de um software.
9
Mudanças constantes durante o processo de desenvolvimento de software, seja por alterações de
requisitos ou falhas no planejamento inicial do projeto, podem resultar em uma documentação
extremamente complexa e de difícil compreensão, mesmo para as pessoas envolvidas no processo
de desenvolvimento desde o seu início.
A interação entre os envolvidos no processo de desenvolvimento, nestes casos, é uma forma
mais eficaz de se estabelecer como e quais tarefas serão realizadas para atender as constantes
mudanças que o processo de desenvolvimento pode sofrer.
10
2.1.1 Método cascata
O método cascata foi o primeiro método amplamente utilizado pela engenharia de software
com o intuito de descrever todos os passos de todos os processos de desenvolvimento de software.
“O paradigma do ciclo de vida clássico da engenharia de software, às vezes chamado modelo
cascata, requer uma abordagem sistemática, seqüencial ao desenvolvimento do software, que se
inicia no nível do sistema e avança ao longo da análise, projeto, codificação, teste e manutenção.”
[Pressman2004]
Cada nível citado na definição acima pode ser caracterizado como uma fase do processo de
desenvolvimento e deve prover uma série de artefatos que documentam cada fase. Todos esses
artefatos são criados e posteriormente utilizados na fase seguinte. Abaixo estão descritas e
detalhadas as seis fases que fazem parte do escopo de um projeto que utiliza o método cascata:
• Análise e engenharia de sistemas: Coleta de todos os requisitos para todos os elementos
do sistema. A coleta desses requisitos é feita em nível de sistema e é feita a análise de alto
nível nesses requisitos. Também é realizada uma análise de alto nível de requisitos
tecnológicos, a fim de prever possíveis limitações de uso.
• Análise de requisitos de software: Nesta fase, a coleta dos requisitos de software é
intensificada especificamente no software a ser desenvolvido, a fim de adquirir o
conhecimento detalhado do negócio para o qual o software se propõe a tratar. As
necessidades de desempenho, de interface e todos os outros métodos que os usuários terão
para se relacionar com o software devem ser especificados, documentados e revistos com o
cliente.
• Projeto: Esta fase define quatro atributos distintos do software: Modelagem, arquitetura,
estrutura de dados e interfaces entre elementos e usuários do sistema. Todos os requisitos
coletados na fase anterior devem ser cobertos nesta fase, a fim de atender todas as
restrições e os níveis mínimos de desempenho e qualidade preestabelecidos. Como na fase
anterior, o projeto é documentado e passa a fazer parte da especificação completa do
sistema.
11
• Codificação: A especificação completa do software deve ser traduzida de forma que a
máquina consiga executar todas as tarefas definidas. O código gerado deve seguir
exatamente o que foi especificado nas fases anteriores.
• Testes: Cada funcionalidade do software é testada e validada a fim de verificar se todos os
requisitos e restrições definidas foram codificados de forma coerente com o que foi definido
na especificação. Os testes podem ser do tipo caixa preta, que verifica apenas as interfaces
que são disponibilizadas pelo sistema, ou podem ser do tipo caixa branca, que verifica o
código gerado durante a fase de codificação.
• Manutenção: Erros ou mudanças de requisitos podem ser identificados pelo cliente durante a
utilização. Assim, ajustes devem ser realizados no software para que estes erros sejam
corrigidos e que os novos requisitos sejam implementados. Uma nova versão do software é
construída e disponibilizada para o cliente, incluindo os ajustes e correções necessárias.
Figura 2 – Método cascata
Mesmo sendo o mais antigo método utilizado para desenvolvimento de software, o método
cascata possui alguns problemas em relação a sua aplicabilidade:
12
1. Os projetos reais dificilmente seguem um fluxo seqüencial. Interações podem ocorrer durante
o desenvolvimento, o que traz problemas na utilização do método;
2. É praticamente impossível definir todos os requisitos do sistema no início do projeto. O
método cascata exige que todos os requisitos sejam definidos no início do projeto;
3. O cliente só terá uma versão de software no final de todo o processo de desenvolvimento.
Assim, verificações de usabilidade e erros na concepção do problema só serão descobertos
depois do software estar pronto, o que causará alto custo de manutenção.
Cada um desses problemas citados é real e embora o método cascata tenha essa fragilidade,
ele é extremamente mais eficaz do que não utilizar método nenhum para desenvolvimento de
software.
13
2.1.2 Método espiral
O método espiral, também conhecido como método iterativo-incremental, apresenta duas
inovações se comparado com o método cascata.
• Introdução do modelo iterativo;
• Inclusão de análise de riscos.
No modelo iterativo as fases de desenvolvimento são realizadas várias vezes, definindo ciclos
de desenvolvimento. Já a análise de riscos propõe momentos em que as pessoas envolvidas no
projeto podem identificar e avaliar possíveis dificuldades encontradas durante o desenvolvimento.
O método espiral utiliza a abordagem do método cascata como uma das etapas do ciclo de
desenvolvimento. A cada iteração o software evolui e fica mais próximo da versão final que será
entregue para o cliente. Quatro etapas são definidas a cada iteração. [Pressman2004] Essas quatro
etapas são:
• Planejamento: Inicialmente são coletados os principais requisitos do sistema para realizar
um planejamento de alto nível, determinar objetivos, alternativas e restrições do projeto.
Depois do primeiro ciclo, a avaliação do cliente também será utilizada nessa iteração.
• Análise de riscos: São avaliados os riscos futuros do projeto, com base nos requisitos
coletados. A partir dessa identificação, procura-se encontrar soluções para minimizar o
impacto que estes riscos possam oferecer. Com essas soluções definidas, toma-se a decisão
de seguir o desenvolvimento do projeto ou de cancelá-lo.
• Engenharia: O produto planejado durante a fase de planejamento é efetivamente
implementado. Porém, não é desenvolvido todo o sistema de uma única vez. Apenas o que
foi planejado para uma única iteração é desenvolvido. A cada nova iteração, um novo módulo
do sistema é desenvolvido e integrado com os módulos desenvolvidos anteriormente. Para
cada iteração da fase de engenharia, utiliza-se o modelo cascata ou outro modelo de
desenvolvimento de software.
• Avaliação do cliente: O cliente avalia o que foi desenvolvido na fase de engenharia e
acrescenta comentários, sugestões e alteração a serem realizadas. Essas avaliações do
cliente serão utilizadas na nova iteração, como entrada para a etapa de planejamento.
14
A Figura 3 demonstra graficamente o modelo espiral e a interação entre os ciclos de
desenvolvimento.
Figura 3 – Método Espiral (Adaptado de http://www.devmedia.com.br/imagens/javamagazine/mod00fig02.jpg)
A análise de riscos possibilita a todos os envolvidos no projeto a possibilidade de
periodicamente avaliar o andamento do projeto e priorizar a atenção em pontos específicos que
podem se tornar impeditivos da continuidade futura do mesmo. Com isso, todos os envolvidos no
projeto têm a obrigação de avaliar e modificar constantemente seus objetivos e a viabilidade do
projeto, durante a sua execução.
Muitas vezes o software produzido não atende as necessidades definidas pelo cliente, devido
a falta de conhecimento de técnicas e de domínio completo do projeto como um todo. O caráter
evolutivo desse método tem como foco principal o conhecimento gradativo do problema, adquirido a
cada nova iteração, e com isso, mais tempo para análise e compreensão das necessidades do
cliente.
Contudo, a grande desvantagem do espiral é definir a quantidade de iterações que o projeto
terá. Assim, torne-se extremamente complexo e difícil determinar quanto será o custo e quando será
o prazo final para encerramento do projeto.
15
2.1.3 Outros métodos tradicionais de desenvolvimento de software
Os métodos cascata e espiral foram abordados com mais detalhes neste trabalho devido a
sua importância histórica e a sua relevância e utilização na indústria de software atual.
Já o método espiral surgiu na metade da década de 80 e obteve grande sucesso, passando a
ser muito utilizado até hoje em várias empresas de desenvolvimento de software.
Além desses dois métodos tradicionais de desenvolvimento de software, podemos citar outros
como Prototipação [Pressman2004] e o RUP (Rational Unified Process) [RUP1999].
2.1.3.1 Prototipação
O método de prototipação tem como base principal a criação de um pequeno protótipo do
software que será desenvolvido com o intuito de, a partir desse protótipo, novos requisitos e
necessidade do software sejam identificados e propiciar para o cliente a possibilidade de sugerir
mudanças e identificar falhas na análise e no desenvolvimento do software.
Um protótipo pode ser desenvolvido para que o cliente possa avaliar o design das telas e a
facilidade de uso. Mas um protótipo também pode ser desenvolvido para que analisar a viabilidade da
utilização de novas tecnologias ou para testar o desempenho do software, por exemplo, simulando a
sua utilização em um ambiente com as mesmas características que terá o ambiente onde o software
será instalado no cliente.
2.1.3.2 RUP
Apesar de o RUP ser tratado por alguns autores como sendo um método ágil de
desenvolvimento de software por se tratar de um método com várias características adaptativas, a
maioria dos autores o descrevem como sendo um método tradicional de desenvolvimento.
O método RUP surgiu em 1999, dentro da Rational Corporation, uma empresa americana que
tinham como proprietários três especialistas em desenvolvimento de software: Ivar Jacobson, Grady
Booch, e J. Rumbaugh. Em 2003 a Rational Corporation foi vendida para a IBM que, no entanto,
preservou o nome do método já disseminado por todo o mundo naquele momento.
O RUP define quatro fases principais no ciclo de desenvolvimento de um software. Iniciação,
Elaboração, Construção e Transição.
16
Na Iniciação são definidos, em poucos dias, quais os objetivos, requisitos básicos e as
prioridades principais do projeto. Na Elaboração são listados e detalhados todos os requisitos do
sistema, além de se iniciar o desenho da arquitetura dos módulos prioritários do sistema. Já na
Construção é realizada a implementação do software tendo como base os artefatos gerados nas
fases anteriores. Por fim, na Transição o software final é entregue e são realizados ajustes e
correções de possíveis bugs que o sistema venha a apresentar.
Figura 4 – Fases e volume de atividades para cada atividade do RUP [RUP2008]
17
2.2 Métodos ágeis de desenvolvimento de software
Neste capítulo vamos descrever a origem e as os princípios básicos dos métodos ágeis e
descreveremos dois dos métodos ágeis (Scrum, XP) mais discutidos e utilizados atualmente, tanto no
meio acadêmico quanto na indústria de software.
Scrum e XP foram escolhidos para serem detalhados neste trabalho por serem métodos
ágeis que podem ser utilizados em conjunto, já que Scrum tem como foco principal o gerenciamento
de um projeto de desenvolvimento de software enquanto XP tem como foco principal definir as
técnicas que serão utilizadas na fase de programação de um projeto de desenvolvimento de software.
Também serão brevemente citados outros métodos ágeis de desenvolvimento de software e,
caso haja interesse no aprofundamento dessas metodologias, mais detalhes poderão ser obtidos
utilizando as referências citadas no texto.
18
2.2.1 Origem dos métodos ágeis de desenvolvimento de software
Como visto anteriormente, os métodos tradicionais se baseavam fortemente em atividades
predefinidas, com extensa documentação e processos prescritivos. Assim, utilizando as metodologias
tradicionais de desenvolvimento de software o trabalho dos analistas de desenvolvimento se inicia
com a coleta de todos os requisitos do software, com a elaboração de um projeto completo de alto
nível, seguida da implementação e de testes, finalizando com a manutenção do software já pronto.
Na década de 90 começaram a surgir novos métodos de desenvolvimento baseados em dois
pontos principais: melhor comunicação entre a equipe e em processos que melhor se adaptam às
mudanças dos requisitos.
O primeiro ponto, que trata da melhor comunicação entre a equipe, foi abordado devido a
constatação que grande parte da documentação gerada durante o processo inicial do
desenvolvimento de software torna o processo de implementação muito burocrático, tirando a
capacidade criativa dos desenvolvedores. Além disso, a manutenção dos documentos gerados
durante o processo de análise dos requisitos se torna uma tarefa complexa caso haja mudanças de
requisitos durante o processo de desenvolvimento, além de causar impacto em todos os processos
que foram desenvolvidos baseados na documentação que foi alterada.
A comunicação contínua entre os membros da equipe, gerando documentos menos
complexos, mas com maior qualidade de informação, diminui o impacto das mudanças de requisitos
durante o processo de desenvolvimento e aumenta o grau de entendimento do problema a ser
resolvido, já que todos os membros da equipe estão em constante comunicação, trocando
experiências e expondo lições aprendidas durante o desenvolvimento do software.
Já o segundo ponto, que trata de processos que melhor se adaptam às mudanças dos
requisitos, foi abordado devido a percepção da maioria dos especialistas em desenvolvimento de
software de que, o melhor e mais eficaz método de coleta de requisitos de um sistema se dá de forma
gradual, de acordo com o andamento do projeto e com o aprimoramento do entendimento do negócio
o qual o software a ser desenvolvido se propõe a tratar por parte da equipe envolvida no projeto, além
da grande quantidade de requisitos que se alteram durante o andamento do projeto.
19
A coleta total de requisitos no início do projeto é praticamente impossível, devido a falta de
entendimento completo do negócio, além de ser custosa alteração dos requisitos durante o processo
de desenvolvimento.
Visto isso, pode-se dizer que os métodos ágeis de desenvolvimento de software utilizam
métodos incrementais e iterativos e são aplicados a equipes auto gerenciáveis e auto organizáveis,
onde todos os membros da equipe têm participação e voz ativa em todas as etapas do
desenvolvimento, tendo como alicerce principal a troca de conhecimento entre todos os membros da
equipe, aliado a uma documentação enxuta, mas de alto valor para o entendimento, manutenção e
futura replicação do software a ser desenvolvido.
Depois de muitos anos de experiência, dezessete especialistas em desenvolvimento de
software, que não utilizavam os métodos tradicionais e sim métodos de desenvolvimento seguindo os
dois pontos abordados anteriormente, verificaram que seus métodos de trabalho, além de serem mais
eficazes e produzirem software com melhor qualidade, possuíam vários pontos em comum. Assim,
em 2001, estes dezessete especialistas se reuniram durante um final de semana em uma estação de
ski no estado de Utah, EUA, para discutir seus métodos de trabalho e proporem uma nova
metodologia de desenvolvimento de software para substituir os métodos tradicionais.
Durante a reunião, os dezessete especialistas não conseguiram definir uma metodologia de
desenvolvimento, já que chegaram a conclusão que desenvolver software é uma tarefa extremamente
complexa e é impossível defini-la em um único processo. De acordo com o que foi debatido,
desenvolver software é uma tarefa que depende praticamente de pessoas em todas as suas etapas,
além de ser composta de um número grande de variáveis que podem se alterar durante as etapas de
desenvolvimento.
Contudo, o grupo chegou a conclusão que uma série de princípios básicos deviam ser
seguidos para garantir a qualidade do software a ser desenvolvidos. Ao final da reunião foram
definidos doze princípios básicos para a obtenção de bons resultados no desenvolvimento de
software. Estes doze princípios são:
1. A prioridade é satisfazer o cliente através de entregas contínuas e freqüentes;
2. Receber bem as mudanças de requisitos, mesmo em uma fase avançada do projeto;
3. Entregas com freqüência, sempre na menor escala de tempo;
20
4. As equipes de negócio e de desenvolvimento devem trabalhar juntas diariamente;
5. Manter uma equipe motivada fornecendo ambiente, apoio e confiança necessários;
6. A maneira mais eficiente da informação circular é através de uma conversa face-a-face;
7. Ter o sistema funcionando é a melhor medida de progresso;
8. Processos ágeis promovem o desenvolvimento sustentável;
9. Atenção contínua à excelência técnica e a um bom projeto aumentam a agilidade;
10. Simplicidade é essencial;
11. As melhores arquiteturas, requisitos e projetos provêm de equipes organizadas;
12. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz.
[ManifestoAgil2001]
A partir desses doze princípios básicos, foi publicado o “Manifesto Ágil”, que os representa
em quatro premissas:
1. Indivíduos e iterações são mais importantes do que processos e ferramentas
2. Software funcionando é mais importante do que documentação completa
3. Colaboração com o cliente é mais importante do que negociação de contratos
4. Adaptação a mudanças é mais importante do que seguir o plano inicial
[ManifestoAgil2001]
21
2.2.2 Valores ágeis
Neste capítulo serão recapituladas as quatro premissas básicas definidas no Manifesto Ágil.
Para cada uma delas será dada a abordagem completa da sua essência e o porquê de serem
definidas como pontos chave para melhor desenvolvimento de um software. Essas quatro premissas
básicas também são conhecidas como “valores ágeis de desenvolvimento de software”.
Primeiro valor ágil: “Indivíduos e iterações são mais importantes do que processos e
ferramentas.” [ManifestoAgil2001]
Este valor ágil vem de encontro com o primeiro ponto abordado no item 2.2.1.: Quanto melhor
for a comunicação e a troca de experiências e lições aprendidas entre os membros da equipe de
desenvolvimento, mais rápido e melhor será o desenvolvimento do software. A mudança de foco do
processo e das ferramentas de desenvolvimento para os indivíduos e suas interações causa uma
grande desconfiança por parte dos analistas e desenvolvedores mais conservadores, pois se trata de
uma mudança radical em relação aos métodos tradicionais de desenvolvimento, já que estes têm seu
foco justamente em processos extremamente rígidos e predefinidos, que devem ser seguidos do
início ao fim do projeto.
Mas como já foi dito anteriormente, a burocracia causada pela grande quantidade de
documentos gerados e a rigidez dos processos que devem ser seguidos ao se utilizar metodologias
tradicionais não são o foco principal do desenvolvimento do software, segundo os formuladores do
“Manifesto Ágil”. Pelo contrário, eles definem como essencial para o desenvolvimento a comunicação
e a troca de experiências e lições aprendidas entre os integrantes da equipe de desenvolvimento.
Segundo valor ágil: “Software funcionando é mais importante do que documentação
completa.” [ManifestoAgil2001]
Outro ponto que pode causar desconfiança por parte de analistas e desenvolvedores
acostumados a desenvolver software utilizando métodos tradicionais é entregar constantemente para
o cliente, mesmo que pequenos, módulos do software em funcionamento ao invés de gastar um longo
período de tempo e esforço para preparar a documentação completa do software a ser desenvolvido.
Entregando pequenos módulos do software funcionando em um curto intervalo de tempo
mostra-se mais eficaz do que entregar a documentação completa do software de uma única vez e,
após um longo período de tempo, entregar o software completo. Isto se deve ao fato de que software
22
funcionando gera para o cliente a sensação de que o projeto realmente está em pleno funcionamento,
que suas necessidades estão sendo atendidas e que o problema a ser tratado pelo software está
sendo resolvido. A cada nova entrega de um módulo de software funcionando, ele é integrada com os
módulos que já havia sido entregues e integrados anteriormente.
Assim, o cliente tem condição de sugerir melhorias do software durante a etapa de
desenvolvimento e não apenas ao final de todo o seu ciclo, o que diminui o custo de manutenção e
faz com que o cliente tenha, ao final do projeto, um software que atenda o mais próximo possível
todas as suas necessidades iniciais.
A Figura 5 mostra a diferença entre o custo de manutenção utilizando a “metodologia
tradicional Cascata” [item 2.1.1.] e a “metodologia ágil XP” [item 2.2.4.].
Figura 5 – Comparação de custo de mudança entre cascata e XP. [Filho2002]
O que se pode verificar na Figura 5 é que na fase inicial do projeto, a metodologia XP tem
maior custo de mudança em relação à metodologia Cascata. Isso se deve ao fato das constantes
mudanças de requisitos e melhorias sugeridas pelo cliente durante a fase de desenvolvimento. Já na
metodologia cascata, a mudanças de requisitos e as melhorias sugeridas pelo cliente só serão
atendidas após a entrega do software pronto. Neste caso, qualquer alteração no software pode
causar impacto em vários módulos do mesmo, aumentando a complexidade e o custo de qualquer
modificação que tenha que ser realizada. Na pior das hipóteses, o cliente pode chegar à conclusão
que o software desenvolvido não atende às suas necessidades, gerando o trabalho de se
desenvolver praticamente todo o sistema novamente.
Terceiro valor ágil: “Colaboração com o cliente é mais importante do que negociação de
contratos.” [ManifestoAgil2001]
Este terceiro valor ágil está fortemente ligado com o segundo valor ágil. Ele destaca o fato de
que a colaboração e a interação constante com o cliente e muito mais importante e eficaz do que a
negociação de contratos.
23
Para a equipe de desenvolvimento a constante colaboração do cliente faz com que a equipe
tenha maiores e melhores condições de desenvolver o software que o cliente espera, já que o
entendimento do negócio a ser tratado pode ser ampliado e melhor esclarecido a cada interação,
além das constantes sugestões de melhorias que o cliente pode sugerir durante o desenvolvimento, o
que faz com que o software esteja cada vez mais próximo do que o cliente espera receber.
Para o cliente o constante contato com a equipe de desenvolvimento garante que o
entendimento do problema a ser tratado pelo software a ser produzido esteja sempre em evolução,
fazendo com que a equipe esteja alinhada com a linha de pensamento do cliente, não deixando para
depois da entrega do software a percepção de que o que foi desenvolvido não atende as
necessidades do cliente. Outro fator positivo para o cliente desse constante contato com a equipe de
desenvolvimento é o fato do acompanhamento do projeto ser mais freqüente, fazendo com que
possíveis mudanças no cronograma do projeto sejam melhor gerenciadas e discutidas em conjunto,
minimizando assim possíveis desvios de custos e prazos de entrega de entrega do software.
Quarto valor ágil: “Adaptação a mudanças é mais importante do que seguir o plano inicial.”
[ManifestoAgil2001]
O último valor ágil definido pelo método ágil é muito baseado em técnicas iterativas e
incrementais, uma vez que sugere que, mais importante do que seguir a qualquer custo o plano inicial
é estar sempre apto a se adaptar as mudanças surgem durante o ciclo de desenvolvimento.
Coletar todos os requisitos de um software no início do projeto e garantir que estes requisitos
não se alterem é praticamente uma utopia do desenvolvimento de software. A experiência de vários
especialistas em desenvolvimento desde o início da computação garante que a identificação
completa de todos os requisitos do sistema durante a fase inicial do projeto é praticamente impossível
devido à dificuldade de entendimento de todo o problema a ser tratado pelo software a ser
desenvolvido e também as constantes alterações dos requisitos do software devido a mudanças
estratégicas da empresa durante o ciclo de desenvolvimento ou devido a evoluções tecnológicas que
podem surgir durante este período.
Estar em constante contato com o cliente, verificando possíveis alterações estratégicas que
podem surgir; definir ciclos de desenvolvimento mais curtos, diminuindo e priorizando o escopo das
iterações, garantindo que as possíveis alterações de um requisito não aconteçam durante a iteração
em que se esteja desenvolvendo o módulo do sistema que trata especificamente do requisito alterado
24
e, após a alteração do requisito, identificar rapidamente quais módulos do software sofrem impacto
com a alteração do requisito e devem ser alterado, são formas de diminuir o custo de manutenção do
software e garantir que qualquer mudança que ocorra durante o ciclo de desenvolvimento venha a ser
rapidamente adaptada ao software que está sendo construído.
25
2.2.3 Características comuns entre métodos tradicionais e métodos
ágeis
Algumas características são comuns entre os métodos tradicionais e os métodos ágeis de
desenvolvimento de software. Neste item abordaremos algumas dessas características comuns entre
os métodos, que podem ser utilizadas durante o projeto de desenvolvimento de um software
independentemente do tipo do método definido para o projeto.
Segundo [Filho2008], essas características comuns entre os métodos são: testes,
desenvolvimento iterativo, desenvolvimento incremental, colaboração, estimativas, negociação e
priorização.
Neste trabalho serão abordados somente as seguintes características: testes,
desenvolvimento iterativo e desenvolvimento incremental.
• Testes: Nos métodos tradicionais de desenvolvimento de software, a fase de testes e a fase
de implementação são duas fases completamente distintas. Já nos métodos ágeis de
desenvolvimento de software as duas fases são realizadas simultaneamente, já que a mesma
pessoa que desenvolve o código do software também escreve os casos de teste e testa o
software desenvolvido. A criação e a execução dos casos de teste já na fase inicial do
desenvolvimento do software facilitam e identificam falhas no desenvolvimento em um estágio
inicial do desenvolvimento, facilitando a sua correção e impedindo que o erro se propagasse
ou afetasse outros módulos do software. O uso de testes automatizados desde o início do
projeto também é outra característica dos métodos ágeis de desenvolvimento de software,
facilitando a execução dos testes e garantindo que todos os requisitos são atendidos, mesmo
após a implementação e integração com um novo módulo do software.
• Desenvolvimento iterativo: É uma característica utilizada em todos os métodos ágeis de
desenvolvimento de software, mas não em todos os métodos tradicionais. Como visto neste
trabalho, desenvolvimento iterativo é uma característica do método Espiral, mas não do
método Cascata. Essa característica define que o desenvolvimento de software será
realizado de forma iterativa, isto é, o desenvolvimento de software será realizado em partes e,
ao final de cada parte, o novo módulo do software produzido é integrado com os módulos já
finalizados. Desta forma é mais fácil a adaptação da equipe de desenvolvimento e menos
26
custosa a alteração no software caso algum requisito venha a ser alterado durante o projeto.
Em métodos ágeis de desenvolvimento de software o número de iterações é maior e o tempo
de cada iteração é menor se comparado com os métodos tradicionais de desenvolvimentos
de software
• Desenvolvimento incremental: Esta é mais uma característica presente em todos os
métodos ágeis de desenvolvimento de software mas, como no desenvolvimento iterativo, é
uma característica presente apenas no método Espiral, em se tratando dos métodos
tradicionais de desenvolvimento de software abordados nesse trabalho. Durante cada nova
iteração novas funcionalidades são implementadas e integradas com as funcionalidades já
desenvolvidas ou as funcionalidades já desenvolvidas em iterações anteriores, por
necessitares ser entregues prioritariamente, são evoluídas e complementadas.
27
2.2.4 Scrum
Scrum é um método de desenvolvimento ágil de software, criado em 1995 por Ken Schwaber
e Jeff Sutherland, onde o foco principal é o gerenciamento do projeto, sem definir exatamente como
será realizada a programação do software a ser desenvolvido.
Scrum leva em conta que o desenvolvimento de um software não é uma tarefa que possa ser
considerada estática, isto é, com requisitos que são definidos no início de um projeto e que não
sofrem nenhuma alteração até a conclusão do mesmo. Pelo contrário, Scrum define o
desenvolvimento de um software como sendo uma tarefa extremamente imprevisível, baseado em
flexibilidade e adaptabilidade.
Os criadores do método Scrum chegaram a conclusão de que é extremamente difícil definir
um método de desenvolvimento de software que seja capaz de abranger inúmeras variações em um
ambiente de desenvolvimento de software. Assim criaram o método contendo um pequeno número de
simples regras gerenciais que dão liberdade à evolução do projeto de desenvolvimento de forma
empírica, criando uma equipe de desenvolvimento auto-organizável e auto-gerenciável.
Segundo o método, o processo de desenvolvimento de software é “um conjunto solto de
atividades que combinam conhecimento, ferramentas e técnicas, com o melhor que a equipe de
desenvolvimento pode oferecer. Dentro do conjunto de atividades estão algumas atividades de
gerência de riscos e do próprio processo, que são necessárias para um desenvolvimento satisfatório.”
[Nascimento2008].
Essa abordagem, focada na gerência do projeto, traz para o método Scrum a possibilidade de
integração com outros métodos ágeis que venham a definir como as tarefas de programação serão
realizadas. Essa integração com outros métodos ágeis se torna eficaz a partir do momento em os
programadores da equipe de desenvolvimento ficam com a tarefa de definir quais serão as técnicas e
práticas de programação que serão adotadas, deixando os membros da equipe de desenvolvimento
responsáveis pelo gerenciamento do projeto fora dessa atividade.
O método Scrum, apesar de ter sua origem na área de desenvolvimento software, pode ser
utilizado em várias outras áreas além do desenvolvimento de software. Scrum é muito utilizado para
gerenciar projetos complexos, onde não é possível prever todas as variáveis que afetarão o projeto
ao longo de sua execução.
28
Assim, o uso do método Scrum vem crescendo muito nos últimos anos por se tratar de um
método onde é possível “saber exatamente o que está acontecendo ao longo do projeto e fazer os
devidos ajustes para manter o projeto se movendo ao longo do tempo visando alcançar os seus
objetivos.” [Cesar2007].
Segundo Marisa Villas Bôas Dias [Dias2008] os princípios básicos do Scrum são:
• Equipes pequenas de trabalho, buscando a maximização da comunicação e da troca de
conhecimento tácito e informal e minimização de overhead.
• Adaptação às solicitações de mudanças técnicas ou do cliente / usuário, assegurando a
entrega do melhor software possível.
• Entregas freqüentes de versões que podem ser testadas, ajustadas, executadas,
documentadas e liberadas para produção.
• Divisão do trabalho e das responsabilidades da equipe de projeto em pequenas entregas.
• Habilidade em entregar um software pronto quando da necessidade do cliente ou do negócio.
Como visto acima, Scrum deve ser utilizado em equipes pequenas de desenvolvimento de
software, já que a comunicação entre os membros da equipe é de fundamental importância no
andamento do projeto.
Essa importância se dá pelo fato de que todos os envolvidos devem relatar continuamente
suas dificuldades, necessidades e aprendizados obtidos durante as fases do desenvolvimento,
fazendo com que o conhecimento individual de cada membro da equipe se torne público e que todos
tenham conhecimento de tudo o que se passa na execução do projeto.
A constante comunicação entre os membros da equipe de desenvolvimento de software
também facilita a adaptação mudanças de requisitos técnicos, às solicitações de mudança por parte
do usuário ou mesmo por parte de inviabilidades tecnológicas que podem ser descobertas durante a
execução do projeto.
Isso se deve ao fato de que, definida a alteração a ser realizada no software, a mesma é
analisada e discutida entre todos os membros da equipe de desenvolvimento de software e o
compartilhamento do conhecimento de todos os envolvidos no projeto faz com que possíveis
impactos que a mudança poderá causar no software sejam minimizados ou até mesmo eliminados.
29
Outro fator importante que vem tornando Scrum como uma metodologia ágil muito utilizada
por toda a comunidade de software do mundo é a capacidade e a habilidade de entregar constantes
versões do software em funcionamento.
A divisão do software a ser produzido em pequenas versões possibilita para a equipe de
desenvolvimento do software a possibilidade de produzir software com mais qualidade, focando o
desenvolvimento de apenas uma pequena parte do todo a ser desenvolvido. Esse foco faz com que a
versão a ser entregue, apesar de pequena, possa ser muito bem documentada e testada.
A constância na entrega de versões em funcionamento para o cliente é outra qualidade que o
Scrum oferece. O cliente participa efetivamente do projeto recebendo constantemente novas versões
em pequenos intervalos de tempo pois, assim, pode-se constatar que o desenvolvimento do software
está sendo realizado constantemente e possíveis alterações em requisitos serão rapidamente
atendidos.
O cliente, tendo acesso a uma versão do software em funcionamento logo no início do
projeto, também pode solicitar possíveis mudanças no design do software, minimizando os impactos
se esta alteração fosse solicitada apenas após a entrega total do software já em produção.
O desenvolvimento do software utilizando Scrum se dá de forma interativa e incremental e
define três papéis principais para sua execução. Segundo [Cesar2007], estes três papéis principais
são:
• Product Owner: representa os interesses de todos no projeto; define os fundamentos do
projeto criando requisitos iniciais e gerais (Product Backlog), retorno do investimento (ROI),
objetivos e planos de entregas; prioriza o Product Backlog a cada Sprint, garantindo que as
funcionalidades de maior valor sejam construídas prioritariamente.
• ScrumMaster: Gerencia o processo do Scrum, ensinando o Scrum a todos os envolvidos no
projeto e implementando o Scrum de modo que esteja adequado a cultura da empresa; deve
garantir que todos sigam as regras e práticas do Scrum; é responsável por remover os
impedimentos do projeto.
• Time: desenvolve as funcionalidades do produto; define como transformar o Product Backlog
em incremento de funcionalidades numa iteração gerenciando seu próprio trabalho sendo
responsáveis coletivamente pelo sucesso da iteração e conseqüentemente pelo projeto como
um todo.
30
Os elementos produzidos pela equipe de desenvolvimento para seguir as práticas do Scrum
são [Filho2008]:
• Backlog do Produto: Lista de todos os cartões de funcionalidades que o produto deve
possuir e que ainda não foram implementadas.
• Backlog Selecionado: Um subconjunto de funcionalidades que o cliente escolheu a partir do
backlog do produto para ser implementado no sprint atual e que não pode ser modificado
durante o sprint.
• Backlog do Sprint: Lista priorizada, obtida a partir da quebra dos cartões do backlog
selecionado em tarefas menores.
• Backlog de Impedimentos: Lista dos obstáculos identificados pela equipe que não
pertencem ao contexto do desenvolvimento.
• Gráficos de Acompanhamento: Gráficos que medem a quantidade de trabalho restante
(burndown charts) são os preferidos em Scrum. É recomendado fazê-los para várias esferas
do projeto: para o produto, para a release e para o Sprint.
O ciclo de vida do Scrum é composto por quatro fases [Cesar2007]:
• Planejamento: estabelecer a visão do projeto e expectativas garantindo recursos para a sua
execução. Nesta fase são criadas as versões iniciais do Product Backlog e o plano de
release, arquitetura de negócio e técnica em alto nível.
• Stagging: avaliar as várias dimensões do projeto criando itens adicionais ao Product Backlog
relacionados com o tipo do sistema, time, ambiente de desenvolvimento, tipo de aplicação.
Nesta fase os Times são formados e são construídos os mecanismos de comunicação e
coordenação entre eles.
• Desenvolvimento: consiste de múltiplas Sprints para o desenvolvimento dos incrementos de
funcionalidade do produto.
• Releasing: realizar a entrega do produto ao cliente.
Em Scrum, um projeto se inicia com uma visão do produto que será desenvolvido. A visão
contém a lista das características do produto estabelecidas pelo cliente. Em seguida, o Product
31
Backlog (Backlog do Produto) é criado contendo a lista de todos os requisitos conhecidos. O Product
Backlog é então priorizado e dividido em versões. O fluxo de desenvolvimento detalhado do Scrum é
mostrado na Figura 6.
Figura 6 – Ciclo de desenvolvimento do Scrum [Filho2008]
Em Scrum, são realizadas iterações chamadas de Sprints. Cada Sprint inicia-se com uma
reunião de planejamento (Sprint Planning Meeting), na qual o Product Owner e o Time decidem em
conjunto o que deverá ser implementado (Selected Product Backlog ou Backlog Selecionado).
A reunião é dividida em duas partes. Na primeira parte (Sprint Planning 1), o Product Owner
apresenta os requisitos de maior valor e prioriza aqueles que devem ser implementados.
O Time então define colaborativamente o que poderá entrar no desenvolvimento da próxima
Sprint, considerando sua capacidade de produção. Na segunda parte (Sprint Planning 2), o time
planeja seu trabalho, definindo o Sprint Backlog (Backlog do Sprint), que são as tarefas necessárias
para implementar as funcionalidades selecionadas no Product Backlog.
Nas primeiras Sprints, é realizada a maioria dos trabalhos de arquitetura e de infra-estrutura.
A lista de tarefas pode ser modificada ao longo da Sprint pelo Time e as tarefas podem variar entre 4
a 16 horas para a sua conclusão.
32
Na execução das Sprints, diariamente o Time faz uma reunião de 15 minutos para
acompanhar o progresso do trabalho e agendar outras reuniões necessárias. Na reunião diária (Daily
Scrum Meeting), cada membro do time responde a três perguntas básicas: O que eu fiz no projeto
desde a última reunião? O que irei fazer até a próxima reunião? Quais são os impedimentos?
Ao final da Sprint, é realizada a reunião de revisão (Sprint Review Meeting) para que o Time
apresente o resultado alcançado na iteração ao Product Owner. Neste momento as funcionalidades
são inspecionadas e adaptações do projeto podem ser realizadas.
Em seguida o ScrumMaster conduz a reunião de retrospectiva (Sprint Retrospective Meeting),
com o objetivo de melhorar o processo/time, o produto ou ambos para a próxima Sprint.
O monitoramento do progresso do projeto é realizado através de gráficos de
acompanhamento. Estes gráficos mostram ao longo do tempo a quantidade de trabalho que ainda
resta ser feito, sendo um excelente mecanismo para visualizar a correlação entre a quantidade de
trabalho que falta ser feita (em qualquer ponto) e o progresso do time do projeto em reduzir este
trabalho.
33
2.2.5 XP
O Extreme Programming (XP) surgiu como uma tentativa para solucionar os problemas
causados pelos ciclos de desenvolvimento longos dos métodos tradicionais de desenvolvimento de
software. XP é composto por práticas que se mostraram eficientes nos processos de desenvolvimento
de software nos últimos tempos.
Depois de aplicado e obtido sucesso num caso real, o XP foi formalizado através de quatro
princípios chaves e doze práticas.
Os quatro princípios chaves do XP são [Franco2007]:
• Comunicação: muitos dos problemas que ocorrem no decorrer do projeto podem ser
relacionados com problemas de comunicação entre a equipe ou entre a equipe do projeto e o
próprio cliente. Uma pessoa pode deixar de comunicar um fato importante à outra pessoa, um
programador pode deixar de levantar uma questão importante ao cliente etc. O XP mantém o
fluxo de comunicação através de algumas práticas que não podem ser realizadas sem
comunicação. Exemplos disto são: testes de unidade, programação em pares e estimativa do
esforço de cada tarefa.
• Simplicidade: deve-se sempre selecionar a alternativa mais simples que possa funcionar. O
XP se baseia no fato que é mais barato fazer algo mais simples e alterá-lo conforme as
necessidades forem surgindo do que tentar prever as necessidades futuras, introduzindo uma
complexidade que possa vir a não ser necessária no futuro.
• Feedback: todo problema é evidenciado o mais cedo possível para que possa ser corrigido o
mais cedo possível. Toda a oportunidade é descoberta o mais cedo possível para que possa
ser incorporada de forma rápida ao produto que está sendo construído.
• Coragem: é preciso coragem para apontar um problema no projeto, para solicitar ajuda
quando necessário, para simplificar o código que já está funcionando, comunicar ao cliente
que não será possível implementar um requisito no prazo estimado e, até mesmo, para fazer
alterações
34
O XP é composto por doze práticas que são descritas a seguir [Franco2007]:
• Jogo de planejamento: nesta prática existe uma grande interação entre o cliente e os
Programadores. Os programadores estimam o esforço necessário para implementar as
estórias definidas pelo cliente e este, decide sobre o escopo e duração das iterações. As
estórias definidas pelo cliente são breves relatos de como o negócio a ser tratado pelo
sistema a ser desenvolvido funciona. Assim o programador sabe qual a necessidade do
cliente e quais são os passos que o sistema deve realizar para solucionar o problema do
cliente.
• Pequenas versões: um incremento simples e funcional é gerado rapidamente pelo menos
uma vez a cada dois ou três meses. Desta forma é possível ter um retorno por parte do
Cliente em tempo hábil para poder incorporar mudanças e corrigir o produto sendo
desenvolvido.
• Metáforas: é elaborada uma descrição que permite todos envolvidos no projeto (clientes,
programadores, gerente etc.) explicar como o sistema funciona. Ela cria uma visão comum e
sugere uma estrutura de como o problema e a solução são percebidos no contexto do
sistema sendo produzido. Ela também auxilia os envolvidos a compreender os elementos
básicos do sistema e seus relacionamentos, criando um vocabulário comum para o projeto.
• Projeto simples: o sistema deve ser projetado da forma mais simples possível de acordo
com as necessidades atuais do projeto. As complexidades desnecessárias são removidas
assim que são descobertas.
• Testes: o desenvolvimento do software é dirigido por testes. Os testes de unidade são
desenvolvidos antes da codificação são executados continuamente. Os testes de aceitação
são escritos pelo cliente.
• Refatoramento: melhoria do sistema através da remoção de duplicações de código,
melhorando a comunicação, simplificando e adicionando flexibilidade.
• Programação em pares: dois programadores escrevem o código em um único computador.
• Propriedade coletiva: qualquer programador pode alterar qualquer parte do código em
qualquer lugar do sistema a qualquer momento.
• Integração contínua: o sistema é integrado e são geradas versões internas, diversas vezes
ao dia, sempre que uma estória é finalizada.
35
• Semanas de 40 horas: não se deve trabalhar mais do que quarenta horas por semana, isto
deve ser encarado como uma regra. Nunca trabalhe mais do que isso duas ou mais semanas
consecutivamente.
• Cliente presente: O cliente deve ser adicionado à equipe de programadores. Ele deve estar
disponível em tempo integral para responder as eventuais dúvidas.
• Padronização de código: os programadores escrevem todo o código de acordo com regras
que enfatizam a comunicação durante a codificação. Antes do início do projeto deve ser
definido um padrão que deverá ser seguido por toda a equipe de Programadores.
Figura 7 – Valores e práticas de XP [Filho2002]
No XP, as práticas de codificação e equipe são mais detalhadas e definidas que as práticas
de processos. Por isso, quando se utiliza métodos ágeis de desenvolvimento de software, é muito
comum se utilizar XP para definir as práticas de codificação e Scrum para a prática de gerenciamento
do projeto.
Existem diferentes papéis sugeridos pelo XP para diferentes fases, práticas e ferramentas
necessárias ao longo do projeto. A seguir, estes papéis são descritos:
• Programador: escrevem testes e mantém o programa o mais simples e conciso possível. A
primeira característica que torna o XP possível é a habilidade de comunicação e coordenação
com outros membros da equipe.
36
• Cliente: escreve as estórias e os testes funcionais, além de decidir quando cada requisito foi
satisfeito. O cliente também define a prioridade de implementação de cada requisito.
• Testador: ajuda o cliente a escrever os testes funcionais. Ele também realiza os testes
funcionais regularmente, comunicando os resultados dos testes e mantém o conjunto de
testes.
• Monitor: fornece a realimentação para a equipe do projeto. Ele acompanha a conformidade
das estimativas feitas pela equipe de desenvolvimento e fornece comentários de quanto
acuradas elas estão, para poder melhorar futuras estimativas. Ele também acompanha o
progresso de cada iteração e avalia se o objetivo é viável dentro das limitações de tempo e
recursos, ou se alguma mudança é necessária no processo.
• Treinador: é a pessoa responsável pelo processo como um todo. Um profundo conhecimento
do XP é importante para este papel, pois é ele que guiará os outros envolvidos no projeto a
executar o processo de forma adequada.
• Consultor: é um membro externo com conhecimento técnico específico necessário para o
projeto. O consultor auxilia a equipe a resolver problemas específicos.
• Chefe: responsável pelas tomadas de decisões. Para isso, ele comunica-se com a equipe de
projeto para determinar a situação atual e para identificar qualquer dificuldade ou deficiência
do processo.
Devido à falta de foco nas práticas relacionadas ao gerenciamento do projeto, o XP tem sido
criticado e questionado por parte dos gerentes e diretores de empresas desenvolvedoras de software
e por parte da comunidade científica.
37
2.2.6 Outros métodos ágeis
Neste item serão abordados outros métodos ágeis utilizados em projetos de desenvolvimento
de software, mas que não serão detalhados neste trabalho. Caso o leitor tenha interesse em
conhecer mais sobre alguns dos métodos que serão apenas apresentados neste item, consulte as
referências disponíveis no texto.
2.2.6.1 Crystal Methods
Criado por Alistair Cockburn no início dos anos 90, a partir da crença de que os principais
obstáculos enfrentados no desenvolvimento de produtos recaíam sobre os problemas de
comunicação, os Crystal Methods dão grande ênfase às pessoas, à comunicação, às interações, às
habilidades e aos talentos individuais, deixando os processos em segundo plano [Dias2008].
Correspondem a uma família de métodos organizados por cores, de acordo com o número de
pessoas envolvidas (tamanho do projeto x necessidade de comunicação), com as prioridades do
negócio e com a complexidade e a criticidade do software a ser desenvolvido, conforme mostra a
Figura 8.
Apesar da estrutura proposta servir como um guia dos processos mais adequados a uma
determinada situação, nos Crystal Methods, a definição final dos processos a serem utilizados é
responsabilidade da equipe de projeto. Mas duas regras principais são sempre seguidas: ciclos de
desenvolvimento incrementais com duração de no máximo quatro meses e reuniões de reflexão que
estimulam a colaboração entre integrantes da equipe de projeto.
Figura 8 – Esquema do Crystal Methods [Dias2008]
38
2.2.6.2 Feature-Driven Development (FDD)
O Feature-Driven Development, criado por Peter Coad e Jeff DeLuca em 1999, é um método
de desenvolvimento de software específico para aplicações críticas de negócio. Diferentemente de
outros Métodos Ágeis, o FDD se baseia em processos bem definidos e que podem ser repetidos. Sua
abordagem se concentra nas fases de projeto e construção, com maior ênfase na modelagem, em um
ciclo de vida iterativo e também em atividades de gerenciamento de projetos.
Os princípios base do FDD são apontados abaixo [Dias2008]:
o Necessidade de se automatizar a geração de software para projetos de grande
escala;
o Um processo simples e bem definido é fundamental;
o As etapas de um processo devem ser lógicas e óbvias para cada integrante da
equipe de desenvolvimento;
o Bons processos atuam na retaguarda, permitindo que a equipe se dedique ao
alcance dos resultados;
o Ciclos de vida curtos e iterativos são mais indicados.
Um projeto conduzido pelo método FDD possui as seguintes etapas:
o Desenvolvimento de um modelo geral;
o Construção da lista de funcionalidades;
o Planejamento por funcionalidades;
o Projeto e desenvolvimento por funcionalidades.
2.2.6.3 Dynamic Systems Development Method (DSDM)
Originário da Inglaterra, em meados dos anos 90, o Dynamic Systems Development Method é
controlado por um consórcio de empresas. Criado a partir do RAD – Rapid Application Development,
o DSDM é o único método ágil compatível com a ISO 9000.
Seu ciclo de vida é divido nos seguintes estágios [Dias2008]:
o Pré-projeto;
o Análise de Aderência;
o Estudo de Negócio;
39
o Modelagem Funcional;
o Projeto e Desenvolvimento;
o Implementação;
o Pós-implementação.
A idéia central do DSDM é que se deve primeiramente fixar o prazo e os recursos para, em
seguida, definir e ajustar o número de funcionalidades a serem desenvolvidas. Dadas a sua natureza,
o DSDM não endereça um tamanho de equipe específico e não possui durações pré-determinadas
para suas iterações.
40
3 PROJETO DESENVOLVIDO
Neste capítulo do trabalho será a feita a comparação entre os métodos ágeis e os métodos
tradicionais de desenvolvimento de software.
A comparação entre os métodos apresentados será realizada através da análise de uma série
de características comuns que os dois métodos têm para o desenvolvimento de um projeto de
software.
As características comuns que serão comparadas neste trabalho são: levantamento de
requisitos e necessidades, necessidade de interação com o cliente, número de indivíduos que
compõe a equipe de desenvolvimento, grau de maturidade desses indivíduos, prazos e custos da
construção de um software, testes e entrega do software para o cliente e, por fim, a manutenção do
software já completamente disponibilizado e em produção.
Todas as características comparadas estão divididas em subitens dentro deste capítulo,
facilitando a leitura e compreensão de cada comparação apresentada.
3.1 Levantamento de necessidades e requisitos
Em se tratando de levantamento de necessidade e requisitos do sistema a diferença entre os
métodos ágeis e os métodos tradicionais de desenvolvimento de software é bem clara e evidente.
Os métodos tradicionais possuem uma visão preditiva em relação ao levantamento das
necessidades e requisitos de um software. Esta visão preditiva diz que todas as necessidades e
requisitos do software devem ser identificados e analisados no início do projeto e que, após isto, as
necessidades e requisitos do sistema não sofrerão mais nenhuma alteração durante todo o
desenvolvimento do projeto.
Durante vários anos percebeu-se que esta visão preditiva não se adequava a realidade do
desenvolvimento de software, já que na maioria dos casos, as necessidades e requisitos são
modificados durante o ciclo de desenvolvimento do software.
Com isso, os métodos ágeis propõem uma visão adaptativa para o levantamento das
necessidades e requisitos de um software. Esta visão adaptativa leva em conta que, na grande
maioria dos projetos de desenvolvimento, as necessidades e requisitos de um software sofrem
41
alterações durante o ciclo de desenvolvimento e, portanto, o método a ser utilizado deve estar
preparado para se adaptar a estas mudanças.
Nos métodos ágeis essa adaptabilidade é obtida através de iterações curtas, pois assim o
processo de desenvolvimento oferece flexibilidade durante o avanço do projeto para adaptações nos
requisitos do sistema e cria oportunidades para novos estudos de viabilidade e incorporação de
novos requisitos
3.2 Interação com o cliente
A interação com o cliente é outra característica que possui uma diferença clara entre os
métodos ágeis e os métodos tradicionais de desenvolvimento de software.
Como visto no item anterior, nos métodos tradicionais todas as necessidades e requisitos de
um software são definidos logo no início do projeto.
Assim, nos métodos tradicionais, a necessidade de interagir com o cliente também só se dá
no início do projeto, levantando-se com o cliente todas as necessidades que ele necessita que o
software resolva e todos os requisitos e características que o software deve possuir. Finalizado esta
fase, a interação com o cliente não se torna mais necessária e, somente após a finalização do
desenvolvimento do software é que o cliente terá a visão do que foi projetado e desenvolvido.
Já nos métodos ágeis a interação com o cliente é constante, uma vez que a visão adaptativa
dos métodos ágeis pressupõe a adaptabilidade das necessidades e requisitos do sistema.
Assim, a constante interação com o cliente durante todo o ciclo de desenvolvimento faz com
que o entendimento do negócio o qual o software se propõe a resolver seja aprimorado a cada nova
interação.
A constante interação com o cliente também é benéfica no sentido que, a cada nova versão
do software em funcionamento que é disponibilizada para o cliente, o mesmo pode sugerir alterações
e melhorias que, se não houvesse interações constantes, só seriam vistas e propostas após a
finalização e entrega do software completo. Uma vez que isso acontecesse, o custo da mudança
seria altamente caro se comparado com a mudança realizada ao longo das interações com o cliente
do software.
42
3.3 Número de indivíduos que compõe a equipe de
desenvolvimento
A comunicação e a interação entre os membros da equipe de desenvolvimento é um fator
primordial para que a utilização de métodos ágeis seja realizada com sucesso. Para que esta
comunicação e interação se mostrem eficientes, é necessário que o número de membros de uma
equipe de desenvolvimento não seja muito grande, pois dificultaria assim a comunicação entre os
membros. O tamanho máximo de uma equipe de desenvolvimento que utiliza métodos ágeis não
deve ultrapassar 12 membros. Um número maior do que esse pode causar problemas na
comunicação e interação entre os membros, fazendo com que a utilização de métodos ágeis possa
se tornar um fracasso.
Já nos métodos tradicionais o tamanho da equipe de desenvolvimento não é um fator
impeditivo para a execução do projeto, pois ao se utilizar métodos tradicionais em um projeto, todas
as tarefas e papéis dos membros da equipe de desenvolvimento são definidos logo no início do
projeto, assim como a documentação completa e detalhada de todo o projeto.
Uma vez definidas todas as tarefas e papéis de todos os membros da equipe durante todo o
ciclo de desenvolvimento e todos têm acesso a documentação completa e detalhada de todo o
software a ser desenvolvido, a necessidade de comunicação entre os membros é diminuída
drasticamente. Portanto, uma equipe de desenvolvimento de software que utiliza métodos tradicionais
não sofreria grandes impactos de comunicação durante a execução do projeto caso conte com um
número elevado de membros.
3.4 Grau de maturidade dos indivíduos que compõe a equipe de
desenvolvimento
Como o ciclo de desenvolvimento de um software utilizando métodos tradicionais é realizado
em um período grande de tempo, o grau de maturidade dos membros da equipe de desenvolvimento
pode evoluir com o andamento do projeto.
A inclusão de membros com baixo grau de maturidade de desenvolvimento na equipe não é
um fator determinante, uma vez que estes membros terão tempo hábil para se adaptarem ao método
utilizado e também para adquirirem maior conhecimento sofre o problema o qual o software a ser
desenvolvido se propõe a resolver.
43
Já em métodos ágeis, que utilizam iterações curtas e necessitam entregar um módulo de
software funcionando ao final de cada iteração, o grau de maturidade de desenvolvimento dos
membros da equipe deve ser elevado, uma vez que o tempo para se desenvolver o software é
reduzido, e membros com baixo grau de maturidade não teriam tempo hábil para se adaptarem ao
método utilizado.
O bom conhecimento do método a ser utilizado é primordial, pois não há tempo para
adaptação ao mesmo. O conhecimento geral do problema o qual o software se propõe a resolver,
mesmo que genérico, também é um fator que os membros da equipe de desenvolvimento devem
possuir para que a fase inicial do projeto seja realizada para atender as necessidades prioritárias que
o cliente necessita.
A cada interação com o cliente, este conhecimento é ampliado e afinado, fazendo com que o
software desenvolvido se aproxime cada vez mais com o software que o cliente espera receber.
3.5 Prazos e custos da construção de um software
Os métodos tradicionais de desenvolvimento definem que a entrega do software deve ser
realizada apenas quando o software estiver finalizado por completo ou, no caso do método espiral,
após uma grande fase de iteração onde a implementação de uma grande qualidade de necessidades
e requisitos foi realizada. Com isso, o cliente não possui, durante a fase de desenvolvimento, nenhum
conhecimento de como o software está sendo desenvolvido. O cliente só terá conhecimento depois
que o software como um todo seja entregue.
Os custos de possíveis alterações sugeridas pelo cliente também são grandes, uma vez que
o cliente só poderá sugerir estas mudanças após o recebimento completo do software.
Nos métodos ágeis o software é constantemente entregue durante o ciclo de
desenvolvimento, através de pequenas versões do software funcionando. Essas entregas são
realizadas, em média, a cada duas semanas, o que dá tempo hábil para o cliente testar o software
entregue sugerir melhorias e novos requisitos a serem implementados.
Com isso, o software irá sendo integrado gradativamente e o cliente terá sempre maneiras de
sugerir melhorias já durante o ciclo de desenvolvimento. Essas sugestões já durante o ciclo de
desenvolvimento diminuem o custo da manutenção, uma vez que as próximas iterações do software
44
já contemplarão a implementação das melhorias sugeridas, não necessitando assim de alterações
futuras.
3.6 Testes e entrega do software para o cliente
A fase de testes do software utilizando métodos tradicionais de desenvolvimento é uma etapa
que se inicia logo após o término da fase de implementação do sistema.
O software é testado por uma equipe de testes após estar completamente finalizado. Caso
sejam encontrados algum incidente que necessite correção, a equipe de testes reporta para a equipe
de desenvolvimento o incidente. A equipe de desenvolvimento corrige o erro e envia para a equipe de
testes o software corrigido, que deverá ser novamente testado. Assim, a identificação de erros que
podem causar impactos em todo o software só são descobertas após o software estar completamente
finalizado.
Em métodos ágeis de desenvolvimento, os testes são uma atividade constante em todo o
ciclo de desenvolvimento, uma vez que se inicia juntamente com a fase de implementação, onde o
próprio desenvolvedor escreve os casos de teste.
Os testes são executados a cada iteração do software, descobrindo logo no início do projeto
possíveis falhas que poderiam se espalhar por todo o software, diminuindo assim os impactos das
correções e de manutenções futuras no software.
A utilização de testes automatizados também é uma prática constante nos métodos ágeis,
uma vez que os testes podem ser executados a qualquer momento, além de facilitar a sua execução.
3.7 Manutenção do software em produção
A manutenção do software já em produção é um fator de alto custo em projetos que utilizam
métodos tradicionais de desenvolvimento, uma vez que várias solicitações de mudança e de
melhorias só são identificadas nesta fase, devido a falta de interação com o cliente durante todo o
ciclo de desenvolvimento. Assim, uma solicitação de mudança pode causar impactos em vários
módulos do sistema, tornando a manutenção do software muito custosa e por vezes demorada.
Já nos métodos ágeis, com a realização dos testes desde o início do projeto e com a grande
interação entre a equipe de desenvolvimento e o cliente, vários problemas de funcionamento do
45
software são verificados e corrigidos logo no início de cada iteração do software, evitando que estes
problemas se espalhem por vários pontos do sistema e tornando a sua correção uma tarefa de alto
custo e impacto no sistema.
Portanto, a manutenção utilizando métodos ágeis de desenvolvimento se torna uma tarefa
extremamente simples e com grau mínimo de complexidade se comparado com o custo e grau de
complexidade da manutenção de um software desenvolvido por uma equipe de software que utiliza
métodos tradicionais de desenvolvimento.
A Figura 5, na página 22, demonstra claramente a diferença entre o custo de manutenção de
um método tradicional (Cascata) comparado com um método ágil de desenvolvimento (XP).
46
3.8 Conclusão
Neste capítulo serão concluídas, com base na comparação dos métodos tradicionais e os
métodos ágeis de desenvolvimento de software, quais são as vantagens e desvantagens de utilizar
métodos ágeis em um projeto de desenvolvimento de software.
Apesar dos métodos ágeis serem considerados uma evolução dos métodos tradicionais de
desenvolvimento de software, algumas de suas características podem apresentar desvantagens em
relação aos métodos tradicionais.
As vantagens e desvantagens da utilização de métodos ágeis em relação aos métodos
tradicionais serão apresentadas em tópicos, onde cada tópico possui a descrição que justifica os
motivos pelos quais o tópico foi classificado como sendo uma vantagem ou desvantagem dos
métodos ágeis.
Ao final da conclusão serão concluídas quais as características necessárias que os membros
de uma equipe de desenvolvimento de software deve possuir para que a utilização de métodos ágeis
seja viável e garanta a qualidade do software gerado ao final do processo de desenvolvimento.
Da mesma forma, as características dos membros da equipe de desenvolvimento serão
apresentadas em tópicos, onde cada tópico possui a descrição que justifica os motivos pelos quais o
tópico foi classificado como sendo uma característica necessária para os membros de uma equipe de
desenvolvimento de software que utiliza algum método ágil de desenvolvimento.
3.8.1 Vantagens dos métodos ágeis em relação aos métodos
tradicionais
• Diferentes métodos ágeis podem ser combinados num único processo de
desenvolvimento de software. Esta conclusão fica evidente devido ao fato de que, como
visto neste trabalho, a maioria dos métodos ágeis não compreendem uma metodologia
completa, isto é, elas não apresentam soluções para todas as áreas de um projeto de
desenvolvimento de software. A maioria dos métodos ágeis são focados em áreas
específicas de um projeto completo de desenvolvimento de software, o que faz com a
utilização de dois ou mais métodos ágeis em conjunto seja possível. Um exemplo clássico
47
dessa combinação de métodos ágeis é a utilização de Scrum e XP. Como Scrum foca a parte
gerencial do projeto de desenvolvimento de software e XP define as praticas de codificação, a
utilização deles em conjunto tem sido muito utilizada e comprovada em vários casos de
sucesso. [Filho2008], [Dias2008].
• Podem ser combinadas com métodos tradicionais de desenvolvimento de software.
Como visto no tópico anterior, a maioria dos métodos ágeis de desenvolvimento de software
não compreende uma metodologia completa. Assim, podemos chegar à conclusão que pode-
se utilizar um método ágil para gerenciamento do projeto enquanto a parte de
desenvolvimento e codificação do projeto utiliza as técnicas definidas por um método
tradicional de desenvolvimento de software. Em muitas empresas que desenvolvem software
tem utilizado a combinação “Scrum + Espiral”, onde a parte gerencial do projeto é realizada
utilizando Scrum e a parte de desenvolvimento e codificação é realizada utilizando as
técnicas iterativas e incrementais definidas pelo método espiral. Outra combinação entre
métodos ágeis e métodos tradicionais é a utilização de RUP com XP, onde são utilizadas as
técnicas gerenciais definidas pelo método RUP, enquanto a área de desenvolvimento e
codificação é realizada utilizando as técnicas definidas pelo método XP.
• Adaptabilidade em relação a mudanças de requisitos. Uma grande vantagem dos
métodos ágeis em relação aos métodos tradicionais de desenvolvimento de software, pois a
adaptabilidade em relação à mudança de requisitos é um fator importante durante um projeto
de desenvolvimento de software. Enquanto os métodos tradicionais de desenvolvimento de
software possuem uma visão preditiva, isto é, possuem a visão de que todos os requisitos de
um software podem ser coletados durante a fase inicial do projeto e não se alterarão durante
o seu desenvolvimento, os métodos ágeis possuem uma visão adaptativa em relação aos
requisitos do sistema. Após vários anos desenvolvendo software com uma visão preditiva em
relação aos requisitos do sistema, verificou-se que esta não era a melhor maneira de se
desenvolver um software com qualidade. Assim, com a criação dos métodos ágeis de
desenvolvimento, esta visão foi alterada de modo a ter uma melhor adaptabilidade em
relação as mudanças de requisitos durante o andamento do projeto. Essa adaptabilidade se
dá devido a iterações mais curtas durante o desenvolvimento do sistema. Assim, o processo
48
de desenvolvimento oferece flexibilidade durante o avanço do projeto para adaptações nos
requisitos do sistema e cria oportunidades para novos estudos de viabilidade e incorporação
de novos requisitos.
• Testes realizados desde o início do projeto. Nos métodos ágeis o teste de software possui
uma importância ainda maior se comparado aos métodos tradicionais de desenvolvimento de
software. A fase de testes é uma das características comuns entre os métodos tradicionais e
os métodos ágeis. Mas podemos chegar à conclusão que a vantagem da fase de testes dos
métodos ágeis é que ela tem início logo que o projeto se inicia e não apenas após a
finalização da fase de codificação, como é definido nos métodos tradicionais de
desenvolvimento de software. Nos métodos ágeis a fase de teste se inicia junto com a fase
de codificação, onde o próprio programador já escreve os casos de teste. Segundo
[Filho2008] “A produção de testes no início do projeto facilita a identificação de problemas e
reduz o custo de desenvolvimento do software”. Também, segundo [Fillho2008], a correção
do software após a entrega pode custar 100 vezes mais do que se a correção fosse realizada
durante o desenvolvimento do projeto. Outro fator que aponta como vantagem a execução
dos testes logo no início do projeto é que freqüentemente os testes podem ser executados,
garantindo assim que o software sempre atenda os requisitos definidos. Para tal, o uso de
testes automatizados é importante já que, após a automatização dos testes, os mesmos
podem ser facilmente executados, no momento que se desejar, principalmente quando
ocorrer mudanças na implementação, garantindo assim a qualidade do software que está
sendo desenvolvido.
• Entrega de software funcionando em pequenos intervalos de tempo. Ao final de cada
iteração, é entregue para o cliente uma nova versão do software, em funcionamento. Essa é
uma característica apontada como essencial por todos os adeptos de métodos ágeis e
também podemos concluir como sendo uma grande vantagem dos métodos ágeis. Mesmo
que seja uma pequena versão, com poucos requisitos implementados e com poucas
funcionalidades disponíveis para o cliente, a constante entrega de software em um curto
espaço de tempo traz como vantagens a satisfação do cliente, que percebe que o sistema
49
está evoluindo rapidamente. Outro fator importante é que as alterações que o cliente sugere
ou que são necessárias devido a alguma mudança de requisito ou algum erro de
implementação são rapidamente corrigidos e entregues para o cliente em um curto espaço de
tempo, fazendo assim com que possíveis propagações de erros sejam minimizadas.
3.8.2 Desvantagens dos métodos ágeis em relação aos métodos
tradicionais
• Na maioria das vezes não é possível a colaboração constante do cliente. Como visto
anteriormente, as alterações de requisitos são fatores constantes durante o desenvolvimento
de software. Isso se deve ao fato de que, com o tempo, o entendimento do negócio o qual o
software pretende resolver vai se aprimorando e afinando. Esse aprimoramento e afinamento
do entendimento do negócio se dá através da constante comunicação com o cliente do
software a ser desenvolvido. Mas devido a problemas como falta de horário para reuniões,
compromissos emergenciais, distância geográfica, entre outros, manter contato constante
com o cliente se torna uma tarefa difícil, prejudicando o aprimoramento e afinamento do
entendimento do negócio e, por vezes, adiando possíveis sugestões de melhorias, correções
de implementação e alterações de requisitos do sistema.
• Mudança radical na cultura da empresa. Outro fator que pode ser apresentado como
desvantagem dos métodos ágeis é a cultura fortemente presente na maioria das empresas
que desenvolve software. Essa cultura prega a utilização de uma documentação fortemente
detalhada, estrutura de projeto extremamente rígida e burocrática e também membro da
equipe de desenvolvimento com papéis extremamente rígidos e não flexíveis. Enquanto isso,
os métodos ágeis sugerem que a equipe de desenvolvimento de software deve ser auto-
gerenciável e auto-organizável, a estrutura do projeto deve ser flexível e simplista, dando
mais ênfase para a comunicação do que para uma documentação detalhada. Sendo assim, a
cultura implantada na maioria das empresas que desenvolve software faz com que a
utilização de métodos ágeis tenha uma grande resistência por parte de todos que fazem parte
dessa cultura instalada.
50
• Dificuldade para adequação onde se utiliza modelos de certificação de qualidade de
software (CMMI, MPS.BR). Os métodos ágeis definem que a estrutura de um projeto de
desenvolvimento de software deve ser flexível e simplista, dando maior prioridade para a
comunicação entre os indivíduos do que para a documentação detalhada do software. Assim,
como a maioria dos modelos de certificação de qualidade de software (CMMI, MPS.BR)
necessita que a documentação do software seja extremamente detalhada e com vários níveis
de evidência que comprovem que a documentação e a implementação do software estão
compatíveis, a utilização de métodos ágeis pode ser difícil dentro deste contexto. Existem
alguns estudos recentes nessa área, onde a utilização de métodos ágeis se adequaria às
exigências dos modelos de certificação de qualidade de software, mas um trabalho mais
aprofundado nesta área seria extremamente benéfico para todos aqueles que desejam utilizar
métodos ágeis durante o desenvolvimento do software, mas que também desejam contar
com a certificação de um dos modelos de qualidade de software.
3.8.3 Características necessárias que uma equipe de
desenvolvimento de software deve ter para utilizar métodos
ágeis
• Equipes pequenas. Como a comunicação é um dos fatores primordiais para a utilização de
métodos ágeis, a utilização de equipes pequenas é uma das características primordiais que
uma equipe de desenvolvimento de software deve possuir. A constante interação dos
membros da equipe de desenvolvimento é um dos fatores que podem garantir que a
utilização de métodos ágeis seja realizada com sucesso. Em equipes muito grandes a
comunicação entre todos os membros da equipe se torna uma tarefa muito complicada, onde
a possibilidade de todos se reunirem constantemente acaba sendo prejudicada. A quantidade
máxima de uma equipe que utiliza métodos ágeis de desenvolvimento de software é de 12
pessoas.
51
• Membros com elevada maturidade no desenvolvimento de software. Como uma nova
versão do software deve ser entregue após o final de cada iteração e o tempo para a
realização de cada iteração é curto (em média 2 semanas), o grau de maturidade dos
membros deve ser elevada, já que a existência de atrasos deve ser mínima. Indivíduos com
baixo nível de maturidade tendem a ter mais dificuldade neste caso, pois necessitam de mais
tempo para estudar e aprimorar conceitos e novas tecnologias a serem utilizadas durante a
fase de desenvolvimento. O alto grau de maturidade também se torna necessário diante da
priorização do que deve ser feito a cada iteração, da definição da arquitetura do software e da
análise de impactos que as alterações de requisitos durante a fase de desenvolvimento do
projeto.
• Capacidade de trabalho em grupo. A cooperação entre os membros da equipe é primordial,
já que qualquer membro da equipe pode, a qualquer hora, realizar alterações no código do
sistema. Assim, o compartilhamento de lições aprendidas e os casos de sucesso verificados
durante a fase de desenvolvimento devem ser práticas constantes dos membros da equipe
de desenvolvimento, fazendo com que todos estejam nivelados em relação ao andamento do
desenvolvimento do projeto.
• Capacidade de se comunicar bem. Como o compartilhamento de lições aprendidas e os
casos de sucesso verificados durante a fase de desenvolvimento devem ser práticas
constantes dos membros da equipe de desenvolvimento, a comunicação entre os membros
da equipe também deve ser realizada de forma eficiente, garantindo assim que todos os
membros da equipe de desenvolvimento tenham pleno conhecimento do que está
acontecendo em todas as fases do projeto. Assim, caso não haja boa comunicação entre os
membros do projeto, o entendimento entre os membros pode ser divergente, ocasionando
possíveis falhas já solucionadas em futuras implementações de novas versões. Se a
comunicação entre os membros da equipe fosse eficiente, todos teriam conhecimento da
correção de falhas já detectadas, minimizando a incidência de falhas no sistema.
52
• Capacidade de se adaptar a mudanças. A adaptabilidade e a flexibilidade devem ser
características dos membros de uma equipe de desenvolvimento de software que utiliza
métodos ágeis. A capacidade de analisar as alterações de requisitos realizadas buscar a
melhor forma de implementar e de se resolver possíveis problemas que estas alterações
possam ocasionar deve ser característica fundamental para todos os membros da equipe de
desenvolvimento. Membros com visões rígidas e burocráticas em relação a alterações de
requisitos durante o andamento do projeto não são recomendados para equipes de
desenvolvimento de software que desejam utilizar algum método ágil de desenvolvimento de
software.
• Capacidade de aceitar críticas. Como a comunicação entre os membros da equipe de
desenvolvimento de software é constante e a troca de informações, sugestões e críticas entre
os membros é fundamental para o andamento do projeto, a capacidade de aceitar críticas e
utilizá-las como estimulante para o aperfeiçoamento profissional é também mais uma
característica fundamental para todos os membros da equipe de desenvolvimento. Membros
com dificuldade na aceitação de críticas podem causar problemas de relacionamento,
dificultado a comunicação entre todos os membros da equipe de desenvolvimento e ponde
em risco o projeto que utiliza algum método ágil de desenvolvimento.
• Capacidade de auto-gerenciamento e auto-organização. As constantes alterações de
requisitos do sistema e a flexibilidade na definição dos papéis de cada membro da equipe traz
a necessidade de que cada membro da equipe de desenvolvimento possua um alto nível de
auto-gerenciamento, no sentido de definir, em conjunto, quais atividades cada membro da
equipe deve desenvolver durante cada iteração. Com iterações curtas, a auto-organização
dos membros é extremamente importante, pois garante que o trabalho definido para cada
membro da equipe de desenvolvimento seja realizado organizadamente, evitando atrasos nos
prazos definidos para finalização das versões a serem entregues ao cliente.
53
3.9 Contribuições
Através deste trabalho podemos extrair algumas conclusões sobre as vantagens e
desvantagens de se utilizar métodos ágeis de desenvolvimento de software, bem como as
características necessárias que uma equipe de desenvolvimento de software deve possuir para que a
utilização de métodos ágeis seja realizada de maneira eficiente e garanta a qualidade do software a
ser desenvolvido.
Também foi realizada a comparação entre os métodos ágeis e os métodos tradicionais de
desenvolvimento de software através de características comuns entre os dois métodos.
Assim, analisados e concluídos os objetivos do trabalho, podemos citar abaixo as
contribuições que este trabalho oferece para o leitor que deseja conhecer mais sobre métodos de
desenvolvimento de software
• Comparação entre métodos ágeis e métodos tradicionais de desenvolvimento de software
através de características comuns entre eles:
o Levantamento de necessidades e requisitos
o Interação com o cliente
o Número de indivíduos que compõe a equipe de desenvolvimento
o Grau de maturidade dos indivíduos que compõe a equipe de desenvolvimento
o Prazos e custos da construção de um software
o Testes e entrega do software para o cliente
o Manutenção do software em produção
• Vantagens de se utilizar métodos ágeis
• Desvantagens de se utilizar métodos ágeis
• Características necessárias que uma equipe de desenvolvimento de software deve ter para
utilizar métodos ágeis
54
3.10 Trabalhos futuros
Como visto durante este trabalho, métodos ágeis de desenvolvimento de software tem como
um de seus focos principais a comunicação, que priorizada em relação à documentação detalhada do
software a ser desenvolvido. Mas para empresas que buscam certificações de qualidade de
desenvolvimento de software (CMMI, MPS.BR, etc.) a falta de uma documentação detalhada sobre o
software a ser desenvolvido pode causar alguns problemas na busca dessas certificações.
Um trabalho que possa vir a analisar os artefatos exigidos na obtenção das certificações de
qualidade de modo a se adequarem aos métodos ágeis de desenvolvimento de software seria muito
interessante, já que a busca por certificações de qualidade e a utilização de métodos ágeis estão
cada vez mais entre os objetivos da empresas que desenvolvem softwares.
Já há um trabalho neste sentido, mas foca apenas na utilização de Scrum em empresas que
utilizam CMMI [CesarCMMI].
O trabalho sugerido deveria englobar vários métodos ágeis em relação as duas certificações
de qualidade mais reconhecidas pelo mercado de software brasileiro: CMMI e MPS.BR.
Outro estudo que pode ser aprofundado utilizando este trabalho como base seria o
desenvolvimento de ferramentas case para gerenciamento e documentação de um projeto de
software utilizando metodologias ágeis.
Muitas empresas utilizam “post-it” colados na parede para documentar um projeto de
desenvolvimento de software utilizando métodos ágeis. O desenvolvimento de uma ferramenta case,
que simularia o ambiente onde os “post-it” são colados, seria de grande utilidade para toda a equipe
nos casos onde algum membro da equipe necessite trabalhar no estilo “home-office”, diretamente no
escritório do cliente ou em lugares remotos.
Assim, a ferramenta case disponibilizaria todo o ambiente de “post-it” na Internet e, de
qualquer lugar do mundo onde haja uma conexão com a Internet, todos os membros da equipe teriam
acesso a documentação, além de poder acompanhar e realizar alterações de modo que todos os
membros da equipe estejam sempre alinhados com as alterações realizadas na documentação.
55
Referências Bibliográficas
[Cesar2007] PEREIRA, Paulo; TORREÃO, Paula; MARÇAL, Ana Sofia. Entendendo
Scrum para Gerenciar Projetos de Forma Ágil, 2007. Disponível em:
http://www.cesar.org.br/files/file/SCRUM_MundoPM-Abril-Maio-2007.pdf.
Acesso em: 12 out. 2008.
[CesarCMMI] MARÇAL, Ana Sofia Cysneiros; FREITAS, Bruno Celso Cunha de; SOARES,
Felipe Santana Furtado; MACIEL, Teresa Maria Medeiros; BELCHIOR,
Arnaldo Dias. Estendendo o SCRUM segundo as Áreas de Processo de
Gerenciamento de Projetos do CMMI, 2007. Disponível em:
http://www.cesar.org.br/files/file/SCRUMxCMMI-CLEI-2007.pdf. Acesso em:
12 out. 2008.
[Chaos] Standish Group. The CHAOS Report, 1994.
http://www.standishgroup.com/sample_research/chaos_1994_1.php.
Acesso em: 18 set. 2008.
[Dias2008] DIAS, Marisa Villas Boas. Um novo enfoque para o gerenciamento de
projetos de desenvolvimento de software. 2005. Tese de mestrado -
Departamento de Administração da Faculdade de Economia, Administração e
Contabilidade, Universidade de São Paulo, São Paulo, 2005. Disponível em:
<http://www.teses.usp.br/teses/disponiveis/12/12139/tde-03012006-122134/>.
Acesso em: 21 out. 2008.
[Filho2008] FILHO, Dairton Luiz Bassi. Experiências com desenvolvimento ágil. 2008.
Tese de mestrado - Instituto de Matemática e Estatística, Universidade de
São Paulo, São Paulo, 2008. Disponível em:
<http://www.teses.usp.br/teses/disponiveis/45/45134/tde-06072008-203515/>.
Acesso em: 18 set. 2008.
[Filho2002] FILHO, Edes Garcia da Costa. Métodos Ágeis, 2002, Ufscar. Disponível em
<http://www2.dc.ufscar.br/~junia/MetAgEds.pdf>. Acesso em 26 out. 2008
[Franco2007] FRANCO, Eduardo Ferreira. Um modelo de gerenciamento de projetos
baseado nas metodologias ágeis de desenvolvimento de software e nos
princípios de produção enxuta, 2007. Tese de mestrado – Escola
Politécnica, Universidade de São Paulo, São Paulo, 2007. Disponível em:
<http://www.teses.usp.br/teses/disponiveis/3/3141/tde-09012008-155823/>.
Acesso em: 05 set. 2008.
56
[Nascimento2008] NASCIMENTO, Gustavo Vaz. Um modelo de referência para o
desenvolvimento ágil de software. 2008. Tese de mestrado - Instituto de
Matemática e Estatística, Universidade de São Paulo, São Carlos, 2008.
Disponível em:
<http://www.teses.usp.br/teses/disponiveis/55/55134/tde-07052008-170413/>.
Acesso em: 29 set. 2008.
[ManifestoAgil2001] BECK, Kent; BEEDLE, Mike; BEENEKUM, Arie van; COCKBURN, Alistair;
CUNNINGHAM, Ward; FOWLER, Martin; GRENNING, James; HIGHSMITH,
Jim; HUNT, Andrew, JEFFRIES, Roland; KERN, Jon; MARICK, Brian,
MARTIN, Robert C.; MELLOR, Steve, SCHWABER, Ken, SUTHERLAND,
Jeff, THOMAS, Dave. Manifesto for Agile Software Development, 2001.
Disponível em <http://www.agilemanifesto.org>. Acesso em: 27 out. 2008.
[Pressman2004] PRESSMAN, ROGER, S. Engenharia de Software. McGraw-Hill, 6ª edição,
2004.
[RUP1999] Jacobson, Ivar; BOOBH, Grady; RUMBAUGH, J. The Unified Software
Development Process. Addison-Wesley, 1999.
[RUP2008] KRUCHTEN, Philippe. What Is the Rational Unified Process?, 2001.
Disponível em:
<http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan
01/WhatIstheRationalUnifiedProcessJan01.pdf>
Acesso em: 12 nov. 2008.
