Qualidade de Software
Professor conteudista: Ivanir Costa
Sumário
Qualidade de Software
Unidade I
1 HISTÓRICO E CONCEITOS DE QUALIDADE ................................................................................................1
1.1 Introdução ..................................................................................................................................................1
1.2 Definições da qualidade .......................................................................................................................5
1.3 Conceitos de qualidade de produto e de processo..................................................................11
1.3.1 A dimensão produto ...............................................................................................................................11
1.3.2 A dimensão processo............................................................................................................................. 13
1.3.3 A qualidade total .................................................................................................................................... 15
1.3.4 O gerenciamento da qualidade ......................................................................................................... 15
1.3.5 As ferramentas da qualidade ............................................................................................................. 17
1.4 Conclusão ................................................................................................................................................ 23
Unidade II
2 QUALIDADE DE SOFTWARE ......................................................................................................................... 24
2.1 Introdução ............................................................................................................................................... 24
2.2 Garantia de produto de software .................................................................................................. 27
2.3 Garantia da qualidade de software .............................................................................................. 29
2.4 Evolução da qualidade de software.............................................................................................. 34
2.5 Fatores de qualidade de software ................................................................................................. 35
2.6 Indicadores de qualidade de software ......................................................................................... 37
2.7 Confiabilidade de software .............................................................................................................. 38
2.8 Medidas de confiabilidade de software ...................................................................................... 39
2.9 Controle de qualidade ........................................................................................................................ 40
2.10 Prevenção X Detecção ..................................................................................................................... 42
2.11 Verificação e validação..................................................................................................................... 43
2.12 Revisões Técnicas Formais (RTF) .................................................................................................. 45
2.13 Testes de software ............................................................................................................................. 46
2.14 Conclusão ............................................................................................................................................. 49
Unidade III
3 INTRODUÇÃO .................................................................................................................................................... 51
3.1 Norma ISO/IEC 12207 IEEE Std 12207-2008 – engenharia de software e
sistemas – processo do ciclo de vida de software.......................................................................... 54
3.1.1 Resumo ....................................................................................................................................................... 54
3.1.2 Definições .................................................................................................................................................. 54
3.1.3 Categorias de processos do ciclo de vida ..................................................................................... 66
3.1.4 Processo de gestão da qualidade ..................................................................................................... 69
3.2 Normas da série NBR ISO 9000 ...................................................................................................... 72
3.2.1 Norma NBR ISO 9000-3 – projeto, desenvolvimento, fornecimento, instalação
e manutenção de software ............................................................................................................................ 73
3.3 Norma NBR ISO/IEC 9126-1 2003 – engenharia de software – qualidade de
produto ............................................................................................................................................................ 83
3.3.1 Diretrizes para uso da norma NBR ISO/IEC 9126-1 .................................................................. 84
3.3.2 Características da qualidade da norma NBR ISO/IEC 9126-1 .............................................. 84
3.3.3 Visões da qualidade de software da norma NBR ISO/IEC 9126-1 ...................................... 88
3.4 Conclusão ................................................................................................................................................ 89
Unidade IV
4 MODELOS DE QUALIDADE DE SOFTWARE ............................................................................................. 90
4.1 Introdução ............................................................................................................................................... 90
4.2 O modelo MPS.BR ................................................................................................................................ 91
4.2.1 Introdução ................................................................................................................................................. 91
4.2.2 Descrição geral do MPS.BR ................................................................................................................. 91
4.2.3 Objetivos do MPS.BR ............................................................................................................................. 92
4.2.4 Os níveis de maturidade do modelo MPS.BR .............................................................................. 94
4.3 O modelo ISO/IEC 15504 (Software Process Assesment) ...................................................100
4.3.1 Introdução ...............................................................................................................................................100
4.3.2 Objetivos da ISO/IEC 15504 ..............................................................................................................100
4.3.3 As dimensões do modelo de referência .......................................................................................103
4.3.4 Conclusão.................................................................................................................................................107
4.4 O modelo CMMI-DEV adpatado do manual CMU/SEI-2006-TR-008 ........................... 107
4.4.1 Introdução ...............................................................................................................................................107
4.4.2 Evolução do CMMI ............................................................................................................................... 110
4.4.3 Objetivos do CMMI............................................................................................................................... 113
4.4.4 Agrupamentos do CMMI ................................................................................................................... 115
4.4.5 Métodos de avaliação ........................................................................................................................ 124
4.4.6 Conclusão................................................................................................................................................ 124
QUALIDADE DE SOFTWARE
Unidade I
1 HISTÓRICO E CONCEITOS DE QUALIDADE
1.1 Introdução
Quando se fala em qualidade pode-se remontar ao início
da organização do homem para comercializar seus produtos há
milhares de anos atrás. O conceito de qualidade muda de pessoa
para pessoa, de local para local, de época para época e, por isso,
5 pode ser considerado como uma noção subjetiva do valor de um
produto.
No entanto, somente ao final do século XIX é que o homem,
com o surgimento da industrialização, passou a estudar e
implantar conceitos de padrões de qualidade com o intuíto de
10 evitar os retrabalhos e a entrega dos produtos com problemas
ao consumidor final. Nesta época era o próprio operário que
com o conhecimento adquirido, com a experiência e com os
ensinamentos recebidos procedia a aceitação ou provocava
ajuste ou rejeitava o produto.
Já no século XX, teve início a verificação da qualidade como
uma tarefa para pessoas mais qualificadas, denominadas de
supervisores, que ao fazer a inspeção do trabalho executado
pelos seus subordinados atuavam para evitar os retrabalhos e
a rejeição de produtos. Com o passar do tempo essa forma de
20 atuação avançou em direção à inspeção dos produtos, realizadas
por inspetores de qualidade.
15
A partir da década de 1930, surge a desvinculação dessas
tarefas da linha de produção em direção a áreas específicas
1
Unidade I
de qualidade, que evoluíram para o uso de controles mais
quantitativos da qualidade dos produtos com o uso efetivo da
estatística da qualidade desenvolvida por W. A. Shewhart.
Somente após a Segunda Guerra Mundial voltou-se a
5 atenção para o controle de processos, já que nas décadas
anteriores o foco da qualidade era eliminar os produtos com
problemas ou defeitos (Juran, 2002). O controle de processos
introduziu procedimentos que deveriam ser seguidos de forma
rigorosa na produção industrial durante todas as etapas do ciclo
10 de produção de um determinado produto.
Na década de 1950, o Japão convidou dois estatísticos
americanos, discípulos de Shewhart, Edward Deming e Joseph
Juran, que encontraram no Japão as condições ideais para
implementar as técnicas de qualidade que tinham desenvolvido,
15 já que o país atravessava uma grande crise devido à rejeição
de seus produtos que apresentavam uma má qualidade. Os
resultados aparecem no final da década de 1970, com o Japão se
tornando uma potência industrial e uma referência com relação
à gestão da qualidade (Juran, 2002).
Nas décadas de 1970 e 1980, outros movimentos surgem
na Europa e nos Estados Unidos. Na Europa, o movimento
se deu em torno do comportamento humano no processo
de produção, indicando que para melhorar a qualidade e
a produtividade era importante preparar os empregados
25 através de constantes treinamentos. Surgiram incentivos
para o trabalho dos empregados em equipes, foram criadas
leis que asseguravam os benefícios, a estabilidade e um
movimento que valorizava o relacionamento entre o cliente e
o fornecedor. Nos Estados Unidos, por outro lado, o processo
30 de produção passou a aplicar a vertente da qualidade
denominada de “garantia da qualidade”, que era um conjunto
de acordos para cumprir o planejamento da qualidade. (Juran,
2002; Rocha, 2001).
20
2
QUALIDADE DE SOFTWARE
Conforme Card (1990), a tecnologia da qualidade em
manufatura pode ser apresentada em três níveis históricos
apresentados na figura 1 e cada nível tecnológico tem aumentado
a qualidade e permitido que as empresas operem em diferentes
5 níveis de qualidade.
Figura 1: Evolução da tecnologia da qualidade
Melhoria da
qualidade
Melhoria do
processo
Nível 3
Controle de
qualidade
Nível 2
Nível 1
Inspeção do
produto
1920
1940
1960
1980
Tempo
2000
Adaptada: Côrtes & Chiossi (2001) apud Card (1990).
Ainda citando Card (1990), os níveis de tecnologia da
qualidade podem ser definidos como:
10
15
20
1. Inspeção do produto: a inspeção do produto é um
processo que examina os produtos intermediários e
o produto final na procura de defeitos. Esse processo
é aplicado nas linhas de montagem dos produtos e foi
popularizado a partir da década de 1920.
2. Controle de qualidade: o controle da qualidade trabalha
com o monitoramento das taxas de defeitos utilizando a
estatística da qualidade e tem como objetivo a redução
dos defeitos e dos custos para se identificar os elementos
defeituosos do processo de produção. O objetivo é
identificar e corrigir esses elementos defeituosos através
das taxas de defeitos.
3
Unidade I
5
3. Melhoria do processo: a proposta da melhoria do
processo e a procura das tarefas ou atividades que
introduzem defeitos no processo de produção da
empresa. Melhorando-se os processos minimiza-se os
defeitos e os custos envolvidos.
Uma outra visão histórica da qualidade total pode ser
apresentada como na tabela 1 criada e apresentada por Shiba
(1997). Nesta visão mostra-se a evolução da qualidade total
também ao longo do tempo, mas focando os objetivos da
10 qualidade.
Tabela 1: Quatro revoluções da qualidade.
Evolução dos objetivos da qualidade ao longo do tempo
Época
Objetivos
Resultados esperados
Década de 1950
Adequação ao
padrão
Produzir produto de acordo com o
padrão escolhido (conformidade).
Década de 1960
Adequação ao uso
Garantir satisfação das necessidades
do mercado (foco no cliente).
Década de 1970
Adequação ao
custo
Reduzir os custos e alcançar a mais
alta qualidade.
Década de 1990
Adequação às
necessidades
latentes
Satisfazer as necessidades dos clientes
antes do momento esperado pelo
cliente.
Fonte: Shiba (1997).
De acordo com Lucena (2007), a tabela 1 ilustra o que ocorreu
historicamente em cada década, apresentando, respectivamente,
qual era o objetivo e qual era o resultado esperado. Lucena
15 ainda mostra que o foco, na década de 1950, era conseguir uma
produção padronizada; na década de 1960, o foco era o uso do
produto e passa-se a considerar a necessidade do mercado no
processo de produção; na décade de 1970, o foco mudou para o
custo, pois a meta era reduzir custos no processo de produção;
20 na década de 1990, o enfoque passou a ser sobre qual a forma
de surpreender satisfatoriamente o cliente para estimulá-lo na
compra do produto.
4
QUALIDADE DE SOFTWARE
Na atualidade, a qualidade é encarada como um conjunto
de atributos essenciais à sobrevivência das organizações num
mercado altamente competitivo, objeto da gerência estratégica,
líder do processo, que envolve planejamento estratégico,
5 estabelecimento de objetivos e mobilização de toda organização.
É o clímax de uma tendência que teve início no começo do
século XX (Garvin, 1992), e que envolve, também na atualidade,
a responsabilidade social das empresas com o seu ambiente
externo, potencializando seu uso em vários setores da economia
10 e mais notadamente no setor de serviços.
1.2 Definições da qualidade
Existem diversas escolas e mestres que ficaram marcados ao
longo da história da qualidade. Abaixo serão apresentados os
principais mestres e seus conceitos sobre a qualidade.
Frederick Taylor considerado um dos precursores da
15 qualidade desenvolve no início do século XX uma teoria
denominada “princípios da administração científica”, que prega
que os processos produtivos podem ser repetidos com um
grau de variabilidade controlada. Com a padronização podese reproduzir um determinado processo em vez do paradigma
20 vigente em que a arte imperava nas tarefas e, dessa forma, não
se podia reproduzir nada (Taylor, 1911).
O livro Princípios da administração científica cita:
25
O aumento da eficiência, a racionalização dos
métodos de trabalho, a crença no homem econômico,
a divisão e a hierarquização do trabalho, a relevância
da organização formal.
Na atualidade, as propostas de Taylor não são bem aceitas
pelos estudiosos da área de gerenciamento, pois ficou a idria
de que a sua teoria considerava os trabalhadores como pessoas
30 preguiçosas e que era necessário forçá-los e puni-los de
5
Unidade I
acordo com as boas práticas e hábitos de trabalho. Outro fator
importante é que os trabalhadores, na teoria de Taylor, deveriam
saber o que fosse estritamente necessário para desempenhar de
forma eficiente o seu trabalho, o que comumente se chamou de
5 “saber tudo sobre apertar parafusos”. Hoje, vigora a ideia de que
as pessoas gostam de trabalhar e que podem ser motivadas no
seu trabalho, por mais repetitivo que seja.
Nos anos 1930, o Dr. W.A. Shewhart, estatístico norteamericano que já na década de 1920 tinha um grande
10 questionamento com a qualidade e com a variabilidade
encontrada na produção de bens, causa uma revolução à teoria
científica da administração de Taylor quando propõe um método
voltado para a gestão das organizações, conhecido como:
“controle da qualidade”, ou “Controle Estatístico da Qualidade
15 (CEQ)”, ou “Controle Estatístico de Processos (CEP)” que se
baseava na aplicação de gráficos de controle, na inspeção por
amostragem.
Shewhart criou também o ciclo PDCA (Plan, Do, Check
e Action), método essencial da gestão da qualidade (Longo,
20 2010). O ciclo PDCA foi divulgado por Deming e é atualmente
conhecido como “Ciclo de Deming” (Walton, 1989).
Já Deming (1982) define que qualidade é:
25
Atender continuadamente às necessidades e
expectativas dos clientes a um preço que eles estejam
dispostos a pagar.
Deming é reconhecido pelos estudiosos da qualidade como
o grande líder no gerenciamento da qualidade e como fundador
da terceira onda industrial (revolução da informação). Ainda
segundo Deming (1982) apud Côrtes & Chiossi (2001):
30
6
A qualidade é um grau previsível de uniformidade e
dependência, baixo custo e satisfação do mercado, ou
QUALIDADE DE SOFTWARE
seja, qualidade é sempre aquilo que o cliente necessita
e quer, isto é, a qualidade é a ausência de falhas ou
defeitos.
Os pontos-chave da teoria de Deming referem-se
5 ao controle estatístico da qualidade, partricipação do
trabalhador no processo de decisão e limitação das fontes de
fornecimento.
Resumindo os conceitos e definições do mestre Deming,
pode-se dizer que qualidade é o aperfeiçoamento contínuo e
10 firmeza de propósitos; compreender o que acontece, construir
e interpretar estatísticas e agir aperfeiçoando; não há respostas
corretas, apenas respostas geradas pelos métodos usados
para gerá-las; o objetivo deve ser as necessidades do usuário,
presentes e futuras.
15
20
Juran (1981), considerado um dos arquitetos da revolução
da qualidade, a partir da década de 1950 define a qualidade
como:
A qualidade consiste nas características do produto
que vão ao encontro das necessidades dos clientes e,
dessa forma, proporcionam a satisfação em relação
ao produto. A qualidade é a ausência de falhas ou
defeitos.
e
25
A qualidade deve ser orientada pelo custo, que consiste
na redução dos despedícios e deficiências do processo
de produção. Alta qualidade implica em menor custo
do produto.
Em contrapartida às propostas de Taylor, Juran defende
a delegação aos trabalhadores de funções executadas pelos
30 homens de planejamento e controle (supervisores). Dessa forma,
7
Unidade I
o processo de produção assume o autocontrole, a autoinspeção
e a autossupervisão. Com essas propostas ele cria e define a
gerência para a qualidade que é constituida por três processos:
o planejamento da qualidade, o controle da qualidade e a
5 melhoria da qualidade.
Armand Feigenbaum, em 1956, propôs um conceito
mais avançado, o “controle total da qualidade”, partindo da
premissa de que a qualidade do produto é objeto de todos na
organização, desde a concepção, passando pela fabricação, até
10 a chegada dos produtos às mãos dos clientes. Portanto, na sua
visão a qualidade não é um trabalho isolado do Departamento
de Controle, emas, na verdade, objetivo de toda a organização,
da alta gerência aos setores operacionais. A qualidade passou
a ser então uma questão de sobrevivência no mercado
15 concorrencial e um objetivo de níveis gerenciais mais elevados,
a partir do início da cadeia produtiva, perpassando desde a
concepção do projeto da organização até seus produtos
(Gurgel Junior, 2002).
A partir desse conceito, foram criadas as equipes
20 interfuncionais, com o objetivo de discutir os processos de
padronização dos produtos, que se iniciavam na formulação
do projeto, na escolha de bons fornecedores, no controle da
produção e na satisfação dos clientes, inclusive no período do
pós-venda, mantendo-se o controle estatístico por amostragem,
25 mas não se limitando a ele.
Philip B. Crosby iniciou seus estudos na década de 1960 e
em sua teoria a qualidade pode ser vista como uma medida da
conformidade com as especificações. O objetivo é ter defeito
zero no produto e para isso torna-se necessário a ausência de
30 defeitos na maioria dos componentes do produto. As empresas
japonesas então passaram a aplicar corretamente a teoria do
defeito zero de Crosby como uma ferramenta de engenharia
com a responsabilidade atribuída ao gerenciamento (Crosby,
1979).
8
QUALIDADE DE SOFTWARE
Em 1979, fundou a Philip Crosby Associates e lançou a sua
famosa obra Quality is Free, um verdadeiro clássico da qualidade
que vendeu mais de 2,5 milhões de cópias e foi traduzido para
quinze línguas e, em 1996, lançou um novo livro intitulado
5 Quality is Still Free. O seu nome ficará para sempre associado
aos conceitos de “zero defeitos” e de “fazer bem à primeira vez”.
Na sua opinião, a qualidade significa conformidade com as
especificações, que variam consoante as empresas e de acordo
com as necessidades dos clientes.
10
Crosby considera a prevenção como a principal causadora
de qualidade, e por isso pensa que as técnicas não preventivas
como a inspecção, o teste e o controle são pouco eficazes. Em
alternativa, apresenta uma “vacina” preventiva que contém
três ingredientes: determinação; formação; liderança. Nos
15 seus famosos quatorze pontos para a melhoria da qualidade,
Crosby encara este esforço como um processo contínuo e
não um programa pelo qual a melhoria da qualidade deve
ser perseguida de modo permanente. Para ele, os verdadeiros
responsáveis pela falta de qualidade são os gestores e não os
20 trabalhadores. As iniciativas para a qualidade deverão vir de
cima para baixo e para isso é necessário o empenho da gestão
de topo e a formação técnica dos empregados em instrumentos
de melhoria da qualidade.
Kaoru Ishikawa,em 1949, entrou para a União Japonesa
25 de Cientistas e Engenheiros (JUSE), um grupo de pesquisa de
controle de qualidade. Lá aprendeu os princípios do controle
estatístico da qualidade desenvolvido por americanos. Kaoru
traduziu, integrou e expandiu os conceitos de gerenciamento
do Dr. Deming e do Dr. Juran para o sistema japonês.Talvez
30 a contribuição mais importante de Ishikawa foi seu papelchave no desenvolvimento de uma estratégia especificamente
japonesa da qualidade. A característica japonesa é a ampla
participação na qualidade, não somente de cima para baixo
dentro da organização, mas igualmente no início e no fim do
35 ciclo de vida do produto. Em conjunto com a JUSE, em 1962,
9
Unidade I
Ishikawa introduziu o conceito de “círculo de qualidade” e em
1982 viria o diagrama de “causa e efeito”, também conhecido
como “diagrama de Ishikawa”.
Ishikawa, um guru japonês, um humanista, segundo o qual:
5
10
Uma interpretação que se poderia dar à qualidade
é que ela significa qualidade de trabalho, qualidade
do serviço, qualidade de informação, qualidade do
processo, qualidade da estrutura, qualidade das
pessoas, incluindo os operários, técnicos, engenheiros,
gerentes e alta administração, qualidade do sistema,
qualidade da companhia, qualidade dos objetivos etc.
(Costa Neto, 2007).
Ainda segundo Costa Neto (2007), é atribuida a ele a
paternidade do “diagrama de causa e efeito”, uma das sete
15 ferramentas usuais para a resolução dos problemas.
Resumindo, para Ishikawa a qualidade é fabricar produtos
mais econômicos, mais úteis e sempre satisfatórios para o
consumidor.
Finalmente, deve-se citar o brasileiro Vicente Falconi Campos,
20 pois ele foi o grande divulgador das técnicas japonesas para
a qualidade no Brasil, fruto do intercâmbio entre a Fundação
Christiniano Ottoni, de Belo Horizonte, da qual participava, com
a JUSE (Japonese Union of Scientists and Engineers) e outros
organismos japoneses voltados para a gestão da qualidade,
25 com vários livros publicados nesse campo, a começar por TQC
– Controle da qualidade total no estilo japonês, de 1992 (Costa
Neto, 2007).
Resumindo, para Falconi (1992):
30
10
produto ou serviço de qualidade é aquele que atende
perfeitamente, de forma confiável, de forma acessível,
QUALIDADE DE SOFTWARE
de forma segura e no tempo certo as necessidades
dos clientes.
1.3 Conceitos de qualidade de produto e de
processo
O verdadeiro critério da boa qualidade é a preferência do
consumidor. A única definição anotada que não privilegia
5 o cliente é a de Crosby (1979), voltada para o produtor. Já o
dicionário Aurélio define qualidade como:
propriedade, atributo ou condição das coisas ou das
pessoas capaz de distingui-las das outras e de lhes
determinar a natureza.
10
Dessa forma, os autores estudam a qualidade a partir de
duas dimensões, que devem ser consideradas: a dimensão do
produto e a dimensão do processo.
1.3.1 A dimensão produto
De acordo com Rocha (2001):
15
Um produto é algo concreto, no qual se percebem as
formas, os tamanhos, as cores, a beleza, a perfeição
e outras observações perceptíveis aos sentidos
humanos.
Já Campos (1992) afirma que qualidade é o sentimento de
satisfação de uma pessoa por ter conquistado algum produto
20 desejado. O comprador espera que ele funcione por muito tempo
e que dificilmente apresente algum problema.
A qualidade de um produto ou serviço pode ser olhada de
duas ópticas: a do produtor e a do cliente. Do ponto de vista
do produtor, a qualidade se associa à concepção e produção de
25 um produto que vá ao encontro das necessidades do cliente. Do
11
Unidade I
ponto de vista do cliente, a qualidade está associada ao valor e
à utilidade reconhecidas ao produto, estando em alguns casos
ligada ao preço.
5
10
15
20
25
30
Do ponto de vista dos clientes, a qualidade de um produto
pode ser vista por diversas características, por exemplo, sua
dimensão, sua cor, sua durabilidade, seu design, as funções
que desempenha etc. Assim, a qualidade é um conceito
multidimensional. A qualidade tem muitas dimensões e é por
isso mais difícil, até para o cliente, de definir o que é qualidade
de produto. Do ponto de vista da empresa, contudo, se o
objetivo é oferecer produtos e serviços de qualidade, o conceito
não pode ser deixado ao acaso. Tem de ser definido de forma
clara e objetiva. Isso significa que a empresa deve apurar quais
são as necessidades dos clientes e, em função destas, definir os
requisitos de qualidade do produto. Os requisitos são definidos
em termos de variáveis como: comprimento, largura, altura,
peso, cor, resistência, durabilidade, funções desempenhadas,
tempo de entrega, simpatia de quem atende ao cliente,
rapidez do atendimento, eficácia do serviço etc. Cada requisito
é em seguida quantificado, a fim de que a qualidade possa
ser interpretada por todos (empresa, trabalhadores, gestores
e clientes) exatamente da mesma maneira. Os produtos
devem exibir esses requisitos, a publicidade se faz em torno
desses requisitos, o controle de qualidade visa assegurar que
esses requisitos estejam presentes no produto, a medição da
satisfação se faz para apurar em que medida esses requisitos
estão presentes e em que medida vão realmente ao encontro
das necessidades. Todo o funcionamento da “empresa de
qualidade” gira em torno da oferta do conceito de qualidade
que foi definido (Brocka, 1994; Fazano, 2006; FNQ, 2007;
Paladini, 2005).
De acordo com Shiba (1997) apud ISO/IEC 9126, devese considerar alguns aspectos para se obter a qualidade do
produto:
12
QUALIDADE DE SOFTWARE
1. Funcionalidade: identifica os procedimentos de
funcionamento de um produto.
5
2. Confiabilidade: o produto não deve apresentar
problemas junto ao clientes, caso contrário, o
fornecedor deverá resolvê-los.
3. Usabilidade: deve-se testar o máximo possível o
produto e constatar o resultado como satisfatório.
4. Eficiência: comprovação, pelo cliente, de sua satisfação
com o produto.
10
5. Manutenibilidade: garantia de correções dos
problemas.
6. Portabilidade: o produto muda de ambiente e a
operação ocorre da mesma forma satisfatória.
1.3.2 A dimensão processo
Uma das evoluções mais necessárias para o estudo da
15 qualidade está em notar que a qualidade do produto é
importante, mas que a qualidade do processo de produção
é ainda mais importante. No caso do prato de comida, por
exemplo, nós podemos dizer mais sobre a qualidade observando
como o prato foi preparado do que analisando o produto final.
20 Afinal, nós não conseguimos ter certeza da higiene ou do
valor nutricional apenas comendo o conteúdo do prato. Esta
descoberta aconteceu durante a própria evolução dos conceitos
de qualidade, ao longo dos anos.
Modernamente, considera-se que a qualidade do produto
25 é conseguida de forma consistente, a longo prazo, a partir da
qualidade do processo.
A qualidade do processo pode ser explicada como sendo
o “melhor caminho” lógico a ser percorrido entre o início e a
conclusão de um produto que será construído. Para determinar
13
Unidade I
o melhor caminho, são utilizadas as ferramentas da qualidade
total para efetuar os estudos e as simulações e determinar a
rota ideal (Oakland, 1994).
Um assunto fundamental no gerenciamento da qualidade
5 é que a qualidade do processo afeta diretamente a qualidade
dos produtos liberados. Isto vem dos sistemas de manufatura
nos quais a qualidade do produto está intimamente relacionada
com o processo de produção. Em um sistema de manufatura
automático, o processo envolve a configuração, o setup e a
10 operação das máquinas envolvidas no processo. Uma vez que as
máquinas estão operando corretamente, a qualidade do produto
acontece naturalmente. A medição da qualidade do produto
perrmite a mudança no processo até que se encontre o nível
de qualidade que se quer, como mostra a figura 2 (Sommerville,
15 2007).
Figura 2: Processo base da qualidade
analysis Business Process Model
Define
processo
Desenvolve
produto
Assegura
qualidade
do produto
Evento
início
Melhora
processo
NÃO
Produto
OK?
SIM
Processo
padronizado
Evento
fim
Fonte: adaptado de Sommerville (2007).
A figura 2 mostra que há um link claro entre a qualidade
do processo e a qualidade do produto na manufatura, porque
o processo é relativamente fácil para padronizar e monitorar.
Uma vez que o sistema de manufatura é calibrado, ele pode ser
20 executado várias vezes e gerar produtos de alta qualidade.
14
QUALIDADE DE SOFTWARE
1.3.3 A qualidade total
O termo “qualidade total” ou TQM (Total Quality Management)
representa a busca da satisfação, não só do cliente, mas de todos
os envolvidos em um processo produtivo da empresa, além de
buscar também a excelência organizacional da empresa. Dessa
5 forma, a qualidade total engloba os conceitos da qualidade do
produto e da qualidade do processo.
A expressão “qualidade total”, em si, não traduz com
correção o conceito que pretende divulgar, pois ela induz
inadvertidamente a uma confusão com qualidade absoluta ou
10 qualidade acabada, “até mesmo porque qualidade não é algo
estático, mas dinâmico. Qualidade não é estado, mas processo
ou busca continuada (Mezomo, 1994).
O conceito de qualidade total vem sendo desenvolvido por
numerosos teóricos há mais de meio século. Ela se compõe de
15 numerosos elementos, como os princípios da administração
científica de Taylor (1995), o controle estatístico de Shewart,
os conceitos sobre o comportamento humano de Maslow,
McGregor e Herzeberg, e os conceitos sobre fatores técnicos da
qualidade de Deming, Juran, Feigenbaum e Crosby, entre outros
20 (Morejón, 2005).
1.3.4 O gerenciamento da qualidade
A responsabilidade do gerenciamento da qualidade é garantir
que o nível esperado de qualidade do processo, produto ou
serviço seja alcançado. O gerenciamento de qualidade envolve a
definição de procedimentos e padrões apropriados e a verificação
25 para que eles sejam seguidos por todos na empresa.
O PDCA (Plan, Do, Check e Act) foi desenvolvido por Shewhart
e divulgado por Deming e foi proposto como um meio sistemático
para a implementação de mudanças corretivas ou evolutivas. Ele
pode ser usado em todos os estágios do ciclo de vida de um
15
Unidade I
produto ou processo para: a) correção de problemas; b) melhoria
de processos; c) manutenção do nível de desempenho de um
processo (Côrtes & Chiossi,2001).
A figura 3 apresenta o ciclo PDCA que hoje é a base de quase
5 todos os modelos de qualidade existentes.
Figura 3: Ciclo PDCA
A (act)
Agir
P (Plan)
Planejar
Metas
Ações
corretivas
Verificação de
resultados
Métodos e
processos
Treinamento
Implantação
C
(Check)
Verificar
D (Do)
Fazer
Fonte: adaptado de Côrtes & Chiossi (2001) e Deming (1982).
Os quatros elementos do ciclo PDCA significam:
• P (planejamento): onde se estabelecem as metas e o
processo formado por métodos, rotinas, documentos,
normas, padrões, papéis etc.;
10
• D (execução): normalmente composta de duas fases, o
treinamento das novas práticas planejadas e a implantação
do processo;
• C (verificação): verificação dos resultados do processo
implantado com relação às metas preestabelecidas;
15
16
• A (ações corretivas): ações para corrigir eventuais desvios
do processo.
QUALIDADE DE SOFTWARE
Além do PDCA, o TQM possui sete ferramentas que
possibilitam atuar nas atividades do processo produtivo dos
diversos segmentos: financeiros, econômico, industrial, serviços
etc.
5
De acordo com Shiba (1997), essas ferramentas contribuem
para as pessoas entenderem os assuntos da mesma forma,
pois se tornam uma comunicação padrão no ato de praticar o
processo e construir os produtos.
1.3.5 As ferramentas da qualidade
Dentre as ferramentas mais utilizadas destacam-se as
10 denominadas ferramentas básicas da qualidade: diagrama
de Pareto, diagrama de causa e efeito, lista de verificação,
histograma, diagrama de dispersão, gráfico linear e gráfico
de controle. Neste item serão apresentas as principais e mais
utilizadas na gestão da qualidade:
15
1. Diagrama de Pareto
É uma forma de descrição gráfica na qual se procura
identificar quais itens são responsáveis pela maior parcela dos
problemas.
De acordo com Ramos (2008), os passos para a construção
20 do Diagrama de Pareto são:
• determinar como os dados serão classificados: por
produto, por máquina, por turno, por operador etc.;
• construir uma tabela, colocando os dados em ordem
decrescente;
25
• calcular a porcentagem de cada item sobre o total e o
acumulado;
• traçar o diagrama.
17
Unidade I
Figura 4: Exemplo de diagrama de Pareto
80
70
60
50
40
30
20
10
0
Problema G
J
A
E
I
B
H
C
D Outros
Count 77 69 63 57 49 40 28 25 18
17
Percent 17,3 15,5 14,2 12,8 11,0 9,0 5,3 5,9 4,1
3,8
Cum % 17,3 32,9 47,1 59,9 70,9 80,0 86,3 92,1 96,2 100,0
Fonte: Ramos (2008).
A figura 4 apresenta um exemplo da aplicação do diagrama
de Pareto onde no eixo vertical foram organizadas as quantidades
de problemas apresentados em um determinado período de
contagem, e na horizontal as quantidades de erros de cada tipo
5 de erro organizadas em ordem descrecente, o percentual de
cada tipo de erro em relação ao total e o percentual acumulado
ao longo dos tipos de erros.
A partir desse gráfico pode-se analisar os dados sob
diferentes pontos de vista para uma tomada de decisão sobre
10 quais ações deverão ser tomadas ou quais os tipos de erros que
terão prioridades nas ações, e assim por diante.
2. Diagrama de causa e efeito
Esta ferramenta permite identificar possíveis causas do
problema envolvido com os seis elementos (6 Ms) de um processo
15 produtivo: materiais, métodos, máquinas, mão de obra, medição
e meio ambiente.
18
QUALIDADE DE SOFTWARE
Utilizando-se os 6Ms (nem todos são necessários – depende
do problema analisado) aplica-se o diagrama de causa e efeito
ou diagrama de Ishikawa ou diagrama espinha de peixe da
seguinte forma:
5
• desenhar uma seta apontando para o problema (efeito)
que está sendo analisado;
• escrever as causas primárias que afetam o efeito nas
espinhas grandes;
10
• escrever as causas secundárias que afetam as espinhas
grandes, associando-as às espinhas médias;
• finalmente, escrever as causas terciárias que afetam as
espinhas médias, associando-as às espinhas pequenas.
A figura 5 mostra a estrutura básica do diagrama de causa
e efeito sobre o qual deve ser montado o problema a ser
15 analisado.
Figura 5: Diagrama básico de causa e efeito
Espinha grande
Espinha pequena
Efeito
Espinha média
A partir de um problema identificado e colocado como efeito
no diagrama, depois os elementos macro (Ms) são identificados
e relacionados nas espinhas grandes do diagrama (causas
primárias). Em sequência, identificam-se as causa possíveis
20 do problema que são colocadas nas espinhas médias (causas
secundárias) e pequenas (causa terciárias) do diagrama.
19
Unidade I
De acordo com Lucena (2007), um diagrama de causa e efeito
ajuda a entender as causas que deram origem ao problema
durante o processo de produção. É um gráfico que induz a pensar
e a definir quais são os “porquês” das causas dos problemas.
5
Ainda conforme Ramos (2008), deve-se ter cuidado na
montagem do diagrama:
• não criticar ideias dos colegas: deixar a cabeça livre, sem
restrições;
10
• participar ativamente, buscando dar o melhor de si e de
seu conhecimento;
• não tentar dominar a discussão: dar chance a todos de
exporem suas ideias e debatê-las;
• registrar todas as ideias à medida em que forem sendo
geradas;
15
• pedir esclarecimentos quando não entender.
Entende-se aqui que o diagrama de Ishikawa é uma
ferramenta poderosa para a identificação dos direcionadores
que potencialmente causam os efeitos indesejáveis. Estes
direcionadores, por sua vez, também podem ser EIs originados por
20 outras causas-raízes. O diagrama apresenta como pontos fortes:
ser uma boa ferramenta de levantamento de direcionadores;
ser uma boa ferramenta de comunicação; estabelecer a relação
entre o efeito e suas causas e possibilitar um detalhamento das
causas. No entanto, também apresenta os seguintes pontos
25 fracos: não apresentar os eventuais relacionamentos entre as
diferentes causas e não focalizar necessariamente as causas que
devem efetivamente ser atacadas (TransMeth, 2010).
3. Lista de verificação
É uma forma de coleta de dados referente à quantidade de
30 fatos ocorridos para uma atividade ou um problema. Os fatos
20
QUALIDADE DE SOFTWARE
devem ser coletados num período de tempo devidamente
definido. A finalidade da coleta de dados é organizar os dados
de uma forma que proporcione uma interpretação de fácil
entendimento (Lucena,2007).
5
Para registrar e ajudar na organização dos dados pode-se
empregar listas de verificação ou tabelas. Estas costumam ser
de uma das seguintes categorias:
• tabela de frequências;
• tabela de classificação;
10
• tabela de simples listagem;
• tabela de localização de defeitos;
• tabela de verificação.
Ramos (2008) apresenta dois exemplos gráficos com uma
tabela de frequência (figura 6) e uma tabela de classificação
15 (figura 7):
Figura 6: Exemplo de uma tabela de frequência
Tempo (dias)
f
10 a 15
||
15 a 20
||||
20 a 25
||||||||||||
25 a 30
|||||||||||
30 a 35
|||||||||||||||||||||||
35 a 40
||||||||||||||
40 a 45
|||||||
45 a 50
||||
Fonte: Ramos (2008).
Esta tabela da figura 6 apresenta duas colunas: a primeira
coluna apresenta os dias da contagem organizados de 5 em 5
21
Unidade I
dias e a segunda coluna apresenta a frequência para a observação
que foi efetuada nos dias.
A tabela de classificação mostrada na figura 7 ilustra uma
contagem de erros por tipo de erros. Na primeira coluna ela indica
5 o tipo de erro e na segunda coluna a quantidade observada em
um deteminado período definido.
Figura 7: Exemplo de uma tabela de classificação
Erro
Falha funcional
Teste inadequado
Erro de codificação
Falha interna
Nâo funciona
Outros
Qtd
||||||||||||||||||||
|||||||||||||
||||||
|||
|
||||||||
Fonte: Ramos (2008).
4. Histograma
Um histograma é um gráfico de barras que mostra a
10 evolução de um cenário de um processo de produção num
intervalo de tempo e, dessa forma, possibilita analisar as
concentrações de comportamento de uma pesquisa. Para
definir o intervalo das faixas estuda-se estaticamente a
frequência adequada.
15
De acordo com Ramos (2008), o histograma mostra a
“forma” dos dados obtidos. Consiste na classificação dos
dados em classes e na contagem da quantidade (frequência)
em cada uma destas, traçando retângulos cujas alturas são
proporcionais a estas. Recomenda-se uma amostra com no
20 mínimo 30 dados, mas 50 dados ou mais são preferíveis, como
mostra a figura 8.
22
QUALIDADE DE SOFTWARE
Figura 8: Exemplo de um histograma
Frequência
60
50
40
30
20
10
0
73.96 73.97 73.98 73.99
74
74.01 74.02 74.03 74.04
Classes
Fonte: Ramos (2008).
A divisão por faixas em grupos de valores proporciona um
gráfico mais condensado, possibilitando uma visualização de
forma resumida. Nota-se no exemplo da figura 8, considerando5 se desvios em peças de uma fábrica, que a classe (faixa de valores)
na qual as medidas das peças vão de 74 a 74.01 apresenta uma
maior concentração, o que corresponde a uma incidência de
quase 50 vezes os desvios anotados.
1.4 Conclusão
Este capítulo apresentou um histórico e conceitos da área de
10 qualidade. Diversos autores foram utilizados para dar uma visão
resumida e abrangente da história da qualidade, pois quando
se trabalha com a área de projetos e qualidade de projetos
pode-se aplicar os mesmos conceitos. Existe um processo para
a “fabricação” dos projetos e deve-se concentrar esforços para
15 realizar um bom controle desse processo.
É importante que não se faça confusão entre o controle de
projeto e o controle do processo de projeto. O primeiro referese a um projeto específico e o segundo refere-se à “fábrica” de
projetos.
23