Modéstia à parte, sua

melhor opção para

se destacar no mercado!
A Escola Superior da Tecnologia da PÓS- GRADUAÇÃO
Informação oferece as melhores Engenharia de Software:
opções em cursos, formações, Desenvolvimento Java
graduações e pós-graduações para Engenharia de Software:
Desenvolvimento .NET
profissionais de desenvolvimento
GRADUAÇÃO
e programação.
Engenharia de Computação
São programas voltados para a Análise e Desenv. de Sistemas
formação de profissionais de elite,
F ORMAÇÕES
com aulas 100% práticas, corpo
Desenvolvedor Java
docente atuante no mercado,
Desenv. Java: Sist. Distribuídos
acesso à mais atualizada biblioteca
Gestor de TI
de TI do Rio, laboratórios equipados
Desenvolvedor Web .NET 2008
com tecnologia de ponta, salas de
MCITP Server Administrator
estudo e exames.
SQL Server 2008

r/esti
Acesse nosso site e conheça todos os nossos programas: www.infnet.edu.br/esti

TURMAS
NO RIO DE
JANEIRO
www.infnet.edu.br - cursos@infnet.edu.br - Central de Atendimento: (21) 2122-8800

EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO

 EDITORIAL

O
propósito da qualidade é estabelecer um diferencial competi-
tivo, através de contribuições como redução de defeitos, redu-
ção de custos, redução de retrabalho e aumento da produtivi-
dade, entre outras. Existem diversas iniciativas para garantia da qualida-
de de produtos e processos nas empresas. Nesta edição, a Engenharia
Ano 2 - 21ª Edição - 2010 Impresso no Brasil de Software Magazine destaca duas delas:
• CMMI, (Capability Maturity Model Integration), um modelo de ma-
turidade mundialmente conhecido, usado para criar uma infraestrutu-
Corpo Editorial ra de processos organizacionais, abordando domínios específicos, tais
como software e engenharia de sistemas.
Colaboradores
Rodrigo Oliveira Spínola • Seis Sigma, uma metodologia criada pela Motorola, caracterizada por
rodrigo@sqlmagazine.com.br uma abordagem sistêmica e utilização intensiva do pensamento esta-
Marco Antônio Pereira Araújo tístico, que visa a redução de defeitos nos produtos para 3,4 defeitos
Eduardo Oliveira Spínola por milhões de oportunidades (Seis Sigma) por meio da otimização de
Capa produtos e processos.
Romulo Araujo - romulo@devmedia.com.br Neste contexto, temos como capa desta edição um artigo que fornece
a compreensão necessária das relações entre as iniciativas e propor a
Diagramação
Janete Feitosa utilização do Seis Sigma na melhoria da qualidade de software para a
obtenção dos níveis de maturidade 4 e 5 do CMMI.
Coordenação Geral Além desta matéria, esta edição traz mais cinco artigos:
Daniella Costa - daniella@devmedia.com.br
• Colaboração em Processos de Aquisição de Software
Revisor e Supervisor • Customização e Integração de Ferramentas Open-Source
Thiago Vincenzo - thiago.v.ciancio@devmedia.com.br
• Organização Fábrica de Experiência
Na Web • Métricas de Software
www.devmedia.com.br/esmag
• Integração contínua com Hudson, Maven2, TestNG e Subversion
Apoio

Desejamos uma ótima leitura!

Equipe Editorial Engenharia de Software Magazine

Rodrigo Oliveira Spínola

Atendimento ao Leitor rodrigo@sqlmagazine.com.br
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Doutorando em Engenharia de Sistemas e Computação (COPPE/UFRJ). Mestre em
Se você tiver algum problema no recebimento do seu exemplar ou precisar de Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Ciências da Computa-
algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de ção (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), ten-
bancas de jornal, entre outros, entre em contato com: do ministrado cursos na área de Qualidade de Produtos e Processos de Software,
Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementação
Cristiany Queiróz– Atendimento ao Leitor do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de
www.devmedia.com.br/mancad
(21) 2220-5338 consultoria na COPPE/UFRJ. É Colaborador da Engenharia de Software Magazine.
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
(21) 2220-5338
Marco Antônio Pereira Araújo
(maraujo@devmedia.com.br)
Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ - Li-
Publicidade
nha de Pesquisa em Engenharia de Software, Especialista em Métodos Estatísticos
Para informações sobre veiculação de anúncio na revista ou no site entre em
Computacionais e Bacharel em Matemática com Habilitação em Informática pela
contato com:
UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informação
Kaline Dolabella
publicidade@devmedia.com.br do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado
em Sistemas de Informação da Faculdade Metodista Granbery, Professor e Diretor
Fale com o Editor!
do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo
Fundação Educacional D. André Arcoverde, Analista de Sistemas da Prefeitura de
você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a
Juiz de Fora, Colaborador da Engenharia de Software Magazine.
vontade para entrar em contato com os editores e dar a sua sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
entre em contato com os editores, informando o título e mini-resumo do tema que você
Eduardo Oliveira Spínola
(eduspinola@gmail.com)
gostaria de publicar:
É Colaborador das revistas Engenharia de Software Magazine, Java Magazine e
Rodrigo Oliveira Spínola - Colaborador
SQL Magazine. É bacharel em Ciências da Computação pela Universidade Salva-
editor@sqlmagazine.com.br
dor (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computação na
linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia
de Software e Aplicações).
 Caro Leitor,
Para esta edição, temos um conjunto de 4 vídeo
aulas. Estas vídeo aulas estão disponíveis para
download no Portal da Engenharia de Software
Magazine e certamente trarão uma significativa
contribuição para seu aprendizado. A lista de
aulas publicadas pode ser vista abaixo:
Tipo: Requisitos
Título: Diagrama de Casos de Uso na Prática – Partes 4 a 7
Autor: Rodrigo Oliveira Spínola
Mini-Resumo: Estas aulas são parte de uma série sobre a
construção de diagrama de casos de uso da UML. O objetivo
do conjunto de aulas é apresentar de forma prática como
elaborar o diagrama de casos de uso a partir de diferentes
estudos de caso. Nestas aulas, serão elaborados diversos dia-
gramas de casos de uso. Também será visto como especificar
um caso de uso para um dos diagramas elaborados.
4 Engenharia de Software Magazine
ÍNDICE
Abordagens Tradicionais de Desenvolvimento
05 - Seis Sigma e CMMI
Luiz Fernando da Silva Fiel, Ana Nathalie de Mello Rodrigues e Marcelo Nascimento Costa
32 - Colaboração em Processos de Aquisição de Software
João Condack, Rafael Vieira
38 - Organização Fábrica de Experiência
Fernando Hadad Zaidan, George Leal Jamil e Leandro Libério da Silva
43 - Customização e Integração de Ferramentas Open-Source
Felipe Furtado, Gustavo Carvalho, Andrea Pinto e Ryan Albuquerque
50 - Métricas de Software
Thamine Chaves Leite de Abreu, Leonardo da Silva Mota e Marco Antônio Pereira Araújo
Validação, Verificação e Teste
56 - Integração contínua com Hudson, Maven2, TestNG e Subversion
Victor Vidigal Ribeiro, Fabrício Nogueira de Almeida e Marco Antônio Pereira Araújo
Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
Seis Sigma e CMMI
Uso do Seis Sigma para Melhoria da Qualidade de Software junto aos Altos
Níveis de Maturidade do CMMI
Luiz Fernando da Silva Fiel
Bacharel em Ciência da Computação pelo
Centro Universitário Metodista Bennett.
Ana Nathalie de Mello Rodrigues
Estagiária na área de Governança de TI da
Wilson, Sons. Bacharel em Ciência da Com-
putação pelo Centro Universitário Metodis-
ta Bennett. Técnica em Processamento de
Dados pela FAETEC.
Marcelo Nascimento Costa
mnc@kalisoftware.com
Diretor de Tecnologia da Kali Software.
Mestre em Engenharia de Sistemas e
Computação pela COPPE/UFRJ. Bacharel
em Ciência da Computação pela UFPA.
Especialista em CMMI, tendo participado
de diversas implementações e avaliações
deste modelo. Professor do curso de Ciên-
cia da Computação do Centro Universitário
Metodista Bennett.
O
propósito da qualidade é esta-
belecer um diferencial compe-
titivo, através de contribuições
como redução de defeitos, redução de
custos, redução de retrabalho e aumento
da produtividade, entre outras.
Existem diversas iniciativas para
garantia da qualidade de produtos e
processos nas empresas. Para este artigo,
selecionamos duas:
• CMMI, (Capability Maturity Model
Integration), um modelo de maturidade
mundialmente conhecido, usado para
criar uma infraestrutura de processos
organizacionais, abordando domínios
específicos, tais como software e enge-
nharia de sistemas.
• Seis Sigma, uma metodologia criada
pela Motorola, caracterizada por uma
abordagem sistêmica e utilização inten-
siva do pensamento estatístico, que visa
a redução de defeitos nos produtos para
3,4 defeitos por milhões de oportunida-
des (Seis Sigma) por meio da otimização
de produtos e processos.
Edição 21 - Engenharia de Software Magazine
O objetivo deste artigo é fornecer a
compreensão necessária das relações
entre as iniciativas e propor a utilização
do Seis Sigma na melhoria da qualidade
de software para a obtenção dos níveis
de maturidade 4 e 5 do CMMI.
Introdução
Motivação
Em meados dos anos 80, influenciado
pela introdução crescente de técnicas
industriais japonesas nas fábricas bra-
sileiras, o conceito de melhoria da qua-
lidade ganhou destaque. Foi o auge do
impacto nipônico na indústria nacional,
impulsionado por visita de técnicos bra-
sileiros ao Japão em missões especiais e
pelo sucesso das ferramentas japonesas
de administração da qualidade.
O desenvolvimento de novas técnicas
de produção e a adaptação de proce-
dimentos criados, sobretudo no Japão,
foram experiências marcantes no perío-
do, caracterizado também pelo advento
5
da norma ISO 9000, então vista como nova forma de avaliar o
processo produtivo.
No Brasil, o termo “qualidade” tem mudado seguidamente de
sentido. Ainda persiste a ideia de que a qualidade é o esforço
para minimizar defeitos. Como também permanece a visão
de que a qualidade está restrita às melhorias localizadas. Ou
até mesmo a uma maior qualificação das pessoas. Mas atual-
mente a qualidade já pode ser vista como um diferencial ou
até mesmo como um item básico de manutenção da empresa,
principalmente nestes tempos de concorrência acirrada (CAR-
VALHO; PALADINI, 2005).
Em termos simples e objetivos, o propósito da qualidade é
estabelecer um diferencial competitivo. Ou seja: garantir um
espaço para a organização, diferenciando-a das demais exis-
tentes no mercado. Em outras palavras: fixar raízes à frente
dos concorrentes.
A qualidade oferece contribuições operacionais que não po-
dem ser desprezadas, como por exemplo: redução de defeitos,
redução de custos, redução de retrabalho, aumento da produti-
vidade. Existem também contribuições táticas relevantes como
a formação de pessoas mais preparadas para tomar decisões
gerenciais críticas para o funcionamento da empresa. Mas as
contribuições mais relevantes são as de natureza estratégica:
garantir não apenas a sobrevivência da organização, mas seu
contínuo crescimento (evolução).
Considerando o escopo das empresas de processo de sof-
tware, além das certificações ISO entre outras iniciativas
aplicáveis, existem modelos de maturidade como o CMMI e
o MPS.BR, que podem ser utilizados para atingir os objetivos
de qualidade desejados.
O que move as empresas no processo de obtenção das certifi-
cações dos altos níveis de maturidade (tanto do CMMI quanto
do MPS.BR) é a necessidade de se ter qualidade de processos,
condições de previsibilidade em termos de prazo, de custo e
de volume de trabalho a ser feito para que consiga satisfazer o
cliente. As empresas estão sempre em evolução para atender as
exigências do mercado cada vez mais competitivo e com as cer-
tificações de maturidade, são adquiridas condições de medir a
melhoria e comprovar as vantagens de se encontrar em outro
nível de excelência em termos de controle de processos.
Para algumas empresas, as principais dificuldades encontra-
das na obtenção dos mais altos níveis são: o custo de implemen-
tação (melhorar requer mudanças e mudanças geram custos) e a
maturidade organizacional, que requer também uma mudança
cultural e a colaboração de todas as equipes. Estas dificuldades
trazem resistência por parte dos envolvidos, porém, ao longo
do tempo percebe-se que o custo é muito maior quando não
se pratica estes processos, pois o nível de qualidade é menor
e há muito retrabalho.
Objetivos
Este artigo propõe uma solução integrada em termos de me-
lhoria de processos de software e obtenção de altos níveis de
maturidade, através da utilização de duas iniciativas:  não o processo. Como exemplo disso, no final do século XIX, a
1. CMMI (Capability Maturity Model Integration) -  um modelo
6 Engenharia de Software Magazine - Seis Sigma e CMMI
de maturidade mundialmente conhecido, usado para criar
uma infraestrutura de processos organizacionais, abordando
domínios específicos, tais como software e engenharia de
sistemas;
2. Seis Sigma - uma iniciativa top-down que abrange toda a
empresa, incluindo áreas como engenharia, vendas, marketing
e pesquisa.  Pode ser definido como “estratégia gerencial,
filosofia ou metodologia”, que tem por objetivo reduzir dras-
ticamente a variabilidade dos processos críticos e aumentar a
lucratividade das empresas, por meio da otimização de produ-
tos e processos, buscando satisfação de clientes e consumidores
(CARVALHO; PALADINI, 2005).
Concepções tão diferenciadas podem gerar dúvidas como:
“Será que é interessante utilizar ambos no mesmo processo
de melhoria? A qualidade pode aumentar dessa forma? O Seis
Sigma é uma boa alternativa para empresas de TI?”. Desta for-
ma, o objetivo deste artigo é fornecer a compreensão necessária
das relações entre as iniciativas, de modo que sua aplicação
em conjunto seja bem sucedida.
Organização do Artigo
Os tópicos a seguir mostram como está organizado este
artigo.
Inicialmente será abordado o histórico dos modelos de
qualidade, passando por gestão e excelência, e trata do mo-
delo CMMI, mostrando suas principais características, como
estrutura e benefícios.
Na sequencia, é apresentado o Seis Sigma, fazendo um relato
do histórico, objetivos, perfis das pessoas responsáveis pela
implementação do modelo e suas metodologias.
Feito isto, é apresentada aplicação do Seis Sigma na melhoria
dos processos de qualidade de software, através do mapeamen-
to de suas atividades com as práticas definidas nos níveis de
maturidade 4 e 5 do CMMI. Ainda neste tópico, é apresentado
um estudo de caso da aplicação integrada do Seis Sigma e
CMMI em uma empresa de software, mostrando como esta
estratégia de melhoria de processos pode trazer benefícios
significativos. Finalmente, é apresentada a conclusão deste
trabalho.
Histórico dos Modelos de Qualidade
Relatos Históricos
A necessidade pela gestão da qualidade surgiu há muitos
anos atrás, onde os artesãos faziam todo o processo, desde a
concepção até o pós-venda de seus produtos. Como a popu-
lação não era numerosa, as necessidades eram mínimas e o
trabalho era artesanal. O artesão, sabendo que seus produtos
dependiam da reputação de qualidade, que era feita pelo boca
a boca dos clientes, usava como abordagem de qualidade o
atendimento às necessidades do cliente. Por esse motivo, nessa
época o foco do controle da qualidade ainda era o produto,
montadora de automóveis Panhard e Levassor (P&L) montava

seus veículos atendendo às necessidades dos clientes que a
procuravam, e como era um produto para poucos, não havia
dois carros iguais.
Em 1750, durante a Revolução Industrial, surgiram as
primeiras máquinas projetadas para obter grande volume
de produção e uma nova forma de organização do trabalho
permitiu alcançar a produção em massa. Nessa nova ordem
produtiva, a customização foi substituída pela padronização
e a produção em larga escala.
A linha de montagem era o modelo ideal para a produção
em massa. O trabalho foi fragmentado e os trabalhadores
tinham domínio apenas de uma pequena fração do trabalho.
O trabalhador não fazia mais parte das etapas de concepção e
planejamento e surgiu a função do inspetor, responsável pela
qualidade dos produtos.
No período de 1908 a 1927, a Ford tinha apenas um carro na
linha de montagem, o modelo Ford T ou Ford Bigode, como era
conhecido. Tinha uma única cor, a preta. De qualquer forma, 15
milhões de unidades foram vendidas. O carro passou a ser um
produto acessível à classe trabalhadora, mudando o conceito
dessa indústria, que investiu em capacidade para atender à
demanda, que era maior que a oferta. Como um veículo ainda
diferia bastante de outro produzido sob o mesmo projeto, a
Ford investiu na intercambialidade das peças e na facilidade
de ajustes, adotando um sistema padronizado de medida para
todas as peças. O modelo de linha de montagem se difundiu
em outros industriais, e para garantir a intercambialidade das
peças, tornou-se importante investir no desenvolvimento de
áreas com a metrologia, sistema de medidas e especificações.
O foco da qualidade ainda era a inspeção, mas já existiam
elementos que mostravam o que viria a ser o conceito de qua-
lidade que priorizava uma abordagem voltada à produção e
à conformidade.
Gestão da Qualidade
Existem algumas pessoas que são consideradas como Gu-
rus da Qualidade. Eles foram alguns teóricos que ajudaram
a construir a área de qualidade e tiveram um papel especial
para merecer a denominação. Alguns dos Gurus mais citados
são: Walter A. Shewhart, W. Edwards Deming, Joseph M. Ju-
ran, Armand Feigenbaum, Philip B. Crosby, Kaoru Ishikawa
e Genichi Taguchi.
Em 1924, Walter A. Shewhart fez o conceito de controle da
qualidade dar um novo salto, criando os gráficos de contro-
le. Com essa ferramenta, Shewhart fundiu os conceitos de
estatística em um método gráfico de fácil utilização no chão
de fábrica e os aplicou à realidade produtiva da empresa de
telefonia Bell Telephone Laboratories.
A ferramenta proposta analisava os resultados das inspeções,
que até aquele momento eram utilizadas apenas para a segrega-
ção dos produtos com defeito, por meio de gráficos de controle,
que permitiam facilmente distinguir entre as causas de variação
comuns ao processo e aquelas causas especiais, que deveriam ser
investigadas. Com a análise desses resultados à luz dos conceitos
estatísticos era possível sair de uma postura reativa e entender e
M etodologias Ágeis
prever o comportamento do processo, o que permitiria uma ação
proativa, evitando novas ocorrências. A facilidade de utilização
do gráfico foi um dos aspectos que ajudou na sua difusão, pois
era uma ferramenta visual, que podia ser preenchida no am-
biente de trabalho, com os parâmetros estatísticos do processo
já sintetizados (CARVALHO; PALADINI, 2005).
Geralmente, o gráfico de controle é utilizado na detecção de
alterações inusitadas de uma ou mais características de um
processo ou produto. Em outras palavras, é uma ferramenta
estatística que alerta para a presença de causas especiais gran-
des na linha de produção. Existem diversos tipos de gráficos
de controle e cada um deles é melhor aplicável a determinadas
situações. Normalmente, todos os tipos de gráficos de controle
seguem a estrutura da Figura 1.
Figura 1. Gráfico de controle em formato conceitual (Fonte: Adaptação
(CARVALHO; PALADINI, 2005))
O gráfico consiste na plotagem de três linhas e os pontos que
representam as médias de pequenas amostras (chamados sub-
grupos racionais), cada qual de tamanho n (= 1, 4, 9, 16, 1000, por
exemplo), de mensurações periódicas de alguma característica
importante de um processo (peso, cumprimento, volume etc.),
ou o número ou porcentagem de peças defeituosas ou número
de defeitos. As três linhas representam dois limites de controle,
um superior (LCS) e outro inferior (LCI), e uma linha no meio
que é a média da variável ou o alvo da característica.
Tradicionalmente, as linhas de controle ficam numa distância
de três desvios-padrão da média ou do alvo do processo. Os
limites definem uma área razoavelmente grande que vai evitar
alarmes falsos. O desvio-padrão utilizado é o desvio-padrão
das médias (erro-padrão); teoricamente, é o desvio-padrão da
população dividido pela raiz quadrada do tamanho da amos-
tra - σ/√n. Em termos estatísticos, os dois limites de controle
definem um intervalo de confiança com nível de confiança de
99,73%. Esse número significa que um alarme falso pode ocor-
rer uma vez em 370 subgrupos. Se forem tiradas 16 amostras
por dia numa fábrica, o alarme falso iria ocorrer apenas uma
vez a cada 23 dias, um preço muito razoável, considerando-se
o grande valor relacionado aos gráficos de controle (CARVA-
LHO; PALADINI, 2005).
Edição 21 - Engenharia de Software Magazine 7
 Walter A. Shewhart também propôs o ciclo PDCA (plan-do-
check-act), que direcionaria as atividades de análise e solução
de problema, percorrendo o ciclo de planejar, fazer, checar o re-
sultado e depois agir, ou seja, implementar a melhoria e garan-
tir o alcance das metas na empresa, disseminado para o mundo
por Deming William Edwards, que era seu discípulo.
O ciclo PDCA é composto das seguintes etapas (Figura 2):
• Caso não sejam identificados desvios, é possível realizar
um trabalho preventivo, identificando quais os desvios são
passíveis de ocorrer no futuro, suas causas, soluções etc.
O PDCA pode ser utilizado na realização de toda e qualquer
atividade da organização (Tabela 1). O ideal é que todos utilizem
esta ferramenta de gestão no dia-a-dia de suas atividades.

Da Gestão da Qualidade para a Qualidade Total

A gestão da qualidade consiste no conjunto de atividades coor-
denadas para dirigir e controlar uma organização com relação à
qualidade, englobando o planejamento, o controle, a garantia e
a melhoria da qualidade (CARVALHO; PALADINI, 2005).
Esse conceito necessita ser trazido para o âmbito organiza-
cional, ou seja, precisa ser “operacionalizado” na organização.
Existe uma necessidade de gerenciar o conjunto de atividades re-
lativas à qualidade, de modo que atenda a qualquer enfoque.
A Figura 3 mostra a relação entre a definição da qualidade
Figura 2. Ciclo PDCA estabelecida pela norma ISO 9000: 2000, seguido pela necessi-
dade de trazer essa definição para a operação organizacional,
Planejar (PLAN) por meio da gestão da qualidade, que, por sua vez, se subdivide
• Definir as metas a serem alcançadas; em planejamento, controle, garantia, e melhoria da qualidade,
• Definir o método para alcançar as metas propostas. cujas definições são também apresentadas na Figura 3 (CAR-
VALHO; PALADINI, 2005).
Executar (DO)
• Executar as tarefas exatamente como foi previsto na etapa
de planejamento;
• Coletar dados que serão utilizados na próxima etapa de
verificação do processo;
• Nesta etapa são essenciais a educação e o treinamento no
trabalho.

Verificar, checar (CHECK)

• Verificar se o executado está conforme o planejado, ou seja,
se a meta foi alcançada, dentro do método definido;
• Identificar os desvios na meta ou no método.

Agir corretivamente (ACTION)

• Caso sejam identificados desvios, é necessário definir e im- Figura 3. Inter-relação entre o conceito de qualidade, Gestão da Qualidade e
plementar soluções que eliminem as suas causas; elementos que a compõem. Fonte: Adaptação (CARVALHO; PALADINI, 2005)

PDCA FLUXO ETAPA OBJETIVO

1 Identificação do Problema
2 Observação
P
3 Análise
4 Plano de ação
D 5 Execução
Definir claramente o problema/processo e reconhecer sua importância.
Investigar as características específicas do problema/processo com uma visão ampla e sob vários pontos de vista.
Descobrir a causa fundamental.
Conceber um plano para bloquear a causa fundamental.
Bloquear a causa fundamental.

C 6 Verificação Verificar se o bloqueio foi efetivo.

7 Padronização Prevenir contra o reaparecimento do problema.

A
8 Conclusão Recapitular todo o método de solução do problema para trabalhos futuros.

Tabela 1. Etapas do Ciclo PDCA (Fonte: Adaptação (SSPJ, 2009))

8 Engenharia de Software Magazine - Seis Sigma e CMMI

 M etodologias Ágeis

A partir da Figura 3, que mostra o conceito de Após uma evolução, o TQC viria a se tornar o TQM (Gestão de Qualidade
gestão da qualidade, e das inter-relações mostradas, Total ou Total Quality Management). Esse termo surgiu em 1980.
o que poderia definir a “qualidade total”? A ideia central do TQM é que a qualidade esteja presente na função de
De acordo com a ISO 8402: 1994, pode ser defini- gerenciamento organizacional, em uma tentativa de ampliar seu foco,
da como o “modo de gestão de uma organização, não se limitando às atividades inerentes ao controle (CARVALHO; PA-
centrado na qualidade, baseado na participação LADINI, 2005).
de todos os membros, visando ao sucesso a longo Desde seu surgimento até meados da década de 1990, diversos estudos
prazo, por meio da satisfação do cliente e dos be- indicaram elementos que são considerados como fatores críticos que
nefícios para todos os membros da organização e devem estar presentes no TQM. São eles:
sociedade”. • Liderança e apoio da alta direção;
A origem da qualidade total remonta à década de • Relacionamento com os clientes;
1950. Armand Feigenbaum foi o primeiro a tratar a • Gestão da força de trabalho;
qualidade de forma sistêmica nas organizações, for- • Relação com os fornecedores;
mulando o sistema de Controle da Qualidade Total • Gestão por processos;
(TQC – Total Quality Control) em seu livro. • Projeto de produto;
Essa origem desencadeou o conceito do que viria • Fatos e dados da qualidade.
a tornar-se duas correntes similares, porém diferen-
ciadas, do TQC: a visão japonesa, conhecida como Modelos de Excelência
CWQC (Company-wide Quality Control – que no A qualidade total é bastante ampla, envolvendo diversas áreas fun-
Brasil foi traduzido para Qualidade por Toda a Em- cionais das organizações, mas também diferentes conceitos, que vão
presa ou Controle da Qualidade Amplo Empresarial) desde a liderança até os meios de controle nos processos produtivos.
e a visão norte-americana do TQC. Uma evolução no conceito da qualidade total veio com a necessidade de
O CWQC surgiu no Japão no final de década de 60. incorporar os diversos interesses dos stakeholders (partes interessadas) de
Kaoru Ishikawa teve importante papel no CWQC,
contribuindo para sua formulação. Em alguns livros,
os autores traduzem o TQC japonês da seguinte
forma: o compromisso para a qualidade total, enal-
tecendo o envolvimento e comprometimento dos
funcionários com essa prática, aliado ao apoio da
alta direção da empresa.
Outro ponto central do CWQC é o gerenciamento
pelas diretrizes, que direciona o foco organizacional
às metas da organização por meio do desdobramen-
to dessas metas e do envolvimento e autonomia dos
funcionários na gestão das atividades diárias da
organização.
No TQC americano existe outro foco, que Feigen-
baum define como um sistema eficaz para integrar a
manutenção da qualidade e os esforços de melhoria
da qualidade dos vários grupos na organização, de
modo a possibilitar a produção em níveis mais eco-
nômicos, permitindo alcançar a completa satisfação
dos clientes.
Mesmo existindo diferenças entre as linhas de
pensamento japonesa e americana, sobre o que
vem a ser o TQC, na essência, o conceito é bastante
similar. No Japão acontece um maior envolvimento
e comprometimento dos funcionários nas atividades
da gestão da qualidade e nos Estados Unidos existe
muita ênfase à aplicação de métodos e técnicas asso-
ciadas à qualidade. Outro ponto é que nos Estados
Unidos a maior preocupação é com a detecção dos
problemas e segregação dos produtos com defeitos
e no Japão, as empresas desenvolvem processos
capazes de detectar e evitar os problemas.

Edição 21 - Engenharia de Software Magazine 9

uma organização na busca da excelência em desempenho. No
passado, o acionista ou proprietário da organização era a maior
parte interessada em seu desempenho, para o qual era dada a
maior atenção e importância. Atualmente ele continua sendo
mais importante, mas a alteração do enfoque considera hoje
outros indivíduos, grupos de indivíduos, ou seja, agentes inte-
ressados no desempenho de uma organização. Essa mudança
ocorreu pelo fato de não ser suficiente que uma organização
concentre seus esforços somente no desempenho financeiro.
O enfoque deve considerar as pessoas e processos e os agentes
internos e externos, que são formados pelos acionistas ou pro-
prietários, pelos clientes da organização, pela força de trabalho,
pelos funcionários e pela comunidade e sociedade.
Os modelos de excelência visam a avaliar a gestão de uma
organização com relação às práticas de gestão utilizadas e
os resultados organizacionais, de forma direcionada para
atender às necessidades de seus stakeholders. As organizações
descrevem as práticas organizacionais por meio de um re-
latório, que é avaliado por especialistas. Posteriormente, as
organizações recebem um relatório de avaliação, podendo ou
não ser premiadas. A premiação é um reconhecimento das
práticas de gestão.
Prêmio Deming
Em junho de 1950, W. Edwards Deming foi ao Japão falar
sobre controle de qualidade, a convite da União da Ciência e
Engenharia Japonesa (JUSE). Entre 1950 e 1952 Deming conse-
guiu reunir e sensibilizar os principais executivos japoneses
das grandes empresas e mostrou-lhes a importância do con-
trole estatístico da qualidade (ABRANTES, 2001).
A convivência com os japoneses durou quase duas décadas,
período em que as empresas japonesas fizeram uma verda-
deira revolução, em termos de qualidade. Em agradecimento
ao papel desempenhado, Deming era tratado como pai do
controle de qualidade no Japão e seu nome tornou-se o Prêmio
Japonês da Qualidade – Deming Prize (CARVALHO; PALA-
DINI, 2005).
O modelo de excelência Deming Prize ou Prêmio Deming, foi
o primeiro prêmio da qualidade lançado no mundo, visando
a avaliar o desempenho das organizações. Ele foi aberto para
organizações não japonesas em 1984. O julgamento do prêmio
é baseado em dez critérios principais:
1. Política;
2. Organização e sua Operação;
3. Informação;
4. Padronização;
5. Recursos Humanos;
6. Garantia da Qualidade;
7. Manutenção;
8. Melhoria;
9. Efeitos (Resultados);
10. Planos Futuros.
Atualmente o Japão conta com um outro modelo de exce-
lência, chamado Japan Quality Award. Ele é dividido em oito
10 Engenharia de Software Magazine - Seis Sigma e CMMI
critérios e apresenta um critério especificamente direcionado à
responsabilidade social, considerando resposta aos requisitos
sociais e contribuição para a sociedade.
Malcolm Baldrige National Quality Award
Em 1987, para aumentar a competitividade nas empresas
americanas, os Estados Unidos lançaram o Malcolm Baldrige
National Quality Award, esse modelo foi uma das tentativas
de resposta para responder à invasão de produtos japoneses
naquele país.
O principal objetivo do prêmio nacional da qualidade
americano é melhorar a competitividade das empresas ame-
ricanas por meio da conscientização para a qualidade, do
reconhecimento dos resultados de excelência em desempenho
nas empresas americanas e da publicação desses resultados
de sucesso das empresas premiadas, como fator de troca de
informações e experiência.
Prêmio Europeu da Qualidade
O Prêmio Europeu da Qualidade, EFQM (European Quality
Award), é a estrutura mais utilizada na Europa e é a base para
a maioria dos prêmios de qualidade nacionais e regionais. É
usado como ferramenta de avaliação para as empresas e tam-
bém como modelo de gestão para definir como as organizações
podem melhorar o desempenho. Sobre o modelo:
• É uma estrutura para o sistema de gestão da organização;
• Pode ser usado como parte de uma auto-avaliação;
• For ne c e u m q uad r o de c ompa raç ão c om out ra s
organizações;
• Ajuda a identificar áreas que podem passar por uma
melhoria.
O EFQM tem a seguinte premissa: excelentes resultados, no
que diz respeito ao desempenho, clientes, pessoas e sociedade,
são alcançados através da liderança conduzindo a política e
a estratégia, que é entregue através das pessoas, parcerias,
recursos e processos. Ou seja, a ideia é que a satisfação do con-
sumidor, funcionários e o impacto na sociedade são atingidos
através de liderança, política de direção e estratégia, adminis-
tração de pessoas, recursos e processos, levando, finalmente a
excelência nos resultados da empresa.
Prêmio Nacional da Qualidade
O Brasil também tem seu modelo de excelência chamado PNQ
(Prêmio Nacional da Qualidade), que é um importante incenti-
vo à competitividade, na forma de avaliação de empresas que
buscam alcançar reconhecimento em excelência daquilo que
produzem e/ou comercializam, sejam produtos ou serviços.
O prêmio é concedido em reconhecimento a empresas com
operação no Brasil, após passarem por uma avaliação de suas
práticas.
Em 1989, um grupo de estudos iniciou um estudo sobre o
desenvolvimento de um prêmio brasileiro nos moldes dos exis-
tentes no mundo, e em 1990 o Comitê Nacional de Qualidade
e Produtividade considerou o estabelecimento de um prêmio
 M etodologias Ágeis

nacional, com participação no processo. Como resultado, em Os oito Critérios de Excelência se subdividem em 24 Itens,
11 de outubro de 1991 foi instituída a FPNQ (Fundação para conforme o ilustrado na Figura 5.
o Prêmio Nacional da Qualidade), que mudou de nome em
2005 e passou a se chamar Fundação Nacional da Qualidade. Programa de Qualidade 8S
Ela é formada por organizações públicas e privadas para ad- Em maio de 1950, o Centro de Educação para a Qualidade no
ministrar o PNQ. Japão, com a equipe do Dr. Kaoru Ishikawa, criou um modelo
A estrutura dos critérios de avaliação segue um enfoque prático para o combate às causas de perdas e desperdícios. O mo-
sistêmico, que deve ser trabalhado na forma de estratégias e delo foi nomeado de Regra dos 5S, que é formado pelas palavras
planos de ação da empresa (Figura 4). japonesas Seiri, Seiton, Seiso, Seiketsu e Shitsuke. Estas palavras
Os oito Critérios de Excelência referem-se a: podem ser traduzidas para o português, sem perderem o sentido,
1. Liderança da seguinte forma: Utilização, Ordenação, Limpeza, Bem-Estar
2. Estratégias e Planos e Autodisciplina.
3. Clientes No Japão, existem empresas que já acrescentaram mais 3S aos
4. Sociedade cinco já existentes. São eles: Shikari Yaro (Determinação e União),
5. Informações e Conhecimento Shido (Treinamento), Setsuyaku (Economia e Combate aos Des-
6. Pessoas perdícios). Dessa forma, o 5S passa a ser o Programa 8S, que é
7. Processos uma metodologia que promove a mudança de comportamento de
8. Resultados dirigentes e funcionários, que passam a formar um grupo unido
com visão de sobrevivência e continuidade dos negócios, princi-
palmente através das sugestões de melhorias dos funcionários.
O Programa 8S depende totalmente da ação das pessoas (Figura
6); assim sendo, três fatores são fundamentais para a educação,
treinamento e mudança de comportamento: motivação, liderança,
e comunicação (ABRANTES, 2001).
No final da década de 1980, surgiu o programa de Gestão da
Qualidade, na Motorola, chamado Seis Sigma que será detalhado
e estudado ainda neste artigo.

CMMI
Esta seção tem por objetivo introduzir o conceito de CMMI,
Figura 4. Modelo de excelência do PNQ (Fonte: (FNQ, 2009)). expondo como o modelo surgiu, quais são seus propósitos,

Figura 5. Subdivisões dos Critérios de Excelência PNQ (Fonte: (FNQ, 2009))

Edição 21 - Engenharia de Software Magazine 11

estrutura, componentes e abordagens, de modo a fornecer um
contexto claro para os níveis de maturidade 4 e 5 que serão
mapeados neste artigo.
Figura 6. Programa 8S (Fonte: (ROCHA, 2009))
Histórico do modelo
Em 1991, o Software Engineering Institute (SEI), da Univer-
sidade Carnegie Mellon (EUA), criou o SW-CMM (Capability
Maturity Model para Software) a partir de uma encomenda
feita pelo Departamento de Defesa dos Estados Unidos.
Esse modelo foi criado focando o processo de engenharia de
software na proposta de melhoria contínua, trazendo discipli-
na e controle no desenvolvimento e manutenção do software
(BARTIÉ, 2002). Desta forma, passou a servir como uma das
principais referências de modelo de qualidade para o mercado
de empresas de software.
Com o passar do tempo, observou-se que variações aplicáveis
a outras disciplinas, tais como engenharia de sistemas, aquisi-
ção de software, gestão e desenvolvimento de mão-de-obra e
desenvolvimento integrado de produtos e processos, surgiram
de acordo com as diferentes necessidades das organizações.
Como cada um destes modelos possuía a sua própria arqui-
tetura e abordagem de implementação, a sua utilização por
organizações que possuíam processos integrados envolvendo
várias destas disciplinas tornou-se difícil devido aos altos
custos de treinamento, avaliação e ações de melhoria.
Diante deste cenário, o CMMI (Capability Maturity Model
Integration) foi criado pelo SEI em 2002 como um modelo evo-
lutivo em relação aos vários CMMs, com o objetivo de combinar
as suas várias disciplinas em uma estrutura única, flexível e
componentizada (Figura 7), que pudesse ser utilizada de forma
integrada por organizações que demandavam processos de
melhoria em âmbito corporativo (FERNANDES, 2008).
A versão 1.2 do CMMI foi publicada pelo SEI em agosto de
2006, trazendo um conjunto de melhorias e simplificações em
relação à versão anterior. Com o documento CMMI for Deve-
lopment (CMMI para Desenvolvimento), houve a unificação
do tratamento das disciplinas de engenharia de software, en-
genharia de sistemas, desenvolvimento integrado de produto
12 Engenharia de Software Magazine - Seis Sigma e CMMI
e processo e terceirização, além do conceito de “constelações”
na arquitetura do modelo, que permite a sua expansão para
outros focos, tais como aquisições e entrega de serviços.
Figura 7. CMMI - Integração dos Modelos CMM
Definição e objetivos do modelo
O CMMI (Capability Maturity Model Integration) é um mo-
delo de maturidade de melhoria de processos para desenvol-
vimento de produtos e serviços. (CMMI, 2006). Seu principal
propósito é fornecer diretrizes baseadas nas melhores práticas
voltadas para atividades de desenvolvimento e manutenção,
abrangendo todo o ciclo de vida do produto, desde a concepção,
desenvolvimento, aquisição até a entrega e manutenção. As
abordagens do CMMI envolvem a avaliação da maturidade
da organização ou a capacitação das suas áreas de processo,
o estabelecimento de prioridades e a implementação de ações
de melhorias (FERNANDES, 2008).
Estrutura do modelo
Visão Geral
O modelo possui duas abordagens: contínua e por estágios,
permitindo à organização optar pela mais adequada a seu
contexto. Atendendo a requisitos de “componentização”,
a versão 1.2 do CMMI apresenta tais abordagens reuni-
das em um mesmo documento, dentro do escopo de cada
constelação.
Uma constelação é uma coleção de componentes do CMMI
que compreende um modelo, seus materiais de treinamento
e documentos relacionados à avaliação para uma área de in-
teresse. “Adições” podem ser usadas para expandir constela-
ções com conteúdos específicos adicionais. Atualmente, três
constelações são suportadas pela versão 1.2 do CMMI:
• CMMI for Development (CMMI-DEV) – fornece diretivas
para monitoração, medição e gerenciamento de processos de
desenvolvimento. Pode ser estendido através da adição para o
Desenvolvimento Integrado de Produto e Processo (IPPD);
• CMMI for Services (CMMI-SVC) – fornece diretivas para
entrega de serviços dentro das organizações e para clientes
externos;
• CMMI for Acquisition (CMMI-ACQ) – fornece diretivas
para suporte às decisões relacionadas à aquisição de produtos
e serviços.

Componentes do Modelo
Os componentes do modelo se agrupam em três categorias
que indicam como interpretá-los:
• Componentes requeridos: descreve o que uma organização
deve realizar para satisfazer uma área de processo. Devem
ser visivelmente implementados nos processos de uma orga-
nização. Os componentes requeridos no CMMI são as metas
específicas e as metas genéricas. A satisfação das metas é
utilizada em avaliações como base para determinar se uma
área de processo foi realizada e satisfeita;
• Componentes esperados: descreve o que uma organização
pode implementar para realizar um componente requerido.
Orientam os que implementam melhorias ou executam ava-
liações. Incluem as práticas específicas e as práticas genéricas.
Antes que os objetivos possam ser considerados satisfeitos, as
práticas tal como descritas ou práticas aceitáveis alternativas
a elas, deverão estar presentes nos processos planejados e
implementados da organização;
• Componentes informativos: proporciona detalhes que aju-
dam as organizações a começar a pensar em como se aproximar
dos componentes requeridos e esperados. As sub-práticas, os
produtos de trabalho típicos, ampliações, a elaboração das
práticas genéricas, os títulos de metas e práticas, as anotações
de metas e práticas, e as referências são exemplos de compo-
nentes informativos do modelo.
A Figura 8 representa esquematicamente os componentes
e seus relacionamentos. A descrição de cada componente é
feita em seguida.
Figura 8. Componentes da Estrutura do CMMI (Fonte: Adaptação
(CMMI, 2006))
• Áreas de Processo: é um grupo de práticas relacionadas que,
quando implementadas coletivamente, satisfazem um grupo de
objetivos considerados importantes para uma determinada área.
Subcomponentes informativos:
- Objetivo: descreve a finalidade da área de processo;
- Notas introdutórias: descreve os principais conceitos com-
preendidos pela área de processo;
M etodologias Ágeis
- Áreas de Processo Relacionadas: lista referências a áreas de
processo relacionadas e reflete as relações de alto nível entre
as áreas de processo.
• Metas Específicas: são metas relacionadas a uma deter-
minada área de processo, que descrevem o que deve ser
realizado para assegurar que esta esteja definitivamente
implementada;
• Metas Genéricas: se denominam “genéricas” porque a mes-
ma declaração da meta se aplica a múltiplas áreas de processo.
Descreve as características que devem estar presentes para
institucionalizar os processos que implementam uma área
de processo;
• Práticas Específicas: descreve as atividades consideradas
importantes para alcançar uma meta específica associada.
Subcomponentes informativos:
- Produtos de Trabalho Típicos: lista exemplos de resultados
de uma prática específica.
- Subpráticas: descrições detalhadas que proporcionam uma
orientação para interpretar e implantar uma prática específica
ou genérica.
• Práticas Genéricas: se denominam “genéricas” porque a
mesma prática se aplica a múltiplas áreas de processo. Descreve
as atividades consideradas importantes para alcançar uma
meta genérica associada.
Subcomponentes informativos:
- Elaboração de Práticas Genéricas: proporciona um guia
sobre como a prática genérica deveria aplicar-se de forma
exclusiva à área de processo.
• Componentes Informativos de Suporte: informação adicio-
nal necessária para descrever um conceito. São eles:
- Notas: pode proporcionar detalhes, fundamentação teórica
ou premissas/restrições relacionadas ao componente;
- Exemplos: texto ou lista provendo um ou mais exemplos
para esclarecer um conceito ou atividade descrita;
- Ampliações: nota ou exemplo relevante para uma disciplina
particular. As disciplinas cobertas neste modelo são Engenha-
ria de Hardware, Engenharia de Sistemas e Engenharia de
Software. Cada amplificação é rotulada com um cabeçalho
que indica à qual disciplina se aplica;
- Referências: indicação para informação adicional ou mais
detalhada em áreas de processo relacionadas.
Abordagens de Implementação
Como mencionado anteriormente, o CMMI possui duas abor-
dagens. Para desenvolvimento deste artigo, utilizamos como base
a abordagem de implantação por estágios, devido à sua grande
aderência no mercado e maior proximidade com os demais mo-
delos CMMI que também utilizam níveis de maturidade para
mensurar a qualidade dos processos organizacionais. Dessa
maneira, daremos a esta representação um foco especial.
Objetivamente, podemos descrever as abordagens da se-
guinte maneira:
Edição 21 - Engenharia de Software Magazine 13
• Abordagem contínua: permite que a organização selecione
uma área de processo (ou um grupo de áreas de processo)
e melhore os processos relacionados. Essa representação
utiliza seis níveis de capacidade (numerados de 0 a 5) para
caracterizar melhorias relativas a uma área de processo
individual;
• Abordagem por estágios: utiliza grupos pré-definidos de
áreas de processo (PAs) para definir um caminho de melho-
ria para uma organização. Este caminho é caracterizado por
cinco níveis de maturidade (numerados de 1 a 5). Cada nível
de maturidade contém uma série de áreas de processo que
caracteriza diferentes condutas organizacionais.
Níveis de Maturidade
Para dar suporte àqueles que utilizam a abordagem por es-
tágios, todos os modelos CMMI trazem níveis de maturidade
em seu desenho e conteúdo (Figura 10).
Um nível de maturidade pode ser considerado um degrau
evolucionário para a melhoria do processo organizacional
como um todo e consistem em práticas específicas e genéricas
que integram um conjunto predefinido de áreas de processo. O
cumprimento das metas específicas e genéricas correspondentes
a estas áreas de processo é um pré-requisito para o alcance do
nível de maturidade correspondente (FERNANDES, 2008).

A Figura 9 ilustra a estrutura de ambas as abordagens evi-

denciando suas diferenças: níveis de capacidade x níveis de
maturidade.

Figura 10. Níveis de Maturidade do CMMI (Fonte: Adaptação (CITS, 2009))

A seguir são descritas as principais características de cada nível

de maturidade e as áreas de processo pertencentes aos mesmos.
Como o foco deste trabalho é relacionar as práticas do modelo
de qualidade Seis Sigma com os altos níveis de maturidade do
CMMI, os níveis 4 e 5 serão expostos de forma mais detalhada
nos próximos capítulos.
• Nível 1 – Inicial:
É o nível de maturidade mais baixo. Em geral, as organizações
desse nível têm processos imprevisíveis que são pobremente
controlados e reativos. Nesse nível de maturidade os processos
são normalmente “ad hoc” e caóticos. A organização geralmente
não fornece um ambiente estável.
Áreas de Processo: Não há.
Figura 9. Estruturas das abordagens contínua e por estágios (Fonte:
• Nível 2 – Gerenciado:
Adaptação (CMMI, 2006))
Neste nível, o foco é o gerenciamento básico de projetos da or-
A Tabela 2 faz uma comparação entre os seis níveis de ca- ganização, proporcionando-lhes a garantia de que os requisitos
pacidade e os cinco de maturidade. Como se pode observar, o são gerenciados, planejados, executados, medidos e controlados.
ponto de início é diferente para as duas implementações, visto Quando essas práticas são adequadas, os projetos são executados
que não há nível 0 para a abordagem por estágios. e controlados de acordo com o planejado.
Áreas de Processo: Gestão de Requisitos (REQM), Planejamento
Níveis de Capacidade da Abordagem Níveis de Maturidade da do Projeto (PP), Controle e Monitoração do Projeto (PMC), Gestão
Nível
Contínua Abordagem por Estágios do Acordo com o Fornecedor (SAM), Medição e Análise (MA),
Nível 0 Incompleto --- Garantia da Qualidade de Processo e do Produto (PPQA) e Gestão
Nível 1 Executado Inicial da Configuração (CM).
• Nível 3 – Definido:
Nível 2 Gerenciado Gerenciado
Neste nível, processos são bem caracterizados, compreendidos e
Nível 3 Definido Definido
descritos em padrões, procedimentos, ferramentas e métodos. O
Nível 4 Gerenciado Quantitativamente Gerenciado Quantitativamente conjunto de processos padrão da organização, que é a base para
Nível 5 Otimizado Otimizado o nível 3 de maturidade, é estabelecido e melhorado ao longo do
Tabela 2. Comparação dos níveis de capacidade e maturidade (Fonte: tempo. Esses processos padronizados são usados para estabelecer
Adaptação (CMMI, 2006)) consistência em toda a organização. Todos os projetos utilizam 

14 Engenharia de Software Magazine - Seis Sigma e CMMI

 M etodologias Ágeis

uma versão de um desses processos padrão adaptando-a às suas

características especificas.
Áreas de Processo: Desenvolvimento de Requisitos (RD), Solução
Técnica (TS), Integração do Produto (PI), Verificação (VER), Vali-
dação (VAL), Foco no Processo Organizacional (OPF), Definição
do Processo Organizacional (OPD), Treinamento Organizacional
(OT), Gestão Integrada do Projeto (IPM), Gestão de Riscos (RSKM),
Análise de Decisões e Resolução (DAR).

• Nível 4 – Gerenciado Quantitativamente:

A gestão quantitativa baseada em medições e indicadores cobre,
de forma integrada, todo o conjunto de processos organizacionais,
assim como os projetos e respectivos produtos, como instrumento
de suporte para o atendimento dos objetivos de desempenho de
processo e de qualidade. Os projetos e seus produtos assim como
o processo organizacional, são controlados estatisticamente.
Áreas de Processo:
- Desempenho do Processo Organizacional (OPP) – Tem por
objetivos: estabelecer e manter uma visão quantitativa do de-
sempenho dos processos padrões, e prover modelos e baselines
de desempenho, visando melhorar a gestão dos projetos através
de métricas de processo e produto.
- Gestão Quantitativa do Projeto (QPM) – Tem por objetivo geren-
ciar quantitativamente (através de métricas) o processo definido
do projeto, visando o alcance dos objetivos preestabelecidos de
desempenho de qualidade e processo.
• Nível 5 – Otimizado:
Neste nível, os processos são continuamente aperfeiçoados com
base em um entendimento quantitativo no qual a variação de um
processo existe devido às interações, normais e presumidas, entre
seus componentes. Esse nível de maturidade tem como objetivo
a melhoria contínua do processo.
Áreas de Processo:
- Inovação e Desenvolvimento Organizacional (OID) – Tem por
objetivo selecionar e implantar melhorias incrementais e inova-
ções nos processos e nas tecnologias que promovam, quantitati-
vamente, o aumento da habilidade da organização para cumprir
os seus objetivos de desempenho de processos e qualidade.
- Análise e Resolução de Causas (CAR) – Tem por objetivo
identificar causas de defeitos e outros problemas e tomar ações
corretivas para prevenir a sua ocorrência futura.
A Figura 11 representa de forma resumida, os níveis de maturi-
dade, seus principais focos e áreas de processo envolvidas.
Figura 11. Os Níveis de Maturidade e suas Áreas de Processo
Benefícios do Modelo
A utilização do modelo CMMI inclui uma série de bene-
fícios significativos e quantificáveis para a organização
que o utiliza na melhoria de seus processos e podem ser
categorizados e resumidos por: custo, prazo, produtivi-
dade, qualidade, satisfação dos clientes e Retorno sobre o
Investimento (ROI – Return on Investment).
Em 2006, o SEI publicou um relatório técnico (Perfor-
mance Results of CMMI - Based Process Improvement)
apresentando dados quantitativos de 35 organizações,
entre elas grandes empresas com mais de uma organiza-
ção constituinte (SEI, 2006). Os esforços no processo de
melhoria dessas organizações incluem tanto pequenas
como grandes unidades organizacionais que atuam em
uma variedade de setores e domínios do mercado. Foram
aplicadas as práticas do modelo CMMI para engenharia
de software, engenharia de sistemas, e outras disciplinas
de engenharia. Enquanto a maioria dos resultados vem
de organizações de maior maturidade, melhorias notáveis
também foram alcançadas pelas organizações de menor
maturidade. Todas as organizações no relatório explici-
tamente atribuem suas realizações a orientação fornecida
pelo CMMI.
A Tabela 3 resume a média percentual de melhorias nas
cinco categorias apresentadas.

Categoria Percentual Médio Exemplos

Custo Redução de 34% Redução dos custos de retrabalho, remoção de defeitos, overhead de projetos.
Prazo Melhoria de 50% Redução do número de dias de atraso de aproximadamente 50 para menos de 10.
Produtividade Aumento de 61% Aumento na quantidade de linhas de código por pessoa/dia, aumento do número de releases de software liberados por ano.
Qualidade Aumento de 48% Redução dos defeitos encontrados e das requisições de mudança no sistema em ambiente de produção.
Satisfação dos Clientes Aumento de 14% Aumento em 55% comparado ao SW-CMM nível 2 e 10% comparado ao nível 5.
Retorno sobre o Investimento 4,0 : 1 Retorno de 5:1 em relação às horas investidas em atividades de qualidade.

Tabela 3. Benefícios Quantitativos da Utilização do CMMI (Fonte: Adaptação (SEI, 2006))

Edição 21 - Engenharia de Software Magazine 15

SEIS SIGMA
Este tópico tem por objetivo introduzir o conceito de Seis
Sigma como modelo de gestão da qualidade, expondo o seu
histórico, propósito, certificações relacionadas e metodologias
criadas a partir de sua concepção. A aplicação na melhoria dos
processos de qualidade de software e a estrutura da metodo-
logia serão detalhadas no tópico seguinte, no qual será feito
o mapeamento entre suas práticas no apoio à implementação
dos níveis de maturidade 4 e 5 do CMMI.
Histórico do Modelo
As origens do Seis Sigma como um padrão de medição vêm
dos trabalhos de Carl Frederick Gauss (1777-1855), que intro-
duziu o conceito da curva normal ou curva de Gauss. As raízes
do Seis Sigma como um padrão de medição da variação dos
produtos podem ser rastreadas até a década de 1920, quando
Walter Shewhart mostrou que a partir de três desvios padrões
ou três “sigmas” da média, o processo requer correção. Muitos
padrões de medição (CPK, Zero Defeitos, etc.) entraram em
cena posteriormente, dando base para o movimento da quali-
dade total, liderado mais tarde por Edward Deming e outros
profissionais militantes da qualidade (ISIXSIGMA, 2009a).
No início e meados dos anos 80, com o presidente Bob Galvin
na direção, engenheiros da Motorola decidiram que os níveis
tradicionais de qualidade – medição de defeitos em milhares de
oportunidades – não forneciam granularidade suficiente. Esta
conclusão partiu de informações vindas da força de vendas,
a respeito da grande quantidade de reclamações de uso de
garantias pelos clientes. Para reverter este quadro, eles deter-
minaram a necessidade de medir os defeitos por milhões de
oportunidades. Desta forma, a Motorola desenvolveu este novo
padrão, criou a metodologia e, em 1986, o termo “Seis Sigma”
foi cunhado pelo engenheiro da Divisão de Comunicações da
Motorola, Bill Smith (Figura 12).
Figura 12. 1986: Processo de qualidade Seis Sigma (Fonte: Adaptação
(MOTOROLA, 2009))
Em 1987, foi lançado um ambicioso programa por Bob Gal-
vin visando a redução de defeitos nos produtos para “seis
sigma” ou 3,4 defeitos por milhões de oportunidades, tendo
como meta o ano de 1991 e como pilar o modelo Seis Sigma
(FERNANDES, 2008).
O modelo ajudou a Motorola a obter excelentes resultados em
sua organização, documentando mais de 16 bilhões de dólares
16 Engenharia de Software Magazine - Seis Sigma e CMMI
em economias como resultado de seus esforços com o Seis
Sigma. Tais resultados concederam à companhia a conquista
do prestigioso prêmio Malcolm Baldrige National Quality
Award (MBNQA) em 1988.
Em 1991, a Motorola introduziu treinamentos para a formação
de especialistas em Seis Sigma, que foram denominados “black
belts”. Em 1992, a metodologia passou a ser adotada por outras
indústrias, incluindo seguros, serviços financeiros, saúde, etc.
Em 1999, a Motorola, através da Motorola University, começou
a ensinar o Seis Sigma para outras organizações de sua cadeia de
valor (fornecedores e clientes) e também para outras indústrias.
Em 2001, o agora ex-CEO da General Electric (GE), Jack Welch,
dedicou um capítulo inteiro em sua biografia (WELCH, 2001) à
iniciativa Seis Sigma, fazendo elogios que se tornaram ao longo
do tempo a grande bandeira da área de qualidade e melhorias
de processos no mundo. Em suas próprias palavras, “Tornei-me
um fanático pelo Seis Sigma” e “O Seis Sigma tornará a GE a
maior empresa do mundo dos negócios”. De fato, o modelo ge-
rou no ano de 2000 mais de 2,4 bilhões de dólares em benefícios
(Figura 13), enquanto no mesmo período a GE teve a maior
valorização de suas ações na história (Figura 14).
Figura 13. Benefícios do Seis Sigma na GE (1996-2000) (Fonte: Adaptação
(VASQUES, 2006))
Figura 14. Situação das Ações na GE (1965-2004) (Fonte: (FINANCE, 2009))
Em 2002, a Motorola ganhou novamente o MBNQA e
milhares de empresas ao redor do mundo adotaram o Seis
Sigma como uma maneira de fazer negócios, ou seja, seu foco
se alargou para além da melhoria da qualidade em produ-
tos. Um dos idealizadores deste programa, Michel Harry,

define o Seis Sigma como uma estratégia que não deve
estar encapsulada na área de qualidade, devendo espalhar
seus “tentáculos” por toda a organização, da manufatura e
engenharia à área de serviço.
Em 2004, a Motorola obteve receitas 42% maiores e um lucro
por ação 257% maior do que no primeiro trimestre do ano fiscal
anterior com o uso do Seis Sigma em todos os seus processos
(FERNANDES, 2008).
Definição e Objetivos do Modelo
Diferentemente de outros programas de qualidade, as empresas
que utilizam o Seis Sigma divulgam cifras milionárias de ganhos
obtidos com sua implementação. Desta maneira, podemos con-
cluir que o Seis Sigma é mais do que apenas um sistema de qua-
lidade como o TQM ou ISO. É uma maneira de fazer negócios.
Geoff Tennant descreve em seu livro Six Sigma: SPC and TQM
in Manufacturing and Services (TENNANT, 2001): “Seis Sigma é
muitas coisas e talvez fosse mais fácil listar todas as coisas que
a qualidade Seis Sigma não é. Seis Sigma pode ser visto como:
uma visão; uma filosofia; um símbolo; uma métrica; um objeti-
vo; uma metodologia”. (ISIXSIGMA, 2009a). A estas descrições
pode-se acrescentar ainda: uma estratégia organizacional, um
modelo de gestão, um conjunto de ferramentas estatísticas ou um
método de comparação (benchmarking) – 3,4 defeitos por milhão
de oportunidades.
É comum encontrar diferentes, embora convergentes, definições
sobre o que é Seis Sigma.
Para VASQUES (2006) da ISD Brasil (Integrated System
Diagnostics Brasil), a definição mais completa e íntegra seria:
“Metodologia de grande rigor analítico, baseada em projetos de
melhorias de processos de negócio onde utilizamos um conjunto
preestabelecido de ferramentas (tipicamente estatísticas) que
direciona a organização para uma mudança cultural profunda
(filosofia), buscando sempre altos resultados financeiros e intenso
foco nos clientes”.
Segundo CARVALHO e PALADINI (2005), o modelo de Gestão
da Qualidade Seis Sigma é uma estratégia gerencial disciplinada,
caracterizada por uma abordagem sistêmica e pela utilização
intensiva do pensamento estatístico, que tem por objetivo reduzir
drasticamente a variabilidade dos processos críticos e aumentar a
lucratividade das empresas, por meio da otimização de produtos
e processos, buscando satisfação de clientes e consumidores.
Os objetivos do Seis Sigma variam de acordo com os objetivos
da melhoria, conforme a lista a seguir:
• Redução de custos;
• Melhoria da produtividade;
• Crescimento de fatia de mercado;
• Retenção de clientes;
• Redução de tempo de ciclo;
• Redução de defeitos;
• Mudança cultural para a qualidade;
• Excelência no desenvolvimento de produtos e serviços.
Ao contrário do “Total Quality Management – TQM”, que
pretendia melhorar a qualidade de toda a organização, o Seis
M etodologias Ágeis
Sigma procura melhorias que agreguem valor para o cliente
e também pode ser aplicado para problemas localizados
(FERNANDES, 2008).
Existem algumas estratégias para se alcançar uma produção
com “zero erro”. PANDE, NEUMAN e CAVANAGH (2001)
afirmam que há três estratégias Seis Sigma. As estratégias são:
(i) estratégia de melhoria de processo; (ii) estratégia de projeto/
reprojeto de processo; e, (iii) estratégia de gerenciamento de
processo. A melhoria de processo refere-se à estratégia de
desenvolver soluções com a finalidade de eliminar as causas-
raiz dos problemas de desempenho de uma empresa, sem,
no entanto, interferir na estrutura básica do processo. Na es-
tratégia projeto/reprojeto de processo, o objetivo é substituir
uma parte ou todo o processo por um novo. Já na estratégia de
gerenciamento de processo, as exigências do cliente são claras
e regularmente atualizadas, os processos são documentados
e gerenciados com medições em todas as suas etapas. Nesta
última estratégia, os gestores também usam as medições e o co-
nhecimento do processo para avaliar os seus desempenhos.
A Figura 15 resume alguns métodos importantes do pro-
grama Seis Sigma.
Figura 15. Métodos e ferramentas essenciais do programa Seis Sigma
(Fonte: Adaptação (PANDE; NEUMAN; CAVANAGH, 2001))
Um programa Seis Sigma tem como requisitos:
• Alinhar o esforço Seis Sigma aos objetivos do negócio;
• Forte patrocínio da administração;
• Focalizar em resultados de curto prazo;
• I mpla nt a r u ma nova for ma de ad m i n i st ração
duradoura;
• Tornar a aprendizagem uma tarefa contínua;
• Selecionar os projetos corretos;
• Ênfase em treinamento e capacitação de recursos
humanos;
• Definir claramente papéis e responsabilidades;
• Forte liderança para a mudança.
O programa Seis Sigma foi batizado com o nome da letra
grega sigma (σ), que representa o desvio-padrão em notação
estatística, já evidenciando a grande ênfase na utilização
destas ferramentas. O uso sistemático de ferramentas
Edição 21 - Engenharia de Software Magazine 17
estatísticas nos projetos tem como objetivo reduzir a varia-
bilidade, até a obtenção da difícil meta de 3,4 defeitos por
milhão (CARVALHO; PALADINI, 2005) ou “seis sigma”,
que equivale a um rendimento de 99,9997% de resultados
do processo isentos de defeitos. A Tabela 4 mostra o que
significa o Seis Sigma em termos de qualidade e defeitos
por milhão.
Sigma Qualidade Defeitos por milhão
6σ 99,9997% 3,4
5σ 99,9767% 233
4σ 99,379% 6.210
3σ 93,32% 66.807
2σ 69,1% 308.537
1σ 31% 690.000
Tabela 4. Qualidade e defeitos sigma (Fonte: Adaptação (FERNANDES, 2008))
Certificações e Responsabilidades
Existem certificações profissionais para qualificar pessoas
como especialistas em Seis Sigma, relativas a “Black Belt”,
“Green Belt” e outras. Ambas são fornecidas pela Motorola
University, por diversas empresas especializadas e pela ASQ
(American Society for Quality). A ASQ é dedicada a assuntos
relacionados à qualidade e a mais indicada para realizar as
certificações (FERNANDES, 2008).
Os especialistas são responsáveis pela implantação da estra-
tégia Seis Sigma. Sua formação é altamente focada em buscar
soluções para a verdadeira causa dos problemas. Eles atuam
como agentes de mudança na organização, aplicando e disse-
minando o uso das ferramentas estatísticas e da qualidade no
aprimoramento dos projetos.
Para realizar o treinamento, é essencial selecionar pessoas
adequadas, definir claramente as expectativas de como este
treinamento deve ser aplicado no local de trabalho e assegu-
rar que seja fornecido o suporte necessário para obter bons
resultados.
Existem duas certificações Seis Sigma da ASQ (ASQ, 2009a):
A Six Sigma Green Belt Certification (SSGB) e a Six Sigma Black
Belt Certification (SSBB). Seus criadores atribuíram tais títulos
(“faixa verde”, “faixa preta”), pois acreditam que as certifica-
ções têm habilidades em comum com as artes marciais.
Six Sigma Green Belt Certification – SSGB
Papel na empresa
Esse profissional auxilia na coleta e análise de projetos de
Black Belt. Lidera a resolução de problemas em projetos de
Green Belt e outras equipes, de acordo com sua experiência.
Requisitos de experiência
Três anos de experiência de trabalho em uma ou mais áreas
do Seis Sigma Green Belt. Esta certificação não é um requisito
para a Certificação Seis Sigma Black Belt.
Expectativas e atribuições mínimas para um SSGB
18 Engenharia de Software Magazine - Seis Sigma e CMMI
• Operar em apoio ou sob a supervisão de um Six Sigma Black
Belt.
• Analisar e resolver problemas de qualidade.
• Envolvimento em projetos de melhoria da qualidade.
• Participação em um projeto, mas não conduzí-lo sozinho.
• Ter pelo menos três anos de experiência de trabalho.
• Ter capacidade de demonstrar seu conhecimento das ferra-
mentas do Seis Sigma e dos processos. (ASQ, 2009c)
Exame
Os candidatos à certificação precisam passar por um exame
escrito que consiste em perguntas de múltipla escolha para medir
a compreensão Six Sigma Green Belt Body of Knowledge (Corpo
de Conhecimentos do Seis Sigma Green Belt). A prova dura quatro
horas, tem 100 questões e é feita no idioma inglês, caso seja feita
pela ASQ. Cada participante deve levar seu próprio material de
referência, pois o exame é “open-book” (com consulta).
O comitê que prepara o exame utiliza o Six Sigma Green Belt
Body of Knowledge como orientação para escrever as pergun-
tas do teste. Este foi feito para ajudar a preparar os candidatos
a identificar o conteúdo específico dentro de cada tema que
pode ser cobrado.
Os exames são realizados duas vezes por ano, em junho e
dezembro, pela ASQ e organizações internacionais.
Six Sigma Black Belt Certification – SSBB
Papel na empresa
O profissional que possui a certificação Six Sigma Black Belt,
está habilitado a explicar a filosofia e os princípios do Seis
Sigma, incluindo sistemas de apoio e ferramentas. O Black
Belt tem que demonstrar liderança, entender a dinâmica da
equipe, saber resolver problemas em projetos, atribuir funções
e responsabilidades aos membros e também preparar equipes
de projeto. Também possui um profundo conhecimento dos
aspectos do modelo DMAIC de acordo com os princípios do
Seis Sigma.
Requisitos de experiência
Para a certificação é preciso ter realizado dois projetos completos
e certificados/aprovados, ou ter finalizado um projeto certificado/
aprovado e mais três anos de experiência em uma ou mais áreas
do Seis Sigma Black Belt Body of Knowledge. A certificação Seis
Sigma Green Belt não é requisito para este exame.
Expectativas e atribuições mínimas para um SSBB
Segundo recomendação da American Society for Quality
(ASQ, 2009b), podemos citar:
• Será capaz de explicar a filosofia e os princípios do Seis Sig-
ma, incluindo sistemas e ferramentas (qualidade, processos /
melhoria contínua, etc.), e poderá descrever seu impacto nos
diversos processos de negócios em toda a organização;
• Conhecer várias guias e saber sobre funções e responsabili-
dades no Seis Sigma. Ao reconhecer obstáculos na organização,
deverá ser capaz de utilizar técnicas de gestão de mudança
para gerir a mudança organizacional;
 M etodologias Ágeis

• Será capaz de definir benchmarking, entender sobre várias Exame

medidas financeiras e outras de desempenho de negócios.
Será capaz de identificar as necessidades dos clientes e
descrever o impacto que os projetos Seis Sigma podem ter
sobre os diversos tipos de clientes;
• Terá uma compreensão fundamental dos componentes e
técnicas utilizados na gestão de equipes, incluindo o tempo
de gestão, planejamento e ferramentas de tomada de decisão,
formação de equipe e avaliação de desempenho e gratifica-
ção. Saberá como usar as técnicas adequadas para superar
os diferentes desafios da dinâmica de grupo;
• Entenderá os elementos de um relatório do projeto (defi-
nição do problema, escopo, metas, etc.) e será capaz de usar
vários instrumentos para acompanhar seu andamento;
• Será capaz de usar o feedback do cliente para determinar
suas necessidades;
• Terá um conhecimento básico sobre técnicas de coleta
de dados, elementos do processo e suas ferramentas de
análise;
• Terá u m con hec i mento bá sico s obre si stema s de
medição;
• Terá um conhecimento básico de conceitos de probabili-
dade e distribuições;
• Será capaz de realizar cálculos estatísticos e de capacidade
do processo;
• Será capaz de realizar testes de hipóteses e analisar seus
resultados;
• Será capaz de utilizar várias ferramentas para eliminar o
desperdício e reduzir o tempo de ciclo;
• Terá uma compreensão fundamental de como implemen-
tar um processo de melhoria e como analisar e interpretar
estudos de risco;
• Será capaz de criar planos de controle e usar ferramentas
para manter e sustentar melhorias.
Os candidatos à certificação precisam passar por um exame
escrito que consiste em perguntas de múltipla escolha para
medir a compreensão Six Sigma Black Belt Body of Knowledge
(Corpo de Conhecimentos do Seis Sigma Black Belt). A prova
dura quatro horas, tem 150 questões e é feita, pela ASQ, no
idioma inglês. Assim como no exame para Green Belt, cada
participante deve levar seu próprio material de referência,
pois o exame é “open-book” (com consulta).
Os exames são realizados duas vezes por ano, em março e
outubro, pela ASQ e organizações internacionais.
Resumo dos papéis da equipe
A Tabela 5 mostra a descrição resumida dos papéis compo-
nentes de uma equipe Seis Sigma.
Metodologias do 6 Sigma
Esta seção apresenta as principais metodologias existentes
no Seis Sigma, abordando suas definições, conceitos e aplica-
bilidade. As metodologias DMAIC e DFSS são utilizadas na
eliminação dos defeitos de um processo ou produto.
O modelo DMAIC
O DMAIC foca na robustez e simplificação dos processos,
visando diminuir o nível de defeitos, o aumento da satisfação
dos clientes e a lucratividade da organização. O DMAIC é
um aperfeiçoamento do processo Seis Sigma que passa por
cinco fases: definir (define), medição (measure), análise (analyze),
aperfeiçoamento (improve) e controle (control). Existem diversas
ferramentas que são utilizadas de maneira integrada às fases
do DMAIC, constituindo um método sistemático, disciplinado,
baseado em dados e no uso de ferramentas estatísticas para se
atingir os resultados almejados pela organização (CARVALHO;
PALADINI, 2005).

Papel exercido no Seis Sigma Pessoa

É o principal executivo da empresa. Responsável pela implantação do Seis Sigma. Essa pessoa deve ter total comprometimento, pois ele é indispensável
Executivo Líder para o sucesso da implantação da estratégia de melhoria. Deve conduzir, incentivar e supervisionar as iniciativas do programa Seis Sigma em toda
a empresa.
Deve liderar os executivos-chave da organização rumo ao programa Seis Sigma. É responsável por organizar e guiar o começo, o desdobramento e a
Champions
implementação do Seis Sigma em toda a organização.
Ajuda o campeão na tarefa de implantar o Seis Sigma na organização. Também ajuda o campeão na escolha e no treinamento de novos projetos de
Master Black Belts melhoria, oferecendo liderança técnica no preparo dos profissionais de Seis Sigma, treinando e instruindo os Black Belts e os Green Belts. Dedicam
100% do tempo às atividades relacionadas ao programa Seis Sigma.
Os Black Belts dedicam 100% do tempo aos projetos Seis Sigma, assim como os Master Black Belts, recebendo treinamento intensivo em técnicas
Black Belts
estatísticas e de solução de problemas. Lideram equipes na condução dos projetos e são capazes de treinar até 100 Green Belts ao ano.
Ficam parcialmente envolvidos com as atividades Seis Sigma. Esses profissionais possuem duas tarefas principais:
Green Belts 1. Auxiliar aos Black Belts na coleta de dados e no desenvolvimento de experimentos;
2. Liderar pequenos projetos de melhoria nas suas respectivas áreas de atuação.
Participam como membros das equipes de projeto supervisionando a utilização das ferramentas Seis Sigma na rotina da empresa e executam
Yellow Belts
projetos mais focados e de desenvolvimento mais rápido que os executados pelos Green Belts.
Não faz parte de uma equipe de projeto. São do nível operacional. Dão suporte aos Black Belts, Green Belts e Yellow Belts na implementação dos
White Belts
projetos. São executores de ações, garantindo que os resultados alcançados sejam mantidos no longo prazo, na operação da rotina da empresa.
Tabela 5. Papéis da equipe Seis Sigma (Fonte: Adaptação (GRUPO WERKEMA, 2008))

Edição 21 - Engenharia de Software Magazine 19

Primeira fase: Define (definir as prioridades)
A primeira fase consiste em definir quais são os requisitos
do cliente (voz do cliente) e traduzir essas necessidades em
Características Críticas para a Qualidade (CTQ – Critical to
Quality). Esta etapa torna-se fundamental por levar a visão do
cliente para dentro da empresa. Os objetivos dos projetos Seis
Sigma de melhoria têm de estar relacionados a um CTQ.
Os desenhos dos processos críticos são feitos por uma equipe
preparada para aplicar as ferramentas Seis Sigma e procuram
identificar aqueles que têm relação com os CTQs do cliente
e que estão gerando resultados ruins, como reclamações de
clientes, problemas funcionais, problemas trabalhistas, baixa
qualidade de suprimentos, altos custos de mão-de-obra, erros
de forma, ajuste e funcionamento etc. Logo após, a equipe
realiza uma análise custo-benefício do projeto, de modo a
ter uma visão clara do retorno que a atividade deverá trazer
para a empresa.
Segunda fase: Measure (como o processo é medido e como
é executado?)
Na segunda fase a equipe assessorada pela Black Belt vai
agora desenhar o processo e os subprocessos que se relacionam
com as CTQs, definindo as entradas e saídas.
Para cada processo, deve-se utilizar o sistema de medição
adequado. Em seguida, a equipe coleta os dados do processo
por meio de um sistema que produza amostras representativas
e aleatórias. Com isso, os índices de capacidade do processo a
curto e longo prazos são determinados.
Terceira fase: Analyze (identificação das principais causas)
A equipe Seis Sigma, na terceira fase, faz a análise dos dados
coletados, que é uma importante função da metodologia. Para
esse trabalho, além de utilizar as ferramentas tradicionais da
qualidade, são utilizadas ferramentas estatísticas de modo a
identificar as causas óbvias e as causas não óbvias. A utiliza-
ção de ferramentas estatísticas de forma competente e prática
é uma das forças da metodologia. A estatística passa a ser
a principal ferramenta a ser utilizada pela equipe, quando
evoluímos para uma visão de que os processos devem ser a
principal ferramenta a ser utilizada pela equipe.
Nesta fase, é imprescindível a utilização de software esta-
tístico, que facilita muito o trabalho da equipe nos cálculos e
desenha os gráficos necessários. A equipe consegue descobrir
as causas geradoras dos defeitos e as fontes de variações nos
processos.
Quarta fase: Improve (eliminação das causas dos defeitos)
Na fase de aperfeiçoamento, a equipe deve fazer as melho-
rias no processo existente. Os dados estatísticos devem ser
transformados em dados do processo, e a equipe deve estudar
tecnicamente quais transformações deve executar. A equipe
pode vir a ter que resolver problemas, pois podem ocorrer
modificações técnicas do processo. O trabalho da equipe será
modificar os elementos das atividades de transformação,
atuando sobre as causas-raiz.
20 Engenharia de Software Magazine - Seis Sigma e CMMI
Essa é considerada uma fase crítica, onde as melhorias se
materializam no processo, quando a equipe interage com as
pessoas que executam as atividades.
As equipes promovem melhorias nas variáveis vitais do
processo e realizam a quantificação dos efeitos nas CTQs, ou
seja, nas metas financeiras e de desempenho (CARVALHO;
PALADINI, 2005). Depois, deve testar as soluções, pois a equipe
começa a passar para o pessoal operacional a responsabilidade
de executar o processo modificado.
Quinta fase: Control (manutenção das melhorias)
Nesta fase, pode surgir a seguinte pergunta: por que ir além
da fase de melhoria, já que os objetivos do projeto foram
atingidos?
Qualquer sistema, mesmo que esteja em ordem, pode vir a
ter algum tipo de desordem, ou seja, o processo pode ficar
mais bagunçado no futuro, caso não esteja sob controle, e
isso pode fazer a capacidade voltar para os níveis do início
do projeto Seis Sigma.
A equipe deve definir como serão feitos esses controles e
passar essa informação para aqueles que trabalham no pro-
cesso normalmente no dia-a-dia. Também nesta fase, para
medir continuamente o processo de modo a garantir que a
capacidade do processo seja mantida, deve ser estabelecido
e validado um sistema de medição e controle.
O monitoramento dos pontos (Xs) críticos é fundamental
não só para manter a capacidade do processo estabelecida,
mas para indicar melhorias futuras. O outro ponto (Y), que
é a saída do processo, deve ser controlado para garantir que
os resultados sejam conforme o planejado.
É elaborada a documentação do processo por meio de méto-
dos estatísticos de controle de processo, além do monitoramen-
to das novas condições do processo. A capacidade do processo
é reavaliada para garantir que os ganhos sejam mantidos. A
reavaliação pode mostrar no resultado, que pode ser necessário
rever uma ou mais fases precedentes do processo.
A implementação correta do programa Seis Sigma permite
criar uma linguagem comum entre as diversas áreas de uma
empresa (Figura 16), compartilhando sucessos e fracassos,
fazendo com que uma unidade aprenda com a experiência
de outra (CARVALHO; PALADINI, 2005).
O modelo DFSS (Design For Six Sigma)
A metodologia lida com a qualidade no projeto de novos pro-
dutos e pode ser aplicada a processos produtivos e de serviços
que precisam ser constituídos de forma que, ao estarem em
funcionamento, já atinjam o nível Seis Sigma e também surgiu
para preencher uma lacuna no DMAIC.
O DFSS também pode ser aplicado a processo nos quais seu
nível de desempenho esteja tão baixo, e o próprio processo
esteja tão ruim, que quaisquer esforços aplicados para se re-
alizar um projeto DMAIC não resultarão em um processo de
nível Seis Sigma. Ou seja, pode-se projetar um novo produto
ou serviço, ou reprojetar um produto ou serviço já existente
(CARVALHO; PALADINI, 2005).

Figura 16. Descrição dos passos do modelo DMAIC (Fonte: Adaptação (SMIDT & PARTNERS, 2005; PDP net, 2008))
Nesta metodologia existem ferramentas que podem reduzir
custos e melhorar a qualidade, mas principalmente adicionar
valor ao produto por meio de inovações e do atendimento das
reais necessidades dos clientes. Como a qualidade do produto/
processo é projetada, e não melhorada, o DFSS é o programa
apontado como a única forma de atingir o nível Seis Sigma
na qualidade. Para isso, é adotada a metodologia DMADV
(definição, medição, análise, projeto e verificação) que também
possui cinco fases bem definidas:
• Definir (Define): identifica-se o que será projetado e os
objetivos a serem alcançados;
• Medir (Measure): entendimento das necessidades e expec-
tativas dos clientes relativas ao produto ou serviço que está
sendo criado. São definidas as características críticas para a
qualidade (CTQ) do projeto, que serão os objetivos do novo
processo;
• Analisar (Analyze): escolher a melhor solução entre as possí-
veis alternativas de desenho, visando atender as necessidades
dos clientes;
• Projeto (Design): será desenvolvido o design de alto nível
(descrição do conceito de produto/serviço escolhido, mapas
do processo e arranjo das instalações) para todos os elementos
apropriados, como: produto/serviço, processo, informação,
instalações, equipamentos, e materiais/suprimentos;
• Verificação (Verify): testar e validar o projeto. A equipe irá
monitorar o desempenho das CTQs do produto ou serviço por
meio das cartas de controle. (CARVALHO; PALADINI, 2005)
Aplicabilidade do Modelo
O modelo pode ser aplicado para projetos de melhoria de
processos, gerenciamento do processo e para projetos de
novos processos.
Na área de segurança da informação, há um campo vasto para
identificar melhorias nos processos de segurança, assim como
M etodologias Ágeis
nos processos de infraestrutura, em especial gerenciamento
de incidentes, gerenciamento de problemas, gerenciamento da
disponibilidade e central de serviços.
O Seis Sigma também pode ser utilizado em questões de
apoio ao CIO, como no caso de elaboração de orçamento,
controle de custos, etc.
Na área de TI, pode ser aplicado em processos de desenvolvi-
mento de software, principalmente em fábricas de programas e
manutenção de sistemas, onde há maior quantidade de projetos
e um maior índice de repetição dos mesmos.
Mapeamento entre Seis Sigma e CMMI Níveis 4 e 5
Este tópico tem o objetivo de apresentar a aplicação do Seis
Sigma na melhoria dos processos de qualidade de software,
através do mapeamento de suas atividades com as práticas
definidas nos níveis de maturidade 4 e 5 do CMMI.
Qualidade de Software
Há algumas décadas, no desenvolvimento de software, nave-
gar pelo código e corrigir problemas era uma prática comum
entre os desenvolvedores. Assim eram feitos os testes para
verificação de erros e a busca pela qualidade. Foi através dos
testes que as organizações começaram a prestar mais atenção
na importância da qualidade do software. Apesar disso, no
final da década de 1950, o teste ainda era encarado como
uma atividade que ocorreria somente no final do processo de
desenvolvimento.
Nas décadas seguintes (1960 e 1970), a Engenharia de Softwa-
re passou a ser adotada pelas universidades e organizações.
Isso ajudou o processo de desenvolvimento de software a ter
uma abordagem mais profunda. Glenford J. Myers, em 1979,
produziu um dos primeiros trabalhos sobre um processo de
teste, no qual afirmou que realizar testes com o objetivo de
provar a boa funcionalidade de um projeto é errôneo, pois toda
Edição 21 - Engenharia de Software Magazine 21
energia gasta para comprovar esse fato é em vão devido aos
poucos defeitos encontrados. Desta maneira, ele definiu o teste
como um “processo de trabalho com a intenção de encontrar
erros”. Com esta definição, um maior número de problemas
será encontrado, uma vez que os profissionais de qualidade
buscarão vários cenários para avaliar o comportamento do
software.
O conceito de qualidade de software surgiu no início da
década de 1980, onde cada fase do processo passava por uma
verificação feita por desenvolvedores e testadores, para garan-
tir que a fase estava completa. Algumas organizações foram
formadas com o intuito de padronizar a qualidade, entre elas:
IEEE (Institute of Eletrical and Electronics Engineers), ANSI
(American National Standards Institute), ISO (International
Organization for Standardization), CMM (Capability Maturity
Model). O modelo avaliação CMM, foi o que mais se destacou
e ganhou maior dimensão e importância para as organizações
de software.
Atualmente, as organizações estão buscando maior eficiência
para conseguir superar a concorrência e estão buscando as
soluções através da tecnologia, que torna os sistemas informati-
zados, reduzindo custos e ampliando a forma de atuação. Para
acompanhar esse crescimento, os ambientes estão tornando-se
mais complexos e fica mais difícil alcançar um elevado nível
de qualidade. Implantar um processo de garantia de qualidade
tornou-se essencial e uma boa estratégia para o mercado.
O produto final é o somatório de todas as decisões e rea-
lizações geradas durante o ciclo de desenvolvimento. Essas
decisões podem afetar a sua qualidade final. Para alcançar
uma alta qualidade, é necessário investir em qualidade em
todos os pontos do processo. Segundo Bartié (2002), Qualida-
de de Software é um processo sistemático que focaliza todas
as etapas e artefatos produzidos com o objetivo de garantir a
conformidade de processos e produtos, prevenindo e elimi-
nando defeitos.
Gerentes, diretores e acionistas podem tomar decisões
equivocadas, por terem como base informações com erros.
Os prejuízos podem tornar-se enormes às organizações. A
qualidade das informações depende da qualidade das deci-
sões. Com processos de desenvolvimento frágeis e deficientes
é impossível garantir a qualidade do software. Portanto, é
importante verificar duas dimensões fundamentais para
atingirmos a qualidade do software: a dimensão da qualidade
do produto, onde o objetivo principal é garantir a qualidade
do produto tecnológico gerado durante o ciclo de desenvolvi-
mento, através de atividades testes e correção de problemas;
e a dimensão da qualidade do processo, onde é feita a estru-
turação de processos que possuam mecanismos de inibição e
impedimento de falhas.
Relações entre CMMI e SEIS SIGMA
Do ponto de vista de definição do processo, há uma siner-
gia natural entre as áreas de alta maturidade do processo do
CMMI e os princípios do framework DMAIC do Seis Sigma.
Desta forma, as táticas do Seis Sigma podem ser utilizadas
22 Engenharia de Software Magazine - Seis Sigma e CMMI
para enriquecer diretamente os processos definidos que abor-
dam as áreas de processo de alta maturidade. Por exemplo, os
processos relacionados com a Gestão Quantitativa de Projeto
e Análise de Causa e Solução de Problemas refletem tanto as
práticas específicas destas áreas de processo quanto as etapas,
sub-etapas e ferramentas do DMAIC. (SEI, 2005)
Existem várias definições sobre as etapas de cada fase
do DMAIC. A Figura 17 apresenta um roteiro resumido
sobre os passos executados no DMAIC, oferecido no curso
“Measuring for Performance-Driven Improvement do
SEI (SEI, 2005).
Figura 17. DMAIC Roadmap (Fonte: Adaptação (SEI, 2005))
A Tabela 6 apresenta os passos de forma mais detalhada
dentro roteiro de atividades (roadmap) do DMAIC.
A aplicação bem sucedida do CMMI em conjunto com o Seis
Sigma exige uma análise das relações entre os dois.
O CMMI é usado para criar uma infraestrutura de processos
organizacionais, abordando domínios específicos, tais como
software e engenharia de sistemas. Seis Sigma é uma iniciativa
top-down que abrange toda a empresa, incluindo áreas como
engenharia, vendas, marketing e pesquisa. O Seis Sigma foi
concebido para ser implementado com um foco em problemas
e oportunidades, muitas vezes com escopos específicos, que
trarão benefícios significativos nos negócios. Centra-se no
desempenho dos processos e práticas implementadas. Embo-
ra estas duas iniciativas de melhoria sejam diferentes na sua
concepção, elas são interdependentes em seu uso. Na prática,
a alternância entre os focos é muitas vezes eficaz. Por exemplo,
o Seis Sigma pode ser usado para descobrir que os processos
precisam ser mais repetitivos, enquanto o CMMI pode ser
usado para instituir processos baseados nas melhores práticas
da comunidade, e, em seguida, o Seis Sigma pode ser usado
para otimizar os processos (SEI, 2005).
Normalmente, é criado um mapeamento quando se compara
uma outra iniciativa de melhoria com CMMI. Neste caso, de-
vido ao fato do CMMI e Seis Sigma serem dois tipos diferentes
de iniciativas, com muitas conexões e sobreposições diferentes,

um mapeamento completo e generalizado é complexo e ofe-
rece pouco valor prático. É mais útil compreender seus focos
complementares e as formas pelas quais eles estão conectados.
Unir esse entendimento a uma estratégia consciente, permite
que uma organização possa criar planos táticos e mapeamentos
específicos para apoiar as suas implementações.
Partindo de uma visão macro, a metodologia DMAIC pode
ser conjugada com as práticas genéricas para institucionali-
zar, otimizar e atingir alta capacidade nesses processos (SEI,
2005). A Figura 18 faz uma relação visual entre várias áreas de
processo do CMMI e práticas genéricas alinhadas com passos
do roteiro DMAIC.
Tabela 6. Six Sigma DMAIC Roadmap (Fonte: Adaptação (ISIXSIGMA, 2009b))
O diagrama da Figura 18 mostra um fluxograma do processo
geral de medição de uma organização, revestido com passos
DMAIC e áreas de processo selecionadas. Enquanto este pro-
cesso da organização foi projetado com observância do modelo
em mente, ele representa uma abordagem integrada para a
utilização global de medição, em vez de uma replicação das
práticas específicas de cada área de processo. Da mesma forma,
esse processo organizativo aproveita ideias do DMAIC, mas
não é uma replicação das etapas DMAIC (SEI, 2005).
A Figura 19 apresenta uma visão resumida dos relaciona-
mentos dos passos do Seis Sigma com as práticas específicas
dos níveis 4 e 5 do CMMI.
M etodologias Ágeis
Figura 18. Áreas de Processo do CMMI e Passos do DMAIC (Fonte: Adaptação
(SEI, 2005))
Figura 19. DMAIC Roadmap e as áreas do CMMI (4 e 5) (Fonte: Adaptação
(SEI, 2005))
Mapeamento CMMI x Seis Sigma
Nesta seção, é feita a relação entre as metas e práticas es-
pecíficas das áreas de processo dos níveis de maturidade
4 e 5 com os passos das fases do Seis Sigma - DMAIC. Em
seguida, há uma breve descrição das metas e práticas para
que possa ser compreendido o relacionamento existente.
Desempenho do Processo Organizacional (OPP)
A área de processo (PA) “Desempenho do Processo Or-
ganizacional (OPP)” (Tabela 7) está englobada no nível 4
de maturidade e possui uma única meta específica (SG):
Estabelecer Baselines e Modelos de Desempenho, na qual
são estabelecidas e mantidas as baselines e os modelos que
caracterizam o desempenho esperado dos processos do
conjunto de processos padrão da organização. Nesta área
Edição 21 - Engenharia de Software Magazine 23
 OPP
SG1 Estabelecer Baselines e Modelos de Desempenho
Práticas Específicas - CMMI
SP 1.1 Selecionar Processos
SP 1.2 Estabelecer Medidas de Desempenho de Processo
SP 1.3 Estabelecer Objetivos de Qualidade e de Desempenho de Processo
SP 1.4 Estabelecer Baselines de Desempenho de Processo
SP 1.5 Estabelecer Modelos de Desempenho de Processo
Tabela 7. Mapeamento da área de processo OPP e DMAIC
existem três, das cinco práticas específicas (SP), que pode-
mos relacionar com o DMAIC.
SP 1.1 Selecionar Processos
Consiste em selecionar os processos ou subprocessos
no conjunto de processos padrão organização que serão
incluídos nas análises de desempenho do processo. Não se
aplica ao Seis Sigma, pois o mesmo parte do princípio de
que tudo é um processo, e, portanto tudo deve ser medido
e analisado.
SP 1.2 Estabelecer Medidas de Desempenho de Processo
Atua no estabelecimento e manutenção das definições das
medidas que serão incluídas nas análises de desempenho de
processo da organização. No Seis Sigma há um conjunto de
atividades que satisfazem esta meta específica, através da
seleção das medidas apropriadas para fornecer visibilidade
da qualidade e desempenho de processo da organização; o
desenvolvimento do plano de coleta dos dados e da validação
do sistema de medição que permite verificar se as medidas
estabelecidas estão sendo úteis.
SP 1.3 Estabelecer Objetivos de Qualidade e de Desempe-
nho de Processo
Consiste em estabelecer e manter objetivos quantitativos de
qualidade e de desempenho de processo para a organização.
No Seis Sigma, as atividades descritas na Tabela 7 se comple-
mentam para atingir a definição de tais objetivos.
SP 1.4 Estabelecer Baselines de Desempenho de Processo
O Seis Sigma atende a esta prática a partir da coleta e análise
das medidas para estabelecer a distribuição e o intervalo de
resultados que caracterizam o desempenho esperado para
os processos, gerando os índices de capacidade através dos
cálculos estatísticos.
24 Engenharia de Software Magazine - Seis Sigma e CMMI
Desempenho do Processo Organizacional (OPP)
Passos do Seis Sigma
---- ---
Definir defeitos, oportunidades, unidades e métricas
MEASURE Desenvolver plano de coleta de dados
Validar o sistema de medição
Definir objetivos de desempenho
ANALYZE Identificar fontes de variação
Determinar a(s) causa(s) raiz(es)
MEASURE Mapa detalhado do processo e áreas adequadas
Coleta de dados
MEASURE
Determinar capacidade do processo e Baseline Sigma
---- ----
SP 1.5 Estabelecer Modelos de Desempenho de Processo
Resume-se em estabelecer e manter os modelos de desem-
penho de processo para o conjunto de processos padrão da
organização. Os modelos de desempenho de processo são
usados para estimar ou prever os valores de uma medida de
desempenho de processo a partir de valores de medições de
outros processos, produtos e serviços. Neste caso, o próprio
seis sigma (6σ) é o valor modelo, obtido através do cálculo do
nível sigma.
Gestão Quantitativa do Projeto (QPM)
A área de processo (PA) “Gestão Quantitativa do Projeto
(QPM)” (Tabela 8) está englobada no nível 4 de maturidade e
possui duas metas específicas (SG): Gerenciar o Projeto Quan-
titativamente, onde o projeto é gerenciado quantitativamente
a partir do uso dos objetivos de qualidade e de desempenho
de processo; e a SG Gerenciar Estatisticamente o Desempenho
de Subprocessos, na qual o desempenho de subprocessos
selecionados no processo definido do projeto é gerenciado
estatisticamente.
A primeira meta contempla as seguintes práticas específicas
(SP):
SP 1.1 Estabelecer os Objetivos do Projeto
Consiste em estabelecer e manter os objetivos de qualidade
e de desempenho de processo do projeto. O Seis Sigma atende
a esta prática através do termo de abertura do projeto que é
gerado na atividade “Desenvolver a declaração do problema,
objetivos e benefícios” na fase de Definição.
SP 1.2 Compor o Processo Definido
Consiste em selecionar os subprocessos que compõem o
processo definido do projeto com bases históricas de estabili-
dade e de dados de capacidade. Não há atividade equivalente
no Seis Sigma.
 M etodologias Ágeis

QPM Gestão Quantitativa do Projeto (QPM)

SG 1 Gerenciar o Projeto Quantitativamente
Práticas Específicas - CMMI Passos do Seis Sigma

SP 1.1 Estabelecer os Objetivos do Projeto DEFINE Desenvolver a declaração do problema, objetivos e benefícios

SP 1.2 Compor o Processo Definido ---- ----

SP 1.3 Selecionar os Subprocessos que serão Gerenciados Estatisticamente ---- ----

MEASURE Determinar capacidade do processo e Baseline Sigma

Identificar valor/não-valor de etapas adicionadas no processo

ANALYZE
SP 1.4 Gerenciar o Desempenho do Projeto Identificar fontes de variação
Determinar a(s) causa(s) raiz(es)
Desenvolver potenciais soluções
IMPROVE
Definir tolerâncias operacionais do sistema em potencial

SG 2 Gerenciar Estatisticamente o Desempenho de Subprocessos

Práticas Específicas - CMMI Seis Sigma
Definir defeitos, oportunidades, unidades e métricas
SP 2.1 Selecionar Medidas e Técnicas Analíticas MEASURE Desenvolver plano de coleta de dados
Validar o sistema de medição
MEASURE Coleta de dados
SP 2.2 Aplicar Métodos Estatísticos para Compreender a Variação Identificar fontes de variação
ANALYZE
Determinar a(s) causa(s) raiz(es)

MEASURE
SP 2.3 Monitorar o Desempenho dos Subprocessos Selecionados Determinar capacidade do processo e Baseline Sigma
ANALYZE Identificar fontes de variação
SP 2.4 Registrar Dados de Gerenciamento Estatístico --- ---

Tabela 8. Mapeamento da área de processo QPM e DMAIC

SP 1.3 Selecionar os Subprocessos que serão Gerenciados
Estatisticamente
Consiste em selecionar os subprocessos e identificar o proces-
so e os atributos de produto a serem medidos e controlados.
As práticas específicas SP 1.2 e SP 1.3 não possuem etapas
correspondentes, pois, conforme mencionado anteriormente,
o Seis Sigma executa a gerência quantitativa em todos os pro-
cessos incluindo, assim, todos os respectivos subprocessos.
SP 1.4 Gerenciar o Desempenho do Projeto
É realizado o monitoramento do projeto para determinar se
os objetivos de qualidade e de desempenho de processo do
projeto serão satisfeitos e identificar ações corretivas quando
apropriado. No Seis Sigma, é executado um conjunto de 6
passos de monitoramento de desempenho do processo, citados
na Tabela 8.
A segunda meta desta PA contempla as seguintes práticas
específicas:
SP 2.1 Selecionar Medidas e Técnicas Analíticas
Consiste em selecionar as medidas e as técnicas analíticas a
serem usadas no gerenciamento estatístico dos subprocessos
selecionados. Três passos do Seis Sigma podem ser utilizados:
“Definir defeitos, oportunidades, unidades e métricas” que
fornece as definições das medidas a serem usadas no geren-
ciamento estatístico; “Desenvolver plano de coleta de dados”
que documenta as definições operacionais das medidas, suas
coleções de pontos e como a integridade das medidas será
determinada; e “Validar o sistema de medição” que permite
a atualização das medidas e técnicas de análise estatística
quando necessário.
SP 2.2 Aplicar Métodos Estatísticos para Compreender a
Variação
Consiste em estabelecer e manter um entendimento da va-
riação dos subprocessos selecionados usando as medidas e as
técnicas analíticas selecionadas.
O entendimento da variação é conseguido, em parte,
coletando e analisando as medidas de processo e de produ-
to de forma que as causas especiais de variação possam ser
identificadas e endereçadas para atingir desempenhos previ-
síveis. Desta forma, utilizam-se os passos Seis Sigma “Coletar
dados”, “Identificar fontes de variação” e “Determinar a(s)
causa(s) raiz(es)”.

Edição 21 - Engenharia de Software Magazine 25

 SP 2.3 Monitorar o Desempenho dos Subprocessos
Selecionados
Monitorar o desempenho dos subprocessos selecionados para
determinar a capacidade dos mesmos de satisfazer aos seus ob-
jetivos de qualidade e de desempenho de processo, e identificar
ações corretivas quando necessário. No Seis Sigma, os passos
“Determinar capacidade do processo e Baseline Sigma” e “Iden-
tificar fontes de variação” permitem obter os limites naturais de
desempenho de processo comparados com seus objetivos estabe-
lecidos e a capacidade de processo de cada subprocesso.
SP 2.4 Registrar Dados de Gerenciamento Estatístico
Trata-se de realizar o registro dos dados de gerenciamento esta-
tístico e de qualidade no repositório de medidas da organização.
O Seis Sigma não possui um passo definido para esta prática, pois
considera a coleta e o armazenamento como um único passo.
Inovação Organizacional (OID)
A área de processo (PA) “Inovação Organizacional (OID)”
(Tabela 9) está inserida no nível de maturidade 5 e possui duas
metas específicas (SG): Selecionar Melhorias, onde são selecio-
nadas as melhorias de processo e de tecnologia que contribuem
para atingir os objetivos de qualidade e de desempenho de
processo; e a SG Implementar Melhorias, na qual melhorias
mensuráveis para os processos e tecnologias da organização
são continuamente e sistematicamente implementadas.
A primeira meta contempla as seguintes práticas especí-
ficas (SP):
SP 1.1 Coletar e Analisar Propostas de Melhoria
Consiste em coletar e analisar propostas de melhoria de proces-
so e de tecnologia. No Seis Sigma, através do desenvolvimento
da declaração do problema, objetivos e benefícios, são definidos
os projetos de melhoria. Na fase de melhoria, são desenvolvidas
as potenciais soluções para os projetos estabelecidos.
SP 1.2 Identificar e Analisar Inovações
Esta prática identifica e analisa melhorias inovadoras que po-
deriam aumentar a qualidade e o desempenho de processo de
uma organização. No Seis Sigma, através do desenvolvimento

OID Inovação e Desenvolvimento Organizacional (OID)

SG 1 Selecionar melhorias
Práticas Específicas - CMMI Passos do Seis Sigma

DEFINE Desenvolver a declaração problema, objetivos e benefícios

SP 1.1 Coletar e Analisar Propostas de Melhoria
IMPROVE Desenvolver potenciais soluções

SP 1.2 Identificar e Analisar Inovações IMPROVE Desenvolver potenciais soluções

Realizar projetos experimentais

SP 1.3 Melhorias Piloto IMPROVE
Desenvolver potenciais soluções

SP 1.4 Selecionar Melhorias para Implantação IMPROVE Validar melhorias em potencial de estudos-piloto

SG 2 Implementar Melhorias
Práticas Específicas - CMMI
SP 2.1 Planejar a Implantação
SP 2.2 Gerenciar a Implantação
Passos do Seis Sigma
Definir defeitos, oportunidade, unidade e métricas
MEASURE Mapa detalhado do processo e áreas adequadas
Desenvolver plano de coleta de dados
Realizar projetos experimentais
Desenvolver potenciais soluções
IMPROVE
Definir tolerâncias operacionais do sistema em potencial

CONTROL Definir e validar acompanhamento e controle do sistema

Validar melhorias em potencial de estudos-piloto

IMPROVE
Corrigir/reavaliar o potencial da solução
SP 2.3 Medir os Efeitos de Melhorias Determinar capacidade do processo
CONTROL
Verificar benefícios, redução/economia de custos, crescimento do lucro

Tabela 9. Mapeamento da área de processo OID e DMAIC

26 Engenharia de Software Magazine - Seis Sigma e CMMI


de potenciais soluções, são analisadas as todas as propostas
de melhoria, incluindo as inovadoras.
SP 1.3 Melhorias Piloto
Implantação de melhorias de processo e tecnologia através de
um piloto para selecionar aquelas a serem implementadas. Pi-
lotos são realizados para avaliar mudanças novas importantes,
sendo implantadas de forma abrangente, quando apropriado. O
Seis Sigma realiza esta implantação piloto através dos projetos
experimentais na fase de melhoria, criando soluções para os
pilotos que apresentam os melhores resultados.
SP 1.4 Selecionar Melhorias para Implantação
Nesta prática, ocorre a seleção de melhorias de processo e de
tecnologia para implantação na organização. O levantamento
é baseado nos critérios quantificáveis derivados dos objetivos
de qualidade e de desempenho de processo da organização.
No Seis Sigma, está relacionada com a validação de melhorias
em potencial de estudos-piloto, da fase de melhoria.
A segunda meta desta PA contempla as seguintes práticas
específicas:
SP 2.1 Planejar a Implantação
Estabelece e mantém os planos de implantação das melho-
rias de processo e de tecnologia selecionadas. No Seis Sigma,
alguns passos podem ser utilizados: o “Definir defeitos,
oportunidade, unidade e métricas” estabelece medidas e
objetivos para determinar o valor de cada melhoria de pro-
cesso e de tecnologia com relação aos objetivos de qualidade
e de desempenho de processo; obter o “Mapa detalhado do
processo e áreas adequadas” auxilia no entendimento do
processo e na identificação de estratégias para endereçar
potenciais barreiras na implantação de cada melhoria de
processo e de tecnologia; e “Desenvolver plano de coleta de
dados” para agregar o uso de dados quantitativos na orien-
tação da implantação.
SP 2.2 Gerenciar a Implantação
Realiza o gerenciamento da implantação das melhorias de pro-
cesso e de tecnologia selecionadas. Nesta prática, o planejamento
pode ser quantificado em relação aos objetivos de negócio da
organização. Duas fases do Seis Sigma podem ser utilizadas:
• A fase de Medição, através dos passos: “Realizar projetos
experimentais”, para implantação das melhorias de forma
controlada e disciplinada; “Desenvolver potenciais soluções”,
para identificar ações corretivas, caso a habilidade dos pro-
cessos definidos em atingir os objetivos de qualidade e de
desempenho de processo seja afetada negativamente pela
melhoria de processo; “Definir tolerâncias operacionais do
sistema em potencial” que pode ser utilizada para determinar
a habilidade dos processos;
• A fase de Controle, que define e valida o acompanhamento e
controle do sistema para documentar e revisar os resultados de
implantação, identificando lições aprendidas, novas propostas
e melhorias de processo.
M etodologias Ágeis
SP 2.3 Medir os Efeitos de Melhorias
Estabelece a medição dos efeitos das melhorias de proces-
so e tecnologia implantadas. Após medir custos, esforço,
cronogramas reais, valor das melhorias, progresso da
qualidade e desempenho, acontece o armazenamento das
medidas no repositório da organização. Os passos do Seis
Sigma que podem ser utilizados na fase de melhoria são:
validar melhorias em potencial de estudos-piloto, corrigir/
reavaliar o potencial da solução. E na fase de controle:
determinar capacidade do processo, verificar benefícios,
redução/economia de custos, crescimento do lucro.
Análise de Causa e Solução de Problemas (CAR)
A área de processo (PA) “Análise de Causa e Solução de
Problemas (CAR)” (Tabela 10) está incluída no nível 5 de
maturidade e possui duas metas específicas (SG): Deter-
minar Causas de Defeitos, onde as causas de defeitos e de
outros problemas são sistematicamente determinadas; e a
SG Tratar as Causas dos Defeitos, na qual as causas raiz
dos defeitos e de outros problemas são tratadas de forma
sistemática para prevenir suas ocorrências futuras.
A primeira meta contempla as seguintes práticas es-
pecíficas (SP):
SP 1.1 Selecionar Dados de Defeitos para Análise
Seleciona os defeitos e outros problemas para análise. Na
fase Medir do Seis Sigma, realiza-se a definição de defei-
tos, oportunidades, unidades e métricas que reúne dados
de defeitos ou de problemas relevantes; há o desenvolvi-
mento do plano de coleta de dados para fazer relatórios e
medições de problemas relevantes; e por último a coleta
de dados para determinar e selecionar defeitos.
SP 1.2 Analisar Causas
Realiza a análise de causas de defeitos selecionados e
de outros problemas e propõe ações para tratá-los. O Seis
Sigma utiliza o passo “Determinar a(s) causa(s) raiz(es)”
para conduzir as análises nas reuniões e o passo “Identi-
ficar fontes de variação” para analisar os defeitos e outros
problemas para determinar soluções. Ambos os passos
são da fase de Análise.
A segunda meta desta PA contempla as seguintes prá-
ticas específicas:
SP 2.1 Implementar Propostas de Ação
Implementa as propostas de ação selecionadas que fo-
ram elaboradas na análise de causa. As propostas descre-
vem as tarefas necessárias para remover as causas raízes
dos defeitos ou dos problemas analisados e evitar suas
recorrências. Durante a implementação as informações
e tarefas podem fazer parte do passo de desenvolver o
plano de transferência (handoff para o proprietário do
processo), da fase controlar no Seis Sigma, contribuindo
para que os experimentos sejam conduzidos de forma
transparente.
Edição 21 - Engenharia de Software Magazine 27
 CAR
SG 1 Determinar Causas de Defeitos
Práticas Específicas - CMMI
SP 1.1 Selecionar Dados de Defeitos para Análise
SP 1.2 Analisar Causas
SG 2 Tratar as Causas dos Defeitos
Práticas Específicas - CMMI
SP 2.1 Implementar Propostas de Ação
SP 2.2 Avaliar os Efeitos das Mudanças
SP 2.3 Registrar Dados
Tabela 10. Mapeamento da área de processo CAR e DMAIC
SP 2.2 Avaliar os Efeitos das Mudanças
Avalia os efeitos das mudanças no desempenho do processo
após a sua implementação modificada no projeto. O efeito deve
ser verificado para reunir evidências de que essa mudança
está corrigindo o problema e melhorando o desempenho. Três
passos da fase de melhoria do Seis Sigma podem ser utiliza-
dos: “Avaliar modos de falha de soluções em potencial” que
determina a influência das mudanças no desempenho, “Va-
lidar melhorias em potencial de estudos-piloto” que valida a
eficiência da melhoria e, por fim, “Verificar redução/economia
de custos, crescimento do lucro”.
SP 2.3 Registrar Dados
Faz o registro dos dados de análise de causa e resolução para
uso no projeto e na organização, que pode ser usado para fazer
mudanças de processo apropriadas e alcançar resultados simi-
lares. No Seis Sigma, o passo de controle que fecha o projeto e
finaliza a documentação é responsável por fazer os registros
de todo material.
Estudo de Caso
Neste tópico é apresentado um exemplo de utilização do
Seis Sigma para o alcance do nível 5 de maturidade do CMMI,
realizado pelo Instituto Atlântico.
A Empresa
Fundado em 2001 pelo CPqD, (Centro de Pesquisa de Desen-
volvimento em Telecomunicações do Brasil), o Atlântico atua
em P&D/Inovação, Projetos de Desenvolvimento e Consulto-
ria, atendendo principalmente à Indústria, Governo e Setor
Financeiro. Suas unidades em Fortaleza-CE, Sobral-CE e São
Paulo-SP agregam mais de 290 profissionais.
28 Engenharia de Software Magazine - Seis Sigma e CMMI
Análise e Resolução de Causas (CAR)
Passos do Seis Sigma
Definir defeitos, oportunidade, unidade e métricas
MEASURE Desenvolver plano de coleta de dados
Coleta de dados
Determinar a(s) causa(s) raiz(es)
ANALYZE
Identificar fontes de variação
Passos do Seis Sigma
CONTROL
Desenvolver plano de transferência, Handoff para o proprietário do processo
Avaliar modos de falha de soluções em potencial
Validar melhorias em potencial de estudos-piloto
IMPROVE
Verificar redução/economia de custos, crescimento do lucro
CONTROL Fechar o projeto, finalizar documentação
O Atlântico desenvolve projetos de tecnologia da informação
na linha de software, hardware e sistemas, para clientes de
diversos segmentos de mercado, gerando soluções em Compu-
tação Móvel, Integração de Sistemas, TV Digital, Aplicações Fi-
nanceiras, Web, Sistemas para Redes, Automação, Engenharia de
Telecom, Hardware e Sistemas Embarcados. Estas soluções são
desenvolvidas em J2EE, J2ME e. NET (ATLANTICO, 2009b).
Qualidade como Ferramenta Estratégica
Desde o início de suas operações, o Atlântico coloca em práti-
ca a ideia de que o investimento em um amplo sistema de qua-
lidade é a forma mais eficiente de se gerar bons resultados.
Em 2005, a empresa conquistou a certificação ISO 9001:2000.
Em fevereiro de 2006 o Atlântico foi avaliado como CMMI
Nível 3, sendo a primeira organização Norte/Nordeste com
esse nível de maturidade. Em 2009, a qualidade atingiu seu
auge com a avaliação CMMI nível 5, que apoiados em filoso-
fias de trabalho como Six Sigma, RUP, PMBoK, Agile e MSF
(ATLANTICO, 2009c).
A Figura 20 apresenta um breve histórico das certificações
obtidas pela empresa, acompanhado das filosofias de quali-
dades utilizadas.
Figura 20. Histórico de Certificações e Filosofias de Qualidade (Fonte:
Adaptação (ATLÂNTICO, 2009c))
 M etodologias Ágeis

Desta forma, o Atlântico obteve ótimos resultados, possi-

bilitando maior índice de entregas dentro do custo e prazo,
com alto padrão de qualidade e aumento na satisfação dos
seus clientes.

Estratégia CMMI x Seis Sigma

Atualmente, o Instituto Atlântico é a sexta organização no
Brasil reconhecida com o CMMI-5. Para o alcance deste ob-
Figura 21. Produtividade (Fonte: (ATLÂNTICO, 2009a))
jetivo, o instituto foi auxiliado pela empresa de consultoria
internacional com foco exclusivo em qualidade de processos,
ISD (Integrated System Diagnostics Brasil S/C Ltda).
A estratégia utilizada para o alcance do Nível 5 com base no Seis
Sigma, foi implementada em três fases (ATLANTICO, 2009a):

Fase 1 – Planejamento e Definição da Estratégia

• Formação de yellow belts e green belts (consultoria de
black belts)
• Reestruturação dos processos de “melhoria contínua” para
incorporar a nova filosofia 6σ (DMAIC) Figura 22. Densidade de Defeitos (Fonte: (ATLÂNTICO, 2009a))
• Reestruturação dos indicadores de acordo com as estratégias
(BSC e M&A)
• Seleção de projetos de melhoria DMAIC e líderes (DAR)

Fase 2 – Execução da Estratégia de Melhoria (DMAIC)

• D – Definição dos Projetos e Casos de Negócios
• M – Medição do Estado Atual
• A – Análise e Teste das Causas
• I – Propostas de Melhoria
• C – Estabelecimento de Controles Organizacionais

• Acompanhamento dos projetos DMAIC
• Tra nsição das mel horias e ga n hos obt idos para a
“produção”
Fase 3 – Avaliação da Estratégia
• Acompanhamento das melhorias e ganhos obtidos
• Avaliação independente dos resultados dos projetos DMAIC
Figura 23. Atendimento ao Prazo (Fonte: (ATLÂNTICO, 2009a))
“É o grande diferencial: a organização vai sempre executar os seus pro-
cessos de forma melhor, mais otimizada, mais eficiente e eficaz. O controle
estatístico é um pré-requisito para fazer essa melhoria dos processos. A
partir desse controle se sabe qual o desempenho e se executam as ações
para melhorar – tudo baseado em controle estatístico”.

Resultados Conforme Cláudio Violato, atual presidente do Instituto

André Pinho, analista da ISD que acompanhou as avaliações
ao longo da preparação para o CMMI5, destaca a redução de
retrabalho, redução de problemas, a melhoria da produtividade
e afirma que a certificação se traduz em ganhos para a empresa
(ATLANTICO, 2009d):
“Quando a empresa começa a medir, controlar e a usar fer-
ramentas estatísticas, é possível melhorar o desempenho, que
se traduz em resultados - inclusive financeiros”.
Os gráficos a seguir permitem uma visualização resumida dos
benefícios em termos de produtividade (Figura 21), densidade
de defeitos (Figura 22) e atendimento ao prazo (Figura 23).
Gabriela Teles, que coordenou a equipe do Atlântico nos dois
anos de preparação para chegar ao CMMI5 faz suas considerações
sobre os benefícios para a empresa (ATLANTICO, 2009d):
Atlântico e vice-presidente de Tecnologia do CPqD, o Atlân-
tico se tornou muito mais capaz de planejar, de organizar, de
estruturar e de garantir o resultado de acordo com o planejado
(ATLANTICO, 2009d):
“O CMMI contribui para melhorar o resultado financeiro em dois
sentidos”, disse ele. “Primeiro porque temos mais condições de trazer
mais projetos para fazer. E segundo porque a gente faz o projeto com
mais controle: a chance de perda é muito menor. Então o resultado
financeiro começa a melhorar também”.
Conclusão
Diante do atual cenário de mercado altamente competitivo, é
mais importante do que nunca para as organizações o investi-
mento na melhoria de processos para atender às suas missões
(satisfação dos clientes, lucratividade, qualidade, entre outras).

Edição 21 - Engenharia de Software Magazine 29

Muitas empresas percebem sabiamente que não é preciso fazê-lo
a partir do zero, sendo possível otimizar os processos existentes,
utilizando iniciativas de melhoria e práticas. No entanto, pode ha-
ver uma “sobrecarga” de iniciativas. Desta forma, os responsáveis
por aplicar os esforços de melhoria de processos organizacionais
devem projetar a sua estratégia e táticas de implementação para
que as múltiplas iniciativas escolhidas possam interagir.
Determinar o que é apropriado requer uma compreensão
das iniciativas selecionadas e suas ligações. Este artigo
abordou os aspectos comuns existentes entre o Seis Sigma
e o CMMI de modo que a sinergia entre ambos possa ser
percebida.
Referências Bibliográficas
ABRANTES,José.Programa 8S:da alta administração à linha de produção:o que fazer para aumentar o lucro?:
a base da filosofia Seis Sigma.Rio de Janeiro: Interciência, 2001.
ASQ 2009a – American Society for Quality.Organization-Wide Approaches.Disponível em: http://www.asq.
org/learn-about-quality/six-sigma/overview/belts-executives-champions.html.Acessado em: 01/11/2009.
ASQ 2009b – American Society for Quality.Six Sigma Black Belt Certification – CSSBB.Disponível em: http://
www.asq.org/certification/six-sigma/index.html.Acessado em: 09/11/2009.
ASQ 2009c – American Society for Quality.Six Sigma Green Belt Certification – CSSBB.Disponível em:http://
www.asq.org/certification/six-sigma-green-belt/index.html.Acessado em: 08/11/2009.
ATLANTICO 2009a – Instituto Atlântico. Utilização do Six Sigma para o alcance do nível 5 de maturidade do
CMMI. Disponível em: http://www.atlantico.com.br/ sites/default/files/biblioteca/utilizacao-do-six-sigma-
para-o-alcance-do-nivel-5-de-maturidade-do-cmmi.pdf.Acessado em: 09/12/2009.
ATLANTICO 2009b – Website do Instituto Atlântico. Quem Somos. Disponível em: http://www.
institutoatlantico.com.br/quem-somos.Acessado em: 09/12/2009.
ATLANTICO 2009c – Website do Instituto Atlântico. Quem Somos - Qualidade. Disponível em: http://www.
institutoatlantico.com.br/quem-somos/qualidade.Acessado em: 09/12/2009.
ATLANTICO 2009d – Website do Instituto Atlântico. Notícias – Instituto Atlântico conquista CMMI Nível 5.
Disponível em: (http://www.institutoatlantico.com.br/ noticias/instituto-atl%C3%A2ntico-conquista-
cmmi-n%C3%ADvel-5) Acessado em: 09/12/2009.
BARTIÉ, Alexandre. Garantia da Qualidade de Software: Adquirindo maturidade organizacional. Rio de
Janeiro: Elsevier, 2002.
CARVALHO, Marly Monteiro de, PALADINI, Edson Pacheco.Gestão da Qualidade:Teoria e Casos.Rio de Janeiro:
Elsevier, 2005.
CITS - CENTRO INTERNACIONAL DE TECNOLOGIA DE SOFTWARE. CMMI (CAPABILITY MATURITY MODEL
INTEGRATION).Disponível em: http://www.cits.br/cmmi.do.Acessado em 24/09/2009.
CMMI Product Development Team. CMMI for Development, Version 1.2 (CMU/SEI-2006-TR-008, ESC-TR-
2006-008).Software Engineering Institute, Carnegie Mellon University, 2006.
EFQM – European Foundation for Quality Management.The EFQM Excellence Model. Disponível em: http://
ww1.efqm.org/en/Home/aboutEFQM/Ourmodels/TheEFQMExcellenceModel/tabid/170/Default.aspx.
Acessado em: 24/09/2009.
FERNANDES, Aguinaldo Aragon.  Implantando a governança de TI:  da estratégia à gestão dos processos e
serviços. 2.ed. Rio de Janeiro: Brasport, 2008.
FINANCE,Yahoo. GE Interactive Charts. Disponível em: http://finance.yahoo.com/echarts?s=GE#chart2:sym
bol=ge;range=19650104,20040101;indicator=volume+mfi;charttype=line;crosshair=on;ohlcvalues=0
;logscale=on;source=undefined.Acessado em: 11/11/2009.
30 Engenharia de Software Magazine - Seis Sigma e CMMI
O valor potencial que é adicionado trata-se da obtenção acelerada
de metas de desempenho, otimização da adoção do CMMI (nos
níveis mais altos), desenvolvimento das habilidades mais importan-
tes de medição e análise para permitir uma melhor quantificação
dos resultados, e toda a mudança de cultura correspondente que
acompanha essas melhorias.
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
Dê seu voto sobre este artigo, através do link: edição
www.devmedia.com.br/esmag/feedback
FNQ – FUNDAÇÃO NACIONAL DA QUALIDADE. Critérios de Excelência 2009 - Avaliação e Diagnóstico
da Gestão Organizacional. Disponível em: http://www.fnq.org.br/Portals/_FNQ/Documents/web_
CriteriosExcelencia2009_mais_recente.pdf.Acessado em: 22/09/2009.
GRUPO WERKEMA - Six Sigma Consultores, Werkema Editora e Ousar Comunicação Estratégica. Dúvidas
frequentes sobre o Seis Sigma. Disponível em: http://www.werkemaconsultores.com/inside.php?ident=8.
Acessado em: 05/11/2009.
ISIXSIGMA 2009a – Six Sigma Quality Resources for Achieving Six Sigma Results. The History of Six Sigma.
Disponível em: http://www.isixsigma.com/library/content/ c020815a.asp .Acessado em: 05/11/2009.
ISIXSIGMA 2009b – Six Sigma Quality Resources for Achieving Six Sigma Results. Six Sigma DMAIC Roadmap.
Disponível em: http://www.isixsigma.com/library/ content/c020617a.asp.Acessado em: 11/12/2009.
MOTOROLA – Website da Motorola Brasil. Linha do Tempo. Disponível em: http://www.motorola.com/
content.jsp?globalObjectId=485-914#top.Acessado em: 05/10/2009.
PANDE, P. S.; NEUMAN, R. P.; CAVANAGH, R. R. Estratégia seis sigma: como a GE, a Motorola e outras grandes
empresas estão aguçando seu desempenho.Rio de Janeiro: Qualitymark, 2001.
PDP Net – Ambiente de Compartilhamento de Conhecimentos em Desenvolvimento de Produtos. Roteiro
DMAIC. Disponível em: http://www.pdp.org.br/ModeloLivroWeb/modelo/met_ferram/seissigma/
fm6sigma_rot1.htm.Acessado em: 12/11/2009.
PROFITABILITY Engineers. Six Sigma Green Belt. Disponível em: http://www.profitability.pt/conteudos.
aspx?cat=30&catMae=26.Acessado em: 06/11/2009.
ROCHA, Hélio. Simples Soluções Desenvolvimento Organizacional Ltda. Programa 8S – Promovendo
a Qualidade de Vida. Disponível em: http://www.simplessolucoes.com.br/blog/wp-content/
uploads/2009/04/programa-8s-rev02.pdf.Acessado em 05/10/2009.
SEI. Performance Results of CMMI - Based Process Improvement (TECHNICAL REPORT CMU/SEI-2006-TR-
004, ESC-TR-2006-004). Software Engineering Institute, Carnegie Mellon University, 2006. Disponível em:
http://www.sei.cmu.edu/publications/documents/06.reports/06tr004.html.Acessado em 23/09/2009.
SEI. Relationships Between CMMI and Six Sigma (TECHNICAL NOTE CMU/SEI-2005-TN-005). Software
Engineering Institute, Carnegie Mellon University, 2005. Disponível em: http://www.sei.cmu.edu/
reports/05tn005.pdf.Acessado em 02/12/2009.
SMIDT & PARTNERS. The phase model for problem solving is named DMAIC. Disponível em: http://smidt-
partners.dk/six-sigma_uk/dmaic.html.Acessado em: 12/11/2009.
SSPJ - SECRETARIA DA SEGURANÇA PÚBLICA DO ESTADO DE GOIÁS. Ferramentas da Qualidade. Disponível
em: http://www.sspj.go.gov.br/policia-comunitaria/aulas-do-curso/gestao-qualidade/material-de-apoio.
doc.Acessado em: 21/09/2009.
TENNANT, Geoff.SIX SIGMA: SPC and TQM in Manufacturing and Services.Gower Publishing Ltd, 2001.
 M etodologias Ágeis

AMIGO
...só pra lembrar,
Existem coisas sua assinatura pode
estar acabando!
que não
conseguimos
ficar sem!
Renove Já!

www.devmedia.com.br/renovacao
Para mais informações:
www.devmedia.com.br/central

Edição 21 - Engenharia de Software Magazine 31

Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
Colaboração em Processos de Aquisição de Software
João Condack
condack@primeup.com.br
Mestre em Informática e Engenheiro de
Computação pela PUC-Rio. Coordenador de
Instituição Implementadora MPS.Br. Rea-
lizou consultoria empresas como Furnas,
Smart Solutions e Banco Itaú. Também é
instrutor de cursos na área de processos de
software pela PrimeUp e pela CCE/PUC-Rio
atendendo organizações como Caixa Econô-
mica Federal, Firjan, Petrobrás entre outras.
Rafael Vieira
rafael.vieira@primeup.com.br
Bacharel em Sistemas de Informação pela
PUC-Rio. Foi analista de sistemas em pro-
jetos junto organizações tais como: IBGE,
M4U e MP-RJ. Instrutor do Programa de
Residência em Desenvolvimento de Sof-
tware do LES/PUC-Rio. Também atuou no
projeto e desenvolvimento de framework
para aplicações colaborativas visando
apoio aquisição de software.
32 Engenharia de Software Magazine - Colaboração em Processos de Aquisição de Software
O
rganizações que tenham neces-
sidades de adquirir software
e serviços relacionados se de-
param frequentemente com problemas
inerentes ao trabalho colaborativo, que
se caracteriza pelo trabalho através da
interação entre diversos indivíduos. Os
desafios e problemas de interação não
possuem uma solução simples, como um
produto único disponível no mercado,
e não podem ser tratados somente por
meio de ferramentas. Os desafios podem
envolver desde a integração de pessoas
com perfis profissionais diferentes até
as dificuldades de identificação das
necessidades de aquisição, dado que
cada stakeholder tem sua própria visão
e abordagem. Para ilustrar a situação
considere o seguinte cenário:
• Equipes de departamentos jurídico e
técnico discutindo questões legais sobre
contratos de software;
• Analistas de requisitos discutindo e
obtendo aprovação de requisitos, junto
aos usuários;
De que se trata o artigo?
Utilizando o Modelo de Colaboração 3C e o Guia de
Aquisição do MPS.Br, este artigo discorre sobre os
aspectos colaborativos em processos de aquisição
de software. Ele identifica suas principais ques-
tões e também algumas ferramentas para apoio
ao trabalho colaborativo no contexto descrito.
Para que serve?
O objetivo deste artigo é apresentar os problemas
específicos relacionado à colaboração em proces-
sos de aquisição de software e indicar algumas das
possíveis soluções para estes.
Em que situação o tema é útil?
O tema é útil para organizações que adqui-
rem softwares produzidos por terceiros e que
desejam melhorar seu processo de aquisição,
com o fim de torná-lo eficiente e eficaz.
• O gerenciamento do contrato, o qual
poderia ser verificado, ou mesmo rene-
gociado, a cada nova versão do sistema
com o cliente.
O objeto da aquisição definido pelo
Guia de Aquisição do MPS.BR é “o pro-
duto de software propriamente dito, bem

como serviços tipicamente relacionados ao desenvolvimento,
implantação, suporte à operação e manutenção do software.” O
processo de aquisição trata das atividades relacionadas à con-
tratação deste objeto, com o fim de criar e manter uma relação
entre cliente e fornecedor em que expectativas de incorporação
e entrega de sistemas sejam atendidas. Esse processo pode ser
descrito através de quatro fases:
1. preparação da aquisição
2. seleção do fornecedor
3. monitoração do fornecedor
4. aceitação pelo cliente
O problema
Para atender novas demandas organizacionais por tecnologia
de informação, pode ser necessário:
• Desenvolver novos sistemas no lugar dos que já existem;
• Desenvolver sistemas que reutilizem os que já existem ou
realizar serviços para sua manutenção;
• Contratar outra empresa que realize as atividades mencio-
nadas acima;
• Adquirir sistemas gratuitos que atendam às necessidades.
Caso a decisão tomada seja por contratar o desenvolvimento,
será necessário, em linhas gerais: definir as necessidades que o
sistema atenderá; selecionar o fornecedor; criar um ou mais con-
tratos, formalmente ou informalmente definido, dependendo
do nível de cerimônia combinado com o contratante; estabelecer
meios de comunicação com o fornecedor e acompanhar o cum-
primento do contrato; e, por fim, aceitar ou não o sistema.
Esse processo poderia se repetir diversas vezes. Por conta
disso, surgem questões indagando se a forma de trabalho au-
xiliou na integração e na comunicação entre os interessados no
projeto, ou se o conhecimento adquirido, que poderia ser útil
para novas aquisições, foi registrado adequadamente.
O Guia de Aquisição do MPS.BR e a Colaboração
O Guia de Aquisição do MPS.BR é um modelo de referên-
cia para processos de aquisição de software. Ele define que
esses processos são constituídos de atividades, as quais são
executadas em fases específicas e possuem produtos como
pré-condições ou pós-condições. Essas fases são:
1. Preparação da aquisição: trata da definição de necessidades,
requisitos de software, metas e critérios de aceitação do software a
ser contratado, bem como a definição do plano da aquisição; aqui
se busca entender as necessidades do sistema a ser adquirido;
2. Seleção do fornecedor: trata da preparação e negociação de
contratos com fornecedores e avaliação e seleção destes;
3. Monitoração do fornecedor: visa manter canais de comu-
nicação com o fornecedor e acompanhar a aquisição propria-
mente dita, ou seja, se as entregas estão dentro dos critérios
de aceitação definidos anteriormente;
4. Aceitação pelo cliente: realiza a aceitação final do produto
desenvolvido, com base nos critérios definidos na preparação
da aquisição; momento em que o sistema é integrado totalmen-
te à organização contratante.
processo
Nestas fases, as atividades apresentadas na Tabela 1 são
executadas.
Guia de Aquisição – Atividades Tarefas
Estabelecer a necessidade
Definir os requisitos
Preparação da aquisição Revisar requisitos
Desenvolver uma estratégia de aquisição
Definir os critérios de seleção de fornecedores
Avaliar a capacidade dos fornecedores
Seleção do fornecedor Selecionar o fornecedor
Preparar e negociar um contrato
Estabelecer e manter comunicações
Trocar informação sobre o progresso técnico
Inspecionar o desenvolvimento com o fornecedor
Monitoração do fornecedor
Monitorar a aquisição
Obter acordo quanto às alterações
Acompanhar problemas
Definir critérios de aceitação
Avaliar o produto entregue
Aceitação pelo cliente
Manter conformidade com o contrato
Aceitar o S&SC
Tabela 1. Fases e tarefas do Guia de Aquisição do MPS.BR
Neste processo, diversos papéis são desempenhados,
entre os quais os mais evidentes são o do cliente e o do
fornecedor. Representando o cliente, outros papéis po-
dem ser identificados, como, por exemplo, analistas de
requisitos, pessoal técnico, usuários ou responsáveis pelo
projeto. Representando o fornecedor, também podem ser
identificados gerentes de projetos, analistas de requisitos,
arquitetos ou representantes comerciais.
É importante destacar que, diferentemente de processos
convencionais de desenvolvimento de software, há um
foco muito maior no cliente e no gerenciamento de suas
interações com o fornecedor. Segundo o trabalho de Fuks,
“um grupo também tem mais capacidade de gerar alterna-
tivas, levantar as vantagens e desvantagens de cada uma,
selecionar as viáveis e tomar decisões”. Ou seja, por um
lado essa diversidade de papéis pode apresentar desafios,
mas também possui um potencial positivo para a melhoria
da análise e geração de soluções mais adequadas ao que
é necessário.
Dessa forma, a natureza colaborativa desse processo se
torna evidente, bem como toma contornos diferentes de
um processo de desenvolvimento. Sabendo disso, faz-se
necessário entender quais são as carências e oportunidades
inerentes ao trabalho colaborativo, com o fim de maximi-
zar o efeito positivo das interações entre diversos agentes.
Fuks, em seu trabalho, propõe o modelo 3C, que classifica
os sistemas colaborativos segundo três necessidades a
que estes devem atender: comunicação, coordenação e
cooperação. Ou seja, necessidades de compartilhamen-
to de informações, delegação e sincronismo de tarefas
e operação conjunta e benéfica, resumidamente. Mais
detalhadamente:
Edição 21 - Engenharia de Software Magazine 33
• Comunicação: “Durante a comunicação, as pessoas almejam • Brainstorming: ferramentas que apóiem a geração de idéias
construir um entendimento comum e compartilhar idéias, podem ser úteis nas fases iniciais, como apoio ao planejamento.
discutir, negociar e tomar decisões. Os participantes de uma Foram levantadas as seguintes ferramentas que ajudam na
equipe de trabalho devem se comunicar para conseguir rea- geração ou organização de idéias:
lizar tarefas interdependentes, não completamente descritas - Mind map: forma intuitiva de registro e organização de
ou que necessitem de negociação”; conhecimento, onde conceitos se relacionam com conceitos
• Coordenação: “Conversação para ação gera compromissos adjacentes a eles, formando uma árvore;
Winograd and Flores, (1987) e Winograd (1988). Para garantir - Gráfico de Ishikawa: possibilita a visualização das relações
o cumprimento destes compromissos e a realização do traba- de causa e efeito entre os conceitos. É útil para a análise de pro-
lho colaborativo através da soma dos trabalhos individuais, blemas e das necessidades de alto nível que levam à aquisição
é necessária a coordenação das atividades. Esta coordenação do software ou serviço correlato.
organiza o grupo para evitar que esforços de comunicação e • FAQs (Frequently Asked Questions): possibilita o registro
cooperação sejam perdidos e que as tarefas sejam realizadas de dúvidas e de soluções simples que possam ser reutilizadas,
na ordem correta, no tempo correto e cumprindo as restrições em vários projetos de aquisição. Problemas mais complexos
e objetivos [Raposo et al., 2001].”; poderiam ser registrados em uma ferramenta de workflow;
• Cooperação: “Cooperação é a operação conjunta dos membros • Fórum: para apoio à discussão, manutenção das discussões
do grupo no espaço compartilhado. Em um espaço virtual de e suas conclusões, bem como seu registro;
informação, os indivíduos cooperam produzindo, manipulan- • Gerenciador de documentos: manutenção de documentos
do e organizando informações, bem como construindo e refi- diversos, como páginas wiki, mensagens em fóruns e docu-
nando artefatos digitais, como documentos, planilhas, gráficos, mentos e templates de, por exemplo, contratos de software,
etc. O ambiente pode fornecer ferramentas de gerenciamento RFP (request for proposal), entre outros;
destes artefatos, como por exemplo, registro e recuperação de • Grupos de trabalho: ferramentas que permitem gerenciar
versões, controle e permissões de acesso, etc.” grupos de trabalho, auxiliam no controle de acesso ao conteúdo
e ao gerenciamento de recursos;
Ferramentas de Apoio ao Trabalho Colaborativo • Quadro branco: possibilita fazer esboços rápidos, para apoio à
Ferramentas colaborativas que apóiem tarefas do processo de comunicação falada e à construção colaborativa de esboços. Pode
aquisição de software devem considerar os elementos expostos ser usada em conjunto com videoconferência, para apoio às reuni-
anteriormente. Muitas delas estão disponíveis para uso na Web ou ões virtuais, no caso de equipes geograficamente distribuídas. A
para customização ou integração e se encaixam nas características dificuldade do uso da ferramenta se dá pela necessidade de habi-
mencionadas, sendo até mesmo passíveis de integração, visando lidades para desenho, quando esta não oferece apoio à construção
o suporte completo a fluxos de interação entre os stakeholders. Na de telas e montagem de cenários de uso (storyboarding);
Tabela 2, algumas delas são apresentadas dentro da classificação • RSS (Really Simple Syndication): tecnologia que faz uso de
do modelo 3C. arquivos XML (RSS feeds) gerados por sistemas Web para
informar programas leitores (RSS readers) das alterações nas
Comunicação Coordenação Cooperação
páginas, notificando os usuários de atualizações de conteúdo.
Facilita o acompanhamento de alterações de conteúdos de
E-mail Agenda Gerenciador de documentos
interesse do usuário, que pode escolher ou não acompanhar
a evolução das páginas Web.
Lista de discussão Relatório de atividades Quadro branco
• Videoconferência: para apoio à discussão, bem como seu
registro, em tempo real. Útil para apoio a reuniões;
Fórum Acompanhamento de participação Ferramenta de busca
• Wiki: ferramenta para a construção de conteúdo coletivo, em
que qualquer usuário pode inserir ou editar o conteúdo. É útil,
Mural Questionários Glossário no contexto de aquisição, para a manutenção de informações
Brainstorming Tarefas Links comuns a diversos projetos de aquisição. Poderia ser usado
Chat Grupos de trabalho Jornal cooperativo também para a publicação do processo de aquisição;
Messenger Gerenciamento de recursos Classificador • Workflow, para acompanhamento do fluxo de tarefas e de
resolução de problemas.
Blog Workflow Wiki
Videoconferência Gerenciador de contatos Cenários de uso em que seriam empregadas tais ferramentas
podem ser ilustrados da seguinte forma:
Revisão em pares
• Uma equipe integrando o departamento jurídico e técnico
FAQs discutem através de um fórum, questões legais sobre contratos
Anotações de software, e, em seguida, documentando o conhecimento
RSS produzido em um wiki ou em um repositório de documentos
Tabela 2. Ferramentas de colaboração central, em uma tarefa de preparação do contrato;

34 Engenharia de Software Magazine - Colaboração em Processos de Aquisição de Software


• Analistas de requisitos, entre outros envolvidos, discutindo
sobre os requisitos com o apoio de protótipos em um quadro
branco, os quais poderiam passar por um fluxo de aprovação
(integração com um mecanismo de workflow), com possível
documentação do conhecimento de negócio obtido, no wiki;
• O acompanhamento do cumprimento financeiro, fiscal e físi-
co do contrato é verificado a cada nova release, tendo um fluxo
de aprovação definido na ferramenta de workflow integrada
à plataforma colaborativa.
A correlação entre processos de aquisição e
ferramentas colaborativas
Nesta seção vamos exemplificar mais detalhadamente como
o processo de aquisição pode ser associado às ferramentas cola-
borativas. O relacionamento se dá através do mapeamento entre
as tarefas do Guia de Aquisição do MPS.BR e as referidas ferra-
mentas. Este mapeamento, além de informar as partes associadas,
também define como tal relacionamento ocorre, definindo como
será o apoio da ferramenta específica sobre determinada tarefa.
Para fins de síntese, consideraremos apenas as tarefas da
fase de Preparação da Aquisição, considerada estratégica para
o processo como um todo. Resumiremos também o conjunto
de ferramentas colaborativas às mais comumente encontradas.
Sendo assim temos:
Tarefa: Estabelecer a necessidade
Ferramenta: Workflow
• Apoio: Criação de uma solicitação “Estabelecer a necessida-
de” para acompanhamento da tarefa. Registros de evolução
gerados automaticamente a partir de atualizações em colabo-
rações relacionadas a esta tarefa.
Ferramenta: Blog
• Apoio: Divulgar chamada de participantes para os Fóruns e
Enquetes desta tarefa.
Ferramenta: Fórum
• Apoio: Discutir: Qual é o objetivo da aquisição? Quais são
nossas necessidades e quais serão atendidas para o alcance do
objetivo? Buscar consenso sobre as necessidades estratégicas
envolvidas na aquisição e qual o efetivo escopo das necessi-
dades a serem contempladas pela aquisição.
Ferramenta: Enquetes
• Apoio: As necessidades estão levantadas apropriadamente?
Sim, Não, Apenas parte relevante delas.
• Apoio: A aquisição atenderá.....das necessidades.: a)a totali-
dade; b)parte definida; c)parte desconhecida;
• Apoio: O projeto de aquisição deve: a) Seguir em frente c)
Aprofundar esta atividade c) Ser cancelado
Ferramenta: Wiki
• Apoio: Construção colaborativa da “análise da necessidade da
aquisição”, pode ter como anexo documentos sobre a estratégia
organizacional relacionada às necessidades (motivadores/
processo
antecedentes do projeto de aquisição). Ao final, um documento
deve ser gerado e anexado.
Tarefa: Definir os requisitos
Ferramenta: Workflow
• Apoio: Criação de uma solicitação “Definir os requisitos”
para acompanhamento da tarefa. Registros de evolução gera-
dos automaticamente a partir de atualizações em colaborações
relacionadas a esta tarefa
• Apoio: Criação de uma solicitação “Pesquisa de Mercado”
para obter informações que substanciem os requisitos. Veri-
ficar possíveis fornecedores, outras empresas, e informações
da própria organização.
Ferramenta: Blog
• Apoio: Divulgar chamada de participantes para definição de
estrutura dos requisitos;
• Apoio: Divulgar chamada de participantes para definição
dos requisitos;
• Apoio: Divulgar execução de pesquisa de mercado;
• Apoio: Divulgar chamada de participantes para definição
das restrições do projeto.
Ferramenta: Fórum
• Apoio: Discutir: Qual a estrutura de requisitos necessária?
Buscar consenso sobre quais os tipos/categorias de requisitos
esperados, presença ou não de Priorização, Restrições, Graus
de Aceitação, Restrições Legais etc...
• Apoio: Discutir: Quais são os requisitos desta aquisição? Definir
quais requisitos atendem as necessidades desta aquisição. Forte-
mente recomendado que sejam descritos em estrutura definida
tendo em mente como eles deverão futuramente ser aceitos.
• Apoio: Discussão sobre técnicas de requisitos documentadas
no wiki.
Ferramenta: Enquetes
• Apoio: As informações colhidas são suficientes para definir os
requisitos? Sim, A maior parte, A metade, A menor parte, Não
• Apoio: Os requisitos estão estruturados apropriadamente?
Sim, A maior parte, A metade, Alguns apenas, Não
• Apoio: Os requisitos contemplam....das necessidades.: a)a
totalidade; b)parte definida; c)parte desconhecida;
• Apoio: Precisamos rever as necessidades e alterá-las?
Sim, Não
• Apoio: Sabemos como medir os requisitos para aceitá-los?
Sim, A maior parte, A metade, Alguns apenas, Não
• Apoio: O projeto de aquisição deve: a) Seguir em frente c)
Aprofundar esta atividade c) Ser cancelado
• Apoio: As técnicas de requisitos utilizadas foram adequadas?
Sim, Para a maior parte dos requisitos, Para a menor parte dos
requisitos, Não
Ferramenta: Wiki
• Apoio: Construção colaborativa da “Especificação de requisi-
tos”, pode ter como anexo pesquisas de mercado, informações
Edição 21 - Engenharia de Software Magazine 35
de fornecedores, práticas de outras organizações. Deve estar
clara a estrutura dos requisitos. Relacionar com as necessi-
dades da aquisição e os critérios de aceitação. Ao final, um
documento deve ser gerado e anexado.
• Apoio: Identificar e relacionar a legislação, jurisprudência e
normas pertinentes.
• Apoio: Catalogar lições aprendidas na tarefa que podem ser
úteis em outros momentos da aquisição.
• Apoio: Documentação e publicação das técnicas associadas
às atividades de requisitos.
Tarefa: Revisar requisitos
Ferramenta: Workflow
• Apoio: Criação de uma solicitação “Revisar os requisitos”.
Registros de evolução gerados automaticamente a partir de
atualizações em colaborações relacionadas a esta tarefa.
Ferramenta: Blog
• Apoio: Divulgar chamada para a revisão de requisitos.
Definirá critérios de revisão, por exemplo: para verificar
ambiguidade, estabelecer uma matriz para preenchimento
das comparações dos requisitos entre si; estabelecer que cada
requisito deverá ter uma avaliação de custo/benefício; etc
Ferramenta: Fórum
• Apoio: Discutir: Quais requisitos são críticos ou que devem
ser priorizados? Buscar consenso quanto ao que é funda-
mental ao software após uma análise individual.
• Apoio: Discutir: Como solucionar as incompatibilidades
entre os requisitos? Buscar soluções quanto a requisitos
inconsistentes, se apresentarem alguma ameaça para o
projeto.
• Apoio: Discutir: Qual é o custo/benefício de cada requisito?
Estes estão compatíveis com o projeto?
Ferramenta: Enquetes
• Apoio: A lista de requisitos proposta está completa? Sim,
A maior parte, A metade, A menor parte, Não
• Apoio: A lista de requisitos proposta está priorizada e com
custo/benefício definido? Sim, A maior parte, A metade, A
menor parte, Não
Ferramenta: Wiki
• Apoio: Registro e armazenamento da revisão da “Especi-
ficação de requisitos”.
• Apoio: Documentação e publicação de técnicas de revisão
de requisitos.
Tarefa: Desenvolver uma estratégia de aquisição
Ferramenta: Workflow
• Apoio: Definir e implantar o fluxo de contratação
• Apoio: Criação de uma solicitação “Adequar modelo
de contrato” visando detalhar a abordagem a respeito de
prazos, custo, escopo, multa, direito de distribuição uso e
propriedade.
36 Engenharia de Software Magazine - Colaboração em Processos de Aquisição de Software
Ferramenta: Blog
• Apoio: Divulgar chamada para o desenvolvimento da estra-
tégia de aquisição.
Ferramenta: Fórum
• Apoio: Discussão sobre os termos contratuais, financeiros
e técnicos; Apoio: Discussão sobre os critérios de aceitação
do produto, frente aos requisitos. Estruturar discussões por
requisitos ou grupo de requisitos relacionados;
• Apoio: Discussão para definição da forma de acompanha-
mento: pessoas, lista de produtos gerados, controle do projeto
de aquisição, suficiência dos testes realizados, normas e mo-
delos a seguir e riscos identificados. Distribuição de tarefas
entre as equipes.
Ferramenta: Enquetes
• Apoio: Os requisitos estão associados a critérios de aceitação
que os avaliem?
• Apoio: Os requisitos e as necessidades para definição do
plano de aquisição estão associados a termos de contrato que
os formalizem?
Ferramenta: Wiki
• Apoio: Construção colaborativa do “Plano de aquisição”, do
“Plano de testes de aceitação”, da “Requisição de propostas”
e da “Minuta do contrato”
Tarefa: Definir os critérios de seleção de fornecedores
Ferramenta: Workflow
• Apoio: Criação de uma solicitação “Definir critérios de sele-
ção” para acompanhamento da tarefa. Registros de evolução
gerados automaticamente a partir de atualizações em colabo-
rações relacionadas a esta tarefa
Ferramenta: Blog
• Apoio: Divulgar chamada para a definição dos critérios de
aceitação.
Ferramenta: Fórum
• Apoio: Discussão sobre os critérios de seleção dos fornece-
dores. Poderá contemplar os seguintes fatores: localização ge-
ográfica do fornecedor; registro de desempenho em trabalhos
similares; equipe e infra-estrutura disponíveis para o desenvol-
vimento do produto desejado; tempo de mercado; experiência
no domínio do problema; nível de qualidade de seus processos
utilizados; e certificações exigidas.
Ferramenta: Enquetes
• Apoio: A lista de critérios proposta está completa incluindo a
forma de análise e priorização? Sim, A maior parte, A metade,
A menor parte, Não
Ferramenta: Wiki
• Apoio: Construção colaborativa dos “Critérios de seleção e
análise de fornecedores”

Alinhando soluções
Para atender as questões, interações e integrações levantadas
até então, uma solução deve levar em conta requisitos que
tenham como objetivos finais a promoção da integração das
equipes e pessoas envolvidas nos projetos de aquisição, bem
como a promoção do reuso do conhecimento adquirido nos
projetos antigos em projetos novos de aquisição. Dentre estes
requisitos citamos:
• Integração de equipes e pessoas
- Apoio à seqüência de tarefas de aquisição;
- Suporte e acompanhamento de discussões;
- Avaliação de resultados, busca de consenso e alinhamento
de percepções em discussões;
- Integração das diversas equipes em um mesmo ambiente
de trabalho.
• Reuso de conhecimento
- Documentação do conhecimento e lições aprendidas, obtidos
em cada projeto de aquisição;
- Manutenção de base de documentos, com mecanismo de
busca integrado;
Vale ressaltar que esses requisitos tratam de diversos proble-
mas inerentes a projetos de software, e que na sua ausência
geram prejuízos ou mesmo cancelamentos. Eles abordam, por
exemplo, questões relacionadas a falha no entendimento das
necessidades, rotatividade da equipe, requisitos incompletos
e falta de participação do cliente.
Outra característica fundamental relacionada a implementa-
ção deste tipo de solução é a integração de diversas aplicações
sobre uma arquitetura comum que permita a gestão, publica-
ção e acompanhamento de fluxos de trabalhos e documentos.
Neste ponto, a flexibilidade para reuso e extensão são requi-
sitos essenciais.
Requisitos e protótipos poderiam ser anotados ao longo das
conversas com usuários e, ao final, salvos em um servidor
central da plataforma colaborativa, ao qual o processo (fluxo)
de desenvolvimento é integrado. Outro exemplo poderia ser a
disponibilização de um repositório central de documentos, em
que toda a documentação do cliente passível de análise seria
armazenada, podendo ser recuperada por um mecanismo de
busca textual. Tudo isso poderia ser relacionado a (rastreado
em) requisitos previamente registrados no servidor central,
para fácil recuperação e apoio às tarefas de especificação de
requisitos, posteriormente.
Já na fase de monitoração e aceitação do fornecedor, tarefas
de acompanhamento do projeto ganham importância maior. A
cada nova versão disponível para homologação, o registro das
funcionalidades entregues e testes realizados podem servir para
a geração de relatórios de acompanhamento no servidor central.
Esses relatórios, disponíveis para o cliente, o permite acompanhar
processo
o progresso técnico em relação ao estipulado em contrato. Para
o acompanhamento de problemas, sistemas já disponíveis no
mercado poderiam ser integrados onde fluxos de tarefas são
adequados para rastrear os problemas identificados. Da mesma
forma, o sistema coletaria dados para a produção de relatórios e
acompanhamento do progresso técnico pelo cliente.
É importante observar que essa plataforma central, pela qual
toda a equipe de projeto interagiria, precisa ser integrada a
ferramentas de apoio à elicitação de requisitos, de construção
e de acompanhamento de solicitações, para o registro dos
requisitos contratados e a geração automática dos relatórios
de acompanhamento frente a esses requisitos.
Essas são possíveis linhas de solução para os desafios colabo-
rativos apresentados ao longo do processo de aquisição de sof-
tware. Muitas outras integrações entre ferramentas e soluções
podem ser propostas. Entretanto, o importante a ser observado
é que, seja qual for a estratégia de solução, as tecnologias em-
pregadas devem levar em conta os diversos atores existentes
no processo, apoiando-os nas suas interações. De forma geral,
esse apoio seria direcionado ao acompanhamento do projeto
por parte do cliente e ao entendimento das necessidades do
cliente pelo pessoal técnico, permitindo assim a realização
efetiva da aquisição contratada entre as partes.
Referências Bibliográficas
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR -
Guia de Aquisição, versão 1.2, junho 2007. Disponível em: <www.softex.br>
ALVES, Ângela M; GUERRA, Ana. Aquisição de Produtos e Serviços de Software. Rio de Janeiro:
Elsevier, 2004. 213p.
GUTWIN, C. & GREENBERG, S. The Mechanics of Collaboration: Developing Low Cost Usability
Evaluation Methods for Shared Workspaces. IEEE 9th International Workshop on Enabling
Technologies: Infrastructure for Collaborative Enterprises (WET-ICE’00). Junho 2000.
FUKS, Hugo; RAPOSO, Alberto Barbosa; GEROSA, Marco Aurélio. Do Modelo de Colaboração 3C à
Engenharia de Groupware. In: Simpósio Brasileiro de Sistemas Multimídia e Web – Webmídia
2003, Trilha especial de Trabalho Cooperativo Assistido por Computador, 03 a 06 de Novembro,
Salvador-BA
FUKS, H.; RAPOSO, A.B.; GEROSA, M.A. (2002), Engenharia de Groupware: Desenvolvimento de
Aplicações Colaborativas, XXI Jornada de Atualização em Informática, Anais do XXII Congresso
da Sociedade Brasileira de Computação, V2, Cap. 3, ISBN 85-88442-24-8, pp. 89-128. Disponível
em http://www.les.inf.puc-rio.br/groupware.
Feedback
Dê seu feedback sobre esta edição! eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Edição 21 - Engenharia de Software Magazine 37
Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
Organização Fábrica de Experiência
Obtendo vantagens competitivas nas empresas desenvolvedoras de software
Fernando Hadad Zaidan
fhzaidan@gmail.com
Atua no ramo de TI há mais de 25 anos. Douto-
rando na Ciência da Informação - UFMG. Mestre
em Administração pela Universidade FUMEC
Bacharel em Ciência da Computação pela Uni-
versidade FUMEC. Gestor e desenvolvedor de
Sistemas Web pelo UNI-BH. Analista de Sistemas
e Programador de Computadores pela UFMG. In-
clui cargos de diretor de empresas de   desenvol-
vimento de software, administrador de TI, ana-
lista/desenvolvedor de sistemas   e arquiteto de
dados. Consultor de TI e organizacional. Professor
e Coordenador da Pós-graduação da Faculdade
Pitágoras. Professor de graduação da Faculdade
Ined. Palestrante. Autor de artigos e livro.
George Leal Jamil
gljamil@gmail.com
Possui graduação em Engenharia Elétrica pela
Universidade Federal de Minas Gerais (UFMG)
(1982), Mestrado em Ciência da Computação
pela UFMG (1999) e doutorado em Ciência da
Informação pela UFMG (2005). Atualmente é
professor adjunto da Fundação Mineira de Edu-
cação e Cultura - FUMEC/BH . Tem experiência
na área de Ciência da Computação e Gestão
Estratégica de Empresas, com ênfase em En-
genharia de Software, atuando principalmente
nos seguintes temas: ciência da computação,
engenharia de software, sistemas de informa-
ção, informática, processo de software, gestão
estratégica e de marketing.
38 Engenharia de Software Magazine - Organização Fábrica de Experiência
Leandro Libério da Silva
leandroliberio@gmail.com
É mestrando em Educação Tecnológica pelo
Centro Federal de Educação Tecnológica - CEFET-
MG. MBA em Gestão Comercial pela Fundação
Getúlio Vargas - FGV. Especialista em Banco de
Dados pelo Centro Universitário de Belo Horizon-
te - UNI-BH (2002). Possui graduação em Tecno-
logia em Informática pelo Centro Universitário
Newton Paiva (2001). Atua também como pro-
fessor e coordenador de cursos de especialização
em Tecnologia da Informação do Núcleo de Pós-
Graduação do Sistema Universitário Pitágoras.
Também leciona no UNI-BH.
C
ompreendemos a gestão do co-
nhecimento como um processo
contínuo onde uma organização
orienta suas várias ações com base no co-
nhecimento empresarial. Como tarefas
típicas temos a geração, valorização, re-
gistro, compartilhamento e aplicação do
conhecimento para planos e processos
variados dentro da empresa. Os resulta-
dos positivos da gestão do conhecimento
são inegáveis, uma vez que torna este
precioso acervo – o conhecimento – num
elemento decisivo para a formulação de
vantagem competitiva pela empresa em
seu cenário competitivo.
De que se trata o artigo?
Neste artigo compreenderemos o modelo de pro-
cesso de desenvolvimento de software denominado
organização fábrica de experiência. A criação deste
modelo se deu no laboratório de Engenharia de Sof-
tware da Universidade de Maryland, EUA. A caracte-
rística principal é a presença de uma equipe destina-
da à finalidade de externalizar o conhecimento dos
desenvolvedores.
Para que serve?
Visa à obtenção de vantagens competitivas e
melhores resultados no desenvolvimento de
software – como exemplo na estimativa de custos,
qualidade e prazos – por meio da contribuição de
experiências de projetos de software anteriores e da
gestão da informação e do conhecimento.
Em que situação o tema é útil?
Este modelo permite que as organizações de desen-
volvimento retenham conhecimento dos projetos do
passado para melhorar as habilidades no desenvolvi-
mento futuro, não permitindo que o conhecimento se
perca ou se dissipe facilmente.
Considerar o processo de desenvolvi-
mento de software com o apoio da gestão
do conhecimento, ou sob sua ótica, é
extremamente oportuno. O processo

de desenvolvimento de software é, segundo estudado na
engenharia de software, um conjunto coordenado de tarefas
organizacionais destinado a disponibilizar software de todas
as formas para que uma empresa o utilize segundo seus planos
estratégicos. Atividade de intensiva comunicação e que estru-
tura ideias e procedimentos muitas vezes não formalmente
documentados, o processo de desenvolvimento de software
oferece uma perspectiva muito interessante se for analisado
sob as lentes da gestão do conhecimento. Neste contexto, o
trabalho das “fábricas de experiência” oferece possibilidades
importantes para a associação que evidenciamos.
A Organização Fábrica de Experiência (OFE) é um modelo
desenvolvido pelo laboratório de Engenharia de Software da
Universidade de Maryland. É composta de duas organizações
que trabalham perfeitamente integradas. Neste modelo, existe
uma equipe específica destinada à finalidade de externalizar
(ou seja, difundir ou publicar) o conhecimento gerado dos
próprios desenvolvedores. O desenvolvimento de software
pode obter melhores resultados – como exemplo na estimati-
va de custos, qualidade e prazos – por meio da contribuição
de experiências de projetos anteriores. Com cronogramas
pressionados, elevadas expectativas quanto à qualidade e
produtividade e desafios técnicos constantes, muitos projetos
de software não oferecem possibilidades de explicitar (ou seja,
estruturar formalmente, a partir do informal) o conhecimento.
Porém, neste modelo, esta importante atividade fica por conta
da equipe chamada fábrica de experiência. Esta equipe será
encarregada de analisar e sintetizar todos os tipos de experi-
ência, incluindo as lições aprendidas, dados de projetos e rela-
tórios que explicitam estas experiências mediante a criação de
repositórios. Tal atividade, se considerada diante do processo
de gestão do conhecimento, se constitui em potencial ganho
para o produtor de software ao realizar as funções de geração,
formalização, retenção, compartilhamento e valorização.
Contextualização
As organizações de fábrica de software são empreendimentos
que têm expressiva demanda por informações para a execução
de seus processos. O uso adequado da gestão do conhecimento
e da informação pode ser revertido em vantagens competitivas
para este tipo de organização.
Compreende-se a engenharia de software como uma disci-
plina que visa o desenvolvimento de software de computador,
integrando processo, métodos e ferramentas. Existem modelos
de processo para que cada produtor implemente a melhor
solução em termos de um processo de produção real, eficaz e
efetivo, porém todos definem um conjunto de atividades, uma
coleção de tarefas que são conduzidas para realizar cada ati-
vidade, produtos de trabalho produzidos como conseqüência
das tarefas a serem exigidos para o aceite ou complementação
da tarefa, bem como um conjunto de atividades padrões que
se espalham por todo o processo.
Neste contexto, o trabalhador do conhecimento, notadamente
presente nas empresas de desenvolvimento de software, valoriza
o conhecimentos e sua aplicação pelas organizações como fator
engenharia de soft ware
de uma nova realidade. As organizações devem almejar a apli-
cabilidade do conhecimento dos funcionários no intuito de gerar
novos conhecimentos. Os trabalhadores do conhecimento podem
descobrir, criar, compilar, distribuir ou aplicar o conhecimento.
Os processos organizacionais, dentre eles o processo de desen-
volvimento de sistemas de informação, estão em constante
melhoria, tornando-se uma busca constante por parte das or-
ganizações. O processo de desenvolvimento de software pode
ser compreendido como um método de trabalho estruturado,
em etapas gerenciáveis individual e coletivamente, que tem
como objetivo produzir, de forma coordenada, software para
uma aplicação em geral.
O modelo proposto por Victor Basili e seus colaboradores da
Universidade de Maryland – USA, denominado Organização
Fábrica de Experiência, apresenta uma equipe destinada à fi-
nalidade de externalizar o conhecimento. Os principais ativos das
empresas de desenvolvimento de software não são as constru-
ções, materiais ou equipamentos caros – é o capital intelectual. O
maior problema com o capital intelectual é que ele “tem pernas”
e caminha para casa todos os dias, dificultando as organizações
na permanência dos mesmos. A seguir, estudamos o processo
de desenvolvimento de software, sua interação com a gestão do
conhecimento e a oportunidade das Organizações de Fábricas
de Software neste poderoso contexto.
Processo de desenvolvimento de software
Ao se abordarem o conceito de processo de software, verifica-
se que este é configurado como um conjunto de atividades,
tais como a análise de requisitos, planejamento de produção,
projeto, desenvolvimento dos códigos, testes, manutenção,
aquisições ou contratações e demais providências que levem
à produção de um software. O processo é proposto como uma
rotina que necessita de documentação que detalhe aspectos
e artefatos como: especificação formal e precisa do produto
a ser desenvolvido; os passos ou fases que serão executados,
incluindo sua ordem, gestão de risco e precedência; preparo e
atribuições dos agentes que atuarão na produção; os insumos
que serão utilizados e os resultados que se espera alcançar.
Como casos típicos de especificações para processo de sof-
tware, citamos os modelos Personal Software Process (PSP) e
Team Software Process (TSP), ambos de autoria do Software
Engineering Institute (www.sei.cmu.edu).
Nota do DevMan
Externalizar o conhecimento: Nonaka e Takeuchi explicam no seu livro “criação
de conhecimento na empresa: como as empresas japonesas geram a dinâmica da
inovação”, que a criação do conhecimento organizacional é uma interação contínua e
dinâmica entre o conhecimento tácito e o conhecimento explícito.Tal interação é mol-
dada pelas mudanças entre diferentes modos de conversão, que são a socialização, a
externalização, a internalização e a combinação. Dentre os quatro modelos de conver-
são do conhecimento, a externalização é a chave para a criação do conhecimento, pois
elabora conceitos novos e explícitos a partir do conhecimento tácito.
Edição 21 - Engenharia de Software Magazine 39
 Há uma imensa diversidade de modelos para processos de
software, não se considerando a existência de um processo
ideal para todos os produtores. Numa concepção atual da En-
genharia de Software, disciplina que prioriza em seu estudo
a criação, implantação e manutenção do processo de desen-
volvimento de software, aplicam-se tais modelos para que o
Engenheiro, conhecendo as demandas do produtor, adapte
estas técnicas para criar o modelo ideal a ser ali utilizado, de
acordo com as especificidades de cada produtor.
Diante de tal fato, pode-se afirmar que as organizações desen-
volveram abordagens diferentes para o processo de software.
O desenvolvimento de software sofre mudanças rápidas. Este
tipo de negócio se utiliza do conhecimento intensivo e envolve
muitas pessoas trabalhando em diferentes fases ou atividades.
São diversos os conhecimentos encontrados nas empresas
desenvolvedoras, porém, existem problemas para identificar
o conteúdo, localização e o uso deste conhecimento. O uso
apurado deste conhecimento é uma motivação básica para
conduzir a gestão do conhecimento nas empresas desenvol-
vedoras, merecendo uma análise profunda.
No desenvolvimento de software, cada pessoa envolvida
toma decisões técnicas ou administrativas, muitas delas
pontuais ou eventuais, diante de situações inéditas. Membros
do time de desenvolvimento tomam decisões baseadas no
conhecimento pessoal, experiências ou conhecimento obtido
usando contatos informais. Isso é possível em empresas me-
nores, com um potencial caótico em empresas maiores, con-
duzindo a conflitos e imprecisões nos trabalhos de produção
do software. Porém, em empresas que lidam com um grande
número de informações, este processo torna-se ineficiente.
Grandes organizações não podem confiar na participação
informal do conhecimento pessoal dos funcionários, bem
como em situações temporárias em que estes funcionários
eventualmente atuem, refletindo-se tais situações em im-
provisos, informalidades que não podem ser adotadas como
comportamentos organizacionais padronizados. Tal situação
é frequentemente referenciada na literatura da Engenharia
de Software ao afirmar que processos não estruturados de-
pendem de atuações “salvadoras” de gerentes e especialistas
(bons programadores, analistas que dominem o contexto da
aplicação, gerentes que conseguem improvisar com sucesso),
eventos que não trazem em si garantia nenhuma que poderão
ser repetidos em novos projetos.
O conhecimento individual, sobre técnicas, processo, métodos,
infraestrutura, bases e gerenciamento, principalmente, precisa ser
compartilhado. Desta forma, os processos de compartilhamento
do conhecimento precisam ser perfeitamente definidos.
Vantagem Competitiva
Entende-se a vantagem competitiva como uma diferença
positiva que um determinado competidor apresenta, em um
segmento, sobre seus concorrentes, percebido pelos clientes
daquele segmento. O software oferece inúmeras situações de
potencial construção da vantagem competitiva, indo desde
a melhora ou customização do atendimento, passando pelo
40 Engenharia de Software Magazine - Organização Fábrica de Experiência
aprimoramento na oferta de produtos e serviços que sejam
diferenciados aos olhos dos consumidores. Destaca-se aqui
também a diferenciação, e consequente vantagem, nas formas
de oferta, como bons serviços de comércio eletrônico.
Analisando o contexto do processo de desenvolvimento de
software, da gestão do conhecimento e a construção da vanta-
gem competitiva, pode-se afirmar que, no desenvolvimento de
software, inúmeros documentos são elaborados. Dessa forma,
o conhecimento produzido deve ser retido e disponibilizado
para o time de desenvolvimento, possibilitando o reuso em
projetos futuros. Para tanto, o conhecimento individual neces-
sita ser explicitamente capturado, oferecendo a oportunidade
para o aprendizado de outros.
A busca por posições estratégicas que combinem ou superem
as existentes nas organizações é um grande desafio que as
empresas enfrentam, e norteará a direção futura delas, tanto
para o sucesso, quanto para o fracasso.
A empresa é um conjunto de recursos cuja utilização é orga-
nizada por um quadro de referência administrativo, tornando
os produtos finais da organização representantes das possibi-
lidades pelas quais se pode utilizar seu conjunto de recursos
para desenvolver suas potencialidades básicas.
Definimos recursos como todos os ativos, processos organi-
zacionais, atributos, informação, conhecimento, etc., controla-
dos pelas organizações, que as tornam capazes de conceber e
implementar estratégias que melhorem sua eficiência e eficácia.
As organizações não podem ser consideradas idênticas, bem
como os recursos reais são heterogêneos (originais) e imóveis
(não são adquiríveis). É aqui que o software, como afirmamos
antes, pode se constituir num diferenciador potencial, produ-
zindo vantagem competitiva.
Tipos de conhecimento e a aplicação para produção de
software
Dentre os conhecimentos típicos que são encontrados
num ambiente de desenvolvimento de software, podemos
exemplificar:
• Os métodos de cálculos de estimativas de prazos e custos
financeiros;
• Especificações técnicas de modelagem de programas, lógicas
e relacionamentos entre módulos;
• Métodos de planejamento de atividades, de delegação de
controle e tarefas durante a produção de software, como os
de testes;
• Formulários e artefatos variados, como definições de layout
para repositórios de requisitos;
Nota do DevMan
Processos organizacionais: procurando estruturar-se em processos, as or-
ganizações terão maior eficiência na obtenção de produtos e serviços e estarão
mais preparadas para mudanças, com melhor integração de seus esforços e maior
capacidade de aprendizado.

• Melhores práticas de processos e projetos, a serem aplicadas
sucessivamente na formulação de novos produtos.
Algumas das áreas do conhecimento e das necessidades
relativas às organizações são:
• Adquirir conhecimento sobre novas tecnologias: novas
tecnologias podem ser bastante eficientes para o desenvol-
vimento de software, mas tornam-se pesadelos para os ge-
rentes de projeto. É difícil para os desenvolvedores ficarem
aptos com as novas tecnologias e, para os gerentes, entende-
rem seus impactos e estimar os novos custos. Tecnologias
não muito familiares fazem uso intensivo do “aprender
fazendo”, que pode trazer retardo nos resultados;
• Conhecimento de acesso do domínio: o desenvolvimento
de software necessita de acesso ao conhecimento não apenas
do seu domínio e em novas tecnologias, mas também sobre o
domínio para o qual o software está sendo desenvolvido;
• Compartilhamento do conhecimento das práticas e políti-
cas locais: os conhecimentos são passados, entre desenvolve-
dores experientes e os com pouca experiência, em encontros
informais; com isso, nem todos têm acesso. Esta prática deve
ser estimulada, mas a captura e compartilhamento formal
do conhecimento asseguram que todos os funcionários
terão acesso a ele.
As organizações devem analisar os projetos do passa-
do para melhorar as habilidades no desenvolvimento.
Isto requer conhecimentos extensivos baseados nas mais
diferentes experiências no desenvolvimento, bem como
insights. Padrões, melhores práticas, modelos e recomen-
dações são exemplos de resultados destas atividades do
conhecimento.
A organização Fábrica de Experiência (OFE)
O modelo desenvolvido denominado organização fábrica
de experiência, conforme mostrado na (Figura 1), possui
duas organizações perfeitamente integradas. Uma equipe
específica é destinada à finalidade de externalizar o conhe-
cimento dos próprios desenvolvedores. Este processo tem
como objetivo obter melhores resultados no desenvolvimen-
to de software – custos, qualidade e prazos – por meio da
alavancagem de experiências de projetos anteriores.
Nota do DevMan
Estratégia: Não existe uma definição única e universalmente aceita para estraté-
gia. Inicialmente deu-se ênfase especial ao uso militar do termo estratégia, originada
das mais antigas literaturas do mundo. Strategos referia-se ao papel de um general
no comando de um exército, passando posteriormente a ser a arte de habilidades
psicológicas e comportamentais com as quais exercia esse seu papel. Uma estratégia
bem formulada ajuda a ordenar e alocar os recursos de uma organização para uma
postura singular e viável. Diversos autores relacionam o conceito de estratégia em
uma série de pontos de vista, como plano, padrão, posição e perspectiva.
engenharia de soft ware
Figura 1. Arquitetura da solução – Victor Basili – adaptada pelos autores
Com cronogramas, expectativas quanto à qualidade e pro-
dutividade e desafios técnicos, muitos projetos não podem
dedicar recursos suficientes para explicitar o conhecimento.
Porém, isto fica por conta da equipe chamada fábrica de
experiência. Esta equipe está encarregada de analisar e
sintetizar todos os tipos de experiência, incluindo as lições
aprendidas, dados de projetos e relatórios que explicitam
estas experiências mediante a criação de repositórios.
A OFE agrega valor ao conhecimento, mediante a criação
de modelos baseados em documentos ou em indivíduos.
Externalização e internalização são integradas, de modo
que a equipe do projeto trabalhe em harmonia com a OFE.
Implantar o conceito de OFE requer mudanças culturais
nas organizações, devido à criação de equipes e processos
distintos de trabalho. O que é mais essencial na OFE não é
a experiência, mas os novos conhecimentos gerados a partir
da experiência. As OFE precisam empacotar a experiência,
por meio da análise, síntese e avaliação da experiência
bruta, e construir modelos que representam a abstração
dessas experiências.
A aprendizagem organizacional é o know-how incorpo-
rado, resultante da capacidade de absorção, bem como da
receptividade da empresa a uma nova tecnologia. Cada
organização tem sua capacidade e habilidade de aprender a
partir de outras organizações. A capacidade em absorver o
conhecimento vem da habilidade em reconhecer os valores
novos, externos, e assimilar e aplicar em fins comerciais.
Quanto mais a organização conhece sua tecnologia, mais
fácil torna-se o aprendizado.
A Gestão do Conhecimento na Engenharia de
Software
As organizações podem aplicar a gestão do conhecimento
para fornecer soluções nos seus negócios. Para evitar erros
e retrabalho, para diminuir tempo e custos de desenvolvi-
mento e aumentar a qualidade, as empresas desenvolvedoras
Edição 21 - Engenharia de Software Magazine 41
necessitam aplicar, nos futuros projetos, o conhecimento
obtido em projetos anteriores. Infelizmente, a realidade
é que o time de desenvolvimento não se beneficia das ex-
periências anteriores e repete os mesmos erros cometidos,
embora alguns desenvolvedores saibam como evitá-los. O
ganho individual e da organização poderia ser maior se o
conhecimento fosse compartilhado.
As atividades da gestão do conhecimento que suportam o
desenvolvimento de software são:
• Gestão de documentos: muitos documentos, processos
e atividades são envolvidos na engenharia de software.
Estes documentos são freqüentemente criados, revisados e
utilizados. Existem diversas ferramentas para a gestão de
documentos;
• Gestão de competência: ou gestão de habilidades; quem
sabe o quê – uso do conhecimento não documentado;
• Reuso de software: programadores não se cansam de imple-
mentar a mesma solução; o reuso é para evitar o retrabalho;
incentivo ao repositório de reuso. Somente será desenvolvido
algo novo caso não se encontre nada para reusar;
• Aprender com experiências necessita de um suporte à me-
mória do produto e do projeto. As práticas da engenharia de
software que ajudam a construir memórias são: controle de
versão, gestão de modificações, documentação de padrões
e rastreabilidade de requisitos. Em todas estas práticas, a
retenção do conhecimento é altamente indicada.
Implementando a gestão do conhecimento na
Engenharia de Software
Para implementar a gestão do conhecimento na engenharia
de software, muitos desafios e obstáculos estão presentes.
Três questões são particularmente importantes:
• Questão tecnológica: A tecnologia de software su-
porta a gestão do conhecimento? É possível integrar
todas as ferramentas para alcançar o nível planejado de
compartilhamento?
• Questão organizacional: É um erro focar somente na
tecnologia e esquecer a metodologia. É um risco cair na
cilada tecnológica sem um planejamento adequado para a
implementação da gestão do conhecimento;
• Assuntos individuais: Funcionários frequentemente não
têm tempo de entrar ou procurar por conhecimento, ou não
desejam disponibilizar seus conhecimentos. E não querem
reusar conhecimentos dos outros.
Uma análise das características da gestão do conheci-
mento revela que muitas organizações que falharam não
Nota do DevMan
Insights: Uma visão que se manifesta de repente, como a compreensão de como
resolver um problema difícil. O termo foi cunhado pelo psicólogo alemão e teórico
linguista Karl Bühler.
42 Engenharia de Software Magazine - Organização Fábrica de Experiência
determinaram seus objetivos e estratégias antes de imple-
mentar sistemas de gestão do conhecimento, não tendo
uma boa preparação do método ou processo da gestão do
conhecimento. É necessário despender um tempo antes de
os benefícios da gestão do conhecimento aparecerem.
Algumas culturas organizacionais incentivam o indivi-
dualismo e limitam o trabalho cooperativo. A falta de uma
cultura do conhecimento tem sido citada como um obstáculo
para o sucesso da gestão do conhecimento. Se a organização
não incentiva a cultura de compartilhamento, o funcionário
se sente dono do seu conhecimento. Os funcionários não
se sentem à vontade com as suas experiências negativas e
lições aprendidas por falhas, temendo que as informações
fornecidas possam ser usadas contra eles.
Conclusão
As organizações não devem apenas encorajar os funcio-
nários, mas recompensá-los por compartilhar seus conheci-
mentos, procurar por conhecimentos e usá-los. A vantagem
da experiência ou do conhecimento explícito é que pode ser
armazenado, organizado e disseminado para terceiros, sem
o envolvimento de quem o originou. Para alcançar vanta-
gem máxima do compartilhamento, as empresas deveriam
encorajar os funcionários a documentar e armazenar seus
conhecimentos em um repositório. As comunidades são
bons exemplos de compartilhamento de conhecimento. Elas
se formam de modo relativamente fácil.
As organizações se esforçam para aprender e aumentar suas
expertises mediante as entradas vindas de fora da organização.
Projetos em empresas de desenvolvimento de software cujo ob-
jetivo é construir uma base de conhecimento incluem um centro
para estas bases, assim como o acúmulo de modelos empíricos
para serem utilizados na validação de novos projetos.
A maioria do conhecimento das empresas de software não
é explícito. O tempo é curto para tornar o conhecimento
explícito, e existem poucas ferramentas para transformar o
conhecimento tácito em explícito. Porém, os artefatos do de-
senvolvimento de software se encontram em formato eletrôni-
co, possibilitando o uso de ferramentas de TI para a retenção,
e facilitando o compartilhamento e a disseminação.
Links
Artigo “A Reference Architecture for the Component Factory”
http://www.lib.umd.edu/drum/bitstream/1903/7521/1/A%20Reference%20Architecture.pdf
Artigo “Knowledge Management in Software Engineering”
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1003450
Dê seu feedback sobre esta edição! eu
Feedback
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
Dê seu voto sobre este artigo, através do link:
edição
www.devmedia.com.br/esmag/feedback
Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
Customização e Integração de Ferramentas Open-Source
Uso de ferramentas integradas para melhoria de processo e aumento de produtividade
Andrea Pinto
andrea.pinto@cesar.org.br
É graduada em Ciência da Computação
pela UFPE e mestra em Ciências da Com-
putação pela UFPE na área de Engenharia
de Requisitos. Com 9 anos de experiência
na área de desenvolvimento de software,
atualmente é Engenheira de Qualidade de
software do C.E.S.A.R. Possui experiência
na definição e implantação de processos de
garantia da qualidade aderentes ao CMMI
e em avaliação SCAMPI, tendo participado
da avaliação Classe A CMMI 3 do C.E.S.A.R.
Ministra aulas de Garantia da Qualidade de
Software na faculdade Unibratec e orienta
alunos em monografias para essa área.Tem
interesse principalmente nas áreas de ga-
rantia de qualidade, modelos de qualidade,
requisitos e metodologias ágeis.
Gustavo Carvalho
gustavo.carvalho@cesar.org.br
É graduado em Ciência da Computação
pelo UNIPE e especialista em Engenharia de
Software pela FBV/Qualiti. Com 8 anos de
experiência na área de desenvolvimento de
software, atualmente é Engenheiro de Confi-
guração do C.E.S.A.R, além de ministrar aulas
de Programação Orientada a Objetos, Estrutu-
ra de Dados e Teoria Geral dos Sistemas na Fa-
culdade Joaquim Nabuco. Possui experiência
em desenvolvimento de software, elicitação
de requisitos e na definição e implantação
de processos de gerência de configuração
aderentes ao CMMI.
Felipe Furtado
felipe.furtado@cesar.org.br
É graduado em Engenharia Mecânica pela
UFPE, especialista em Tecnologias da Infor-
mação pelo Centro de Informática da UFPE e
mestre em Ciência da Computação na área de
produtividade de software também pela UFPE.
Com 13 anos na área de desenvolvimento de
software, atualmente é coordenador da garan-
tia da qualidade de software e do SEPG (Sof-
tware Engineering Process Group), liderando
também a melhoria dos processos das áreas de
gestão de projetos no C.E.S.A.R.
Ryan Albuquerque
ryan@cesar.org.br
É graduado em Ciência da Computação pela UFC
e mestre em Ciências da Computação pela UFPE
na área de Inteligência Artificial. Com 10 anos
de experiência na área de desenvolvimento de
software, 7 deles como Engenheiro de Configu-
ração de Software. Atualmente é Engenheiro de
Sistemas do C.E.S.A.R. Possui experiência na defi-
nição e implantação de processos de Gerência de
Configuração aderentes ao CMMI e em avaliação
SCAMPI, tendo participado da avaliação Classe A
CMMI 2 e 3 do C.E.S.A.R.
A
s organizações de desenvolvi-
mento de software têm buscado
diversas formas para melhoria
de seus processos com o objetivo de au-
mentar a produtividade das equipes de
desenvolvimento. Uma forma de obter
Edição 21 - Engenharia de Software Magazine
De que se trata o artigo?
Este artigo relata a experiência de uma Organização
CMMI (Capability Maturity Model Integration), nível
3, na customização e integração de ferramentas open-
source para melhoria de processo e aumento da produ-
tividade das equipes de desenvolvimento de software.
Para que serve?
A utilização de ferramentas desta natureza é útil para
as Organizações que possuem um ambiente de me-
lhoria dos processos de software e tem a necessidade
de adotar ferramentas de baixo custo e de forma in-
tegrada. Tais ferramentas darão suporte ao processo
institucional com uma maior agilidade pelas equipes
de desenvolvimento de software.
Em que situação o tema é útil?
Em ambientes que necessitam integrar ferramentas de
apoio ao processo organizacional de forma produtiva e
consistente. Especificamente em processos relaciona-
dos com gerenciamento de mudanças, gerenciamento
de testes, gerenciamento de requisitos e revisão de
artefatos (código ou documentos).
ganhos significativos de produtividade
requer iniciativas integradas em diver-
sas áreas, por exemplo, melhoria em
ferramentas, metodologia, ambiente de
43
trabalho, gerenciamento, reuso, dentre outros fatores [Bohem
et AL, 1982].
Por outro lado, a inclusão de ferramentas em um projeto nem
sempre está associada a ganho de produtividade. Isso irá depen-
der, dentre outros fatores, do tamanho da equipe e da maturidade
do processo de desenvolvimento [Bruckhaus et AL, 1996].
Neste contexto, a Organização aqui apresentada estabele-
ceu dois principais objetivos em seu programa de melhoria
contínua:
• Seleção de ferramentas free e open source que propiciem au-
mento da produtividade das equipes de desenvolvimento de
software de forma controlada, gerenciada e com baixo custo;
• Customização das ferramentas selecionadas considerando o
processo definido na organização com o objetivo de aumentar
a maturidade do processo de desenvolvimento de software,
obter ganhos na produtividade das equipes e na qualidade
dos produtos gerados.
A Organização Estudada
O C.E.S.A.R – Centro de Estudos e Sistemas Avançados do
Recife – é um instituto privado de inovação que cria produtos,
processos, serviços e empresas usando Tecnologia da Infor-
mação e Comunicação (TIC), atuando há mais de 10 anos em
âmbito nacional e internacional.
O C.E.S.A.R faz parte do Porto Digital, ambiente de em-
preendedorismo, inovação e negócios de TIC do estado de
Pernambuco que reúne mais de 100 empresas no pólo do
Bairro do Recife.
Desde sua inauguração, a instituição recebeu reconhecimen-
tos na área de TIC, entre eles: o Prêmio Info200 de Melhor
empresa de serviços de software, o prêmio FINEP de mais
inovadora instituição de pesquisa do Brasil, a escolha da ins-
tituição como exemplo de criação de negócios pelo World Eco-
nomic Fórum e uma menção honrosa no Stockholm Challenge.
Além do prêmio que a Revista Época Negócios concedeu ao
C.E.S.A.R com o título de um dos Modelos de Negócios mais
Inovadores do Brasil, em 2009.
Em junho/2003, o C.E.S.A.R alcançou o nível 2 de maturi-
dade do modelo SW-CMM [Paulk et AL 1999] na vertical de
telecomunicações, e em Novembro/2007 atingiu o nível 3 de
maturidade do modelo CMMI-DEV, versão 1.2 [SEI 2006].
Atualmente, utiliza metodologias ágeis em conjunto com o
modelo de maturidade.
Processo de Seleção das Ferramentas
A estratégia de seleção das ferramentas iniciou com um levan-
tamento dos requisitos necessários levando em consideração
as necessidades do processo e projetos da organização. Nesta
primeira etapa, o grupo envolvido analisou os processos que
estavam diretamente relacionados com a equipe de engenharia
de software e que demandavam um esforço significativo em
passos que poderiam ser automatizados e/ou integrados. Como
resultado desta análise, quatro processos foram selecionados:
Gerenciamento de Requisitos, Gerenciamento de Mudanças,
Gerenciamento de Testes e Revisão de Artefatos.
44 Engenharia de Software Magazine - Customização e Integração de Ferramentas Open-Source
Em seguida, foi realizada uma pesquisa e análise de ferra-
mentas disponíveis no mercado levando em consideração as
necessidades anteriormente identificadas em cada um dos
processos selecionados. Como resultado desta pesquisa, um
processo de tomada de decisão foi realizado para identificar
quais ferramentas seriam adquiridas e adaptadas à realidade
da organização. Os principais requisitos estavam relacionados
com o baixo custo necessário para aquisição e com a possi-
bilidade de customização e integração das ferramentas para
que elas, de fato, se adaptassem ao processo organizacional.
Portanto, foi dada preferência na seleção de ferramentas open
source e as escolhidas foram: Mantis e Salomé.
Originalmente, o Mantis foi concebido como uma ferramenta
para bug tracking. Porém, pela sua flexibilidade e facilidade
de customização, também foi utilizada para gerenciamento de
mudanças, gerenciamento de requisitos e revisão de artefatos.
A Salomé, por sua vez, foi concebida como uma ferramenta de
gerenciamento de testes e foi customizada para atender ao pro-
cesso de gerenciamento de testes da organização estudada.
A seguir, será brevemente descrito cada uma das ferramentas
utilizadas.
Mantis Bug Tracker – Gerenciamento de Mudanças
O Mantis é uma ferramenta de gerenciamento de bugs
baseado na web. É um dos mais populares sistemas de bug
tracker do mundo, sendo open-source, sob os termos da GNU
General Public License (GPL), estando livre para ser usado e
modificado.
O Mantis é desenvolvido em PHP, com suporte a banco de da-
dos, incluindo o MySQL, MS SQL, PostgreSQL e DB2, podendo
rodar em qualquer sistema operacional que seja suportado pelo
PHP. Ele foi projetado para ser facilmente modificável, perso-
nalizável e atualizável. Esse foi um dos motivos que pesou na
escolha da ferramenta de gerenciamento de mudanças.
As customizações no Mantis começaram a surgir a partir
da necessidade de padronização na abertura das CR´s (Change
Requests) ou Requisições de Mudança. O formulário das CR’s
possui vários campos, mas em alguns deles não era clara a for-
ma de preenchimento. Em especial os campos descritivos (e.g.
descrição da requisição de mudança e passos para reprodução)
poderiam ser escritos com texto livre, fazendo assim com que
a falta de informações importantes ou falhas de interpretação
acontecessem com certa freqüência.
Para minimizar esse tipo de situação, foi criado um modelo
em XML que descrevia de forma mais estruturada as informa-
ções importantes de cada campo. Foi dada uma opção para o
relator da CR incluir o modelo no campo a ser editado e o mes-
mo poderia preencher as informações nos campos delimitados
pelas tags XML. A utilização desse modelo ajudou também na
formatação das informações e no processo de automação de
checagens em auditorias, pois as informações estavam mais
estruturadas, e não mais em texto livre.
No processo interno, as CR´s poderiam ser de diversos ti-
pos: Defeitos de Código, Defeitos de Documento, Mudanças,
Tarefas, Requisições de Baseline e Requisições de Release, e,

para cada tipo, os campos obrigatórios relativos ao processo
eram diferentes, o que acarretava em um enorme tempo con-
sumido para o Engenheiro de Configuração verificar cada CR.
Neste sentido, o código fonte do Mantis foi alterado para que
a visualização e obrigatoriedade de alguns campos fossem
dependentes do valor de um campo novo chamado “Tipo”,
que listava os tipos de requisições possíveis no processo da
organização. Além disso, a máquina de estados padrão tam-
bém foi reformulada para se adaptar a esse novo contexto,
como ilustrado na Figura 1.
Figura 1. Máquina de Estados do Mantis
A integração dos sistemas de controle de versão (CVS e
Subversion) com o Mantis tem sido de enorme utilização
por parte dos projetos. Através dela, todos os comentários
dos commits realizados via CVS/Subversion são registrados
automaticamente na respectiva CR que está sendo resolvida.
Com a integração, consegue-se garantir um rastreamento bi-
direcional entre CR’s e artefatos:
• Identificação a partir do Mantis de todos os artefatos (seus
branches, revisões e responsáveis) alterados para resolver cada
requisição de mudança;
• Identificação a partir dos comentários dos commits de todas
as CR’s que ocasionaram as mudanças.
Ainda foram implementadas integrações do Mantis com os
outros sistemas descritos neste documento: Rev.I.S.E e ITReq. A
partir da tela de visualização de cada CR é possível acessar suas
respectivas revisões e requisitos impactados pela mudança.
Rev.I.S.E – Revision Infrastructure for Software
Engineering
A ferramenta Rev.I.S.E foi idealizada, principalmente, para
substituir as planilhas de revisão contendo as informações
das revisões formais realizadas e que eram armazenadas no
processo
repositório dos projetos. Para que os membros da equipe se-
guissem o processo definido de revisão formal utilizando pla-
nilhas fazia-se necessário realizar um conjunto de atividades
meramente operacionais como: recuperar o último template
da planilha no site do processo organizacional, renomear o
arquivo de acordo com as regras de gerência de configuração
para o projeto, preencher a planilha com os dados da revisão
e incluir a planilha no repositório. Havia também uma grande
dificuldade de se auditar o processo de revisão, visto que se
fazia necessário abrir cada planilha para checagem das infor-
mações. Tudo isso tornava a execução do processo de revisão
custoso para a equipe, para o projeto e para a empresa devido
ao esforço envolvido. O processo era ainda propício a erros
em cada um dos passos descritos, visto que todos eles eram
realizados manualmente.
Inicialmente, para resolver o problema de forma mais rápida,
pensou-se numa solução para coleta de informações das pró-
prias planilhas automaticamente. Uma aplicação consultava
determinadas células das planilhas, gerava uma página web
consolidando as informações e realizava a maioria das checa-
gens de consistências. Mas, essa solução tinha a desvantagem
de se basear num modelo fixo de planilha. Toda vez que o
modelo mudava, a aplicação teria que ser adaptada.
Devido a essas dificuldades, o SEPG (Software Engineering
Process Group) propôs o uso de uma ferramenta web que
automatizasse todas essas atividades, agilizando a criação,
o preenchimento e o acesso aos dados entre os participantes
do processo de revisão formal. Foram feitas pesquisas, mas
nenhuma solução gratuita foi encontrada para suprir as ne-
cessidades da organização e, por isso, resolveu-se construir
uma ferramenta.
Em uma análise prévia dos requisitos básicos e imediatos
para a ferramenta, foi identificado que o Mantis, ferramenta
para gerenciamento de mudanças já largamente utilizado na
organização, supriria a maioria deles: suporte de projetos,
controle de acesso de usuários, máquina de estados e campos
customizáveis. Assim, decidiu-se utilizar o Mantis como base
Nota do DevMan
CMMI (Capability Maturity Model Integration): é um framework que des-
creve princípios e práticas relacionadas ao processo de desenvolvimento de produ-
tos e serviços tecnológicos. O modelo visa ajudar organizações envolvidas com o
desenvolvimento de software a melhorar a capacidade de seus processos por meio
de um caminho evolucionário, com resultados mais previsíveis e com possibilidade
de melhoria contínua. [SEI, 2006].
CR (Change Request): Solicitações de Mudança em um artefato.
CVS (Concurrent Version System) e SVN (SubVersion): são sistemas de con-
trole de versão que permitem que se trabalhe com diversas versões de arquivos
organizados em um diretório e localizados local ou remotamente, mantendo-se
suas versões antigas e os logs de quem e quando manipulou os arquivos.
Edição 21 - Engenharia de Software Magazine 45
para todo o desenvolvimento, batizando a nova ferramenta
de Rev.I.S.E.
Durante o desenvolvimento houve a preocupação de disponi-
bilizar um ambiente amigável e fácil de usar para inclusão das
não-conformidades e os dados das revisões. Assim, decidiu-se
usar algum framework com componentes Ajax/DHTML para
que os dados fossem postados facilmente com edições inline
de tabelas. Neste intuito, escolheu-se o framework Ext.JS.
A máquina de estados do Rev.I.S.E também foi reformulada
de acordo com a Figura 2.
Figura 2. Máquina de estados do Rev.I.S.E
Dependendo do papel na revisão do usuário autenticado no
sistema, e do estado da revisão, alguns campos são habilitados
ou desabilitados, conforme as responsabilidades descritas na
Tabela 1.
Algumas automações foram feitas na ferramenta para que
os esforços com as checagens em auditorias pudessem ser
diminuídos, entre elas:
• Checagem das transições de estados específicas por papel;
• Verificação da consistência dos papéis por tipo de revisão;
• Verificação e validação de campos obrigatórios;
• Envio automático do convite por e-mail aos envolvidos na
revisão;
• Integração com a ferramenta de controle de mudanças
(Mantis);
• Seleção automática do checklist de auditorias definido no
processo da organização;
• Acompanhamento do estado da revisão por e-mail;
46 Engenharia de Software Magazine - Customização e Integração de Ferramentas Open-Source
• Verificação de métricas de tempo planejado versus o
realizado.
Papel Responsabilidades
Autor Criar e/ou atualizar o artefato a ser revisado;
Planejar a revisão;
Definir os papéis e responsabilidades da equipe de revisão;
Agendar a reunião de revisão;
Realizar o retrabalho após a revisão, garantindo que todos os pontos
levantados tenham sido corretamente analisados e resolvidos.
Moderador Determinar quando a revisão estará completa e indicar, caso necessário,
uma nova revisão;
Analisar se o retrabalho foi realizado conforme descrito no Rev.I.S.E;
Realizar o fechamento da revisão.
Redator Cadastrar os findings na ferramenta.
Revisor Revisar os artefatos.
Leitor Apresentar o artefato aos participantes ao longo da reunião. Obs: o papel do
Leitor só existe para técnicas que realizam reunião de revisão.
Tabela 1. Papéis e Responsabilidades
ITReq - Infrastructure to Track Requirements
A ferramenta para Desenvolvimento e Gerenciamento de
Requisitos (ITReq) trata-se de uma customização da ferramen-
ta de Gerência de Mudanças, o Mantis. O layout de algumas
funcionalidades é idêntico à ferramenta original, como o me-
canismo de busca e a visão inicial dos requisitos, organizada
pelo estado no qual o requisito se encontra.
O requisito é criado no ITReq da mesma forma que uma CR
é registrada no Mantis. Para isto, os campos relacionados a
um requisito tiveram seus nomes reeditados para se adequar
aos termos normalmente utilizados no gerenciamento de
requisitos. A máquina de estados também foi adaptada de
acordo com a Figura 3.
Cada requisito cadastrado no ITReq é identificado uni-
camente e tratado de forma independente dos demais
requisitos, com suas prioridades e estados. Além do identi-
ficador único, cada requisito possui Nome, Descrição, Tipo
(requisito funcional, requisito não funcional, caso de uso
ou restrição) e Prioridade. O campo Descrição é livre, sendo
possível ser utilizado para descrever um requisito funcional
Nota do DevMan
Ext.JS: é um framework javascript com uma extensão rica em funcionalidades e
componentes de interface gráfica com o usuário.
Findings: São os erros, problemas, lapsos, oportunidades de melhoria ou pontos
de investigação identificados durante o processo de revisão de artefatos.
GNU GPL (General Public License): é a designação da licença para software
livre idealizada por Richard Stallman no final da década de 1980, no âmbito do pro-
jeto GNU da Free Software Foundation (FSF). A GPL é a licença com maior utilização
por parte de projetos de software livre.
 processo

de forma textual, ou um caso de uso com pré-condição,

atores, passos e pós-condições. Nota do DevMan
PHP (PHP: Hypertext Preprocessor): é uma linguagem de programação in-
terpretada, livre e muito utilizada para gerar conteúdo dinâmico na Web.

SEPG (Software Engineering Process Group): grupo estabelecido e desig-

nado como responsável pela definição, manutenção e melhoria do processo de
engenharia de software [SEI 2006].

executado. Para cada ciclo, o usuário seleciona as suítes de

testes (conjunto de casos de testes) que serão executados e
reporta o resultado da execução (Figura 5).

Figura 3. Máquina de Estados do ITReq

A máquina de estados do ITReq (Figura 3) está diretamente Figura 4. Ferramenta ITReq: armazenamento das versões, histórico de
versões e os requisitos relacionados
relacionada ao processo de revisão e aprovação definido na
organização. O tratamento individual de requisitos através da
máquina de estados trouxe também um ganho não planejado
para os projetos: maior agilidade no processo de revisão de
requisitos, visto que os requisitos podem ser revisados indi-
vidualmente, o que não poderia ser feito facilmente com o uso
de documentos.
Outra funcionalidade essencial é o controle das alterações
de documentos com o uso de um histórico de revisões e com
o armazenamento, tornando possível a comparação com
outras versões de documentos (Figura 4).
A ferramenta gera o documento de requisitos em formato
HTML seguindo o template definido no processo organiza-
cional com seções para descrição do projeto, aprovadores,
glossário, histórico de revisões, referências e requisitos
agrupados em seções definidas pelo usuário.

Salomé – Gerenciamento de Testes

Diferentemente das ferramentas descritas até agora, Sa-
lomé TMF (Test Management Framework) é uma ferramenta
independente, isto é, não foi construída a partir do Mantis.
É uma ferramenta open-source que foi melhorada e adaptada
ao processo de testes organizacional, bem como, integrada
à ferramenta ITReq anteriormente descrita.
Nela pode-se especificar os casos de testes para cada requi-
sito cadastrado no ITReq, bem como registrar os resultados
da execução dos casos de testes para cada ciclo de testes Figura 5. Ferramenta Salomé

Edição 21 - Engenharia de Software Magazine 47

 Salomé-TMF é também compatível com JUnit, Abbot e Be-
anshell, sendo possível a definição de testes automáticos.
Integração entre as Ferramentas
Todas as ferramentas descritas possuem alguma integração
entre si. ITReq está integrada com Salomé, sendo possível
acessar os casos de testes de cada requisito a partir dessa
ferramenta, como mostra a Figura 6.
O Mantis possui integrações com o Rev.I.S.E, ITReq e Salo-
mé. A partir de uma CR de melhoria criada no Mantis, por
exemplo, pode-se acessar as revisões realizadas no projeto
para aquela melhoria (Figura 7) e vice-versa (Figura 8) e os
requisitos impactados por ela (Figura 9).
Desta forma, ao criar uma baseline no Mantis com suas
respectivas CR’s, é possível visualizar todos os requisitos
impactados e os respectivos casos de testes, facilitando a
identificação dos casos de testes que devem ser executados
devido à melhoria implementada no projeto.
Projeto Piloto e Institucionalização das
Ferramentas
Após a conclusão do processo de seleção das ferramentas,
foi dado início ao planejamento do projeto piloto para a
customização e testes das ferramentas selecionadas. As
seguintes fases podem ser destacadas:
• Planejamento e alocação dos recursos necessários para
implementação das melhorias e customizações com o su-
porte organizacional;
Figura 6. Ferramenta ITReq integrada com a Salomé
Figura 7. Integração do Mantis com o Rev.I.S.E
48 Engenharia de Software Magazine - Customização e Integração de Ferramentas Open-Source
• Implementação e testes dos requisitos de cada uma das
ferramentas;
• Planejamento de quais projetos em execução na organização
iriam adotar e avaliar as ferramentas;
• Execução dos projetos piloto com o apoio do SEPG (Software
Engineering Process Group) e Engenheiros de Qualidade e
Configuração alocados ao projeto;
• Coleta de resultados e de sugestão de melhorias nas ferra-
mentas após finalização do período do piloto.
Após a execução do projeto piloto, o primeiro passo foi
o envolvimento do SEPG na seleção e priorização das me-
lhorias que haviam sido propostas. Este grupo, formado
por especialistas em cada uma das áreas impactadas pelas
ferramentas, analisou e priorizou as melhorias solicitadas
para dar início à implementação das mudanças.
O grupo também precisou realizar um planejamento do
uso institucionalizado das ferramentas, isto é, como colocar
as ferramentas em uso em novos projetos. Essa ação incluía
também as alterações a serem realizadas no processo orga-
nizacional, como elaboração de guias e treinamentos para
uso das ferramentas customizadas e integradas.
Além das mudanças no processo, o SEPG passou a atuar
como facilitador na utilização das ferramentas pelos de-
mais projetos da organização.
Conclusões e Resultados Obtidos
A produtividade dos projetos aumentou notavelmente
com as customizações e integrações de todas as ferramentas
supracitadas. É possível ter uma maior rastreabilidade entre
as mudanças, um melhor controle do processo, além de agi-
lidade na hora da criação e manutenção das requisições de
mudança, requisitos do produto e revisões de artefatos.
Para se ter uma idéia da grande aceitação dessas ferra-
mentas na organização, faz-se necessário destacar alguns
números:
• Mantis: em uso por mais de 40 projetos;
• ITReq: em uso por mais de 20 projetos;
• Rev.I.S.E: em uso por 19 projetos, onde já foram realizados
mais de 2 mil revisões em código e documentos;
• Salomé: em uso por quatro projetos.
Antes de utilizar as ferramentas, os membros das equi-
pes passam por um treinamento organizacional para que
consigam utilizar melhor os recursos oferecidos por elas,
aumentando ainda mais sua produtividade.
As ferramentas estão em constante melhoria. As soli-
citações de melhoria podem ser realizadas por qualquer
pessoa dentro da organização através do próprio Mantis,
onde há um projeto específico para cada ferramenta para
reportagem de sugestões de melhoria, bem como de defeitos
encontrados.
Em relação aos ganhos deste processo de tomada de deci-
são e do uso das ferramentas, pode-se destacar os seguintes
aspectos:
 processo

Figura 8. Integração do Rev.I.S.E com o Mantis

Figura 9. Integração com o ITReq a partir do Mantis

• Quanto ao impacto, houve uma disseminação do uso de Referências

ferramentas open-source para melhoria de produtividade das
equipes de desenvolvimento;
• Quanto ao investimento, nota-se o baixo custo do projeto
que se restringiu ao esforço de alteração e manutenção nas
ferramentas, visto que se tratam de ferramentas open-source;
• Quanto à inovação, apesar do uso de ferramentas open-source
em projetos de desenvolvimento de software já ser algo conhe-
cido pela comunidade, foi possível, a partir de uma ferramenta
já institucionalizada na organização, realizar customizações
para atender outros processos relacionados, integrando-os e
automatizando seus passos.
Dê seu feedback sobre esta edição!
eu
s
Dê
Mantis (2009) “Ferramenta Mantis Bug Tracker”,http://www.mantisbt.org/
Salomé (2009) “Ferramenta para Gerenciamento de Testes”,https://wiki.ow2.org/salome-tmf/
Boehm,B et AL (1982).“The TRW Software Productivity System”.International Conference on Software
Engineering. IEEE Computer Society Press, Los Alamitos, CA. p. 148-156.
Bruckhaus, T. et AL (1996).“The Impact of Tools on Software Productivity”. IEEE Software v. 13, nº 5.
p. 29-38.
SEI (2006). “CMMI for Development, version 1.2, staged representation”. http://www.sei.cmu.edu/
pub/documents/06.reports/pdf/06tr008.pdf, CMU/SEI-2006-TR-008
Paulk et al (1999) “The Capability Maturity Model: Guidelines for Improving the Software Process”,
Addison-Wesley.
Feedback

A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e

Para isso, precisamos saber o que você, leitor, acha da revista!

s

ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback

Edição 21 - Engenharia de Software Magazine 49

Abordagens Tradicionais de Desenvolvimento
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
tradicionais de apoio ao desenvolvimento de projetos de software
Métricas de Software
Como utilizá-las no gerenciamento de projetos de software
Thamine Chaves de Abreu
thamine.abreu@gmail.com
Atualmente cursa especialização em De-
senvolvimento de Aplicações para Web no
Centro de Ensino Superior de Juiz de Fora
(CES/JF), Bacharel em Sistemas de Infor-
mação pela Universidade Severino Sombra
(USS), Desenvolvedor de Sistemas Web na
Granbery Consultoria Júnior em projeto
para a Fundação COPPETEC, possui expe-
riência de 4 anos em desenvolvimento de
sistemas Java (web/desktop).
Leonardo da Silva Mota
leonardo.smota@hotmail.com
Atualmente cursa especialização em De-
senvolvimento de Aplicações para Web no
Centro de Ensino Superior de Juiz de Fora
(CES/JF), Bacharel em Sistemas de Infor-
mação pela Universidade Severino Sombra
(USS), Desenvolvedor de Sistemas Web na
Granbery Consultoria Júnior em projeto
para a Fundação COPPETEC, programa-
dor certificado Java (SCJP), atuou como
professor assistente no curso de Sistemas
de Informação da USS e dos cursos de in-
formática da Fundação de Apoio a Escola
Técnica (FAETEC), possui experiência de
4 anos em desenvolvimento de sistemas
Java (web/desktop).
50 Engenharia de Software Magazine - Métricas de Software
Marco Antônio Pereira Araújo
maraujo@acessa.com
Doutor e Mestre em Engenharia de Sistemas
e Computação pela COPPE/UFRJ, Especialista
em Métodos Estatísticos Computacionais e
Bacharel em Matemática com Habilitação em
Informática pela UFJF, Professor dos cursos de
Bacharelado em Sistemas de Informação do
Centro de Ensino Superior de Juiz de Fora e
da Faculdade Metodista Granbery, Analista de
Sistemas da Prefeitura de Juiz de Fora e Editor
da Engenharia de Software Magazine.
A
garantia da qualidade é uma
das principais preocupações da
indústria de desenvolvimento
de software, pois atualmente a maior
parte das empresas atuantes no mercado
utiliza esse tipo de aplicação para gerir
seus negócios, produtos e relacionamen-
tos com clientes, necessitando maior
confiabilidade e qualidade. Existem
diversas medidas de garantia de qua-
lidade fundamentais para o sucesso de
qualquer tipo de aplicação de software,
De que se trata o artigo?
O artigo trata da utilização de métricas de software
no gerenciamento de projetos, sendo fortes aliadas
na estimativa, acompanhamento e apoio em toma-
da de decisões durante a construção de produtos de
software, visando uma melhor qualidade de todo
este processo.
Para que serve?
Métricas de software servem para apresentar medi-
das, preferencialmente quantitativas, que reflitam
características específicas de processos e de produtos
em construção, podendo ser utilizadas em diferentes
dimensões, como esforço, tamanho, complexidade,
dentre outras.
Em que situação o tema é útil?
A coleta adequada de métricas, com suas res-
pectivas análises, pode auxiliar o Engenheiro
de Software na tomada de decisões ao longo
do desenvolvimento de um projeto, visando a
melhoria da qualidade do processo e do produto
em construção.
dentre elas, uma das mais simples e
menos custosa, é a medição de software.
Nesse sentido, a medição de software
auxilia a tomada de decisão, pois através

de dados quantitativos, é capaz de informar que aspectos do
produto atendem ou não ao padrão de qualidade especificado,
além de permitir a avaliação dos benefícios de novos métodos
e ferramentas de engenharia de software, o entendimento e
aperfeiçoamento do processo de produção, a avaliação do
retorno do investimento e tornar o gerenciamento de projetos
baseado em fatos e não “achismos”, por exemplo.
Para medir software, são utilizadas diversas métricas que são
como tipos de medições aplicadas a um sistema de software,
documentação ou processo relacionado. Através dessas métri-
cas é possível determinar o esforço ou tempo para realização
de uma tarefa ou o tamanho do produto, por exemplo. Além
disso, as métricas de software são facilmente calculadas, en-
tendidas e testadas e independem do observador que as aplica,
sendo também uma boa fonte para estudos estatísticos acerca
do ciclo de vida do software.
Dentro desse contexto, este artigo tem por objetivo apresentar
algumas métricas de software e sua importância no processo
de desenvolvimento. Para isso, algumas métricas serão aplica-
das em pequenos exemplos, permitindo ao leitor compreender
e analisar seus benefícios imediatos.
Utilização de métricas
Existem dois tipos de métricas no contexto de desenvolvi-
mento de produtos de software: as métricas diretas, que são
realizadas em termos de atributos observáveis, como por
exemplo, esforço, tamanho e custo, e as métricas indiretas ou
derivadas, que podem ser obtidas através de outras métricas,
como por exemplo, complexidade, confiabilidade, e facilidade
de manutenção. Quanto ao contexto, podem ser aplicadas em
produtos ou em processos. Quando as métricas incidem dire-
tamente no produto de software, são chamadas de métricas de
predição, quando em processos de software, são comumente
chamadas de métricas de controle e sua aplicação normalmente
é realizada em processos já maduros e controlados.
Para obter resultados significativos, as métricas devem ser
aplicadas em um ciclo constante, que envolve as etapas de
planejamento, medição, análise de resultados, tomada de de-
cisão e implementação das decisões. Desta maneira, pode-se
construir uma base histórica do artefato medido que permitirá
ao engenheiro de software analisar que processos, ferramentas
e métodos melhor se aplicam àquele tipo de produto. Alguns
cuidados também devem ser tomados no processo de medição,
como o momento e a escolha do conjunto de métricas mais
relevantes a serem aplicadas, e a comparação entre produtos
através da aplicação de métricas (pois nenhum produto é igual
a outro). O escopo, os desenvolvedores e o ambiente são fatores
que podem influenciar o processo de desenvolvimento. Assim,
comparações devem ser cuidadosamente analisadas.
As métricas podem e devem ser aplicadas durante as fases
de desenvolvimento do software, o que garante ainda mais
seu impacto positivo no produto final.
Segundo alguns especialistas, para medir artefatos de softwa-
re através de métricas significativas, as medições devem ser
definidas de acordo com objetivos específicos. Nesse sentido, o
Gerência de Projetos
GQM (Goal/Question/Metric), desenvolvido por Basili em 1988, é
uma abordagem para aplicação de métricas afim de aprimorar
o processo de desenvolvimento de software (e, consequente-
mente, os produtos de software gerados) enquanto mantém
os objetivos de negócio e objetivos técnicos da organização
nivelados. É uma abordagem top-down que estabelece uma
medição sistemática para objetivos relacionados ao processo
de desenvolvimento, em que a equipe começa estabelecendo
os objetivos organizacionais, define metas de medição, insere
questões com o propósito de abordar os objetivos especifica-
dos e identifica as métricas que fornecem respostas para as
questões definidas.
O GQM define um modelo de três níveis, ilustrado na Figura 1.
Figura 1. Níveis do modelo do GQM
O GQM pode ser aplicado em todo o ciclo de vida de produ-
tos, processos e artefatos de software e é bem alinhado com
o ambiente organizacional, sendo um meio adequado para
conseguir dados confiáveis e conhecimento sobre as práticas
de software da organização para conduzir a melhoria do
processo. Nesse contexto, é útil para auxiliar na compreensão
e formar um baseline das práticas aplicadas no desenvolvi-
mento de software, evoluir as atividades de medição, guiar e
monitorar processos de software e reduzir custos de desen-
volvimento, por exemplo. O GQM pode ser utilizado também
como base de fundamentação para outras técnicas de medição
de software.
O GQM pode ser muito útil na definição de quais métricas
são necessárias de serem coletadas e analisadas para responder
questões sobre um determinado objetivo. Isso é importante
para evitar que esforço seja gasto com coleta desnecessária de
métricas, que provavelmente nunca serão utilizadas.
Algumas métricas comumente utilizadas
Softwares podem ser medidos (ou estimados) baseados em
diversos tipos de perspectivas, como tamanho e complexidade.
Além disso, em função da etapa do desenvolvimento, diferen-
tes métricas podem ser colhidas para um mesmo produto. Por
exemplo, para a medição de tamanho na etapa de levantamento
de requisitos, podemos utilizar como métrica o número de
requisitos especificados. Já na fase de projeto, o tamanho pode
ser medido em função do número de classes e, na fase de codi-
ficação, a partir no número de linhas de código fonte.
A seguir, serão apresentadas algumas das principais mé-
tricas baseadas nos tipos de medição citados e, para melhor
Edição 21 - Engenharia de Software Magazine 51
compreensão, serão utilizados exemplos de códigos e aplicação
das métricas.
Análise de Pontos de Função (APF): visa estimar o ta-
manho do software baseado em Pontos de Função (PFs).
Seu objetivo é medir as funcionalidades do software, sem
se preocupar com a tecnologia que será utilizada na im-
plementação e, pode ser aplicado já nos estágios iniciais
do desenvolvimento de software. A Tabela 1 apresenta as
fases para sua medição.
Número de linhas de código (LOC, KLOC): assim como a
APF, visa estabelecer o tamanho de um sistema, baseando-se
no número de linhas de código. Essa medição pode auxiliar
o engenheiro de software a determinar o tamanho de uma
aplicação já construída ou estimar o esforço a ser conside-
rado para a obtenção de um produto a ser desenvolvido.
Embora seja bastante objetiva, bastando analisar o código-
fonte de produtos concluídos para obtê-la, ela pode variar
de acordo com a linguagem de programação utilizada e,
portanto, as estimativas devem considerar dados de projetos
similares apenas na mesma linguagem.
Complexidade Ciclomática (CC): proposta por McCabe
em 1976, fornece uma medida quantitativa da complexidade
lógica de um programa. Através dessa métrica é possível
definir o número de caminhos possíveis de um algoritmo
através do seu número de condições (if, for, while, do e
switch) e assim, especificar o quanto um sistema é complexo
e, por conseqüência, testável, pois apresenta um indício do
número de casos de teste a serem realizados para cobrir as
possibilidades de um algoritmo. O ideal é que a complexi-
dade ciclomática seja baixa, pois desta forma, as funções
podem ser mais facilmente entendidas e modificadas. O
SEI (Software Engineering Institute) definiu uma faixa de
valores para a CC, que indicam o grau de complexidade de
um algoritmo, conforme mostra a Tabela 2.
Para exemplificar o cálculo da complexidade ciclomática,
será utilizado um algoritmo para cálculo de aprovação de
um aluno. Os possíveis caminhos no algoritmo são nume-
rados, conforme mostra a Figura 2.
Figura 2. Numeração de possíveis caminhos em um algoritmo
Existem diversas formas de cálculo da CC, através de fór-
mulas, ou pela contagem de caminhos possíveis. A Tabela 3
ilustra as possíveis formas de cálculo da complexidade
ciclomática para este algoritmo.
Para programas grandes e complexos, calcular a com-
plexidade ciclomática de cada função pode se tornar uma
tarefa exaustiva. Por este motivo, ferramentas automatizadas
podem ser utilizadas, como o plugin Metrics for Eclipse
(ver seção Links), um plugin gratuito para a IDE Eclipse
que calcula a complexidade em sistemas desenvolvidos na
linguagem Java. A Figura 3 ilustra o cálculo realizado pela
ferramenta.

FASE DESCRIÇÃO
Determinar o tipo de contagem de pontos de função Existem três tipos de contagem que podem ser levadas em conta: contagem de PF de projeto de desenvolvimento, de aplicações instaladas e
de projetos de manutenção.
Determinar o escopo de contagem e a fronteira da aplicação A fronteira da aplicação é definida estabelecendo um limite lógico entre a aplicação que está sendo medida, o usuário e outras aplicações. O
escopo para a contagem define a parte do sistema (funcionalidades) a ser contada.
Determinar a contagem de pontos de função não ajustados Essa contagem leva em conta dois tipos de função: de dados e transacionais, bem como sua complexidade (simples, média ou complexa).
Contagem das funções de dados Contagem referente às funcionalidades relativas aos requisitos de dados internos e externos à aplicação.
Contagem das funções transacionais Contagem referente às funcionalidades de processamento de dados do sistema fornecidas para o usuário, como entradas e consultas externas.
Determinar o valor do fator de ajuste Baseado em diversas características gerais de sistemas, que avaliam a funcionalidade geral da aplicação que está sendo contada e seus níveis
de influência que podem ser determinados com base em uma escala de 0 a 5.
Calcular os pontos de função ajustados PFs ajustados são calculados, considerando o tipo de contagem definido no primeiro passo.

Tabela 1. Fases para a medição por pontos de função

Complexidade Situação
1-10 Programa simples, baixo risco.
11-20 Programa mais complexo, risco moderado.
21-50 Programa complexo, risco alto.
Maior que 50 Programa não testável, risco elevado.

Tabela 2. Faixas de Complexidade Ciclomática. Fonte: SEI – Software Engineering Institute (http:// www.sei.cmu.edu)

52 Engenharia de Software Magazine - Métricas de Software


Forma de cálculo Cálculo
Contagem através dos números de CC = E – N + 2
arcos e nós onde:
E= número de arcos
N= número de nós
Contagem através do número de CC = P + 1
nós predicados (que indicam uma onde:
decisão) P= número nós predicados (decisões)
Contagem visual Através do número de regiões fechadas do gráfico
construído, considerando também a região externa
Contagem dos caminhos possíveis CC = 5
1, 2, 10
1, 3, 4, 10
1, 3, 5, 6, 10
1, 3, 5, 7, 8, 10
1, 3, 5, 7, 9, 10
Tabela 3. Formas para cálculo da Complexidade Ciclomática
Figura 3. Cálculo da complexidade ciclomática no plugin Metrics for Eclipse
Métricas de Chidamber & Kemerer (CK): foram propostas
por Chidamber & Kemerer em 1994, um conjunto de seis mé-
tricas que permitem a análise quantitativa dos artefatos de
software construídos utilizando o paradigma da orientação a
objetos. Essas métricas têm o objetivo de salientar as classes
que possivelmente contém maior número de defeitos, com o
propósito de direcionar os esforços de teste.
1. WMC (Weighted methods per class - Métodos ponderados
por classe): cálculo do número de serviços por classe, que
pode auxiliar o engenheiro de software indicando o esforço
necessário para o teste de complexidade da classe. Quando
classes apresentam um alto WMC, significa que tendem ser
específicas, ou seja, destinando-se a necessidades individuais,
o que restringe sua reutilização.
2. DIT (Depth of the inheritance tree - Profundidade da
árvore de herança): número máximo de superclasses acima
da classe em questão. Um DIT alto pode indicar que (i) a classe
em questão herdou muitas características comuns a outras
classes, indicando que suas superclasses estão preparadas
Gerência de Projetos
para reutilização, visto que provavelmente possuem alto
nível de abstração, (ii) pode indicar que a classe herda mui-
tos serviços, o que pode aumentar consideravelmente sua
complexidade.
3. NOC (Number of children - Número de filhos): número
de subclasses posicionadas imediatamente abaixo da classe
em questão. Um NOC alto indica que uma superclasse possui
muitos filhos que necessitaram implementar características
próprias, demonstrando baixo nível de abstração, visto que
podem existir poucas características em comum entre as
classes filhas. A Figura 4 exibe uma hierarquia de classes,
que demonstra um NOC de valor três. Pode-se observar que
quanto maior o número de métodos e atributos especializados,
menores são as chances de reutilização das classes filhas e
mais complexas ficam as operações de polimorfismo. Em uma
situação simples, como a do exemplo, o valor NOC não tem
impacto negativo sobre o sistema, porém caso o cenário seja
um sistema complexo com muitas classes “filhas”, é importante
acompanhar os valores de NOC, com o propósito de tomar
medidas que evitem números altos.
Figura 4. Hierarquia de classes, que demonstra um NOC de valor 3
4.CBO (Coupling between object classes - Acoplamento
entre classes de objetos): é o nível de acoplamento entre as
classes. Um CBO alto indica que a classe possui muitos rela-
cionamentos, o que dificulta sua reutilização e aumenta sua
complexidade, visto que a classe torna-se dependente de outras
para efetuar suas operações. Essa métrica auxilia o engenheiro
de software a avaliar o nível de reaproveitamento da aplicação
e o esforço despendido em testes.
5.LCOM (Lack of cohesion in methods - Falta de coesão em
métodos): Número de acessos a um ou mais atributos em co-
mum pelos métodos da própria classe. Quanto maior o LCOM,
menos coesa é a classe. A coesão em métodos é a capacidade
dos métodos realizarem apenas a função a que são destinados
e, para isso devem acessar apenas atributos essenciais ao seu
funcionamento. Portanto, é importante que o LCOM seja baixo
a fim de aumentar a reutilização e diminuir a complexidade
da classe.
Edição 21 - Engenharia de Software Magazine 53
6.RFC (Response for a class - Resposta de uma classe):
Indica a capacidade de resposta que a classe tem ao receber
mensagens de seus objetos (conjunto resposta). É o número de
métodos que podem ser chamados em resposta a uma mensa-
gem recebida por um objeto ou por algum método da classe.
Quanto maior o RFC, maior a possibilidade da classe atender
às suas funções. Em contrapartida, para obter um RFC alto,
é necessário projetar uma estrutura de classes adequada que
possa tender a essa particularidade, o que acaba gerando maior
complexidade, tornando necessário maior esforço de teste.
Métricas de Lorenz & Kidd: Lorenz & Kidd, também em 1994,
propuseram um conjunto de quatro métricas, comumente cha-
madas métricas LK, que se baseiam assim como as métricas
CK, no cálculo quantitativo de alguns aspectos fundamentais
da Orientação a Objetos, como os atributos, métodos, herança,
coesão e acoplamento. A diferença entre as métricas LK e as
métricas CK é em relação à metodologia empregada em seu
cálculo.
1.CS (Class size - Tamanho da classe): é o número de métodos
e atributos da própria classe e herdados de suas superclasses.
Um número alto de CS indica que a classe pode ser muito espe-
cífica, atendendo necessidades privadas, o que pode dificultar
sua reutilização e aumentar sua complexidade.
2.NOO (Number of operations overriden by a subclass
- Número de operações redefinidas por uma subclasse):
número de sobrescritas de métodos em subclasses. Os
métodos herdados de uma superclasse podem ser sobres-
critos, ou seja, redefinidos em subclasses, com o propósito
de tornar sua funcionalidade mais específica. De certa
forma, essa redefinição de métodos pode ferir a abstração
implícita da superclasse e um número elevado de NOO
pode indicar problemas estruturais, pois muitas subclas-
ses do sistema têm métodos redefinidos e possivelmente
estão hierarquicamente mal projetadas. Utilizando ainda
o exemplo da Figura 4, nas Listagens 1, 2 e 3 pode-se ob-
servar trechos de código das três classes (Gerente, Diarista
e Vendedor), que redefinem o método calculaSalario(). As
classes Gerente e Vendedor também redefinem o método
getCargo(), e ainda,a classe Vendedor redefine o método
getDepartamento(). Apesar de não representar um risco
estrutural para o projeto, no caso do exemplo, o número
de métodos redefinidos indica quais classes devem ter sua
evolução acompanhada. Em um projeto de grande porte e
crítico, pode ser complicado reestruturar uma hierarquia
de classes no meio do projeto e o NOC indica que classes
possivelmente devem ser reestruturadas o quanto antes. A
Figura 5 apresenta o resultado da coleta dessa métrica com
a ferramenta Metrics for Eclipse.
3. NOA (Number of operations added by a subclass - Número
de operações adicionadas por subclasse): número de métodos
e atributos definidos em uma subclasse. Um NOA alto quer
54 Engenharia de Software Magazine - Métricas de Software
Listagem 1. métodos gerCargo() e calculaSalario() redefinidos na classe Gerente
public String getCargo (){
return
“Gerente”;
}
public double calculaSalario(){
double taxaTotal=(getSalario()*taxaDependentes)*numDependentes;
return
getSalario()-getDesconto() + taxaTotal;
}
Listagem 2. método calculaSalario() redefinido na classe Diarista
public double calculaSalario(){
return horasTrabalhadas * valorHora;
}
Listagem 3. métodos getDepartamento(), getCargo() e calculaSalario()
redefinidos na classe Vendedor
public Departamento getDepartamento(){
return new Departamento(Departamento.VENDAS);
}
public String getCargo(){
return “vendedor”;
}
public double calculaSalario(){
return (getSalario()- getDesconto())+(numeroVendas *
comissaoPorVenda);
}
Figura 5. Coleta da Métrica NOO pela ferramenta Metrics for Eclipse, aqui
chamada de Number of Overridden Methods
dizer que a subclasse adicionou muitos métodos e atributos
em sua definição, o que indica um problema estrutural, já que
boa parte de seus atributos deveria ser definida em super-
classes. Além de aumentar a complexidade do sistema como
um todo, um valor elevado de NOA reduz as possibilidades
de reutilização.
4. SI (Specialization index - Índice de especialização): nú-
mero de métodos adicionados, eliminados ou redefinidos em
uma classe. Na verdade, essa métrica complementa as métricas
NOO e NOA e um valor alto indica também um problema de
estruturação de classes, já que possivelmente foram realizadas
alterações para atendimento de necessidades específicas. Clas-
ses muito específicas dificilmente são reaproveitadas, ferindo
um dos princípios básicos da OO, a reutilização.
A seguir, são apresentadas na Figura 6 as possíveis mé-
tricas coletadas de um fragmento de sistema de controle de
Recursos Humanos, através da ferramenta Metrics for Eclipse,
para demonstrar como é simples e rápida a coleta de um
conjunto significativo de métricas através de ferramentas
automatizadas.

Figura 6. Métricas coletadas pela ferramenta Metrics for Eclipse
Alguns outros tipos de métricas
Diversos outros tipos de métricas são largamente utilizados,
como métricas de confiabilidade e esforço.
Métricas de confiabilidade são normalmente baseadas em
número de defeitos apresentados por uma aplicação, poden-
do ser medidas por intervalo de tempo ou por versão de um
produto em uso. Nessa categoria, ferramentas de apoio como
BugZilla, Mantis ou Trac são boas aliadas para o registro e
acompanhamento de defeitos.
Métricas de esforço são importantes no acompanhamento de
processos de software, sendo comumente utilizada a medição
de esforço por Homem/Hora, ou alguma derivada desta, como
Homem/Mês, que refletem a quantidade de recursos humanos
alocados ao projeto por unidade de tempo.
Conclusão
Métricas de software são medidas quantitativas acerca de
processos ou produtos de software. O artigo procurou mostrar
Gerência de Projetos
algumas das métricas mais conhecidas e exemplificar o uso
de algumas delas através de exemplos simplificados, com o
propósito de acentuar a importância de sua utilização em um
projeto. As métricas são capazes de indicar pontos em que
são necessários maiores esforços de teste e acompanhamento.
Através de ferramentas automatizadas, é possível coletar um
grande número de métricas com menor esforço, o que viabi-
liza a implantação de processos de medição em qualquer tipo
de sistema, desde os mais simples até os mais críticos, o que
contribui para a qualidade do produto final.
Feedback
Dê seu feedback sobre esta edição! eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista!
s
ta
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Edição 21 - Engenharia de Software Magazine 55
Validação, Verificação e Teste
Esta seção traz artigos que apresentam como e quando utilizar as diferentes abordagens
de VV&T no apoio ao desenvolvimento de projetos de software
Integração contínua com Hudson, Maven2,
TestNG e Subversion
Victor Vidigal Ribeiro
victorvidigal@gmail.com
É pós-graduando do Curso de Gerência de
Projetos em Engenharia de Software pelo
Centro de Ensino Superior de Juiz de Fora
– CES/JF, Bacharel em Sistemas de Infor-
mação pela Faculdade Metodista Granbery
e Analista de Sistemas da Granbery Consul-
toria Junior, atuando em projeto vinculado
à Fundação COPPETEC/UFRJ.
Fabrício Nogueira de Almeida
fnalmeida@gmail.com
É pós-graduando do Curso de Gerência de
Projetos em Engenharia de Software pelo
Centro de Ensino Superior de Juiz de Fora
– CES/JF, Bacharel em Sistemas de Infor-
mação pela Faculdade Metodista Gran-
bery e Analista de Sistemas da Uptodate
Consulting.
Marco Antônio Pereira Araújo
maraujo@acessa.com
Doutor e Mestre em Engenharia de Sistemas
e Computação pela COPPE/UFRJ, Especialista
em Métodos Estatísticos Computacionais e
Bacharel em Matemática com Habilitação em
Informática pela UFJF, Professor dos cursos de
Bacharelado em Sistemas de Informação do
Centro de Ensino Superior de Juiz de Fora e
da Faculdade Metodista Granbery, Analista
de Sistemas da Prefeitura de Juiz de Fora e
Editor da Engenharia de Software Magazine.
56 Engenharia de Software Magazine - Integração contínua com Hudson, Maven2, TestNG e Subversion
D
evido à crescente demanda por
softwares cada vez mais com-
plexos e de maior qualidade,
várias técnicas vêm sendo propostas
para auxiliar na sua construção. Uma
dessas técnicas é o teste de unidade que
tem como principal finalidade a busca
por defeitos na menor unidade de um
sistema como um método ou função,
por exemplo.
Porém, em um sistema com uma com-
plexidade relevante, os testes de unidade
podem consumir um tempo excessivo
da equipe cada vez que uma alteração
no sistema seja necessária e os testes
tenham que ser executados.
De que se trata o artigo?
Montagem de um ambiente de integração con-
tínua utilizando um conjunto de ferramentas
para este fim.
Para que serve?
O ambiente de integração contínua proposto
mantém o código fonte do repositório sempre
testado, aumentando sua confiabilidade, além
de diminuir a alocação de recursos humanos em
atividades de teste.
Em que situação o tema é útil?
Em ambientes em que é preciso manter um
repositório com código fonte confiável e em sis-
temas em que os testes atingiram uma comple-
xidade relevante e estão consumindo recursos
humanos em excesso ao serem executados.
É neste contexto que se pode tirar pro-
veito da integração contínua, onde um
servidor faz periodicamente o checkout
do código fonte do repositório e executa
automaticamente os testes já criados.
Com isto, ao subir um código para o
repositório não é necessário que todos
os testes do sistema sejam executados.
Pode ser definida uma estratégia onde o

responsável por enviar o código para o repositório execute apenas
os testes diretamente relacionados com a alteração realizada,
diminuindo o tempo gasto com a execução dos testes.
Além disto, a execução periódica dos testes ajuda a manter a
confiabilidade do código fonte que está no repositório.
Este artigo tem por finalidade demonstrar a configuração de
um ambiente de integração contínua utilizando um servidor
de integração contínua chamado Hudson, em um repositório
controlado pelo Subversion, e um projeto criado no Eclipse
utilizando o Maven2 através do plug-in Maven2Eclipse e o
framework de testes TestNG.
Criando o repositório
O primeiro passo para iniciar a construção do ambiente é
baixar e instalar o Subversion. Será utilizado o VisualSVN que
é um servidor do Subversion que disponibiliza uma interface
gráfica para configuração e que pode ser baixado no endereço
http://www.visualsvn.com/.
A instalação do VisualSVN é bastante simples, basta executar
o arquivo de instalação baixado e seguir os passos mantendo
sempre as configurações padrões sugeridas pelo instalador.
Depois de instalado e executado, o VisualSVN apresenta uma
tela semelhante à Figura 1.
Figura 1. Configuração VisualSVN
Neste momento é preciso configurar os usuários e grupos de
usuários que terão acesso ao repositório. Como exemplo, será criado
apenas um usuário chamado “devmedia” que pode ser incluído
clicando com o botão direito sobre a opção Users, selecionando a
opção New User e definindo um login e senha para este usuário.
Depois de criar o usuário, será criado um repositório chama-
do CalcularAprovacao. Para isso, clique com o botão direito
sobre a opção Repositories e selecione a opção Create New
Repository. Uma caixa de texto será aberta onde deve ser di-
gitado CalcularAprovacao no nome do repositório.
Note que a URL do Subversion pode ser vista na tela inicial
do VisualSVN no campo Server URL is. Posteriormente essa
URL será necessária para configurar o servidor de integração
e o Eclipse.
PROJETO
Feito isto, as configurações necessárias no repositório estão
prontas.
Configurando o Eclipse
Para facilitar a criação do ambiente, primeiro será instalado
um plug-in chamado Subclipse que permite a comunicação
entre o Eclipse e o repositório. Para isto, abra o eclipse e acesse
o menu Help / Install New Software. Uma janela será apresen-
tada onde o endereço http://subclipse.tigris.org/update_1.6.x
deve ser digitado no campo Work with e, em seguida, deve-se
acessar a opção Add. Ao acessá-la, algumas opções irão apare-
cer no campo Name desta janela, onde devem ser marcadas as
opções Core SVNKit Library, Optional JNA Library e Subclipse,
como pode ser visto na Figura 2 e, logo em seguida, deve-se
selecionar a opção Next até que a instalação seja concluída.
Figura 2. Instalação do Subclipse
Neste momento o plug-in Subclipse está instalado e deve-se
agora instalar o plug-in Maven2Eclipse. Para isso, siga o mesmo
procedimento, porém, utilizando o endereço http://m2eclipse.
sonatype.org/update/ e selecionando apenas a opção Maven
Integration no campo Name.
Com isto, o Eclipse já está com todos os plug-ins que preci-
samos para começar a criar o projeto de exemplo e se integrar
com o Hudson.
Criando o projeto de teste
Para criar o projeto de exemplo utilizaremos o Maven2
através do plug-in Maven2Eclipse, instalado anteriormente.
O Maven é um projeto da Apache que tem por finalidade o
gerenciamento de projetos. Ele trabalha com o conceito de
convenção, ou seja, permite a compilação e a distribuição de
Edição 21 - Engenharia de Software Magazine 57
uma aplicação com um mínimo de configuração, desde que
o projeto respeite a estrutura proposta, e ainda gerencia as
dependências do projeto.
Para iniciar a construção do projeto, acesse o menu File / New
/ Other. Uma janela será apresentada onde a opção Maven /
Maven Project deve ser escolhida. Após isto, uma nova janela
é apresentada onde a opção Create a simple project deve ser
marcada e, logo em seguida, deve ser selecionada a opção Next.
Feito isso, outra janela, semelhante à Figura 3, é apresentada,
onde devem ser digitados alguns dados do projeto:
• Goup Id: é o identificador exclusivo do grupo ou organiza-
ção que criou o projeto. No projeto de exemplo será digitado
br.com.calcularAprovacao neste campo.
• Artifact Id: indica um nome único para o projeto, deve ser
digitado CalcularAprovacao neste campo.
• Version: é a versão do artefato gerado pelo projeto, deixare-
mos esta opção como padrão.
• Packaging: é o tipo de artefato que será gerado pelo projeto,
por exemplo, JAR, WAR, EAR. Para o exemplo será gerado um
artefato do tipo JAR.
• Name: é o nome que será visualizado nos relatórios que
podem ser gerados pelo Maven. Neste campo será digitado
CalcularAprovacao.
• Description: neste campo pode ser digitada uma breve des-
crição sobre o projeto.
Figura 3. Criação de um projeto Maven2
Após preencher os dados do projeto, clique sobre o botão
Finish que o Maven irá criar o projeto utilizando sua estrutura
padrão.
Depois de criar o projeto, deve ser adicionada a dependência
do TestNG, que é o framework de testes que será utilizado.
Clique com o botão direito sobre o projeto e selecione o menu
58 Engenharia de Software Magazine - Integração contínua com Hudson, Maven2, TestNG e Subversion
Maven / Add Dependency. Uma janela será apresentada onde
se deve digitar TestNG no campo Enter groupId, artifactId or
sha1 prefix or pattern. Com isto, o Maven busca em seu repo-
sitório online as dependências com o nome TestNG. Selecione
a opção org.testng testng e clique sobre o botão Ok. Feito isto,
o Maven2Eclipse adiciona algumas linhas no arquivo de
configuração do Maven (chamado pom.xml) e irá baixar as
dependências necessárias para que o TestNG funcione.
Apesar do Maven2Eclipse facilitar bastante a configuração
do Maven, uma configuração manual deve ser adicionada no
arquivo pom.xml. A tag <build> e suas sub-tags devem ser
adicionadas indicando que o código do projeto deve ser com-
pilado para versão 1.6 do Java. Com isto, o arquivo pom.xml
deve ficar semelhante ao mostrado na Listagem 1.
Depois disso, clique com o botão direito sobre o projeto e
selecione a opção New / Package e crie um pacote chamado
br.com.calcularAprovacao dentro de src/main/Java para
armazenar o código do exemplo. Outro pacote com o mesmo
nome também deve ser criado dentro de src/test/java para
armazenar os casos de testes.
Neste momento, a estrutura do projeto está criada e confi-
gurada para trabalhar com o TestNG. Agora, é preciso criar
uma classe chamada Aluno que contém um método chamado
calcularAprovacao(). Este método será testado pelos casos de
testes que serão criados posteriormente.
Listagem 1. Arquivo pom.xml
<project xmlns=”http://maven.apache.org/POM/4.0.0”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://
maven.apache.org/maven-v4_0_0.xsd”>
<modelVersion>4.0.0</modelVersion>
<groupId>br.com</groupId>
<artifactId>CalcularAprovacao</artifactId>
<packaging>jar</packaging>
<version>0.0.1-SNAPSHOT</version>
<dependencies>
dependency>
<
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>5.10</version>
<classifier>jdk15</classifier>
/dependency>
<
</dependencies>
<build>
<finalName>CalcularAprovacao</finalName>
plugins>
<
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
/plugins>
<
</build>
</project>
 PROJETO

Crie a classe Aluno. Ela deve ser criada dentro de src/main/ new repository location deve ser selecionada e, logo em segui-
Java utilizando o código mostrado na Listagem 2. da, a opção Next deve ser escolhida. Feito isto, uma nova janela
é exibida onde a URL do Subversion (https://localhost:8443/
Listagem 2. Classe Aluno svn/CalcularAprovacao/) deve ser digitada. Após isso, clique
sobre a opção Finish.
package br.com.calcularAprovacao;
public class Aluno {
private String nome; Listagem 3. Classe de teste CalcularAprovacaoTest
private float nota1;
private float nota2; package br.com.testeAprovacao;
private float notaFinal; import org.testng.annotations.Test;
private int frequencia; import org.testng.*;
import br.com.calcularAprovacao.Aluno;
public String getNome(){
return nome;
@Test
} public class CalcularAprovacaoTest {
public void setNome(String nome){ public void testAlunoReprovadoFrequencia() {
this.nome = nome;
Aluno aluno = new Aluno();
} aluno.setNome(“João”);
public float getNota1() { aluno.setNota1(0);
return nota1; aluno.setNota2(0);
} aluno.setNotaFinal(0);
public void setNota1(float nota1) { aluno.setFrequencia(74);
this.nota1 = nota1; Assert.assertFalse(aluno.calcularAprovacao());
} }
public float getNota2() { public void testAlunoAprovadoNota() {
return nota2; Aluno aluno = new Aluno();
} aluno.setNome(“João”);
public void setNota2(float nota2) { aluno.setNota1(70);
this.nota2 = nota2; aluno.setNota2(70);
} aluno.setNotaFinal(0);
public float getNotaFinal() { aluno.setFrequencia(75);
return notaFinal; Assert.assertTrue(aluno.calcularAprovacao());
} }
public void setNotaFinal(float notaFinal) { public void testAlunoReprovadoNota() {
this.notaFinal = notaFinal; A
luno aluno = new Aluno();
} aluno.setNome(“João”);
public int getFrequencia() { aluno.setNota1(29);
return frequencia; aluno.setNota2(30);
} aluno.setNotaFinal(0);
public void setFrequencia(int frequencia) { aluno.setFrequencia(75);
this.frequencia = frequencia; Assert.assertFalse(aluno.calcularAprovacao());
} }
public boolean calcularAprovacao(){ public void testAlunoReprovadoFinal() {
float media; Aluno aluno = new Aluno();
aluno.setNome(“João”);
if (frequencia < 75) { aluno.setNota1(30);
return false; aluno.setNota2(30);
} else { aluno.setNotaFinal(69);
media = (nota1 + nota2) / 2; aluno.setFrequencia(75);
if (media < 30) { Assert.assertFalse(aluno.calcularAprovacao());
return false; }
} else { public void testAlunoAprovadoFinal() {
if (media >= 70) { A
luno aluno = new Aluno();
return true; aluno.setNome(“João”);
} else { aluno.setNota1(30);
if (((media + notaFinal) / 2) >= 50) { aluno.setNota2(30);
return true; aluno.setNotaFinal(70);
} else { aluno.setFrequencia(75);
return false; Assert.assertTrue(aluno.calcularAprovacao());
} }
} }
}
}
}
}

Depois de criar a classe Aluno, será criada a classe Calcu-

larAprovacaoTest que contém os casos de teste. Esta classe
deve ser criada dentro de src/test/Java, e deve conter o código
mostrado na Listagem 3.
Pode-se perceber que esta classe contém a anotação @Test que
faz com que o TestNG a reconheça como uma classe de teste.
Neste momento, o projeto está criado e deve ter uma estrutura
semelhante à apresentada na Figura 4.
Agora é preciso subir nosso projeto para o repositório. Para
isto, clique com o botão direito sobre o projeto e selecione a Figura 4. Estrutura do Projeto
opção Team / Share Project. Ao selecionar essa opção, uma
janela é exibida onde deve ser escolhido o tipo do repositório. Com o procedimento anterior, o Subclipse vinculou o projeto
Selecione a opção SVN, que é a sigla para Subversion, e clique ao repositório, mas ainda não subiu o código para este repo-
sobre Next. Uma nova janela é exibida onde a opção Create a sitório. Para subir o código clique novamente sobre o projeto

Edição 21 - Engenharia de Software Magazine 59

e selecione a opção Team / Commit. Ao selecionar esta opção
uma janela é exibida onde é possível escrever um comentário
sobre o código que está sendo enviado ao repositório. Digite
“Primeiro commit para o subversion” e clique sobre o botão
Ok. Com isto, o código é enviado ao repositório.
Configurando o Hudson
Depois de ter realizado os procedimentos anteriores, chegou
a hora de configurar o Hudson, que é um servidor de integra-
ção contínua.
O Hudson é disponibilizado como um arquivo WAR e tem
um servidor web integrado a ele. Por conta disso, ele pode
ser executado utilizando o comando java –jar hudson.war ou
através de um servidor externo. No exemplo, será utilizado
o Tomcat.
Portanto, copie o arquivo hudson.war para a pasta webapps e
reinicie o Tomcat para que ele efetue o deploy do Hudson. Feito
isto, basta acessar o endereço http://localhost:8080/hudson
para entrar na interface de configuração.
Na página de configuração do Hudson, o menu Gerenciar
Hudson / Configure System deve ser acessado para iniciar a
configuração, como mostra a Figura 5.
Figura 5. Configurações do Hudson
Há muitas maneiras diferentes de se configurar o Hudson e,
por conta disso, serão mostradas as principais configurações
que são necessárias para seu funcionamento.
O primeiro campo, Mensagem do Sistema, é apenas a men-
sagem inicial que será exibida ao acessar o Hudson.
O campo Número de executores informa qual é a quantidade
de builds concorrentes que o Hudson pode fazer. Isso porque
um servidor do Hudson pode rodar vários projetos simulta-
neamente. Já no campo Período de Silêncio pode-se definir
quanto tempo o Hudson irá aguardar até que comece o build
e, em SCM checkout retry count, a quantidade de vezes que o
Hudson deve tentar fazer checkout caso aconteça algum erro
nesse procedimento.
A opção Habilitar segurança deve estar marcada para que
se possa definir como o Hudson irá controlar os usuários. Ao
habilitar a segurança, o Hudson fornece opções de controle
de usuário. Selecione a opção Hudson’s own user database
para que os usuários sejam controlados pelo próprio Hudson.
60 Engenharia de Software Magazine - Integração contínua com Hudson, Maven2, TestNG e Subversion
Logo abaixo, marque também a opção Logged-in users can do
anything para permitir que os usuários criados posteriormente
tenham permissão para fazer qualquer coisa no Hudson.
Um pouco mais abaixo na janela de configuração, como pode
ser visto na Figura 6, é possível configurar o Maven e o JDK
que serão utilizados. Para incluir o Maven, clique sobre o botão
Add Maven e digite Maven no campo Name e, em Version,
selecione a opção 2.2.1.
Para adicionar o JDK, clique sobre o botão Add JDK, digite
jdk6 no campo Name e, em JAVA_HOME, informe o diretório
onde o JDK está instalado.
Figura 6. Configuração do Maven e JDK
A próxima e última configuração é referente ao envio de e-
mails. Caso esteja configurado, o Hudson envia e-mails cada
vez que é executado, informando o resultado de sua execução.
Para configurar essa funcionalidade, na parte de Notificação
de E-mail, informe o endereço do servidor SMTP no campo
Servidor SMTP e o sufixo padrão para e-mail de usuário.
Sufixo padrão para e-mail de usuário indica ao Hudson que
o endereço de e-mail de cada usuário é formado pelo nome do
usuário mais o sufixo padrão. Por exemplo, se o sufixo padrão
for configurado como @gmail.com e um usuário chamado de-
vmedia for adicionado, o Hudson irá entender que o endereço
de e-mail desse usuário é devmedia@gmail.com.
Deve-se preencher o Endereço de e-mail do Administrador
do sistema com o endereço de e-mail do administrador.
No campo URL do Hudson deve ser definido o endereço
do Hudson, com http://localhost:8080/hudson.
Como exemplo, será utilizado o SMTP do GMail que
necessita de autenticação para funcionar. Para configurar
esta autenticação clique sobre o botão Avançado, marque a
opção Use SMTP Authentication, digite o nome do usuário,
a senha e, caso seja necessário, marque a opção Usar SSL.
A Figura 7 mostra como ficou a configuração dessa parte
do Hudson.
O envio de e-mail pode ser testado através do botão Con-
figuração de teste para enviar e-mail para o endereço do
Administrador do Sistema. Acessando esse botão, um e-mail
de teste é enviado.

Figura 7. Configurações do servidor de SMTP
Pode-se perceber que do lado de cada campo há um , Raíz onde está o arquivo pom.xml do projeto gerado. Nesse
que caso acionado, exibe a descrição do campo que está a sua
esquerda. Este recurso é de grande auxílio na configuração
do Hudson.
Após realizar as configurações anteriores, o botão Salvar deve
ser acionado. Com isso, o Hudson exibe uma página onde o
primeiro usuário deve ser criado. Para o exemplo, foi criado
um usuário chamado devmedia.
Criando tarefas no Hudson
Depois de configurar o Hudson, é preciso criar uma tarefa
informando a ele que deve baixar o projeto do repositório e
executar os testes criados.
Ao clicar na opção Nova Tarefa, localizada na parte esquerda
do Hudson, uma janela é exibida onde se pode digitar o nome
da tarefa. A tarefa de teste será chamada de CalcularAprova-
cao. É preciso definir também o tipo de tarefa que, no caso do
exemplo, será escolhida a opção Construir um projeto Maven2.
Após isto, clique sobre o botão Ok e uma nova janela é exibida
onde é possível configurar a tarefa construída.
Em Gerenciamento de Código Fonte, selecione a opção Sub-
version e digite a URL do Subversion em URL do Repositório.
O Hudson irá informar que não consegue acessar o repositório,
isto é porque ainda não foi definido um usuário e senha para
acessá-lo. Clique sobre o link enter credential para definir o
usuário do repositório.
No campo Diretório do módulo local deve ser digitado o
nome do projeto que foi criado no Eclipse e, portanto, deve-se
digitar CalcularAprovacao.
A opção Usar Atualização é bastante interessante. Caso seja
marcada, o Hudson não faz o checkout de todo o projeto no-
vamente. Ele faz o checkout apenas dos arquivos que foram
alterados no repositório. A Figura 8 mostra como esta parte
da configuração do repositório deve estar.
A próxima configuração diz respeito à periodicidade do Hu-
dson, ou seja, o Hudson pode ser configurado para rodar de
tempos em tempos. Para isso, em Disparadores de Construção,
PROJETO
a opção Construir periodicamente deve ser marcada, e o cam-
po Agenda configurado com o seguinte texto: 0 0 * * *. Desta
maneira, o Hudson irá rodar no minuto 0 da hora 0 de cada
dia do ano, pois este campo segue a mascara: minuto hora
dia_mês mês dia_semana.
Figura 8. Configuração do Subversion no Hudson
Após isto, em Construir, é preciso informar no campo POM
campo deve ser digitado CalcularAprovacao/pom.xml. No
campo Goals and options deve ser digitado test. Esse é um
parâmetro que faz com que o Hudson execute o Maven para
rodar os testes criados.
Uma última configuração que deve ser feita é marcar a
opção Notificação de E-mail para que um e-mail com os
relatórios de execução do Hudson seja enviado cada vez
que o Hudson for executado.
Para salvar as configurações, deve ser acionado o botão
Salvar. Com isso, o Hudson exibe a página inicial da tarefa
que acabou de ser criada.
Com essas configurações, o Hudson irá baixar o projeto do
repositório e executar os testes criados às 0:00 horas de cada
dia. É possível executar a tarefa criada a qualquer momento
também através do menu Construir Agora.
Na parte esquerda do Hudson, como pode ser visto na
Figura 9, pode ser visualizado um histórico das construções
que foram realizadas, e também de alguma eventual cons-
trução que esteja sendo executada.
Figura 9. Histórico de Construção
Caso alguma construção não tenha sido realizada com
sucesso, é possível ver o motivo do erro clicando sobre a
construção e, em seguida, sobre o menu Console output.
Ao acessar esta opção, o Hudson exibe a saída gerada pela
construção. A Figura 10 mostra um exemplo de saída em
que a construção falhou, sendo possível verificar o motivo
da falha.
Edição 21 - Engenharia de Software Magazine 61
 ferramentas de acompanhamento de defeitos (Bugzilla, Man-
tis, Trac), suporte a outras linguagens (.net, ruby) e até mesmo
integração com o Twitter.

Figura 10. Saída de Console
O Hudson também disponibiliza um relatório de tendência
onde é possível visualizar graficamente os resultados dos
testes executados. A Figura 11 mostra o relatório gerado no
projeto de exemplo.
O gráfico apresenta o número da construção pelo seu tempo
de execução. Enquanto as áreas vermelhas do gráfico represen-
tam as construções que falharam, as cinzas são construções que
foram abortadas. Já as amarelas são as construções que foram
executadas com sucesso parcial e as construções executadas
com sucesso total são representadas pela cor azul.
Conclusão
O artigo procurou mostrar como configurar um ambiente de
integração contínua utilizando diferentes ferramentas.
O ambiente foi construído utilizando o servidor de integração
Hudson, o repositório Subversion, com o uso do VisualSVN
para instalação do servidor, e o plug-in Subclipse para integra-
ção com o Eclipse, o gerenciador de projetos Maven2, através
do plug-in Maven2Eclipse, e o framework de teste TestNG.
Um ambiente de integração contínua, como o apresentado
neste artigo, possibilita a execução de testes de maneira auto-
matizada o que pode torná-los mais eficientes e economizar
recursos humanos nessa tarefa. Além disso, com a execução
periódica dos testes, é mais rápida a identificação de falhas
inseridas no código fonte pelos desenvolvedores. Devido a isto,
o código do repositório pode ser considerado mais confiável.
Outra vantagem desse ambiente é que se torna possível um
melhor acompanhamento da execução de testes através de
relatórios gerados pelo Hudson.

Links

Hudson
http://hudson-ci.org/

VisualSVN
http://www.visualsvn.com/

Subclipse
http://subclipse.tigris.org/

TestNG
http://testng.org

Figura 11. Gráfico de tendências

Dê seu feedback sobre esta edição! Feedback
eu
s
Apesar do ambiente proposto ter mostrado apenas a execução
Dê

A Engenharia de Software Magazine tem que ser feita ao seu gosto.

sobre e
de testes de unidade através do Hudson, é possível integrar
Para isso, precisamos saber o que você, leitor, acha da revista!
também ferramentas de checkstyle de código, detecção de bugs ta
edição
s
Dê seu voto sobre este artigo, através do link:
e cobertura de testes, por exemplo.
Além disso, o Hudson é extensível através de plug-ins www.devmedia.com.br/esmag/feedback
que podem fornecer funcionalidades como integração com

62 Engenharia de Software Magazine - Integração contínua com Hudson, Maven2, TestNG e Subversion
 PROJETO

Edição 21 - Engenharia de Software Magazine 63

64 Engenharia de Software Magazine - Integração contínua com Hudson, Maven2, TestNG e Subversion