1. C.E.S.A.R – CENTRO DE ESTUDOS E SISTEMAS AVANÇADOS
DO RECIFE
ADSON WENDEL CIRILO FERREIRA
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O
MODELO DE QUALIDADE MPS.BR NOS NÍVEIS DE
MATURIDADE G E F
Recife
2011

2. ADSON WENDEL CIRILO FERREIRA
MAPEAMENTO ENTRE A METODOLOGIA ÁGIL FDD E O
MODELO DE QUALIDADE MPS.BR NOS NÍVEIS DE
MATURIDADE G E F
Monografia apresentada ao programa de
Especialização em Engenharia de Software do
Centro de Estudos e Sistemas Educacionais do
Recife – C.E.S.A.R, como requisito para a
obtenção do título de Especialista em Engenharia
de Software com ênfase em Gestão Ágil de
Projetos.
Orientação: Prof. Jorge Luiz Bublitz
Recife
2011

3. Mapeamento entre a metodologia ágil FDD e o Modelo de
Qualidade MPS.BR nos Níveis de Maturidade G e F
Adson Wendel Cirilo Ferreira1
, Jorge Luiz Bublitz2
1
C.E.S.A.R – Centro de Estudos e Sistemas Avançados do Recife
Adson_wendel@hotmail.com
2
E.S.A.B - Escola Superior Aberta do Brasil
bublitz@hotmail.com
Resumo. O MPS.BR, é uma avaliadora da qualidade de software e serviços
relacionados, utiliza padrões e características semelhantes ao modelo CMMI
e nas normas ISO/IEC 12207 e na ISO/IEC 15504, visando as empresas
desenvolvedoras de software, que seja certificada na norma brasileira, este
artigo baseando-se na FDD, vem com o objetivo de ajudar as empresas a
definirem um processo ágil e ganharem mais velocidades nos processos dos
resultados esperados desta certificação, assim tornando-se ainda mais
competitiva no mercado de software.
1. Introdução
O MPS.BR (Melhoria de Processo do Software Brasileiro) é um programa brasileiro que
apresenta um padrão de qualidade fundamentado no CMMI (Capability Maturity Model
Integration) e nas ISO's 12207 e 15504, o qual é responsável em avaliar não só a
qualidade e a produtividade de software, mas também serviços relacionados a ele. Para
uma empresa que trabalha visando alcançar os resultados esperados do modelo de
maturidade brasileiro.
Seu principal objetivo é traçar os resultados esperados a serem trabalhados de
maneira produtiva e eficiente para o desenvolvimento de um software que busca sempre
um melhoramento geral, voltando-se à condição do mercado brasileiro, para o alcance
das empresas públicas e privadas de vários tamanhos, onde a maior atenção é para as
micros, pequenas e médias empresas, segundo a SOFTEX (2011a) “de forma a atender
as suas necessidades de negócio e ser reconhecido nacional e internacionalmente
como um modelo aplicável à indústria de software” por esses motivos o MPS.BR é
modelo escolhido para este artigo.
O Manifesto Ágil, resultado de uma reunião realizada em 2001 nos EUA, que
teve a participação de dezessete especialistas da engenharia e desenvolvedores de
software, Agile Manifesto (2004) relata que “Como seria difícil outra reunião com estes
anarquistas organizacionais, o que resultou foi o simbólico – Manifesto do
Desenvolvimento Ágil de Software – assinado por todos participantes.”, Relata
Soare(2009) que a agile manifesto importando-se com “os indivíduos e interações,

4. com o software estar executável, com a colaboração do cliente e as respostas rápidas a
mudanças e alterações”.
Diante disso, os modelo, MPS.BR e CMMI, e as normas, ISO (Institute of
Organization for Standardization) 12207 e 15504, são conhecida como metodologias
tradicionais, segundo Soares (2009) “Processos orientados a documentação para o
desenvolvimento de software são, de certa forma, fatores limitadores aos
desenvolvedores”, chegando a prorrogar a criação dos processos mais complexos,
retardando as entregas. Com base no novo pensamento agilista, este trabalho propõe
ajudar uma empresa a se tornar mais competitiva, aumentar ainda mais sua visibilidade
no mercado e ganhar mais velocidade nos processos requeridos pela norma de
maturidade, baseando-se na metodologia de gerenciamento e engenharia de
software, a FDD(Feature Driven Development), que é utilizada de forma iterativa e
incremental com práticas ágeis.
1.1 Objetivo
O objetivo principal deste artigo é o mapeamento dos resultados esperados do modelo
MPS.BR dos níveis G e F com as práticas da FDD que satisfaça as necessidades de cada
resultado. As áreas de processos que serão utilizadas no modelo brasileiro são: Gerência
de Projetos, Gerência de Requisito, Gerência de Configuração, Garantia da Qualidade e
Medição. Os processos de Aquisição e Gerência de Portfólio de Projetos não são
contemplados. No intuito de consolidar o artigo, foi feita uma revisão bibliográfica no
Manifesto ágil, na FDD, no MPS.BR e suas bases estruturais, que é a ISO 12207, a
15504 e o CMMI.
1.2 Justificativa
A competitividade entre as organizações desenvolvedoras de software fez com que os
clientes ficassem mais rigorosos na qualidade dos produtos por elas produzidos, onde as
empresas podem comprovar com uma Certificação MPS.BR, programa que avalia a
qualidade e serviços relacionados a software, que é direcionado a real situação do
mercado brasileiro, no intuito do alcance das empresas públicas e privadas, com maior
atenção as micros, pequenas e médias empresas.
O MPS.BR utiliza uma metodologia tradicional segundo Soares (2009)
“conhecidas também como pesadas ou orientadas a planejamentos”. Através dele, as
atividades são orientadas a documentação para o desenvolvimento de software, que de
certa forma limita o desenvolvimento dos processos mais complexos.
O foco deste artigo são as empresas que seja certificado no (MPS.BR) , com real
contribuição que a FDD tem para agilizar os resultados esperados pelo modelo
brasileiro. Com isso, tais empresas ganham mais velocidade nos processos, tornando-se
ainda mais competitivas no mercado de software, através da utilização de uma das
metodologias (FDD) que foi associada ao manifesto ágil.

5. 1.3 Estrutura da Monografia
Este artigo está organizado na seguinte forma:
Na seção 2, foi feita uma abordagem sobre as bases da estrutura do modelo
brasileiro MPS.BR, delimitando em resumos a ISO/IEC 12207 e sua evolução, a
ISO/IEC 15504 e o CMMI, descrevendo suas origens e seus desenvolvedores. Foi
apresentado, também em síntese, o conceito e as características de cada norma de
melhoria de processo de software;
Na seção 3, foi realizada uma abordagem sobre o programa MPS.BR,
apresentando informações essenciais sobre o modelo de Referência (MR-MPS),
aprofundando as informações para os níveis de maturidade G e F, com intuito de
delimitar o tema deste artigo;
Na seção 4, foi abordado o surgimento do manifesto ágil, os seus conceitos,
princípios, os profissionais e as metodologias envolvidas;
Na seção 5, foi comentada a criação da FDD, seu conceito, características,
modelo ARO, algumas das práticas mais usadas, principais papéis e os cinco processos
principais;
Na seção 6, foi apresentado um mapeamento conciso entre o modelo MPS.BR
com os resultados esperados dos níveis de maturidades G e F que possuem atividades
similares na FDD;
Na seção 7, foi apresentada uma conclusão analítica sobre o artigo.
2. Base da Estrutura do Modelo MPS.BR
2.1 ISO/IEC 12207
A norma ISO/IEC 12207 foi criada pela ISO e IEC para solucionar um problema de
modelagem e melhoria no processo de software, e segundo Gusmão & Moura (2004) “é
a primeira norma internacional que descreve em detalhes os processos, atividades e
tarefas que envolvem o fornecimento, desenvolvimento, operação e manutenção de
produtos de software” localizando-se entre as mais antigas normas que definem os
processos de desenvolvimento da área.
Weber (2004) afirma que “a norma foi publicada internacionalmente em 1995, e
no Brasil em 1998”. Segundo Gusmão & Moura (2004) “Essa norma divide os
processos em três grandes classes: Processos Fundamentais, Processos de Apoio e
Processos Organizacionais”, cada classe com suas atividades.
O objetivo fundamental do modelo é instalar uma base comum para os processos
de ciclo de vida e de desenvolvimento do software, estruturada para ser flexível, sem
ligações com treinamentos, ferramentas, métodos e linguagens de desenvolvimento.
Segundo Ferreira (2010; p18) a norma “possibilita um acompanhamento da evolução da
engenharia de software e de organizações com culturas distintas, flexibilidade
importante, pois implica no “o que fazer” e não ficando refém de “como fazer””.

6. 2.2 ISO/IEC 15504
Também conhecida como SPICE e evoluída da ISO 12207, é uma norma de processos
de desenvolvimento de software que teve uma versão aprovada em 1998, que, em união
com a comunidade internacional e através do projeto SPICE, foi publicada em 2003 pela
ISO. Nela é descrito um conjunto de processos considerados universais e fundamentais
para que se possa ter um planejamento e desenvolvimento com qualidade, visando a
melhoria dos processos da criação do software.
As organizações podem solicitar certificação de capacidade específica em áreas
determinadas, sabendo assim quais partes da organização terão que ser feitas melhorias
e quais características manter. Segundo Weber et al. (2004; p6) “a organização pode
realizar a avaliação, gerando um perfil dos processos que será usado para a elaboração
de um plano de melhorias”, das quais a empresa deve continuar sempre a manter, sem
perder a qualidade e o foco no cliente.
2.3 CMMI
É uma modelo de certificação de qualidade empregada no intuito de avaliar as melhorias
na maturidade dos processos em desenvolvimento de software e serviços
correspondentes, com origem no ano de 1980, nos Estados Unidos, com implantação do
projeto desenvolvido pelo SEI(Software Engineering Institute). Segundo Pessôa (2005)
“O desenvolvimento desse modelo foi financiado pelo departamento de defesa
americano, com o objetivo de estabelecer um padrão de qualidade para software
desenvolvido para as forças armadas”. Com essa norma de avaliação, seria possível
mensurar os processos desenvolvidos de software das organizações que concorriam pela
licitação, tendo em vista as indicações, valor do produto, qualidade, garantia de prazos
de entrega e dos projetos contratados. Embora iniciada para projetos militares, é válida
para todo tipo de projetos de software.
Rezende (2002) afirma que “os principais objetivos do CMMI são auxiliar as
empresas a conhecerem e melhorarem seus processos de desenvolvimento e manutenção
de software, fornecendo uma estrutura conceitual para guiar as empresas para obterem
controles de seus processos, com melhoria contínua de seus produtos de software”.
O CMMI é dividido em níveis de maturidade. Segundo Gusmão & Moura (2004)
O SW-CMM foi o primeiro modelo desenvolvido na área de maturidade e capacidade, o
qual apresenta cinco níveis de maturidade, onde o mais avançado corresponde a uma
maior maturidade do processo que está associado a uma maior produtividade, qualidade
e a um menor risco organizacional. As graduações crescentes são: inicial, repetível,
definido, gerenciado e otimização.
3 MPS.BR
O modelo MPS.BR tem como objetivo a melhoria de processo de software, manejando a
empresa buscar a seus produtos desenvolvidos e serviços relacionados com qualidade.
Weber (2004, P3) afirma que “O Projeto MPS.Br visa a melhoria de processos de
software em empresas brasileiras a um custo acessível, especialmente na grande massa
de micro, pequenas e médias empresas”. É um projeto brasileiro empregado,
igualmente, para organizações públicas e privadas, com padrão e qualidade das normas
de desenvolvimento internacionais.

7. Figura 1: Estrutura do projeto MPS.BR
Fonte: SOFTEX <http://www.softex.br/portal/softexweb/uploadDocuments/sbes2011_
melhoria_processo_folder_com_quadro_a4.pdf >
A figura 1 exibe a estrutura do projeto MPS.BR, as suas bases de sustentação
nas normas internacionais da ISO/IEC 12207 e ISO/IEC 15504 e o modelo CMMI,
apresentando o conjunto do projeto com as respectivas funções. No guia geral, são
demonstrada as informações do modelo de Referência (MR-MPS), níveis, resultados
esperados e outros; no guia de aquisição, são mencionados os processos de aquisição
de software e serviços correlatos; no guia de avaliação, é apresentado o método de
avaliação (MA-MPS), mencionando as informações necessárias para o entendimento
dos processos avaliativos; e no documento de programa, são apresentadas as
informações sobre o modelo de negócio (MN-MPS).
Figura 2: Comparação dos Níveis de Maturidade do modelo MPS.BR com o modelo CMMi
Fonte: SOFTEX < http://www.softex.br/portal/softexweb/uploadDocuments/MN-MPS.pdf>
Na figura 2, são apresentados os níveis de maturidade do modelo de referência.
Segundo a SOFTEX (2011a) são “A (Em Otimização), B (Gerenciado
Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido),
F(Gerenciado) e G (Parcialmente Gerenciado)”. Nos níveis de maturidades, serão mais
detalhados o G e F.
3.1 G - Parcialmente Gerenciado
Por ser o primeiro nível de maturidade a implantar as melhorias dos processos de
software em uma empresa, requer cautela para mudar a cultura da organização para a
melhoria de processo e para a definição de projeto. A SOFTEX (2011b, pag. 6) relata

8. que “porventura, a organização possuir processos já definidos e os projetos necessitarem
adaptar os processos existentes, tal fato deverá ser declarado durante o planejamento do
projeto”. Essas adaptações podem incluir alteração em processos, atividades,
ferramentas, técnicas, procedimentos, padrões, medidas, dentre outras.
3.1.1 Gerência de Projetos
O guia específico do nível de maturidade G da SOFTEX (2011b) afirma que “O
propósito do processo de Gerência de Projetos é estabelecer e manter planos que
definam as atividades, recursos e responsabilidades do projeto, bem como prover
informações sobre o seu andamento”. Ao acumular os níveis de maturidades, alguns
resultados esperados são incorporados e outros sofrem modificações.
3.1.2 Gerência de requisito
Na gerência de requisito, o objetivo do processo é o controle e a evolução dos
requisitos, vindos de análise junto ao cliente ou gerados pelo projeto, sempre
documentando as mudanças dos requisitos e seus motivos. Segundo a SOFTEX (2011b)
“O propósito do processo e Gerência de Requisitos é gerenciar os requisitos e os
componentes do produto do projeto, identificar inconsistências entre os requisitos,
planos e produtos de trabalho do projeto”.
3.2 F – Gerenciado
No nível de maturidade F, o principal foco é nos processos para a gestão do projeto,
“[...] no que diz respeito à Garantia da Qualidade (GQA) e Medição (MED), bem como
aqueles referentes à organização dos artefatos de trabalho por meio da Gerência de
Configuração (GCO)” relata a SOFTEX (2011c).
3.2.1 Gerência de Configuração
Sua principal atuação ocorre durante o processo de auxiliar no controle e
acompanhamento, manter a integridade do projeto e suas funcionalidades, sendo
fundamental prover o controle sobre os trabalhos desenvolvidos e modificados. A
SOFTEX (2011c) afirma que “em determinados momentos do ciclo de vida do
desenvolvimento e manutenção do software, esses itens de configuração são agrupados
e verificados, constituindo configurações do software, voltadas para propósitos
específicos, denominadas baselines”, assim ficam delegados conjuntos de itens de
configuração.
3.2.2 Garantia da Qualidade
Com a finalidade em confirmar que o produto desenvolvido ou serviços estão em
conformidades com os processos traçados no plano do projeto, exibe visibilidade do
projeto e apoia à gerência. De acordo com a SOFTEX (2009e) “A pessoa ou grupo que
executa a atividade de garantir a qualidade de processos e produtos tem uma

9. responsabilidade delicada, pois fiscaliza se as pessoas estão desempenhando
adequadamente as suas tarefas e seguindo os procedimentos estabelecidos”. Para isso, é
necessário que os responsáveis tenham autoridade para executar seu trabalho,
documentarem não conformidade do projeto, cobrarem a correção dos artefatos
encontrados, promoverem feedback da verificação realizada para a gerência e equipe de
projeto.
3.2.3 Medição
Segundo a SOFTEX (2009e) “O propósito do processo Medição é coletar, armazenar,
analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos
implementados na organização e em seus projetos, de forma a apoiar os objetivos
organizacionais”. A medição é muito utilizada para o auxílio da tomada de decisão da
gerência
4 Manifesto Ágil
Em 2001, nos EUA, em uma reunião que discutiu formas de melhorar o desempenho de
projetos de softwares, surgindo assim a Aliança do Desenvolvimento Ágil de
Software. onde 17 desenvolvedores assinantes, principais profissionais experientes e
reconhecidos “gurus” desenvolvedores na área de engenharia de softwares, foram: Kent
Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon
Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland e Dave Thomas, os quais têm o objetivo de ajudar outras pessoas com os
métodos ágeis a crescerem seus próprios conhecimentos, segundo Agile
Manifesto(2004) “Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo.”
Na elaboração do manifesto ágil, foram envolvidas várias metodologias ágeis:
XP (eXtreme Programming), DSDM (Dynamic Systems Development Method), Família
Crystal, ASD (Adaptive Software Development), SCRUM e FDD (Feature-Driven
Development), das quais este artigo fará o mapeamento com os níveis G e F do
MPS.BR.
Os valores do desenvolvimento ágil, de acordo com o Agile Manifesto (2004),
são:
• Indivíduos e interações mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.
A utilização das metodologias ágeis já é um movimento que é fato no Brasil,
onde vários projetos foram concluídos com êxito. AgilCoop (2011) lista algumas
empresas: Objective Solutions, pioneira no uso de XP no Brasil; LocaWeb, utiliza
Scrum e XP desde de 2007; Paggo, desenvolve software usando XP que também
influencia no funcionamento da empresa; Improve It, consultoria em XP; Teamware,

10. consultoria, mentoring e treinamento com Scrum Master e Scrum Leader e Neurobox
com Scrum, XP e Lean, entre outras não citadas pelas empresas.
5 FDD
Surgiu em 1997 em Singapura para solução de um projeto de software de
empréstimo para uma instituição bancária, segundo Retamal (2008b) “a partir de
técnicas de gerenciamento de projetos e de modelagem orientadas a objetos, Jeff De
Luca era o gerente do projeto e Peter Coad foi contratado para fazer a modelagem do
domínio do problema”, nascendo assim a FDD que equilibrava as metodologias
prescritivas com as técnicas de De Luca e com as estratégias de Coad, propondo uma
metodologia de desenvolvimento que atendesse a demanda de entrega de resultados
frequentes e sem atrasos, a qual possui o lema “resultados frequentes, tangíveis e
funcionais”. O projeto para a instituição bancária durou 15 meses e foi desenvolvido
com 2000 feature por 50 pessoas.
De acordo com Retamal (2008b) os responsáveis “lançaram as ideias no livro
“Java Modeling in Color with UML” (1999). Posteriormente (2002), Stephen Palmer
[...] e John Mac Felsing [...] lançaram “A Practical Guide to FDD”, com a descrição
completa e atualizada da metodologia.”
Bublitz (2011) afirma que a FDD “é uma metodologia iterativa e incremental de
gerenciamento e engenharia de software, que combina as melhores práticas de outras
abordagens ágeis com técnicas centradas no modelo”, com característica que enfatiza a
qualidade durante o processo, entregas curtas e versões de software pequenas. Com o
intuito de oferecer valor ao cliente, as features são desenvolvidas no máximo em duas
semanas e segue o modelo ARO (Ação, Resultado e Objetivo). Medeiros (2011) explica
que o modelo “Representa uma <Ação> necessária para atingir determinado
<Resultado> de negócio envolvendo determinados <Objetos> de negócio, por exemplo:
“<Autorizar> um <desconto> numa <venda>””.
Os papéis chaves em um projeto FDD são divididos em funções e cargos, são
eles: gerente de Projeto, líder administrativo e financeiro do projeto, o qual tem a
palavra final no que se trata de escopo, cronograma e RH do projeto; arquiteto chefe,
responsável pela modelagem do projeto; gerente de desenvolvimento, este lidera as
atividades diárias do desenvolvimento, sendo responsável para solucionar conflitos
dentro da equipe; programador chefe é o desenvolvedor experiente, presente nas fases
de análise de requisitos e de modelagem de projetos, lidera pequenos times de
desenvolvimento, seleciona as funcionalidades e os donos das classes para a próxima
iteração; donos de classe, geralmente é um desenvolvedor que trabalha orientado pelo
Programador Chefe, executando as tarefas de modelar, codificar, testar e documentar; e
os especialistas no domínio de negócio, os quais são responsáveis em informar a
equipe sobre o que deve ser implementado para que o software agregue valor.
A FDD possui algumas práticas de engenharia de software com o objetivo de
estimularem a produção com qualidade, entre elas: modelagem de objetos do domínio,
desenvolvimento por feature, posse individual de classe (código), equipes de features,
inspeções, builds regulares, demonstrável para o cliente; relatório/visibilidade de

11. resultados e gerenciamento de configuração que acompanha todo o histórico do código-
fonte.
A FDD é uma metodologia muito objetiva que possui cinco processos, o qual é
dividida em duas etapas, assim tornou esta metodologia escolhida para o
mapeamento com o MPSBR neste artigo, a primeira é concepção e planejamento,
que pensa no modelo e cria uma lista de feature e planeja através dela; a segunda é a
construção, que é um desenvolvimento iterativo e incremental que dura no máximo
duas semanas.
Figura 3: Estrutura da FDD.
Fonte: < http://www.heptagon.com.br/images/fdd.png >
5.1 Desenvolver um Modelo Abrangente
Processo que é executado apenas uma vez em todo o Projeto, composto por um time de
modelagem com especialistas de negócio, programadores e arquiteto líder. Luca (1998)
relata que “É feito um estudo detalhado do escopo do sistema e seu contexto é
executada, então são feitos estudos mais detalhados em cada área a ser modelada”. Em
seguida são formados pequenos grupos por membros do domínio do negócio, os
desenvolvedores criam seus modelos, os quais são estudados, revisados e discutidos,
para através de um consenso escolher um ou mais modelos criados pelos grupos.
5.2 Construir uma lista de funcionalidades Também é um processo único executado no
início do projeto, que visa satisfazer os requisitos e criar as funcionalidades. É composto por
programadores líderes do processo anterior, onde o entendimento do escopo é ampliado através
da descoberta das feature de cada área prioritária. Retamal (2008a) descreve que “para
decompor funcionalmente o domínio em áreas, atividades de negócio dentro delas e passos
dentro de cada atividade de negócio, formando assim a lista categorizada de funcionalidades”, é
utilizada a prática de FBS (Feature Breakdown Structure) para ajudar a identificar as
funcionalidades a desenvolver, segundo Medeiros (2011) “Organiza o entendimento sobre as
áreas, as atividades de negócios e as funcionalidades de um produto” sobre uma leitura
estruturada dos requisitos.

12. Figura 4: Feature Breakdown Structure.
Fonte: < http://agiles2008.agiles.org/common/pdfs/Pimentel%20-20Agil%20FDD.pdf>
5.3 Planejar por Feature
Último processo da primeira etapa que, igualmente aos dois processos anteriores, é
inicial e abrange todo o projeto onde são planejadas as sequências, nas quais as
funcionalidades serão desenvolvidas, tendo como base para desenvolver as
dependências entre classes, carga de trabalho e complexidade.
A equipe é composta pelo gerente de desenvolvimento e pelos programadores
líderes, de modo que, para cada atividade de negócio, o planejamento deve reportar uma
data com mês e ano para a finalização.
5.4 Projetar por Feature
Primeiro processo da etapa de construção, que tem seu ciclo renovado em todas as
funcionalidades. Certas features são selecionadas e agendadas com uma data de
finalização, consequentemente irá para desenvolvimento, criando uma “caixa de
entrada”, podendo fazer uma junção de funcionalidades, chamada de pacote de trabalho.
Segundo Luca (1998) “o programador chefe, forma uma equipe de recursos,
identificando os proprietários das classes (desenvolvedores) que possam estar
envolvidos no desenvolvimento desses recursos. Essa equipe então produz Vistas
Cenário para o recurso atribuído”.
Cada desenvolvedor produz então prefácios das classes e métodos para cada
feature com seus diagramas de classes e de sequências que servirão de base para o
programador líder refinar o modelo de objetos que serão submetidos ao sistema de
controle de versões. A atividade de projetar por feature pode ou não utilizar UML em
cores, no intuito de auxiliar no entendimento das features. O programador líder pode
fazer inspeção no projeto com os membros da equipe de funcionalidades ou com outros
membros do projeto.
De acordo com Medeiros (2011) “a UML em cores foi inicialmente posta por
Peter Coad, e teve grande contribuição de Eric Lefebvre e Jeff De Luca, os quais
possuem vários anos de experiência em modelagem de aplicações para segmentos de
variados tamanhos”. Para facilitar a identificação das construções das entidades, as
categorias segundo o Coad (1999) são identificada da seguinte forma “Rosa: um
momento ou intervalo de tempo. Amarelo: um papel a ser desempenhado por alguém ou
algo. Azul: a entrada de catálogo-como a descrição. Verde: uma pessoa (partido), lugar
ou coisa”.

13. 5.5 Construir por Feature
Processo onde é realmente desenvolvido o código fonte de cada feature, visando a
entrega contínua com valor ao cliente. Luca (1998) relata que “Começando com o
pacote de projeto, os proprietário das classes implementam os itens que serão
necessários para que suas classes suportem o projeto para a sua funcionalidade.” e após
passar pela inspeção de outra pessoa da equipe ou do projeto, a funcionalidade é levada
a uma build. Cada funcionalidade é medida através de um gráfico constituído por seis
marcos bem definidos, denominados milestones. A cada etapa cumprida, o percentual
respectivo é agregado ao total de progresso e utilizado para o controle das features do
painel de progresso (Parking Lot).
6 Mapeamentos entre FDD e MPS.BR.
Neste capítulo será apresentado um mapeamento conciso entre o modelo MPS.BR com
os resultados esperados dos níveis de maturidades G e F que possuem atividades
similares na FDD, delimitando as áreas de processos do MPS.BR para gerência de
projetos, gerência de requisito, gerência de configuração, garantia da qualidade e
medição, não contemplando os processos de aquisição e gerência de portfólio de
projetos, os quais não possuem práticas que a FDD atenda.
A FDD não é condicionalmente compatível com os resultados esperados dos
níveis do MPS.BR exposto neste artigo, por este motivo foram estabelecidos três
critérios para classificar a equivalência entre da metodologia FDD e o modelo de
qualidade brasileiro, primeiro critério, Atende, a prática da FDD está em plena
conformidade; Atende Parcial, Algumas evidências são encontradas mas não satisfaz
integralmente o que é solicitado; Não Atende, não há como a FDD ajudar com suas
atividades.
Processo Gerência de Projetos (GPR)
O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem
as atividades
Processo Gerência de Projetos (GPR) FDD Critério
GPR1 - O escopo do trabalho para o projeto é
definido.
O escopo é criado em duas etapas:
Desenvolver o modelo abrangente e
Construir a lista de funcionalidades.
Atende
GPR2 - As tarefas e Produtos são
dimensionados, resultado de estimativa de
tamanho, a dimensão das funcionalidades são
contadas, classes, objetos.
No processo Construir a Lista de
Funcionalidades, ocorre a decomposição
funcional das áreas do negócio definidas
na primeira etapa.
Atende
GPR3 - As fases do ciclo de vida do projeto são
definidas.
Ocorre em duas etapas: Desenvolver o
modelo abrangente e Construir a lista de
funcionalidades, onde é decomposto em
funcionalidades.
Atende
GPR4 - O esforço e o custo para a execução do
projeto são estimados com base em dados
históricos onde são recuperadas informações de
tempo e complexidade.
A estimativa de esforço encontra-se na
etapa Planejar por Funcionalidade, onde
são realizadas através da complexidade e
experiências anteriores.
Atende
Parcial
GPR5 - O orçamento e o cronograma do
projeto, incluindo a definição de marcos e
pontos de controle, são estabelecidos e
No fim do processo Planejar por
Funcionalidade é criado o Plano de
Desenvolvimento, onde encontram-se: as Atende

14. mantidos. features com suas dependências, a
sequência de criação, as atividades de
negócio com as datas de términos e os
pontos de controle do cronograma.
Parcial
GPR6 - Os riscos do projeto são identificados,
o seu impacto é documentado e os riscos são
analisados e priorizados.
O gerente de desenvolvimento tem o
papel de ser o responsável pela resolução
de riscos que possam vir a ocorrer dentro
da equipe. As funcionalidades mais
complexas de maiores riscos ficam sob a
responsabilidade dos programadores
chefe.
Atende
GPR7 - Os recursos humanos para o projeto são
planejados considerando o conhecimento,
habilidades e experiências possuídas.
Os papéis são definidos e cada um tem
suas funções e as atividades realizadas no
processo Planejar por Funcionalidade,
onde as pessoas da equipe são alocadas
de acordo com as classes que lhes foram
atribuídas.
Atende
GPR8 - Os recursos e o ambiente de trabalho
necessários para executar o projeto são
planejados.
O gerente de projeto é responsável por
fornecer condições de trabalho
adequadas para a equipe.
Atende
GPR9 - Os dados do projeto são identificados e
planejados quanto à forma de coleta,
armazenamento e distribuição.
São identificados em diagrama de classes
(Modelo Abrangente de Dados),
diagramas de sequência, de estado, de
casos de uso entre outros; já o
armazenamento é submetido a um
controle de versão.
Atende
GPR10 - Um plano geral para a execução do
projeto é estabelecido com a integração de
planos específicos.
No plano de desenvolvimento contém
atividades, onde os programadores
líderes atribuem as funcionalidades das
atividades de negócio aos seus
respectivos desenvolvedores
proprietários.
Atende
Parcial
GPR11 - A viabilidade do projeto,
considerando as restrições e os recursos
disponíveis, é avaliada, se necessário, ajustes
são realizados.
Ainda no plano de desenvolvimento no
processo Planejar por Funcionalidade são
geradas atividades de negócio com datas
de término, e o acompanhamento do
projeto é revisto de acordo com as
alterações junto ao cliente.
Atende
GPR12 - O Plano do Projeto é revisado com
todos os interessados e o compromisso com ele
é obtido.
O processo Desenvolver o Modelo
Abrangente é realizado por membros de
domínio do negócio, por programadores
e pelo arquiteto líder. Após construir a
lista de features, o plano de
desenvolvimento é criado. Este é
revisado pelo cliente e pela equipe, todos
se comprometendo.
Atende
Parcial
GPR13 - O projeto é gerenciado utilizando-se o
Plano do Projeto e outros planos que afetam o
projeto, e os resultados são documentados.
No plano de desenvolvimento, contém as
datas para as entregas das features. Ao
fluir das atividades, as datas são
comparadas.
Atende
Parcial
GPR14 - O envolvimento das partes
interessadas no projeto é gerenciado,
informando em quais fases eles são importantes
e como serão envolvidos.
Todos os processos e as partes
interessadas são planejados, Desenvolver
o Modelo Abrangente com domínio do
negócio, desenvolvedores e arquiteto
líder. No processo Construir a Lista de
Funcionalidades programadores líderes e
Atende

15. desenvolvimento assim sendo
envolvidos.
GPR15 - Revisões são realizadas em marcos do
projeto e conforme estabelecido no
planejamento.
No plano de desenvolvimento,
contemplam as datas de finalização.
Nessas datas são realizadas inspeções do
progresso das atividades e do projeto em
relação ao planejado.
Atende
GPR16 - Registros de problemas
identificados, incluindo dependências críticas,
são estabelecidos e tratados com as partes
interessadas.
Não
Atende
GPR17 - Ações para corrigir desvios em
relação ao planejado e para prevenir a repetição
dos problemas identificados são estabelecidas.
No plano de desenvolvimento contem as
lista de funcionalidades nas quais são
realizadas inspeções e testes podendo
identificar possíveis riscos que é de
responsabilidade do gerente de projeto
aplicar medidas que sanem problemas em
desvios de planejamento.
Atende
Parcial
Quadro1: Descrição dos resultados esperados do processo de Gerência de Projetos e o mapeamento na FDD
Nível G – Processo Gerência de Requisitos (GRE)
O propósito do processo Gerência de Requisitos é gerenciar os requisitos dos produtos e
componentes do produto do projeto. Ele possui os seguintes resultados esperados:
Processo Gerência de Requisitos (GRE) FDD Critério
GRE1 - Os requisitos são entendidos, avaliados
e aceitos junto aos fornecedores de requisitos.
É realizado o levantamento dos
requisitos e armazenado na lista de
funcionalidades, com o cliente priorizado
as funcionalidades.
Atende
GRE2 - O comprometimento da equipe técnica
com os requisitos aprovados é obtido.
As aprovações das funcionalidades pela
equipe técnica ocorrem na etapa Planejar
por Funcionalidade que é gerado o Plano
de Desenvolvimento revisado pelo
cliente e pelos membros da equipe.
Atende
GRE3 - A rastreabilidade bidirecional entre os
requisitos e os produtos de trabalho é
estabelecida e mantida.
Não
Atende
GRE4 - Revisões em planos e produtos de
trabalho do projeto são realizadas visando
identificar e corrigir inconsistências em relação
aos requisitos.
Na atividade inspeção de código e na de
testes de unidade, possibilita identificar
inconsistências, visando a entrega de uma
atividade de valor ao cliente.
Atende
GRE5 - Mudanças nos requisitos são
gerenciadas ao longo do projeto.
As alterações de requisitos podem
ocorrer no projeto, alterando, nesse caso,
o Plano de Desenvolvimento. As
mudanças nos requisitos são gerenciadas
através do controle das versões.
Atende
Parcial
Quadro 2: Descrição dos resultados esperados do processo de Gerência de requisito e o mapeamento na FDD

16. Nível F – Processo Gerência de Configuração (GCO)
Tem propósito de estabelecer e manter a integridade de todos os produtos.
Processo Gerência de Configuração (GCO) FDD Critério
GCO1 - Um Sistema de Gerência de
Configuração é estabelecido e mantido.
É realizado o gerenciamento de
configurações durante o controle de
versões do projeto de software.
Atende
GCO2 - Os itens de configuração são
identificados com base em critérios
estabelecidos.
No Processo Detalhar por
funcionalidade, os diagramas de classe,
métodos, atributos são identificados para
controle de versão.
Atende
GCO3 - Os itens de configuração sujeitos a um
controle formal são colocados sob baseline.
Não
atende
GCO4 - A situação dos itens de configuração e
das baselines é registrada ao longo do tempo e
disponibilizada.
Os proprietários das classes escrevem os
prefácios sobre suas classes e as mesmas
são publicadas na intranet.
Atende
GCO5 - Modificações em itens de configuração
são controladas.
Fica sob a responsabilidade do
programador líder fazer as alterações.
Atende
GCO6 - Todos os produtos de trabalho que
forem itens de configuração, tanto de projetos
quanto de processos, são armazenados no
sistema de Gerência de Configuração.
Diagrama de sequência, métodos,
atributos, parâmetros, tipos de retorno,
exceções e mensagens são submetidos a
um controle de versão.
Atende
GCO7 - Auditorias de configuração são
realizadas objetivamente para assegurar que as
baselines e os itens de configuração estejam
íntegros, completos.
Não
Atende
Quadro 3: Descrição dos resultados esperados do processo de Gerência de Configuração e o mapeamento na FDD
Nível F – Processo Garantia da Qualidade (GQA)
O propósito do processo Garantia da Qualidade. Este processo compreende os
resultados esperados:
Processo Garantia da Qualidade (GQA) FDD Critério
GQA1 - A aderência dos produtos de trabalho,
os padrões, procedimentos e requisitos
aplicáveis são avaliados objetivamente antes
dos produtos serem entregues ao cliente e em
marcos predefinidos ao longo do ciclo de vida
do projeto.
O produto concluído passa pelo teste e
inspeção que são feitos por membros da
equipe ou outros membros do projeto,
que tem sua data (mês e ano) para a
entrega de cada atividade de negócio.
Atende
GQA2 - A aderência dos processos executados,
as descrições de processo, padrões e
procedimentos são avaliados objetivamente.
Atende
GQA3 - Os problemas e as não-conformidades
são identificados, registrados e comunicados.
As não-conformidades são recolocadas
no plano de desenvolvimento e é
verificado se isso irá trazer impacto no
cronograma. Se ocorrer, o plano é
readequado.
Atende
Parcial
GQA4 - Ações corretivas para as não-
conformidades são estabelecidas e
acompanhadas até as suas efetivas conclusões.
As correções dos problemas são
identificadas na inspeção e nos testes do
código.
Atende
Parcial
Quadro 4: Descrição dos resultados esperados do processo da Garantia da Qualidade e o mapeamento na FDD

17. Nível F – Processo Medição (MED)
O propósito do processo Medição é coletar, analisar e relatar as atividades
desenvolvidas, o processo possui os seguintes resultados esperados:
Processo Medição (MED) FDD Critério
MED1 - Objetivos de medição são
estabelecidos e mantidos a partir dos objetivos
da organização e das necessidades de
informação.
O painel de progresso (Parking Lot)
apresenta informação do andamento das
atividades. Atende
Parcial
MED2 - Um conjunto adequado de medidas,
orientado pelos objetivos de medição, é
identificado e definido, priorizado,
documentado, revisado e, quando pertinente,
atualizado.
As medições dos processos são
estabelecidas nos (Milestone), cada um
com um peso em relação à
funcionalidade que são: Estudo dirigido
da funcionalidade 1%, Desenho 40%,
Inspeção de Desenho 3%, Codificação
45%, Inspeção do Código10% e
Promover para Build 1%.
Atende
MED3 - Os procedimentos para a coleta e o
armazenamento de medidas são especificados.
É estabelecido o processo de medição
das funcionalidades (Milestone).
Atende
Parcial
MED4 - Os procedimentos para a análise das
medidas são especificados, após escolha de uma
métrica em MED2, têm que ser documentadas
as atividades e responsabilidades pela análise
das medições e como os resultados serão
comunicados.
Os programadores chefe e o gerente de
desenvolvimento ficam com a
responsabilidade de coletar e analisar as
features.
Atende
MED5 - Os dados requeridos são coletados e
analisados.
Os dados coletados são analisados e
atualizados no quadro de tarefas no
processo Construir por Funcionalidade.
Atende
MED6 - Os dados e os resultados de análises
são armazenados.
As informações são coletadas com os
proprietários das classes para medirem o
andamento da funcionalidade.
Atende
MED7 - As informações produzidas devem ser
comunicadas para os usuários das medições,
apoiando-os nos processos de tomada de
decisão.
Há uma preocupação com o
armazenamento da coleta dos dados para
serem usados como apoio de decisões.
Atende
Parcial
Quadro 8: Descrição dos resultados esperados para o processo de Medição e o mapeamento na FDD
Portanto neste mapeamento foi visto 40 resultados esperado nos processos dos
níveis G e F do MPS.BR, dos quais de acordo com os critérios pré-estabelecidos, foram
distribuídos da seguinte forma: Atende com 24, Atende Parcial com 12, Não Atende
finalizando com 04, ao qual é demostrada no gráfico abaixo.
Figura 4: Gráfico do Resultado do Mapeamento.

18. Processo Resultados
Esperados
Atende Não
Atende
Atende
Parcial
Gerência de Projetos (GPR) 17 10 1 6
Gerência de Requisitos (GRE) 5 3 1 1
Gerência de Configuração (GCO) 7 5 2 0
Garantia da Qualidade (GQA) 4 2 0 2
Medição (MED) 7 4 0 3
Quadro 9: Resumo dos resultados esperados com a distribuição nos critérios pré-
estabelecido.
No quadro 9, demostra o resumo do mapeamento dos resultados esperados do
MPSBR com as praticas da FDD em relação aos critérios de classificar, assim fica
transparente a real contribuição da FDD, expondo a forma com que as práticas se
relacionam com o com MPS.BR
7. Conclusões
Este artigo realizou, como alvo principal, o Mapeamento dos resultados esperados entre
o modelo MPS.BR apenas nos níveis G e F com a FDD, a qual possui as práticas e
tarefas similares, a FDD não cobre todas as atividades em total compatibilidade que é
exigida pela norma brasileira. Por esse motivo, a metodologia FDD vem ajudar e não
substituir as atividades esperadas pelo programa brasileiro.
Esta pesquisa analisou, em síntese, o conceito das normas já existentes no
mercado mundial, o CMMI e as ISO’s 12207 e 15504, no intuito de demonstrar a base
que é constituída o modelo MPS.BR, tornando-o aceitável no mercado brasileiro.
Conhecido como metodologia tradicional, também demonstrou o surgimento do
manifesto ágil em 2001 nos EUA, que, entre as metodologias ágeis, são abordadas as
características e práticas de engenharia de software da FDD que estimula agilidade da
produção com qualidade.
Na última seção deste artigo, foi demonstrado o mapeamento do MSPBR com a
FDD, onde ele é passível de interpretações. O trabalho proposto vem apresentar, em
forma de porcentagens, o quanto a FDD há de ajudar nas tarefas requeridas, e sim,
demonstrar que existe uma alternativa viável para agilizar as atividades. Essa agilidade é
conseguida com várias das boas práticas que a FDD disponibiliza, são elas: modelo
ARO, papéis-chaves, dono do código FBS, Inspeções, builds regulares, demonstrável
para o cliente, utilização da UML em cores e outras.

19. Referências
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO “Guia Geral”, 2009. Disponível <http://www.softex.br/mpsbr/_guias
/guias/MPS.BR_Guia_Geral_2011.pdf >.Acessado em 21 de abril de 2011, 2011a.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO “Guia de Implementação – Parte 1: Fundamentação para
Implementação do Nível G do MR-MPS”, 2009. Disponível <http://www.softex.br
/mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_1_2011.pdf >.Acessado
em Julho de 2011 de 2010, 2011b.
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO “Guia de Implementação – Parte 2: Fundamentação para
Implementação do Nível F do MR-MPS”, 2009. Disponível <http://www.softex.br
/mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_2_2011.pdf>.Acessado
em 25 de Julho de 2011, 2011c.
AGILCOOP, Cooperativa de Desenvolvimento Ágil de Software, “Empresas Ágeis no
Brasil”. 2011. Disponível em < http://ccsl.ime.usp.br/agilcoop/empresas_ageis >
Acessado em: 23/08/2011
BECK, K at all. “Manifesto para Desenvolvimento Ágil de Software”.2001.
Disponível em: < http://agilemanifesto. org/iso/ptbr/.> Acesso em: 09/08/2011.
BUBLITZ, Jorge Luiz “FDD - Feature-Driven Development - Desenvolvimento ágil
dirigido a funcionalidades”,2011, Disponível em <http://www.slideshare.net/brjedi
/aula-fdd-cesar-recife-gap > Acessado em: 09 Out. 2011
COAD, Peter; LEFEBVRE, Eric.; LUCA , Jeff de “Java Modeling In Color With
UML: Enterprise” Components and Process. Prentice Hall, 1999
FERREIRA, Adson Wendel Cirilo. “Melhoria de processo de software brasileiro
aplicado no nível de maturidade f em uma empresa alagoana desenvolvedora de
software”.Disponível em <http://www.slideshare.net/adsonwendel/melhoria-de-
processo-de-software-brasileiro-aplicado-no-nvel-de-maturidade-f-em-uma-empresa-
alagoana-desenvolvedora-de-software-8534557> Acessado em: 12 junho 2010.
LUCA, Jeff de “The Original FDD Processes”.1998, Disponível em
<http://www.nebulon. com/articles/fdd/originalfdd.html>. Acesso em 05 Mai. 2011.
GUSMÃO, Cristine Gomes de; MOURA, Hermano Perrelli. Gerência de Risco em
Processos de Qualidade de Software: Uma análise Comparativa. 2004. P.6

20. Disponível em <http://www.cefetrn.br/~placido/disciplina/pgp/material/sbqs05_
Gusmao.pdf>Acessado em: 19 de Mar 2010
MEDEIROS, Manoel Pimentel. “FDD - O ponto de Equilíbrio Ágil ”. In Artigo Java
Magazine 76, Para projetos de desenvolvimento de software em ambientes corporativos
complexos, 2011 Disponível em < http://www.devmedia.com.br/post-15854-FDD-O-
ponto-de-Equilibrio-Agil.html> Acessado em: 09 Out. 2011
PÊSSOA, Marcelo Schneck de Paula. Modelo Integrado de Maturidade da
Capacidade de Processo. Lavras: UFLA/FAEPE, 2005.
RETAMAL, Adail Muniz “Feature-Driven Development - Descrição dos Processos”,
2008, Dispoível em < http://www.heptagon.com.br/files/FDD-Processos.pdf > Acessado
em: 09 Out. 2011. 2008a
RETAMAL, Adail Muniz “Metodologias de Desenvolvimento: UDP, FDD e XP”,
2008, Disponível em <http://adailmr.sites.uol.com.br/artigos/fdd-udp-xp.htm> Acessado
em: 09 Out. 2011. 2008b
REZENDE, Denis Alcides. Engenharia de Software e sistemas de informação. 2. ed.
Rio de Janeiro: Brasport, 2002.
SOARES, Michel dos Santos. “Comparação entre Metodologias Ágeis e
Tradicionais para o Desenvolvimento de Software”.2009. Disponível em <
http://www.inf.ufrgs.br/~dsogari/material/S5/INF01127/Material/Comparacao-Metodos-
Ageis-Tradicionais .pdf> Acessado em: 21 Mai. 2011
WEBER, Kival C.; ROCHA, Ana Regina; ALVES, Ângela; AYALA, Arnaldo M.;
GONÇALVES, Austregésilo; PARET, Benito; SALVIANO, Clênio; MACHADO,
Cristina F.; SCALET, Danilo; PETIT, Djalma; ARAÚJO, Eratóstenes; BARROSO,
Márcio Girão; OLIVEIRA, Kathia;OLIVEIRA, Luiz Carlos A.; AMARAL, Márcio P.;
CAMPELO, Renata Endriss C.; MACIEL,Teresa. Modelo de Referência para
Melhoria de Processo de Software: uma abordagem brasileira. Disponível em <
http://pos.facom.ufu.br/~willian/uniube/eng_software/arteng2.pdf.> Acessado em: 20
Jan. 2010, 2004.
Weber, K. C., Rocha, A. R., Alves, A., Ayala, A. M., Gonçalves, A., Paret, P., Salviano,
C., Machado, C. F., Scalet, D., Petit, D., Araújo, E., Barroso, M. G., Oliveira, K.,
Oliveira, L. C.A., Amaral, M. P., Campelo, R. E. C., Maciel, T. “Modelo de Referência
para Melhoria de Processo de Software: uma abordagem brasileira”, In: XXX
Conferencia Latinoamericana de Informatica (CLEI 2004). Arequipa, Peru: Septiembre
2004.