Engenharia de Software - Edição 26

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 ME R C A D O
PS- GRADUAO
Engenharia de Software:
Desenvolvimento Java
Engenharia de Software:
Desenvolvimento .NET
GRADUAO
Engenharia de Computao
Anlise e Desenv. de Sistemas
FORMAES
Desenvolvedor Java
Desenv. Java: Sist. Distribudos
Gestor de TI
Desenvolvedor Web .NET 2008
MCITP Server Administrator
SQL Server 2008
Acesse nosso site e conhea todos os nossos programas: www.infnet.edu.br/esti
A Escola Superior da Tecnologia da
Informao oferece as melhores
opes em cursos, formaes,
graduaes e ps-graduaes para
profissionais de desenvolvimento
e programao.
So programas voltados para a
formao de profissionais de elite,
com aulas 100% prticas, corpo
docente atuante no mercado,
acesso mais atualizada biblioteca
de TI do Rio, laboratrios equipados
com tecnologia de ponta, salas de
estudo e exames.
r/esti
TURMAS
NO RIO DE
JANEIRO
Modstia parte, sua
melhor opo para
se destacar no mercado!
Corpo Editorial
Colaboradores
Rodrigo Oliveira Spnola
rodrigo@sqlmagazine.com.br
Marco Antnio Pereira Arajo
Eduardo Oliveira Spnola
Capa e Diagramao
Romulo Araujo - romulo@devmedia.com.br
Coordenao 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 Edio - 2010 Impresso no Brasil
A
o final dos anos 90, como reao s formas tradicionais de desenvolvimento de
software, que baseado em estudos realizados pela indstria e academia foi apon-
tada como a principal responsvel por falhas encontradas em projetos de softwa-
re, acompanhamos o surgimento de vrias metodologias geis, como: Adaptive Software
Development, Crystal, Dynamic Systems Development, eXtreme Programming (XP), Featu-
re Driven Development (FDD) e Scrum.
Neste sentido, organizaes que procuram melhoria em seus processos de produo
atravs 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 tambm acreditam que introduzir conceitos
geis em seus processos de desenvolvimento, buscando um equilbrio 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, alcanar competitividade pela qualidade para as empresas de softwa-
re implica tanto na melhoria da qualidade dos produtos de software e servios correlatos,
como dos processos de produo e distribuio de software. Desta forma, assim como
para outros setores, qualidade fator crtico de sucesso para a indstria de software.
O desenvolvimento gil e os modelos e padres de qualidade de software tradicionais
so vistos frequentemente como contraditrios, pois se tem o raciocnio que os modelos
so muito burocrticos, enquanto que o desenvolvimento gil ad-hoc. Na verdade exis-
tem desafios na integrao entre os dois, embora o esforo possa valer a pena, pois ao final
pode-se obter qualidade no produto atravs da unio de maturidade e agilidade.
Neste contexto, a Engenharia de Software Magazine destaca nesta edio a matria
Extenso do Scrum segundo o MPS.BR nvel Gcujo o objetivo propor uma estratgia para
extenso do Scrum segundo as reas de processo do guia MPS.BR nvel G. Este estudo se
inicia com o mapeamento entre o Scrum e o MPS.BR atravs de uma avaliao dos resultados
esperados do guia segundo as prticas do Scrum. A partir deste mapeamento, uma extenso
do Scrum realizada atravs da adio de prticas complementares para satisfazer o guia. Ao
final, gerado um novo processo de desenvolvimento para uma fbrica de software.
Alm desta matria, esta edio traz mais cinco artigos:
Lidando com o risco nas corporaes
Extrao de mtricas em software orientado a objetos
Anlise de dependncias entre prticas especficas do nvel 2 do CMMI
Integrao das ferramentas Trac e Subversion
Auditoria de Sistemas Baseada em Riscos
Desejamos uma tima leitura!
Equipe Editorial Engenharia de Software Magazine
Rodrigo Oliveira Spnola
rodrigo@sqlmagazine.com.br
Doutorando em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em
Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computao
(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 implementao 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 Antnio Pereira Arajo - Editor
(maraujo@devmedia.com.br)
Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Li-
nha de Pesquisa em Engenharia de Software, Especialista em Mtodos Estatsticos
Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao
do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em
Sistemas de Informao da Faculdade Metodista Granbery,Professor e Diretor do Cur-
so Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao
Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora,
Colaborador da Engenharia de Software Magazine.
Eduardo Oliveira Spnola
(eduspinola@gmail.com)
Colaborador das revistas Engenharia de Software Magazine,Java Magazine e SQL Ma-
gazine. bacharel em Cincias da Computao pela Universidade Salvador (UNIFACS)
onde atualmente cursa o mestrado em Sistemas e Computao na linha de Engenharia
de Software,sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).
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, endereo de
bancas de jornal, entre outros, entre em contato com:
Cristiany Queirz 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 informaes sobre veiculao de anncio 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 sugesto!
Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc
gostaria de publicar:
Rodrigo Oliveira Spnola - Colaborador
editor@sqlmagazine.com.br
EDITORIAL
NDICE
Por trs do obvio
06 - Lidando com o risco nas corporaes
Glnio Cabral
Agilidade
07 - Extenso do Scrum segundo o MPS.BR nvel G
Fernando Szimanski, Jones Oliveira de Albuquerque e Felipe Furtado
Engenharia
15 - Extrao de mtricas em software orientado a objetos
Bruno Gis Borges
35 - Anlise de dependncias entre prticas especficas do nvel 2 do CMMI
Thiago Salhab Alves e Paulo C. Barreto da Silva
Desenvolvimento
41 - Integrao das ferramentas Trac e Subversion
Daves Marcio Silva Martins, Tadeu Moreira de Classe, Eduardo Leandro Pinto Dornelas e Guilherme de Jorge Palmeira
Tipo: Processo
Ttulo: Introduo a Modelos de Ciclo de Vida Parte 1
Autor: Rodrigo Oliveira Spnola
Mini-Resumo: Perceber que atividades fazem parte do processo de engenharia de
software o primeiro passo para concretiz-lo, mas tambm importante perceber
como as atividades do processo se relacionam umas com as outras para que se torne
visvel 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 srie de 3 vdeo aulas.Nesta primeira,
conheceremos algumas definies sobre modelos de ciclo de vida e conheceremos o ciclo
de vida em cascata atentando para suas vantagens e desvantagens.
Tipo: Processo
software o primeiro passo para concretiz-lo, mas tambm importante perceber
visvel 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 srie de 3 vdeo aulas. Nesta
segunda aula, conheceremos os modelos de ciclo de vida em V e o interativo.
Tipo: Processo
software o primeiro passo para concretiz-lo,mas tambm importante perceber
visvel 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 srie de 3 vdeo
aulas. Nesta terceira parte, conheceremos os modelos de ciclo de vida evolutivo,
RAD, prototipao e espiral.
Tipo: Processo
Ttulo: Atividades do Desenvolvimento de Software Parte 1
Mini-Resumo: Esta vdeo aula apresenta algumas das principais atividades execu-
tadas ao longo do desenvolvimento de projetos de software. Nesta primeira parte
conheceremos as atividades: elicitao de requisitos, anlise de requisitos, projeto
de arquitetura do sistema e projeto de software.
Tipo: Processo
Ttulo: Atividades do Desenvolvimento de Software Parte 2
Mini-Resumo: Esta vdeo aula apresenta algumas das principais atividades executadas
ao longo do desenvolvimento de projetos de software. Nesta segunda parte conhe-
ceremos as atividades: implementao do software, integrao de software, teste de
software, integrao de sistema, teste de sistema e implantao do software.
4 Engenharia de Software Magazine
Caro Leitor,
Para esta edio, temos um conjunto de 5 vdeo aulas. Estas vdeo aulas esto disponveis para
download no Portal da Engenharia de Software Magazine e certamente traro uma signica-
tiva contribuio para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:
Edio 05 - Engenharia de Software Magazine 5
6 Engenharia de Software - Lidando com o risco nas corporaes
Lidando com o risco nas
corporaes
Pos trs do bvio
A
lgum j disse que, para morrer, basta estar vivo. Seja
quem for que tenha dito isso, afirmou uma grande e
fnebre verdade. Mortos no costumam morrer, porque
j esto mortos. A eles cabe apenas permanecer em seu estado
de sono profundo. Apenas os vivos podem um dia dar adeus
existncia e descansar em paz.
Embora a morte seja o fim do ciclo de vida de todos os seres
vivos, permanecer vivo uma obsesso instintiva de todo aquele
que respira. Por isso desenvolvemos estratgias para prorrogar ao
mximo o nosso encontro com a morte, identificando e evitando
os caminhos que podem nos levar mais cedo para o mundo do
alm. Assim, cada vez que vamos ao mdico fazer exames de
rotina, que mudamos a nossa alimentao para uma dieta mais
saudvel e que cuidamos mais de ns mesmos, estamos iden-
tificando e avaliando riscos que podem nos levar a situaes
indesejveis.
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 ocorrncia de eventos prejudiciais ao sucesso. Por
isso, administrar riscos numa corporao como fazer exames
de rotina. O objetivo principal garantir a sobrevivncia. O en-
graado que da mesma forma que muitas pessoas no gostam
de fazer exames preventivos por diversas razes, alguns gestores
insistem em adotar uma postura incompetente diante dos riscos
que envolvem suas atividades. Mas o que ser incompetente na
administrao desses riscos?
Primeiro, achar que nunca vai adoecer. O maior erro de
algum que deseja ter uma vida saudvel pensar que por ter
uma sade inabalvel, nunca ir pegar uma gripe, uma virose
ou coisa parecida. Ledo engano. Muitas das variveis internas e
externas que envolvem nossas organizaes so como vrus que
vivem assediando empresas com sistemas imunolgicos fragiliza-
dos pela atitude desleixada e prepotente da auto-suficincia. Por
isso, estar atendo aos riscos , antes de mais nada, uma postura
de humildade.
Glnio Cabral
gleniocabral@yahoo.com.br
Administrador de Empresas, ps-graduado em Gesto de Pessoas e m-
sico. Idealizador do site de educao infantil www.novainfancia.com.br.
Segundo, desconhecer a prpria realidade domstica.
H casos de gestores que desconhecem as particularidades
de seu prprio empreendimento. Informaes como riscos
inerentes ao negcio, riscos que envolvem os fornecedores,
os consumidores e os concorrentes so essenciais para o bom
andamento das atividades organizacionais. Uma pessoa que
no est informada de sua prpria condio fsica corre o
risco de estar abrigando uma grave enfermidade dentro de
si, desconhecendo-a por completo. Assim tambm se d com
a corporao que no est devidamente inteirada de suas
prprias singularidades.
Terceiro, arriscar-se em mares proibidos. Uma pessoa que
diabtica e desconhece isso por no ter o hbito de fazer exames
peridicos, acaba consumindo alimentos proibidos para o seu
quadro clnico. Assim tambm ocorre com uma organizao
que no est atenta aos ambientes micro e macro, e que por isso
muitas vezes adota estratgias e metas desaconselhveis para a
sua realidade.
Algum j disse que, para morrer, basta estar vivo. Seja quem
for que tenha dito isso, afirmou uma grande e fnebre verdade.
No entanto, muitas pessoas que j no esto mais entre ns, con-
tinuam vivas atravs das organizaes que idealizaram e ajuda-
ram a fundar, e que hoje so referenciais na arte de administrar
imprevistos. Chegamos ento a uma bombstica concluso: uma
boa administrao de riscos pode gerar uma certa imortalidade.
Por que no?
D seu feedback sobre esta edio!
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, atravs do link:
www.devmedia.com.br/esmag/feedback
D

s
e
u
Feedba
c
k
s
o
b
r
e

e
s
t
a
e
d i o
Fernando Szimanski
fernando@criativadsi.com.br
Possui graduao em Processamento de
Dados (UNOPAR, 2002), Ps-graduao em
Melhoria em Processo de Software (UFLA,
2006) e Mestrado em Engenharia de Sofware
(CESAR.EDU, 2009). Atualmente professor e
coordenador de estgio do Centro Universit-
rio UNIRG e Gerente de Projetos da Criativa
Tecnologia. Tem experincia na rea de Enge-
nharia de Software, com nfase em Modelos e
Padres de Melhoria no Processo de Software,
Metodologias geis e Gesto de Projetos.
Jones Oliveira de Albuquerque
jones.albuquerque@gmail.com
Possui graduao em Cincia da Computa-
o (UFPE, 1994), mestrado em Cincias da
Computao (UFPE, 1997) e doutorado em
Cincias da Computao (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 Avanados do Recife. Tem experincia
na rea de Cincia da Computao, foi diretor
de empresa e atua na rea de Engenharia de
Software e Modelagem Matemtica, atuando
principalmente nas seguintes linhas: enge-
nharia de software, processo de software,
qualidade de software, matemtica com-
putacional, epidemiologia computacional e
modelagem de sistemas.
Felipe Furtado
felipe.furtado@cesar.org.br
graduado em Engenharia Mecnica pela UFPE,
especialista em Tecnologias da Informao pelo
Centro de Informtica da UFPE e mestre em Ci-
ncia da Computao na rea de produtividade
de software tambm 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 experincia na defi-
nio e implantao de processos aderentes ao
CMMI e em avaliaes SCAMPI, com participao
em avaliaes Classe A CMMI nveis 2 e 3.
De que se trata o artigo?
Este artigo apresenta a extenso da metodologia gil
Scrum para as reas de processo do MPS.BR nvel G
aplicada em uma pequena fbrica de software.
Para que serve?
A extenso realizada neste trabalho pode contribuir de
forma relevante para organizaes que tm o propsi-
to de adotar prticas geis no seu processo de software
mantendo a compatibilidade com o MPS.BR nvel G.
Em que situao o tema til?
Introduzir conceitos geis em processos de software
buscando um equilbrio entre agilidade e maturida-
de uma alternativa capaz de promover a melhoria
da qualidade dos produtos e, consequentemente,
aumento da competitividade no mercado.
Extenso do Scrum segundo o MPS.BR nvel G
Implementando agilidade e maturidade em uma fbrica de software
A
o final dos anos 90, como rea-
o s formas tradicionais de
desenvolvimento de software,
que baseado em estudos realizados pela
indstria e academia [12], foi apontada
como a principal responsvel por falhas
encontradas em projetos de software,
acompanhamos o surgimento de vrias
metodologias geis, como: Adaptive
Software Development, Crystal, Dynamic
Systems Development, eXtreme Program-
ming (XP), Feature Driven Development
(FDD) e Scrum [4].
As metodologias geis so uma coleo
de diferentes tcnicas (ou prticas), que
utilizam os mesmos valores e princpios
bsicos, tais como ciclos iterativos, en-
trega rpida de software funcionando
e simplicidade, conforme est definido
no Manifesto para Desenvolvimento
gil [2].
Neste sentido, organizaes que pro-
curam melhoria em seus processos de
Agilidade
Nesta seo voc encontra artigos voltados para as prticas e mtodos geis.
8 Engenharia de Software Magazine - Extenso do Scrum segundo o MPS.BR nvel G
produo atravs 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 tambm acreditam que intro-
duzir conceitos geis em seus processos de desenvolvimento,
buscando um equilbrio 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], alcanar competitividade pela qua-
lidade para as empresas de software implica tanto na melhoria
da qualidade dos produtos de software e servios correlatos,
como dos processos de produo e distribuio de software.
Desta forma, assim como para outros setores, qualidade fator
crtico de sucesso para a indstria de software.
O desenvolvimento gil e os modelos e padres de qualida-
de de software tradicionais so vistos frequentemente como
contraditrios, pois se tem o raciocnio que os modelos so
muito burocrticos, enquanto que o desenvolvimento gil
ad-hoc [6]. Na verdade existem desafios na integrao entre os
dois, embora o esforo possa valer a pena, pois ao final pode-se
obter qualidade no produto atravs da unio de maturidade
e agilidade.
Nessa direo, [Chin 2004] afirma que, se por um lado o
excesso de formalidade e estruturao tende a inibir e limitar
as equipes, por outro, a liberalidade catica 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 estratgia para extenso do Scrum segundo as reas de
processo do guia MPS.BR nvel G. Este estudo se inicia com o
mapeamento entre o Scrum e o MPS.BR atravs de uma avalia-
o dos resultados esperados do guia segundo as prticas do
Scrum. A partir deste mapeamento, uma extenso do Scrum
realizada atravs da adio de prticas complementares
para satisfazer o guia. Ao final, gerado um novo processo de
desenvolvimento para uma fbrica de software.
O MPS.BR
O MPS.BR tem como objetivo definir um modelo de melhoria
e avaliao de processo de software, preferencialmente para
as micro, pequenas e mdias empresas, para satisfazer as suas
necessidades de negcio e tambm ser reconhecido nacional
e internacionalmente como um modelo aplicvel indstria
de software [11].
O Modelo de Referncia MR-MPS define sete nveis de matu-
ridade, que so uma combinao entre processos e capacidade
de processos, tais como: A (Em Otimizao); B (Gerenciado
Quantitativamente); C (Definido); D (Largamente Definido);
E (Parcialmente Definido); F (Gerenciado); G (Parcialmente
Gerenciado). Para cada um destes sete nveis de maturidade
foi atribudo um perfil de processos e de capacidade de pro-
cessos que indicam onde a organizao tem que concentrar
o esforo para melhoria de forma a atender os objetivos de
negcio [11].
O nvel G de maturidade do MPS.BR (Parcialmente Geren-
ciado) composto pelos processos de Gerncia de Projetos e
Gerncia de Requisitos satisfazendo os atributos de processo
AP 1.1 e AP 2.1.
O processo de Gesto de Projetos (GPR) composto por
dezessete resultados esperados e tem o propsito de estabe-
lecer e manter planos que definem as atividades, recursos e
responsabilidades do projeto, bem como prover informaes
sobre o andamento do projeto que permitam a realizao de
correes quando houver desvios significativos no desempe-
nho do projeto [11].
O processo de Gerncia de Requisitos (GRE) composto por
cinco resultados esperados. O seu propsito gerenciar os re-
quisitos do produto e dos componentes do produto do projeto
e identificar inconsistncias 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 emprica 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 princpios como: equipes pequenas, requisitos pouco
estveis ou desconhecidos e iteraes curtas. As iteraes so
divididas em intervalos de tempos de, no mximo 30 dias,
tambm chamadas de Sprints.
Papis e responsabilidades
O Scrum define para sua estrutura iterativa incremental trs
papis 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 organizao; deve
garantir que todos sigam as regras e prticas do Scrum; e
responsvel por remover os impedimentos do projeto [10]. Ele
o lder e facilitador entre o Team e o Product Owner;
Product Owner: o responsvel 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 priorizao do Backlog e questes de requisitos. Esta pessoa
deve estar disposio 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
necessrias para transformar requisitos em um incremento po-
tencialmente entregvel. Para tanto, geralmente so uma mescla
de analistas, designers, gerentes de qualidade, desenvolvedores,
etc. A equipe tem a autoridade de decidir, quando necessrio,
as aes que sero realizadas e prioriz-las organizando-as
em Sprints. Effort estimation, Sprint Backlog, revises de product
Backlog List e sugestes de impedimentos para serem removidos
do projeto tambm so atividades do time [13].
METODOLOGI AS GEI S
As fases do Scrum
O ciclo de desenvolvimento do Scrum baseado em trs 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 viso do projeto e expectativas, garantindo recursos para a
sua execuo. A subfase Staging tem por objetivo avaliar as
vrias dimenses do projeto criando itens adicionais ao Product
Backlog relacionados com o tipo do sistema, time, ambiente de
desenvolvimento e tipo de aplicao;
GAME: consiste de mltiplas Sprints para o desenvolvimen-
to dos incrementos de funcionalidades do produto. Onde o
time analisa a situao atual do produto, avaliando quais
mudanas devem ser implementadas, procedendo ao final
com o desenvolvimento atravs de etapas de anlise, projeto,
implementao, testes e documentao de mudanas;
POST-GAME: fase de fechamento, que tem por objetivo pre-
parar o produto para o seu lanamento. Isto inclui atividades
de integrao, anlise, documentao do usurio, treinamento
e preparao do material de marketing.
Figura 1. Fases do Scrum
Fluxo do Scrum
Um projeto se inicia com a viso do produto que ser desen-
volvido [10], com a lista das caractersticas do produto estabe-
lecidas pelo cliente, alm de algumas premissas e restries.
Em seguida, o Product Backlog criado contendo a lista de todos
os requisitos funcionais e no funcionais. O Product Backlog
ento priorizado pelo Product Owner e dividido em Releases.
No Scrum, so realizadas iteraes chamadas de Sprints. Se-
gundo [Schwaber 2008], cada Sprint inicia-se com uma reunio
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 sero includas
nas iteraes de Sprint (Selected Backlog). A reunio 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 ento define
colaborativamente o que poder entrar no desenvolvimento
da prxima Sprint, considerando sua capacidade de produo.
Na segunda parte (Sprint Planning 2), o time planeja seu traba-
lho, definindo o Sprint Backlog, que so as tarefas necessrias
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 concluso.
Na execuo das Sprints, diariamente o time faz uma reunio
de 15 minutos para acompanhar o progresso do trabalho e
agendar outras reunies necessrias. Ao final da Sprint, re-
alizada a reunio de reviso (Sprint Review Meeting) para que
o time apresente o resultado alcanado na iterao ao Product
Owner. Neste momento as funcionalidades so inspecionadas
e adaptaes do projeto podem ser realizadas. Em seguida o
Scrum Master conduz a reunio de retrospectiva (Sprint Retros-
pective Meeting), com o objetivo de melhorar o processo/time
e/ou produto para a prxima Sprint.
O monitoramento do progresso do projeto realizado atravs
de grficos de acompanhamento (Burndown Charts). Eles so
um excelente mecanismo para visualizar a correlao 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: Adaptao de [7])
Mapeando o Scrum para as reas de processo do MPS.
BR nvel G
Para cada rea de processo do MPS.BR nvel G foi realizada
uma anlise detalhada entre os resultados esperados do MPS.BR
e as prticas encontradas no Scrum, classificando cada resultado
esperado de acordo com os critrios estabelecidos na Tabela 1.
Para avaliar o processo segundo o mtodo de avaliao do
MPS.BR (MA-MPS), o processo de desenvolvimento da orga-
nizao avaliado baseado em evidncias (diretas e indiretas)
de um conjunto de atividades e tarefas para atingir este pro-
psito. Portanto, estes aspectos no foram considerados no
escopo deste trabalho, pois o mapeamento foi realizado com
o objetivo somente de tornar a organizao aderente ao guia
e no para fins de certificao.
Classificao Critrio
NS No Satisfeito No h evidncias da prtica na metodologia
PS Parcialmente Satisfeito
H evidncias da prtica na metodologia, embora a prtica no
esteja plenamente atendida.
S Satisfeito
A prtica est totalmente atendida na Metodologia.
Tabela 1. Critrios para classificao das reas de processO
Aps a realizao da classificao, conforme os critrios acima
estabelecidos, foram calculados os percentuais de satisfao de
cada rea de processo entre os critrios definidos, tomando como
base o nmero total de resultados esperados de cada rea.
Para o processo de desenvolvimento de software de uma
organizao estar totalmente aderente ao nvel G do MPS.BR,
necessrio tambm atender aos atributos de processo AP 1.1 e
AP 2.1 no que se refere aos resultados esperados RAP1 a RAP8.
Por essa razo, tambm foi realizado o mapeamento entre os
atributos de processo acima relacionados e o novo processo
de software da empresa em questo.
O mapeamento detalhado apresentando os pontos que o
Scrum satisfaz ou no os resultados esperados do MPS.BR
nvel G (Gesto de projetos e Gerenciamento de requisitos)
pode ser encontrado em [15].
Os resumos das anlises para os processos de Gesto de
Projetos (GPR) Gerenciamento de Requisitos (GRE) so apre-
sentados nas Tabelas 2 e 3, respectivamente.
MPS.BR Nvel G SCRUM
rea de Processo Abrev. Objetivos Classificao Resumo das Prticas
G
e
s
t
o

d
e

P
r
o
j
e
t
o
s
(
G
P
R
)
GPR1 Escopo do trabalho Satisfeito Elaborao da Viso do Produto e Definio dos Itens de Backlog (IBL)
GPR2 Dimensionamento de tarefas e produtos de trabalho Parcialmente Satisfeito Estimativas atravs de Story Points
GPR3 Modelo e as fases do ciclo de vida do projeto Satisfeito Iterativo incremental. Fases: Pregame, Game e Postgame
GPR4
Estimativa de esforo e o custo baseado em dados histricos ou
referncias tcnicas
Parcialmente Satisfeito
Retorno sobre o Investimento (ROI), Estimativas atravs de Story Points e
diviso de IBLs em tarefas
GPR5 O oramento e o cronograma do projeto Parcialmente Satisfeito Planejamento de Sprints e Estimativas atravs de Story Points
GPR6 Riscos do projeto Satisfeito Daily Meetings, Impediment Backlog e responsabilidades do Scrum Master
GPR7 Planejamento de recursos humanos Satisfeito
Definio 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 segurana)
No Satisfeito Prtica no mencionada no Scrum
GPR10 Planos para a execuo do projeto Satisfeito Viso do Produto,Product Backlog,Sprint Backlog,Sprint planning 1 e 2 e Daily meeting
GPR11 Avaliao de viabilidade de atingir as metas do projeto Satisfeito
Sprint Planning (1 e 2) e Definio do objetivo da iterao na elaborao do
Sprint Backlog
GPR12 Reviso 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
Revises so realizadas em marcos do projeto e conforme
estabelecido no planejamento
Satisfeito Sprint Review Meeting
GPR16 Identificao e registros de problemas Satisfeito Daily Scrum Meeting e Impediment Backlog
GPR17 Aes para corrigir e prevenir desvios em relao 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 - Nvel G SCRUM
rea de Processo Abrev. Objetivos Classificao Resumo das Prticas
G
e
r
e
n
c
i
a
m
e
n
t
o

d
e

R
e
q
u
i
s
i
t
o
s

(
G
R
E
)
GRE1 Entendimento dos requisitos Satisfeito Viso do produto, Definio de itens de Backlog e Elaborao das tarefas da Sprint
GRE2 Aprovao de requisitos Satisfeito
Aprovao de requisitos atravs do Business Value (BV), Priorizao de requisitos (ROI) e
Sprint Planning (1 e 2)
GRE3
A rastreabilidade bidirecional entre os
requisitos e os produtos de trabalho
No Satisfeito Prtica no mencionada no Scrum
GRE4
Revises em planos e produtos de trabalho
do projeto
Satisfeito Daily Scrum Meeting e Sprint Review Meeting
GRE5 Gerenciamento de mudanas 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
METODOLOGI AS GEI S
Resultado do mapeamento
Este comparativo entre o Scrum e as reas de processo do
MPS.BR nvel G teve por objetivo mapear o alinhamento e a
conformidade entre eles. A partir deste mapeamento desco-
brimos que o Scrum no satisfaz totalmente o nvel G do MPS.
BR, conforme apresentado na Figura 3.
0%
20%
40%
60%
80%
Satisfeito 76% 80%
Parcialmente
Satisfeito
18% 0%
No Satisfeito 6% 20%
GPR GRE
Figura 3. Resultado Geral da Avaliao
Este resultado se deve a alguns fatores, tais como:
Lacunas na definio de um mtodo apropriado de comple-
xidade ou tamanho para estimativas, impactando diretamen-
te no resultado esperado GPR2 e indiretamente no GPR5;
Ausncia de utilizao de dados histricos organizacionais
ou referncias tcnicas para definio de esforo e custo de
um projeto, afetando o resultado esperado GPR4;
Ausncia de definio de privacidade e segurana no aces-
so s informaes do projeto, comprometendo totalmente o
GPR9;
Ausncia de rastreabilidade entre os requisitos e produtos
de trabalho, afetando diretamente o GRE3.
Portanto, para implementao de um processo aderente
s prticas definidas nas reas de processo do nvel G do
MPS.BR, foi necessrio complementar o Scrum com prticas
adicionais conforme visto na prxima seo.
Estendendo o Scrum para o MPS.BR nvel G
Baseado no resultado geral do comparativo entre o Scrum
e as reas de processo do MPS.BR nvel G, para as lacunas
encontradas (itens Parcialmente Satisfeito e No satisfei-
to), solues complementares foram adicionadas ao processo,
conforme descrio abaixo.
GAP1 Lacunas na definio de um mtodo apropriado de
complexidade ou tamanho para as tarefas e os produtos de
trabalho do projeto, impactando diretamente o GPR2.
Para realizao da estimativa das tarefas foi indicado o uso
da tcnica 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 sequncia
de Fibonacci. Inicialmente escolhe-se a funcionalidade de
menor complexidade e atribui a ela a pontuao 2 (dois) para
servir como referncia. A partir deste item de backlog so
realizadas estimativas relativas para os demais itens. Caso
haja divergncias entre as cartas mostradas, as pessoas que
atriburam 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 Ausncia de estimativa do esforo e o custo para a
execuo das tarefas e dos produtos de trabalho com base em
dados histricos ou referncias tcnicas.
O Scrum no menciona a utilizao de dados histricos
organizacionais, ou seja, ele somente define a utilizao de
dados de Sprints anteriores para o mesmo projeto. Portanto,
para definio dos custos e esforo sero analisados dados
histricos organizacionais mantidos atravs de um documen-
to que contempla informaes de projetos anteriores.
GAP3 Ausncia de definio do oramento.
Para definio do oramento ser utilizada a poltica de
negociao da empresa em questo. Este documento fornece
orientaes sobre os procedimentos a serem observados na
negociao dos projetos de software da empresa no tocante s
regras em relao s pessoas, condutas, vedaes, divulgao
de informaes e violaes.
GAP4 Ausncia de privacidade e segurana no acesso s
informaes.
A proposta armazenar as informaes coletadas no projeto
utilizando a poltica de segurana, acesso e armazenamento
das informaes de projetos. Este documento define a estra-
tgia para implementao nos projetos da empresa no que se
refere infraestrutura (confiabilidade, segurana e estabilida-
de) e nvel operacional (nveis de usurios, responsabilidades,
limites e controle de verses).
GAP5 Ausncia de rastreabilidade entre os requisitos e
produtos de trabalho.
Para a rastreabilidade vertical cada item de Backlog (IBL) ser
inicialmente identificado, ento, na criao do Sprint Backlog
cada tarefa estar associada a um IBL e os artefatos de enge-
nharia estaro associados ao IBL correspondente. Portanto, a
rastreabilidade vertical pode ser distribuda em cada artefato
gerado, como por exemplo, o cdigo implementado.
Adaptando a extenso no processo de uma Fbrica
de Software
Para validao deste trabalho, foi implementada a extenso
proposta na CRIATIVA Tecnologia, que uma empresa de
tecnologia que cria produtos e servios utilizando Tecno-
logia da Informao (TI). Atualmente a empresa conta com
cerca de trinta colaboradores, atendendo diversos clientes e
atuando em trs reas de negcio: fbrica de software, trei-
namentos e prestao de servios tcnicos em equipamentos
eletrnicos.
Histrico de melhoria de processos da CRIATIVA
Os trabalhos em melhoria de processo de software na CRIA-
TIVA iniciaram cerca de trs anos aps a sua fundao (2003),
onde aps um crescimento significativo de sua base de clientes, a
empresa comeou a apresentar diversos problemas relacionados
ao processo de produo de software. Baseado neste contexto,
foi realizada a modelagem de um processo de desenvolvimento
baseado no guia MPS.BR nvel G [14], onde no perodo inicial
pode-se notar melhorias. Entretanto, aps alguns meses de uti-
lizao, alguns fatores impactaram negativamente na empresa
em relao ao processo que foi definido, tais como: dificuldade
em seguir o processo, produo de artefatos desnecessrios,
desmotivao dos colaboradores, entre outros.
Em seguida foi proposto o desenvolvimento de um novo
processo de software que proporcionasse maturidade para a
organizao e que ao mesmo tempo tivesse seu foco nos prin-
cpios 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 trs 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 questo, para todas as fases
deste novo processo foram descritas suas etapas, objetivos,
conceitos chave e quadros de estruturao de cada atividade
com seus respectivos papis, entradas, sadas e artefatos.
Fase PREGAME: Esta fase tem como objetivos delimitar o
escopo do projeto, verificar a viabilidade econmica e elimi-
nar riscos a partir de uma arquitetura estvel. 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 incio atravs da criao
da Viso do Produto, acessvel por todos e de responsabilidade
do Product Owner.
O Product Backlog outro artefato de responsabilidade do
Product Owner (PO), mas tambm atualizado pelo time, em
comum acordo com o PO. Pode conter requisitos funcionais
e no funcionais.
Conceitos chave da subfase Staging
Esta subfase uma continuao da subfase inicial Planning, mas
com o foco voltado definio de algumas atividades, como:
organizao da infraestrutura para desenvolvimento do projeto,
definio da arquitetura, definio do plano de comunicao,
elaborao do Release Plan e realizao da reunio de kick-off.
Fase GAME: esta fase (Figura 6) tem como objetivo criar
releases do produto podendo obter verses funcionais do sof-
tware. Nesta direo, 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 reunies dirias, as tarefas
so 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 reunies da Sprint que so divididas
em dois nveis, Sprint Planning 1 e Sprint Planning 2. A Sprint
Planning 1 uma reunio que tem por objetivo a verificao
de dados histricos organizacionais, priorizao de IBL da
Sprint, seleo dos IBLs que iro compor a Sprint e elaborao
da Sprint Backlog. A Sprint Planning 2 a segunda reunio de
planejamento com participao do time e do Scrum Master
para realizao de atividades como: definio de tarefas (Task)
necessrias para realizao da Sprint, diviso das tarefas da
Sprint entre a equipe, anlise da capacidade produtiva da
equipe e atualizao do Task Board.
Ao final das Sprint Planning 1 e 2, a obteno de compro-
misso e revises 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
entregvel.
Figura 5. Fase PREGAME
METODOLOGI AS GEI S
Durante a execuo da Sprint realizada a atividade Daily
Scrum, que uma reunio diria onde o time monitora o
progresso da execuo das atividades e procura identificar
os impedimentos encontrados.
Posteriormente, o Scrum Master trabalha no sentido de
elaborar aes para resolver tais impedimentos e dissemi-
nar a soluo para o time. Atualizaes na Sprint Backlog e
Product Backlog so realizadas para controlar o progresso
das Sprints.
Fase POSTGAME: esta fase (Figura 7) tem como objetivos
apresentar o produto ao cliente para validao, realizar uma
reunio para melhoria do processo e avaliar a capacidade
produtiva do time.
Conceitos chave da fase POSTGAME
A reunio de reviso da Sprint, chamada de Sprint Review
Meeting, fornece algumas vises para todos os envolvidos,
tais como: visibilidade se a meta da Sprint foi alcanada,
apresentao de resultados, inspeo de funcionalidades para
possveis mudanas e adaptaes, e a reunio 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 so realizados iniciando-se
pela fase GAME.
Ao final, informaes coletadas no projeto so armazenadas
para utilizao em projetos futuros formando a base de dados
de histrico organizacional.
Estudo de Caso
Visando avaliar os efeitos da aplicao da extenso proposta
neste artigo, foi realizado o estudo de caso na empresa em
questo em projetos de software selecionados com base na
semelhana das caractersticas de domnio, escopo, arquite-
tura, tempo, custo e equipe.
A definio das mtricas para realizao 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-
fao do cliente e quantidade de bugs.
Figura 7. Fase POSTGAME
Como resultado da avaliao da mtrica entregas no prazo,
foi possvel observar que, apesar do time no ter conseguido
completar 100% das tarefas que foram atribudas iterao,
pode-se observar um aumento de 42,5% de entregas no
prazo.
Para medir a satisfao dos clientes, foi aplicado um ques-
tionrio em relao a diversos aspectos, entre eles: comunica-
o, qualidade do produto, gerenciamento de mudanas, en-
tregas no prazo, dentre outros. Para avaliar o processo foram
utilizados trs indicadores (Atende Totalmente, Atende
Parcialmente e No atende), sendo que para cada questo,
o questionrio disponibilizou orientaes de como ela deveria
ser avaliada. Foi possvel observar que o projeto que utilizou
o novo processo de desenvolvimento obteve aumento de
57,14% das respostas atendem totalmente no questionrio,
proporcionando uma grande reduo nos valores para as
respostas que atendem parcialmente (46,39%) e manuteno
da ausncia de respostas que no atendem o cliente.
Para medir a quantidade de Bugs, foram coletados os dados
na ferramenta Bug Tracker da empresa, e pde-se observar que
o Projeto que utilizou o novo processo teve um nmero menor
de Bugs que o processo anterior (equivalente a 75%).
Atravs das mtricas apresentadas anteriormente, pode-se
observar que h indcios 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:
O quadro de tarefas (Taskboard) proporcionou uma grande
visibilidade do andamento das tarefas;
A participao da equipe nas decises do projeto proporcio-
nou comprometimento e motivao na realizao das tarefas
dirias;
Atravs das reunies dirias pde-se monitorar a produo do
time, promover feedback e remover impedimentos que poderiam
atrasar o bom andamento do desenvolvimento da Sprint.
A medio de entregas no prazo proporcionou a visibilidade
da performance da empresa no cumprimento dos prazos esta-
belecidos, aumentando a eficincia em projetos futuros devido
ao ajuste realizado na capacidade de produo do time (Velocity)
a cada novo ciclo iterativo do novo processo (Sprint).
A satisfao dos clientes uma forma de identifcar a qualidade
do software que foi produzido, que por sua vez auxiliada por
um processo de desenvolvimento efcaz.
Ao identificar a satisfao dos clientes da empresa em questo,
observa-se que aps a implementao deste novo processo, eles
esto apresentando um nvel mais alto de satisfao comparado ao
processo anterior, o que significa que a CRIATIVA obteve efeitos
positivos no seu novo processo de desenvolvimento. No entanto,
podem-se observar situaes onde a empresa deve melhorar
ainda mais a qualidade dos servios prestados, tais como:
Melhoria na qualidade do produto: Apesar da diminuio na
quantidade de bugs na fase de desenvolvimento, durante os testes
de aceitao foram registradas solicitaes de mudanas;
Cumprimento dos prazos: Apesar de ter melhorado a taxa de
entrega, ainda pode ser observado falha no cumprimento dos
prazos acordados.
A medio da quantidade de bugs na ferramenta Bug Tracker
proporcionou grande visibilidade e acompanhamento da soluo
dos mesmos ao final de cada iterao dos projetos. Devido par-
ticipao constante do Scrum Master, proximidade dos membros
do time e colaborao do cliente, o nmero de bugs diminuiu
consideravelmente.
Concluso
Este trabalho apresentou a extenso do framework Scrum para
as reas de processo de Gesto de Projetos e Gerenciamento de
Requisitos contempladas no MPS.BR nvel G.
No mapeamento entre o Scrum e o guia MPS.BR nvel G, desco-
briu-se que ele no cobre totalmente os resultados esperados do
guia, mas pode ser um ponto de partida, pois proporciona uma
base fundamental para empresas que esto iniciando a melhoria
de processos, principalmente as que dispem de poucos recursos
como as micro e pequenas empresas.
Visto que aps o mapeamento ainda restaram alguns resultados
esperados do MPS.BR no cobertos plenamente pelas prticas do
Scrum, outras alternativas foram pesquisadas e relacionadas na
extenso proposta neste projeto para adaptao do processo de
uma fbrica de software.
A extenso relacionada ao gerenciamento de requisitos atra-
vs de abordagens geis foi uma forma alternativa e eficaz de
gerenciar requisitos e solicitaes de mudanas durante o desen-
volvimento do projeto, evitando o retrabalho.
A extenso relacionada gesto gil de projetos foi uma alterna-
tiva capaz de gerar inovao, diminuio 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 avano inicial no
sucesso de um projeto de software desenvolvido pela empresa,
mas como se encontra ainda em fase de implantao, o monito-
ramento se faz necessrio para obteno da melhoria contnua e
obteno de melhores resultados.
D

s
e
u
Feedba
c
k
s
o
b
r
e

e
s
t
a
e
d i 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 Maro 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. Maral, 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 Isnt 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 nvel G na melhoria do processo de software em
uma pequena empresa.Simpsio Mineiro de Sistemas de Informao.Lavras,UFLA.
15. Szimanski, F. (2009). Extenso do Scrum segundo as reas de processo do MPS.BR nvel G.
Dissertao de mestrado.Recife,CESAR.
Referncias
Bruno Gis Borges
gois.mg@gmail.com
arquiteto de sistemas e trabalha com
desenvolvimento de software a mais de 12
anos. Bacharel em cincia da computao
e ps-graduado em desenvolvimento web
pela FURB e FFM - Blumenau. consultor em
engenharia de software.
Este artigo pretende contribuir para a anlise da quali-
dade e complexidade do cdigo OO, assim como auxi-
liar no entendimento dos benefcios das mtricas.
Para que serve?
A gerncia de um produto de software atinge um de-
terminado estado de qualidade e preciso se existirem
medidas que tornem possvel a administrao atravs
dos aspectos do sistema. A mtrica de software uma
medida de propriedades do sistema que podem ser
defnidas como caminhos para determinar quantitati-
vamente a dimenso em que o produto, a sequencia e
o projeto de software tm certas caractersticas.
Para gerenciar produtividade e qualidade ne-
cessrio saber se ambas esto melhorando ou
piorando. Isto implica na necessidade de mtricas
que indiquem as inclinaes do desenvolvimento
de sistema
Extrao de mtricas em software orientado
a objetos
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
P
ara gerenciar produtividade e
qualidade necessrio saber se
ambas esto melhorando ou pio-
rando. Isto implica na necessidade de
mtricas que indiquem as inclinaes
do desenvolvimento de sistema. Assim,
a gerncia de um produto de software
atinge um determinado estado de qua-
lidade e preciso se existirem medidas
que tornem possvel a administrao
atravs dos aspectos do sistema. A
mtrica de software uma medida de
propriedades do sistema que podem ser
definidas como caminhos para determi-
nar quantitativamente a dimenso em
que o produto, a sequencia e o projeto de
software tm certas caractersticas.
Neste contexto, o processo de software
estar sob controle se for adotada uma
poltica de coleta de dados e documen-
tao durante o desenvolvimento do
projeto. O objetivo da mensurao
abastecer engenheiros e gerentes de
16 Engenharia de Software Magazine - Extrao de mtricas em software orientado a objetos
produtos com um grupo de informaes palpveis para se
projetar, gerenciar, controlar, estimar e melhorar os projetos
com maior eficcia [20]. Segundo Crtes e Chiossi (2001), quan-
do so calculadas mtricas, pretende-se obter dados que iro
proporcionar opes para uma melhoria. Este o objetivo da
mtrica de software, o estudo dos fatores que influenciam o
rendimento atravs da qualificao dos projetos de desenvol-
vimento de software.
Entre as principais inquietaes nas fbricas de software
encontra-se a possibilidade de se criar um sistema de uma
maneira mais rpida e a um custo mais baixo. As prticas ba-
seadas em objetos tendem a simplificar o projeto de softwares
complexos. Para Amber (1998), as organizaes escolhem a
orientao 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 anlise da qualidade e
complexidade do cdigo OO, assim como auxiliar no entendi-
mento dos benefcios das mtricas. Para isso, ser apresentado
o desenvolvimento de uma ferramenta capaz de efetuar a coleta
de mtricas de software OO a partir da anlise de cdigos
fontes escrita em linguagem C# e Java.
Origem do Sistema Mtrico
As mtricas originaram-se da execuo prtica de avaliao
para quantificar indicadores sobre o processo de desenvolvi-
mento de um sistema, sendo adotados a partir de 1970. Existem
quatro tendncias desta rea que so:
a) Medida da complexidade do cdigo: criada em meados de
1970, os conjuntos mtricos foram fceis de atingir desde que
fossem calculados pelo prprio cdigo automatizado;
b) Estimativa do custo de um projeto de software: esta tcnica
foi desenvolvida em meados de 1970, estimando o trabalho e
o tempo gasto para se desenvolver um software, baseando-se
alm de outros fatores, no nmero de linhas de cdigo utili-
zados na implementao do sistema;
c) Garantia da qualidade do software: a melhoria destas
tcnicas teve maior repercusso entre os anos de 1970 e 1980,
dando-se destaque identificao de informaes faltantes,
durante as etapas do ciclo de vida do software;
d) Processo de desenvolvimento do software: o projeto de
software ganhou importncia e complexidade, sendo que a
necessidade de se administrar este processo foi emergencial.
O processo incluiu a definio do ciclo de vida do software
atravs da definio da seqncia das fases do desenvolvi-
mento, dando mais destaque ao gerenciamento e controle de
recursos deste projeto.
A partir do aparecimento destas tendncias, os desenvolve-
dores de sistema comearam a usar mtricas no propsito de
adequar o processo de desenvolvimento de software.
Importncia das Medies
Se no conhecida a complexidade de um software no 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 utilizao da medio de
software. As mtricas podem medir cada estgio do desen-
volvimento e diversos aspectos do produto. Mtricas ajudam
a compreender o processo utilizado para a implementao de
um sistema. De acordo com Pressman, o processo medido
com o propsito de melhor-lo e o produto mensurado com
o intuito de ampliar sua qualidade.
Medidas so necessrias para examinar a qualidade e o rendi-
mento do processo de desenvolvimento e manuteno do produto
de software implementado. Assim, as empresas devem estabele-
cer mtricas apropriadas e manter procedimentos para monitorar
e medir as caractersticas de suas operaes que possam causar
impacto significativo na qualidade de seus produtos [5].
Objetivos da utilizao de mtricas
A utilidade das mtricas deve ser traada desde o incio da
implantao de mtricas para avaliao de software. H vrias
caractersticas 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 utilizao das
mtricas;
b) As mtricas devem ser simples de atender e de serem utili-
zadas para verificar atendimentos de objetivos e para subsidiar
processos de tomadas de deciso;
c) As mtricas devem ser objetivas, visando reduzir ou mini-
mizar a influncia do julgamento pessoal na coleta, clculo e
anlise dos resultados.
Para Ambler (1998), as mtricas podem ser utilizadas para:
a) Estimar projetos: baseado em experincias anteriores pode-
se utilizar mtricas para estimar o tempo, o esforo e o custo
de um projeto;
b) Selecionar as ferramentas;
c) Melhorar a abordagem de desenvolvimento.
Em uma organizao que se dedica ao desenvolvimento de
software, seja como atividade-fim seja como de suporte para
uma empresa, h vrios objetivos que se busca atingir, depen-
dendo do estgio de maturidade em que se encontram essas
atividades. Alguns dos objetivos perseguidos geralmente se
enquadram na seguinte relao:
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 satisfao dos usurios 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) Aperfeioar continuamente os mtodos de gesto do projeto;
i) Aperfeioar continuamente o processo e o produto;
j) Avaliar o impacto de atributos no processo de desenvolvi-
mento, tais como novas ferramentas;
k) Determinar tendncias relativas a certos atributos do
processo.
MEDI O
Um dos aspectos que deve ser observado quando da imple-
mentao de iniciativas de utilizao de mtricas quanto a
sua utilidade no contexto de um projeto ou do ambiente como
todo, alm dos tipos e categorias de mtricas, usurios das
mtricas, pessoas para as quais os resultados das mtricas so
destinados e os seus nveis de aplicao.
O processo de medio e avaliao 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 determinao do
objetivo da medio. A definio de tal objetivo abre caminho
para algumas perguntas que definem um conjunto especfico
de dados a serem coletados. Os objetivos da medio e da
avaliao so consequncias das necessidades da empresa, que
podem ser a necessidade de avaliar determinada tecnologia, a
necessidade de entender melhor a utilizao dos recursos para
melhorar a estimativa de custo, a necessidade de avaliar a qua-
lidade do produto para poder determinar sua implementao
ou a necessidade de avaliar as vantagens e desvantagens de
um projeto de pesquisa.
Assim, o objetivo primrio de se realizar medies no de-
senvolvimento de software obter nveis cada vez maiores
de qualidade, considerando o projeto, o processo e o produto,
visando satisfao plena dos clientes ou usurios a um custo
economicamente compatvel.
Mtricas tradicionais
A partir de agora sero apresentados alguns exemplos de
mtricas tradicionais.
Constructive Const Model
O modelo COCOMO calculado a partir do nmero de
linhas de cdigo fonte entregue ao usurio [7]. Este modelo
foi desenvolvido por Barry Boehm e resulta em estimativas
de esforo, prazo, custo e tamanho da equipe para um pro-
jeto de software. O COCOMO um conjunto de submodelos
hierrquicos, que pode ser dividido em submodelos bsicos,
intermedirios ou detalhados.
Linhas de Cdigo
O modelo LOC, a tcnica de estimativa mais antiga. Ela
pode ser aplicada para estimar o custo do software ou para
especificar igualdade de analogia. H muitas discusses e
especulaes sobre esta tcnica. Primeiramente, a definio
de linhas de cdigo no muito clara.
Um exemplo simples seria o caso de ser colocado ou no
um comentrio ou uma linha em branco como LOC. Alguns
autores consideram estes comentrios, no entanto, outros no.
No caso de programas recursivos, essa tcnica falha, porque
a recursividade torna o programa mais curto. O sistema LOC
uma tcnica genrica e superficial [11].
Outro problema da tcnica LOC que esta tcnica forte-
mente ligada linguagem de programao utilizada, impos-
sibilitando a utilizao de dados histricos para projetos que
no utilizam a mesma linguagem.
As vantagens do uso de LOC so [7]:
a) fcil de ser obtido;
b) utilizado por muitos modelos de estimativa de software
como valor bsico de entrada;
c) Existe farta literatura e dados sobre este sistema de mtrica.
As desvantagens so:
a) Dependncia de linguagem: no possvel comparar di-
retamente projetos que foram desenvolvidos em linguagens
diferentes. Como exemplo, pode-se verifica a quantidade de
tempo gasto para gerar uma instruo em uma linguagem de
alto nvel comparado com uma linguagem de baixo nvel;
b) Penalizam programas bem projetados: quando um progra-
ma bem projetado o mesmo utiliza poucos comandos para
execuo de uma tarefa;
c) Difceis de estimar no incio do projeto de software:
praticamente impossvel estimar o LOC necessrio para um
sistema saindo da fase de levantamento de requisitos ou da
fase de modelagem.
Com estas colocaes, nota-se que a mtrica LOC no uma
mtrica a ser utilizada por si s, ela deveria ser utilizada em
conjunto com outras mtricas, efetuando um comparativo de
resultados. Deste modo, uma mtrica poderia completar a outra,
fornecendo informaes que so pertinentes s caractersticas
de cada uma.
Medida de Cincia do Software
Halstead identificou a Cincia de Software originalmente
chamada de Fsica do Software como uma das primeiras
manifestaes sobre mtrica de cdigo baseada num modelo de
complexidade do software [18]. A idia principal deste modelo
a compreenso de que software um processo de manipulao
mental dos smbolos de seus programas.
Estes smbolos podem ser caracterizados como operadores (em
um programa executvel verbos como: IF, DIV, READ, ELSE e
os operadores propriamente ditos) ou operandos (variveis
e constantes), visto que a diviso de um programa pode ser
considerada como uma seqncia de operadores associados a
operandos.
Para Shepperd (1993), a cincia do software atraiu consideravel-
mente o interesse das pessoas em meados de 1970 por ser uma
novidade na metrificao do software. Alm disso, as entradas
bsicas do software so todas facilmente extradas. Aps o
entusiasmo inicial da cincia do software, foram encontrados
srios problemas. Os motivos podem ser relatados em funo da
dificuldade que os pesquisadores encontraram na comparao
dos trabalhos e evoluo da mtrica. Outro motivo seria a no
associao correta entre o esforo requerido para manipulao
do programa e o tempo exigido para conceber o programa e
tambm por tratar um sistema como um simples mdulo.
Mtrica da complexidade ciclomtica
Este mtodo foi proposto por McCabe, que estava particular-
mente interessado em descobrir o nmero de caminhos criado
pelos fluxos de controle em um mdulo do software, desde que
fosse relacionada dificuldade de teste e na melhor maneira de
dividir software em mdulos.
A idia desenhar num grafo a sequencia que um pro-
grama pode tomar com todos os possveis caminhos. A
complexidade calculada fornecer um nmero designando
o quo complexo um programa (ou seqncia).
Para possibilitar o clculo desta mtrica, os programas so
inicialmente representados por grafos dirigidos represen-
tando o fluxo de controle. De um grafo G, pode ser extrada
a complexidade ciclomtica v(G). O nmero de caminhos
dentro de um grafo pode ser dado como: o conjunto mnimo
de caminhos os quais podem ser utilizados para a constru-
o de outros caminhos atravs do grafo. A complexidade
ciclomtica tambm equivalente ao nmero de decises
adicionais dentro de um programa:
v(G) = E n + 2,
onde,
E: o nmero de arestas.
N: o nmero de ns.
A viso simplificada da mtrica de McCabe pode ser ques-
tionada em vrios pontos. Primeiro, ele tinha uma preocu-
pao especial com os programas escritos em Fortran, onde
o mapeamento do cdigo-fonte, para um grafo de fluxo do
programa era bem definido, sendo que isto no seria o caso
de outras linguagens como Ada. A segunda oposio que
v(G) = 1 seria verdadeiro em uma sequencia linear de cdigo
de qualquer tamanho. Consequentemente, a medio no
sensvel complexidade, contribuindo assim na formao
de declaraes de sequencia lineares.
A complexidade ciclomtica sensvel ao nmero de sub-
rotinas dentro de um programa, por este motivo, McCabe
sugere que este aspecto seja tratado como componentes no
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
vrios mdulos que se imagina serem sempre simples.
A Figura 1 demonstra um exemplo de complexidade ciclo-
mtica que ilustra o fluxo do grafo gerado para os caminhos
entre 1 e 9.
Mtricas para Orientao a Objetos
Embora exista farta literatura sobre como aplicar os mtodos
OO, a maioria no apresenta detalhes relativos qualidade.
A razo simples: o desenvolvimento de software utilizando
esse enfoque ainda no dispe de mtricas precisas e bem
entendidas que possam ser utilizadas para avaliar produtos e
processos de desenvolvimento nesta abordagem.
Muitas mtricas j foram desenvolvidas para geraes pas-
sadas de tecnologia e, em muitos casos, so usadas at para
desenvolvimento OO, porm no so muito coerentes, pois a
diferena 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 distncia
entre o problema do mundo real e sua abstrao.
A OO requer uma abordagem diferente tanto no desenvolvi-
mento do projeto quanto na implementao do mesmo, como
tambm nas mtricas de software, visto que usa objetos e no
blocos de construo fundamentais [17]. Dadas as diferenas
entre as duas vises, comum constatar que as mtricas de
software desenvolvidas para serem aplicadas aos mtodos
tradicionais de desenvolvimento no so facilmente mapeadas
para os conceitos OO.
Existem vrias propostas para mtricas OO que levam em
considerao as caractersticas bsicas e interaes do siste-
ma como: nmero de classes; nmero de mtodos; linhas de
cdigo por mtodo; profundidade mxima da hierarquia de
classes; a relao existente entre mtodos pblicos e privados;
entre outros. Tais mtricas baseiam-se na anlise detalhada
do projeto.
As mtricas OO podem ser separadas em duas categorias:
medidas relacionadas com processos e relacionadas com
produtos [10]. As mtricas relacionadas com processo so
utilizadas para mensurar o processo e o status do processo
de desenvolvimento do sistema, consistem em medir coisas
tais como: cronogramas ou nmeros 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 medies to metodicamente quanto possvel. A seguir
alguns exemplos de mtricas 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-
pecificao dos casos de uso, desenho do bloco, teste do bloco
e do caso de uso para cada objeto;
e) Nmero de diferentes tipos de falhas encontrados durante
revises;
f) Nmero de mudanas propostas nos modelos anteriores;
g) Custo da garantia de qualidade;
h) Custo para introduzir novas ferramentas e processo de
desenvolvimento.
Figura 1. Exemplo de clculo de complexidade ciclomtica
MEDI O
Estas medies podem formar uma base para o planeja-
mento do desenvolvimento de projetos futuros. Por exemplo,
conhecendo o tempo mdio gasto para especificar todos os
casos de uso. Estas medies, entretanto deveriam sempre
vir acompanhadas por uma indicao de exatido da medio
(tal como desvio padro), caso contrrio, no se tem senso de
exatido da previso. Deve-se observar tambm que estas
medies podem variar muito entre diferentes processos,
organizaes, aplicao e equipe. Portanto, perigoso tirar
concluses genricas sobre dados existentes sem considerar
as circunstncias.
As mtricas relacionadas com produtos so aquelas que so
utilizadas para controlar a qualidade do produto final. Elas
tradicionalmente so 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 aplicaes OO [10]. Entretanto, a mtrica mais comum,
linhas de cdigo, a menos interessante para sistemas OO, pois
s vezes o menor cdigo escrito o mais reutilizado e, muitas
vezes d maior qualidade ao produto.
A seguir sero exemplificadas algumas mtricas para OO.
Estas mtricas esto relacionadas em trs categorias: mtricas
de anlise, projeto e construo. Estas medidas podem ser utili-
zadas para auxiliar a melhorar os esforos de desenvolvimento
[1]. Elas podem identificar reas com problemas na aplicao
antes que elas apaream como um erro detectado pelo usu-
rio. As mtricas de projetos e construo alm de mensurar
aspectos importantes do sistema, so fceis de automatizar,
tornando-as mais fceis 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 criao de pessoas: uma pessoa pode
ser do tipo cliente ou funcionrio, por sua vez o funcionrio
pode ser do tipo horista, diarista ou mensalista; um funcion-
rio tem um cargo e deve estar em um departamento.
cd Data Model
Departamento
- Descri cao: Stri ng
- Chefi a: Funci onari oMensal i sta
Cargo
- Descri cao: Stri ng
- Ti tul acaoMi ni ma: Stri ng
Pessoa
- Nome: Stri ng
- Sexo: Stri ng
- DataNasci mento: TDateTi me
Cliente
- CPF: Stri ng
Funcionario
- Sal ari o: Real
- Al ocacao: Departamento
- CargoAtual : Cargo
+ Cal cul arSal ari o()
+ ObterSal ari o() : Real
FuncionarioHorista
- Val orHora: Real
- NumeroDi as: Integer
- NumeroHorasDi a: Integer
FuncionarioDiarista
- Val orDi a: Real
- NumeroDi as: Integer
FuncionarioMensalista
- Val orMes: Real
- Encargos: Real
+ Cal cul arEncargos()
-Chefi a
-CargoAtual
-Al ocacao
Figura 2. Exemplo de diagrama de classes
Faz sentido adicionar um peso s mtricas das classes para
produzir uma medida de complexidade do sistema. A maioria
das medidas examina atributos em termos dos conceitos de
OO como herana, polimorfismo e encapsulamento. Para tanto,
seria necessrio coletar um nmero significativo de contagens,
ou seja, seria necessrio tomar valores de vrios projetos e
dimension-los selecionando as classes, os mtodos e os atri-
butos desejveis para medir o tamanho e a complexidade de
um novo software.
Mtricas segundo Chidamber e Kemerer
Chidamber e Kemerer (1994, p. 41) propuseram seis mtricas
para o clculo de complexidade de sistema OO. As mtricas
chamadas de CK so timas referncias para anlise quan-
titativa, objetivando a concentrao de testes em classes que
possivelmente contm maior nmero de defeitos. A seguir
uma descrio de cada mtrica:
a) WMC: clculo do nmero de servios por classe. Um
alto WMC mostra que a classe tende a se tornar especfica
e seus servios possuem caractersticas que atendem a
necessidades individuais, restringindo sua reutilizao. O
nmero de servios mostra ainda qual o nvel de esforo
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 mtrica WMC
b) DIT: o nmero mximo de superclasses posicionadas
hierarquicamente acima da classe em questo. Um DIT ele-
vado mostra que muitas das caractersticas da classe foram
adquiridas por herana e so comuns a outras classes. Isso
mostra que as superclasses contm um alto nvel de abstrao,
o que significa que elas esto possivelmente preparadas para
possibilitar uma boa reutilizao. Em contrapartida, DIT pode
indicar que a classe herda muitos servios, aumentando a sua
complexidade (ver Figura 4);
A
B
D
C
DIT (C) = 2 DIT (C) = 2
A
B D
E
C
DIT (E) = 2 DIT (E) = 2
Figura 4. Exemplo da mtrica DIT
c) NOC: nmero de subclasses posicionadas imediatamente
abaixo da superclasse em questo ou filhos diretos. Um NOC
elevado indica um baixo nvel de abstrao, pois uma super-
classe com muitos filhos tende a conter poucas caractersticas
comuns a todas as subclasses. Um alto nmero de filhos diretos
tambm pode indicar problemas estruturais, uma vez que as
subclasses podem no se adequar abstrao implcita da
classe pai (ver Figura 5);
d) CBO: mostra qual o nvel de acoplamento entre as classes
da aplicao. Quanto maior a ligao entre elas, menor a pos-
sibilidade de reutilizao, pois a classe torna-se dependente
de outras classes para cumprir suas obrigaes. Portanto o
CBO est diretamente legado ao nvel de reaproveitamento.
Um alto acoplamento indica uma baixa independncia de
classe, o que aumenta consideravelmente a complexidade e,
em consequncia, o esforo de teste (ver Figura 6);
Chegada de Chegada de
mensagem mensagem
para o para o
objeto X objeto X
CBO (X) = 2 CBO (X) = 2
Figura 6. Exemplo da mtrica CBO
e) LCOM: nmero de acesso a um ou mais atributos em
comum pelos servios da prpria classe. Dessa forma, os ser-
vios tornam-se ligados pelos atributos, podendo indicar que
foram mal projetados, pois apresentam baixa coeso. Uma das
principais caractersticas do software OO apresentar uma
alta coeso nos mtodos, o que garante que esses exeram
sua funo adequadamente. Portanto importante manter o
LCOM da classe baixo (ver Figura 7);
Figura 7. Exemplo da mtrica LCOM
f) RFC: indica a capacidade de resposta que a classe tem ao
receber mensagens de seus objetos. Uma maior capacidade
de resposta requer uma estrutura de classe projetada para
A
B
D
C
NOC (A) = 1 NOC (A) = 1
A
B D
E
C
NOC (B) = 2 NOC (B) = 2
F
Figura 5. Exemplo da mtrica NOC
atender a essa particularidade gerando uma maior com-
plexidade, tornando necessrio um maior esforo de teste
(ver Figura 8).
Figura 8. Exemplo da mtrica RFC
Conhecidas as mtricas, temos na Tabela 1 o resultado do cl-
culo das mtricas OO para o modelo de classes da Figura 2.
Classe WCT DIT NOC CBO RFC LCOM
Pessoa 0 0 2 0 0 0
Cliente 0 1 0 0 0 0
Funcionrio 2 1 3 2 2 0
Cargo 0 0 0 0 0 0
FuncionarioHorista 1 2 0 0 1 0
FuncionarioMensalista 2 2 0 0 2 1
FuncionarioDiarista 1 2 0 0 1 0
Departamento 0 0 0 2 0 0
Tabela 1. Exemplo de calculo do modelo de CK para Figura 2
Mtricas segundo Lorenz e Kidd
Uma outra proposta de mtricas OO foi criada por Lorenz e
Kidd tem como base o clculo quantitativo de alguns aspectos
fundamentais da OO, como os atributos e servios, herana,
coeso e acoplamento. No diferindo das mtricas de CK no
foco, mas sim em sua metodologia de calculo. Abaixo segue a
descrio de cada mtrica definida:
a) CS: nmero de servios e atributos locais e herdados de su-
perclasses. Os servios e atributos pblicos das classes localiza-
das hierarquicamente acima e os da prpria classe em questo
compe o CS. Um grande CS torna a classe muito especfica,
pois sua estrutura atende a particularidades, o que restringe a
reutilizao, requerendo ainda maior esforo de testes, j que
a classe se torna mais complexa (ver Figura 9);
MEDI O
b) NOO: os mtodos definidos nas superclasses so herdados
pelas subclasses, mas, quando esses no atendem necessi-
dade individual da subclasse, podem ser redefinidos, ferindo
assim a abstrao implcita na superclasse. Um alto ndice de
NOO indica um problema estrutural. Se muitas subclasses
tm servios redefinidos, as subclasses possivelmente esto
hierarquicamente mal projetadas (ver Figura 10);
Atributo1
Metodo_Y
Metodo_Z
Metodo_X
Metodo_X
NOO (XE) = 1
Figura 10. Exemplo da mtrica NOO
c) NOA: se a classe contm um alto nmero de operaes e
atributos privados, ela torna-se muito especfica, diminuindo
as possibilidades de reaproveitamento. Pode-se dizer que um
alto NOA pode indicar uma falha de modelo. Muitas particu-
laridades mostram que a classe no est bem posicionada na
hierarquia, j que suas caractersticas principais deveriam estar
implcitas nos seus ancestrais (ver Figura 11);
d) SI: nmero de servios adicionados, eliminados ou rede-
finidos. Indica o nvel de especializao das classes ou as
alteraes efetuadas para atender necessidade individual
daquela classe (ver Figura 12).
Conhecidas as mtricas, temos na Tabela 2 o resultado do cl-
culo das mtricas OO para o modelo de classes da Figura 2.
CS (LCOM) = 3 CS (LCOM) = 3
cd Diagrama de Classes
Metricas
- FVal or: i nt
+ SetVal or(i nt) : voi d
+ GetVal or() : i nt
LCOM
- Codi go: i nt
Figura 9. Exemplo da mtrica CS
Atributo1
Metodo_Y
Metodo_Z
Metodo_X
NOA (XE) = 2
Metodo_A
Metodo_B
Metodo_A
Metodo_B
Figura 11. Exemplo da mtrica NOA
Uma tcnica muito interessante consiste em pesquisar intui-
tivamente o acoplamento e a coeso [11]. Um recurso bastante
utilizado por meio de grficos que demonstram ao analisador a
complexidade estrutural do produto e facilitam a identificao de
gargalos. A Figura 13 um modelo tridimensional da estrutura
de uma classe. Os cubos so atributos, acessados por mtodos
representados por esferas. Imediatamente percebido acopla-
mento ou no entre os mtodos do objeto, suas dependncias e
oportunidades de particionamento da classe em subclasses.
Outro recurso em forma de grfico muito interessante o pro-
posto por Kiviat, que auxilia no reconhecimento de problemas
SI = [NOO x DIT] / n total de mtodos da classe
Atributo1
Metodo_Y
Metodo_Z
Metodo_X
Metodo_A
Metodo_B
Metodo_X
Metodo_A
Metodo_B
Metodo_A
Metodo_B
Metodo_X
X
XE
D
C
X
XE
D
C
DIT (XE) = 1 DIT (XE) = 1 NOO (XE) = 1 NOO (XE) = 1
SI (XE) = 1 x x
WMC (XE) = 3 WMC (XE) = 3
SI (XE) = 0.3333 SI (XE) = 0.3333
1 / / 3
Figura 12. Exemplo da mtrica SI
Classe CS NOO NOA SI
Pessoa 3 0 3 0
Cliente 1 0 1 0
Funcionrio 5 0 3 0
Cargo 2 0 2 0
FuncionarioHorista 6 1 3 0
FuncionarioMensalista 6 1 2 0
FuncionarioDiarista 5 1 2 0
Departamento 2 0 2 0
Tabela 2. Exemplo de calculo do modelo de LK para Figura 2
de performance, um grfico circular em que as mtricas so
plotadas sobre retas radiais. Neste modelo, tem-se cada m-
trica representada. A linha vermelha o limite determinado
de acordo com os valores informados para cada mtrica, antes
da execuo do clculo. Os pontos vermelhos so as mtricas
que foram violadas. Os verdes significam que os valores
mximos definidos na mtrica esto de acordo com o que foi
calculado. Se houver ponto azul, o valor mnimo estabelecido
para mtrica no foi atingido. Na Figura 14 apresentado um
exemplo do grfico de Kiviat.
Figura 13. Visualizao da estrutura de uma classe
Figura 14. Exemplo do grfico de Kiviat
Ferramentas sobre Mtricas Orientadas a Objetos
Nesta seo sero apresentadas trs ferramentas relacionadas
a mtricas OO.
JMetric - Java Metrics Analyser
O JMetric propem a coleta de mtricas OO, o projeto foi
iniciado em abril de 1998 como parte de uma pesquisa refe-
rente a ferramentas de medio de mtricas em software OO.
A equipe de desenvolvimento concluiu com a pesquisa que
as ferramentas disponveis para o propsito no eram boas.
Ento o JMetric comeou a ser desenvolvida pela Univer-
sidade tecnolgica de Swinburne para coletar mtricas em
projetos Java. A ferramenta open-source e continua sendo
melhorada. Ao iniciar o JMetric apresentada a tela principal
(Figura 15).
Figura 15. Tela principal do JMetric
Para efetuar o clculo das mtricas do sistema o usurio
dever selecionar um projeto. Dever ser adicionado um ar-
quivo escrito em Java. Aps adicionar o arquivo, apresentada
uma rvore com a estrutura das classes, neste casso o objeto
TokenUtils(Figura 16).
Figura 16. rvore com a estrutura da(s) classe(s)
Aps a escolha do arquivo para o clculo, necessrio sele-
cionar a opo de calcular (Figura 17).
Figura 17. Calcular as mtricas JMetrics
Aps calcular as medidas, pose-se exibir de duas maneiras,
tabelas e grficos, de acordo com a documentao do projeto.
Portanto, a exibio em forma de tabela no foi possvel, pois
a ferramenta no apresentou nenhum resultado conforme o
grfico demonstrado na Figura 18.
MEDI O
Ferramenta para clculo de mtricas em Softwares Orien-
tados a Objetos codificados em Delphi
Em Seibt (2001) descrito um prottipo de uma ferramenta
para clculo de mtricas em software orientado a objetos. O
prottipo capaz de analisar o cdigo fonte de um projeto OO
em Delphi, extraindo as classes, seus mtodos e atributos para
posterior clculo de mtricas para software OO. A ferramenta
permite calcular dezenove mtricas de projeto e de construo,
entre estas, profundidade da rvore de herana e mtodos
ponderados por classe.
Mtricas para Programao Orientada a Objetos
Em Cardoso (1999) descrito o software implementado para
facilitar o clculo de mtricas em sistemas OO. O sistema
analisa o cdigo fonte de projetos em Delphi e fornece clculos
de mtricas como contagem de mtodos, classes sucessoras,
ascendentes e descendentes especficas para OO.
Desenvolvimento da ferramenta
A partir de agora apresentaremos como uma ferramenta que
possibilita analisar cdigo fonte OO em C# e Java e fornecer
algumas das mtricas estudadas foi construda.
Requisitos principais do problema a ser trabalhado
O objetivo do desenvolvimento foi disponibilizar uma
ferramenta capaz de calcular mtricas pr-definidas a partir
da anlise de cdigo fonte de projetos codificados em C# e
Java. As informaes para clculo das mtricas so coletadas
atravs da extrao das classes, mtodos e de seus atributos
atravs da anlise dos arquivos de um projeto em C# e Java,
exemplificada na Figura 19. Aps a coleta destes dados so
calculadas as mtricas estudadas.
Para extrair e identificar as informaes do cdigo fonte, os
dados das classes, foram utilizadas o Scanner e o Parser gerados
pela ferramenta CocoR for C#. O Scanner separa os Tokenz e o
Parser verifica a sintaxe do projeto.
Mtricas selecionadas
As mtricas de projeto e de construo so as mais indicadas
para se obter atravs da anlise do cdigo fonte, pois a maioria
das informaes necessrias para o clculo destas mtricas
pode ser obtida atravs de anlise automtica do cdigo fonte.
As mtricas a seguir foram as implementadas pelo software:
Nmero de servios por classe;
Nmero mximo de superclasses;
Figura 18. Demonstrao do grfico do JMetric
Nmero de subclasses;
Nvel de acoplamento entre as classes;
Nmero de acesso a um ou mais atributos em comum pelos
servios da prpria classe;
Capacidade de resposta da classe;
Nmero de servios e atributos locais e herdados;
Mtodos definidos nas superclasses herdados pelas
subclasses;
Nmero de operaes e atributos privados;
Nmero de servios adicionados.
Figura 19. Esquema de funcionamento do prottipo
Especificao do Software
Para a especificao do software foi utilizada a UML, que
apresentado atravs do diagrama de caso de uso, diagrama
de classes e do diagrama de sequencia. Estes diagramas se-
ro apresentados a seguir e foram construdos na ferramenta
Enterpreise Architect.
Diagrama de Caso de Uso
A ferramenta criada tem por objetivo facilitar a coleta de
mtricas em cdigos fontes. A Figura 20 exibe o diagrama de
casos de uso da ferramenta. A Tabela 3 descreve os casos de
uso exibidos na Figura 20, que se refere iterao do arquiteto
com os casos de uso.
Diagrama de Classes
No desenvolvimento do software foram identificadas 53
classes. Destas sero exemplificadas mtodos e atributos
pblicos de vinte e sete classes (Figura 21) que so utilizadas
para armazenar as informaes coletadas do cdigo fonte e
posteriormente auxiliar na obteno das mtricas. As outras
vinte e seis classes esto dividias entre interfaces e auxiliares,
no influenciam na exemplificao do funcionamento da
ferramenta.
A classe ColetaMetricas responsvel por iniciar a anlise
do cdigo fonte dos arquivos do projeto selecionado e a partir
desta anlise alimentar a classe ColetaMetricas, com objetos
Classe, que por sua vez ser composta com as classes Atribu-
tos, Servicos e Assinatura. A Tabela 4 descreve os mtodos da
classe ColetaMetricas.
ud Diagrama de Caso de Uso
Arquiteto
5 - Calcular
mtricas
3 - Selecionar
mtricas
6 - Salvar proj eto
7 - Abrir proj eto
2 - Selecionar
arquivos
individuais
4 - Definir limites
de algumas
mtricas
1 - Selecionar
arquivo de proj eto
Figura 20. Diagrama de caso de uso
Figura 21. Diagrama de classes
Caso de Uso Descrio
Selecionar arquivos de projeto Permite ao arquiteto de software escolher o projeto que ser
analisado, que pode ser um escrito em C# ou Java.
Seleciona arquivos individuais Permite ao arquiteto de software selecionar arquivos
individualmente para uma anlise especfica de um arquivo
escrito em Java ou C#.
Selecionar mtricas Permite ao arquiteto de software escolher as mtricas que sero
calculadas.
Salvar projeto Permite ao arquiteto de software gravar o resultado do clculo
das mtricas.
Abrir projeto Permite ao arquiteto de software carregar um projeto gravado
anteriormente.
Definir limites de algumas
mtricas
Permite ao arquiteto de software definir o limite mnimo e
mximo que uma determinada mtrica pode atingir.
Calcular mtricas Permite ao arquiteto de software calcular as mtricas a partir das
informaes selecionadas anteriormente.
Tabela 3. Descrio dos casos de uso do ambiente de coleta de mtricas
Mtodos Descrio
ColetaMetricas() Operao responsvel pela criao da classe.
AddClasse() Adiciona uma nova classe para coleta das mtricas.
GetClasse() Retorna um objeto Classe.
Coletar() Operao responsvel por iniciar a anlise do cdigo fonte para extrao dos
dados do projeto para posterior clculo das mtricas.
Tabela 4. Descrio dos mtodos da classe ColetaMetricas
MEDI O
A classe Scanner a que auxilia na anlise do cdigo fonte.
A mesma faz uma busca e extrao de identificadores, sm-
bolos especiais e palavras reservadas. A Tabela 5 descreve os
mtodos e atributos da classe Scanner.
Mtodos Descrio
SetColetaMetricas() Informa para a classe Scanner o objeto ColetaMetricas descrito anteriormente.
GetColetaMetricas() Retorna um objeto ColetaMetricas.
LoadFile() Responsvel por carregar o arquivo a ser analisado.
Scan() Operao responsvel por pegar o prximo smbolo para a anlise.
Peek() Avana para o prximo smbolo.
ResetPeek() Certifica-se de que o Peek() comece pela posio atual da busca.
Atributos Descrio
AddClass Armazena se foi adicionado uma classe.
Tabela 5. Descrio dos mtodos da classe Scanner
A classe ScannerCS uma extenso da classe Scanner, e tem
a funo de analisar do cdigo fonte escrito em C#. A Tabela 6
descreve os mtodos da classe ScannerCS.
Mtodos Descrio
ScannerCS(string) Operao responsvel pela criao da classe, informando o caminho do
arquivo que ser analisado.
ScannerCS(Stream) Operao responsvel pela criao da classe, informando o arquivo j
carregado que ser analisado.
Tabela 6. Descrio dos mtodos da classe ScannerCS
A classe ScannerJava uma extenso da classe Scanner, e
auxilia na anlise do cdigo fonte escrito em Java. A Tabela 7
descreve os mtodos da classe ScannerJava.
Mtodos Descrio
ScannerJava(string) Operao responsvel pela criao da classe, informando o caminho do
arquivo que ser analisado.
ScannerCS(Stream) Operao responsvel pela criao da classe, informando o arquivo j
carregado que ser analisado.
Tabela 7. Descrio dos mtodos da classe ScannerJava
A classe Parser responsvel pela anlise lxica e sinttica do
cdigo fonte. A Tabela 8 descreve o mtodo da classe Parser.
Mtodos Descrio
Error() Operao responsvel pelo disparo da mensagem de erro caso o parsing
retorne algum erro.
Tabela 8. Descrio dos mtodos da classe Parser
A classe ParserCS uma extenso da classe Parser, e auxilia
na anlise lxica e sinttica do cdigo fonte escrito em C#. A
Tabela 9 descreve o mtodo da classe ParserCS.
A classe ParserJava uma extenso da classe Parser, e auxilia
na anlise lxica e sinttica do cdigo fonte escrito em Java. A
Tabela 10 descreve o mtodo da classe ParserJava.
Mtodos Descrio
ParserJava() Operao responsvel pela criao da classe e iniciar a anlise.
Tabela 10. Descrio dos mtodos da classe ParserJava
A classe Errors responsvel pela notificao dos erros en-
contrados na anlise do cdigo fonte. A Tabela 11 descreve os
mtodos da classe Errors.
Mtodos Descrio
SynErr() Operao responsvel pela notificao dos erros sintticos.
SemErr() Operao responsvel pela notificao dos erros semnticos em uma
futura implementao.
Error() Operao responsvel pela notificao de erros diversos como arquivo
corrompido.
Tabela 11. Descrio dos mtodos da classe Errors
A classe ErrorsCS uma extenso da classe Errors, e auxilia
nos erros da anlise do cdigo fonte escrito em C#. A Tabela 12
descreve os mtodos da classe ErrorsCS.
Mtodos Descrio
SynErr() Operao responsvel pela notificao dos erros sintticos do cdigo fonte C#.
Tabela 12. Descrio dos mtodos da classe ErrorsCS
A classe ErrorsJava uma extenso da classe Errors, e auxilia
nos erros da anlise do cdigo fonte escrito em Java. A Tabela 13
descreve o mtodo da classe ErrorsJava.
Mtodos Descrio
SynErr() Operao responsvel pela notificao dos erros sintticos do cdigo fonte Java.
Tabela 13. Descrio dos mtodos da classe ErrorsJava
A classe Classe contm as informaes das classes encontra-
das no projeto analisado, sempre que uma classe encontrada,
um objeto Classe instanciado a partir do mtodo AddClasse()
da classe ColetaMetricas (Listagem 1). A Tabela 14 descreve
os mtodos e atributos da classe Classe.
Mtodos Descrio
ParserCS() Operao responsvel pela criao da classe e iniciar a anlise.
Tabela 9. Descrio dos mtodos da classe ParserCS
Mtodos Descrio
SetSuper() Informa para o objeto Classe qual a classe antecessora da mesma.
GetSuper() Retorna a descrio da classe antecessora.
SetAbstract() Informar se a classe abstrata ou no.
SetAbstract() Retorna se a classe abstrata ou no.
Atributos Descrio
Assinatura Contm o nome da classe.
Atributos Contm os atributos da classe.
Servio Contm os servios ou mtodos da classe.
CK Contm as mtricas previstas por Chidamber e Kemerer.
LK Contm as mtricas previstas por Lorenz e Kidd.
Tabela 14. Descrio dos mtodos da classe Classe
A classe Atributo contm as informaes dos atributos das
classes encontradas no projeto analisado. A Tabela 15 descreve
os mtodos da classe Atributos.
Mtodos Descrio
SetAtributo() Adiciona um atributo no objeto Atributo.
GetAtributo() Retorna a descrio do atributo solicitado.
Tabela 15. Descrio dos mtodos da classe Atributos
J a classe Servico contm as informaes dos servios ou
mtodos das classes encontradas no projeto analisado. A
Tabela 16 descreve os mtodos da classe Servico.
Mtodos Descrio
SetServico() Adiciona um servio no objeto Servio.
GetServico() Retorna a descrio do servio solicitado.
Tabela 16. Descrio dos mtodos da classe Servico
A classe Assinatura responsvel por definir a descrio
de outras classes. A Tabela 17 descreve os mtodos da classe
Assinatura.
Mtodos Descrio
SetAssinatura() Informa para o objeto Assinatura a descrio da mesma.
GetAssinatura() Retorna a descrio do objeto Assinatura.
Tabela 17. Descrio dos mtodos da classe Assinatura
A classe CK contm as informaes das mtricas previstas
por Chidamber e Kemerer descritas anteriormente neste artigo.
A Tabela 18 descreve os atributos da classe CK.
Atributos Descrio
WMC Contm o objeto de mtrica WMC.
CBO Contm o objeto de mtrica CBO.
RFC Contm o objeto de mtrica RFC.
LCOM Contm o objeto de mtrica LCOM.
NOC Contm o objeto de mtrica NOC.
DIT Contm o objeto de mtrica DIT.
Tabela 18. Descrio dos atributos da classe CK
A classe LK contm as informaes das mtricas previstas
por Lorenz e Kidd apresentadas anteriormente neste artigo.
A Tabela 19 descreve os atributos da classe LK.
Listagem 1. Instancia um objeto de Classe
public void AddClasse(string prClasse)
{
Classe classe = new Classe();
classe.Assinatura.SetAssinatura(prClasse);
Classes.Add(prClasse.ToUppper(), classe);
}
A classe Metricas contm as informaes referentes quan-
tidade calculada da mtrica. A Tabela 20 descreve os mtodos
da classe Metrica.
Atributos Descrio
SetValor() Informar para o objeto Metricas o valor calculado.
GetValor() Retorna o valor calculado.
Tabela 20. Descrio dos mtodos da classe Metricas
As classes WMC, CBO, RFC, LCOM, NOC, DIT, SI, NOA, CS
e NOO so extenses da classe Mtricas descrita na Tabela 20,
dando um destaque para as classes DIT e NOO que especiali-
zaram o construtor da classe Metricas. As Tabelas 21 e 22 des-
crevem os mtodos das classes DIT e NOO respectivamente.
Atributos Descrio
DIT() Operao responsvel pela criao da classe.
Tabela 21. Descrio dos mtodos da classe DIT
Atributos Descrio
NOO() Operao responsvel pela criao da classe.
Tabela 22. Descrio dos mtodos da classe NOO
Diagrama de Atividade
Na Figura 22 apresentado o diagrama de atividades, que
representa os passos para a realizao do clculo das mtricas.
A Tabela 23 descreve as atividades deste processo.
Atividades Descrio
Seleciona opo inicial O arquiteto de software escolhe criar um novo projeto ou
abrir um projeto existente.
Preencher dados do projeto O arquiteto de software preenche os dados referentes ao
projeto criado.
Selecionar projeto / arquivo(s) para o
clculo das mtricas
O arquiteto de software escolhe um projeto escrito em
C# ou Java para a coleta das mtricas.
Selecionar mtricas a serem coletadas O arquiteto de software define dentre as mtricas
propostas, as que sero coletadas.
Definir limites para cada mtrica O arquiteto de software informa o limite mnimo e
mximo que uma determinada mtrica pode atingir.
Calcular mtricas O arquiteto de software executa o clculo das mtricas.
Tabela 23. Descrio das atividades do processo de coleta das mtricas
Implementao
Consideraes sobre as tcnicas utilizadas para implemen-
tao do software, bem como a forma de operao do mesmo,
sero apresentadas nesta seo.
Atributos Descrio
CS Contm o objeto de mtrica CS.
NOA Contm o objeto de mtrica NOA.
SI Contm o objeto de mtrica SI.
NOO Contm o objeto de mtrica NOO.
Tabela 19. Descrio dos atributos da classe LK
MEDI O
Figura 22. Diagrama de atividades do processo de coleta das mtricas
No construtor da classe ColetaMetricas, atribudo dentre
outros parmetros, a lista de arquivos e o tipo do projeto a
ser coletada as mtricas conforme pode ser observado na
Listagem 2.
O processo de coleta de medidas iniciado atravs do
mtodo Coletar() da classe ColetaMetricas. Este mtodo
no recebe parmetro porque no construtor da classe j
foram passadas todas as informaes necessrias para a
coleta das mtricas.
O mtodo Coletar() faz um lao sobre a lista de arqui-
vos informado no construtor da classe ColetaMetricas no
parmetro prListaArquivos que foi atribudo ao atributo
FlistaArquivos (Listagem 2). A cada iterao do procedi-
mento Coletar() chamado o mtodo parse() que carrega o
arquivo informado no parmetro do mesmo (Listagem 3),
e iniciado o processo de anlise lxica e sinttica do texto
do arquivo segundo gramtica definida.
O mtodo parse() instancia as classes o atributo parser
e scanner (Listagem 3) de acordo com o atributo Ftype-
Project informado no construtor da classe ColetaMetricas
(Listagem 2).
Caso o processo de parsing ocorra sem nenhum erro, o
atributo Classes que est definido na classe ColetaMetricas
(Listagem 4) conter as mtricas coletadas do projeto.
Listagem 2. Atribuindo a lista de arquivos para coleta das mtricas e o tipo
do projeto
public ColetaMetricas(CheckedListBox prListFiles, ArrayLista prListaArquivos,
DataSet prDataSet, byte prTypeProject)
{
FListaArquivos = prListaARquivos;
FListaFiles = prListaFiles;
FDataSet = prDataSet;
FTypeProject = prTypeProject;
}
public void Coletar()
{
for (int i = 0; i < FListFiles.Items.Count; i++)
{
this.parse(FListaArquivos[i].ToString().Replace(\,\\).ToString()
+ \\ + FListFiles.Items[i].ToSting());
}
}
Listagem 3. Executando o analisador lxico e sinttico no arquivo informado
private void parse(string s)
{
fstream = File.Open(s, FileMode.Open, FileAccess.Read, FileShare.Read);
switch (FTypeProject)
{
case 0: //C#
scanner = new ScannerCS(s);
parser = new ParserCS(scanner);
break;
case 1: //Java
scanner = new ScannerJava(s);
parser = new ParserJava(Scanner);
break;
}

scanner.SetColetaMetricas(this);
parser.Parse(); // Analisa o cdigo
}
Listagem 4. Definio do atributos da classe ColetaMetricas
public class ColetaMetricas
{
private ArrayLista FListaArquivos;
private CheckedListBox FListFiles;
private FileStream fstream;
private Scanner scanner;
private Parser parser;
private Hashtable Classes = new Hashtable();
private DataSet FDataSet;
private byte FTypeProject;
Se existirem erros durante a anlise lxica e sinttica do texto
do arquivo, estes erros so informados conforme o cdigo ilus-
trado na Listagem 5. Neste caso, nenhuma mtrica coletada
e, portanto, no sero exibidas as medidas do projeto.
A gramtica ilustrada nas Listagens 6 e 7 ajudou na cons-
truo do analisador para a coleta das mtricas. Ela identifi-
ca em uma classe informaes como a declarao, estrutura,
declarao da estrutura, mtodos e atributos.
Tcnicas e ferramentas utilizadas
O software foi implementado no ambiente de desenvolvimen-
to Microsoft Visual C# 2005 Express Edition, utilizando a OO
ClassDeclaration
= class ident [extendsType] [implementsTypeList] ClassBody
.
ClassBody
={{ClassBodyDeclaration} }
.
ClassBodyDeclaration
=;
|[static] (Block
|[Modifier1 {Modifier} ] MemberDec1
.
MemberDec1
=IF(identAndLPar()) ident ConstructorDeclaratorRest
| MethodOrFiedlDec1
| void ident VoidMethodDeclaratorRest
| ClassDeclaration
| InterfaceDeclaration
.
MethodOrFieldDec1
= Type ident MethodOrFieldRest
.
MethodOrFieldRest
= VariableDeclaratorsRest ;
| MethodoDeclaratorRest
.
VariableDeclaratorsRest
= VariableDeclaratorRest {,VariableDeclarator}
.
ArrayInitializer
= }[VariableInitializer {IF(commaAndNoRBrace()) ,VariableInitializer}] [,]}
.
MethodoDeclaratorRest
= FormalParameters BracketOpt [throwsQualidentList] (Block | ;)
.
VoidMethodDeclaratorRest
= FormalParameters [throwsQualidentList] (Bloch | ;)
.
ConstructorDeclaratorRest
= FormalParameters [throwsQualidentList] Block
FormalParameters
=([Formal Parameter {,FormalParameter}])
Listagem 6. Gramtica da classe para linguagem Java
public void SynErr(int line, int col, int n)
{
string s;
switch (n)
{
case 0:
s = EOF expected;
break;
case 1:
s = ident expected;
break;
case 2:
s = intCon expected;
break;
case 3:
s = realCon expected;
break;
case 4:
s = charCon expected;
break;
case 5:
s = stringCon expected;
break;
case 6:

s = abstract expected;
break;
case 7:
s = as expected;
break;
case 8:
s = base expected;
break;
case 9:
s = bool expected;
break;
case 10:
s = break expected;
break;
case 11:
s = byte expected;
break;
case 12:
s = case expected;
break;
.
.
.
Listagem 5. Tratamento de erro
para o desenvolvimento do projeto. Para gerao do analisador
lxico e sinttico foi utilizado o Coco/R for C#, o que facilitou
bastante para que fosse dada total ateno coleta de mtricas.
J a gerao das palavras reservadas e da lista de tokens foi
gerada a partir da gramtica do C# e Java (Listagens 6 e 7).
Para a gerao do grfico foi utilizada a biblioteca GDI+ que
est disponvel no C# e para elaborao da ajuda foi utilizado
o HelpNDoc.
Operao
A partir de agora sero apresentadas as telas do software com
suas respectivas funcionalidades. Com o intuito de facilitar a
MEDI O
demonstrao e compreenso, ser realizada a coleta das m-
tricas de um projeto C# a partir do cdigo fonte das classes da
Figura 2 que contm as classes Pessoa, Cliente, Funcionario,
Cargo, Departamento, FuncionarioMensalista, Funcionario-
Horista e FuncionarioDiarista.
Dessa forma, ao iniciar o sistema ser apresentada a tela
principal do programa ao usurio como ilustra a Figura 23. A
ferramenta conta com opes de menu, barra de atalho e local
destinado a projetos.
Figura 23. Tela principal do software
Para iniciar um novo projeto no sistema o arquiteto de sof-
tware dever selecionar a opo Novo Projeto... ou clicar em
Projeto... conforme a Figura 24.
Para efetuar o clculo das mtricas de um sistema o arquiteto
de software dever selecionar um projeto. Esta seleo pode
ser de duas formas. A primeira selecionar um novo projeto
para coleta de mtricas. Aps a escolha, a guia Projeto
apresentada para o preenchimento dos dados do projeto como
pode ser visto na Figura 25.
Figura 24. Criao de um novo projeto no Visual Mtrica
Figura 25. Guia de informao dos dados do projeto
NamespaceMemberDeclaration (.Modifiers m = new Modifiers(this);.)
=
namespace ident {. ident}
{{ IF (IsExternaAliasDirective()) ExternAliasDirective} { UsingDirective }
{NamespaceMemberDeclaration} }[;]
| {Attributes} ModifierList<m> TypeDeclaration<m>
.
TypeDeclaration<Modifiers m> (. TypeKind dummy; .)
=
([partial]
( (. m.Check(Modifier.classes);.)
class ident [TypeParameterList]
[:TypeName {,TypeName}]
{TypeParameterConstraintsClause} StructBody [;]
| (. m.Check(Modifier.nonClassTypes); .)
struct ident [TypeParameterList]
{TypeParameterConstraintsClause} StructBody [;]
interface ident [TypeParameterList]
{TypeParameterConstraintsClause}
{{InterfaceMemberDeclaration} }[;]
)
enum ident [: InteggralType] EnumBody [;]
delegateType<out dummy, true> ident [ TypeParameterList ]
([FormalParameterList] )
{TypeParameterConstraintsClause } ;
)
.
ClassBase
=
: ClassType {,TypeName}
.
ClassBody
=
{{ { Attributes }
ModifierList<m>
ClassMemberDeclaracion<m>
}
}
Listagem 7. Gramtica da classe para linguagem C#
Figura 28. Tela de seleo de projetos salvo anteriormente
Aps informar os dados do projeto, dever ser selecionado o
projeto ou o(s) arquivo(s) para o clculo das mtricas. Na janela
ao lado dos dados do projeto, encontra-se uma outra janela com
o ttulo Selecionar Projeto. Para escolher um projeto basta
clicar no cone que representa uma lupa e ser apresentada
uma caixa de dilogo para abrir um arquivo (as extenses dos
arquivos a serem aberto so referentes a projeto C#, arquivos
individuais do C# e arquivos do Java consecutivamente, .vc-
proj, .cs, .java) conforme Figura 26.
Figura 26. Tela de abertura do projeto para anlise
Aps a escolha do projeto a ser analisado, listado o(s) arquivo(s)
na janela Selecionar Projeto conforme a Figura 27.
Figura 27. Lista dos arquivos referentes ao projeto selecionado
Com todos os dados do projeto preenchidos e o projeto esco-
lhido, dever ser selecionada a guia Mtrica para a escolha
das medidas que sero calculadas para o projeto conforme
visto na Figura 28.
Outra funcionalidade muito interessante da ferramenta a
possibilidade de definir limite mximo e mnimo de algumas
mtricas. Esta parametrizao por projeto e influencia dire-
tamente o resultado do clculo. Ao navegar pelas mtricas, a
descrio da mesma apresentada na parte inferior da tela na
janela Descrio como pode ser visto na Figura 29.
Aps a definio de todos os parmetros do projeto, informaes
referentes ao mesmo, mtricas a serem calculadas e os limites
das mtricas, devero ser calculadas as medidas deste cdigo
conforme ilustrada na Figura 30.
Durante o clculo das mtricas, algumas informaes so atua-
lizadas na tela como qual o arquivo que est sendo analisado no
momento e uma barra de progresso para informar o percentual
do que j foi calculada conforme ilustrada na Figura 31.
Aps o clculo das mtricas os resultados so apresentados
como mostra as Figuras 32 e 33. Estas telas listam todas as mtri-
cas selecionadas e calculadas para cada classe do projeto.
Outra opo interessante desta ferramenta a possibilidade de
analisar os resultados obtidos do clculo com o auxlio do grfico
proposto por Kiviat. Para analisar a classe escolhida basta clicar
com o boto direito do mouse na grade dos resultados em cima
da classe e ser exibida a opo de grfico conforme ilustrado
na Figura 34.
O grfico ser gerado com base nas informaes calculas
para a classe selecionada, respeitando os limites escolhidos na
Figura 29. Esta opo prope uma visualizao dos dados de
uma maneira mais intuitiva e no s com valores em grade que
pode se tornar confuso e pouco apresentvel. As mtricas que
influenciam no grfico so: WMC, DIT, NOO, CBO e LCOM. A
Figura 35 demonstra os dados em forma de grfico exemplificado
anteriormente neste artigo.
Figura 29. Tela de parametrizao de limite mximo e mnimo por mtrica
MEDI O
Depois de analisar um projeto, o arquiteto de software pode
salvar suas informaes em disco. Para isto basta escolher a
opo Arquivo e em seguida Salvar (Figura 36). Em seguida
apresentada a tela para escolha do nome que ser salvo, o
projeto e o seu diretrio (Figura 37).
Outra maneira de escolher um projeto para o clculo dessas me-
didas abrir um projeto analisado previamente e armazenado em
disco. Para tanto, o arquiteto de software deve selecionar a opo
Abrir na barra de atalho ou no menu escolher Arquivo e posterior-
mente Abrir Projeto. Ainda existe a opo de utilizar as teclas de
atalho CTRL+SHIFT+O. O sistema mostrar a tela da Figura 38,
que permite a escolha de um projeto salvo anteriormente.
Com o intuito de demonstrar o funcionamento da ferramen-
ta em um projeto escrito em Java, ser realizada a coleta das
mtricas das classes da Figura 39.
Figura 35. Grfico de Kiviat
Figura 30. Tela para o clculo das mtricas
Figura 31. Tela com informaes durante o clculo
Figura 32. Resultado do clculo segundo Chidamber e Kemerer
Figura 33. Resultado do clculo segundo Lorenz e Kidd
Figura 34. Opo de anlise com o grfico de Kiviat
Figura 36. Tela de opes do projeto
Figura 37. Tela para escolher o nome do projeto a ser salvo
Figura 38. Tela de seleo de projeto salvo anteriormente
Os passos so similares ao demonstrado nas telas anteriores. Os
resultados do clculo so apresentados nas Figuras 40 e 41.
O prottipo implementado ainda dispe do recurso de ajuda,
podendo ser acessado pelo menu do sistema Figura 42 ou pela
tecla de atalho F1.
A ajuda do sistema disponibilizada no formato HTML e tem
um menu com as opes no lado esquerdo do vdeo e as informa-
es do outro lado. A Figura 43 exemplifica a ajuda do sistema.
cd Classe Exemplo Prottipo
Telefone
- NomeUsuari o: stri ng
- EnderecoInstal acao: stri ng
- DataInstal acao: Date
+ getVal orBasi co() : fl oat
TelefoneResidencial
- ConexaoInternet: Bool ean
TelefoneComercial
- QtdeRamai s: i nt
Figura 39. Exemplo para demonstrao (Fonte: Hugo e Hbner)
Figura 40. Resultado do clculo segundo Chidamber e Kemerer Java
Figura 41. Resultado do clculo segundo Lorenz e Kidd Java
Resultados e discusses
A Tabela 24 traz um comparativo entre quatro ferramentas
de coleta de mtricas em software OO, e tem o objetivo de
demonstrar algumas das mtricas calculadas por essas ferra-
mentas, linguagens suportadas e demonstrativo de resultados
em forma de grfico.
MEDI O
Figura 43. Tela de ajuda do sistema
Figura 42. Opo de ajuda do prottipo
Ferramenta Mtrica Linguagem Grfico
W
M
C
D
I
T
N
O
C
C
B
O
L
C
O
M
R
F
C
C
S
N
O
O
N
O
A
S
I
C
#
J
a
v
a
D
e
l
p
h
i
Visual Mtrica X X X X X X X X X X X X X
JMetric X X X X X X X X
Prottipo Seibt (2001) X X X X X X X X X X X
Prottipo Cardoso (1999) X X X X X X
Tabela 24. Comparativo entre as ferramentas
Pode-se perceber neste comparativo que a ferramenta Visual
Mtrica cujo desenvolvimento foi apresentado neste artigo
possui funcionalidades mais abrangentes que outras de pro-
posta semelhante.
Concluses
Neste artigo apresentamos um conjunto de conceitos asso-
ciados a mtricas de software. Alm disso, apresentamos o
desenvolvimento de uma ferramenta para coleta de mtricas
em software OO escritos em C# e Java. A ferramenta calcula
dez mtricas previstas por CK e LK.
A utilizao da ferramenta CocoR for C# para a construo
do analisador lxico e sinttico foi importante, pois como foi
uma ferramenta de fcil aprendizado, acelerou e simplificou
o processo de desenvolvimento do analisador. As utiliza-
es da ferramenta Microsoft Visual C# Express Edition e
Enterprise Architect tambm auxiliaram consideravelmente
no desenvolvimento. Para a implementao da classe de
coleta de mtricas foram necessrios estudos detalhados
da estrutura das classes C# e Java.
1. AMBER, Scott W. Anlise e projeto orientado a objeto: seu guia para desenvolver sistemas
robustos com tecnologia de objetos.Traduo Oswaldo Zanelli. Rio de Janeiro: Infobook, 1998.
2. ARTHUR, Lowell J. Melhorando a qualidade de software: um guia para o TQM. Rio de Janeiro.
Infobook, 1994.
3. CARDOSO, Eduardo J. Mtricas para programao orientada a objetos. 1999. 45 f. Trabalho
de Concluso de Curso (Bacharelado em Cincias da Computao) Universidade Regional de
Blumenau, Blumenau.
4. CORDEIRO, Marco A. Mtricas de software. Curitiba, 2000. Disponvel em: <http://www.pr.gov.br/
batebyte/edicoes/2000/bb101/metricas.htm>. Acesso em: 12 nov. 2005.
5. CRTES, Mario L.; CHIOSSI, Thelma C. S. Modelos de qualidade de software. Campinas: Editora
da UNICAMP, 2001.
6. DEMARCO, Tom. Controle de projetos de software: gerenciamento, avaliao, estimativa. Rio de
Janeiro: Campus, 1989.
7. FUNCK, Mnica Andra. Estudo e aplicao das mtricas da qualidade do processo de
desenvolvimento de aplicaes em banco de dados. 1995. 104 f. Trabalho de Concluso de Curso
(Bacharelado em Cincias da Computao) Centro de Cincias Exatas e Naturais, Universidade
Regional de Blumenau, Blumenau.
8. GUSTAFSON, David A.Teoria e problema de engenharia de software. So Paulo: Bookman, 2003.
9. HBNER Jomi F.; HUGO Marcel. Prtica de laboratrio lista 4. Blumenau, 2003. Disponvel em:
<http://www.inf.furb.br/~poo/listas/poo-praticaLab4.pdf>. Acesso em: 3 nov. 2006.
10. JACOBSON, Ivar et al. Object oriented software engineering: a use case driven approach
Wokingham: Addison Wesley, 1992.
11. KOSCIANSKI, Andre; SOARES, Michel dos S. Qualidade de software:Aprenda as metodologias e
tcnicas mais modernas para o desenvolvimento de software. So Paulo: Novatec, 2006.
12. LORENZ, Mark; KIDD, Jeff. Object-oriented software metrics: a practical guide. New Jersey: PTR
Prenticel Hall, 1994.
13. MOLLER, Kurt. H., PAULISH, Daniel J. Software metrics: a practitioneris guide to improved
product development. Los Alamitos: IEEE, 1993.
14. POSSAMAI, Roque Csar. Ferramenta de anlise de estruturas bsicas em linguagem Pascal
para o fornecimento de mtricas. 2000. 71 f. Trabalho de Concluso de Curso (Bacharelado em
Cincias da Computao) Centro de Cincias Exatas e Naturais, Universidade Regional de
Blumenau, Blumenau.
15. PRESSMAN, Roger S. Engenharia de software. So Paulo: Makron Books, 1995.
16. ROCHA, Ana R.; MOLDONADO, Jos C.; WEBER, Kival C. Qualidade de software: teoria e prtica.
So Paulo: Prentice Hall, 2001.
17. ROSENBERG, Linda. Applying and interpreting object oriented metrics. Utah, abr. 1998.
Disponvel em: <http://satc.gsfc.nasa.gov/support/STC_APR98/apply_oo apply_oo.html>.
Acesso em: 07 jun. 2006
18. SEIBT, Patrcia R. R. S. Ferramenta para clculo de mtricas em softwares orientados a objetos
codificados em Delphi. 2001. 86 f. Trabalho de Concluso de Curso (Bacharelado em Cincias da
Computao) Universidade Regional de Blumenau, Blumenau.
19. SHEPPERD, Martin. Foundation of software measurement. New York: Prentice Hall, 1995.
20. TONINI, Antonio C. Mtricas de software. [S.l.], 2004. Disponvel em: <http://www.spin.org.br/
Pdf/metricas%202.ppt>. Acesso em: 12 nov. 2005.
Referncias bibliogrficas
D

s
e
u
Feedba
c
k
s
o
b
r
e

e
s
t
a
e
d i o
Paulo C. Barreto da Silva
paulo.Barreto@unianhanguera.edu.br
Graduado em Anlise de Sistemas pelo Centro
Universitrio Salesiano de So Paulo (2003) e
Ps-graduado pela Universidade Estadual de
Campinas - UNICAMP - na rea de Orientao
a Objetos (2005). Professor da Anhanguera
Educacional SA e Analista de Sistemas na Pa-
pirus Indstria de Papel SA.Possui experincia
de 11 anos na rea de Cincia da Computa-
o, com nfase em Sistemas de Informao,
atuando principalmente nos seguintes temas:
anlise de sistemas, programao orientada
a objetos, programao estruturada, desen-
volvimento de sistemas, UML (Linguagem de
Modelagem Unificada), gesto de projetos,
linguagem de programao C e Java.
Thiago Salhab Alves
thiago.alves@unianhanguera.edu.br
Graduado em Cincia da Computao pela
Universidade Metodista de Piracicaba - UNI-
MEP (2004) e Mestre em Cincia da Computa-
o pela Universidade Metodista de Piracica-
ba - UNIMEP (2008). Professor e Coordenador
do curso de Cincia da Computao da Facul-
dade Anhanguera de Santa Brbara. Possui
seis anos de experincia na rea de Cincia
da Computao com nfase em Engenharia
de Software.
Este artigo apresenta uma anlise sobre as dependn-
cias entre prticas especfcas para as sete reas de
processo do nvel 2 de maturidade do CMMI.
Para que serve?
Serve como guia para a melhoria de processos na orga-
nizao e tambm da habilidade dos profssionais em
gerenciar o desenvolvimento, aquisio e manuteno
dos produtos ou servios.
Como modelo de capacitao e maturidade do pro-
cesso e como ferramenta de acuidade da qualidade
do desenvolvimento, podendo ser utilizada por
equipes e organizaes desenvolvedoras de sof-
tware que pretendem avaliar seus processos frente
ao CMMI.
Anlise de dependncias entre prticas
especficas do nvel 2 do CMMI
Engenharia
Nesta seo voc encontra artigos voltados para testes, processo,
modelos, documentao, entre outros
E
quipes e organizaes desen-
volvedoras de software muitas
vezes adotam diferentes prticas
de desenvolvimento, criando o que se
costuma chamar de processos ad hoc de
desenvolvimento de software. Infeliz-
mente esses processos ad hoc costumam
ser pouco controlados, no passveis de
repetio e altamente dependentes da
capacidade individual de cada membro
da equipe.
Desde a dcada de 1990, vrios modelos
de maturidade de processos vm sendo
propostos com o objetivo de auxiliar na
melhoria da qualidade dos processos de
software adotados pelas organizaes
[3]. Entre eles podemos citar os modelos
CMM [5], Spice ISO/IEC 15504 [2],
CMMI [1] e mais recentemente, no Brasil,
o MPS-BR [4]. Atualmente as organiza-
es que desenvolvem software esto
atentas s necessidades da adoo de
processos de desenvolvimento de sof-
tware melhor definidos, e observam-se
movimentos dessas organizaes em
busca de certificaes de qualidade de
processos de software, notadamente as
certificaes CMMI de nvel 2.
Neste sentido, o objetivo deste artigo
apresentar o resultado de uma anlise
ampla sob o CMMI que foi realizada
para determinar possveis dependncias
entre as prticas especficas em uma
mesma rea de processo. Para isso, foram
36 Engenharia de Software Magazine - Anlise de dependncias entre prticas especcas do nvel 2 do CMMI
analisadas as sete reas de processo do nvel 2 de maturidade.
As motivaes para a anlise se devem ao fato das organizaes
e equipes de desenvolvimento, que fazem o uso do CMMI para
avaliao de seus processos, no encontrarem no documento
oficial uma descrio clara e objetiva de possveis relaes de
dependncias entre prticas especficas dentro de uma mesma
rea de processo (o documento apenas sugere uma consulta
de reas de processos relacionadas para mais informaes).
A comprovao das dependncias de grande importncia
para um mtodo de auto-avaliao de processos de software,
pois sabendo quais as prticas que possuem dependentes,
uma maior ateno na classificao dessas prticas dever
ser adotada e eventuais falhas na classificao podem ser
identificadas e corrigidas.
Com o resultado das anlises de dependncias e estudos
dos principais modelos de avaliao integrados ao CMMI
(ARC V1.2 (Appraisal Requirements for CMMI)), e do mtodo
de avaliao SCAMPI A (Standard CMMI Appraisal Method for
Process Improvement), foi desenvolvido um mtodo de auto-
avaliao de processos de software, apoiado por um prottipo
da ferramenta MAPSw, apresentando-se como um instrumento
que oferecer auxlio s organizaes e s equipes de desen-
volvimento de software na melhoria de seus processos frente
ao CMMI nvel 2 de maturidade, bem como na obteno de
certificao CMMI em um futuro prximo.
As principais motivaes para o desenvolvimento deste m-
todo se devem escassez de mtodos de auto-avaliao para
CMMI e pela dificuldade encontrada pelas organizaes e
equipes de desenvolvimento em interpretar e utilizar correta-
mente os documentos de avaliao (ARC e SCAMPI A), pois so
muito extensos, passveis de m interpretao e apresentados
em ingls. Dessa forma, o mtodo e a ferramenta desenvolvi-
dos do suporte verificao de dependncias entre prticas,
auxiliando o usurio a identificar em que pontos devem ser
melhorados e a minimizar possveis falhas de avaliao.
O restante deste artigo est organizado da seguinte forma:
na seo CMMI so apresentados seus principais compo-
nentes e reas de processo; na seo Modelos de Avaliao
Integrados ao CMMI so apresentados o ARC e SCAMPI, que
so os principais modelos de Avaliao; na seo Anlise das
Dependncias entre Prticas Especficas apresentada uma
anlise sobre as dependncias entre prticas especficas das
reas de processos do nvel 2; na seo MAPSw: Mtodo de
Auto-Avaliao de Processos de Software apresentado o
mtodo de auto-avaliao que d suporte a anlise de depen-
dncias entre prticas; e na ltima seo so apresentadas as
concluses deste artigo.
CMMI
Capability Maturity Model Integration for Development verso
1.2 (2006) uma atualizao do CMMI verso 1.1 (2002) desen-
volvido no SEI (Software Engineering Institute) e patrocinado
pelo Departamento de Defesa dos Estados Unidos e filiado
Universidade Carnegie Mellon. O objetivo principal do CMMI
foi integrar vrios modelos disponveis, que dificultavam e
apresentavam alto custo de implantao. Os principais com-
ponentes do CMMI so:
reas de processo: conjunto de prticas que quando exe-
cutadas, satisfazem a um conjunto de metas consideradas
importantes para obter melhoria significativa;
Metas especficas: aplicam-se a uma rea de processo e
descrevem o que deve ser executado para satisfazer a rea de
processo. So componentes requeridos do modelo e utilizados
nas avaliaes para ajudar a determinar se uma rea de pro-
cesso est satisfeita;
Prticas especficas: so atividades importantes para conse-
guir a meta especfica associada. So componentes esperados
do modelo;
Metas genricas: so consideradas genricas pois aparecem
em vrias reas de processo. So componentes requeridos do
modelo e usados nas avaliaes para determinar se uma rea
de processo est satisfeita;
Prticas genricas: asseguram que os processos associados
com a rea de processo sejam eficazes e duradouros. So com-
ponentes esperados do modelo;
Produtos tpicos do trabalho: listam exemplos de sada de
prticas especficas. Esses exemplos so chamados produtos
tpicos de trabalho porque h frequentemente outros produtos
de trabalho que so efetivos, mas no listados. So componen-
tes informativos do modelo.
As reas de processo do nvel 2 de maturidade do modelo
CMMI so [1]:
Gerncia de Requisitos;
Planejamento do Projeto;
Monitoramento e Controle do Projeto;
Gerncia de Acordo com Fornecedores;
Medio e Anlise;
Garantia da Qualidade do Produto e Processo;
Gerncia de Configurao.
Cada rea de processo possui metas especficas e genricas
com suas respectivas prticas especficas e genricas, e cada
prtica apresenta produtos tpicos de trabalho que so exem-
plos de sada da implementao da prtica.
Para algumas prticas especficas, o CMMI apenas solicita
a consulta de reas de processos relacionadas. Em nenhum
momento uma relao de dependncia entre reas de processo,
metas e prticas apresentada, sendo apresentadas apenas
as descries das mesmas. Assim, o estudo das possveis
dependncias foi realizado e descrito na seo Anlise das
Dependncias entre Prticas Especficas.
Modelos de Avaliao Integrados ao CMMI
Os principais modelos usados para avaliao de processos
de software integrados ao CMMI so o ARC (Appraisal Requi-
rements for CMMI) verso 1.2 e o SCAMPI A (Standard CMMI
Appraisal Method for Process Improvement) verso 1.2.
O ARC define os requisitos considerados essenciais para
mtodos de avaliao que pretendem ser usados com o CMMI.
PROCESSO
Os requisitos so alocados em cada classe, baseado
nos atributos associados com essa classe. Assim,
um mtodo de avaliao pode ser declarado para
ser um ARC classe A, B ou C. Nem todos os mto-
dos de avaliao CMMI so esperados de estar em
total conformidade com o ARC, isto , satisfazer
cada requisito ARC.
Os mtodos da classe A devem satisfazer todos
os requisitos ARC e at o presente momento, so
os nicos mtodos considerados apropriados para
fornecer avaliao. Um exemplo do mtodo da clas-
se A o SCAMPI (Standard CMMI Appraisal Method
for Process Improvement). Os requisitos incluem
sees de: Responsabilidade; Documentao do
Mtodo de Avaliao; Planejamento e Preparao
para a Avaliao; Coleo dos Dados da Avaliao;
Consolidao dos Dados e Validao; Avaliaes e
Relatrio de Resultados.
O SCAMPI A foi desenvolvido para prover pontu-
aes para modelos CMMI. aplicado a uma vasta
escala de modos de avaliao, incluindo melhoria
de processo interno e determinao de capacidade
externa [7].
Ele satisfaz todos os requisitos do Appraisal
Requirements for CMMI (ARC) para o mtodo de
avaliao Classe A. O Documento de Definio
do Mtodo Classe A SCAMPI v1.2 descreve os
requisitos, atividades e prticas associadas com
cada processo que compe o mtodo. A Tabela 1
apresenta a sua Metodologia, dividida em trs
fases, cada fase com seus respectivos processos
Anlise das Dependncias entre Prticas
Especficas
O levantamento das dependncias iniciou-se
pelas anlises dos produtos tpicos de trabalho
das prticas especficas, buscando verificar se al-
guma dependncia entre eles era encontrada. Pela
verificao constataram-se dependncias entre os
produtos tpicos de trabalho de prticas de uma
mesma rea de processo e, consequentemente, a
dependncia entre as prticas que as possuem.
A Tabela 2 apresenta a anlise realizada para as
prticas especficas da rea de processo Garantia
da Qualidade do Produto e do Processo. Todas as
sete reas de processo tambm foram verificadas
de forma semelhante. A anlise foi realizada
comparando os produtos tpicos de trabalho de
uma prtica com as outras, dentro da mesma rea
de processo. Assim, determinaram-se as depen-
dncias existentes. A coluna Prtica Analisada
apresenta as prticas que sero analisadas em
busca de dependncias. Se houver dependncias,
a coluna Dependncias apresenta a prtica da
qual se depende. A coluna Produtos Tpicos de
Trabalho Analisados apresenta os produtos tpicos de trabalho das pr-
ticas analisadas em busca de dependncias. Se houver dependncias,
a coluna Dependncias apresenta o produto tpico de trabalho que se
depende. importante ressaltar que essa anlise foi feita com base em
estudos no CMMI, sendo que diferentes analistas poderiam sugerir
novas dependncias ou discordar de algumas propostas.
A Figura 1 apresenta um grfico com a relao de dependncia entre as pr-
ticas especficas nas sete reas de processo para o nvel 2 de maturidade.
Fase Processo
A: Planejar e preparar para avaliao A.1 Anlise de requisitos
A.2 Desenvolvimento do plano de avaliao
A.3 Selecionar e preparar a equipe
A.4 Obter e fazer inventrio das evidncias
A.5 Preparar para conduzir a avaliao
B: Conduzir a avaliao B.1 Preparar os participantes
B.2 Examinar as evidncias objetivas
B.3 Documentar as evidncias objetivas
B.4 Verificar as evidncias objetivas
B.5 Validar os encontros preliminares
B.6 Gerar os resultados da avaliao
C: Relatar resultados C.1 Entrar os resultados da avaliao
C.2 Pacotes e recursos de avaliao arquivados
Tabela 1. Metodologia do SCAMPI A
Objetivo Especfico: SG2 Prover Introspeco Objetiva
Prtica analisada Dependncias Produtos Tpicos de Trabalho Analisado Dependncias
SP1.1 Comunicar e assegurar resoluo
de questes de no conformidade
SP1.1 Objetivamente avaliar processos PTT1. Relatrio de ao corretiva (SP1.1) PTT3. Aes corretivas
(SP1.2) PTT3. Aes corretivas
SP1.2 Objetivamente avaliar produtos de trabalho e
servios
PTT2. Relatrio de avaliao No h dependncias
PTT3.Tendncias de Qualidade No h dependncias
SP2.2 Estabelecer registros SP2.1 Comunicar e assegurar resoluo de questes de
no conformidade
PTT1. Registros de avaliao (SP2.1) PTT2. Relatrio de avaliao
PTT3. Relatrio de status de aes corretivas (SP2.1) PTT1. Relatrio de aes corretivas
PTT4. Relatrios de tendncias de qualidade (SP2.1) PTT3.Tendncias de qualidade
PTT2. Relatrios de garantia da qualidade No h dependncias
Tabela 2. Dependncias entre Prticas Especficas Garantia da Qualidade do Produto e do Processo
Figura 1. Relao de Dependncia entre prticas especficas em reas de
processo para o nvel 2 de maturidade
De acordo com a Figura 1, a quantidade de relaes de
dependncias entre prticas bem significante para todas as
reas de processo. Para a rea de processo Planejamento do
Projeto, por exemplo, h 14 prticas especficas e pela anlise
de dependncias entre prticas, 24 relaes de dependncias
foram encontradas. de extrema importncia a identificao
dessas relaes em uma auto-avaliao.
O grfico apresenta dois conceitos de classificao de
dependncia: dependncia fraca e forte. Uma dependncia
forte ocorre se a prtica especfica dependente ficar muito
prejudicada (invivel ou quase invivel de se realizar) quan-
do a prtica especfica da qual ela depende estiver ausente
ou com classificao ruim. Uma dependncia fraca ocorre
se a prtica especfica dependente ficar pouco prejudicada,
mesmo quando a prtica especfica da qual ela depende
estiver ausente ou com avaliao ruim.
Como exemplo de anlise, verificando as informaes do
grfico, a rea de processo Gerncia de Requisitos possui
duas relaes de dependncias fracas e cinco relaes de
dependncias fortes. As relaes de dependncias fortes
foram:
SP1.2 Obter Compromisso com os Requisitos depende
fortemente de SP1.1 Obter uma Compreenso dos Requisitos,
pois para se ter compromissos documentados dos requisitos
deve-se ter um conjunto de requisitos acordados;
SP1.3 Gerenciar Mudanas de Requisitos depende forte-
mente de SP1.1 Obter uma Compreenso dos Requisitos,
pois para se ter uma base de dados dos requisitos deve-se
ter requisitos acordados;
SP1.4 Manter Rastreabilidade Bidirecional de Requisitos de-
pende fortemente de SP1.3 Gerenciar Mudanas de Requisitos,
pois para se ter uma matriz de rastreabilidade de requisitos
deve-se ter a base de dados dos requisitos;
SP1.5 Identificar Inconsistncias entre trabalho de projeto e
requisitos depende fortemente de SP1.3 Gerenciar Mudanas
de Requisitos, pois para se identificar inconsistncias entre
trabalho de projeto e requisitos deve-se ter a base de dados dos
requisitos;
SP1.5 Identificar Inconsistncias entre trabalho de projeto e
requisitos depende fortemente de SP1.4 Manter Rastreabilidade
Bidirecional de Requisitos, pois para se identificar inconsistn-
cias entre trabalho de projeto e requisitos (tomar aes correti-
vas) deve-se ter uma matriz de rastreabilidade.
As relaes de dependncias fracas encontradas foram:
SP1.3 Gerenciar Mudanas de Requisitos depende fracamente
de SP1.2 Obter Compromisso com os Requisitos, pois para se
ter uma base de dados dos requisitos ideal ter compromissos
com os requisitos documentados;
SP1.4 Manter Rastreabilidade Bidirecional de Requisitos
depende fracamente de SP1.1 Obter uma Compreenso dos
Requisitos, pois para se ter uma matriz de rastreabilidade de
requisitos ideal ter um conjunto de requisitos acordados.
Pelo estudo das dependncias entre as prticas, observou-se
que:
A classificao de uma prtica que possui dependente(s)
influenciar diretamente na classificao da(s) prtica(s)
dependente(s);
Na relao de dependncia, a classificao de uma prtica de-
pendente deve ser igual ou inferior classificao da(s) prtica(s)
da qual se depende;
Na relao de dependncia de prticas especficas, a ausncia
ou ponto fraco encontrado em evidncia(s) objetiva(s) de uma
prtica, que possui dependente(s), far com que a prtica de-
pendente tambm possua uma ausncia, ou ponto fraco na(s)
evidncia(s) objetiva(s).
Atravs das verificaes das dependncias entre prticas e
das observaes encontradas durante o estudo comparativo,
PROCESSO
foi possvel a criao de regras que pudessem ser includas no
mtodo de auto-avaliao MAPSw que estava sendo proposto,
tornando assim o mtodo mais confivel. A prxima seo
apresenta o mtodo de auto-avaliao com suas trs fases e a
incluso na Fase III do mtodo, a descrio de como proceder
com a verificao para consistncias entre prticas (anlise
de dependncia).
MAPSw: Mtodo de Auto-Avaliao de Processos de
Software
Para a construo do MAPSw (ver Nota 1), foi realizado um
estudo amplo para identificar possveis dependncias entre
as prticas especficas em uma mesma rea de processo e
analisadas as sete reas de processo do nvel 2 de maturidade
do CMMI.
O MAPSw um mtodo de auto-avaliao de processos
de software, especificamente para avaliao do nvel 2
de maturidade de processos, conforme o modelo CMMI.
O mtodo de auto-avaliao tem o suporte de uma ferra-
menta, em fase de prottipo, desenvolvida em Java, com o
IDE NetBeans 5.0 e o SGBD Firebird 2.0, visando facilitar
e direcionar a auto-avaliao de processos de software. As
relaes de dependncias entre prticas especficas apre-
sentadas anteriormente foram includas no mtodo MAPSw
e no prottipo.
O mtodo de avaliao SCAMPI A foi determinado como
base para a construo do MAPSw, pois um mtodo que
satisfaz todos os requisitos da classe A do ARC, e utilizado
para prover pontuaes. Os objetivos do MAPSw so:
Ser utilizado por pequenas organizaes ou pequenas
equipes de desenvolvimento para uma auto-avaliao de
seus processos de software;
Ajudar organizaes a identificar o estado atual de seus
processos;
Servir como plano de melhoria de processo de desenvol-
vimento de software;
Apresentar baixo custo para a organizao usuria;
Ser confivel e simples;
Permitir tempo flexvel de aplicao (a organizao deter-
minar o tempo das atividades da avaliao);
No influenciar no fluxo das atividades dirias da organi-
zao (a organizao no receber avaliadores externos);
Servir como base para prximas avaliaes (certificaes
oficiais).
O MAPSw apresenta trs fases, conforme a Tabela 3.
Para a Fase I, a avaliao deve ser preparada buscando
definir os objetivos e o escopo organizacional, isto , definir
o(s) projeto(s) que efetivamente represente(m) a utilizao
do processo da organizao ou equipe de desenvolvimento
avaliada. A equipe deve ser preparada determinando o co-
ordenador da avaliao (membro com maior conhecimento
sobre o escopo da organizao e CMMI) e os membros da
equipe (pessoas motivadas, responsveis e com conheci-
mento dos projetos da organizao).
Para a Fase II, a avaliao deve ser conduzida pelo coorde-
nador e demais membros da equipe que utilizam o prottipo
da ferramenta MAPSw e classificam as evidncias objetivas
encontradas em:
Artefato direto: resultados diretos da implementao da
prtica. Exemplos: Plano de Projeto, Medidas de Performance
de Projeto, etc.;
Artefato indireto: indicativo da execuo da prtica. Exem-
plos: Ata de Reunies, Revises, Relatrios, etc.;
Afirmao: provas escritas ou orais confirmando ou su-
portando a implementao da prtica. Exemplos: Entrevistas,
Questionrios, etc.;
No possui Evidncia: quando nenhum artefato, afirmao
ou qualquer tipo de evidncia sobre a implementao da prtica
for encontrado;
Ponto Fraco Encontrado: quando existe artefato ou afirmao
que apresenta alguma fraqueza.
Fase I Preparar para Avaliao
A. Preparar Avaliao
A.1 Definir os Objetivos da Avaliao
A.2. Determinar o Escopo Organizacional da Avaliao
A.3. Preparar Equipe de Avaliao
A.3.1. Identificar o Coordenador da Avaliao
A.3.2. Selecionar os Membros da Equipe de Avaliao
A.3.3. Orientar a Equipe de Avaliao
A.4. Obter Evidncias Objetivas
A.5.Validar Evidncias Objetivas
Fase II Avaliao
B. Conduzir Avaliao
B.1. Classificar as Evidncias Objetivas
B.2. Realizar Processo de Classificao
B.2.1. Classificar as Prticas Especficas e Genricas
B.2.2. Classificar Metas Especficas e Genricas
B.2.3. Classificar reas de Processo
B.2.4. Classificar Nvel de Maturidade
Fase III Resultados
C. Relatar Resultados
C.1.Verificar consistncia entre as prticas (anlise de dependncias)
C.2. Entregar Descobertas Finais
C.3. Planejar Prximos Passos
Tabela 3. Fases e Procedimentos do MAPSw
A classificao das metas especficas e genricas so realiza-
das automaticamente utilizando as seguintes regras:
No Pontuada: se h prticas associadas meta espec-
fica ou genrica que foram classificadas como Ainda No
Implementada;
Nota do DevMan 1
MAPSw Mtodo de Auto-Avaliao de Processos de Software baseado no CMMI-
DEV, ARC e SCAMPI A, e que d suporte a anlise de dependncias entre prticas.
Satisfeita: se todas as prticas associadas meta especfica ou
genrica foram classificadas como Largamente Implementada
ou Completamente Implementada;
No Satisfeita: qualquer outra classificao que no seja No
Pontuada ou Satisfeita.
Com a classificao das metas especficas e genricas,
determina-se a classificao das reas de Processo de acordo
com as seguintes regras:
Satisfeita: se, e somente se, todas as metas genricas e espe-
cficas so classificadas como Satisfeita;
No Satisfeita: uma ou mais metas so classificadas como
No Satisfeita;
No Aplicvel: quando a rea de processo for considerada
fora do escopo de trabalho da unidade organizacional;
No Classificada: se uma das metas for classificada como
No Pontuada, e nenhuma das metas foi classificada como
No Satisfeita.
O nvel de maturidade determinado pela classificao das
reas de processo. A organizao avaliada contempla o nvel
2 de maturidade se todas as sete reas de processo forem
classificadas como Satisfeita ou No Aplicvel.
Para a Fase III, o objetivo verificar as dependncias entre
as prticas especficas, emitir diagnstico final da avaliao
e dar condies para que a equipe de avaliao planeje suas
aes futuras. A verificao de dependncias entre prticas,
apresentada anteriormente, foi includa no MAPSw e na ferra-
menta de suporte, sendo um diferencial importante em relao
s demais ferramentas existentes. A verificao de consistncia
entre prticas deve ser realizada pelas seguintes anlises:
Analisar as classificaes das prticas especficas que possuem
dependentes e a classificao das prticas dependentes;
A classificao de uma prtica dependente deve ser igual ou
inferior classificao da prtica da qual se depende;
Caso a classificao de uma prtica dependente seja superior
classificao da prtica da qual se depende, deve-se reavaliar
a classificao da prtica dependente.
Concluso
Com a verificao de dependncias entre prticas espec-
ficas em reas de processo do nvel 2 de maturidade CMMI
e a elaborao do mtodo de auto-avaliao de processos de
software, uma nova contribuio para a rea de Qualidade
de Software e Melhoria de Processos de Software pde ser
agregada. Com a verificao das dependncias entre prticas,
IDE NetBeans
http:// netbeans.org/
Software Engineering Institute CMMI
http:// http://www.sei.cmu.edu/cmmi/
Links
1. CMMI Product Team.: CMMI for Development,Version 1.2, Carnegie Mellon University. http://
www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf, (2006)
2. Crtes, M. L. e Chiossi, T. C. S.: Modelos de Qualidade de Software, Editora Unicamp, (2001)
3. Guerrero, F. and Eterovic, Y.: Adopting the SW-CMM in a Small IT Organization, IEEE
Software, (2004)
4. MPS-Br.: Melhoria do Processo de Software Brasileiro, Notas de Apresentao do Workshop
do Projeto melhoria de processo do software Brasileiro (mps BR), Campinas, (2004)
5. Paulk, M.C., Curtis, B., Chrissis, M.B., Weber., C.W.: Capability Maturity ModelSM for Software,
Version 1.1, Carnegie Mellon University. http://www.sei.cmu.edu/pub/documents/93.reports/
pdf/tr24.93.pdf, (1993)
6. Scampi Upgrade Team.: Appraisal Requirements for CMMI, Version 1.2, Carnegie Mellon
University, (2006a)
7.Scampi Upgrade Team.:Standard CMMI Appraisal Method for Process Improvement (SCAMPI)
A, Version 1.2: Method Definition Document, Carnegie Mellon University, (2006b)
Referncias Bibliogrficas
a auto-avaliao se torna mais segura, pois as classificaes
das prticas passam para uma anlise de consistncia, isto ,
so submetidas anlise de dependncias. Eventuais falhas
nas classificaes das prticas, principalmente entre prticas
dependentes e das quais se depende, podem ser verificadas
com o auxlio do MAPSw e da ferramenta de apoio, garantindo
assim as classificaes das metas e reas de processo.
Futuras verificaes de dependncias devem ser realizadas
para verificar a dependncia entre prticas de reas de processos
diferentes, dentro de um mesmo nvel, bem como a anlise de
dependncia para nveis superiores (3, 4 e 5) do CMMI.
D

s
e
u
Feedba
c
k
s
o
b
r
e

e
s
t
a
e
d i o
Tadeu Moreira de Classe
tadeuneo@oi.com.br
Graduando no Curso Bacharelado em Sistemas
de Informao do Centro de Ensino Superior de
Juiz de Fora. Tcnico em Informtica Industrial
pelo Colgio Tcnico Universitrio (CTU/UFJF).
Programador Pleno da empresa de softwares
jurdicos Novaprolink de Juiz de Fora/MG.
Guilherme de Jorge Palmeira
guilhermejp8@hotmail.com
Graduando no curso de Sistemas de Informao
do Centro de Ensino Superior de Juiz de Fora. Atu-
almente estagiando como programador de JSF na
empresa INFOBICAS.
Daves Marcio Silva Martins
davesmartins@gmail.com
desenvolvedor Java desde 2000, com ampla
experincia em aplicaes Win32, Web e Celu-
lar. Graduado em Informtica pela UFJF, com
Especializao em Banco de Dados pelo Centro
de Ensino Superior de Juiz de Fora, Mestrado
em Computao de Alto Desempenho pela UFRJ
e Doutorando na UFJF. Atualmente professor
universitrio em diversas instituies, em cusos
de Sistemas de Informao, Analista de Sistema
na UFJF, e atua como consultor, pesquisador e
desenvolvedor de aplicaes Java, sobretudo na
plataforma J2EE para Web, e J2ME, sendo espe-
cialista em aplicaes Web.
Eduardo Leandro Pinto Dornelas
eduardol.dornelas@gmail.com
Graduando em Sistemas de Informao pelo
Centro de Ensino Superior de Juiz de Fora. Tcnico
de Informtica pelo Colgio Tcnico Pio XII. Atuou
como analista de suporte pela COCA-COLA FEMSA
MG. Atualmente Analista Field Services pela HP
Enterprise Services.
Apresenta a integrao do sistema de controle de
mudanas Trac e com o sistema de controle de verso
Subversion (SVN).
Para que serve?
Exemplifcar ao leitor como feita a integrao
do Trac com o SVN, mostrando os passos para essa
confgurao.
Durante o processo de desenvolvimento de um
projeto, no qual h necessidade de controlar suas
etapas, mudanas e sugestes, obtendo um deta-
lhamento completo de suas verses.
Integrao das ferramentas Trac e Subversion
Trabalhe na prtica com um sistema de controle de mudanas integrado a um
de controle de verso
C
ontrolar mudanas em projetos
como inseres, alteraes de
cdigo fonte e excluses de do-
cumentos, uma tarefa difcil devido ao
grande volume de informao e comple-
xidade de softwares que o mercado vem
exigindo s empresas.
Muitas solues para essas dificulda-
des foram desenvolvidas ao longo dos
anos, como o CVS (Concurrent Version
System - Sistemas de Verses Concorren-
tes) o qual permite o versionamento de
projetos. Esses projetos, ento armaze-
nados em servidores, so utilizados por
clientes que se conectam e copiam todo o
contedo para as suas mquinas a fim de
realizarem alteraes ou melhorias.
Tudo evolui e com o CVS no foi di-
ferente. Este abriu espao para o SVN
(Subversion), que trabalha da mesma
forma que o anterior, porm, com diver-
sas correes e melhorias.
Com a evoluo tecnolgica, existe
tambm a necessidade de controlar as
mudanas ocorridas durante o desen-
volvimento de um projeto. Para essa
gerncia de mudanas existem diversas
ferramentas como Mantis, Bugzilla, Trac
(foco deste artigo), dentre outros. Esses
Desenvolvimento
Nesta seo voc encontra artigos voltados para diferentes
abordagens de apoio ao desenvolvimento de projetos de software
42 Engenharia de Software Magazine - Integrao das ferramentas Trac e Subversion
softwares permitem a criao e o gerenciamento de tarefas que
podem ser correo de defeitos, implementao de melhorias,
e/ou implementao de novas funcionalidades.
Assim, esses sistemas permitem um registro da evoluo do
projeto bem como permitem um controle de mudanas ocor-
ridas ao longo das verses do sistema. importante atentar
para o fato de que estes programas tendem a se tornar ainda
mais teis quando conseguem ser integrados aos sistemas
de controle de verso, pois assim, h o controle das verses,
alteraes e melhorias de todo o projeto.
Softwares de controle de mudana de projetos ajudam na
melhoria da qualidade do produto por permitirem manter
um registro de toda mudana ocorrida, acompanhando a
evoluo do projeto e documentando o que realizado atravs
da participao da equipe de desenvolvimento. Neste sentido,
este artigo apresenta a integrao do sistema de controle de
mudanas Trac e com o sistema de controle de verso Subver-
sion (SVN).
O Subversion (SVN)
O Subversion um sistema de controle de verso de cdigo
aberto que surgiu para competir com o CVS, mantendo a
metodologia existente, porm corrigindo erros e falhas. O
sistema faz a gerncia de arquivos e diretrios, juntamente
com as modificaes realizadas, permitindo que um usurio
recupere verses antigas de dados ou apenas visualize e se
informe a partir de um histrico de atualizaes.
O sistema utilizado em rede, fazendo com que diversos
clientes copiem toda a estrutura de diretrio que se encontra
em um repositrio de dados no servidor. Qualquer usurio
que tenha permisso pode ler ou gravar dados do repositrio
(Figura 1). Porm, diferente dos servidores de arquivos co-
muns, o SVN se lembra das alteraes realizadas permitindo
assim o versionamento do projeto.
Figura 1. Sistema cliente/servidor
Com o uso do Subversion, os usurios podem trabalhar ao
mesmo tempo em arquivos iguais salvando suas alteraes.
Em sistemas onde no h um repositrio para os dados, no
possvel duas ou mais pessoas trabalharem ao mesmo tempo
no mesmo arquivo e gravarem o seu trabalho, pois isso pode
ocasionar perdas de informaes ou at mesmo corromper o
documento.
Utilizando o SVN, pelo fato de existir um repositrio para
os dados e existirem cpias dele em cada mquina cliente,
as alteraes simultneas em arquivos se torna possvel. Ao
final de cada alterao o usurio pode subir o documento
de volta ao repositrio pela operao de commit do sistema,
o qual permite fazer o merge, a unio dos dados alterados
para dentro do documento no servidor, como podemos ver
esquematizado na Figura 2.
Figura 2. Esquema Lgico de um Sistema de Controle de Verso
Assim no haver perda alguma de dados desde que o pro-
cedimento de unio dos documentos seja feito de maneira
correta. Ser gerada ento uma nova verso do repositrio o
qual poder ser novamente copiada, ou melhor, atualizada para
as mquinas clientes atravs do comando update do SVN.
Tortoise SVN
O TortoiseSVN uma ferramenta livre e de cdigo fonte
aberto com a funo de ser um cliente para o sistema de con-
trole de verso Subversion. Isto , ele monitora em tempo real
um repositrio de dados local verificando se existe alguma
coisa alterada, diferente do repositrio de dados encontrado
no servidor, marcando com diferentes cones as modificaes
encontradas dentro da pasta.
Ele conta com uma srie de funcionalidades alm de uma
interface grfica integrada com o Windows provendo as fun-
es do sistema de controle de verso como se fossem menus
do Explorer, conforme mostra a Figura 3.
O cliente tambm possui a sobreposio de cones, onde cada
arquivo ou diretrio marcado com um pequeno cone que
permite rapidamente saber a situao de cada um em relao
DESENVOLVI MENTO
ao repositrio de dados, conforme exibido na Figura 4. Alm
disso, possui todos os comandos do Subversion dentro de
seus prprios menus, podendo ser exibidos relatrios para o
controle de verses, janelas de autenticao de usurio, telas de
atualizaes, submisses e unies de cdigo, enfim, utilidades
para o controle de verso.
Figura 3. TortoiseSVN integrado com o Explorer do Windows
Figura 4. cones do TortoiseSVN
O Trac
O Trac uma ferramenta open source que roda em ambiente
Web, escrito em Python, sob a licena GPL, para rastreamento
de mudanas em projetos de desenvolvimento de software, o
qual visa facilitar algumas atividades corriqueiras na Gerncia
de Configurao de Software.
O projeto Trac teve incio em 2003, inspirado no CVSTrac,
o mesmo desenvolvido e mantido pela empresa Edgewall
Software e por colaboradores da comunidade open source. Da
mesma forma que o Subversion, a ferramenta vem conquistando
popularidade e usada em diversas empresas para gerenciar di-
ferentes projetos. O objetivo do controle de mudanas registrar
o porqu das alteraes ocorreram no projeto. No Trac, a central
do controle de mudanas o ticket e os seguintes servios so
oferecidos: Controle de Mudanas; Wiki para documentao
colaborativa e referncia cruzada; Integrao com o Subversion;
Acompanhamento da evoluo do projeto; Linha do tempo e
diversas outras funcionalidades que visam facilitar o controle
de mudanas de um projeto.
O ticket usado para registrar defeitos, pedidos de melhoria e
tarefas de projeto, ou seja, relatrios de bugs, requisio de carac-
tersticas e suporte de publicao do software e tarefas do projeto,
sendo possvel obter diversas informaes sobre o andamento e
evoluo do mesmo. Todos os tickets podem ser editados, anota-
dos, associados, priorizados e discutidos a qualquer momento.
No projeto Trac, utiliza-se os comentrios do ticket para
discutir publicaes e tarefas. Isso permite entender mais
facilmente a motivao por trs de um design ou a escolha da
implementao.
Integrao do Trac com o Subversion
Para que seja feita a integrao, parte-se do princpio que
j exista o SVN e o TortoiseSVN instalados, um repositrio
criado e o Trac configurado para acessar esta mesma base de
dados. No caso deste exemplo, o repositrio ser o MyProject.
Vamos agora passo a passo entender como esta integrao
pode ser realizada:
1. Inicia-se criando os dois usurios no VisualSVN mostrados
na Figura 5, o admin e o user, os quais respectivamente sero
administrador do Trac e um usurio normal, com as senhas
admin e user;
Figura 5. Usurios do VisualSVN
2. Em seguida deve-se configurar para que o usurio admin
seja o administrador do sistema Trac, onde poder realizar as
configuraes para que o TortoiseSVN consiga enxergar os ti-
ckets. Dentro do prompt de comando do Windows deve-se digitar
as linhas de comandos mostradas na Listagem 1. Os detalhes de
cada um destes comandos esto explicados na Tabela 1.
3. No browser, deve-se digitar o endereo: http://localhost/
trac/MyProject. Ser exigido o usurio e senha. Entrando com o
usurio user e o usurio admin, pode-se perceber a diferena
entre os menus do programa para o usurio administrador e
para o usurio comum (Figura 6).
4. Agora entre no Trac como administrador do sistema. Para
isso, deve-se entrar na aba Admin para acessar as configu-
raes de administradores do programa. Ao lado esquerdo da
tela, pode ser visto um outro menu chamado Administration.
Clicando na opo Plugins, ser mostrada uma tela com todos
os plugins instalados no sistema. Para que se consiga fazer uma
integrao com o Tortoise, deve-se baixar e instalar (opo
install plugin) a extenso Trac XML-RPC Plugin, o qual far com
que os servidores Trac consigam ser vistos pelos programas
clientes SVN.
5. Deve-se baixar tambm um programa de auxlio ao Trac
chamado TracExplorer, o qual permite a visualizao extena
dos servidores Trac, dentro dos clientes SVN. Sua instalao
simples. Depois de feito o download do pacote, so executar
a instalao e avanar at o final.
6. Com o Trac configurado, pode-se configurar o Tortoise para
as conexes. Em alguma pasta do projeto que esteja versiona-
do com o repositrio MyProject, clica-se com o boto direito
e seleciona-se a opo Settings no Tortoise, onde ser exibida
a tela de configurao do cliente. Navega-se at a opo Issue
Tracker Integration e depois clica-se no boto Add....
Ser apresentada uma tela onde deve ser informado o di-
retrio local de projeto (Working Copy Path) e Parmetros de
configurao do Trac (Parameters), clicando na opo Options
para configur-los. Na tela que surgir, seleciona-se a opo Add
New Trac Server para cadastrar o local onde est o sistema de
controle de mudanas (Figura 7), onde devem ser informados
o endereo do servidor, o usurio e a senha, atravs da seleo
da opo Basic Autentication. Avanando, ser configurado o
servidor do Trac para aquela cpia do repositrio.
Listagem 1. Criao do usurio adminitrador do Trac.
cd\
C:\PythonServer\trac\python\python.exeC:\PythonServer\trac\python\
scripts\trac-admin-script.pyC:\Trac\MyProject permission add jaum TRAC_
ADMIN
Cdigo Explicao Caso geral
cd\ Diretrio principal cd\
C:\PythonServer\trac\
python\python.exe
Vai para o diretrio do executvel do Python C:\<diretorio_python>\python.exe
C:\PythonServer\trac\
python\scripts\
trac-admin-script.py
Vai para a pasta scripts do python, associnado o aquivo trac-admin C:\<diretorio_python>\scripts\
trac-admin-script.py
C:\Trac\MyProject Diretrio do Trac C:\Trac\<repositorio>
permission add jaum TRAC_ADMIN Permisso de administrador ao usurio permission add <nome_usuario_svn> TRAC_ADMIN
Tabela 1. Codificao dos cdigos de criao do usurio administrador do Trac
Figura 6. Menu de administrador e menu de usurio no Trac
Configurado o servidor, dentro da rvore de tickets, entra-
se em Active tickets e depois em Next, onde ser exibida a tela
mostrada na Figura 8. Clicando-se em Select all e depois em
Finish, ser dada permisso para que possam ser realizadas
as operaes selecionadas do Trac de dentro do Tortoise.
7. Com o Tortoise configurado para aquela cpia do repo-
sitrio, s falta configurar as opes de comitt para aquela
pasta. Novamente clica-se com o boto direito no diretrio
local do projeto e em propriedades. Dentro dela procura-
se a aba Subversion e depois o boto Properties.... Assim
aparecer a tela de configurao do Subversion, onde se
pode adicionar as propriedades descritas na Tabela 2, se-
lecionando o boto New...
8. A configurao do Tortoise com o Trac est completa, agora
preciso configurar o arquivo post-commit que fica dentro da
pasta do repositrio de dados. Para isso, deve-se copiar os
arquivos trac-post-commit-hook e trac-post-commit-hook.cmd que
ficam no diretrio de instalao do Trac para a pasta de script
Figura 7. Configurao do Trac dentro do TortoiseSVN
DESENVOLVI MENTO
Figura 8. Configurao de Tickets para o Trac no Tortoise
Propriedade Valor
bugtraq:append True
bugtraq:label Tcket N:
bugtraq:logregex ([Cc]lose[sd]?|[Ff ]ix(e?[ds])?|[Rr]e(fs)?|[Rr]e(ferences)?|
[Aa]ddresses|[Ss]ee)\s(#|ticket:)(\d+)(((,\s)|(\s&\s)|(\sand\s))(#|ticket:)(\d+))*
(\d+)
bugtraq:message Ticket: %BUGID%
bugtraq:url http://localhost/trac/MyProject/ticket/%BUGID%
bugtraq:warnifnoissue True
webviewer:pathrevision http://localhost/trac/MyProjectr/browser/%PATH%?rev=%REVISION%
webviewer:revision http://localhost/trac/MyProject/changeset/%REVISION%
Tabela 2. Propriedades do diretrio de trabalho no TortoiseSVN
do diretrio que fica o executvel do Python. Na pasta hooks
do repositrio MyProject, deve-se trocar a extenso do arquivo
post-commit para post-commit.bat. Ento, deve-se apagar todo o
contedo que se encontra dentro do arquivo e digitar o que
est descrito na Listagem 2. Deve-se trocar os caminhos do
comando de acordo com a necessidade e diretrios de insta-
lao do Python.
Listagem 2. Post-commit.bat.
cd \
cd C:\PythonServer\trac\python\Scripts
C:\PythonServer\trac\python\python.exe trac-post-commit-hook -p C:\trac\
MyProject -r %2
9. Seguindo esses passos, o Trac, o Subversion e o Tortoise
esto configurados e prontos para o uso.
Para exemplificar essa integrao com o Trac, ser aberto
um novo ticket no sistema como se fosse uma correo de
bug (Figura 9). Na abertura do ticket informado o ttulo e
a descrio do problema, verso do sofware, responsvel, e
outras informaes importantes.
Figura 9. Criao de tickets do Trac
Suponhamos que o erro esteja corrigido, ento pode-se
realizar o commit para o repositrio SVN para versionar o
cdigo fonte do projeto. Ao clicar na opo SVN Commit... do
Tortoise, o usurio encontra uma tela diferente da padro do
cliente. Nessa tela se encontra o boto Choose tickets, onde ser
exibida o TracExplorer (Figura 10), no qual possvel selecio-
nar qual o ticket que aquela correo ser responsvel, e que
tipo de operao foi resolvida. A correo ento realizada no
repositrio e foi gerada uma nova reviso do projeto.
Figura 10. Commit do Tortoise e o TracExplorer mostrando as operaes
do ticket
Novamente no Trac, no menu Time Line (uma linha do
tempo com tudo que foi realizado no repositrio), pode-se
ver as operaes que acabaram de ser realizadas ou um
histrico de tudo que j aconteceu. Seleciona-se o registo
de ticket mais atual e, aps o carregamento da tela, v-se o
status do mesmo juntamente com seu histrio de atualizao
(Figura 11).
Figura 11. Ticket fechado e histrio de alteraes
Concluso
Este artigo apresentou a como integrar um sistema de con-
trole de mudana (Trac) com o Subversion e seu cliente, o
TortoiseSNV.
Com o uso de interaes entres esses softwares, um projeto
poder ser melhor controlado. Isto poder trazer economia
de tempo, e delegaes de responsabilidade, onde qualquer
alterao feita em um projeto por determinado usurio salva
nas alteraes dos tickets abertos do Trac.
Projeto Trac
http://trac.edgewall.org/
Subverion
http://subversion.tigris.org/
VisualSVN
http://www.visualsvn.com/server/download/
VisualSVN e Trac
http://www.visualsvn.com/server/trac/
TortoiseSVN
http://tortoisesvn.tigris.org/
TracExplorer
http://sourceforge.net/apps/trac/vstrac/wiki
Trac XMP-RPC
http://code.google.com/p/cubeon/downloads/detail?name=TracXMLRPC-1.5.0-py2.5.egg
Links
SUSSMAN, Ben Collins Brian W. Fitzpatrick, C. Michael Pilato. Controle de Verso com Subversion.
California - EUA: Creative Commons, 2007.
KNG , Stefan, Lbbe Onken, e Simon Large. TortoiseSVN: Um aplicativo do Subversion para
Windows. 2010.
Referncias
D

s
e
u
Feedba
c
k
s
o
b
r
e

e
s
t
a
e
d i o
DESENVOLVI MENTO

Engenharia de Software - Edição 26

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia de Software - Edição 26

Enviado por

Direitos autorais:

Formatos disponíveis

www.infnet.edu.br - cursos@infnet.edu.

br - Central de Atendimento: (21) 2122-8800

Você também pode gostar