CURSO SUPERIOR DE TECNOLOGIA EM ANALISE E

DESENVOLVIMENTO DE SISTEMAS

ROSANGELA CATHIA SILVA COSTA

ANTONIO DE PADUA LINO DANTAS
EDUARDOSERGIO DA SILVA ATHAN
GIL RAMISON SANTOS EVANGELISTA DE CASTRO
JONATHAS MARCELLO GUIMARAES DE SOUZA
WALLACE DIAS BEZERRA

ATIVIDADE DE PORTFÓLIO
ATIVIDADE DE PRODUÇÃO TEXTUAL

Juazeiro-BA
2010

ROSANGELA CATHIA SILVA COSTA

 ANTONIO DE PADUA LINO DANTAS
EDUARDOSERGIO DA SILVA ATHAN
GIL RAMISON SANTOS EVANGELISTA DE CASTRO
JONATHAS MARCELLO GUIMARAES DE SOUZA
WALLACE DIAS BEZERRA

ATIVIDADE DE PORTFÓLIO
ATIVIDADE DE PRODUÇÃO TEXTUAL

Trabalho apresentado ao Curso (Tecnlogia em Analise e

Desenvolvimento de Sistemas) da UNOPAR -
Universidade Norte do Paraná, para a disciplina
[ENGENHARIA DE SOFTAWARE]
Orientador: Prof. Luis Flavio Perini

Juazeiro-BA
20-10-2010

SUMARIO
1 – INTRODUÇÃO
2- CONCEITO
3- DESENVOLVIMENTO SOFTWARE
3.1 Processo de Desenvolvimento de Software Sistematizado
3.1.1 Fases do Desenvolvimento de Software
3.1.1.1 Fase de Definição
3.1.1.2 Fase de Desenvolvimento
3.1.1.3 Fase de Manutenção
3.2 MODELOS DE PROCESSO DE SOFTWARE
3.2.1Modelo Sequencial Linear
3.2.2Modelo de Prototipagem
3.2.3Modelo RAD – Rapid Application Development
3.3 MODELOS DE PROCESSOS EVOLUCIONÁRIOS
3.3.1 Modelo Incremental
3.3.2 Modelo Espiral
3.4 METODOLOGIAS DE DESENVOLVIMENTO TRADICIONAIS OU “PESADAS
3.4.1 RUP – Rational Unified Process
3.5 METODOLOGIAS DE DESENVOLVIMENTO ÁGEIS OU LEVES
3.5.1 Extreme Programming – XP
3.5.2 Feature driven development – FDD
3.5.2.1 SCRUM
4 – CONCLUSÃO
5- REFERENCIAS

INTRODUÇÃO
 Este trabalho propõe uma análise comparativa de duas frentes
destas metodologias, as tradicionais, que têm como característica a grande
quantidade de documentos gerados, “atrasando” o desenvolvimento do projeto, e as
metodologias ágeis, que se opõem às tradicionais evitando, sempre que possível, a
documentação e focando a codificação do projeto.

Para isso linguagens para modelagem do sistema, como a UML, foram

criadas. Além das linguagens, principalmente, foram desenvolvidas metodologias de
desenvolvimento de software, onde passos eram detalhados para que o processo de
desenvolvimento seguisse um padrão e assim atingisse a qualidade necessária.
Com o tempo, as metodologias se tornaram mais complexas e distintas
melhorando a qualidade do produto, independente do foco do sistema sempre
haveria uma metodologia para manter a qualidade.
Este trabalho propõe uma análise comparativa de duas frentes destas
metodologias, as tradicionais, que têm como característica a grande quantidade de
documentos gerados, “atrasando” o desenvolvimento do projeto, e as metodologias
ágeis, que se opõem às tradicionais evitando, sempre que possível, a documentação
e focando a codificação do projeto.
2 - Conceito

Desde a Crise do Software, que forçou com que as Software Houses

realizadas sem projetos de desenvolvimento de Software de uma maneira mais
profissional e organizada, gerando uma documentação para acompanhar o produto,
muitas metodologias para esse desenvolvimento surgiram. Linguagens foram
criadas para modelar e facilitar o entendimento do produto pelo cliente e pela própria
empresa desenvolvedora.
Essa documentação gerada a partir na análise da especificação dos
projetos, era acompanhada de um método de desenvolvimento para especificar ao
cliente o que seria desenvolvido e como isso seria feito. Foi então que surgiram
Métodos para visualizar o processo de desenvolvimento, dividindo-o em etapas,
sempre com foco na qualidade final do produto.

Os processos sempre começavam com uma primeira etapa de

Análise, onde os requisitos eram estabelecidos de acordo com a necessidade do
cliente. Depois da Análise, tem-se a Modelagem que gera os documentos
necessários e por último o Desenvolvimento e a fase de Testes.
Levando-se em consideração que o processo de desenvolvimento é
bastante mutável, pois o surgimento de novos requisitos (tanto funcionais como não
funcionais) por parte do cliente é normal, assim como a não conformidade de
algumas solicitações, era necessário alterar constantemente a documentação e o
produto em si. Isso demandava muito tempo.
Para circular esse problema de constantes alterações, assumindo
que essas mudanças fazem parte do processo de desenvolvimento surgiram os
Métodos Ágeis, aqueles com foco no código e otimizados para alterações de
requisitos, como a Extreme Programming, esses métodos também prezam pela
qualidade do Software, mas a sua filosofia de desenvolvimento é diferente, dando
ênfase principalmente no código, sendo que as alterações necessárias não devem
acarretar em tanto tempo gasto.
Com o surgimento recente de novas Metodologias de
Desenvolvimento de Software – MDS, que dividiram o processo de desenvolvimento
de Software, para organizá-lo, planejá-lo e facilitar o entendimento do mesmo,
existem agora duas principais áreas de atuação, o Desenvolvimento chamado
Tradicional, com embasamento na Análise e Projeto, mantendo tudo em
documentos, porém se tornando lento para mudanças, e o Desenvolvimento Ágil,
baseado em código, totalmente adaptável a mudanças nos requisitos, entretanto
fraco na parte contratual e de documentos.

O trabalho faz um comparativo entre as Metodologias de

Desenvolvimento Tradicional e o Ágil, analisando pontos fortes e fracos de cada
uma e os pontos em comum.
3 – Desenvolvimento do software

Na década de 70, a atividade “desenvolvimento de software” era

executada de forma desorganizada, desestruturada e sem planejamento, gerando
um produto final de má qualidade, pois não existia documentação ou era entregue
fora do prazo ou o levantamento de tempo e esforço não correspondia com a real
necessidade. Muitas vezes, esta atividade não satisfazia as necessidades do cliente,
desperdiçando recursos da empresa e aumentando gastos, que não viriam a ser
compensa- dores para o cliente, demandando tempo, esforço e dinheiro, essa época
ficou conhecida com Crise do Software [PRESSMAN 02].
A partir deste cenário, surgiu a necessidade de tornar o
Desenvolvimento de Software como um processo estruturado, planejado e
padronizado, para que as necessidades fossem atendidas e os gastos com
informatização de processos de informações se tornassem compensadores.
Para o atendimento desta padronização, surgiram Metodologias de
Desenvolvimento, que dividem o processo de desenvolvimento em fases pré-
definidas. Essas Metodologias se adequam às características organizacionais e ao
ambiente de desenvolvimento implementado em uma organização, ao paradigma de
desenvolvimento e ao tipo de plataforma que o Software deve ser desenvolvido, e às
características dos projetos: o tempo que pode ser gasto e a real necessidade do
cliente, a fim de estimar custos e prazos reais.
Entretanto, a Crise do Software perdura até hoje, onde, mesmo com
técnicas avançadas de desenvolvimento e padrões consolidados na área de criação
de Softwares, ainda existem características da época da Crise, como Projetos
atrasados, erros de estimativa de custos e de tempo, que tornam o Processo, ainda
que sistematizado, passível de muitos erros.

3.1 - Processo de Desenvolvimento de Software Sistematizado

No início da padronização do Processo de Desenvolvimento, foram

mantidos conceitos típicos de Engenharia, que ajudaram a sistematizar o processo,
e mais tarde, criando a Engenharia de Software.
Fritz Bauer [PRESSMAN 02] define a Engenharia de Software como:
“A criação e utilização de sólidos princípios da Engenharia a fim de obter software de
maneira econômica, que seja confiável para trabalhar eficientemente em máquinas
reais”. Engenharia é a análise, o projeto, a construção (desenvolvimento), a
verificação e a gestão de elementos técnicos.
O Processo de Desenvolvimento de Software, assim como qualquer
outro, tem um compromisso com qualidade, sendo que esse enfoque na qualidade
se desenvolveu com o passar do tempo, dando surgimento a métodos e abordagens
de Engenharia de Software cada vez amadurecidos, para gerar produtos de
qualidade melhor e a menores custos.

A Engenharia de Software é dividida em camadas, que tem como

foco principal a qualidade final do produto gerado, e como maneira de chegar até ela
é o aperfeiçoamento do Processo de Desenvolvimento, que consiste na criação de
documentos, artefatos e marcos capazes de representar o contexto do software,
levando em consideração recursos, ferramentas, prazos, restrições, e outros
aspectos que envolvem o desenvolvimento de um produto de software
[PRESSMAN].

Para auxiliar nesse processo existem Métodos de Engenharia de Software que

fornecem técnicas de construção, que abrangem a análise de requisitos, projetos,
construção de programas, testes e manutenção. E ainda as Ferramentas, que
servem apenas para fornecer apoio automatizado para processos e métodos.
Numa visão geral do processo de desenvolvimento de um software pode-se
subdividí-lo em três fases genéricas, ou seja, independem da área de aplicação,
tamanho ou complexidade do projeto.

3.1.1 Fases do Desenvolvimento de Software

Numa visão geral do processo de desenvolvimento de software, a

literatura especializada costuma subdividi-lo em três fases genéricas, ou seja,
independem da área de aplicação, tamanho ou complexidade do projeto. Estas três
fases serão detalhadas a seguir [SOMMERVILLE ].

3.1.1.1 Fase de Definição

 É uma das fases principais do projeto, pois é onde se procura
identificar funcionalidades, restrições, validações, interfaces e, principalmente, os
requisitos-chave, que o projeto necessita.
É uma fase de muita interação com o cliente para validar todas as
informações por ele passadas e com ele coletadas, a fim de que todos os requisitos-
chave sejam atendidos de maneira correta no decorrer da implementação do
produto de software.
É composta de três sub-tarefas principais, que são executadas
independente dos métodos utilizados nesta fase, que podem variar de acordo com o
paradigma usado. As sub-tarefas são: a Engenharia de Sistemas, que visa entender
e definir objetivos do sistema; o Planejamento do Projeto, que tenta determinar com
o máximo de exatidão, custos, tempo, esforço e recursos que são necessários para
conclusão do projeto; e a Análise de Requisitos, a fim de entender os requisitos
(necessidades) específicos necessários para construir um software de qualidade.

3.1.1.2 Fase de Desenvolvimento

Tenta definir como os dados serão estruturados, como a função

deve ser implementada. Em outras palavras, é quando o projeto, que antes estava
todo documentado em papel, passa a ser transformado em código para entrar em
operação de fato.
Linguagens de programação, técnicas e métodos, podem ser
diferentes, dependendo da metodologia escolhida, porém tarefas básicas, comuns a
todas as metodologias, devem ser realizadas, como o Projeto de Software, parte
central do desenvolvimento, que mostra o que e como será desenvolvido, e a
Geração de Código, que é traduzir em linguagem de programação o que foi
especificado no projeto de software.
Alguns autores colocam a fase de testes dentro da fase de
Desenvolvimento, como parte das tarefas básicas dessa fase, porém o mais
importante é que ela, não pode deixar de existir, pois é justamente nesta fase que se
encontram não conformidades com aquilo que foi especificado na fase de Definição,
que não atende as exigências do cliente, diminuindo assim a qualidade final do
produto.

3.1.1.3 Fase de Manutenção

 É a fase final, pois nela se analisa todo o produto. Tem como
foco principal as modificações, sejam elas correções de erros, adaptações
necessárias e novas funcionalidades (melhorias) para evoluir o software.
Como alterações ocorrem, a fase de manutenção engloba algumas
características das fases anteriores, porém seu enfoque passa a ser um
software já existente. É nesta fase onde as empresas que desenvolvem
softwares obtêm maior parte dos lucros, pois contratos de manutenção são
assinados garantindo receita fixa.

Existem quatro tipos de modificações que podem ocorrer, durante a

fase de manutenção. São elas:

• Manutenção Corretiva: visa corrigir defeitos que ocorreram durante a fase

de desenvolvimento;
• Manutenção Adaptativa: modifica o software para adaptá-lo à alterações no
ambiente externo, composto de variáveis que não do escopo do sistema,
como uma mudança de sistema operacional;

• Manutenção Perfectiva: adiciona novas funcionalidades ao software. Essas

novas especificações estão fora do projeto original, e devem ser
consideradas como melhorias de produto;

• Manutenção Preventiva: assume que mudanças, tanto no ambiente externo,

quanto de especificações, vão ocorrer, portanto já prepara o produto para que
o impacto causado por essas alterações não afete o software. Também é
conhecida como Reengenharia de Software, que nada mais é que a
reconstrução de algo real que já foi desenvolvido, para melhorá-lo.

3.2 MODELOS DE PROCESSO DE SOFTWARE

Para tornar o desenvolvimento de software uma atividade menos

caótica, surgiram os Modelos de Processo de Software, que visam organizar o
desenvolvimento utilizando as técnicas e métodos descritos acima.
[SOMMERVILLE]
Dependendo do tipo de projeto a ser desenvolvido modelos
diferentes serão utilizados, porém todos seguem um determinado ciclo, onde
existem quatro fases distintas, que vão caracterizar o modelo.
A primeira fase é a Situação Atual, que define como está o
ambiente. A Definição do Problema indica qual o problema específico que está se
tentando resolver. O Desenvolvimento Técnico, que resolve o problema de maneira
que satisfaça as necessidades, e, por último, a Integração da Solução, que entrega
a solução ao cliente.

Essas quatro fases, quando colocadas em seqüência, formam um

ciclo, sendo que dentro de cada uma dessas fases desse ciclo, existe um outro ciclo
mais interno com um problema em escala menor, e assim sucessivamente, deixando
uma idéia de recursividade. Essa recursividade acaba em níveis racionais, quando
uma solução resolver o problema definido [PRESSMAN].
As seções a seguir descrevem sucintamente cada um dos modelos
encontrados nas literaturas especializadas [SOMMERVILLE], [PRESSMAN].

3.2.1 Modelo Sequencial Linear

Esse modelo, proposto em 1970, é também conhecido como Modelo

em Cascata onde as fases definidas são sistematicamente seguidas de maneira
linear [PRESSMAN 02].
É o modelo mais usado em todo o mercado, porém não é o mais
eficaz, pois raros projetos seguem esse fluxo linear, além das mudanças de
requisitos que ocorrem no decorrer do projeto não serem de fácil adaptação, porque
alteram toda a documentação já desenvolvida, o que implica em retrabalho
[PRESSMAN 02].
Mesmo com todos estes problemas, este modelo ainda é bem
melhor e mais eficiente que um projeto que não segue nenhum padrão.
O modelo é dividido em etapas pré-definidas, que são: Modelagem,
uma vez que o software interage com o sistema, é importante saber como o mesmo
funciona a fim de prover a compatibilidade com os demais módulos existentes do
sistema como um todo. Análise, onde os requisitos do software são levantados
(elicitados) e definidos para entender como o software funcionará. Projeto, que é a
representação dos requisitos, é subdividido em 4 atributos: Estrutura de Dados, que
é a maneira que os dados vão ser tratados, Arquitetura de Software, que define a
base estrutural de como o sistema deve ser desenvolvido, Caracterizações das
Interfaces, repre- sentam o meio entre o usuário e o sistema, bem como entre os
módulos do sistema, e Detalhes Procedimentais [PRESSMAN 02]. A Codificação,
que traduz os requisitos especificados nas etapas anteriores em linguagem de
máquina. Testes, os quais são responsáveis por identificar se todas as
funcionalidades desenvolvidas estão funcionando perfeitamente, ou seja, garantir
que esteja de acordo com o que foi especificado. Por último a Manutenção, que
corrige erros encontrados após a liberação para o cliente, implementando melhorias
ao produto, isso implica em um novo ciclo de desenvolvimento.

3.2.2 Modelo de Prototipagem

Esse modelo é muito utilizado quando nem todos os requisitos de
sistema são definidos de maneira clara pelo cliente. Apenas os objetivos de sistema
são descri- tos, mas não a maneira com que os dados serão processados e como a
saída será mostrada.
A característica principal desse modelo é gerar protótipos do sistema
com definições de requisitos dadas pelo cliente. Essas definições geram
documentos que, por sua vez resultam no protótipo. Esse protótipo é então testado
pelo cliente para validar suas funcionalidades [PRESSMAN 02].
Após o teste do protótipo o ciclo de desenvolvimento se repete. O
engenheiro de software, que é aquele responsável por fazer a coleta das
necessidades do cliente, juntamente com o cliente faz o levantamento de novas
funcionalidades, que serão desenvolvidas e adicionadas ao protótipo já criado.
Quando todas as funcionalidades que o sistema deveria prover
estiverem desenvolvidas e validadas, o protótipo é descartado para que o sistema
real seja desenvolvido com base no que foi especificado com o protótipo, agora
dando ênfase, também, a características não-funcionais: segurança,
manutenibilidade e qualidade do produto; procurando soluções ideais para os
problemas.
 O modelo de prototipagem tem a grande vantagem de gerar
resultados visíveis para o cliente de uma maneira veloz, e ao final de cada ciclo,
onde novas funcionalidades são adicionadas, pode mostrar a evolução do sistema.
Por se tratar de protótipos, nem sempre a solução escolhida para
resolver tal problema é a ideal, pois não leva em consideração as variáveis de
ambiente, como o sistema operacional onde o software funcionará ou se a
linguagem de programação é adequada. O desenvolvedor pode acabar se
acostumando com a idéia de utilizar o protótipo que foi gerado como parte integral
do sistema, deixando “brechas” e possíveis erros [PRESSMAN 02].

3.2.3 Modelo RAD – Rapid Application Development

O RAD é um modelo incremental, considerado uma adaptação para

projetos curtos, usualmente com prazo máximo de 90 dias, do modelo sequencial
linear. Sua principal característica é que o produto de software seja desenvolvido em
componentes, pois a reutilização de código permite que a equipe de
desenvolvimento possa desenvolver um sistema completamente funcional em pouco
tempo.
Igualmente aos outros modelos, o RAD é subdividido em fases, que
são:
• Modelagem de Negócios: responsável por definir arquiteturas que
permitam ao negócio (sistema) utilizar informações colhidas de maneira efetiva;

• Modelagem de Dados: responde a questões relacionadas a objetos de

dados utilizando diagramas como o modelo de entidade e relacionamento (MER);

• Modelo de Processo: descreve os processos básicos para manipular

as informações contidas nos objetos de dados gerados pela fase anterior, montando
assim um fluxo de informações;

• Geração da Aplicação: utiliza ferramentas automatizadas para criar ou

reusar componentes já desenvolvidos;
 • Teste e Entrega: testa a integração entre componentes já criados em
outros projetos que foram reutilizados e os que foram desenvolvidos para o atual
projeto. Testa-se também as interfaces criadas.
RAD, assim como outros modelos, possui desvantagens. Visto que a
principal característica do RAD é a modularização, e para isso os requisitos
precisam estar bem definidos e com um certo grau de independência entre eles. Se
uma das situações citadas não ocorrerem o modelo pode não ser adequado.
Para que o RAD possa ser utilizado de maneira eficiente, é
necessário que existam uma quantidade de recursos suficientes para montar as
equipes RAD de desenvolvimento. Isto é considerado como um grande problema
nos projetos grandes, pois são mais difíceis de gerenciar.

3.3 Modelos de Processos Evolucionários

Assumindo que os sistemas tendem a evoluir durante o

desenvolvimento e essa evolução acrescenta novas funcionalidades ao projeto, que
aumenta as especificações e, como uma “bola de neve”, crescem até que estouram
o prazo definido na negociação, os modelos evolucionários têm como principal
característica a interatividade, com isso é possível desenvolver versões do sistema
que a cada novo lançamento (release) agrega novas funcionalidades.
As seções a seguir descrevem alguns exemplos de Modelos
Evolucionários [PRESSMAN 02], [SOMMERVILLE 00].

3.3.1 Modelo Incremental

Esse modelo é a “versão” evolucionária do Modelo Sequencial

Linear. Apenas assume que o software desenvolvido pode sempre crescer e agregar
novas funcionalidades, sendo que cada uma dessas funcionalidades, ou o conjunto
delas, será desenvolvido por um incremento e esse incremento segue todas as
etapas descritas no modelo linear [PRESSMAN 02].
O primeiro incremento deste modelo é chamado de Núcleo do
Produto, pois nele estarão as principais funcionalidades do sistema, aquelas
consideradas vitais. Os próximos incrementos desenvolvidos agregarão as funções
do Núcleo do Produto e dos incrementos anteriores já desenvolvidos. Esse modelo é
análogo a uma “bola de neve” que cresce e atinge sua totalidade quando o produto
está completamente desenvolvido [PRESSMAN 02].
O modelo incremental é muito utilizado em projetos longos e que
tendem a crescer com o passar do tempo e o prazo de entrega é curto. Como, ao
final de cada incremento, é gerada uma versão do produto final, é possível mostrar
ao cliente como está o andamento do projeto e atingir as metas definidas no começo
do projeto.

3.3.2 Modelo Espiral

O Modelo Espiral é um modelo iterativo, como o modelo de

prototipagem, e sistemático como o Modelo Linear. Isso facilita com que sejam
lançadas versões utilizáveis do projeto ao final de cada iteração do modelo, similar
ao modelo incremental. É muito utilizado no desenvolvimento de softwares em
conjunto com o paradigma da orientação a objetos, onde o desenvolvimento em
módulos, somado ao processo de integração, se encaixa nos conceitos do
paradigma [PRESSMAN 02].
Esse modelo se subdivide em Regiões de Tarefa. Essas regiões
abrigam conjuntos de tarefas que crescem proporcionalmente ao risco e ao tamanho
do projeto. Basicamente existem 6 regiões, sendo que todas podem ser usadas, ou
não, em um projeto. São elas: Comunicação com o Cliente, a fim de manter contato
com o cliente, adquirindo informações úteis ao sistema; Planejamento, que definirá
custo e tempo de desenvolvimento; Análise de Risco, gerenciamento e recuperação
de riscos; Engenharia, que á construção da representação da aplicação; Construção
e Liberação, onde acontecem a implementação, testes, instalação e suporte da
aplicação, e Avaliação pelo Cliente, quando se tem o feedback quanto ao
incremento desenvolvi- do [PRESSMAN 02].
Uma forte característica desse modelo, que o difere de outros
modelos e o torna bastante utilizado pelas empresas, é o fato de acompanhar toda a
vida do software, mesmo depois da entrega ao cliente, pois é na manutenção que
muitas empresas desenvolvedoras têm o principal foco de atuação.
Este modelo é o considerado mais realístico possível, pois assume
que usuários, analistas e desenvolvedores adquirem maior conhecimento sobre o
projeto com o decorrer do tempo [SOMMERVILLE 00].
3.4 METODOLOGIAS DE DESENVOLVIMENTO TRADICIONAIS OU “PESADAS

Metodologia de Desenvolvimento é um conjunto de práticas

recomendadas para o Desenvolvimento de Softwares, sendo que essas práticas,
geralmente, passam por fases ou passos, que são subdivisões do processo para
ordená-lo e melhor gerenciá-lo [SOMMERVILLE 00].
As metodologias consideradas tradicionais, também chamadas de
“pesadas”, têm como característica marcante serem divididas em etapas e/ou fases.
Essas fases são muito bem definidas e englobam atividades como Análise,
Modelagem, Desenvolvimento e Testes.
Cada fase concluída gera um marco, que geralmente é algum
documento, protótipo do software ou mesmo uma versão do sistema. Esses marcos,
dependendo do final de que etapa foram criados, podem ser documentos, como
Diagramas de UML (Unified Modeling Language – é a linguagem padronizada de
modelagem de sistemas orientados a objetos para visualização, construção,
especificação e documentação do sistema), ou algum protótipo do software.

Muitas “metodologias” pesadas são desenvolvidas no modelo em

cascata o que dificulta o controle do projeto, pois a cada alteração em determinado
ponto do projeto, como os requisitos, será necessário uma volta ao início do mesmo
para alteração de documentação ou outro marco [PRESSMAN 02].
O foco principal das metodologias tradicionais é a previsibilidade dos
requisitos do sistema, que traz a grande vantagem de tornar os projetos
completamente planejados, facilitando a gerência do mesmo, mantendo sempre uma
linha, caracterizando o processo como bastante rigoroso [OLIVEIRA 04].

3.4.1 RUP – Rational Unified Process

Para melhor analisarmos as características das metodologias pesadas,

veremos o principal framework utilizado comercialmente no mercado, o RUP.
O maior expoente das metodologias “pesadas” é o RUP, um Processo de
Engenharia de Software criado pela Rational Software Corporation e oriundo do
Processo Unificado – UP – para descrever como desenvolver um software usando
técnicas comerciais com o objetivo de aumentar a qualidade dos softwares gerados
pela empresa desenvolvedora.
O RUP é aplicável em classes de projetos variadas, sendo considerado um
framework genérico para os processos de desenvolvimento, a contar que este deve
ser configurado de acordo com o tamanho e a necessidade de cada projeto e/ou
empresa desenvolvedora.
O RUP é uma metodologia iterativa, ou seja, trabalha em ciclos de
desenvolvimento. Isso provê vários benefícios como [KRUCHTEN 00]:
• Gerenciamento de Requisitos: após do começo do desenvolvimento, é
comum que os requisitos mudem, fazendo com que haja alterações na
documentação. Desenvolvendo iterativamente, essas alterações são
facilmente gerenciáveis;
• Integração dos Elementos: quando cada módulo é desenvolvido este é
integrado ao sistema como um todo, evitando que este seja um problema no
final do projeto;
• Gerenciamento de Riscos: a cada iteração é possível analisar pontos
críticos e planejar estratégias para não se perder tempo durante o
desenvolvimento;
• Testes: os testes são realizados ao final de cada módulo, permitindo que
erros e não-conformidades possam ser tratados ainda dentro do mesmo ciclo.

3.5 METODOLOGIAS DE DESENVOLVIMENTO ÁGEIS OU LEVES

No começo de 2001, motivados pela observação de times de

desenvolvimentos, perdidos entre os processos que existiam na época, alguns
experts da indústria do desenvolvimento de softwares se uniram para encontrar
valores e princípios relacionados ao desenvolvimento, que seriam capazes de fazer
com que os times, também chamados de equipes, de desenvolvimento pudessem
responder mais rápidos às mudanças nas especificações e que o projeto fosse
desenvolvido mais rapidamente.
Depois de algum tempo de pesquisa, esses experts escreveram um
manifesto, que ficou conhecido como Manifesto for Agile Software Development
[FOWLER 01]. Esse manifesto destacava 4 (quatro) valores. São eles:
 • Indivíduos e iterações ao invés de processos e ferramentas;
• Software funcional ao invés de documentação detalhada;
• Colaboração do Cliente ao invés de negociação de contratos;
• Responder às mudanças ao invés de seguir um plano.
Analisando individualmente cada um desses 4 (quatro) valores; as
seções a seguir explicam sucintamente suas definições [BECK 99], [WELLS 04] e
[XISPE 04].

 Indivíduos e iterações ao invés de processos e ferramentas

É certo que a qualidade dos profissionais envolvidos no desenvolvimento do projeto

afeta diretamente a qualidade do produto e o bom desempenho da equipe no
projeto. Ter excelentes profissionais, no entanto, não é certeza de sucesso, pois
estes dependem diretamente do processo. Um mau processo pode fazer com que
os melhores desenvolvedores não sejam capazes de usar de todo o seu talento.

Além da mistura certa do processo adequado com bons profissionais, é

preciso que todo o grupo possa interagir perfeitamente entre si. Comunicação é mais
importante do que simples talento para programação. Um desenvolvedor médio com
bom relacionamento é bem melhor, trabalhando em equipe, é mais produtivo que um
excelente programador trabalhando sozinho.
É importante levar em consideração que, as ferramentas utilizadas são
importantes para o sucesso final do projeto, porém elas não podem ter mais
importância que seus utilizadores. Mais importante que o meio onde se vai trabalhar
é a qualidade e o grau de interação da equipe.

 Software funcional ao invés de documentação detalhada

A documentação de um projeto é extremamente necessária para o sucesso do

projeto, já que o código não é o melhor meio de comunicação entre o racional e a
estrutura do sistema. A documentação legível para descrever o sistema ainda se faz
necessária na tomada de decisões do projeto.
É preciso tomar muito cuidado com a documentação, pois em excesso é pior
do que a falta dela. De nada adianta uma extensa gama de documentos que
demoram muito tempo para serem gerados, se eles não estão em sincronia com o
que está sendo desenvolvido e o que foi especificado. Documentos sem essa

sincronia desvirtuam a realidade do projeto, fazendo com que decisões

erradas possam ser tomadas.
O que é sugerido pelo Manifesto é que somente a documentação
necessária seja gerada, e esta esteja sempre sincronizada com o sistema. Para
evitar erros quais documentos devem ser gerados, é levada em conta a seguinte
prerrogativa: “Nenhum documento é gerado a não ser que seja necessário e
significante.”

O fato de só existir a documentação necessária ajuda na integração

da equipe, pois a transferência de conhecimento sobre o projeto é feita trabalhando
lado a lado, utilizando-se do código, sendo que este não permite duplas
interpretações da funcionalidade e do que o sistema faz, e de alguns dos membros
da equipe ajudando quando necessário.

 Colaboração do Cliente ao invés de negociação de contratos

A venda de um software é muito diferente de um produto qualquer.

Não se consegue um bom software escrevendo suas necessidades num papel e
entregando à empresa que vai desenvolver, esperando que tudo esteja como foi
solicitado no final do prazo estipulado. Projetos tratados desta maneira são falhos,
gerando um produto final de pouca qualidade.
As metodologias ágeis, assumem que para um projeto obter sucesso
e aceitação, gerando um produto de boa qualidade, é preciso que exista sempre um
feed back do cliente para garantir que o software esteja sendo desenvolvido de
maneira que atenda as necessidades.
Contratos que determinam requisitos, prazos e custo de um projeto
são, fundamentalmente, falhos. Isso porque no decorrer do desenvolvimento alguns
requisitos passam a se tornarem dispensáveis enquanto surge a necessidade de se
adicionar outros não previstos em contrato ou especificação. Portanto, o melhor
contrato é aquele que determinará como será a comunicação e o relacionamento do
cliente com a equipe desenvolvedora.
  Responder às mudanças ao invés de seguir um plano

Assumindo que mudanças de especificação sempre vão ocorrer em

todos os projetos, é possível afirmar, que melhor será o projeto que mais se adaptar
a estas mudanças. A flexibilidade é fator fundamental para o sucesso do projeto, ela
determina o quão adaptável o projeto é.

Planos devem, sim, ser traçados, porém, como não é possível

prever o futuro, as visões desses planos não podem ir muito longe. Muito deve ser
planejado para poucas semanas, pouco se planeja para o próximo mês e quase
nada se planeja para próximos anos, pois com as alterações que invariavelmente
irão aparecer, muito difícil será seguir a risca estes planos mais longos.

Os valores citados como fundamentais dentro do Manifesto

inspiraram 12 (doze) princípios básicos, que são características que diferenciam as
Metodologias Ágeis de outras Metodologias chamadas tradicionais.

Esses princípios serão discutidos a seguir [FOWLER 01], [BECK 99]:

A maior prioridade é satisfazer o cliente, lançando versões em pouco

tempo e continuamente.
Como a principal prioridade é por um produto final de qualidade,
foram feitas pesquisas para definir quais as características durante a fase de
desenvolvimento, que foram comuns nos processos que obtiveram sucesso.
O resultado desta pesquisa revelou que o quanto antes se
entregasse uma versão, mesmo que com poucas funcionalidades, do sistema,
melhor seria a qualidade final, pois o sistema começaria a evoluir mais cedo. Sendo
que essas versões deveriam ser atualizadas e entregues num período curto de
tempo.

Um processo ágil é aquele que entrega cedo é constantemente.

Tenta-se entregar o primeiro sistema já com algumas funcionalidades desenvolvidas
e funcionais em algumas semanas do início do projeto, sendo que novos pacotes de
funcionalidades continuam sendo desenvolvidos e integrados ao módulo anterior, no
decorrer de algumas semanas. Isso deve ocorrer constantemente.
 É de opção do cliente, escolher se vai implantar o sistema ainda não
todo completo ou vai apenas testa-lo para definir novas funcionalidades ou encontrar
não- conformidades com aquilo que é necessário.
b) Mudanças dos requisitos são bem-vindas, mesmo tarde durante o
desenvolvimento. Processos Ágeis mudam para a vantagem do cliente.
Indica atitude. Os participantes dos Processos Ágeis não temem
mudanças, pois assumem que as mudanças são indicadores de que o time está
aprendendo sobre o sistema, possibilitando saber se vai satisfazer o mercado.
c) Entregar software funcional frequentemente, de duas semanas a
dois meses. Quanto mais rápido melhor.
A idéia é entregar softwares funcionais regularmente em um curto
período de tempo. Documentações e papéis não contam como entregas, pois não
satisfazem à necessidade atual do cliente.

d) Pessoas de Negócios e Desenvolvedores devem trabalhar em

conjunto.
Um processo ágil precisa ser guiado constantemente, portanto é
necessária a interação freqüente de Clientes, Desenvolvedores e Partes
Interessadas, pois todos fazem parte do time.

e) A equipe deve estar motivada para o sucesso de um projeto.

Os indivíduos são parte fundamental do processo, como citados nos
4 (quatro) valores das Metodologias Ágeis, portanto é fundamental para o sucesso
do projeto que tos estejam motivados, seja com o apoio de outros membros da
equipe ou material e equipamento. Indivíduos motivados trabalham melhor.
f) A maneira mais rápida de se obter informações é conversando.
Conversação e Comunicação são valores básicos dos Processos
Ágeis. Documentos e papéis são supérfluos, apenas escritos quando extremamente
necessitados e significantes. A maneira padrão de troca de informações é a
conversação.
g) O progresso do projeto é medido pela quantidade de software
funcional que existe.
 30% do projeto estão concluídos, quando 30% das funcionalidades
necessárias estiverem funcionando. O volume de documentos e qual fase do
processo se está não determinam o progresso atual do projeto.
h) Processos Ágeis promovem o desenvolvimento sustentável.
A velocidade do desenvolvimento nos Processos Ágeis deve ser
sempre constante. De nada adianta começar um projeto desenvolvendo de maneira
rápida e essa velocidade não ser mantida, pois isso irá iludir o cliente, causando a
ele uma impressão de falsa velocidade.

Desenvolver em velocidades diferentes cansa mais os

desenvolvedores, fazendo-os ficarem estressados isso diminui a qualidade final do
produto, quebrando um dos principais valores dos Processos Ágeis.
i) Atenção contínua a excelência técnica e boa modelagem
aumentam a agilidade.
Alta qualidade é a chave para a agilidade. Para manter rápido o
desenvolvimento é necessário deixar o software o mais limpo e o mais robusto
possível. Isso porque os times de Processos Ágeis estão compromissados em
desenvolver códigos da melhor qualidade.
j) Simplicidade é essencial.
O caminho a ser escolhido para desenvolver e projetar é sempre o
caminho mais simples e consistente que leve ao resultado final esperado. A escolha
do caminho mais simples implica em dizer que caso alguma mudança ocorra – e
elas vão ocorrer – será mais fácil alterar o que já foi feito.
k) As melhores Arquiteturas, Requisitos e Projetos vêm de equipes
organizadas.
Decisões são tomadas por toda a equipe e não por apenas um
indivíduo. Isso caracteriza uma equipe organizada, pois todos trabalham juntos para
o sucesso do projeto.
Responsabilidades são compartilhadas pro todos os membros da
equipe, mostrando que todos estão envolvidos no processo de um projeto.
l) Em intervalos regulares a equipe debate como ela pode ser
melhorada e ajustada para melhores resultados.
Para uma equipe ágil melhorar é uma constante máxima. Sempre
são feitas reuniões com a equipe a fim de encontrar novos pontos onde o time pode
ser melhorado para satisfazer as necessidades atuais do meio, que está em
constante mudança. O meio está sempre mudando e para e equipe continuar ágil é
necessário que ela mude de acordo.
A seguir serão analisadas algumas características das principais
metodologias ágeis encontrada na literatura especializada.

3.5.1 Extreme Programming – XP

• XP é uma abordagem deliberada e disciplinada para desenvolvimento de

software.
• Criada por kent baeck em 1996 durante o projeto daimler-chrysler.
O sucesso de xp advém da intensa satisfação do cliente. Cliente
satisfeito é o melhor indicativo de sucesso de um projeto esta metodologia foi criada
para produzir o software que o cliente precisa quando ele é necessário.
XP encoraja os desenvolvedores a atender as requisições de
mudanças dos requisitos do software, no momento em isto acontece. Em XP alguns
princípios traduzem o espírito da metodologia e devem serem rigorosamente
seguidos e planejados.
• Simplicidade
• comunicação
• feedback
• coragem

Simplicidade
• Tentar sempre desenvolver a solução mais simples possível.
• Muitos projetos perdem muito tempo quando os desenvolvedores destinam
muito tempo desenvolvendo uma solução genérica.
• A solução deve responder simplesmente um requisito do usuário.
• Algumas funcionalidades podem nunca vir a serem utilizadas.
Comunicação
• Canal aberto de comunicação entre a equipe de desenvolvimento e com os
usuários.
• A comunicação é chave para o sucesso.

Feedback
 • Feedback possibilita que o software evolva
• “Pergunte ao software, não a um documento”
• Feedback precisa ser:
Cedo (pra gente descobrir logo se está fazendo a coisa correta)
Concreto (feedback oriundo do código)
Constante (o ciclo de desenvolvimento tem que ser curto)

Coragem

• Colocar o cliente a par do que ta acontecendo

• Acreditar na capacidade de responder a mudanças
• Aprender com os erros
• Acreditar no feedback (não na “teoria”)
• Jogar pra ganhar (não pra ter uma desculpa)
• Fazer o que precisa ser feito
• Jogar fora código ruim
O projeto é inciado em xp com o levantamento das "estórias dos
usuários". Cada estória é escrita pelo usuário e consiste de um ou alguns parágrafos
de um o propósito da estória não é definir toda a funcionalidade de um cenário, mas
sim, estimar como será a complexidade de parte do sistema em quanto tempo isso
será desenvolvido. Todos os demais detalhes da estória serão esclarecidos com o
cliente, imediatamente ao início do desenvolvimento.
O próximo passo é o planejamento do release, onde será definido
quais estórias deverão ser desenvolvidas em quais releases.
Cada release consiste de um número de iterações. Cada iteração
terá um conjunto de estórias implementadas. Em cada iteração,:
Planeje, para que você sempre faça a coisa mais importante ainda a fazer
Codifique, senão o software não sai
Teste, senão você não sabe se está funcionando
Refatore, senão o código vai ficar tão ruim que será impossível dar manutenção
Escute, para que você saiba qual é o problema a resolver o refatoramento e os
testes automáticos são atividades fundamentais em xp.

Refatoramento
 • Refatorar é melhorar o código sem alterar sua funcionalidade
• Antes de uma mudança, você refatora o código para que a mudança seja
simples de fazer
• Refatoração continua possibilita manter um design legal, mesmo com
mudanças freqüentes

Testes automáticos

• Testes automáticos são parte do software

• Se você tem somente a funcionalidade, seu software está incompleto
• Testes permitem que você refatore sem medo de quebrar o código
• Testes representam uma “redundância lógica” que você adiciona ao código
• Escrevendo testes antes da funcionalidade,
• Você clareia dúvidas sobre o que o software deve fazer, algumas práticas
importantes em XP:
 Projeto mais simples possível
 Programação em pares
 Propriedade coletiva do código
 Cliente sempre disponível
 Estórias do usuário
 Planejamento do release

Projeto mais simples possível

Projetos flexíveis são uma defesa contra mudanças imprevistas no

software porém, também têm custos, tempo para desenvolvimento e manutenção, o
código fica mais complexo, muitas vezes a flexibilidade não é utilizada nunca.
Como mudança é barata em XP, vamos manter o projeto mais
simples possível, modificando-o quando for necessário, suportar mais
funcionalidade, o melhor projeto é aquele que:
• Roda todos os testes
• Não contém duplicação de funcionalidade
• Deixa claro as decisões de design importantes
• Ter o menor número possível de classes e métodos
• O melhor projeto não é aquele: mais flexível (com mais “ganchos”), mais
abstrato, que resistirá ao tempo

Programação em pares
• Se a revisão de código é legal, vamos fazê-la o tempo todo
 • Em XP, programação é feita em pares, pares mudam com relativa rapidez
(em dias)
• Programação em pares favorece comunicação e aprendizado
• Mas, você precisa estabelecer um padrão de codificação
• Há casos de redução no tempo de desenvolvimento com programação em
pares

Propriedade coletiva do código

• Desenvolvimento com objetos leva a alterações por todo o código

• Coordenar alterações toma tempo e gera resistências no “dono” do código
• Em XP, "não se coordena", simplesmente faz-se o que precisa ser feito, mas
integra-se freqüentemente, no máximo, uma vez por dia
• Todos são responsáveis por todo o código
• Qualquer um que vê uma oportunidade de adicionar valor ao código, devo
fazê-lo mantendo em vista as prioridades do cliente, mantendo o design mais
simples possível
• Testes protegem a funcionalidade padrão de codificação evita a “guerra dos
parênteses”

Cliente sempre disponível

• Um cliente (usuário da aplicação) deve trabalhar com o time para esclarecer
dúvidas e estabelecer pequenas prioridades, é muito caro colocar um cliente
a disposição do desenvolvimento?
• Talvez então não valha a pena fazer o sistema...

Estórias do usuário

• Usuários escrevem estórias descrevendo a funcionalidade que querem

desenvolvedores estimam o tempo necessário para implementar cada estória
• Um release é um conjunto de estórias que são disponibilizados
simultaneamente
• As estórias mais importantes e/ou mais difíceis tem prioridade
Planejamento do release
• XP preconiza releases pequenos e freqüentes (a cada 2-3 meses)
• As quatro dimensões do desenvolvimento de software são custo, tempo,
qualidade e escopo
• XP tenta manter escopo como variável livre
• Releases são divididas em iterações de 2-3 semanas
• O cliente decide: os programadores decidem, escopo, prioridade, composição
do release, data do release, estimativas, conseqüências, processo,
planejamento intra release (o mais arriscado primeiro)
• Uma iteração alcança algum objetivo (tipicamente a adição de nova
funcionalidade)
• Nada é feito que não seja imediatamente útil e necessário para não impactar
os prazos de desenvolvimento problemas em XP
• Considerar testes como parte normal do processo de desenvolvimento
• Sempre fazer a coisa mais simples
• Admitir que você não sabe
• Colaborar
• Vencer resistência nas pessoas
• Times grandes
• Situações em que você não pode mudar livremente o código

3.5.2 Feature driven development – FDD

Feature driven development é uma metodologia ágil criada por Jeff

de Luca e Peter Code. foi reconhecida em 1997. FDD possui requisitos mais formais
e mais passos que XP, além de possuir um mecanismo mais preciso para
acompanhamento do projeto. O desenvolvimento baseado em FDD consiste de dois
estágios principais:
• Descobrir uma lista de "features" a serem
• Implementação baseada em "features".
Descobrir a lista de "features" é sem dúvida o processo mais crítico.
é a chave para o sucesso do projeto!
 A qualidade com a qual se identifica a lista de "features" define quão
preciso o projeto será controlado, quão extensível e manutenibilidade o código terá.
Requer participação integral do cliente junto à equipe de
desenvolvimento. Como a identificação da lista de "features" deriva-se um diagrama
de classes de análise.
As responsabilidades das classes devem expressar um linguajar
comum entre desenvolvedores e usuários. Por exemplo: imaginem um sistema de
compras on-line onde o cliente loga no sistema para comprar algo.
O diagrama de classes deve conter classes como: carrinho de
compras, cliente e item.
O resultado da lista de "features" deve incluir:
• Criar um novo carrinho de compras para o cliente;
• Adicionar um novo item no carrinho de compras;
• Listar todos itens do carrinho de compras;
• Calcular o preço total dos itens do carrinho de compras.
A lista de "features" deve representar algo para o usuário, refletindo
diretamente a funcionalidade que será disponibilizada na aplicação, também deve
conter unidades de trabalho para os desenvolvedores, onde toda "feature" é
pequena o suficiente para que o seu desenvolvimento seja feito em pequenas
iterações.
A implementação começa através do agrupamento de um conjunto
de "features" relacionadas em um pacote de trabalho.
Um pacote de trabalho deve ser completamente desenvolvido em
uma iteração, normalmente de 1 a 3 semanas, desenvolvido deve apresentar uma
parte do software onde o usuário pode utilizá-lo. Cada iteração inclui:
• Kick-off meeting para um pacote detrabalho: detalhes das "features" incluídas
devem ser esclarecidos.
• Projeto: classes/métodos e documentação necessárias são criadas.
• Revisão de projeto: um projetista experiente avalia o projeto feito, analisando-
o ou rejeitando-o.
• Desenvolvimento: implementação e testes de unidade são criados.
• Revisão de código: é uma espécie de programação em pares.
• Fechamento do release: as "features" desenvolvidas são liberadas em um
build.
O FDD possui 5 principais processos:

3.5.2.1 SCRUM
 Scrum é um processo para construir software incrementalmente em
ambientes complexos, onde os requisitos não são claros ou mudam com muita
freqüência.
O objetivo do scrum é fornecer um processo conveniente para
projetos e desenvolvimento orientado a objetos.
A metodologia é baseada em princípios semelhantes aos de XP:
equipes pequenas, requisitos pouco estáveis ou desconhecidos, e iterações curtas
para promover visibilidade para o desenvolvimento.
Scrum divide o desenvolvimento em sprints de 30 dias. equipes
pequenas, de até 7 pessoas, são formadas por projetistas, programadores,
engenheiros e gerentes de qualidade. As equipes trabalham em cima de
funcionalidade (os requisitos, em outras palavras) definidas no início de cada sprint.
A equipe toda é responsável pelo desenvolvimento desta funcionalidade.Todo dia, é
feita uma reunião de 15 minutos onde o time expões à gerência o que será feito no
próximo dia, e nestas reuniões os gerentes podem levantar os fatores de
impedimento, e o progresso geral do desenvolvimento.
Todos respondem às perguntas:
• O que você realizou desde a última reunião?
• Quais problemas você enfrentou?
• Em que você trabalhará até a próxima reunião?

Algumas conclusões sobre xp, fdd e scrum

As três são metodologias que utilizam o modelo iterativo para evitar

os principais "gargalos" do modelo em cascata; as três são metodologias ágeis, mas
o XP é considerado muito mais "leve" porque não produz muitos artefatos; XP é
melhor para projetos que possuem mudanças frequentes ou "pobre" levantamento
de requisitos.
A escalabilidade do FDD é melhor. existe uma hierarquia de
processos que permite iterações tanto com equipes pequenas quanto grandes, FDD
oferece um melhor acompanhamento gerencial do projeto.
As três necessitam de disciplina, o que não exclui a necessidade de
um bom gerente de projetos.
 Scrum fornece um mecanismo de informação de status que é
atualizado continuamente.
Scrum e XP são complementares, pois Scrum provê práticas ágeis
de gerenciamento enquanto XP está mais preocupado com a produção de código.
As três oferecem técnicas bastante úteis e que podem ser aplicadas
em outras metodologias.

Algumas outras metodologias ágeis:

• Crystal/clear
• Dynamic systems development method (dsdm)
• Adaptive software development (asd)

Conclusão
 O desafio futuro das metodologias ágeis é encontrar maneiras de
eliminar alguns de seus pontos fracos, como a falta de análise de riscos, sem torná-
las metodologias pesadas. Na XP não existe a preocupação formal em fazer a
análise e o planejamento de riscos. Como riscos acontecem normalmente em
projetos de desenvolvimento de software, este é um ponto negativo da XP. Deve-se,
portanto, procurar implementar uma estratégia de gestão de riscos sem tornar a
metodologia muito complexa. Outro desafio é como usar essas metodologias ágeis
em grandes empresas e equipes, uma vez que normalmente essas metodologias
são baseadas em equipes pequenas. Neste caso, pelo menos é necessário resolver
os problemas de comunicação internos na equipe, uma vez que é comum em
grandes empresas os funcionários estarem separados geograficamente.
Apesar do interesse crescente no uso das metodologias ágeis, ainda
faltam casos de sucesso de seu uso em projetos grandes e críticos. Quanto mais
organizações usem as metodologias ágeis, melhores serão os resultados empíricos
em termos de vantagens, desvantagens, riscos e procedimentos para sua adoção
nas organizações.
Mesmo assim, os resultados iniciais em termos de qualidade,
confiança, datas de entrega e custo são promissores.
Como a Web é um ambiente de desenvolvimento dinâmico e com
mudanças constantes, as metodologias tradicionais orientadas a documentação são
menos adequadas que as metodologias ágeis. Uma idéia a ser implantada
futuramente neste projeto de pesquisa é a integração da XP com outras
metodologias ágeis, como a Scrum. Neste caso, os aspectos de planejamento e
gerenciamento de projeto da Scrum serão integrados com as práticas da XP.

REFERENCIAS:
- PRESSMAN, ROGER S., Engenharia de Software- (6 Edição), São Paulo, Ed.
McGrawhill, 2006.
- pt.wikipedia.org/.../Desenvolvimento_ágil_de_software – Acesso em 18/10/2010
- SOMMERVILLE, IAN.,
- PERINI, LUIS CLAUDIO - HISATOMI, MARCO IKURO – BERTO, WAGNER LUIZ.
Engenharia de Software - Livros didáticos - Unopar Virtual.
- improveit.com.br/xp/manifesto_agil – Acesso em 15/10/2010
- www.cci.unama.br/margalho/portaltcc/.../oscar.PDF