235654164 Engenharia de Software Edicao 26

Prévia do material em texto

www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800
E D U C A Ç Ã O S U P E R I O R O R I E N T A D A A O M E R C A D O
PÓS-GRADUAÇÃO
Engenharia de Software: 
Desenvolvimento Java
Engenharia de Software: 
Desenvolvimento .NET
GRADUAÇÃO
Engenharia de Computação
Análise e Desenv. de Sistemas
FORMAÇÕES
Desenvolvedor Java
Desenv. Java: Sist. Distribuídos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator 
SQL Server 2008
Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti
A Escola Superior da Tecnologia da 
Informação oferece as melhores 
opções em cursos, formações, 
graduações e pós-graduações para 
profissionais de desenvolvimento 
e programação. 
São programas voltados para a 
formação de profissionais de elite, 
com aulas 100% práticas, corpo 
docente atuante no mercado, 
acesso à mais atualizada biblioteca 
de TI do Rio, laboratórios equipados 
com tecnologia de ponta, salas de 
estudo e exames.
r/esti
TURMAS
NO RIO DE
JANEIRO
Modéstia à parte, sua
melhor opção para
se destacar no mercado!
Corpo Editorial 
Colaboradores
Rodrigo Oliveira Spínola
rodrigo@sqlmagazine.com.br
Marco Antônio Pereira Araújo
Eduardo Oliveira Spínola
Capa e Diagramação
Romulo Araujo - romulo@devmedia.com.br
Coordenação Geral
Daniella Costa - daniella@devmedia.com.br
Revisor e Supervisor
Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br
Na Web
www.devmedia.com.br/esmag
Ano 3 - 26ª Edição - 2010 Impresso no Brasil
A
o final dos anos 90, como reação às formas tradicionais de desenvolvimento de 
software, que baseado em estudos realizados pela indústria e academia foi apon-
tada como a principal responsável por falhas encontradas em projetos de softwa-
re, acompanhamos o surgimento de várias metodologias ágeis, como: Adaptive Software 
Development, Crystal, Dynamic Systems Development, eXtreme Programming (XP), Featu-
re Driven Development (FDD) e Scrum.
Neste sentido, organizações que procuram melhoria em seus processos de produção 
através de modelos e frameworks como Capabitity Model Integration (CMMI), Control 
Objectives for Information and related Technology (COBIT), Information Technology In-
frastructure Library (ITIL), entre outros, agora também acreditam que introduzir conceitos 
ágeis em seus processos de desenvolvimento, buscando um equilíbrio entre agilidade e 
maturidade, é uma alternativa capaz de promover a melhoria da qualidade dos seus pro-
dutos e, consequentemente, aumento da competitividade no mercado.
Segundo o Softex, alcançar competitividade pela qualidade para as empresas de softwa-
re implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, 
como dos processos de produção e distribuição de software. Desta forma, assim como 
para outros setores, qualidade é fator crítico de sucesso para a indústria de software.
O desenvolvimento ágil e os modelos e padrões de qualidade de software tradicionais 
são vistos frequentemente como contraditórios, pois se tem o raciocínio que os modelos 
são muito burocráticos, enquanto que o desenvolvimento ágil é ad-hoc. Na verdade exis-
tem desafios na integração entre os dois, embora o esforço possa valer a pena, pois ao final 
pode-se obter qualidade no produto através da união de maturidade e agilidade.
Neste contexto, a Engenharia de Software Magazine destaca nesta edição a matéria “ 
Extensão do Scrum segundo o MPS.BR nível G” cujo o objetivo é propor uma estratégia para 
extensão do Scrum segundo as áreas de processo do guia MPS.BR nível G. Este estudo se 
inicia com o mapeamento entre o Scrum e o MPS.BR através de uma avaliação dos resultados 
esperados do guia segundo as práticas do Scrum. A partir deste mapeamento, uma extensão 
do Scrum é realizada através da adição de práticas complementares para satisfazer o guia. Ao 
final, é gerado um novo processo de desenvolvimento para uma fábrica de software.
Além desta matéria, esta edição traz mais cinco artigos:
• Lidando com o risco nas corporações
• Extração de métricas em software orientado a objetos
• Análise de dependências entre práticas específicas do nível 2 do CMMI
• Integração das ferramentas Trac e Subversion
• Auditoria de Sistemas Baseada em Riscos
Desejamos uma ótima leitura!
Equipe Editorial Engenharia de Software Magazine
Rodrigo Oliveira Spínola 
rodrigo@sqlmagazine.com.br
Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em 
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computação 
(UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), tendo minis-
trado cursos na área de Qualidade de Produtos e Processos de Software, Requisitos e 
Desenvolvimento Orientado a Objetos. Consultor para implementação do MPS.BR. Atua 
como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/
UFRJ. É Colaborador da Engenharia de Software Magazine.
Marco Antônio Pereira Araújo - Editor
(maraujo@devmedia.com.br)
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-
nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos 
Computacionais e Bacharel em Matemática com Habilitação em Informática pela 
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação 
do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em 
Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor do Cur-
so Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Fundação 
Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, 
Colaborador da Engenharia de Software Magazine.
Eduardo Oliveira Spínola
(eduspinola@gmail.com) 
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Ma-
gazine. É bacharel em Ciências da Computação pela Universidade Salvador (UNIFACS) 
onde atualmente cursa o mestrado em Sistemas e Computação na linha de Engenharia 
de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicações).
Apoio
Atendimento ao Leitor
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. 
Se você tiver algum problema no recebimento do seu exemplar ou precisar de 
algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de 
bancas de jornal, entre outros, entre em contato com:
Cristiany Queiróz– Atendimento ao Leitor
www.devmedia.com.br/mancad
(21) 2220-5338
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5338
Publicidade
Para informações sobre veiculação de anúncio na revista ou no site entre em 
contato com:
Kaline Dolabella
publicidade@devmedia.com.br
Fale com o Editor! 
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo 
você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a 
vontade para entrar em contato com os editores e dar a sua sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine, 
entre em contato com os editores, informando o título e mini-resumo do tema que você 
gostaria de publicar:
Rodrigo Oliveira Spínola - Colaborador
editor@sqlmagazine.com.br
EDITORIAL
 ÍNDICE
Por trás do obvio
06 - Lidando com o risco nas corporações
Glênio Cabral
Agilidade
 07 - Extensão do Scrum segundo o MPS.BR nível G
Fernando Szimanski, Jones Oliveira de Albuquerque e Felipe Furtado 
Engenharia
15 - Extração de métricas em software orientado a objetos
Bruno Góis Borges 
35 - Análise de dependências entre práticas específicas do nível 2 do CMMI 
Thiago Salhab Alves e Paulo C. Barreto da Silva 
Desenvolvimento41 - Integração das ferramentas Trac e Subversion
Daves Marcio Silva Martins, Tadeu Moreira de Classe, Eduardo Leandro Pinto Dornelas e Guilherme de Jorge Palmeira
Tipo: Processo 
Título: Introdução a Modelos de Ciclo de Vida – Parte 1 
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Perceber que atividades fazem parte do processo de engenharia de 
software é o primeiro passo para concretizá-lo, mas é também importante perceber 
como as atividades do processo se relacionam umas com as outras para que se torne 
visível todo o processo de desenvolvimento. Neste sentido, o termo modelo de ciclo de 
vida é utilizado para descrever um modelo que visa descrever um grupo de atividades e a 
forma como elas se relacionam. Este é o tema desta série de 3 vídeo aulas. Nesta primeira, 
conheceremos algumas definições sobre modelos de ciclo de vida e conheceremos o ciclo 
de vida em cascata atentando para suas vantagens e desvantagens.
Tipo: Processo 
Título: Introdução a Modelos de Ciclo de Vida – Parte 2 
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Perceber que atividades fazem parte do processo de engenharia de 
software é o primeiro passo para concretizá-lo, mas é também importante perceber 
como as atividades do processo se relacionam umas com as outras para que se torne 
visível todo o processo de desenvolvimento. Neste sentido, o termo modelo de ciclo de 
vida é utilizado para descrever um modelo que visa descrever um grupo de atividades 
e a forma como elas se relacionam. Este é o tema desta série de 3 vídeo aulas. Nesta 
segunda aula, conheceremos os modelos de ciclo de vida em V e o interativo.
Tipo: Processo 
Título: Introdução a Modelos de Ciclo de Vida – Parte 3
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Perceber que atividades fazem parte do processo de engenharia de 
software é o primeiro passo para concretizá-lo, mas é também importante perceber 
como as atividades do processo se relacionam umas com as outras para que se torne 
visível todo o processo de desenvolvimento. Neste sentido, o termo modelo de ciclo 
de vida é utilizado para descrever um modelo que visa descrever um grupo de 
atividades e a forma como elas se relacionam. Este é o tema desta série de 3 vídeo 
aulas. Nesta terceira parte, conheceremos os modelos de ciclo de vida evolutivo, 
RAD, prototipação e espiral.
Tipo: Processo 
Título: Atividades do Desenvolvimento de Software – Parte 1 
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Esta vídeo aula apresenta algumas das principais atividades execu-
tadas ao longo do desenvolvimento de projetos de software. Nesta primeira parte 
conheceremos as atividades: elicitação de requisitos, análise de requisitos, projeto 
de arquitetura do sistema e projeto de software.
Tipo: Processo 
Título: Atividades do Desenvolvimento de Software – Parte 2 
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Esta vídeo aula apresenta algumas das principais atividades executadas 
ao longo do desenvolvimento de projetos de software. Nesta segunda parte conhe-
ceremos as atividades: implementação do software, integração de software, teste de 
software, integração de sistema, teste de sistema e implantação do software.
4 Engenharia de Software Magazine 
Caro Leitor, Para esta edição, temos um conjunto de 5 vídeo aulas. Estas vídeo aulas estão disponíveis para download no Portal da Engenharia de Software Magazine e certamente trarão uma significa-
tiva contribuição para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:
Edição 05 - Engenharia de Software Magazine 5 
6 Engenharia de Software - Lidando com o risco nas corporações
Lidando com o risco nas 
corporações
Pos trás do Óbvio
Alguém já disse que, para morrer, basta estar vivo. Seja quem for que tenha dito isso, afirmou uma grande e fúnebre verdade. Mortos não costumam morrer, porque 
já estão mortos. A eles cabe apenas permanecer em seu estado 
de sono profundo. Apenas os vivos podem um dia dar adeus à 
existência e descansar em paz.
Embora a morte seja o fim do ciclo de vida de todos os seres 
vivos, permanecer vivo é uma obsessão instintiva de todo aquele 
que respira. Por isso desenvolvemos estratégias para prorrogar ao 
máximo o nosso encontro com a morte, identificando e evitando 
os caminhos que podem nos levar mais cedo para o mundo do 
além. Assim, cada vez que vamos ao médico fazer exames de 
rotina, que mudamos a nossa alimentação para uma dieta mais 
saudável e que cuidamos mais de nós mesmos, estamos iden-
tificando e avaliando riscos que podem nos levar a situações 
indesejáveis.
Da mesma forma que para morrer basta estar vivo, o simples 
fato de uma atividade ou rotina existir abre um leque de possibi-
lidades para a ocorrência de eventos prejudiciais ao sucesso. Por 
isso, administrar riscos numa corporação é como fazer exames 
de rotina. O objetivo principal é garantir a sobrevivência. O en-
graçado é que da mesma forma que muitas pessoas não gostam 
de fazer exames preventivos por diversas razões, alguns gestores 
insistem em adotar uma postura incompetente diante dos riscos 
que envolvem suas atividades. Mas o que é ser incompetente na 
administração desses riscos?
Primeiro, é achar que nunca vai adoecer. O maior erro de 
alguém que deseja ter uma vida saudável é pensar que por ter 
uma saúde “inabalável”, nunca irá pegar uma gripe, uma virose 
ou coisa parecida. Ledo engano. Muitas das variáveis internas e 
externas que envolvem nossas organizações são como vírus que 
vivem assediando empresas com sistemas imunológicos fragiliza-
dos pela atitude desleixada e prepotente da auto-suficiência. Por 
isso, estar atendo aos riscos é, antes de mais nada, uma postura 
de humildade.
Glênio Cabral
gleniocabral@yahoo.com.br
É Administrador de Empresas, pós-graduado em Gestão de Pessoas e mú-
sico. Idealizador do site de educação infantil www.novainfancia.com.br.
Segundo, é desconhecer a própria realidade doméstica. 
Há casos de gestores que desconhecem as particularidades 
de seu próprio empreendimento. Informações como riscos 
inerentes ao negócio, riscos que envolvem os fornecedores, 
os consumidores e os concorrentes são essenciais para o bom 
andamento das atividades organizacionais. Uma pessoa que 
não está informada de sua própria condição física corre o 
risco de estar abrigando uma grave enfermidade dentro de 
si, desconhecendo-a por completo. Assim também se dá com 
a corporação que não está devidamente inteirada de suas 
próprias singularidades. 
Terceiro, é arriscar-se em mares proibidos. Uma pessoa que é 
diabética e desconhece isso por não ter o hábito de fazer exames 
periódicos, acaba consumindo alimentos proibidos para o seu 
quadro clínico. Assim também ocorre com uma organização 
que não está atenta aos ambientes micro e macro, e que por isso 
muitas vezes adota estratégias e metas desaconselháveis para a 
sua realidade. 
Alguém já disse que, para morrer, basta estar vivo. Seja quem 
for que tenha dito isso, afirmou uma grande e fúnebre verdade. 
No entanto, muitas pessoas que já não estão mais entre nós, con-
tinuam vivas através das organizações que idealizaram e ajuda-
ram a fundar, e que hoje são referenciais na arte de administrar 
imprevistos. Chegamos então a uma bombástica conclusão: uma 
boa administração de riscos pode gerar uma certa imortalidade. 
Por que não? 
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
D
ê 
se
u Fe
edback
so
b
re esta edição
Edição 26 - Engenharia de Software Magazine 7 
Fernando Szimanski
fernando@criativadsi.com.br
Possui graduação em Processamento de 
Dados (UNOPAR, 2002), Pós-graduação em 
Melhoria em Processo de Software (UFLA, 
2006) e Mestrado emEngenharia de Sofware 
(CESAR.EDU, 2009). Atualmente é professor e 
coordenador de estágio do Centro Universitá-
rio UNIRG e Gerente de Projetos da Criativa 
Tecnologia. Tem experiência na área de Enge-
nharia de Software, com ênfase em Modelos e 
Padrões de Melhoria no Processo de Software, 
Metodologias Ágeis e Gestão de Projetos.
Jones Oliveira de Albuquerque
jones.albuquerque@gmail.com
Possui graduação em Ciência da Computa-
ção (UFPE, 1994), mestrado em Ciências da 
Computação (UFPE, 1997) e doutorado em 
Ciências da Computação (UFMG, 2002). Atu-
almente é Professor Adjunto da Universidade 
Federal Rural de Pernambuco e colaborador 
ad hoc do C.E.S.A.R. – Centro de Estudos e Sis-
temas Avançados do Recife. Tem experiência 
na área de Ciência da Computação, foi diretor 
de empresa e atua na área de Engenharia de 
Software e Modelagem Matemática, atuando 
principalmente nas seguintes linhas: enge-
nharia de software, processo de software, 
qualidade de software, matemática com-
putacional, epidemiologia computacional e 
modelagem de sistemas.
Felipe Furtado
felipe.furtado@cesar.org.br
É graduado em Engenharia Mecânica pela UFPE, 
especialista em Tecnologias da Informação pelo 
Centro de Informática da UFPE e mestre em Ci-
ência da Computação na área de produtividade 
de software também pela UFPE. Com 14 anos 
na área de desenvolvimento de software, atual-
mente é doutorando e coordenador da garantia 
da qualidade de software e do SEPG (Software 
Engineering Process Group) no C.E.S.A.R. É Scrum 
Master desde 2007 e possui experiência na defi-
nição e implantação de processos aderentes ao 
CMMI e em avaliações SCAMPI, com participação 
em avaliações Classe A CMMI níveis 2 e 3.
De que se trata o artigo?
Este artigo apresenta a extensão da metodologia ágil 
Scrum para as áreas de processo do MPS.BR nível G 
aplicada em uma pequena fábrica de software.
Para que serve?
A extensão realizada neste trabalho pode contribuir de 
forma relevante para organizações que têm o propósi-
to de adotar práticas ágeis no seu processo de software 
mantendo a compatibilidade com o MPS.BR nível G.
Em que situação o tema é útil?
Introduzir conceitos ágeis em processos de software 
buscando um equilíbrio entre agilidade e maturida-
de é uma alternativa capaz de promover a melhoria 
da qualidade dos produtos e, consequentemente, 
aumento da competitividade no mercado.
Extensão do Scrum segundo o MPS.BR nível G
Implementando agilidade e maturidade em uma fábrica de software
Ao final dos anos 90, como rea-ção às formas tradicionais de desenvolvimento de software, 
que baseado em estudos realizados pela 
indústria e academia [12], foi apontada 
como a principal responsável por falhas 
encontradas em projetos de software, 
acompanhamos o surgimento de várias 
metodologias ágeis, como: Adaptive 
Software Development, Crystal, Dynamic 
Systems Development, eXtreme Program-
ming (XP), Feature Driven Development 
(FDD) e Scrum [4].
As metodologias ágeis são uma coleção 
de diferentes técnicas (ou práticas), que 
utilizam os mesmos valores e princípios 
básicos, tais como ciclos iterativos, en-
trega rápida de software funcionando 
e simplicidade, conforme está definido 
no Manifesto para Desenvolvimento 
Ágil [2]. 
Neste sentido, organizações que pro-
curam melhoria em seus processos de 
Agilidade
Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
8 Engenharia de Software Magazine - Extensão do Scrum segundo o MPS.BR nível G
produção através de modelos e frameworks como Capabitity 
Model Integration (CMMI), Control Objectives for Information and 
related Technology (COBIT), Information Technology Infrastructure 
Library (ITIL), entre outros, agora também acreditam que intro-
duzir conceitos ágeis em seus processos de desenvolvimento, 
buscando um equilíbrio entre agilidade e maturidade, é uma 
alternativa capaz de promover a melhoria da qualidade dos 
seus produtos e, consequentemente, aumento da competitivi-
dade no mercado [9].
Segundo o [Softex 2007], alcançar competitividade pela qua-
lidade para as empresas de software implica tanto na melhoria 
da qualidade dos produtos de software e serviços correlatos, 
como dos processos de produção e distribuição de software. 
Desta forma, assim como para outros setores, qualidade é fator 
crítico de sucesso para a indústria de software.
O desenvolvimento ágil e os modelos e padrões de qualida-
de de software tradicionais são vistos frequentemente como 
contraditórios, pois se tem o raciocínio que os modelos são 
muito burocráticos, enquanto que o desenvolvimento ágil é 
ad-hoc [6]. Na verdade existem desafios na integração entre os 
dois, embora o esforço possa valer a pena, pois ao final pode-se 
obter qualidade no produto através da união de maturidade 
e agilidade.
Nessa direção, [Chin 2004] afirma que, se por um lado o 
excesso de formalidade e estruturação tende a inibir e limitar 
as equipes, por outro, a liberalidade caótica e informal, despro-
vida de processos, pode fazer com que os objetivos do projeto 
nunca sejam atingidos.
Inserido neste contexto, este trabalho tem o objetivo de propor 
uma estratégia para extensão do Scrum segundo as áreas de 
processo do guia MPS.BR nível G. Este estudo se inicia com o 
mapeamento entre o Scrum e o MPS.BR através de uma avalia-
ção dos resultados esperados do guia segundo as práticas do 
Scrum. A partir deste mapeamento, uma extensão do Scrum 
é realizada através da adição de práticas complementares 
para satisfazer o guia. Ao final, é gerado um novo processo de 
desenvolvimento para uma fábrica de software.
O MPS.BR
O MPS.BR tem como objetivo definir um modelo de melhoria 
e avaliação de processo de software, preferencialmente para 
as micro, pequenas e médias empresas, para satisfazer as suas 
necessidades de negócio e também ser reconhecido nacional 
e internacionalmente como um modelo aplicável à indústria 
de software [11].
O Modelo de Referência MR-MPS define sete níveis de matu-
ridade, que são uma combinação entre processos e capacidade 
de processos, tais como: A (Em Otimização); B (Gerenciado 
Quantitativamente); C (Definido); D (Largamente Definido); 
E (Parcialmente Definido); F (Gerenciado); G (Parcialmente 
Gerenciado). Para cada um destes sete níveis de maturidade 
foi atribuído um perfil de processos e de capacidade de pro-
cessos que indicam onde a organização tem que concentrar 
o esforço para melhoria de forma a atender os objetivos de 
negócio [11].
O nível G de maturidade do MPS.BR (Parcialmente Geren-
ciado) é composto pelos processos de Gerência de Projetos e 
Gerência de Requisitos satisfazendo os atributos de processo 
AP 1.1 e AP 2.1.
O processo de Gestão de Projetos (GPR) é composto por 
dezessete resultados esperados e tem o propósito de estabe-
lecer e manter planos que definem as atividades, recursos e 
responsabilidades do projeto, bem como prover informações 
sobre o andamento do projeto que permitam a realização de 
correções quando houver desvios significativos no desempe-
nho do projeto [11].
O processo de Gerência de Requisitos (GRE) é composto por 
cinco resultados esperados. O seu propósito é gerenciar os re-
quisitos do produto e dos componentes do produto do projeto 
e identificar inconsistências entre os requisitos, os planos do 
projeto e os produtos de trabalho do projeto [11].
O Scrum
A metodologia ágil Scrum foi criada em 1996 por Ken Schwaber 
e Jeff Sutherland, e destaca-se das demais metodologias ágeis 
pela maior ênfase dada ao gerenciamento do projeto [10].
Trata-se de uma abordagem empírica focada nas pessoas para 
ambientes em que os requisitos surgem e mudam rapidamente, 
resultando em uma abordagem que reintroduz as ideias de 
flexibilidade, adaptabilidade e produtividade [3]. Ela se ba-
seia em princípios como: equipes pequenas, requisitospouco 
estáveis ou desconhecidos e iterações curtas. As iterações são 
divididas em intervalos de tempos de, no máximo 30 dias, 
também chamadas de Sprints.
Papéis e responsabilidades
O Scrum define para sua estrutura iterativa incremental três 
papéis principais [10]:
• Scrum Master: gerencia o processo, ensinando o Scrum a todos 
os envolvidos no projeto e implementando o Scrum de modo 
que o mesmo esteja adequado à cultura da organização; deve 
garantir que todos sigam as regras e práticas do Scrum; e é 
responsável por remover os impedimentos do projeto [10]. Ele 
é o líder e facilitador entre o Team e o Product Owner;
• Product Owner: é o responsável pelo retorno sobre o investi-
mento (ROI), ou seja, seu foco é na parte comercial do produto. 
Ele é o representante de todos os stakeholders e os representa 
na priorização do Backlog e questões de requisitos. Esta pessoa 
deve estar à disposição da equipe em qualquer momento, mas 
sobretudo durante o Sprint Planning Meeting e Sprint Review 
Meeting [13];
• Team: é um grupo de pessoas com diferentes habilidades 
necessárias para transformar requisitos em um incremento po-
tencialmente “entregável”. Para tanto, geralmente são uma mescla 
de analistas, designers, gerentes de qualidade, desenvolvedores, 
etc. A equipe tem a autoridade de decidir, quando necessário, 
as ações que serão realizadas e priorizá-las organizando-as 
em Sprints. Effort estimation, Sprint Backlog, revisões de product 
Backlog List e sugestões de impedimentos para serem removidos 
do projeto também são atividades do time [13].
Edição 26 - Engenharia de Software Magazine 9 
MEtoDoLoGIAS ÁGEIS
As fases do Scrum
O ciclo de desenvolvimento do Scrum é baseado em três fases 
principais [1], conforme ilustra a Figura 1:
• PRE-GAME: dividida em duas subfases, Planejamento e 
Staging. A subfase Planejamento tem por objetivo estabelecer 
a visão do projeto e expectativas, garantindo recursos para a 
sua execução. A subfase Staging tem por objetivo avaliar as 
várias dimensões do projeto criando itens adicionais ao Product 
Backlog relacionados com o tipo do sistema, time, ambiente de 
desenvolvimento e tipo de aplicação;
• GAME: consiste de múltiplas Sprints para o desenvolvimen-
to dos incrementos de funcionalidades do produto. Onde o 
time analisa a situação atual do produto, avaliando quais 
mudanças devem ser implementadas, procedendo ao final 
com o desenvolvimento através de etapas de análise, projeto, 
implementação, testes e documentação de mudanças;
• POST-GAME: fase de fechamento, que tem por objetivo pre-
parar o produto para o seu lançamento. Isto inclui atividades 
de integração, análise, documentação do usuário, treinamento 
e preparação do material de marketing.
Figura 1. Fases do Scrum
Fluxo do Scrum
Um projeto se inicia com a visão do produto que será desen-
volvido [10], com a lista das características do produto estabe-
lecidas pelo cliente, além de algumas premissas e restrições. 
Em seguida, o Product Backlog é criado contendo a lista de todos 
os requisitos funcionais e não funcionais. O Product Backlog é 
então priorizado pelo Product Owner e dividido em Releases.
No Scrum, são realizadas iterações chamadas de Sprints. Se-
gundo [Schwaber 2008], cada Sprint inicia-se com uma reunião 
de planejamento (Sprint Planning Meeting), na qual o Product 
Owner e o Time decidem em conjunto o que deverá ser imple-
mentado, ou seja, quais unidades de trabalho serão incluídas 
nas iterações de Sprint (Selected Backlog). A reunião é dividida 
em duas partes. Na primeira parte (Sprint Planning 1), o Pro-
duct Owner apresenta os requisitos de maior valor e prioriza 
aqueles que devem ser implementados. O time então define 
colaborativamente o que poderá entrar no desenvolvimento 
da próxima Sprint, considerando sua capacidade de produção. 
Na segunda parte (Sprint Planning 2), o time planeja seu traba-
lho, definindo o Sprint Backlog, que são as tarefas necessárias 
para implementar as funcionalidades selecionadas no Product 
Backlog. Nas primeiras Sprints, é realizada a maioria dos traba-
lhos de arquitetura e de infraestrutura. A lista de tarefas pode 
ser modificada ao longo da Sprint pelo time e as tarefas podem 
variar entre 4 a 16 horas para a sua conclusão.
Na execução das Sprints, diariamente o time faz uma reunião 
de 15 minutos para acompanhar o progresso do trabalho e 
agendar outras reuniões necessárias. Ao final da Sprint, é re-
alizada a reunião de revisão (Sprint Review Meeting) para que 
o time apresente o resultado alcançado na iteração ao Product 
Owner. Neste momento as funcionalidades são inspecionadas 
e adaptações do projeto podem ser realizadas. Em seguida o 
Scrum Master conduz a reunião de retrospectiva (Sprint Retros-
pective Meeting), com o objetivo de melhorar o processo/time 
e/ou produto para a próxima Sprint.
O monitoramento do progresso do projeto é realizado através 
de gráficos de acompanhamento (Burndown Charts). Eles são 
um excelente mecanismo para visualizar a correlação entre a 
quantidade de trabalho a ser realizada (em qualquer ponto) e 
o progresso do time do projeto para reduzir este trabalho [8].
A Figura 2 demonstra detalhadamente o fluxo de desenvol-
vimento do Scrum.
Figura 2. Fluxo do Scrum (Fonte: Adaptação de [7])
Mapeando o Scrum para as áreas de processo do MPS.
BR nível G
Para cada área de processo do MPS.BR nível G foi realizada 
uma análise detalhada entre os resultados esperados do MPS.BR 
e as práticas encontradas no Scrum, classificando cada resultado 
esperado de acordo com os critérios estabelecidos na Tabela 1.
Para avaliar o processo segundo o método de avaliação do 
MPS.BR (MA-MPS), o processo de desenvolvimento da orga-
nização é avaliado baseado em evidências (diretas e indiretas) 
de um conjunto de atividades e tarefas para atingir este pro-
pósito. Portanto, estes aspectos não foram considerados no 
escopo deste trabalho, pois o mapeamento foi realizado com 
10 Engenharia de Software Magazine - Extensão do Scrum segundo o MPS.BR nível G
o objetivo somente de tornar a organização aderente ao guia 
e não para fins de certificação.
Classificação Critério
NS Não Satisfeito Não há evidências da prática na metodologia
PS Parcialmente Satisfeito
Há evidências da prática na metodologia, embora a prática não 
esteja plenamente atendida.
S Satisfeito A prática está totalmente atendida na Metodologia.
tabela 1. Critérios para classificação das áreas de processO
Após a realização da classificação, conforme os critérios acima 
estabelecidos, foram calculados os percentuais de satisfação de 
cada área de processo entre os critérios definidos, tomando como 
base o número total de resultados esperados de cada área.
Para o processo de desenvolvimento de software de uma 
organização estar totalmente aderente ao nível G do MPS.BR, é 
necessário também atender aos atributos de processo AP 1.1 e 
AP 2.1 no que se refere aos resultados esperados RAP1 a RAP8. 
Por essa razão, também foi realizado o mapeamento entre os 
atributos de processo acima relacionados e o novo processo 
de software da empresa em questão.
O mapeamento detalhado apresentando os pontos que o 
Scrum satisfaz ou não os resultados esperados do MPS.BR 
nível G (Gestão de projetos e Gerenciamento de requisitos) 
pode ser encontrado em [15].
Os resumos das análises para os processos de Gestão de 
Projetos (GPR) Gerenciamento de Requisitos (GRE) são apre-
sentados nas Tabelas 2 e 3, respectivamente.
MPS.BR – Nível G SCRUM
Área de Processo Abrev. Objetivos Classificação Resumo das Práticas
Ge
st
ão
 d
e 
Pr
oj
et
os
(G
PR
)
GPR1 Escopo do trabalho Satisfeito Elaboração da Visão do Produto e Definição dos Itens de Backlog (IBL)
GPR2 Dimensionamento de tarefas e produtos de trabalho Parcialmente Satisfeito Estimativas através de StoryPoints
GPR3 Modelo e as fases do ciclo de vida do projeto Satisfeito Iterativo incremental. Fases: Pregame, Game e Postgame
GPR4
Estimativa de esforço e o custo baseado em dados históricos ou 
referências técnicas
Parcialmente Satisfeito
Retorno sobre o Investimento (ROI), Estimativas através de Story Points e 
divisão de IBLs em tarefas
GPR5 O orçamento e o cronograma do projeto Parcialmente Satisfeito Planejamento de Sprints e Estimativas através de Story Points
GPR6 Riscos do projeto Satisfeito Daily Meetings, Impediment Backlog e responsabilidades do Scrum Master
GPR7 Planejamento de recursos humanos Satisfeito
Definição dos Recursos humanos (Time, Product Owner, Scrum Master) 
baseado no perfil
GPR8 Planejamento das tarefas, os recursos e o ambiente de trabalho Satisfeito Itens adicionais ao Product Backlog e Tarefas da Sprint (Task)
GPR9
Planejamento de dados relevantes do projeto
(armazenamento, privacidade e segurança)
Não Satisfeito Prática não mencionada no Scrum
GPR10 Planos para a execução do projeto Satisfeito Visão do Produto, Product Backlog, Sprint Backlog, Sprint planning 1 e 2 e Daily meeting
GPR11 Avaliação de viabilidade de atingir as metas do projeto Satisfeito
Sprint Planning (1 e 2) e Definição do objetivo da iteração na elaboração do 
Sprint Backlog
GPR12 Revisão e compromisso com o Plano do Projeto Satisfeito Sprint Planning (1 e 2) e Daily meeting
GPR13 Monitoramento do progresso do projeto Satisfeito Product Burndown, Sprint Burndown, Daily Review e Retrospective Meeting
GPR14
Gerenciamento do envolvimento das partes interessadas no 
projeto 
Satisfeito Daily Scrum Meeting, Sprint Review Meeting e Sprint Retrospective Meeting
GPR15
Revisões são realizadas em marcos do projeto e conforme 
estabelecido no planejamento
Satisfeito Sprint Review Meeting
GPR16 Identificação e registros de problemas Satisfeito Daily Scrum Meeting e Impediment Backlog
GPR17 Ações para corrigir e prevenir desvios em relação ao planejado Satisfeito Daily Scrum Meeting, Impediment Backlog e Retrospective Meeting
tabela 2. Resumo do mapeamento entre Scrum e a área de GPR
MPS.BR - Nível G SCRUM
Área de Processo Abrev. Objetivos Classificação Resumo das Práticas
Ge
re
nc
ia
m
en
to
 d
e 
Re
qu
is
ito
s 
(G
RE
)
GRE1 Entendimento dos requisitos Satisfeito Visão do produto, Definição de itens de Backlog e Elaboração das tarefas da Sprint
GRE2 Aprovação de requisitos Satisfeito
Aprovação de requisitos através do Business Value (BV), Priorização de requisitos (ROI) e 
Sprint Planning (1 e 2)
GRE3
A rastreabilidade bidirecional entre os 
requisitos e os produtos de trabalho
Não Satisfeito Prática não mencionada no Scrum
GRE4
Revisões em planos e produtos de trabalho 
do projeto
Satisfeito Daily Scrum Meeting e Sprint Review Meeting 
GRE5 Gerenciamento de mudanças nos requisitos Satisfeito Sprint Planning (1 e 2), Daily Scrum Meeting e Sprint Review Meeting
tabela 3. Resumo do mapeamento entre Scrum e a área GRE
Edição 26 - Engenharia de Software Magazine 11 
MEtoDoLoGIAS ÁGEIS
Resultado do mapeamento
Este comparativo entre o Scrum e as áreas de processo do 
MPS.BR nível G teve por objetivo mapear o alinhamento e a 
conformidade entre eles. A partir deste mapeamento desco-
brimos que o Scrum não satisfaz totalmente o nível G do MPS.
BR, conforme apresentado na Figura 3.
0%
20%
40%
60%
80%
Satisfeito 76% 80%
Parcialmente
Satisfeito
18% 0%
Não Satisfeito 6% 20%
GPR GRE
Figura 3. Resultado Geral da Avaliação
Este resultado se deve a alguns fatores, tais como:
• Lacunas na definição de um método apropriado de comple-
xidade ou tamanho para estimativas, impactando diretamen-
te no resultado esperado GPR2 e indiretamente no GPR5;
• Ausência de utilização de dados históricos organizacionais 
ou referências técnicas para definição de esforço e custo de 
um projeto, afetando o resultado esperado GPR4;
• Ausência de definição de privacidade e segurança no aces-
so às informações do projeto, comprometendo totalmente o 
GPR9;
• Ausência de rastreabilidade entre os requisitos e produtos 
de trabalho, afetando diretamente o GRE3.
Portanto, para implementação de um processo aderente 
às práticas definidas nas áreas de processo do nível G do 
MPS.BR, foi necessário complementar o Scrum com práticas 
adicionais conforme visto na próxima seção.
Estendendo o Scrum para o MPS.BR nível G
Baseado no resultado geral do comparativo entre o Scrum 
e as áreas de processo do MPS.BR nível G, para as lacunas 
encontradas (itens “Parcialmente Satisfeito” e “Não satisfei-
to”), soluções complementares foram adicionadas ao processo, 
conforme descrição abaixo.
GAP1 – Lacunas na definição de um método apropriado de 
complexidade ou tamanho para as tarefas e os produtos de 
trabalho do projeto, impactando diretamente o GPR2.
Para realização da estimativa das tarefas foi indicado o uso 
da técnica Story Points com Planning Poker.
A ideia do Planning Poker [Mountain Goat Software 2008] 
é pontuar os itens de Backlog, onde cada membro da equipe 
possui um conjunto de cartas numeradas com a sequência 
de Fibonacci. Inicialmente escolhe-se a funcionalidade de 
menor complexidade e atribui a ela a pontuação 2 (dois) para 
servir como referência. A partir deste item de backlog são 
realizadas estimativas relativas para os demais itens. Caso 
haja divergências entre as cartas mostradas, as pessoas que 
atribuíram o menor e o maior valor explicam o motivo que 
os levaram a tal estimativa. É importante que o Scrum Master 
esteja envolvido como mediador para gerenciar conflitos.
GAP2 – Ausência de estimativa do esforço e o custo para a 
execução das tarefas e dos produtos de trabalho com base em 
dados históricos ou referências técnicas.
O Scrum não menciona a utilização de dados históricos 
organizacionais, ou seja, ele somente define a utilização de 
dados de Sprints anteriores para o mesmo projeto. Portanto, 
para definição dos custos e esforço serão analisados dados 
históricos organizacionais mantidos através de um documen-
to que contempla informações de projetos anteriores.
GAP3 – Ausência de definição do orçamento.
Para definição do orçamento será utilizada a política de 
negociação da empresa em questão. Este documento fornece 
orientações sobre os procedimentos a serem observados na 
negociação dos projetos de software da empresa no tocante às 
regras em relação às pessoas, condutas, vedações, divulgação 
de informações e violações.
GAP4 – Ausência de privacidade e segurança no acesso às 
informações.
A proposta é armazenar as informações coletadas no projeto 
utilizando a política de segurança, acesso e armazenamento 
das informações de projetos. Este documento define a estra-
tégia para implementação nos projetos da empresa no que se 
refere à infraestrutura (confiabilidade, segurança e estabilida-
de) e nível operacional (níveis de usuários, responsabilidades, 
limites e controle de versões).
GAP5 – Ausência de rastreabilidade entre os requisitos e 
produtos de trabalho.
Para a rastreabilidade vertical cada item de Backlog (IBL) será 
inicialmente identificado, então, na criação do Sprint Backlog 
cada tarefa estará associada a um IBL e os artefatos de enge-
nharia estarão associados ao IBL correspondente. Portanto, a 
rastreabilidade vertical pode ser distribuída em cada artefato 
gerado, como por exemplo, o código implementado.
Adaptando a extensão no processo de uma Fábrica 
de Software
Para validação deste trabalho, foi implementada a extensão 
proposta na CRIATIVA Tecnologia, que é uma empresa de 
tecnologia que cria produtos e serviços utilizando Tecno-
logia da Informação (TI). Atualmente a empresa conta com 
cerca de trinta colaboradores, atendendo diversos clientes e 
atuando em três áreas de negócio: fábricade software, trei-
namentos e prestação de serviços técnicos em equipamentos 
eletrônicos.
12 Engenharia de Software Magazine - Extensão do Scrum segundo o MPS.BR nível G
Histórico de melhoria de processos da CRIATIVA
Os trabalhos em melhoria de processo de software na CRIA-
TIVA iniciaram cerca de três anos após a sua fundação (2003), 
onde após um crescimento significativo de sua base de clientes, a 
empresa começou a apresentar diversos problemas relacionados 
ao processo de produção de software. Baseado neste contexto, 
foi realizada a modelagem de um processo de desenvolvimento 
baseado no guia MPS.BR nível G [14], onde no período inicial 
pode-se notar melhorias. Entretanto, após alguns meses de uti-
lização, alguns fatores impactaram negativamente na empresa 
em relação ao processo que foi definido, tais como: dificuldade 
em seguir o processo, produção de artefatos desnecessários, 
desmotivação dos colaboradores, entre outros.
Em seguida foi proposto o desenvolvimento de um novo 
processo de software que proporcionasse maturidade para a 
organização e que ao mesmo tempo tivesse seu foco nos prin-
cípios do manifesto ágil.
O novo processo de software da CRIATIVA Tecnologia
A partir de uma perspectiva de gerenciamento e baseado no 
ciclo de desenvolvimento iterativo e incremental definido por 
[10] para o framework Scrum, chegou-se a um processo com-
posto por três fases: Pregame, Game e Postgame, apoiadas por 
atividades de Monitoramento e Controle, conforme ilustrado 
na Figura 4.
Figura 4. Processo de Software Macro da CRIATIVA Tecnologia
Com o objetivo de proporcionar o entendimento para os 
colaboradores da empresa em questão, para todas as fases 
deste novo processo foram descritas suas etapas, objetivos, 
conceitos chave e quadros de estruturação de cada atividade 
com seus respectivos papéis, entradas, saídas e artefatos.
Fase PREGAME: Esta fase tem como objetivos delimitar o 
escopo do projeto, verificar a viabilidade econômica e elimi-
nar riscos a partir de uma arquitetura estável. A mesma foi 
dividida em duas subfases: Planning e Staging, o seu fluxo de 
atividades é apresentado na Figura 5. 
Conceitos chave da subfase Planning
Esta é uma fase inicial que tem seu início através da criação 
da Visão do Produto, acessível por todos e de responsabilidade 
do Product Owner.
O Product Backlog é outro artefato de responsabilidade do 
Product Owner (PO), mas também é atualizado pelo time, em 
comum acordo com o PO. Pode conter requisitos funcionais 
e não funcionais.
Conceitos chave da subfase Staging
Esta subfase é uma continuação da subfase inicial Planning, mas 
com o foco voltado à definição de algumas atividades, como: 
organização da infraestrutura para desenvolvimento do projeto, 
definição da arquitetura, definição do plano de comunicação, 
elaboração do Release Plan e realização da reunião de kick-off.
Fase GAME: esta fase (Figura 6) tem como objetivo criar 
releases do produto podendo obter versões funcionais do sof-
tware. Nesta direção, o time realiza algumas atividades como: 
dividir os Itens de Backlog (IBL) que foram selecionados para a 
Sprint em tarefas, realizar estimativas, priorizar e analisar a 
viabilidade dos IBLs. Durante as reuniões diárias, as tarefas 
são selecionadas por cada membro do time. Desta forma, 
espera-se que o compromisso da equipe seja obtido e todos 
sigam para o desenvolvimento de uma parte do produto com 
base na arquitetura definida, enfatizando o gerenciamento de 
custos, recursos e qualidade. 
Conceitos chave da fase Game
Esta fase se inicia com as reuniões da Sprint que são divididas 
em dois níveis, Sprint Planning 1 e Sprint Planning 2. A Sprint 
Planning 1 é uma reunião que tem por objetivo a verificação 
de dados históricos organizacionais, priorização de IBL da 
Sprint, seleção dos IBLs que irão compor a Sprint e elaboração 
da Sprint Backlog. A Sprint Planning 2 é a segunda reunião de 
planejamento com participação do time e do Scrum Master 
para realização de atividades como: definição de tarefas (Task) 
necessárias para realização da Sprint, divisão das tarefas da 
Sprint entre a equipe, análise da capacidade produtiva da 
equipe e atualização do Task Board.
Ao final das Sprint Planning 1 e 2, a obtenção de compro-
misso e revisões no planejamento foram realizadas por 
todos os envolvidos. A partir disso é executada a Sprint, que 
consiste no desenvolvimento das tarefas definidas para cada 
IBL, com o objetivo de obter um produto potencialmente 
entregável.
Figura 5. Fase PREGAME
Edição 26 - Engenharia de Software Magazine 13 
MEtoDoLoGIAS ÁGEIS
Durante a execução da Sprint é realizada a atividade Daily 
Scrum, que é uma reunião diária onde o time monitora o 
progresso da execução das atividades e procura identificar 
os impedimentos encontrados.
Posteriormente, o Scrum Master trabalha no sentido de 
elaborar ações para resolver tais impedimentos e dissemi-
nar a solução para o time. Atualizações na Sprint Backlog e 
Product Backlog são realizadas para controlar o progresso 
das Sprints.
Fase POSTGAME: esta fase (Figura 7) tem como objetivos 
apresentar o produto ao cliente para validação, realizar uma 
reunião para melhoria do processo e avaliar a capacidade 
produtiva do time.
Conceitos chave da fase POSTGAME 
A reunião de revisão da Sprint, chamada de Sprint Review 
Meeting, fornece algumas visões para todos os envolvidos, 
tais como: visibilidade se a meta da Sprint foi alcançada, 
apresentação de resultados, inspeção de funcionalidades para 
possíveis mudanças e adaptações, e a reunião de retrospectiva 
(Sprint Retrospective Meeting).
Ao final desta fase, caso haja nova Sprint, ou seja, caso 
ainda exista a necessidade de serem desenvolvidas outras 
funcionalidades, novos ciclos são realizados iniciando-se 
pela fase GAME.
Ao final, informações coletadas no projeto são armazenadas 
para utilização em projetos futuros formando a base de dados 
de histórico organizacional.
Estudo de Caso
Visando avaliar os efeitos da aplicação da extensão proposta 
neste artigo, foi realizado o estudo de caso na empresa em 
questão em projetos de software selecionados com base na 
semelhança das características de domínio, escopo, arquite-
tura, tempo, custo e equipe.
A definição das métricas para realização de um compa-
rativo entre o processo de software anterior e o novo pro-
cesso foi baseada nos fatores que mais estavam impactando 
Figura 6. Fase GAME
negativamente nos projetos, como entregas no prazo, satis-
fação do cliente e quantidade de bugs.
Figura 7. Fase POSTGAME
Como resultado da avaliação da métrica entregas no prazo, 
foi possível observar que, apesar do time não ter conseguido 
completar 100% das tarefas que foram atribuídas à iteração, 
pode-se observar um aumento de 42,5% de entregas no 
prazo.
Para medir a satisfação dos clientes, foi aplicado um ques-
tionário em relação a diversos aspectos, entre eles: comunica-
ção, qualidade do produto, gerenciamento de mudanças, en-
tregas no prazo, dentre outros. Para avaliar o processo foram 
utilizados três indicadores (“Atende Totalmente”, “Atende 
Parcialmente” e “Não atende”), sendo que para cada questão, 
o questionário disponibilizou orientações de como ela deveria 
ser avaliada. Foi possível observar que o projeto que utilizou 
o novo processo de desenvolvimento obteve aumento de 
57,14% das respostas “atendem totalmente” no questionário, 
proporcionando uma grande redução nos valores para as 
respostas que atendem parcialmente (46,39%) e manutenção 
da ausência de respostas que não atendem o cliente.
Para medir a quantidade de Bugs, foram coletados os dados 
na ferramenta Bug Tracker da empresa, e pôde-se observar que 
o Projeto que utilizou o novo processo teve um número menor 
de Bugs que o processo anterior (equivalente a 75%).
Através dasmétricas apresentadas anteriormente, pode-se 
observar que há indícios de sucesso no uso conjunto do modelo 
de maturidade MPS.BR com a metodologia ágil Scrum.
Alguns aspectos nos projetos que utilizaram o novo processo 
podem ser ressaltados:
14 Engenharia de Software Magazine - Extensão do Scrum segundo o MPS.BR nível G
• O quadro de tarefas (Taskboard) proporcionou uma grande 
visibilidade do andamento das tarefas;
• A participação da equipe nas decisões do projeto proporcio-
nou comprometimento e motivação na realização das tarefas 
diárias;
• Através das reuniões diárias pôde-se monitorar a produção do 
time, promover feedback e remover impedimentos que poderiam 
atrasar o bom andamento do desenvolvimento da Sprint.
A medição de entregas no prazo proporcionou a visibilidade 
da performance da empresa no cumprimento dos prazos esta-
belecidos, aumentando a eficiência em projetos futuros devido 
ao ajuste realizado na capacidade de produção do time (Velocity) 
a cada novo ciclo iterativo do novo processo (Sprint).
A satisfação dos clientes é uma forma de identificar a qualidade 
do software que foi produzido, que por sua vez é auxiliada por 
um processo de desenvolvimento eficaz.
Ao identificar a satisfação dos clientes da empresa em questão, 
observa-se que após a implementação deste novo processo, eles 
estão apresentando um nível mais alto de satisfação comparado ao 
processo anterior, o que significa que a CRIATIVA obteve efeitos 
positivos no seu novo processo de desenvolvimento. No entanto, 
podem-se observar situações onde a empresa deve melhorar 
ainda mais a qualidade dos serviços prestados, tais como:
• Melhoria na qualidade do produto: Apesar da diminuição na 
quantidade de bugs na fase de desenvolvimento, durante os testes 
de aceitação foram registradas solicitações de mudanças;
• Cumprimento dos prazos: Apesar de ter melhorado a taxa de 
entrega, ainda pode ser observado falha no cumprimento dos 
prazos acordados.
A medição da quantidade de bugs na ferramenta Bug Tracker 
proporcionou grande visibilidade e acompanhamento da solução 
dos mesmos ao final de cada iteração dos projetos. Devido à par-
ticipação constante do Scrum Master, proximidade dos membros 
do time e colaboração do cliente, o número de bugs diminuiu 
consideravelmente.
Conclusão
Este trabalho apresentou a extensão do framework Scrum para 
as áreas de processo de Gestão de Projetos e Gerenciamento de 
Requisitos contempladas no MPS.BR nível G.
No mapeamento entre o Scrum e o guia MPS.BR nível G, desco-
briu-se que ele não cobre totalmente os resultados esperados do 
guia, mas pode ser um ponto de partida, pois proporciona uma 
base fundamental para empresas que estão iniciando a melhoria 
de processos, principalmente as que dispõem de poucos recursos 
como as micro e pequenas empresas.
Visto que após o mapeamento ainda restaram alguns resultados 
esperados do MPS.BR não cobertos plenamente pelas práticas do 
Scrum, outras alternativas foram pesquisadas e relacionadas na 
extensão proposta neste projeto para adaptação do processo de 
uma fábrica de software.
A extensão relacionada ao gerenciamento de requisitos atra-
vés de abordagens ágeis foi uma forma alternativa e eficaz de 
gerenciar requisitos e solicitações de mudanças durante o desen-
volvimento do projeto, evitando o retrabalho.
A extensão relacionada à gestão ágil de projetos foi uma alterna-
tiva capaz de gerar inovação, diminuição do tempo de entrega dos 
projetos, desenvolvimento de produtos de trabalho que agregam 
valor real para o cliente e resultados para a empresa.
O novo processo proposto demonstrou um avanço inicial no 
sucesso de um projeto de software desenvolvido pela empresa, 
mas como se encontra ainda em fase de implantação, o monito-
ramento se faz necessário para obtenção da melhoria contínua e 
obtenção de melhores resultados. 
Dê seu feedback sobre esta edição!
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
Para isso, precisamos saber o que você, leitor, acha da revista!
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
D
ê 
se
u Fe
edback
so
b
re esta edição
1. Adm, Advanced Development Methods. (2003). Scrum Methodology – Incremental, Iterative 
Software. Development from Agile Processes.
2. Beck, K., et al. (2001). “Manifesto for Agile Software Development.” Manifesto for Agile Software 
Development. http://www.agilemanifesto.org (acesso em 22 de Março de 2008).
3. Beedle, M., and Schawaber, K. (2002). Agile Software Development With Scrum. New Jersey, Books.
4. Boehm, B. (2006). “A View of 20th and 21st Century Software Engineering.” ICSE06. Shanghai, 
China, ACM.
5. Chin, G. (2004). Agile Project Management: How to Succeed in the Face of Changing Project 
Requirements. New York, Amacon.
6. Davis, C, et al. (2004). An Agile Approach to Achieving CMMI. http://www.agiletek.com/images/
AgileTek/pdf/an_agile_approach_to_achieving_cmmi.pdf (acesso em 27 de Dezembro de 2008).
7. Gloger, B. (2008) “Scrum Glossary - Sprint It.” Sprint It. http://sprint-runner.com (acesso em 15 de 
Junho de 2008).
8. Marçal, A. S. (2007). Estendendo o SCRUM segundo as Áreas de Processo de Gerenciamento de 
Projetos do CMMI. Recife.
9. Playfair, K (2008). “When ‘General Agile’ Isn’t Enough - Why Scrum Wins in the Enterprise.” Agile 
Journal. http://www.agilejournal.com/content/view/808/111/ (acesso em 29 de Dezembro de 2008).
10. Schwaber, K. (2008). Agile Project Management With Scrum. Redmond, Microsoft Press.
11. Softex. MPS.BR (2007), Melhoria de Processo de Software Brasileiro - Guia Geral V1.2. Rio de 
Janeiro, Softex.
12. Standish, The Standish Group International. (2004).. “The Chaos Report.” Standish Group. secure.
standishgroup.com/reports/reports.php?rid=500.
13. Szalvay, V. (2007). “Glossary of Scrum Terms.” http://www.scrumalliance.org/articles/39-glossary-
of-scrum-terms#1121 (acesso em 25 de mAIO de 2008).
14. Szimanski, F. (2006). Implementando MPS.BR nível G na melhoria do processo de software em 
uma pequena empresa. Simpósio Mineiro de Sistemas de Informação. Lavras, UFLA.
15. Szimanski, F. (2009). Extensão do Scrum segundo as áreas de processo do MPS.BR nível G. 
Dissertação de mestrado. Recife, CESAR.
Referências 
Edição 26 - Engenharia de Software Magazine 15 
Bruno Góis Borges
gois.mg@gmail.com
É arquiteto de sistemas e trabalha com 
desenvolvimento de software a mais de 12 
anos. Bacharel em ciência da computação 
e pós-graduado em desenvolvimento web 
pela FURB e FFM - Blumenau. É consultor em 
engenharia de software.
De que se trata o artigo?
Este artigo pretende contribuir para a análise da quali-
dade e complexidade do código OO, assim como auxi-
liar no entendimento dos benefícios das métricas.
Para que serve?
A gerência de um produto de software atinge um de-
terminado estado de qualidade e precisão se existirem 
medidas que tornem possível a administração através 
dos aspectos do sistema. A métrica de software é uma 
medida de propriedades do sistema que podem ser 
definidas como caminhos para determinar quantitati-
vamente a dimensão em que o produto, a sequencia e 
o projeto de software têm certas características.
Em que situação o tema é útil?
Para gerenciar produtividade e qualidade é ne-
cessário saber se ambas estão melhorando ou 
piorando. Isto implica na necessidade de métricas 
que indiquem as inclinações do desenvolvimento 
de sistema
Extração de métricas em software orientado 
a objetos
Engenharia
Nesta seção você encontra artigos voltados para testes, processo, 
modelos, documentação, entre outros
Para gerenciar produtividade e qualidade é necessário saber se ambas estão melhorando ou pio-
rando. Isto implica na necessidade de 
métricas que indiquem as inclinações 
do desenvolvimentode sistema. Assim, 
a gerência de um produto de software 
atinge um determinado estado de qua-
lidade e precisão se existirem medidas 
que tornem possível a administração 
através dos aspectos do sistema. A 
métrica de software é uma medida de 
propriedades do sistema que podem ser 
definidas como caminhos para determi-
nar quantitativamente a dimensão em 
que o produto, a sequencia e o projeto de 
software têm certas características.
Neste contexto, o processo de software 
estará sob controle se for adotada uma 
política de coleta de dados e documen-
tação durante o desenvolvimento do 
projeto. O objetivo da mensuração é 
abastecer engenheiros e gerentes de 
16 Engenharia de Software Magazine - Extração de métricas em software orientado a objetos
produtos com um grupo de informações palpáveis para se 
projetar, gerenciar, controlar, estimar e melhorar os projetos 
com maior eficácia [20]. Segundo Côrtes e Chiossi (2001), quan-
do são calculadas métricas, pretende-se obter dados que irão 
proporcionar opções para uma melhoria. Este é o objetivo da 
métrica de software, o estudo dos fatores que influenciam o 
rendimento através da qualificação dos projetos de desenvol-
vimento de software.
Entre as principais inquietações nas fábricas de software 
encontra-se a possibilidade de se criar um sistema de uma 
maneira mais rápida e a um custo mais baixo. As práticas ba-
seadas em objetos tendem a simplificar o projeto de softwares 
complexos. Para Amber (1998), as organizações escolhem a 
orientação a objetos (OO) porque querem dar às suas aplica-
ções mais qualidade, as quais querem implementar sistemas 
seguros, com um menor custo e menor tempo. 
Este artigo pretende contribuir para a análise da qualidade e 
complexidade do código OO, assim como auxiliar no entendi-
mento dos benefícios das métricas. Para isso, será apresentado 
o desenvolvimento de uma ferramenta capaz de efetuar a coleta 
de métricas de software OO a partir da análise de códigos 
fontes escrita em linguagem C# e Java.
Origem do Sistema Métrico
As métricas originaram-se da execução prática de avaliação 
para quantificar indicadores sobre o processo de desenvolvi-
mento de um sistema, sendo adotados a partir de 1970. Existem 
quatro tendências desta área que são:
a) Medida da complexidade do código: criada em meados de 
1970, os conjuntos métricos foram fáceis de atingir desde que 
fossem calculados pelo próprio código automatizado;
b) Estimativa do custo de um projeto de software: esta técnica 
foi desenvolvida em meados de 1970, estimando o trabalho e 
o tempo gasto para se desenvolver um software, baseando-se 
além de outros fatores, no número de linhas de código utili-
zados na implementação do sistema;
c) Garantia da qualidade do software: a melhoria destas 
técnicas teve maior repercussão entre os anos de 1970 e 1980, 
dando-se destaque à identificação de informações faltantes, 
durante as etapas do ciclo de vida do software;
d) Processo de desenvolvimento do software: o projeto de 
software ganhou importância e complexidade, sendo que a 
necessidade de se administrar este processo foi emergencial. 
O processo incluiu a definição do ciclo de vida do software 
através da definição da seqüência das fases do desenvolvi-
mento, dando mais destaque ao gerenciamento e controle de 
recursos deste projeto.
A partir do aparecimento destas tendências, os desenvolve-
dores de sistema começaram a usar métricas no propósito de 
adequar o processo de desenvolvimento de software.
Importância das Medições
Se não é conhecida a complexidade de um software não se 
pode saber o caminho a seguir e nem mesmo o que fazer para 
solucionar um problema. Uma das maneiras de se controlar o 
desenvolvimento de um sistema é a utilização da medição de 
software. As métricas podem medir cada estágio do desen-
volvimento e diversos aspectos do produto. Métricas ajudam 
a compreender o processo utilizado para a implementação de 
um sistema. De acordo com Pressman, o processo é medido 
com o propósito de melhorá-lo e o produto é mensurado com 
o intuito de ampliar sua qualidade.
Medidas são necessárias para examinar a qualidade e o rendi-
mento do processo de desenvolvimento e manutenção do produto 
de software implementado. Assim, “as empresas devem estabele-
cer métricas apropriadas e manter procedimentos para monitorar 
e medir as características de suas operações que possam causar 
impacto significativo na qualidade de seus produtos” [5]. 
Objetivos da utilização de métricas
A utilidade das métricas deve ser traçada desde o início da 
implantação de métricas para avaliação de software. Há várias 
características importantes associadas com o emprego das mé-
tricas de software. Sua escolha requer alguns pré-requisitos:
a) Os objetivos que se pretende atingir com a utilização das 
métricas;
b) As métricas devem ser simples de atender e de serem utili-
zadas para verificar atendimentos de objetivos e para subsidiar 
processos de tomadas de decisão;
c) As métricas devem ser objetivas, visando reduzir ou mini-
mizar a influência do julgamento pessoal na coleta, cálculo e 
análise dos resultados.
Para Ambler (1998), as métricas podem ser utilizadas para:
a) Estimar projetos: baseado em experiências anteriores pode-
se utilizar métricas para estimar o tempo, o esforço e o custo 
de um projeto;
b) Selecionar as ferramentas;
c) Melhorar a abordagem de desenvolvimento.
Em uma organização que se dedica ao desenvolvimento de 
software, seja como atividade-fim seja como de suporte para 
uma empresa, há vários objetivos que se busca atingir, depen-
dendo do estágio de maturidade em que se encontram essas 
atividades. Alguns dos objetivos perseguidos geralmente se 
enquadram na seguinte relação:
a) Melhorar a qualidade do planejamento do projeto;
b) Melhorar a qualidade do processo de desenvolvimento;
c) Melhorar a qualidade do produto resultante do processo;
d) Aumentar a satisfação dos usuários e clientes do software;
e) Reduzir os custos de retrabalho no processo;
f) Reduzir os custos de falhas externas;
g) Aumentar a produtividade do desenvolvimento;
h) Aperfeiçoar continuamente os métodos de gestão do projeto;
i) Aperfeiçoar continuamente o processo e o produto;
j) Avaliar o impacto de atributos no processo de desenvolvi-
mento, tais como novas ferramentas;
k) Determinar tendências relativas a certos atributos do 
processo.
Edição 26 - Engenharia de Software Magazine 17 
MEDIção
Um dos aspectos que deve ser observado quando da imple-
mentação de iniciativas de utilização de métricas é quanto a 
sua utilidade no contexto de um projeto ou do ambiente como 
todo, além dos tipos e categorias de métricas, usuários das 
métricas, pessoas para as quais os resultados das métricas são 
destinados e os seus níveis de aplicação.
O processo de medição e avaliação requer um mecanismo 
para determinar quais os dados que devem ser coletados e 
como os dados coletados devem ser interpretados [7]. O proces-
so requer um mecanismo organizado para a determinação do 
objetivo da medição. A definição de tal objetivo abre caminho 
para algumas perguntas que definem um conjunto específico 
de dados a serem coletados. Os objetivos da medição e da 
avaliação são consequências das necessidades da empresa, que 
podem ser a necessidade de avaliar determinada tecnologia, a 
necessidade de entender melhor a utilização dos recursos para 
melhorar a estimativa de custo, a necessidade de avaliar a qua-
lidade do produto para poder determinar sua implementação 
ou a necessidade de avaliar as vantagens e desvantagens de 
um projeto de pesquisa.
Assim, o objetivo primário de se realizar medições no de-
senvolvimento de software é obter níveis cada vez maiores 
de qualidade, considerando o projeto, o processo e o produto, 
visando à satisfação plena dos clientes ou usuários a um custo 
economicamente compatível.Métricas tradicionais
A partir de agora serão apresentados alguns exemplos de 
métricas tradicionais.
Constructive Const Model
O modelo COCOMO é calculado a partir do número de 
linhas de código fonte entregue ao usuário [7]. Este modelo 
foi desenvolvido por Barry Boehm e resulta em estimativas 
de esforço, prazo, custo e tamanho da equipe para um pro-
jeto de software. O COCOMO é um conjunto de submodelos 
hierárquicos, que pode ser dividido em submodelos básicos, 
intermediários ou detalhados.
Linhas de Código
O modelo LOC, é a técnica de estimativa mais antiga. Ela 
pode ser aplicada para estimar o custo do software ou para 
especificar igualdade de analogia. Há muitas discussões e 
especulações sobre esta técnica. Primeiramente, a definição 
de linhas de código não é muito clara.
Um exemplo simples seria o caso de ser colocado ou não 
um comentário ou uma linha em branco como LOC. Alguns 
autores consideram estes comentários, no entanto, outros não. 
No caso de programas recursivos, essa técnica falha, porque 
a recursividade torna o programa mais curto. O sistema LOC 
é uma técnica genérica e superficial [11]. 
Outro problema da técnica LOC é que esta técnica é forte-
mente ligada à linguagem de programação utilizada, impos-
sibilitando a utilização de dados históricos para projetos que 
não utilizam a mesma linguagem.
As vantagens do uso de LOC são [7]:
a) É fácil de ser obtido;
b) É utilizado por muitos modelos de estimativa de software 
como valor básico de entrada;
c) Existe farta literatura e dados sobre este sistema de métrica.
As desvantagens são:
a) Dependência de linguagem: não é possível comparar di-
retamente projetos que foram desenvolvidos em linguagens 
diferentes. Como exemplo, pode-se verifica a quantidade de 
tempo gasto para gerar uma instrução em uma linguagem de 
alto nível comparado com uma linguagem de baixo nível;
b) Penalizam programas bem projetados: quando um progra-
ma é bem projetado o mesmo utiliza poucos comandos para 
execução de uma tarefa;
c) Difíceis de estimar no início do projeto de software: é 
praticamente impossível estimar o LOC necessário para um 
sistema saindo da fase de levantamento de requisitos ou da 
fase de modelagem.
Com estas colocações, nota-se que a métrica LOC não é uma 
métrica a ser utilizada por si só, ela deveria ser utilizada em 
conjunto com outras métricas, efetuando um comparativo de 
resultados. Deste modo, uma métrica poderia completar a outra, 
fornecendo informações que são pertinentes às características 
de cada uma.
Medida de Ciência do Software
Halstead identificou a Ciência de Software – originalmente 
chamada de Física do Software – como uma das primeiras 
manifestações sobre métrica de código baseada num modelo de 
complexidade do software [18]. A idéia principal deste modelo é 
a compreensão de que software é um processo de manipulação 
mental dos símbolos de seus programas.
Estes símbolos podem ser caracterizados como operadores (em 
um programa executável verbos como: IF, DIV, READ, ELSE e 
os operadores propriamente ditos) ou operandos (variáveis 
e constantes), visto que a divisão de um programa pode ser 
considerada como uma seqüência de operadores associados a 
operandos.
Para Shepperd (1993), a ciência do software atraiu consideravel-
mente o interesse das pessoas em meados de 1970 por ser uma 
novidade na metrificação do software. Além disso, as entradas 
básicas do software são todas facilmente extraídas. Após o 
entusiasmo inicial da ciência do software, foram encontrados 
sérios problemas. Os motivos podem ser relatados em função da 
dificuldade que os pesquisadores encontraram na comparação 
dos trabalhos e evolução da métrica. Outro motivo seria a não 
associação correta entre o esforço requerido para manipulação 
do programa e o tempo exigido para conceber o programa e 
também por tratar um sistema como um simples módulo.
Métrica da complexidade ciclomática
Este método foi proposto por McCabe, que estava particular-
mente interessado em descobrir o número de caminhos criado 
18 Engenharia de Software Magazine - Extração de métricas em software orientado a objetos
pelos fluxos de controle em um módulo do software, desde que 
fosse relacionada à dificuldade de teste e na melhor maneira de 
dividir software em módulos.
A idéia é desenhar num grafo a sequencia que um pro-
grama pode tomar com todos os possíveis caminhos. A 
complexidade calculada fornecerá um número designando 
o quão complexo é um programa (ou seqüência).
Para possibilitar o cálculo desta métrica, os programas são 
inicialmente representados por grafos dirigidos represen-
tando o fluxo de controle. De um grafo G, pode ser extraída 
a complexidade ciclomática v(G). O número de caminhos 
dentro de um grafo pode ser dado como: o conjunto mínimo 
de caminhos os quais podem ser utilizados para a constru-
ção de outros caminhos através do grafo. A complexidade 
ciclomática é também equivalente ao número de decisões 
adicionais dentro de um programa:
v(G) = E – n + 2,
onde, 
E: é o número de arestas.
N: é o número de nós.
A visão simplificada da métrica de McCabe pode ser ques-
tionada em vários pontos. Primeiro, ele tinha uma preocu-
pação especial com os programas escritos em Fortran, onde 
o mapeamento do código-fonte, para um grafo de fluxo do 
programa era bem definido, sendo que isto não seria o caso 
de outras linguagens como Ada. A segunda oposição é que 
v(G) = 1 seria verdadeiro em uma sequencia linear de código 
de qualquer tamanho. Consequentemente, a medição não é 
sensível à complexidade, contribuindo assim na formação 
de declarações de sequencia lineares.
A complexidade ciclomática é sensível ao número de sub-
rotinas dentro de um programa, por este motivo, McCabe 
sugere que este aspecto seja tratado como componentes não 
relacionados dentro de um grafo de controle [19]. Este ponto 
teria um resultado interessante, pois aumentaria a complexi-
dade do programa globalmente, visto que ele é dividido em 
vários módulos que se imagina serem sempre simples.
A Figura 1 demonstra um exemplo de complexidade ciclo-
mática que ilustra o fluxo do grafo gerado para os caminhos 
entre 1 e 9.
Métricas para Orientação a Objetos
Embora exista farta literatura sobre como aplicar os métodos 
OO, a maioria não apresenta detalhes relativos à qualidade. 
A razão é simples: o desenvolvimento de software utilizando 
esse enfoque ainda não dispõe de métricas precisas e bem 
entendidas que possam ser utilizadas para avaliar produtos e 
processos de desenvolvimento nesta abordagem. 
Muitas métricas já foram desenvolvidas para gerações pas-
sadas de tecnologia e, em muitos casos, são usadas até para 
desenvolvimento OO, porém não são muito coerentes, pois a 
diferença com sistemas tradicionais é muito grande.
Nesse sentido, o desenvolvimento de software utilizando o 
paradigma de OO surge como uma possibilidade para a me-
lhoria da qualidade e produtividade, pois permite modelar o 
problema em termos de objetos capazes de diminuir a distância 
entre o problema do mundo real e sua abstração.
A OO requer uma abordagem diferente tanto no desenvolvi-
mento do projeto quanto na implementação do mesmo, como 
também nas métricas de software, visto que usa objetos e não 
blocos de construção fundamentais [17]. Dadas as diferenças 
entre as duas visões, é comum constatar que as métricas de 
software desenvolvidas para serem aplicadas aos métodos 
tradicionais de desenvolvimento não são facilmente mapeadas 
para os conceitos OO.
Existem várias propostas para métricas OO que levam em 
consideração as características básicas e interações do siste-
ma como: número de classes; número de métodos; linhas de 
código por método; profundidade máxima da hierarquia de 
classes; a relação existente entre métodos públicos e privados; 
entre outros. Tais métricas baseiam-sena análise detalhada 
do projeto. 
As métricas OO podem ser separadas em duas categorias: 
medidas relacionadas com processos e relacionadas com 
produtos [10]. As métricas relacionadas com processo são 
utilizadas para mensurar o processo e o status do processo 
de desenvolvimento do sistema, consistem em medir coisas 
tais como: cronogramas ou números de falhas encontradas 
durante o processo de testes. 
Para aprender a manipular e administrar um processo de 
desenvolvimento OO é importante iniciar a coleta de dados 
destas medições tão metodicamente quanto possível. A seguir 
alguns exemplos de métricas relacionadas com processo:
a) Tempo total de desenvolvimento;
b) Tempo de desenvolvimento em cada processo e subprocesso;
c) Tempo utilizado modificando modelos de processos 
anteriores;
d) Tempo gasto em todos os tipos de subprocessos como: es-
pecificação dos casos de uso, desenho do bloco, teste do bloco 
e do caso de uso para cada objeto;
e) Número de diferentes tipos de falhas encontrados durante 
revisões;
f) Número de mudanças propostas nos modelos anteriores;
g) Custo da garantia de qualidade;
h) Custo para introduzir novas ferramentas e processo de 
desenvolvimento.Figura 1. Exemplo de cálculo de complexidade ciclomática
Edição 26 - Engenharia de Software Magazine 19 
MEDIção
Estas medições podem formar uma base para o planeja-
mento do desenvolvimento de projetos futuros. Por exemplo, 
conhecendo o tempo médio gasto para especificar todos os 
casos de uso. Estas medições, entretanto deveriam sempre 
vir acompanhadas por uma indicação de exatidão da medição 
(tal como desvio padrão), caso contrário, não se tem senso de 
exatidão da previsão. Deve-se observar também que estas 
medições podem variar muito entre diferentes processos, 
organizações, aplicação e equipe. Portanto, é perigoso tirar 
conclusões genéricas sobre dados existentes sem considerar 
as circunstâncias.
As métricas relacionadas com produtos são aquelas que são 
utilizadas para controlar a qualidade do produto final. Elas 
tradicionalmente são aplicadas ao sistema ainda em constru-
ção para mensurar sua complexidade e prever propriedades 
do produto final.
Medidas tradicionais de produtos podem ser utilizadas para 
algumas aplicações OO [10]. Entretanto, a métrica mais comum, 
linhas de código, é a menos interessante para sistemas OO, pois 
às vezes o menor código escrito é o mais reutilizado e, muitas 
vezes dá maior qualidade ao produto.
A seguir serão exemplificadas algumas métricas para OO. 
Estas métricas estão relacionadas em três categorias: métricas 
de análise, projeto e construção. Estas medidas podem ser utili-
zadas para auxiliar a melhorar os esforços de desenvolvimento 
[1]. Elas podem identificar áreas com problemas na aplicação 
antes que elas apareçam como um erro detectado pelo usuá-
rio. As métricas de projetos e construção além de mensurar 
aspectos importantes do sistema, são fáceis de automatizar, 
tornando-as mais fáceis de coletar.
A Figura 2 demonstra um exemplo de diagrama de classes 
que ilustra algumas medidas explicadas em seguida. Este dia-
grama de classes define criação de pessoas: uma pessoa pode 
ser do tipo cliente ou funcionário, por sua vez o funcionário 
pode ser do tipo horista, diarista ou mensalista; um funcioná-
rio tem um cargo e deve estar em um departamento.
cd Data Model
Departamento
- Descricao: String
- Chefia: FuncionarioMensalista
Cargo
- Descricao: String
- TitulacaoMinima: String
Pessoa
- Nome: String
- Sexo: String
- DataNascimento: TDateTime
Cliente
- CPF: String
Funcionario
- Salario: Real
- Alocacao: Departamento
- CargoAtual: Cargo
+ CalcularSalario()
+ ObterSalario() : Real
FuncionarioHorista
- ValorHora: Real
- NumeroDias: Integer
- NumeroHorasDia: Integer
+ CalcularSalario()
FuncionarioDiarista
- ValorDia: Real
- NumeroDias: Integer
+ CalcularSalario()
FuncionarioMensalista
- ValorMes: Real
- Encargos: Real
+ CalcularEncargos()
+ CalcularSalario()
-Chefia
-CargoAtual
-Alocacao
Figura 2. Exemplo de diagrama de classes
Faz sentido adicionar um peso às métricas das classes para 
produzir uma medida de complexidade do sistema. A maioria 
das medidas examina atributos em termos dos conceitos de 
OO como herança, polimorfismo e encapsulamento. Para tanto, 
seria necessário coletar um número significativo de contagens, 
ou seja, seria necessário tomar valores de vários projetos e 
dimensioná-los selecionando as classes, os métodos e os atri-
butos desejáveis para medir o tamanho e a complexidade de 
um novo software.
Métricas segundo Chidamber e Kemerer
Chidamber e Kemerer (1994, p. 41) propuseram seis métricas 
para o cálculo de complexidade de sistema OO. As métricas 
chamadas de CK são ótimas referências para análise quan-
titativa, objetivando a concentração de testes em classes que 
possivelmente contêm maior número de defeitos. A seguir 
uma descrição de cada métrica:
a) WMC: cálculo do número de serviços por classe. Um 
alto WMC mostra que a classe tende a se tornar específica 
e seus serviços possuem características que atendem a 
necessidades individuais, restringindo sua reutilização. O 
número de serviços mostra ainda qual o nível de esforço 
deve ser despendido para o teste da complexidade da classe 
(ver Figura 3);
Atributo1
Metodo_X
Metodo_Y
Metodo_Z
Metodo_X
Metodo_Y
Metodo_Z
Metodo_X
Metodo_Y
Metodo_Z
Metodo_X
Metodo_Y
Metodo_Z
Metodo_X
Metodo_Y
Metodo_Z
WMC (X) = 3= WMC (X) = 3=
Figura 3. Exemplo da métrica WMC
b) DIT: é o número máximo de superclasses posicionadas 
hierarquicamente acima da classe em questão. Um DIT ele-
vado mostra que muitas das características da classe foram 
adquiridas por herança e são comuns a outras classes. Isso 
mostra que as superclasses contêm um alto nível de abstração, 
o que significa que elas estão possivelmente preparadas para 
possibilitar uma boa reutilização. Em contrapartida, DIT pode 
indicar que a classe herda muitos serviços, aumentando a sua 
complexidade (ver Figura 4);
A
B
D
CDIT (C) = 2DIT (C) = 2
A
B D
EC
DIT (E) = 2DIT (E) = 2
Figura 4. Exemplo da métrica DIT
c) NOC: número de subclasses posicionadas imediatamente 
abaixo da superclasse em questão ou filhos diretos. Um NOC 
elevado indica um baixo nível de abstração, pois uma super-
classe com muitos filhos tende a conter poucas características 
comuns a todas as subclasses. Um alto número de filhos diretos 
também pode indicar problemas estruturais, uma vez que as 
subclasses podem não se adequar à abstração implícita da 
classe pai (ver Figura 5);
20 Engenharia de Software Magazine - Extração de métricas em software orientado a objetos
d) CBO: mostra qual é o nível de acoplamento entre as classes 
da aplicação. Quanto maior a ligação entre elas, menor a pos-
sibilidade de reutilização, pois a classe torna-se dependente 
de outras classes para cumprir suas obrigações. Portanto o 
CBO está diretamente legado ao nível de reaproveitamento. 
Um alto acoplamento indica uma baixa independência de 
classe, o que aumenta consideravelmente a complexidade e, 
em consequência, o esforço de teste (ver Figura 6);
Chegada de Chegada de 
mensagem mensagem 
para o para o 
objeto Xobjeto X
CBO (X) = 2CBO (X) = 2
Figura 6. Exemplo da métrica CBO
e) LCOM: número de acesso a um ou mais atributos em 
comum pelos serviços da própria classe. Dessa forma, os ser-
viços tornam-se ligados pelos atributos, podendo indicar que 
foram mal projetados, pois apresentam baixa coesão. Uma das 
principais características do software OO é apresentar uma 
alta coesão nos métodos, o que garante que esses exerçam 
sua função adequadamente. Portanto é importante manter o 
LCOM da classe baixo (ver Figura 7);
Figura 7. Exemplo da métrica LCOM
f)