SCIENTIA PLENA VOL. 5, NUM.

12 2009
www.scientiaplena.org.br
121301-1
Uma anlise das Metodologias geis FDD e Scrum sob a
Perspectiva do Modelo de Qualidade MPS.BR
F. G. Silva; S. C. P. Hoentsch, L. Silva
Departamento de Computao, Universidade Federal de Sergipe, So Cristvo SE, 49000-100, Brasil
{nandagomes.si, sandracostah}@hotmail.com, leila@ufs.br

(Recebido em 14 de setembro de 2009; aceito em 13 de dezembro de 2009)
Este trabalho analisa a viabilidade do emprego das metodologias geis FDD e Scrum para se atingir os
nveis de maturidade do MPS.BR. Todos os nveis do MPS.BR so investigados, tomando-se por base os
resultados esperados dos processos que compe cada nvel. O resultado sumarizado desta anlise aqui
discutido, permitindo-se constatar a parcial aderncia das metodologias ao modelo.
Palavras-chave: MPS.BR, metodologia gil, FDD, Scrum.

This paper analyses the viability of adepting the agile methodologies FDD and Scrum to achieve the
maturity levels of the MPS.BR quality model. All levels of MPS.BR are investigated, based on the
expected results of the processes that compose each level. The summary of this analysis is here discussed,
showing the partial adherence of the metodologies to the model.
Keywords: MPS.BR, agile methodologie, FDD, Scrum.
1. INTRODUO
O software faz parte do cotidiano das pessoas, podendo ser encontrado em hospitais, escolas,
atividades de lazer e de segurana, entre outros. No entanto, a produo de software ainda
enfrenta uma srie de desafios como reduo de custos, cumprimento de prazos e alta obteno
de qualidade do produto final.
A necessidade de se introduzir qualidade no processo de produo de software levou ao
estabelecimento de normas e modelos de qualidade que so guias para aumentar, medir e
garantir a qualidade de software. Dentre estes destacam-se as normas da srie ISO 9000, as
normas ISO/IEC 12207 e 15504, os modelos CMM Capability Maturity Model e CMMI -
Capability Maturity Model Integration [Koscianski e Soares, 2007].
Em 2003 foi lanado no Brasil o modelo de qualidade MPS.BR - Melhoria do Processo de
Software Brasileiro [MPS.BR, 2007a], visando atender a necessidade de guiar a implantao de
prticas recomendadas da Engenharia de Software no contexto das empresas de software
brasileiras, especialmente as de porte pequeno e mdio. O modelo est em consonncia com as
principais abordagens internacionais para definio, avaliao e melhoria de processos de
software. No entanto o modelo, como os demais, expressa apenas o que fazer para se atingir a
qualidade, mas no estabelece como fazer para alcan-la, fornecendo assim empresa um
grau de liberdade na escolha do processo de desenvolvimento a adotar.
Metodologias e processos de desenvolvimento de software descrevem como atingir o que foi
estabelecido nos modelos de qualidade, definindo guias para as atividades a serem realizadas,
critrios para monitorar e medir as atividades e produtos do projeto e definindo ainda, quais e
quando os artefatos devem ser desenvolvidos, dentre outros aspectos. Diversas abordagens
foram propostas, sendo atualmente RUP Rational Unified Process [J acobson et al, 1999] o
processo mais difundo.
Recentemente, um conjunto de novas metodologias, conhecidas como Metodologias geis,
foram propostas. Dentre elas destacam-se XP eXtreme Programming [Beck e Andres, 2005],
Crystal [Cockburn, 2004], FDD Feature Driven Development [Palmer e Felsing, 2002] e
Scrum [Schwaber e Beedle, 2002]. Estas metodologias incluem quatro valores principais:
interaes e indivduos so mais importantes que processos e ferramentas; o software
funcionando mais relevante que a documentao compreensiva; o cliente deve estar sempre
presente durante o projeto e a metodologia deve prover agilidade na resposta a mudanas.
F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 2
Dado que as metodologias geis no so orientadas documentao, surge o questionamento
sobre a adequao do uso de metodologias geis no processo de implantao de um modelo de
qualidade. Alguns trabalhos j avaliaram parcialmente esta questo. Por exemplo, Santana et al
(2006) investigaram a adequao de XP para a implantao dos nveis G e F do MPS.BR. Vilain
e Zanatta (2006) fizeram uma anlise da metodologia gil Scrum em relao s reas de
processo Gerenciamento de Requisitos e Desenvolvimento de Requisitos do modelo CMMI. J
o trabalho de Campelo (2003) apresenta um guia de utilizao do CMM com XP e verifica a
possibilidade da aderncia da metodologia XP ao CMM nvel 2. Entretanto, as autoras
desconhecem trabalhos similares envolvendo o MPS.BR e as metodologias FDD e Scrum.
Nessa direo, este trabalho visa analisar a viabilidade de utilizao das metodologias geis
FDD e Scrum por empresas que desejem implantar o modelo de qualidade MPS.BR, fornecendo
assim um guia para estas empresas. O estudo realizado inova tambm por realizar uma anlise
exaustiva dos resultados esperados dos processos que compem todos os nveis do MPS.BR.
Este artigo est organizado como descrito a seguir. As metodologias FDD e Scrum e o
MPS.BR so brevemente introduzidos nas sees 2, 3 e 4, respectivamente. Em seguida, na
Seo 5, detalhado o estudo de adequao realizado para os processos do MPS.BR, em cada
um dos nveis de maturidade. Por fim, as concluses e trabalhos futuros so discutidos na Seo
6.
2. A METODOLOGIA GIL FDD (FEATURE-DRIVEN DEVELOPMENT)
Feature-Driven Development (FDD) uma metodologia de desenvolvimento de software que
inclui alguns benefcios de processos rigorosos, como modelagem, planejamento prvio e
controle do projeto, assim como contm caractersticas de processos geis, como foco na
programao, interao constante com o cliente e entrega freqente de verso do produto. Prev
prticas apenas para o desenvolvimento de software em si no se preocupando com outros
fatores como a escolha de tecnologias e ferramentas, a definio de procedimentos de aquisio,
dentre outros.
Embora no seja to orientada documentao quanto o RUP, em FDD relatrios que
controlam o estado e o progresso das atividades so previstos. Os artefatos principais so o
plano de projeto, a lista de funcionalidades e o diagrama de seqncia. O plano de projeto o
documento principal de sada a ser aprovado pelo cliente, nele est definido o escopo, a lista de
funcionalidades, os riscos, as mtircas para controle do projeto, os critrios de aceitao, dentre
outras informaes pertencentes ao domnio da aplicao. A lista de funcionalidades usada
para planejar, dirigir, rastrear e reportar o progresso do projeto e est organizada
hierarquicamente com requisitos funcionais. O diagrama de seqncia serve para mostrar os
participantes de uma interao e a seqncia das mensagens trocadas entre eles [Blaha e
Rumbaugh, 2006].
So cinco os processos da metodologia gil FDD: Desenvolver um Modelo Abrangente,
Construir uma Lista de Funcionalidades, Planejar Atravs de Funcionalidades, Projetar Atravs
de Funcionalidades e Construir Atravs de Funcionalidades. O processo Desenvolver um
Modelo Abrangente responsvel pelo estudo detalhado sobre o domnio do negcio e pela
definio do escopo do projeto. Segue-se o Construir uma Lista de Funcionalidades, onde todas
as funcionalidades necessrias ao cumprimento das necessidades do cliente so levantadas. Os
itens desta lista so ordenados por prioridade de desenvolvimento no processo Planejar atravs
de Funcionalidades, considerando inclusive se a funcionalidade funcional ou no. Ao final
deste processo gerada uma lista das classes e estas so associadas aos desenvolvedores
responsveis. Um plano de projeto elaborado pelo arquiteto chefe e aprovado pelo cliente.
Inicia-se ento vrias iteraes que compreende os dois processos finais. No processo Projetar
atravs de Funcionalidades, para cada funcionalidade da lista definida uma atividade a ser
realizada. Neste processo o modelo da interface do usurio esboado e os diagramas de
seqncia e de classe so gerados. J no processo Construir atravs de Funcionalidades o cdigo
gerado, produzindo-se a cada iterao, para cada funcionalidade definida, uma funo que
agregue valor ao cliente, este chamado de dono do produto.
F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 3
3. A METODOLOGIA GIL SCRUM
O Scrum uma metodologia gil que tem por objetivo gerenciar os processos de
desenvolvimento de software. O scrum focado nas pessoas e indicados para ambientes em que
os requisitos surgem e mudam rapidamente.
O Scrum prev alguns artefatos, sendo os principais: Product Backlog e Sprint Backlog. O
Product Backlog o documento mutvel definido pelo cliente no incio do projeto, onde esto
contidas suas caractersitcas esperadas em forma de lista ordenada por prioridade. O Sprint
Backlog um documento gerado na reunio de planejamento (sprint planning) com a diviso do
product backlog em pedaos de cdigo para serem implementados.
Os processos do Scrum se dividem em vrias iteraes chamadas de sprint. O processo
iterativo tem o objetivo de minimizar riscos, oferecendo aos usurios uma rpida avaliao do
que est sendo construdo. estabelecido um tempo fixo, geralmente de trinta dias, onde o time
deve trabalhar para atingir o objetivo especificado para a iterao. Ao trmino do perodo, o
time apresenta o que foi desenvolvido.
No primeiro dia do sprint feita a reunio de planejamento do sprint (sprint planning). No
primeiro planejamento o lder do processo, chamado de scrum mster, se rene com o cliente
para definir o product backlog, ou lista de funcionalidades. Nessa reunio, a equipe deve definir
quanto trabalho ser necessrio para cada tarefa baseado no tamanho do grupo e ento
decidido que trabalho ser realizado no sprint. Durante todos os dias do sprint so realizadas
reunies dirias (daily scrum) de quinze minutos para se avaliar o que foi feito no dia anterior,
no dia atual e quais foram os impedimentos encontrados.
No ltimo dia do sprint, feita uma reunio com o cliente que poder dar novo
direcionamento ao projeto. Essa reunio chamada de reunio de reviso (sprint review).
Posteriormente reunio de reviso feita uma reunio de retrospectiva (sprint retrospective),
onde ser avaliado o que foi aprendido e os ajustes necessrios ao projeto, objetivando a
melhoria contnua. Iniciado a prxima iterao, comea-se um novo planejamento, e assim
segue-se sucessivamente. Para o Scrum, uma tarefa s considerada pronta se tiver o potencial
de entrar em produo assim que o cliente decidir. Ao trmino de cada iterao, a equipe deve
apresentar ao cliente algo realmente funcional e no somente documentos.
4. O MODELO DE QUALIDADE MPS.BR
O MPS.BR um modelo de qualidade voltado para o perfil das empresas brasileiras e est
dividido em trs componentes: Modelo de Referncia (MR-MPS), Mtodo de Avaliao (MA-
MPS) e Modelo de Negcio (MN-MPS). O documento relevante para este trabalho o Modelo
de Referncia, onde so encontrados documentos em forma de trs guias, os quais esto
baseados no conceito de maturidade e capacidade dos processos para avaliao e melhoria da
qualidade dos processos e produtos/servios de software. O Guia Geral fornece informaes
gerais e o detalhamento dos componentes e definies necessrios para aplicao do MPS.BR
em uma empresa. O Guia de Aquisio compreende as recomendaes para empresas que
querem adquirir um produto/servio de software. J o Guia de Implementao descreve como
implementar os sete nveis de maturidade do MR-MPS, a saber, G (Parcialmente Gerenciado), F
(Gerenciado), E (Parcialmente Definido), D (Largamente Definido), C (Definido), B
(Gerenciado Quantitativamente) e A (Em Otimizao).
Os nveis de maturidade so composto por processos. Cada processo definido de forma a
atender aos propsitos previamente definidos e aos atributos estabelecidos. O processo
considerado satisfeito se todos os resultados esperados para este forem atendidos. Considera-se
que uma empresa atinge um dado nvel de maturidade Ni, se esta satisfaz todos os processos dos
nveis j, j=G, F, ..., i. Na seo a seguir descrevemos o objetivo de cada processo, juntamente
com os resultados esperados, ao mesmo tempo em que a anlise de adequao do Scrum e FDD
delineada.
F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 4
5. ANLISE DA FDD E DO SCRUM SOB A PERSPECTIVA MPS.BR
A adequao das metodologias FDD e Scrum ao cumprimento dos preceitos do MPS.BR
medida atravs de anlise dos resultados esperados de cada processo, detalhado no Guia de
Implementao [MPS.BR, 2007b]. Na realidade, ser observado se as metodologias em estudo
possuem prticas que garantam o alcance destes resultados esperados. Ao todo, 162 resultados
esperados foram analisados. No entanto, por razo de conciso, aqui omitiremos a descrio de
alguns deles.
5.1 Nvel G Processo Gerncia de Projetos (GPR)
O propsito do processo Gerncia de Projetos estabelecer e manter planos que definem as
atividades, recursos e responsabilidades do projeto, bem como prover informaes sobre o
andamento do projeto que permitam a realizao de correes quando houver desvios
significativos no desempenho do projeto.
O processo Gerncia de Projetos possui os seguintes resultados esperados: GPR1 - O escopo
do trabalho para o projeto definido; GPR2 - As tarefas e os produtos de trabalho do projeto so
dimensionados utilizando mtodos apropriados; GPR3 - O modelo e as fases do ciclo de vida do
projeto so definidos; GPR4 (At o nvel F) - O esforo e o custo para a execuo das tarefas e
dos produtos de trabalho so estimados com base em dados histricos ou referncias tcnicas;
GPR5 - O oramento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, so
estabelecidos e mantidos; GPR6 - Os riscos do projeto so identificados e o seu impacto,
probabilidade de ocorrncia e prioridade de tratamento so determinados e documentados;
GPR7 - Os recursos humanos para o projeto so planejados considerando o perfil e o
conhecimento necessrios para execut-lo; GPR8 - As tarefas, os recursos e o ambiente de
trabalho necessrios para executar o projeto so planejados; GPR9 - Os dados relevantes do
projeto so identificados e planejados quanto forma de coleta, armazenamento e distribuio.
Um mecanismo estabelecido para acess-los, incluindo, se pertinente, questes de privacidade
e segurana; GPR10 (At o nvel F) - Planos para a execuo do projeto so estabelecidos e
reunidos no Plano do Projeto; GPR11 - A viabilidade de atingir as metas do projeto,
considerando as restries e os recursos disponveis, avaliada. Se necessrio, ajustes so
realizados; GPR12 - O Plano do Projeto revisado com todos os interessados e o compromisso
com ele obtido; GPR13 (At o nvel F) - O progresso do projeto monitorado com relao ao
estabelecido no Plano do Projeto e os resultados so documentados; GPR14 - O envolvimento
das partes interessadas no projeto gerenciado; GPR15 - Revises so realizadas em marcos do
projeto e conforme estabelecido no planejamento; GPR16 - Registros de problemas
identificados e o resultado da anlise de questes pertinentes, incluindo dependncias crticas,
so estabelecidos e tratados com as partes interessadas; GPR17 - Aes para corrigir desvios em
relao ao planejado e para prevenir a repetio dos problemas identificados so estabelecidas,
implementadas e acompanhadas at a sua concluso.
Considerando-se os resultados GPR1 e GPR2, na FDD o escopo do trabalho documentado
atravs da lista de funcionalidades, a qual decomposta em classes para serem mais facilmente
gerenciveis e possveis de serem dimensionado. No Scrum apenas os requisitos conhecidos so
listados e agrupados originando o product backlog, o qual decomposto em tarefas dirias. Em
relao ao GPR3, na FDD e no Scrum existem as fases do ciclo de vida parcialmente definidas.
No ficam bem claros os procedimentos a serem realizado aps a entrega final do sistema ao
cliente. Referente ao GPR4 ao GPR6, na FDD o esforo, o oramento e o cronograma so
estimados a partir da diviso da lista de funcionalidades em classes que sero implementadas.
Os riscos preliminares so identificados e documentados antes do incio do projeto. J no Scrum
a equipe quem estima o esforo e o oramento decidindo qual tarefa do product backlog ser
realizada. A definio do oramento e cronograma ocorre na reunio de planejamento e a
avaliao ocorre nas reunies dirias. Os riscos so identificados no decorrer do
desenvolvimento do projeto, so tratados, mas no so documentados. Em relao a GPR7 a
GPR11, tanto na FDD quanto no Scrum o trabalho dividido em vrias equipes com papis e
responsabilidades bem definidos. Na FDD tudo que se refere a planejamento ocorre antes de
iniciar o projeto e no Scrum realizado na reunio de planejamento. Quanto ao atendimento do
F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 5
GPR13 ao GPR17, na FDD monitoramento e acompanhamento do projeto ocorrem durante as
iteraes. Os problemas so identificados e corrigidos durante a inspeo e os testes do cdigo.
No Scrum so identificados e registrados nas reunies dirias e corrigidos posteriormente com
os envolvidos no processo. Assim, dos dezessete resultados esperados percebemos que a FDD
no atende ao resultado GPR3 e o Scrum no atende aos resultados GPR3 e GPR6.
5.2 Nvel G Processo Gerncia de Requisitos (GRE)
O propsito do processo Gerncia de Requisitos gerenciar os requisitos dos produtos e
componentes do produto do projeto e identificar inconsistncias entre os requisitos, os planos do
projeto e os produtos de trabalho do projeto.
O processo Gerncia de Requisitos possui os seguintes resultados esperados: GRE1 - O
entendimento dos requisitos obtido junto aos fornecedores de requisitos; GRE2 - Os requisitos
de software so aprovados utilizando critrios objetivos; GRE3 - A rastreabilidade bidirecional
entre os requisitos e os produtos de trabalho estabelecida e mantida; GRE4 - Revises em
planos e produtos de trabalho do projeto so realizadas visando identificar e corrigir
inconsistncias em relao aos requisitos; GRE5 - Mudanas nos requisitos so gerenciadas ao
longo do projeto.
Na FDD realizado o levantamento dos requisitos e armazenado na lista de funcionalidades.
Os requisitos que compe o plano de projeto aprovado pelo cliente. A rastreabilidade ocorre
atravs do desenvolvimento e implementao da lista de funcionalidades e uso dos diagramas de
seqncia. As revises no plano do projeto so realizadas durante o desenvolvimento e
refinamento do modelo de objetos. As mudanas nos requisitos so gerenciadas atravs do
controle das verses. No Scrum o scrum master realiza o levantamento dos requisitos
juntamente com o cliente e armazena no product backlog. O cliente define e aprova o product
backlog. No definido nenhum mecanismo de rastreabilidade entre requisitos e produtos de
trabalho. As mudanas nos requisitos so acrescentadas ao product backlog na reunio de
reviso mas no so gerenciadas. Assim, dos cinco resultados esperados percebemos que a FDD
atende a todos os resultados e o Scrum no atende aos resultados GRE3 e GRE5.
5.3 Nvel F Processo Aquisio (AQU)
O propsito do processo Aquisio gerenciar a aquisio de produtos e/ou servios que
satisfaam a necessidade expressa pelo adquirente. O processo Gerncia de Aquisio possui
nove resultados esperados aqui no detalhados. Como o foco da FDD e Scrum com o processo
de desenvolvimento e gerenciamento, este processo no satisfeito por nenhuma das duas
metodologias. Sobre este processo a FDD apenas define a aquisio de um produto durante o
levantamento dos requisitos e documenta na lista de funcionalidades. J no Scrum a aquisio
pode ser documentada no product backlog.
5.4 Nvel F Processo Gerncia de Configurao (GCO)
O propsito do processo de Gerncia de Configurao estabelecer e manter a integridade de
todos os produtos de trabalho de um processo ou projeto e disponibiliz-los a todos os
envolvidos.
So resultados esperados deste processo: GCO1 - Um Sistema de Gerncia de Configurao
estabelecido e mantido; GCO2 - Os itens de configurao so identificados; GCO3 - Os itens de
configurao sujeitos a um controle formal so colocados sob baseline; GCO4 - A situao dos
itens de configurao e das baselines registrada ao longo do tempo e disponibilizada; GCO5 -
Modificaes em itens de configurao so controladas e disponibilizadas; GCO6 - Auditorias
de configurao so realizadas objetivamente para assegurar que as baselines e os itens de
configurao estejam ntegros, completos e consistentes; GCO7 - O armazenamento, o
manuseio e a liberao de itens de configurao e baselines so controlados.
Considerando os resultados GCO1 ao GCO5, na FDD realizado o gerenciamento de
configuraes durante o controle de verses do projeto de software. No Scrum as configuraes
so encontradas nas especificaes do product backlog e so gerenciadas em diferentes etapas
do projeto. Em relao aos resultados GCO6, nem a FDD nem o Scrum se preocupam com
F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 6
auditoria de configurao. Sobre o resultado GCO7, na FDD os itens de configurao so
armazenados e controlados na lista de funcionalidades e no Scrum so armazenados e
gerenciados no product backlog. Assim, dos sete resultados esperados percebemos que a FDD e
o Scrum no atendem ao resultado GCO6.
5.5 Nvel F Processo Garantia da Qualidade (GQA)
O propsito do processo Garantia da Qualidade assegurar que os produtos de trabalho e a
execuo dos processos esto em conformidade com os planos e recursos predefinidos.
Este processo compreende os resultados esperados: GQA1 - A aderncia dos produtos de
trabalho aos padres, procedimentos e requisitos aplicveis avaliada objetivamente, antes dos
produtos serem entregues ao cliente e em marcos predefinidos ao longo do ciclo de vida do
projeto; GQA2 - A aderncia dos processos executados s descries de processo, padres e
procedimentos avaliada objetivamente; GQA3 - Os problemas e as no-conformidades so
identificados, registrados e comunicados; GQA4 - Aes corretivas para no-conformidades so
estabelecidas e acompanhadas at as suas efetivas concluses. Quando necessrio, o
escalonamento das aes corretivas para nveis superiores realizado, de forma a garantir sua
soluo.
Na FDD as no-conformidades, os problemas e correes so identificados durante a
inspeo e os testes do cdigo e no Scrum ocorre nas reunies dirias e nas reunies de reviso.
Aps detectarem a falha, aes corretivas so tomadas e acompanhadas at a soluo do
problema. Nem a FDD nem o Scrum se preocupam com a avaliao da aderncia dos processos.
Assim, as duas metodologias no atendem apenas o resultado GQA2.
5.6 Nvel F Processo Medio (MED)
O propsito do processo Medio coletar, analisar e relatar os dados relativos aos produtos
desenvolvidos e aos processos implementados na organizao e em seus projetos, de forma a
apoiar os objetivos organizacionais.
So os resultados esperados deste processo: MED1 - Objetivos de medio so estabelecidos
e mantidos a partir dos objetivos da organizao e das necessidades de informao de processos
tcnicos e gerenciais; MED2 - Um conjunto adequado de medidas, orientado pelos objetivos de
medio, identificado e/ou definido, priorizado, documentado, revisado e atualizado; MED3 -
Os procedimentos para a coleta e o armazenamento de medidas so especificados; MED4 - Os
procedimentos para a anlise da medio realizada so especificados; MED5 - Os dados
requeridos so coletados e analisados; MED6 - Os dados e os resultados de anlises so
armazenados; MED7 - As informaes produzidas so usadas para apoiar decises e para
fornecer uma base objetiva para comunicao aos interessados.
Na FDD e no Scrum existe uma preocupao com a coleta e o armazenamento de dados para
serem usados como apoio deciso, mas no especificam os mtodos e ferramentas para a
anlise dos dados coletados para medio. Assim, dos sete resultados esperados tanto a FDD e
como o Scrum no atendem aos resultados MED1, MED2, MED3, MED4.
5.7 Nvel E Processo Avaliao e Melhoria do Processo
Organizacional (AMP)
O propsito do processo Avaliao e Melhoria do Processo Organizacional determinar o
quanto os processos padro da organizao contribuem para alcanar os objetivos de negcio da
organizao. O processo Avaliao e Melhoria do Processo Organizacional possui dez
resultados esperados aqui no detalhados. Apesar da FDD e do Scrum realizar procedimentos
que objetivam melhorar o processo de desenvolvimento de software, nenhuma das duas
metodologias define atividades que identifiquem as necessidades de melhoria, classifiquem,
acompanhem e avaliem a melhoria dos seus processos. Assim, no atendem a nenhum dos
resultados para este processo.
F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 7
5.8 Nvel E Processo Definio do Processo Organizacional (DFP)
O propsito do processo Definio do Processo Organizacional estabelecer e manter um
conjunto de ativos de processo organizacional e padres do ambiente de trabalho usveis e
aplicveis s necessidades de negcio da organizao.
Este processo possui os seguintes resultados esperados: DFP1 - Um conjunto definido de
processos padro estabelecido e mantido, juntamente com a indicao da aplicabilidade de
cada processo; DFP2 - Uma biblioteca de ativos de processo organizacional estabelecida e
mantida; DFP3 - Tarefas, atividades e produtos de trabalho associados aos processos padro so
identificados e detalhados, juntamente com as caractersticas de desempenho esperadas; DFP4 -
As descries dos modelos de ciclo de vida a serem utilizados nos projetos da organizao so
estabelecidas e mantidas; DFP5 - Uma estratgia para adaptao do processo padro para o
produto ou servio desenvolvida considerando as necessidades dos projetos; DFP6 - O
repositrio de medidas da organizao estabelecido e mantido; DFP7 - Os ambientes padro
de trabalho da organizao so estabelecidos e mantidos.
Considerando-se os resultados DFP1 e DFP3, na FDD processos-padro so adotados nas
atividades desenvolvidas em todas as fases das cinco etapas da metodologia. A identificao e
detalhamento das tarefas, atividades e produtos de trabalho fazem parte da atividade de
construo da lista de funcionalidades. No Scrum, as prticas de reunies dirias, iteraes,
reunio de reviso, retrospectiva constituem-se processos-padro. A identificao e
detalhamento das tarefas feita no product backlog. Em relao ao resultado DFP4, sobre o
modelo de ciclo de vida, temos que no FDD o produto desenvolvido por funcionalidades e no
Scrum o desenvolvimento atravs de iteraes. Para os resultados DFP5 ao DFP7, na FDD o
time tem a liberdade de escolher, dentre os prioritrios, os itens que eles julguem possveis de
serem executados. No Scrum, pode ser observada a flexibilidade proporcionada pela
possibilidade de remanejar um item das tarefas dirias. Na FDD e no Scrum necessrio o
estabelecimento do time de trabalho, montagem da equipe, diviso das tarefas, definio do
local de reunio. Em nenhuma das duas metodologias estudadas foi encontrado relato referente
ao estabelecimento de biblioteca de ativos de processo organizacional, que proposto pelo
resultado DFP2, nem o estabelecimento de um repositrio de medidas da organizao, que
proposto pelo resultado DFP6. Assim, dos sete resultados esperados percebemos que a FDD o
Scrum no atendem aos resultados DFP2 e DFP6.
5.9 Nvel E Processo Gerncia de Recursos Humanos (GRH)
O propsito do processo Gerncia de Recursos Humanos prover a organizao e os projetos
com os recursos humanos necessrios e manter suas competncias consistentes com as
necessidades do negcio.
O processo Gerncia de Recursos Humanos possui os seguintes resultados esperados: GRH1
- Uma reviso das necessidades estratgicas da organizao e dos projetos conduzida para
identificar recursos, conhecimentos e habilidades requeridos e, de acordo com a necessidade,
desenvolv-los ou contrat-los; GRH2 - Indivduos com as habilidades e competncias
requeridas so identificados e recrutados; GRH3 - As necessidades de treinamento que so
responsabilidade da organizao so identificadas; GRH4 - Uma estratgia de treinamento
planejada e implementada com o objetivo de atender s necessidades de treinamento dos
projetos e da organizao; GRH5 - Os treinamentos identificados como sendo responsabilidade
da organizao so conduzidos e registrados; GRH6 - A efetividade do treinamento avaliada;
GRH7 - Critrios objetivos para avaliao do desempenho de grupos e indivduos so definidos
e monitorados para prover informaes sobre este desempenho e melhor-lo; GRH8 - Uma
estratgia apropriada de gerncia de conhecimento planejada, estabelecida e mantida para
compartilhar informaes na organizao; GRH9 - Uma rede de especialistas na organizao
estabelecida e um mecanismo de apoio troca de informaes entre os especialistas e os
projetos implementado; GRH10 - O conhecimento prontamente disponibilizado e
compartilhado na organizao.
Na FDD existe o rodzio para que todos os funcionrios entendam o funcionamento de todos
os processos. A equipe recebe tambm um treinamento sobre a viso geral da rea do domnio
F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 8
que deve ser apresentada pelo cliente e no Scrum no so encontrados relatos referentes a
definio e implantao de treinamentos, mas sim busca por funcionrios j capacitados. Nem
a FDD nem o Scrum se preocupam com o gerenciamento e acompanhamento da efetividade do
treinamento. Assim, dos dez resultados esperados percebemos que a metodologia gil FDD
atende a cinco resultados esperados (GRH1 a GRH5) e a metodologia gil Scrum atende apenas
ao resultado GRH2.
5.10 Nvel E Processo Gerncia de Reutilizao (GRU)
O propsito do processo de Gerncia de Reutilizao gerenciar o ciclo de vida dos ativos
reutilizveis. Este processo possui cinco resultados esperados que no sero detalhados. Nem a
FDD nem o Scrum se preocupam com o gerenciamento dos ativos reutilizveis, assim nenhum
resultado esperado desse processo satisfeito.
5.11 Nvel E Processo Gerncia de Projetos (GPR (evoluo))
Este processo uma evoluo do processo descrito na seo 5.1, incorporando alguns
resultados novos e modificando trs j existentes. Deve satisfazer aos seguintes resultados
esperados: GPR4 - O planejamento e as estimativas das atividades do projeto so feitos
baseados no repositrio de estimativas e no conjunto de ativos de processo organizacional;
GPR10 - Um plano geral para a execuo do projeto estabelecido com a integrao de planos
especficos; GPR13 - O projeto gerenciado utilizando-se o Plano do Projeto e outros planos
que afetam o projeto. Os resultados so documentados; GPR18 - Um processo definido para o
projeto estabelecido de acordo com a estratgia para adaptao do processo da organizao;
GPR19 - Produtos de trabalho, medidas e experincias documentadas contribuem para os ativos
de processo organizacional
Na FDD e no Scrum o planejamento e as estimativas das atividades do projeto so realizados
durante a definio do escopo, mas nenhum dos dois contempla repositrio de estimativas.
Somente na FDD definido o plano de projeto, o qual utilizado no processo de gerenciamento
do projeto. No Scrum o planejamento estabelecido no product backlog, na medida em que
abrange as atividades necessrias para o desenvolvimento do produto, desde os seus requisitos
at sua entrega final. Assim, dos cinco resultados esperados a FDD atende a trs destes (GPR10,
GPR13, GPR18) e o Scrum atende somente ao resultado GPR18.
5.12 Nvel D Processo Desenvolvimento de Requisitos (DRE)
O propsito do processo Desenvolvimento de Requisitos estabelecer os requisitos dos
componentes do produto e do cliente.
Este processo possui os seguintes resultados esperados: DRE1 - As necessidades,
expectativas e restries do cliente, tanto do produto, quanto de suas interfaces, so
identificadas; DRE2 - Um conjunto definido de requisitos do cliente especificado a partir das
necessidades, expectativas e restries identificadas; DRE3 - Um conjunto de requisitos
funcionais e no-funcionais, do produto e dos componentes do produto que descrevem a soluo
do problema a ser resolvido, definido e mantido a partir dos requisitos do cliente; DRE4 - Os
requisitos funcionais e no-funcionais de cada componente do produto so refinados, elaborados
e alocados; DRE5 - Interfaces internas e externas do produto e de cada componente do produto
so definidas; DRE6 - Conceitos operacionais e cenrios so desenvolvidos; DRE7 - Os
requisitos so analisados para assegurar que sejam necessrios, corretos, testveis e suficientes e
para balancear as necessidades dos interessados com as restries existentes; DRE8 - Os
requisitos so validados.
Na FDD a lista de funcionalidades descreve todos os requisitos, eventos e iteraes possveis
para o projeto. A verificao dos requisitos na FDD realizada pela prpria equipe de
desenvolvimento durante a implementao. As interfaces so especificadas e documentadas de
acordo com a arquitetura definida no plano de projeto. J no Scrum no product backlog que
est descrita toda a seqncia de requisitos e eventos possveis para o projeto. No existe a
preocupao com a definio da interface, na validao o prprio cliente define. Assim, dos oito
F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 9
resultados esperados percebemos que a metodologia gil FDD atende a todos os resultados e a
metodologia gil Scrum s no atende ao resultado DRE5.
5.13 Nvel D Processo Integrao do Produto (ITP)
O propsito do processo Integrao do Produto compor os componentes do produto,
produzindo um produto integrado consistente com o projeto, e demonstrar que os requisitos
funcionais e no-funcionais so satisfeitos para o ambiente alvo ou equivalente.
Este processo possui os seguintes resultados esperados: ITP1 - Uma estratgia de integrao,
consistente com o projeto e com os requisitos do produto, desenvolvida para os componentes
do produto; ITP2 - Um ambiente para integrao dos componentes do produto estabelecido e
mantido; ITP3 - A compatibilidade das interfaces internas e externas dos componentes do
produto assegurada; ITP4 - As definies, o projeto e as mudanas nas interfaces internas e
externas so gerenciados para o produto e os componentes do produto; ITP5 - Cada componente
do produto verificado, utilizando-se critrios definidos, para confirmar que estes esto prontos
para a integrao; ITP6 - Os componentes do produto so integrados, de acordo com a
seqncia determinada e seguindo os procedimentos e critrios para integrao; ITP7 - Os
componentes do produto integrados so avaliados e os resultados da integrao so registrados;
ITP8 - Uma estratgia de regresso desenvolvida e aplicada para uma nova verificao do
produto, caso ocorra uma mudana nos componentes do produto (incluindo requisitos, projeto e
cdigos associados); ITP9 - O produto e a documentao relacionada so preparados e
entregues ao cliente.
Na FDD ao trmino do desenvolvimento de cada funcionalidade gerada uma nova verso
para integr-las, onde so observadas as exigncias constantes nos resultados acima listados. As
medidas de regresso so feitas antes da entrega da nova verso do produto. No Scrum, a
funcionalidade que ser entregue ao cliente durante a reunio de reviso fica em evidncia
durante toda a iterao, no sendo necessrio definir nenhuma estratgia de regresso. Tanto a
FDD quanto o Scrum entregam o produto e a documentao referente utilizao de arquivos
necessrios para a instalao do software e transio para um ambiente de produo. Assim, dos
nove resultados esperados percebemos que a FDD atende a todos resultados e o Scrum s
atende ao resultado ITP9.
5.14 Nvel D Processo Projeto e Construo do Produto (PCP)
O propsito do processo Projeto e Construo do Produto projetar, desenvolver e
implementar solues para atender aos requisitos.
So resultados esperados deste processo: PCP1 - Alternativas de soluo e critrios de
seleo so desenvolvidos para atender aos requisitos definidos; PCP2 - Solues so
selecionadas para o produto ou componentes do produto, com base em cenrios definidos e em
critrios identificados; PCP3 - O produto ou componente do produto projetado e
documentado; PCP4 - As interfaces entre os componentes do produto so projetadas com base
em critrios predefinidos; PCP5 - Uma anlise dos componentes do produto conduzida para
decidir sobre sua construo, compra ou reutilizao; PCP6 - Os componentes do produto so
implementados e verificados de acordo com o projeto; PCP7 - A documentao identificada,
desenvolvida e disponibilizada de acordo com os padres identificados; PCP8 - A
documentao mantida de acordo com os critrios definidos.
Na FDD, antes de iniciar o projeto, feito todo o levantamento dos requisitos macros e dos
riscos preliminares, bem como realizada a anlise de mercado facilitando o desenvolvimento
de alternativas de soluo e critrios de seleo para o produto ou componentes do produto, bem
como toda documentao do projeto de desenvolvimento. No Scrum, os critrios predefinidos
para o sistema podem ser encontrados no product backlog, onde esto as funcionalidades
pretendidas e os componentes para o software. No existe a preocupao do Scrum com a
documentao do projeto de desenvolvimento, nem com o projeto de interface. Assim, dos oito
resultados esperados percebemos que a metodologia gil FDD atende a todos resultados e a
metodologia gil Scrum s atende a dois dos resultados (PCP3, PCP6).
F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 10
5.15 Nvel D Processo Validao (VAL)
O propsito do processo Validao confirmar que um produto ou componente do produto
atender a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido.
Este processo possui os seguintes resultados esperados: VAL1 - Produtos de trabalho a serem
validados so identificados; VAL2 - Uma estratgia de validao desenvolvida e
implementada, estabelecendo cronograma, participantes envolvidos, mtodos para validao e
qualquer material a ser utilizado na validao; VAL3 - Critrios e procedimentos para validao
dos produtos de trabalho a serem validados so identificados e um ambiente para validao
estabelecido; VAL4 - Atividades de validao so executadas para garantir que os produtos de
software estejam prontos para uso no ambiente operacional pretendido; VAL5 - Problemas so
identificados e registrados; VAL6 - Resultados de atividades de validao so analisados e
disponibilizados para as partes interessadas; VAL7 - Evidncias de que os produtos de software
desenvolvidos esto prontos para o uso pretendido so fornecidas;
Na FDD e no Scrum os envolvidos no projeto so os responsveis pelas atividades de
validao onde os testes de usabilidade so realizados e em seguida o produto aprovado pelo
cliente. Existe inclusive a identificao e registro dos problemas, bem como analise e
disponibilizao dos resultados da validao para a equipe. As evidncias de que o produto est
pronto fornecida ao cliente dentro de perodos pr-estabelecidos e com a participao da
equipe. Assim, dos sete resultados esperados percebemos que as duas metodologias atendem a
todos.
5.16 Nvel D Processo Verificao (VER)
O propsito do processo Verificao confirmar que cada servio e/ou produto de trabalho
do processo ou do projeto atende apropriadamente os requisitos especificados.
O processo Verificao possui os seguintes resultados esperados: VER1 - Produtos de
trabalho a serem verificados so identificados; VER2 - Uma estratgia de verificao
desenvolvida e implementada, estabelecendo cronograma, revisores envolvidos, mtodos para
verificao e qualquer material a ser utilizado na verificao; VER3 - Critrios e procedimentos
para verificao dos produtos de trabalho a serem verificados so identificados e um ambiente
para verificao estabelecido; VER4 - Atividades de verificao, incluindo testes e revises
por pares, so executadas; VER5 - Defeitos so identificados e registrados; VER6 - Resultados
de atividades de verificao so analisados e disponibilizados para as partes interessadas.
Tanto a FDD quanto o Scrum verificam as funcionalidades do produto atravs de teste que
so realizados pela equipe durante o desenvolvimento dentro do cronograma estabelecido. Os
resultados da verificao so analisados e disponibilizados para as equipes durante as reunies.
Assim, percebemos que a FDD e o Scrum atendem a todos os resultados.
5.17 Nvel C Processo Anlise de Deciso e Resoluo (ADR)
O propsito do processo Anlise de Deciso e Resoluo analisar possveis decises
usando um processo formal, com critrios estabelecidos, para avaliao das alternativas
identificadas.
O processo Anlise de Deciso e Resoluo possui sete resultados esperados que no sero
detalhados. No FDD e no Scrum as decises e resolues so tomadas durante as reunies, sem
a existncia de documentao formal nem de critrios definidos, os quais so exigidos por esse
processo. Assim, nem a FDD nem o Scrum atendem a nenhum dos resultado esperado por esse
processo.
5.18 Nvel C Processo Desenvolvimento para Reutilizao (DRU)
O propsito do processo Desenvolvimento para Reutilizao identificar oportunidades de
reutilizao sistemtica na organizao e, se possvel, estabelecer um programa de reutilizao
para desenvolver ativos a partir de engenharia de domnios de aplicao. O processo
Desenvolvimento para Reutilizao possui nove resultados esperados que no sero detalhados.
F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 11
Nem a FDD nem o Scrum tratam de tarefas de compra ou reuso de software, assim nenhum
resultado esperado desse processo satisfeito.
5.19 Nvel C Processo Gerncia de Riscos (GRI)
O propsito do processo Gerncia de Riscos identificar, analisar, tratar, monitorar e reduzir
continuamente os riscos em nvel organizacional e de projeto.
O processo Gerncia de Riscos possui os seguintes resultados esperados: GRI1 - O
escopo da gerncia de riscos determinado; GRI2 - As origens e as categorias de riscos so
determinadas, e os parmetros usados para analisar riscos, categoriz-los e controlar o esforo
da gerncia do risco so definidos; GRI3 - As estratgias apropriadas para a gerncia de riscos
so definidas e implementadas; GRI4 - Os riscos do projeto so identificados e documentados,
incluindo seu contexto, condies e possveis conseqncias para o projeto e as partes
interessadas; GRI5 - Os riscos so priorizados, estimados e classificados de acordo com as
categorias e os parmetros definidos; GRI6 - Planos para a mitigao de riscos so
desenvolvidos; GRI7 - Os riscos so analisados e a prioridade de aplicao dos recursos para o
monitoramento desses riscos determinada; GRI8 - As medies do risco so definidas,
aplicadas e avaliadas para determinar mudanas na situao do risco e no progresso das
atividades para seu tratamento; GRI9 - Aes apropriadas so executadas para corrigir ou evitar
o impacto do risco, baseadas na sua prioridade, probabilidade, conseqncia ou outros
parmetros definidos.
A FDD prev apenas a identificao dos riscos preliminares na preparao inicial
podendo assim prever e evitar ou corrigir os riscos. J no Scrum no existe essa preocupao
com a identificao e documentao dos riscos e das incertezas, pois eles so reduzidos devido
ao grande nmero de participao e iteratividade com o cliente. Assim, dos nove resultados
esperados percebemos que a metodologia gil FDD atende a trs (GRI3, GRI4, GRI9) e a
metodologia gil Scrum no atende a nenhum.
5.20 Nvel C Gerncia de Reutilizao (GRU (evoluo))
Este processo uma evoluo do processo da seo 5.10, acrescentando mais um resultado
esperado que no ser detalhado. Assim como na seo 5.10, nem a FDD nem o Scrum atendem
este resultado pois no foram encontradas definies sobre o gerenciamento estatstico, bases
histricas e nem repositrios de dados que possam apoiar e guardar os resultados da anlise de
processos, no atendendo ao nico requisito desse processo.
5.21 Nvel B Processo Gerncia de Projetos (GPR (evoluo))
Este processo uma evoluo do processo da seo 5.12, incluindo mais os sete resultados
esperados aqui no detalhados. Nem na FDD nem no Scrum foram encontradas definies sobre
o gerenciamento estatstico, bases histricas e repositrios de dados que possam apoiar e
guardar os resultados da anlise de processos. Portanto, estas metodologias geis no atendem
os resultados deste processo.
5.22 Nvel A Processo Anlise de Causas de Problemas e
Resoluo (ACP)
O propsito do processo Anlise de Causas de Problemas e Resoluo identificar causas de
defeitos e de outros problemas e tomar aes para prevenir suas ocorrncias no futuro. Este
processo possui cinco resultados esperados, aqui no detalhados. Na FDD e no Scrum existe
apenas o registro e a identificao do problema, mas no h a preocupao de aes preventivas.
As duas metodologias no atendem nenhum dos resultado esperado deste processo.

F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 12
0
10
20
30
40
50
60
70
80
90
Nvel G Nvel F Nvel E Nvel D Nvel C Nvel B Nvel A
FDD
SCRUM

Figura 1 Quantitativo dos resultados esperados atingidos nos nveis de maturidade do MPS.BR
6. CONCLUSES
Este trabalho apresentou um mapeamento entre as metodologias geis FDD e Scrum e o
modelo de qualidade MPS.BR. Foram analisados todos os processos dos nveis G ao A do
MPS.BR. Para cada processo foi observado se as metodologias em questo provem prticas
para atender os resultados esperados de cada processo. O trabalho analisou 162 resultados
esperados e neste sentido contribui para empresas que desejem implantar o MPS.BR, j que as
autoras desconhecem trabalhos correlatos que tenham realizado uma anlise detalhada de todos
os nveis do MPS.BR. O trabalho tambm contribui para as comunidades de FDD e Scrum, j
que estas metodologias parecem no ter sido exaustivamente comparadas com o MPS.BR.
A metodologia FDD atendeu a 87 resultados esperados, enquanto que o Scrum somente a 60
resultados, e desta forma, conclui-se que FDD mais robusta que Scrum no que diz respeito
implantao do MPS.BR. Apesar da superioridade de FDD, as duas abordagens no
conseguiram satisfazer completamente o nvel G do MPS.BR, pois embora essas duas
metodologias implementem algumas fases do ciclo de vida como requisitos, anlise, projeto e
entrega final, no ficam claros os procedimentos a serem realizados aps a entrega final do
sistema ao cliente. Alm disso, nenhuma das metodologias consegue satisfazer plenamente os
processos dos nveis A e B, o que sugere que a adoo pura de FDD ou Scrum inapropriada
para empresas que visem galgar sistematicamente todos os nveis de maturidade do MPS.BR.
Observa-se tambm que Scrum no atende a nenhum resultado esperado que no seja
contemplado por FDD. Assim, o estudo indica que uma associao do Scrum ao FDD no
implica em melhorias para o cumprimento dos requisitos do MPS.BR.
Para complementar o trabalho realizado torna-se interessante, para os casos em que
resultados esperados no so integralmente ou parcialmente atendidos, a proposio de prticas
que possam suprir as lacunas identificadas. Este o objeto de trabalho futuro imediato.
Pretende-se tambm investigar o nvel de adequao de outras metodologias geis aos nveis do
MPS.BR, visando fornecer uma ampla viso do alcance destas metodologias para pequenas e
mdias empresas que pretendam implantar o MPS.BR.
1. BECK, KENT E ANDRES, CYNTHIA. Extreme Prgramming Explained, Addison-Wesley, 2005.
2. CAMPELO, RENATA E.C; SILVA, FBIO GOMES E MOURA, HERMANO P. O uso de
Extreme Programming em uma Organizao CMM nvel 2. Anais do Simpsio Brasileiro de
Qualidade de Software, 2003.
3. COCKBURN, ALISTAIR. Crystal Clear - A Human-Powered Methodology for Small Teams.
Series Editors, 2004
4. CRUZ, LEANDRO RODRIGO SAAD. Desenvolvimento de Software com Scrum. Disponvel em:
cv-acolhimento.bvs.br/tiki-download_file.php?fileId=59. Acesso em: 15/08/2008.
5. KOSCIANSKI, ANDR E SOARES, MICHEL DOS SANTOS. Qualidade de Software. So Paulo,
SP. Editora: Novatec, 2007.
F. G. Silva; S. C. P. Hoentsch, L. Silva., Scientia Plena 5, 121301, 2009 13
6. [MPS.BR, 2007a] Associao para Promoo da Excelncia do Software Brasileiro SOFTEX.
MPS.BR Guia Geral, verso 1.2, junho 2007. Disponvel em: www.softex.br. Acesso em:
15/08/2008.
7. [MPS.BR, 2007b] Associao para Promoo da Excelncia do Software Brasileiro SOFTEX.
MPS.BR Guia de Implementao Partes 1 a 7, verso 1.1, junho 2007. Disponvel em:
www.softex.br. Acesso em: 15/08/2008.
8. J ACOBSON, IVAR; BOOCH, GRADY E RUMBAUGH, J AMES. The Unified Software
Development Process. Addison-Wesley, 1999.
9. PALMER, STEPHEN R. E FELSING, JOHN M. A Pratical Guide to Feature-Driven Development.
Prentice Hall, 2002.
10. RETAMAL, ADAIL MUNIZ. Metodologias de Desenvolvimento: UDP, FDD e XP. Disponvel
em: http://adailmr.sites.uol.com.br/artigos/fdd-udp-xp.htm. Acesso em: 15/08/2008.
11. SANTANA, CLIO A.; TIMTEO, Aline L. e VASCONCELOS, Alexandre M. L. Mapeamento
do Modelo de Melhoria de Software Brasileiro (MPS.BR) para Empresas que Utilizam Extreme
Programming (XP) como Metodologia de Desenvolvimento. Anais do V Simpsio Brasileiro de
Qualidade de Software, 2006.
12. SANTOS, J ORGE ET AL. Mtodos geis. Disponvel em
http://www.devmedia.com.br/articles/viewcomp.asp?comp=9443. Acesso em: 15/10/2008.
13. SCHWABER, KEN; BEEDLE, MIKE. Agile Software Development with SCRUM. Prentice Hall,
2002.
14. SOARES, MICHEL DOS SANTOS. Comparao entre Metodologias geis e Tradicionais para o
Desenvolvimento de Software. Disponvel em:
http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf. Acesso em : 10/08/2006.
15. ZANATTA, ALEXANDRE LAZARETTI E VILAIN, PATRCIA. Uma anlise do mtodo gil
Scrum conforme abordagem nas reas de processo Gerenciamento e Desenvolvimento de Requisitos
do CMMI. Passo Fundo - RS, 2003.