Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros
Gerenciando com o CMMI 2
Produzindo software de forma gerenciada com o modelo CMMI
Crhistian Ghamaliel
crhistian.ti@gmail.com.br
Especialista em Processos de Software,
CMMI e MPS.BR. Bacharel em Ciências da
Computação, pós-graduado em Gestão
de Projetos e Gestão da Tecnologia da
Informação. Possui mais de 10 anos de
experiência com Engenharia de Software.
Já exerceu todos os papéis no ciclo de vida
de desenvolvimento de software e atual-
mente atua como Gerente de Melhoria de
Processos. Implementador e Avaliador cer-
tificado do MPS.BR. Tem sido responsável
pela certificação de empresas nos modelos
CMMI e MPS.BR. Palestrante em universi-
dades e congressos pelo Brasil, também já
lecionou em faculdades de TI.
De que se trata o artigo?
Nesse artigo, iniciaremos uma série de análises sobre
o modelo de maturidade CMMI, começando pelo nível
2 e sua capacidade de tornar os processos gerencia-
dos. Neste nível, analisaremos suas áreas de processo
e resultados esperados, buscando um paralelo com a
realidade praticada pelas empresas de software.
Em que situação o tema é útil?
Esse artigo é útil para todos aqueles interessa-
dos em conhecer o modelo CMMI, iniciando pelo
nível 2. Nele, mostramos em detalhes os ganhos
obtidos com o atendimento ao que é proposto
por cada uma das áreas de processo desse nível.
M
uitos artigos já foram escritos
sobre CMMI. Dentre eles,
vários com um enfoque em
apresentar e descrever este consagrado
modelo de maturidade de software.
Neste artigo, também apresentaremos
o CMMI, porém o nosso enfoque será
no nível 2, direcionado para o que rea-
lizamos diariamente nas organizações
que desenvolvem software. Este enfoque
busca responder às seguintes perguntas:
Edição 47 - Engenharia de Software Magazine
O paralelo estabelecido com as práticas realizadas
pelas empresas de software permitirá aos leitores
compreender as vantagens do CMMI.
Resumo:
Esse artigo inicia uma série de análises sobre o
modelo CMMI (Capability Maturity Model Inte-
gration), começando pelo seu nível 2 de matu-
ridade. Neste nível, o principal ganho obtido é a
capacidade de implantar processos gerenciados
nas organizações. Esse será o principal aspecto
apresentado, fazendo-se um paralelo com as or-
ganizações que ainda não adotaram modelos de
maturidade de software como o CMMI.
como o nível 2 do CMMI pode auxiliar
as organizações? Quais são as vantagens
competitivas deste modelo?
Para isso, primeiramente iremos co-
nhecer o modelo CMMI e, em seguida,
analisarmos os processos do nível 2 de
maturidade. Ao longo desta análise, fa-
remos um paralelo com a realidade das
organizações, observando as vantagens
trazidas pelo modelo. Ao final, apresen-
taremos uma conclusão sobre o artigo.
39
O modelo CMMI
CMMI, sigla para Capability Maturity Model Integration, é
uma coleção de modelos que contêm melhores práticas que
auxiliam as organizações a aprimorarem os seus processos.
Eles são desenvolvidos por membros da indústria, governo e
pelo Software Engineering Institute (SEI), instituição sedia-
da nos Estados Unidos. Dentre estes modelos, o CMMI for
Development (CMMI-DEV) fornece um conjunto abrangente
e integrado de diretrizes para o desenvolvimento de pro-
dutos e serviços. Ele aborda práticas que cobrem o ciclo de
vida do produto, desde a sua concepção até a entrega para
o cliente. Atualmente, o CMMI-DEV está em sua versão 1.3,
lançada em 2010. Neste artigo, utilizaremos a sigla CMMI
para referenciar o CMMI-DEV, nosso foco de interesse.
O CMMI trata da melhoria dos processos em uma organiza-
ção. Ele contém os elementos essenciais de processos efetivos
para uma ou mais disciplinas e descreve um caminho evolutivo
de processos imaturos para processos disciplinados, maduros
e com maior qualidade e eficácia. É fruto de um longo traba-
lho do SEI, que teve seus primeiros resultados por volta de
1988, há mais de vinte anos. Portanto, o CMMI é um modelo
consolidado mundialmente, fruto de um extenso trabalho de
pesquisa de boas práticas de engenharia de software, serviços
e aquisições.
O CMMI utiliza o conceito de níveis para descrever um
caminho evolutivo recomendado para uma organização que
quer melhorar os processos que utiliza para desenvolver
produtos ou serviços. Este caminho evolutivo é apresen-
tado de duas formas: pela representação contínua e pela
representação por níveis de maturidade. Na representação
contínua, o foco são os “níveis de capacidade”; na repre-
sentação por níveis, são os “níveis de maturidade”. Neste
artigo iremos utilizar como base a representação por níveis
de maturidade.
Os níveis do CMMI ganham uma denominação numérica
e vão do 1 ao 5. Cada nível recebe também uma designação
que informa a sua principal característica, conforme ilustrado
pela Figura 1.
Figura 1. /ÓWFJT
EP
$..*
F
EFTJHOBÎÜFT
EF
NBUVSJEBEF
Dentre eles, o nível 1 não é atingível pelo CMMI, ou seja,
o SEI não disponibiliza uma certificação neste nível, pelo
simples fato de ele significar a ausência de qualquer matu-
ridade dos processos de uma organização. Neste nível, os
sucessos de uma organização são conseguidos através de
40 Engenharia de Software Magazine - Gerenciando com o CMMI 2
esforços, muitas vezes heroicos, de pessoas, que na grande
maioria das vezes atuam sem o apoio de nenhum processo
formalizado, bem como de nenhuma ferramenta que suporte
o seu árduo trabalho. Infelizmente, ainda considerável é o
número de organizações brasileiras, sobretudo empresas
privadas, que desenvolvem software desta maneira. As
consequências são muitas vezes drásticas e desgastantes,
tanto do ponto de vista humano, quanto do financeiro e da
qualidade. Trabalhar conforme esta cultura já foi responsá-
vel pelo desaparecimento de muitas empresas de software
promissoras em nosso país. Portanto, o CMMI apenas lista
o nível 1 para classificar com ele as organizações que ainda
não apresentam nenhum tipo de maturidade em seus pro-
cessos de software.
O nível 2, foco deste artigo, é designado como “Geren-
ciado”. De acordo com o CMMI, quando uma organização
atinge este nível, seus projetos são executados conforme
os processos estabelecidos na organização, obedecendo
às suas políticas organizacionais. Os profissionais desta
organização possuem, além da capacidade adequada para
executar seus trabalhos, os recursos adequados para ge-
rarem produtos controlados. Além disso, os projetos são
planejados, controlados e revistos com os stakeholders (veja
a Nota 1). Uma área responsável pela qualidade examina
constantemente a aderência dos projetos aos processos esta-
belecidos. A disciplina do processo refletida pelo nível 2 aju-
da a garantir que as práticas estabelecidas sejam mantidas
em momentos de stress. Também neste nível, os status dos
produtos de trabalho são visíveis para a gestão em pontos
definidos (por exemplo, em milestones ou na finalização de
tarefas maiores); compromissos são estabelecidos entre os
stakeholders e são revistos sempre que necessário; os produtos
de trabalho são apropriadamente controlados; e por fim, os
produtos e serviços satisfazem suas descrições de processos,
normas e procedimentos especificados.
Nota 1: Stakeholders
É o termo utilizado para designar todos os interessados nos resultados de um projeto. Portanto,
abrange a equipe do projeto, a organização que o mantém, as organizações que o contratam e,
de forma mais abrangente, os elementos da sociedade que serão afetados por ele.
É fácil visualizar, portanto, que no nível 2 a organização
consegue muito mais controle sobre os seus projetos e obtém
muito mais vantagens daquilo que faz. Existe menor chance
do aparecimento de problemas decorrentes da desorgani-
zação, da falta de método e de informação, e a relação entre
os membros da equipe dos projetos e destes com os clientes
melhora muito do ponto de vista do fluxo das informações e
da cadeia produtiva.
Exploraremos os demais níveis em próximos artigos, com-
pondo desta forma um pequeno estudo de análise do CMMI,
sempre realizando um paralelo com a realidade das empresas
de software. Na próxima seção, apresentaremos uma visão
geral das áreas de processo do nível 2.

As áreas de processo do nível 2
Cada nível do CMMI é composto por um conjunto de áreas de
processos que, sendo todas seguidas, fornecem à organização a
maturidade e capacidade esperadas por aquele nível. A Figura 2
apresenta as áreas de processos que constituem o nível 2.
Figura 2. «SFBT
EF
1SPDFTTP
EP
OÓWFM

EP
$..*
Uma área de processo do CMMI é um conjunto de práti-
cas relacionadas em uma área que, quando implementadas
coletivamente, satisfazem um conjunto de metas considera-
das importantes para a tomada de melhoria nessa área. Por
exemplo, a área de processo Gestão de Requisitos traz um
conjunto de práticas que orientam para a melhoria na área
de Requisitos. O nível 2 é composto por áreas de processos
consideradas fundamentais para uma engenharia de software
realizada com qualidade e controle. Daí a sua designação ser
“gerenciado”. Sem implementar tais áreas, uma organização
não conseguirá atingir os níveis de maturidade mais altos
propostos pelo modelo.
Cada área de processo possui um objetivo, metas específicas
da área e metas genéricas, que abrangem todas as áreas de pro-
cesso. Estas metas constituem as boas práticas de engenharia
de software mencionadas no início deste artigo.
Muitas empresas interessadas em adotar o CMMI têm dúvida
sobre o propósito deste modelo. Se ele determina o quê deve
ser feito e como deve ser feito. Primeiramente, diríamos que
o CMMI recomenda, não determina. Mesmo em situações em
que uma organização está sendo avaliada em algum nível do
modelo, a postura do avaliador é sempre a de quem recomenda
as boas práticas. Obviamente, se a organização não atender às
recomendações, não conseguirá sua certificação, mas poderá
continuar melhorando o seu processo até obtê-la.
Segundo, o CMMI informa o que espera que seja praticado
em cada área de processo, mas não se prende ao como isso
será feito. Para o nível 2, se a organização utiliza planilhas, e
não um sistema gerencial, de maneira geral isso não afetará a
sua avaliação final. Se ela desenvolve em Java, e não em .NET,
também não importa, e assim por diante. Naturalmente, em
se tratando de níveis mais altos, como o 4 e o 5, a utilização
de algumas ferramentas é essencial, como um banco de dados
para o armazenamento de medições e um sistema gerencial
para os projetos da organização. Mas mesmo nestes níveis não
há determinação específica do CMMI dando detalhes sobre
estas ferramentas.
Estruturado desta forma, o CMMI torna-se, portanto, um mo-
delo, um guia para as boas práticas da engenharia de software.
AG IL I DAD E
Esclarecidos estes conceitos, vamos analisar detalhadamente
cada uma das áreas de processo do nível 2, começando pela
Gestão de Requisitos.
Gestão de Requisitos
Requisitos é a chave para o sucesso de todo projeto de
software. Por isso, requisitos bem elicitados e claramente
especificados são um excelente começo para um software de
qualidade e que satisfaça aos seus clientes. Da mesma forma,
requisitos mal compreendidos e pobremente especificados
são fontes de grandes riscos de retrabalho e mudanças des-
controladas no desenvolvimento. Várias organizações ainda
não deram a devida atenção a esta área, motivo pelo qual têm
experimentado as mais diversas dificuldades em seus ciclos
de vida de desenvolvimento de software, onde muitas vezes
a causa aparente é a falta de gestão ou questões técnicas de
desenvolvimento, quando na verdade reside em requisitos mal
especificados e pobremente descritos.
De acordo com o CMMI, o objetivo da área de processo
Gestão de Requisitos é “fornecer subsídios para gerenciar
os requisitos dos produtos e componentes de produto do
projeto e identificar inconsistências entre esses requisitos
e os planos e produtos de trabalho do projeto”. Portanto,
o foco desta área de processo está em gerenciar requisitos
e identificar inconsistências entre requisitos e os planos e
produtos do projeto.
As práticas específicas (veja a Nota 2) desta área de processo
são as seguintes:
SG 1 Gerenciar Requisitos
SP 1.1 Obter Entendimento dos Requisitos
SP 1.2 Obter Comprometimento com os Requisitos
SP 1.3 Gerenciar Mudanças nos Requisitos
SP 1.4 Manter Rastreabilidade Bidirecional dos Requisitos
SP 1.5 Identificar Inconsistências entre Produtos de Trabalho e
Requisitos
Nota 2: Práticas específicas
Toda área de processo do CMMI possui suas práticas específicas (specific practices, abreviadas
por “SP”), que são as atividades esperadas para satisfazer as metas específicas (specific goals,
abreviadas por “SG”) daquela área de processo.
Dentre elas, podemos destacar a prática SP 1.2, referente
ao comprometimento com os requisitos. É muito comum as
empresas que desenvolvem software não se lembrarem de
obter este comprometimento, o que dá margem para altera-
ções descontroladas dos requisitos. Por isso, a necessidade
de implantar-se também a prática SP 1.3, para gerenciar estas
mudanças. Mudanças não controladas de requisitos podem
causar o naufrágio de um projeto.
Por fim, podemos destacar a rastreabilidade bidirecional
dos requisitos (SP 1.4), uma técnica que consiste em associar
os componentes de projeto e produto com os requisitos que
lhe deram origem. Esta é a técnica mais útil para a análise de
impacto de mudanças de requisitos.
Edição 47 - Engenharia de Software Magazine 41
 Planejamento de Projeto e Monitoramento e Controle de
Projeto
É desnecessário destacar a importância da gestão de projetos
para as organizações de qualquer natureza, dentre elas as que
produzem software, pois inúmeros artigos e livros já foram
escritos a esse respeito. Atualmente é senso comum saber que
as técnicas de gestão de projetos são essenciais para a condução
das empreitadas cada vez mais complexas nas organizações.
Porém, colocar em prática tais técnicas tem sido um desafio
constante para muitas delas. Neste sentido, as duas áreas de
processo do nível 2 referentes à gestão de projetos possuem
um ótimo roteiro do caminho a seguir.
De acordo com o CMMI, o objetivo da área de processo Pla-
nejamento de Projeto é “fornecer subsídios para estabelecer
e manter planos visando definir as atividades de projeto”. O
objetivo da área de processo Monitoramento e Controle de
Projeto é “fornecer subsídios para proporcionar visibilidade
do progresso do projeto, de forma que ações corretivas apro-
priadas possam ser implementadas quando o desempenho
do projeto desviar significativamente do plano”. Portanto, o
CMMI confirma as duas práticas fundamentais da gestão de
projetos: o planejamento e o controle. Muitos profissionais in-
cumbidos de gerenciar projetos são bons em planejamento, mas
displicentes no controle. Outros planejam superficialmente e
depois precisam controlar arduamente o projeto, para evitar
os vários riscos adicionados.
Como essas duas áreas de processo possuem muitas
práticas específicas, vamos destacar aquelas que considera-
mos principais, iniciando pelas práticas da área de processo
Planejamento de Projeto:
SG 1 Estabelecer Estimativas
SP 1.1 Estimar o Escopo do Projeto
SP 1.4 Estimar o Esforço e Custo
SG 2 Elaborar um Plano de Projeto
SP 2.1 Estabelecer Orçamento e Cronograma
SP 2.2 Identificar Riscos do Projeto
SP 2.7 Estabelecer o Plano do Projeto
SG 3 Obter Comprometimento com o Plano
SP 3.2 Conciliar Carga de Trabalho e Recursos
As práticas SP 1.1 e SP 1.4 tratam de duas atividades fun-
damentais para o sucesso de todo projeto: as estimativas de
escopo, esforço e custo. Segundo o PMBOK, o escopo do projeto
define o trabalho que deve ser realizado para entregar um
produto com as características e funções especificadas. Por
isso, um escopo mal estimado significa um projeto sem norte
e sem destino certo. Neste cenário, é muito comum a execução
de trabalhos não previstos, muitas vezes com a ocorrência de
horas-extras, onerando os custos do projeto e reduzindo as
suas margens financeiras.
A prática SP 2.1 estabelece as questões do orçamento e crono-
grama. O orçamento de um projeto diz respeito aos recursos
financeiros que estão disponíveis para a execução do seu
42 Engenharia de Software Magazine - Gerenciando com o CMMI 2
escopo. É muito comum vermos orçamentos que incluem ape-
nas despesas de pessoal (homem/hora) e não levam em conta
outras despesas, tais como: aquisição de hardware específico,
licenças de software, viagens, cursos, etc. Essa omissão terá
impacto imediato nas margens financeiras do projeto, muitas
vezes catastrófico. Por sua vez, o cronograma é o reflexo do
escopo com as restrições de orçamento. Um ponto importante
a destacar é: todo cronograma deve ir até o nível mais deta-
lhado de tarefas. Se houver tarefas a executar e que não estão
no cronograma, surge o risco de desvio das estimativas de
esforço, prazo e custo do projeto.
A prática SP 2.2 trata da identificação dos riscos do projeto.
Eis uma área em que as organizações brasileiras têm muito
ainda o que aprender e praticar! Riscos são constantemente
ignorados nos projetos de TI! Quando muito, são planejados,
mas muito raramente acompanhados. O CMMI dá a atenção
devida aos riscos de projetos, já no seu nível 2.
A prática SP 2.7 determina o estabelecimento do plano do pro-
jeto. Pode parecer óbvio, mas não é, pois ainda há organizações
que resumem o plano a um cronograma. É importantíssima a
elaboração de um plano de projeto nos moldes indicados pelo
PMBOK, podendo ser adaptado à cultura da organização. Além
disso, devemos ter ciência de que o termo “plano do projeto”
não se resume a apenas um documento, mas a um conjunto
de documentos, tais como declaração do escopo, estimativas,
plano de riscos, plano de comunicação, plano de custos, etc.
Daí a importância de desenvolver-se a cultura de uma docu-
mentação rica, que estabeleça com clareza o que será feito, por
quem, como, quando e quanto custará.
Por fim, a prática SP 3.2 diz respeito ao estabelecimento de
um comprometimento com o plano do projeto. Segundo o
CMMI, para estabelecer um projeto viável, deve-se obter o
comprometimento das partes interessadas relevantes e conci-
liar as diferenças entre os recursos estimados e os disponíveis.
Sem este consenso sobre o plano, muitos dissabores poderão
ser experimentados, tanto por parte de quem contrata quanto
de quem é contratado, pois falsas expectativas são criadas em
torno de uma visão equivocada do projeto.
Vamos agora analisar algumas práticas que destacamos da
área de processo Monitoramento e Controle do Projeto:
SG 1 Monitorar o Projeto em Relação ao Plano
SP 1.1 Monitorar os Parâmetros de Planejamento do Projeto
SP 1.3 Monitorar Riscos do Projeto
SP 1.5 Monitorar o Envolvimento das Partes Interessadas
SP 1.6 Conduzir Revisões de Progresso
SG 2 Gerenciar Ações Corretivas até sua Conclusão
SP 2.1 Analisar Questões Críticas
SP 2.2 Implementar Ações Corretivas
SP 2.3 Gerenciar Ações Corretivas
As práticas SP 1.1 a SP 1.6 dizem respeito ao monitoramento
do projeto. Da mesma forma que dissemos em relação aos
riscos, o plano de um projeto não pode estacionar no seu
planejamento, mas deve ser continuamente monitorado, pois

planejar significa estabelecer estimativas (de escopo, prazo,
esforço, custo, riscos, equipe, complexidade, etc.) e sabemos
que estimativas não são 100% precisas, por mais experiente
que seja aquele que as estabeleceu. Portanto, é fundamental
acompanhar o projeto em relação ao que foi planejado e realizar
as ações corretivas necessárias.
As práticas SP 2.1 a SP 2.3 tratam das ações corretivas. É
comum encontrarmos Gerentes de Projeto que, ao encontra-
rem desvios do plano na execução do projeto, simplesmente
re-planejam o projeto para aquela nova realidade. Tal prática é
um equívoco! Desvios devem ser corrigidos da melhor forma
possível, por isso a importância do estabelecimento de ações
corretivas e o seu acompanhamento até o fim. Replanejamentos
dizem respeito a mudanças de escopo, o que está em outro
contexto.
Gestão de Configuração
Atualmente, trabalhar sem gestão de configuração é prati-
camente impossível. Ao construírem sistemas cada vez mais
complexos, as organizações se veem diante de uma infinidade
de arquivos referentes a código-fonte, modelos, requisitos e
documentação de projeto, dentre outros. Como não bastasse
essa complexidade, todo esse universo de arquivos é modifi-
cado continuamente ao longo do projeto. Caso a organização
não aplique técnicas e ferramentas de gestão de configuração,
muitos desses arquivos podem ser perdidos, bem como todo
o histórico de modificações realizado.
Aliadas às técnicas propostas pelo CMMI, existem no mer-
cado algumas excelentes ferramentas para gestão de configu-
ração, com destaque para o Subversion (SVN).
De acordo com o CMMI, o objetivo da área de processo Gestão
de Configuração é “fornecer subsídios para estabelecer e man-
ter a integridade dos produtos de trabalho, utilizando iden-
tificação de configuração, controle de configuração, balanço
das atividades de configuração e auditorias de configuração”.
Discutiremos estas técnicas a partir das práticas específicas
desta área de processo, que estão listadas a seguir:
SG 1 Estabelecer Baselines
SP 1.1 Identificar Itens de Configuração
SP 1.2 Estabelecer um Sistema de Gestão de Configuração
SP 1.3 Criar ou Liberar Baselines
SG 2 Acompanhar e Controlar Mudanças
SP 2.1 Acompanhar Solicitações de Mudança
SP 2.2 Controlar Itens de Configuração
SG 3 Estabelecer Integridade
SP 3.1 Estabelecer Registros de Gestão de Configuração
SP 3.2 Executar Auditorias de Configuração
As práticas SP 1.1 a SP 1.3 dizem respeito ao conceito de itens
de configuração e baselines. O conceito de baselines é muito
confundido e pobremente compreendido pelas organizações
pouco familiarizadas com a gestão de configuração. O CMMI
define baseline como sendo um “conjunto de especificações ou
AG IL I DAD E
produtos de trabalho formalmente revisados e acordados, que
servem como base para desenvolvimentos a partir de então”.
Por isso compreendemos a baseline como sendo uma “foto”
do projeto e seus produtos em um momento considerado im-
portante no ciclo de vida do projeto e do produto. A baseline
nos dá recursos de resgatarmos esse conjunto de produtos
de trabalho arquivado nos pontos importantes e mantidos
tais quais eram naquele momento. Neste contexto, os itens
de configuração são os produtos de trabalho ou conjuntos
de produtos que participam de uma baseline. Baseline é um
conceito poderoso da gestão de configuração, que ajuda a
reduzir os riscos de projeto e adiciona muita consistência aos
seus produtos de trabalho.
As práticas SP 2.1 e SP 2.2 tratam do controle de mudanças,
um assunto extremamente crítico em qualquer projeto de sof-
tware. Segundo Fred Brooks (1986), os softwares estão sujeitos
a solicitações de mudanças muito mais frequentemente do que
outros produtos ditos concretos, tais como carros, edifícios e
eletrônicos. Isso porque o software, sendo um produto flexível,
ou seja, que pode ser modificado muito mais facilmente do
que outros produtos, dá aos seus clientes uma falsa impressão
de que é fácil de ser modificado. Por este motivo, controlar e
gerenciar mudanças são uma prática vital para a saúde dos
projetos. Como dito anteriormente, mudanças descontroladas
podem ser a causa de insucesso de uma enorme parcela de
projetos que não dão certo.
Por fim, um aspecto elegante desta área de processos é que
ela contém em si uma prática específica de auditoria (SP 3.2),
visando garantir que todo o sistema de gestão de configuração
esteja funcionando conforme o esperado.
Medição e Análise
A máxima “Você não pode controlar o que não pode medir”,
cunhada pelo autor americano Tom DeMarco, é uma das
mais famosas e repetidas na engenharia de software. Ela dá a
dimensão exata da importância da área de processo Medição
e Análise.
Para controlar eficientemente qualquer aspecto da engenharia
de software é preciso conhecê-lo em detalhes, e isso só é possí-
vel através da atividade de medição e análise. Muitas organi-
zações ainda desenvolvem software sem coletar nem analisar
nenhum tipo de medição sobre as atividades realizadas e os
produtos gerados pelas suas equipes. Infelizmente, essa é uma
forma muito eficiente de inserir grandes riscos aos projetos e
produtos. E, ao contrário do que muitas delas imaginam, medir
e analisar são práticas acessíveis a qualquer organização, desde
que seja especificado um processo para isso.
De acordo com o CMMI, o objetivo da área de processo
Medição e Análise é “fornecer subsídios para desenvolver e
manter uma capacidade de medição utilizada para dar suporte
às necessidades de informação para gestão”. Portanto, esta
área de processo suporta diretamente as áreas de processo de
gestão, daí a sua importância vital.
Discutiremos a seguir as práticas específicas desta área de
processo:
Edição 47 - Engenharia de Software Magazine 43
 SG 1 Alinhar Atividades de Medição e Análise
SP 1.1 Estabelecer Objetivos de Medição
SP 1.2 Especificar Medidas
SP 1.3 Especificar Procedimentos de Coleta e Armazena-
mento de
Dados
SP 1.4 Especificar Procedimento de Análise
SG 2 Fornecer Resultados de Medição
SP 2.1 Coletar Dados Resultantes de Medição
SP 2.2 Analisar Dados Resultantes de Medição
SP 2.3 Armazenar Dados e Resultados
SP 2.4 Comunicar Resultados
As práticas SP 1.1 a SP 1.4 são referentes à especificação do
modelo de medição da organização. Este modelo deverá ser
composto de medidas (ou métricas), que devem ser especifi-
cadas de acordo com os objetivos estratégicos da organização.
Por exemplo, uma medida do tipo “Quantidade de versões
intermediárias geradas” pode não significar nada caso a or-
ganização só se interesse pelas versões finais.
A especificação das medidas deverá ir além de seu nome e
descrição. Deverá conter detalhes sobre a forma de coletá-las,
onde encontrar os seus dados e onde armazenar o resultado
final da medição, além de valores de referência para o que
está sendo medido. Se nos depararmos com uma medição de
20 horas, coletada para a métrica “Número de horas médio de
especificação em projetos”, não saberemos muito bem se este
valor é bom ou ruim se não tivermos um valor de referência
especificado para ele. Da mesma forma, esse valor poderá ser
visto como muito bom para uma organização que estabeleceu
como referência o valor de 40 horas e um tanto preocupante
para outra que estabeleceu o valor de 15 horas. Portanto, não
existem medidas certas ou erradas, nem valores bons ou ruins,
tudo depende das especificações e dos objetivos estratégicos
da organização que especifica tais medidas.
As demais práticas, SP 2.1 a SP 2.4, tratam da execução do
modelo de medições especificado. O CMMI propõe o ciclo
básico de medições: coletar, analisar, armazenar e comunicar.
Dificilmente um processo de medições executará um ciclo
muito diferente desse.
Garantia da Qualidade de Processo e Produto
O termo “qualidade” passou a ser muito referenciado no
Brasil a partir da década de noventa, com a popularização
da norma ISO 9001 e sua adoção por praticamente todos os
setores da indústria brasileira, incluindo o setor de softwa-
re. Pouco depois, o CMMI começa a ser considerado como
modelo de referência de qualidade de processos, até atingir
a ampla adoção atual nas empresas de software brasileiras.
Nesse meio tempo, surge o MPS.BR (Melhoria de Processo do
Software Brasileiro), um modelo nacional alternativo ao CMMI
e plenamente compatível com ele, e também com as normas
ISO 12207 (Engenharia de Software e Sistemas – Processos
de Ciclo de Vida de Software) e ISO 15504 (Tecnologia da
44 Engenharia de Software Magazine - Gerenciando com o CMMI 2
Informação – Avaliação de Processos). A partir daí, o MPS.BR
passa a ser também amplamente adotado pelas organizações
brasileiras.
Portanto, esse é o cenário de valorização da qualidade no
Brasil, que vem sendo ampliado a cada ano. Organizações
compradoras de software, tanto públicas quanto privadas, têm
demandado cada vez mais certificações de qualidade das suas
empresas fornecedoras. Assim, não ser capaz de comprovar
sua própria qualidade é uma grande perda competitiva para
qualquer empresa de software. Neste sentido, o nível 2 do
CMMI fornece um excelente processo de qualidade, através
de sua área de processo Garantia da Qualidade de Processo
e Produto.
De acordo com o CMMI, o objetivo dessa área é “fornecer visi-
bilidade para a equipe e gerência sobre os processos e produtos
de trabalho associados”. Ou seja, o foco desta área é na garantia
interna da qualidade, que irá refletir-se consequentemente na
percepção da qualidade pelos clientes.
Vejamos as práticas específicas desta área:
SG 1 Avaliar Objetivamente Processos e Produtos de
Trabalho
SP 1.1 Avaliar Objetivamente os Processos
SP 1.2 Avaliar Objetivamente Produtos de Trabalho
SG 2 Fornecer Visibilidade
SP 2.1 Comu n ica r e Asseg u ra r a Solução de Não
Conformidades
SP 2.2 Estabelecer Registros
A prática SP 1.1 trata da avaliação objetiva dos processos. Es-
tão presentes aí dois conceitos importantes. Primeiro, o termo
“avaliação objetiva”. Objetividade em avaliações de qualidade
significa que critérios devem ser claramente definidos, para
que as avaliações não se tornem subjetivas, prejudicando o
objetivo maior, que é fornecer a visibilidade sobre os processos
e produtos de trabalho. Segundo, trata-se de uma avaliação de
processos. Isso significa “avaliar objetivamente os processos
selecionados em relação às descrições de processo, padrões e
procedimentos aplicáveis”, segundo o CMMI. As organizações
que ainda estão se iniciando na implantação de processos de
qualidade podem dar-se por satisfeitas em avaliar apenas
processos, esquecendo-se ou ignorando o conceito de avaliação
de produtos, que veremos na prática seguinte.
A prática SP 1.2 complementa a SP 1.1 fornecendo orientações
para a avaliação de produtos de trabalho. Um produto de
trabalho é tudo aquilo que é produzido pelas atividades de
um processo. Portanto, abrange toda a documentação gerada,
tanto de projeto quanto de requisitos, arquitetura, testes, etc.
E este é o ponto chave: os produtos são mais visíveis para os
clientes do que o processo. Por isso, essa prática não pode
ser ignorada nem praticada superficialmente. Obviamente, a
garantia do processo não possui menor importância, pois é
o processo que gera os produtos. O que pretendemos alertar
aqui é a boa prática de conduzir estes dois tipos de avaliação
paralelamente.

Através das práticas SP 2.1 e SP 2.2, a área de qualidade de
uma organização reporta os achados da qualidade, ou seja, as
chamadas não-conformidades, para os interessados, que são
os gerentes de projeto e suas equipes e os níveis superiores
de gestão. Além disso, garantem que as não-conformidades
sejam resolvidas. Para atingir esse objetivo, é necessária a
geração de relatórios claros e detalhados sobre o estado dos
processos e produtos de trabalho. Estes relatórios devem
ser divulgados para todos os interessados. Além disso, não-
conformidades que não são resolvidas no prazo estabelecido
devem ser escalonadas para os níveis superiores de gestão,
para que sejam sanadas.
Gestão de Contrato com Fornecedores
Neste artigo, não abordaremos esta área de processo pois
desejamos explorá-la detalhadamente em um próximo ar-
tigo, dada a sua importância no cenário atual do mercado
brasileiro.
Conclusão
Neste artigo fornecemos uma visão geral sobre o modelo
CMMI, seus principais conceitos e sua estrutura em níveis
de maturidade. Analisamos mais detalhadamente o nível 2,
cujo foco é fornecer um conjunto de áreas de processo, prá-
ticas específicas e genéricas que permitam às organizações
estabelecerem um processo gerenciado. Na visão deste artigo,
a adoção do nível 2 do CMMI fornece às organizações as se-
guintes vantagens:
• Utilização de um conjunto de áreas de processo que estabele-
cem os fundamentos essenciais para a produção de softwares
com a qualidade cada vez mais exigida pelo mercado;
• Adoção de boas práticas consagradas no mercado mundial
de produção de software;
• Redução dos problemas típicos na produção de software, as-
sociados a organizações imaturas em processos de software;
AG IL I DAD E
• Aumento da visibilidade de seus processos de software e na
percepção de qualidade por parte de seus clientes;
• Ampliação de sua capacidade de concorrência, com a adoção
de um modelo referência de mercado;
• Estabelecimento de um processo gerenciado e visível, prepa-
rando a organização para alçar patamares maiores de maturi-
dade, com a adoção dos próximos níveis do CMMI.
Nos próximos artigos, continuaremos a analisar os níveis do
CMMI, dando destaque ao nível 3 e sua capacidade de tornar
o processo organizacional definido.
Links
Site oficial do CMMI
http://www.sei.cmu.edu/cmmi/index.cfm
Documentação oficial do CMMI-DEV, v. 1.3
http://www.sei.cmu.edu/reports/10tr033.pdf
Site oficial do MPS.BR
http://www.softex.br/mpsbr/_home/default.asp
PMBOK Guide no site do PMI
http://www.pmi.org/PMBOK-Guide-and-Standards.aspx
Link para o artigo “No Silver Bullet: Essence and Accidents of Software Engineering”
http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html
Livro oficial do CMMI
CHRISSIS,M.B.; KONRAD,M.D.; SHRUM,S.CMMI for Development:Guidelines for Process Integration
and Product Improvement, Third Edition. Addison-Wesley Professional, 2011. 688 p.
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
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback
Edição 47 - Engenharia de Software Magazine 45