O USO DAS SETE FERRAMENTAS DA QUALIDADE NA

IMPLANTAÇÃO DO CAPABILITY MATURITY MODEL

Alfredo Colenci Neto

Universidade de São Paulo
Escola de Engenharia de São Carlos – EESC

Dr. Edson Waldir Cazarni

Universidade de São Paulo
Escola de Engenharia de São Carlos – EESC

Abstract

This paper presents a study of the seven tools of the quality as aid in the implantation the model of
quality Capability Maturity Model applied in the process of software development. This study is gone back to
the small organizations that have difficulties in the implementation of the model.

Key-Words: Capability Maturity Model, CMM, Qualidade de Software, Ferramentas da Qualidade.

Tema: Gestão da Qualidade/Produtividade

Introdução

Uma das evoluções mais importantes no estudo da qualidade, foi justamente, notar
que a qualidade do produto depende diretamente da qualidade de seu processo de
desenvolvimento.
O melhoramento da qualidade em software é a busca contínua para descobrir as
causas básicas das falhas de produtos e serviços além da prevenção de erros, e não a
correção destes bugs. O melhoramento da qualidade leva a diminuição dos custos devido a
diminuição de operação de depuração e retrabalho, aumentando-se a produtividade,
habilidades de manutenção, fazendo com que a empresa ou departamento cresça em
tamanho e lucratividade. ARTHUR (1994).
Na maioria das organizações ao ocorrer um problema, reage-se consertando-o, quer
seja importante ou não. O único critério parece ser a urgência do cliente. A qualidade exige
que toda a organização aprenda como consertar os problemas com maior efetividade. Ela
também exige que não se conserte apenas os sintomas observáveis do problema mas que se
desloque o núcleo dos esforços da resolução de problemas para suas causas básicas -
defeitos do processo que, em primeiro passo, produziram ou melhoraram o programa.
Torna-se necessário, portanto, entender que o problema não é intrínseco ao software,
mas principalmente à forma com que as pessoas o têm desenvolvido. Partindo-se desta
necessidade surgiram no mercado diversos modelos de qualidade relacionados ao processo
de desenvolvimento e não ao produto final.
Os modelos mais conhecidos são o Bootstrap, Trilium, Spice e o Capability Maturity
Model que se destaca pela sua literatura bem definida e sua flexibilidade na
implementação.
 O grande desafio do CMM, nos dias atuais, é achar mecanismos que auxiliem sua
implantação nas pequenas e médias empresas, que hoje, contribuem com 63,6% da
produção de software no Brasil, segundo o Ministério da Ciência e Tecnologia, MCT
(1999). Desta forma, propõe-se neste trabalho a utilização das 7 ferramentas básicas da
qualidade.

CMM - Capability Maturity Model

O SW-CMM (Software CMM) é atualmente o modelo de qualidade mais

divulgado, tem tido uma considerável adoção por organizações e produtores de software de
diversos portes em todo o mundo, Segundo JAMIL (1999). Origina-se de pesquisas e
trabalhos do Software Engineering Institute (SEI) da Carnegie Mellon University,
notadamente de Watts Humphrey, pesquisador vindo da IBM, que trabalhou com as teses
de qualidade de processo de Philip Crosby, Edwards Deming e Joseph Juran. Seus
trabalhos objetivaram adaptar uma metodologia de qualidade de processos para a área de
software, visando que esta pudesse ser adotada por órgãos do governo americano para a
contratação de produção externa de software, no sentido de estabelecer um nível de
maturidade que o prestador de serviços deveria ter para atender estas demandas.
A estrutura de estágios de maturidade do CMM está baseada nos princípios de
qualidade de produto, desenvolvidos nos últimos 60 anos. O CMM é uma aplicação dos
conceitos de gerência de processos do Total Quality Management – Gerenciamento da
Qualidade Total (TQM) para o software.
Estes princípios estão sendo adaptados pelo SEI, dentro de uma estrutura de
maturidade que estabelece um embasamento de engenharia e de gerência de projeto,
visando o controle quantitativo do processo de software. Esta estrutura de maturidade é a
base para a melhoria contínua de processo, FIORINI (1998).

Estrutura do CMM

A estrutura do SW-CMM é composta por 5 níveis, chamados de níveis de

maturidade, que são: Inicial, Repetível, Definido, Gerenciado e Otimizado. Cada nível de
maturidade é composto por áreas chave de processo (KPA). Cada área-chave de processo é
organizada em cinco seções denominada características comum. As características comuns
especificam as práticas-chave que cumprem os objetivos da área-chave do processo.
Níveis de Maturidade – São estágios de evolução bem definidos, no caminho para
se obter um processo de software maduro.
Áreas-Chave de processo – Identificam as questões que devem ser consideradas
para se alcançar um nível de maturidade. Para alcançar um determinado nível de
maturidade, todas as áreas-chaves do processo do nível em questão devem ser satisfeitas.
Características Comuns – por conveniência, as área-chave de processo são
organizadas por características comum. As características comuns são atributos que
indicam se a implementação e a institucionalização de uma área-chave de processo é
efetiva, repetível e duradoura. As características comuns são divididas em:
1- Habilidade de realizar: Descrevem as pré-condições que devem existir no projeto
ou na organização para que o processo de software seja implementado
competentemente.
2- Atividades Realizadas: Descrevem as atividades, papéis e procedimentos
necessários para implementar uma área chave de processo.
3- Medições e Análises: descrevem as necessidades para medir o processo e analisar
as medidas. Essas medidas são usadas para melhorar e controlar o processo.
 4- Verificação da Implementação: Descrevem os passos para assegurar que as
atividades sejam realizadas em conformidade com o processo que foi estabelecido.
5- Comprometimentos para realizar: Descrevem as ações que a organização deve tomar
para assegurar que o processo seja estabelecido e que perdure.
Práticas – Chave: As práticas chave descrevem as técnicas que contribuem para a
implementação e institucionalização efetiva da área–chave de processo. Cada Prática-
Chave constitui de uma única sentença, frequentemente seguida por uma descrição
detalhada, a qual pode incluir exemplos. A práticas-chave descrevem “o que” deve ser
feito, mas não especifica “como”.
Os 5 níveis de maturidade e sua características são mostrados no quadro abaixo:

Nível CMM Características

1) Inicial O processo de desenvolvimento é desorganizado e até caótico. Poucos
processos são definidos e padronizados e o sucesso depende de esforços
individuais e heróicos dos desenvolvedores.
2) Repetitivo Os processos básicos de gerenciamento de projeto estão estabelecidos e
permitem acompanhar custo, cronograma e funcionalidade e possível
repetir o sucesso de um processo já utilizado anteriormente.
3) Definido Tanto as atividades de gerenciamento quanto de engenharia do processo
de desenvolvimento de software estão documentadas, padronizadas, e
integradas em um padrão de desenvolvimento da organização. Todos os
projetos utilizam uma versão aprovada e adaptada do processo padrão de
desenvolvimento de software da organização.
4) Gerenciado São coletadas medidas detalhadas da qualidade do produto e processo de
desenvolvimento de software. Tanto o produto Quanto o processo de
desenvolvimento são entendidos e controlados quantitativamente.
5) Otimizado O melhoramento contínuo do processo é conseguido através de um
feedback quantitativo dos processos e pelo uso pioneiro de idéias e
tecnologias inovadoras.
Quadro 1: Visão dos Níveis de Maturidade do CMM
Fonte: PAULK et al. (1993)

Como visto, tem-se as práticas-chave na estrutura do CMM, que são ações efetivas
que devem ser tomadas no sentido de se atingir cada umas das áreas-chaves do processo. A
literatura do CMM não especifica técnicas, ferramentas ou qualquer tipo de recurso à ser
utilizado nas práticas chave. Por ser um modelo bastante flexível e adaptável as
organizações. A utilização de qualquer tipo de ferramenta fica a critério das empresas para
poder utilizar os recursos mais cabíveis.
Desta forma, propõe-se aqui a utilização das 7 ferramentas básicas da qualidade
como forma de auxílio para as empresas de pequeno e médio porte na aplicação das
práticas chave, já que estas ferramentas possuem um baixo custo administrativo o que
facilitará sua implementação na pequenas organizações.

As 7 Ferramentas da Qualidade

As sete ferramentas básicas do melhoramento da qualidade incluem as Folhas de

Verificação, Gráficos de Paretto, Diagrama de Ishikawa, Diagrama de Pontos, Histograma
e Gráficos de Controle e Gráfico de Fluxo.
 Usando as três primeiras, podemos resolver 85 % de todos os problemas de
qualidade. As outras quatro ajudam a resolver a maior parte dos problemas remanescentes,
segundo ARTHUR (1994).
FAESARELLA (1998), defende que as ferramentas da qualidade, podem vir a ser
aplicadas na implementação as ações nas diferentes fases do ciclo de produção.
Os próximos tópicos destacam cada ferramenta particularmente.

Folha de Verificação

Técnica utilizada quando se deseja obter dados, baseados em observações amostrais.

Para definição de um modelo. É o ponto de partida na maioria dos ciclos de solução de
problemas, sendo uma ferramenta de fácil compreensão que mostra a frequência com que
certos eventos ocorrem.
As folhas de verificação tem como objetivo:
a) Verificação do processo de desenvolvimento;
b) Verificação de itens defeituosos;
c) Verificação da localização dos defeitos;
d) Verificação das causas dos defeitos.

Diagrama de Paretto

O princípio de Paretto está na base do diagrama do mesmo nome que foi inicialmente
definido por Joseph Juran em 1950. O nome desta ferramenta da qualidade provem de um
economista italiano chamado Vilfredo Paretto, que analisando a sociedade notou que a
grande parte da riqueza estava nas mãos de um número pequeno de pessoas, em uma
relação de [20:80]. Juran descobriu que este princípio estava válido em muitas áreas da
vida cotidiana, e podia ser usado com sucesso nas técnicas de qualidade.
Em termos simplificados, o princípio de Paretto diz-nos que a maioria dos efeitos está
relacionado com um número reduzido de causas. Podemos, portanto, dizer que 80% dos
problemas são causados por 20% das máquinas, materiais ou pessoas; Juran descreveu os
20% das causas como sendo os “essenciais e poucos” e os restantes 80% chamou-lhes as
“muitas vulgares”.

Diagramas de Ishikawa

Este diagrama é muitas vezes designado por “Diagrama de Causa e Efeito” ou

“Diagrama de Espinha de Peixe” em decorrência da sua forma. O primeiro diagrama de
Causa e Efeito foi desenvolvido pelo Dr. Kaoru Ishikawa, em 1943, quando explicava a
alguns engenheiros de uma empresa japonesa (Kawasaki Steel Works) como é que diversos
fatores (causas) podiam ser ordenados de uma forma lógica.
O seu objetivo é relacionar as causas com os efeitos.
As causas gerais têm uma influência direta no problema a ser resolvido. As causas de
nível 1 afetam diretamente a respectiva causa geral. Desta forma se constrói todo o
diagrama. Facilmente se entende que o diagrama de Ishikawa é uma ferramenta adequada
para trabalhos em equipe. Não é, portanto, de admirar que o Dr. Kaoru Ishikawa seja
considerando o pai dos círculos de qualidade, pois o diagrama facilita o brainstorming da
equipe da qualidade.

Histograma
 Com os crescentes graus de automação industrial, são cada vez maiores as quantidades
de dados recolhidos e arquivados. Contudo estes elementos de pouco ou nada servirão se
não forem devidamente trabalhados ou examinados. Torna-se extremamente difícil, se não
impossível, para os operadores tirar qualquer ensinamento de uma enorme pilha de
números. O mesmo já não acontece se esses mesmos números forem convertidos num
gráfico que ilustra a frequência relativa com que os diversos tipos de valores foram
obtidos. Tais gráficos dão-se pelo nome de histogramas, permitindo obter uma impressão
visual preciosa sobre a dispersão e localização dos valores recolhidos.
A construção de um histograma possui cinco passos ou etapas. A primeira etapa consiste
em agrupar e contar os dados. De seguida vamos achar o valor máximo e mínimo. Isto vai
permitir sabermos o intervalo de valores a serem considerados.

Gráficos de Controle

Os gráficos de controle, também conhecidos como cartas de controle fornecem

informações sobre um dado processo, com base em amostras periodicamente coletadas
dele. As amostras são reunidas em grupos com o mínimo de variação, os grupos são
selecionados e o valor médio de cada um é plotado no gráfico.
A flutuação dos pontos dos limites de controle e distribuída de forma aleatória é
resultado da variação intrínseca do processo, devido à causas comuns, inerentes ao sistema.
Pontos localizados fora dos limites ou, ainda que dentro dos limites, com uma distribuição
não aleatória (cíclica, crescente, etc) podem refletir causas especiais, que devem ser
eliminadas. Para distinguir as causas especiais das comuns e prever se o processo está sob
controle ou não, é preciso avaliar se há mudança de parâmetro com a média e o desvio
padrão. Se não houver mudança nesses parâmetros ao longo do tempo, o processo estará
sob controle estatístico e só as causas comuns estarão presentes. Mas, se houver mudança
nos parâmetros, diz-se que uma causa especial agiu sobre o processo.
Essas cartas somente monitoram o processo, mantendo-o sob controle estatístico, ou
seja, mostrando que o processo é consistente, mas não garante que ele é capaz de atender
às especificações.

Diagramas de Pontos

Os diagramas de pontos, também conhecido como diagrama de dispersão, ajudam a

identificar o relacionamento entre duas variáveis, isto é, auxilia na visualização da relação
de dependência entre um parâmetro de qualidade e uma variável do processo, analisando
uma possível relação entre elas.
Com este diagrama pode-se, por exemplo, verificar a existência de uma correlação
entre o tamanho de um programa, em linhas de código e o tempo necessário para ser
executado. Eles ajudam a identificar a causa e o efeito entre duas variáveis. São
normalmente úteis em verificar a causa de um problema.
O diagrama de dispersão é construído através dos seguintes passos:
1. Coletar de 50 a 100 pares de amostra.
2. Plotar os Valores em um gráfico X,Y em ordem crescente para cima e para
direita, colocando no eixo horizontal a variável que “possivelmente” é a
causa.
3. Marcar os dados no diagrama. Quando houver valores repetidos circulá-
los tantas vezes quanto necessário.
 Gráfico de Fluxo

O gráfico de fluxo, ou fluxograma, é uma ferramenta vital para se visualizar um

processo. ARTHUR (1994). Apesar de eles terem sido amplamente abandonados pelas
organizações de um Sistema de Informação como ferramenta de projeto, são formas
altamente efetivas de se observar e sintetizar os processos existentes, antes de automatizá-
los.
Para construir um gráfico de fluxo, você precisará de representantes dos seus
fornecedores, clientes e do seu grupo, incluindo um supervisor e um facilitador. Estas
pessoas deverão ser as que realmente fazem o trabalho e todas devem participar no
desenvolvimento do processo. As pessoas que trabalham no processo compreendem-no
mais do que ninguém. Essas pessoas, desenham o fluxograma do processo atual, o
fluxograma do processo ideal, os passos que o processo deveria seguir, se tudo corresse
bem, e comparam os 2 esquemas para verificar as diferenças e encontrar a raiz do
problema.
É uma representação gráfica através de símbolos padronizados.
O gráficos de fluxo de processo ajudam os fornecedores, clientes e funcionários a
entender onde eles se adaptam à criação e ao fornecimento de serviços e produtos. Eles
servem como ferramenta úteis de treinamento para os novos funcionários, fornecedores e
clientes. Eles promovem um entendimento comum do que deve ser feito para se fornecer
um produto ou serviço de qualidade. A comunicação é aberta e o trabalho começa a fluir,
ao invés de se tornar bloqueado, como já o foi uma vez.

O Uso Das 7 ferramentas na estrutura da CMM

O ponto de partida para a aplicação das ferramentas é a aplicação de um

questionário, conhecido como Questionário de Maturidade desenvolvido pelo próprio SEI
e adapatado por ENDO (1998), que tem como objetivo fazer o levantamento da situação
inicial em que se encontra o processo de desenvolvimento da organização. O questionário é
aplicado individualmente para cada desenvolvedor e gerentes de projeto.
Após a sua aplicação e análise dos resultados, isto é, conhecendo como é o processo
atual de desenvolvimento de sistemas dentro da organização, pode-se então, fazer o uso das
ferramentas.

Estudo de Caso

Este trabalho está sendo desenvolvido juntamente com uma empresa

desenvolvedora de software, que conta com aproximadamente 30 funcionários sendo 15
desenvolvedores, esta é caracterizada com uma empresa de pequeno porte. A empresa é
localizada no município de São Carlos – SP e foi fundada em 1997 com a finalidade de
prover soluções para aplicações com tecnologia SmartCard.
Desde setembro de 2000, foram formados os grupos para a implantação do
Capability Maturity Model, com a finalidade de se atingir um nível de maturidade
considerável e desta forma a possibilidade de ter seus produtos exportados.
O estudo de caso, tem como objetivo, exemplificar a utilização das ferramentas
básicas da qualidade apresentadas neste trabalho em um caso real da implementação do
CMM, onde a empresa passa do nível 1 (Inicial) para o nível 2 (repetitivo) utilizando
algumas das 7 ferramentas básicas da qualidade.
 Conclusão

A qualidade de software é um dos assuntos mais atuais em discussão na

comunidade de Engenharia de Software. Embora os primeiros esforços mais amplos no
sentido de se produzir software com maior qualidade e produtividade datem da década de
70, foi na segunda metade da década de 90 que uma série de novos conceitos e abordagens
alcançaram maturidade e visibilidade.
O trabalho tem como intuito difundir a idéia da importância da qualidade, trazendo
para o âmbito computacional a idéia de que a qualidade do software está fortemente
relacionada com o processo de desenvolvimento.
Um dos maiores desafios da Engenharia de Software hoje é justamente aplicar os
conceitos do Capability Maturity Model em pequenas organizações. Existe muita
especulação de que o CMM foi desenvolvido visando sua utilização para grandes
empresas, porém, vimos neste trabalho que este modelo é totalmente aplicável em
pequenas empresas.
Pensando neste sentido, surge a possibilidade de se trabalhar com as já consagradas 7
ferramentas da qualidade no auxílio dos implementadores do CMM nas pequenas e médias
organizações. Pois, esta se destacam pela facilidade de implementação e baixo custo
administrativo.
Desta forma, fez-se um levantamento da utilização das 7 ferramentas básicas da
qualidade, que são; Folhas de Verificação, Gráficos de Paretto, Diagrama de Ishikawa,
Diagrama de Pontos, Histograma e Gráficos de Controle e Gráfico de Fluxo.

Referências Bibliográficas

ARTHUR, L. J. (1994) Melhorando a qualidade do software: um guia para o TQM.

Trad. F. E. F. Morgado. Rio de Janeiro, Infobook.
BELLOQUIM, A. (1999). CMM em Pequenas Organizações: É Possível? Infochoose
n010, Maio de 1999.
ENDO, C. (1998) Uma estratégia para iniciar melhoria de processo de software.
Dissertação (Mestrado). Instituto de Ciências Matemáticas e Computação – ICMC-USP.
FAESARELLA, I. S. (1998) Gestão da qualidade: Conceitos e Ferramentas.
HUMPHREY, W. (1989) Managing the software process – SEI/CMU – Addison
Wesley publishing.
PAULK, M. C.; et al, (1995) The capability maturity model: Guidelines for
improving the software process – SEI/CMU – Addison Wesley publishing.
PAULK, M. C. (1998) Using the software CMM in small organizations – SEI/CMU
– Addison Wesley publishing.
PRESSMAN, R, S. (1994) – Software Engeeniring – A Practtioner’s Approach, 30 ed.
McGraw-Hill.
JAMIL, G. (1999) - Visão geral dos modelos de qualidade para software. Infochoose
n0 9 Abril de 1999.
ROCHA, A.R.C, et al. (2001) Qualidade de software – Teoria e Prática. São Paulo,
Prentice Hall.
SMITH, D. J.; WOOD, K. B. (1989) Engeneering quality software: a review of
current pratics standards and guidelines including new methods and development tools. 2 o
ed. London, Elsevier computer science.
MCT; (1999) MCT/SEPIN. Qualidade e Produtividade no Setor de Software
Brasileiro: Brasília, 2000.