Padres esperados Qualidade de Software

O principal objetivo da engenharia de software ajudar a produzir software de qualidade.

Conceitos de qualidade so imprecisos e difceis de serem aceitos por todas as pessoas, no
entanto, mtricas de qualidade de software surgem desde a dcada de 70 e vm se desenvolvendo
de forma a ajudar no processo de desenvolvimento de software.
A garantia de controle de qualidade de software est intimamente relacionada a atividades
de verificao e validao e esto presentes em todo o ciclo de vida do software. Em algumas
organizaes no existe distino entre essas atividades. Entretanto, a garantia de qualidade e os
processos de verificao e validao de software devem ser atividades distintas. A garantia de
qualidade uma funo gerencial, enquanto que a validao e a verificao so processos
tcnicos no desenvolvimento de software.
Dentre os modelos de gerenciamento de controle de qualidade de software mais
conhecidos esto o Capability Maturity Model (CMM) e o ISO 9000-3, que foram motivados
pelas falhas nos processos de gerncia e manuteno durante o desenvolvimento de software
[CESAR97].
Definir qualidade de software uma tarefa difcil. Muitas definies tm sido propostas e
uma definio decisiva poderia ser debatida interminavelmente.
Controle de Qualidade
Pela definio da ISO, controle de qualidade a atividade e tcnica operacional
que utilizada para satisfazer os requisitos de qualidade [McDermid94].
O controle de qualidade feito atravs de uma srie de inspees, revises e testes,
usados atravs do ciclo de desenvolvimento para garantir que cada trabalho produzido est de
acordo com sua especificao/requerimento. Portanto, o controle de qualidade parte do
processo de desenvolvimento e, como um processo de feedback, ele essencial para minimizar
os defeitos produzidos.
Garantia de Qualidade
A garantia de qualidade de software no algo com o qual se comea a pensar
depois que o cdigo gerado. A Garantia de Qualidade de Software ou SQA (Software Quality
Assurance) uma atividade que aplicada ao longo de todo o processo de engenharia de
software. Ela abrange:
mtodos e ferramentas de anlise, projeto, codificao e teste;
revises tcnicas formais que so aplicadas durante cada fase da engenharia de
software;
uma estratgia de teste de mltiplas fases;
controle da documentao do software e das mudanas feitas nela;
um procedimento para garantir a adequao aos padres de desenvolvimento
de software, se eles forem aplicados;
mecanismos de medio e divulgao.

Geralmente, a garantia de qualidade consiste daqueles procedimentos, tcnicas e

ferramentas aplicadas por profissionais para assegurar que um produto atinge ou excede
padres pr-especificados durante o ciclo de desenvolvimento do produto; se tais padres no
so aplicados, a garantia de qualidade assegura que um produto atinge ou excede um nvel de
excelncia (industrial ou comercial) mnimo aceitvel.
Custo de Qualidade
Como seria utpico alcanar a perfeio em um sistema de computao, ento o
mais importante passa a ser definir qual nvel de checagem (de qualidade) seria suficiente para o
sistema em questo e os custos associados.
O custo de qualidade inclui todos os gastos financeiros relacionados s atividades
de qualidade, os quais podem ser divididos em: custos de preveno, custos de avaliao e custos
de falhas.
Os custos de preveno incluem:
planejamento da qualidade;
revises tcnicas formais;
teste de equipamentos;
treinamento.
Os custos de avaliao incluem:
inspees dos processos e relaes entre eles;
manuteno dos equipamentos;
testes.
Os custos de falhas poderiam desaparecer se nenhum defeito ocorresse antes da entrega do
produto para o cliente. Os custos de falhas podem ser divididos em: custos de falhas internas e
custos de falhas externas.
Os custos de falhas internas incluem:
retrabalho;
conserto de bugs;
anlise de falhas.
Os custos de falhas externas incluem:
resoluo de queixas;
troca/devoluo do produto;
suporte em help on-line;
trabalhos de segurana.
Os custos relacionados a encontrar e consertar um defeito aumentam drasticamente
quando vamos da preveno de falhas internas para a preveno de falhas externas. Dados
coletados por Boehm [Boe81], ilustram esse fenmeno (figura 1).

Custo relativo do conserto de um erro

1000

40-1000 vezes

100

30-70 vezes
15-40 vezes
10 vezes

10
3-6 vezes
1 vez
1

requisitos

projeto

codificao

desenv. teste

sistema de teste

manuteno

Figura 1

Atributos de Qualidade de Software

A qualidade de software no uma idia to simples. mais fcil descrev-la atravs de
um conjunto de atributos ou fatores requeridos que variam de acordo com as diferentes
aplicaes e os clientes que as solicitam.
Existem vrias formas de se classificar os fatores de qualidade. Uma delas classific-los
como fatores externos e fatores internos. Fatores externos so aqueles cuja presena ou falta num
produto de software pode ser detectada pelos usurios do produto (velocidade, facilidade de uso).
Fatores internos so aqueles que so perceptveis apenas por profissionais de computao
(modularidade). Apesar de apenas os fatores externos terem importncia no final, a chave para
assegurar que eles so satisfeitos so os fatores internos, ou seja, as tcnicas internas so um meio
para atingir qualidade de software externa. Alguns atributos externos so: corretude, robustez,
extensibilidade, reusabilidade, compatibilidade, eficincia, portabilidade, verificabilidade,
integridade e facilidade de uso [Meyer88].
Outra maneira de se classificar os atributos de qualidade divid-los em atributos
funcionais e atributos no funcionais. Os atributos funcionais tipicamente se aplicam a pedaos
do software, mdulos do sistema como um todo e esto mais relacionados com o qu deve ser
feito. J os atributos no funcionais podem se aplicar a qualquer produto do processo de
desenvolvimento: especificaes, cdigo, manuais, etc., e esto mais relacionados com o quo
bem deve ser feito [McDermid94].

Mtricas de Qualidade de Software

Um elemento chave de qualquer processo de engenharia a medio. Ns usamos
medidas para melhor entendermos os atributos dos modelos que criamos e, o mais importante
que ns usamos medidas para avaliarmos a qualidade dos produtos de engenharia ou sistemas que
ns construmos.
Ao contrrio de outras engenharias, a engenharia de software no baseada em
leis quantitativas bsicas, medidas absolutas no so comuns no mundo do software. Ao invs
disso, ns tentamos derivar um conjunto de medidas indiretas que levam a mtricas que fornecem
uma indicao de qualidade de alguma representao do software.
Embora as mtricas para software no sejam absolutas, elas fornecem uma
maneira de avaliar qualidade atravs de um conjunto de regras definidas.
Boehm, Brown e Lipow
Para medir qualidade de software deve-se determinar quais caractersticas
medir e como medir. Boehm, Brown e Lipow (1977) definem uma rvore de atributos de
qualidade de software bem definidos e bem diferenciados (figura 2) [Shn80], onde as direes
das setas indicam implicaes lgicas. Por exemplo, um programa que fcil de ser mantido
deve tambm ser facilmente testado, entendido e modificado.
Portabilidade

Independente Device
Auto Contido
Preciso

Confiabilidade
Usabilidade

Completude
Robustez/Integridade
Consistncia

Eficincia

Facilidade de Medio
Eficincia de Device

Utilidade Geral
Engenharia Humana

Facilidade de Acesso

Facilidade de Teste

Facilidade de Comunicao
Auto Descritivo
Estruturado

Facilidade de Entendimento

Conciso

Manutenibilidade

Legvel
Facilidade de Modificao

Extensibilidade

Figura 2

A estrutura de mais alto nvel reflete o uso de avaliao da qualidade de

software. Boehm, Brown e Lipow enfatizam a aquisio do pacote de software, o qual deve ter as
seguintes caractersticas de nvel mdio na estrutura hierrquica: portabilidade, confiabilidade,
eficincia, engenharia humana e facilidades de teste, uso e modificao.
As caractersticas de mais baixo nvel so primitivas que podem ser
combinadas para formar caractersticas de nvel mdio. As caractersticas primitivas so

recomendadas como mtricas quantitativas delas prprias e das caractersticas de mais alto nvel
[Shn80].
Uma caracterstica primitiva pode ser definida ou medida atravs de uma
checklist. Valores numricos podem ser dados aos atributos de qualidade, em alguns casos isso
pode ser apropriado, como por exemplo, nos atributos de performance, e em outros pode existir
um certo grau de subjetividade.
Tais checklists podem ser teis, mas tendem a crescer e se tornarem
incmodas, surgindo a necessidade de uma organizao especfica e tornando-se especfica para
uma linguagem/sistema.
Mtricas para o Cdigo Fonte (Halstead)
A cincia de software de Halstead (1977) prope as primeiras leis analticas
para o software de computador. Ela usa um conjunto de medidas primitivas que pode ser derivado
depois que o cdigo gerado, ou estimado assim que o projeto est completo [Shn80].
O mtodo de Halstead baseado na habilidade de se obter as seguintes
medidas primitivas num programa:
n1 = o nmero de operadores distintos que aparecem num programa;
n2 = o nmero de operandos distintos que aparecem num programa;
N1 = o nmero total de ocorrncias de operadores;
N2 = o nmero total de ocorrncias de operandos.
Essas medidas podem ser melhor ilustradas atravs da seguinte subrotina em
FORTRAN:
SUBROUTINE SORT (X, N)
DIMENSION X(N)
IF (N .LT. 2) RETURN
DO 20 I = 2,N
DO 10 J = 1,I
IF (X(I) .GE. X(J)) GO TO 10
SAVE = X(I)
X(I) = X(J)
X(J) = SAVE
10 CONTINUE
20 CONTINUE
RETURN
END
Operadores
1 fim de instruo
2 indexador de vetor
3 =
4 IF ()
5 DO
6 ,
7 fim de programa

Contagem
7
6
5
2
2
2
1

Operandos
1 X
2 I
3 J
4 N
5 2
6 SAVE
7 1

Contagem
6
5
4
2
2
2
1

8 .LT.
9 .GE.
10 GO TO 10
n1 = 10

1
1
1
N1 = 28

n2 = 7

N2 = 22

Halstead usa essas medidas primitivas para desenvolver vrias expresses, dentre
elas:
o comprimento global do programa (N = n1 log2 n1 + n2 log2 n2);
o volume real (V = N log2 n): representa o nmero de bits exigido para
especificar um programa, o que o faz independente do conjunto de
caracteres da linguagem usada para expressar o algoritmo, mas muda
quando um algoritmo traduzido de uma linguagem para outra;
o volume mnimo potencial (V = (2 + n2) log2 (2 + n2), onde n2 o
valor mnimo do nmero de operandos nicos): no muda quando um
algoritmo traduzido de uma linguagem para outra;
nvel de programa (L = V/V): foi desenvolvido para comparar
implementaes de um algoritmo em linguagens diferentes. Halstead
valida esta mtrica comparando valores observados e valores medidos,
obtendo um coeficiente de correlao de 0.90;
esforo de programao (E = V/L);
nvel de linguagem (X = LV): implica em um nvel de abstrao na
especificao do procedimento; uma linguagem de alto nvel permite a
especificao de cdigo num nvel de abstrao mais elevado do que a
linguagem Assembler.
As aplicaes da teoria de Halstead incluem vrias estimativas, as quais podem ser
de tempo de programao, de tamanho de programa, de nmero de erros a ser esperado de um
dado programa, entre outras.
A IBM demonstrou uma outra possvel aplicao da teoria de Halstead que foi
aplicar os relacionamentos de software a circuitos de hardware, os quais eram expressos como
um programa de computador.
Uma grande extenso de pesquisa foi realizada para investigar a cincia de
software e pode-se dizer que uma boa concordncia foi encontrada entre os resultados
analiticamente previstos e os experimentais.
Mtricas para Qualidade de Especificao (Davis)
Davis [Dav93] e alguns colegas propem uma lista de caractersticas que
podem ser usadas para avaliar a qualidade do modelo de anlise e da correspondente
especificao de requisitos: falta de ambigidade, completude, corretude, facilidade de
entendimento, verificabilidade, consistncia interna e externa, conciso, facilidade de
rastreamento, facilidade de modificao, preciso e reusabilidade.
Embora muitas das caractersticas acima paream qualitativas, cada uma
pode ser representada usando uma ou mais mtricas, por exemplo, assumindo que existem nr
requisitos numa especificao, tal que nr = nf + nnf, onde nf o nmero de requisitos funcionais
e nnf o nmero de requisitos no funcionais.

Para determinar a falta de ambigidade dos requisitos, Davis e seus colegas

sugerem uma mtrica que baseada na consistncia da interpretao dos revisores de cada
requisito: Q1 = nui/nr, onde nui o nmero de requisitos para os quais todos os revisores tiveram
a mesma interpretao. Quanto mais perto de 1 esteja o valor de Q1, menos ambgua a
especificao.
A completude dos requisitos funcionais pode ser computada por Q2 = nu/
(ni x ns), onde nu o nmero de requisitos de funo nicos, ni o nmero de entradas definidas
ou implicadas pela especificao e ns o nmero de estados especificados. Q2 mede a
percentagem de funes necessrias que tenham sido especificadas para um sistema. Para
inserirmos os requisitos no funcionais nesta mtrica, devemos considerar o grau de validao
dos requisitos: Q3 = nc/(nc + nnv), onde nc o nmero de requisitos que foram validados e nnv
o nmero de requisitos que ainda no foram validados.
Mtricas para Sistemas Orientados a Objetos
Software orientado a objetos (OO) fundamentalmente diferente do
software desenvolvido usando mtodos convencionais. Por esta razo, mtricas usadas para
sistemas OO devem focalizar as caractersticas que distinguem software OO de software
convencional [Pressman97].
Berard [Ber95] define cinco caractersticas que tratam mtricas
especializadas: localizao, encapsulamento, information hiding, herana e tcnicas de abstrao
de objetos.
Localizao uma caracterstica de software que indica a maneira na qual
as informaes so concentradas dentro de um programa.
Encapsulamento o empacotamento de uma coleo de itens.
Information hiding esconde os detalhes operacionais de um componente de
programa.
Herana um mecanismo que capacita a responsabilidade de um objeto ser
propagada para outros objetos.
Abstrao um mecanismo que capacita o projetista a focar nos detalhes
essenciais de um componente de programa sem se preocupar com detalhes de baixo nvel.
Mtricas Orientadas a Classes
A classe a unidade fundamental de um sistema OO. Classes freqentemente so
superclasses de outras classes, as quais herdam seus atributos e suas operaes. As classes
tambm colaboram com outras classes. Cada uma dessas caractersticas pode ser usada como
base para uma mtrica.
Mtricas CK
Chidamber e Kemerer [Chi94] propem seis mtricas de projeto baseadas em
classes para sistemas OO:
- Pesos dos Mtodos por Classe (WMC): assume que n mtodos de complexidade
C1, C2, ..., Cn so definidos para uma classe C. A especfica mtrica de complexidade que
escolhida deve ser normalizada, tal que a complexidade nominal para um mtodo resulte no
valor 1.0.
WMC = Ci, para i = 1 a n.

O nmero de mtodos (e suas complexidades) um indicador razovel para

implementar e testar uma classe. Se o nmero de mtodos para uma dada classe e a rvore de
herana crescem, ela se torna mais e mais especfica, limitando seu potencial de reuso. Por
todas essas razes, WMC deve ser conservado to baixo quanto possvel.
- Profundidade da rvore de Herana (DIT): Esta mtrica definida como o
tamanho mximo do n raiz da rvore. Na figura 3, o valor de DIT para a hierarquia de
classe 4.
Com o crescimento do DIT, fica claro que classes de mais baixo nvel iro herdar
muitos mtodos. Um problema com um valor alto para DIT que existe uma potencial
dificuldade de determinar o comportamento das classes de nveis mais baixos, por outro lado,
isso implica que muito mtodos podem ser reusados.
C

C1

C11

C2

C21

C22

C23

C211

tricas Propostas por Lorenz e Kidd

Lorenz e Kidd [Lor94] dividem mtricas baseadas em classes em quatro
categorias: orientadas ao tamanho, baseadas na herana, internas e externas. Mtricas
orientadas a tamanho em classes OO enfocam a contagem dos atributos e operaes para uma
classe individual e os valores mdios para sistemas OO como um todo. Mtricas baseadas em
herana enfocam a maneira na qual operaes so reusadas atravs da hierarquia de classes.
Mtricas internas verificam a coeso e as caractersticas do cdigo, e mtricas externas
examinam o acoplamento e o reuso.
- Tamanho da Classe (CS): o tamanho total de uma classe pode ser determinado
usando as medidas do nmero total de operaes (tanto operaes de instncia privadas como
operaes de instncia herdadas) que so encapsuladas dentro da classe e do nmero de
atributos (tanto atributos de instncia privados como atributos de instncia herdados) que so
encapsulados por uma classe.
Como pode-se notar, grandes valores para CS indicam que a classe pode ter muita
responsabilidade, o que pode reduzir a reusabilidade da classe e tornar difcil a implementao
e os testes. Em geral, operaes e atributos pblicos ou herdados deveriam ter um peso maior
na determinao do tamanho da classe. Operaes e atributos privados tornam possvel a
especializao e so mais localizados dentro do projeto.
- Mdias para o nmero das operaes e dos atributos de uma classe tambm
podem ser computadas. Quanto menor esse nmero mdio, mais as classes podem ser
reusadas.

- Nmero de Operaes Sobrescritas (Overridden) por uma Subclasse (NOO):

quando uma subclasse redefine uma operao herdada isso caracterizado um overriding.
Valores grandes para NOO geralmente indicam um problema de projeto.
Se NOO grande, o projetista violou a abstrao da superclasse, se isso acontecer
em alguns pontos do projeto, problemas de teste e manuteno podem surgir.
- Nmero de Operaes Adicionadas a uma Classe (NOA): Subclasses so
especializadas pela adio de atributos e operaes privadas. Quanto maior o nmero NOA,
mais especfica se torna a classe, ficando longe do nvel de abstrao proposto pelas suas
superclasses. Em geral, quanto maior o DIT menor os valores para NOA nas classes de nvel
mais baixo da hierarquia.
- ndice de Especializao (SI): o ndice de especializao fornece uma indicao
do grau de especializao para cada subclasse em um sistema OO. A especializao pode ser
alcanada adicionando/retirando operaes ou por overriding.
SI = [NOO x Nvel] / Mtotal;
onde Nvel o nvel na hierarquia de classes na qual a classe reside e M total o nmero total de
mtodos da classe. Valores altos para SI indicam que na hierarquia de classes existe uma (ou
algumas) classe que no est de acordo com a abstrao da superclasse.
Mtricas para Testes em OO
As tcnicas descritas at agora fornecem uma indicao da qualidade do projeto.
Elas tambm fornecem uma indicao geral da quantidade de esforo de testes requerido para
sistemas OO. Mtricas para teste so organizadas em categorias que refletem importantes
caractersticas de projeto:
- Encapsulamento:
Falta de Coeso nos Mtodos (LCOM): valores altos para LCOM implicam
que mais estados deveriam ser testados para garantir que os mtodos no geram efeitos
colaterais.
Percentagem Pblica e Protegida (PAP): atributos pblicos so herdados de
outras classes e, por isso so visveis para essas classes. Atributos protegidos so uma
especializao e so privados para uma especfica subclasse. Esta mtrica indica a
percentagem de atributos de classe que so pblicos. Altos valores para PAP aumentam a
possibilidade de efeitos colaterais entre classes. Testes devem ser projetados para garantir que
tais problemas no venham a ocorrer.
Acesso Pblico para Dados (PAD): esta mtrica indica o nmero de classes
(ou mtodos) que podem acessar outro atributo de uma outra classe (uma violao de
encapsulamento). Valores altos para PAD aumentam a possibilidade de efeitos colaterais entre
classes. Testes devem ser projetados para garantir que tais problemas no venham a ocorrer.
- Herana:
Nmero de Classes Raiz (NOR): esta mtrica um contador do nmero de
hierarquias distintas de classes que so descritas no projeto do modelo. Quando NOR
aumentado, o esforo para o teste tambm .
Fan in (FIN): Quando usado no contexto OO, fan-in uma indicao de
herana mltipla. FIN > 1 indica que uma classe herda seus atributos e operaes de mais de
uma classe raiz. FIN > 1 deveria ser evitado quando possvel.
Nmero de Filhos (NOC) e Profundidade na rvore de Herana (DIT):
mtodos da superclasse devem ser retestados para subclasses.

Mtricas para Projeto OO

Como sabemos, o trabalho de um gerente de projeto planejar, coordenar,
verificar a evoluo e controlar o projeto de software. Um dos pontos chave para um gerente
de projeto durante a fase de planejamento uma estimativa do tamanho do software. Tamanho
diretamente proporcional ao esforo e durao. As seguintes mtricas OO [Lor94] podem
fornecer uma idia do tamanho do software:
- Nmero de Scripts de Cenrio (NSS): o nmero de scripts de cenrio, ou casos
de uso, diretamente proporcional ao nmero de classes requeridas para encontrar os
requisitos, o nmero de estados para cada classe e o nmero de mtodos, atributos e
colaboraes. O NSS um forte indicador do tamanho do programa.
- Nmero de Classes Chaves (NKC): Uma classe chave enfoca diretamente o
domnio do negcio para um determinado problema e ter uma probabilidade baixa de ser
implementada via reuso. Por esta razo, valores altos para NKC indicam um substancial
trabalho de desenvolvimento. Lorenz e Kidd [Lor94] sugerem que entre 20% e 40% de todas
as classes em um tpico sistema OO so classes chaves.
- Nmero de Subsistemas (NSUB): o nmero de subsistemas fornecem um
entendimento da alocao de recursos, do cronograma e do esforo total de integrao.
Motivao para o uso de Mtricas de Qualidade
Independentemente da mtrica usada, elas buscam sempre os mesmos objetivos:
melhorar o entendimento da qualidade do produto;
atestar a efetividade do processo;
melhorar a qualidade do trabalho realizado a nvel de projeto.

Garantia de Qualidade de Software (SQA)

Um dos desafios crticos para qualquer programa de qualidade tornar possvel que
qualquer pessoa possa fazer revises no trabalho de pessoas experientes. Gerentes querem os
melhores projetistas para projetar o produto, ento, em geral, SQA no pode t-los. A necessidade
concentrar esforos em mtodos de SQA que permitam que o desenvolvimento possa ser
revisado por pessoas que no so desenvolvedores. O papel de SQA monitorar os mtodos e os
padres que os engenheiros de software usam e verificar se eles esto usando apropriadamente
seus conhecimentos. Pessoas podem ser experientes em SQA sem, no entanto, serem experientes
em projeto de software.
Atividades de Garantia de Qualidade de Software
Em SQA temos uma variedade de tarefas, as quais podemos dividir em dois
grandes grupos: os engenheiros de software que fazem o trabalho tcnico e o grupo de SQA que
tem responsabilidades no plano de qualidade, na inspeo, na conservao de registros histricos,
na anlise e no reporting das atividades de SQA para o gerente do projeto.
Os engenheiros de software buscam qualidade de software aplicando slidos
mtodos e medidas, conduzindo revises tcnicas formais e realizando testes de software bem
planejados.
O papel do grupo de SQA ajudar o time de engenharia de software a alcanar um
produto de alta qualidade.

O Instituto de Engenharia de Software (SEI) recomenda as seguintes atividades a

serem realizadas por um grupo de SQA:
Preparar um plano de SQA (ver seo 6.3) para o projeto. O plano
desenvolvido durante o planejamento do projeto e revisado por todas as partes
interessadas.
Participar do desenvolvimento da descrio do processo do projeto do software.
O time de engenharia de software seleciona um processo para o trabalho a ser
realizado. O grupo de SQA revisa a descrio do processo, verificando se o
mesmo est de acordo com a poltica organizacional, aos padres internos para
o software, aos padres impostos externamente e a outras partes do plano de
projeto de software.
Revisar as atividades dos engenheiros de software para verificar se o processo
de software definido est sendo seguido. O grupo de SQA identifica, documenta
e trilha os desvios do processo e verifica quais correes devem ser realizadas.
Garantir que os desvios no trabalho do software e nos produtos do trabalho so
documentados e mantidos de acordo com o procedimento documentado.
Registrar qualquer discordncia e reportar para o gerente.
Alm dessas atividades, o grupo de SQA coordena o controle e o gerenciamento de
mudanas e ajuda a coletar e analisar mtricas de software.
Medidas de Produtividade de Programao
Zak (1977) lista os seguintes cinco atributos de produtividade: corretude,
habilidade para cumprir cronogramas, adaptabilidade, eficincia e, por fim ausncia de erros. Ele
admite que existem controvrsias em relao a quais variveis deveriam ser medidas e que efeito
elas podem ter na produtividade. Zak d a seguinte mtrica para taxa de programao:
R = L/(ST);
onde R a taxa de programao em linhas de cdigo fonte por pessoas-ms; L o nmero de
linhas de cdigo fonte do produto final; S o nvel do staffing e T o cronograma (em meses).
Existe um certo consenso em relao aos critrios mais importantes de produtividade: qualidade
da documentao externa, linguagem de programao, disponibilidade de ferramentas,
experincia do programador no processamento dos dados, experincia do programador na rea
funcional, comunicao no projeto, mdulos independentes e prticas de programao bem
definidas.
Revises de Software
Revises de software so um filtro no processo de engenharia de software. Isto ,
revises so aplicadas a vrios pontos durante o desenvolvimento de software e serve para
descobrir erros que podem ser removidos. Revises no so limitadas a especificao, projeto e
cdigo. Documentos, tais como, plano de teste, procedimentos de gerenciamento de
configurao, padres e normas de usurio deveriam tambm ser revisados [Sommerville92].
Existem vrios tipos de reviso:
Inspees no projeto e no cdigo: tm a finalidade de detectar erros no projeto
ou cdigo e checar quando padres tm sido seguidos.
Revises gerenciais: esse tipo de reviso feita para fornecer informaes aos
gerentes sobre todo o processo no desenvolvimento do projeto de software.

 Revises de qualidade: o trabalho de um indivduo ou de um time revisado

por um grupo composto por membros do projeto e gerentes tcnicos.
O dicionrio de padres do IEEE define defeito como uma anomalia do produto.
Um defeito implica em um problema na qualidade que descoberto depois que o software foi
entregue ao usurio final.
O objetivo primrio de revises tcnicas formais encontrar erros durante o
processo antes que eles se tornem defeitos aps o release do software. Um benefcio bvio de
revises tcnicas formais a descoberta de erros antes que eles se propaguem para as prximas
fases do processo de software.
Estudos de algumas indstrias indicam que as atividades de projeto introduzem
entre 50% e 60% de todos os erros durante o processo de software. Entretanto, tcnicas de
revises formais tm atingido um percentual de 75% na descoberta desses erros, reduzindo o
custo dos passos subsequentes.

Confiabilidade
No h dvidas de que a confiabilidade de um programa de computador um
elemento importante para sua qualidade. Se um programa falha freqentemente e repetidamente,
no importa muito se outros fatores de qualidade so aceitveis.
Confiabilidade de software pode ser medida, direcionada e estimada usando dados
histricos e de desenvolvimento. Ela definida em termos estatsticos como a probabilidade de
uma operao de programa de computador ser livre de falha. Para ilustrar isto, digamos que um
programa X estimado ter uma confiabilidade de 0.96 em oito horas de processamento, ou seja,
se o programa X fosse executado 100 vezes em oito horas de processamento (tempo de
execuo), provvel que ele opere corretamente (sem falhas) em 96 das 100 vezes
[Pressman97].
Uma questo que surge ao se discutir sobre qualidade o que significa o termo
falha. No contexto de qualquer discusso sobre qualidade e confiabilidade de software, falha a
no conformidade com os requisitos de software. Ainda existem gradaes nesta definio.
Falhas podem ser apenas incmodas ou catastrficas. Uma falha pode ser corrigida dentro de
segundos, enquanto uma outra pode requerer semanas ou at mesmo meses para ser corrigida.
Alm disso, a correo de uma falha pode resultar na introduo de outros erros que no final
resultam em outras falhas.
Medidas de Confiabilidade e Disponibilidade
Os primeiros trabalhos em confiabilidade de software tentaram extrapolar a
matemtica da teoria de confiabilidade de hardware para a previso de confiabilidade de
software. A maioria dos modelos relacionados confiabilidade de hardware so estabelecidos em
falhas devido ao uso (desgaste), ao invs de falhas devido a defeitos de projeto, porque as falhas
de desgaste fsico so mais provveis de acontecer. Infelizmente, o oposto disto verdade para
software.
Ainda existe debate sobre os relacionamentos entre os conceitos chave de
confiabilidade de hardware e sua aplicabilidade a software. Embora exista uma ligao,
importante considerar poucos conceitos simples que se aplicam a ambos.
Considerando um sistema baseado em computador, uma simples medida de
confiabilidade o tempo mdio entre falhas (MTBF), onde:

MTBF = MTTF + MTTR,

MTTF = tempo mdio para a falha e MTTR = tempo mdio para o reparo.
Muitos pesquisadores argumentam que MTBF uma medida mais til do que defeitos/KLOC,
pois um usurio final preocupa-se com falhas, e no com o nmero total de defeitos. O nmero
total de defeitos fornece pouca indicao da confiabilidade de um sistema porque cada defeito
dentro de um programa no tem a mesma taxa de falha. Muitos defeitos num programa podem
permanecer sem ser detectados por dcadas (MTBF longo) e, se eles so removidos, o impacto na
qualidade de software imperceptvel [Pressman97].
Alm da medida de confiabilidade, deve-se desenvolver uma medidade de
disponibilidade, a qual a probabilidade de que um programa esteja operando de acordo com os
requisitos num dado ponto no tempo, e definida como:
Disponibilidade = MTTF/(MTTF + MTTR) X 100%.
A medida de disponibilidade mais sensvel ao MTTR, uma medida
indireta da manutenibilidade de software.
Segurana X Confiabilidade
Na seo anterior, foi discutido o papel da anlise da confiabilidade de
software. No obstante, a confiabilidade e a segurana de software estejam estreitamente
relacionadas, importante compreender a sutil diferena entre elas. A confiabilidade de software
usa a anlise estatstica para determinar a probabilidade de que uma falha de software venha a
ocorrer. Entretanto, a ocorrncia de uma falha no necessariamente resulta num risco ou
deformao. A segurana de software examina as maneiras segundo as quais as falhas resultam
em condies que podem levar a uma deformao. Ou seja, as falhas no so consideradas no
vazio, mas so avaliadas no contexto de um sistema inteiro computadorizado.
Segurana de software um atividade de garantia de qualidade de software
que se concentra na identificao e avaliao de casualidades em potencial que possam exercer
um impacto negativo sobre o software e fazer com que todo o sistema falhe.
Logo que as casualidades a nvel de sistema so identificadas, tcnicas de
anlise so usadas para definir a gravidade e a probabilidade de ocorrncia, tais como, anlise em
rvore, lgica de tempo real ou modelos de rede de Petri. Aps as casualidades serem
identificadas e analisadas, os requisitos relacionados segurana podem ser especificados para o
software.

Controle de Qualidade
Como fazer Controle de Qualidade
possvel observar que o controle de qualidade algo que consome tempo no
desenvolvimento de sistemas de software, e, claro, vai alm da entrega do sistema e entra na
fase de manuteno. Poderamos generalizar dizendo que deveramos identificar controle de
qualidade sobre todos os produtos em cada estgio. Toda atividade deve culminar em uma
atividade de controle de qualidade desejada.
Desde que desejamos ser capazes de definir atividades de controle de qualidade
para toda atividade durante o desenvolvimento, faz sentido verificar como as tcnicas usadas para
cada atividade podem contribuir para o controle de qualidade delas. Algumas tcnicas so boas,
tm controle de qualidade embutido, outras no tm, e deve-se, ento, aplicar aes de controle
de qualidade gerais para fazer o controle eficientemente.

Plano de SQA
Cada projeto de desenvolvimento e manuteno deveria ter um Plano de Controle
de Qualidade (SQAP) que especifica seus objetivos, as tarefas de SQA a serem realizadas, os
padres contra os quais o trabalho de desenvolvimento para ser medido e os procedimentos e a
estrutura organizacional. O Plano de SQA constitui um mapa rodovirio para a instituio da
garantia de qualidade de software.
O padro IEEE (Padro ANSI/IEEE 730-1984 e 983-1986) para a preparao do
SQAP contm os seguintes tpicos [Humphrey89]:
I.
Propsito do plano
II.
Documentos de referncia
III.
Administrao
A.
Organizao
B.
Tarefas
C.
Responsabilidades
IV.
Documentao
A.
Propsito
B.
Documentos de engenharia de software exigidos
C.
Outros documentos
V.
Padres, prticas e convenes
A.
Propsito
B.
Convenes
VI.
Revises auditoriais
A.
Propsito
B.
Requisitos de reviso
1.
Reviso dos requisitos de software
2.
Revises de projeto
3.
Verificao de software e revises de validao
4.
Auditoria funcional
5.
Auditoria fsica
6.
Auditorias in-process
7.
Revises administrativas
VII. Gerenciamento de configurao de software
VIII. Reportagem de problemas e aes corretivas
IX.
Ferramentas, tcnicas e metodologias
X.
Controle de cdigo
XI.
Controle de mdia
XII. Controle de fornecedores
XIII. Coleta, manuteno e reteno de registros
A seo de documentao deveria descrever a documentao a ser produzida e
como para ela ser revisada. Os documentos de engenharia de software exigidos podem ser:
Especificao de Requisitos, Descrio de Projeto, Plano de Verificao e Validao, Relatrio de
Verificao e Validao e Documentao do Usurio. O Plano de Verificao e Validao uma
descrio dos mtodos usados para verificar se os requisitos so implementados no projeto, se o
projeto implementado no cdigo e se o cdigo atinge os requisitos. Outros documentos podem
ser: Plano de Desenvolvimento de Software, Plano de Gerncia de Configurao de Software,
Manual de Padres e Procedimentos.

A seo de padres, prticas e convenes especifica um contedo mnimo de:

padres de documentao;
padres de estrutura lgica;
padres de codificao;
padres de comentrios.
A auditoria funcional uma auditoria feita antes da entrega do sistema para
verificar se os requisitos foram encontrados. A auditoria fsica tambm feita antes da entrega do
sistema para verificar se o software e a documentao esto consistentes com o projeto e prontos
para serem entregues. A auditoria in-process uma amostra estatstica do processo de
desenvolvimento que feita para verificar a consistncia do o cdigo versus as especificaes de
projeto e interface, do projeto versus os requisitos e os planos de testes versus os requisitos. As
revises administrativas so revises independentes, conduzidas para a verificao da execuo
do plano de qualidade.
Muitos dos padres so requeridos para definir apropriadamente a operao de
uma organizao de software.
Pessoas de SQA
Alocar pessoas para trabalhar com SQA uma tarefa difcil dos gerentes de
software. A prtica de iniciar novas contrataes em SQA uma soluo parcial que pode ser
efetiva apenas se existem pessoas experientes no mercado. Recrutar pessoas para trabalhar em
SQA difcil tambm porque os profissionais de software geralmente preferem atribuies de
desenvolvimento e a gerncia certamente quer atribuir aos melhores projetistas o trabalho de
projeto. O esquema de rotatividade tambm pode ser efetivo, mas infelizmente, o
desenvolvimento de software geralmente adepto a transferir pessoas para trabalhar em SQA e
no peg-las de volta.
Uma soluo efetiva requerer que todos os novos gerentes de desenvolvimento
sejam promovidos para trabalharem em SQA. Isso poderia significar que potenciais gerentes
poderiam passar entre seis meses e um ano em SQA, antes de serem promovidos gerncia. Essa
uma medida extrema, mas pode ser efetiva [Humphrey89].
Para o trabalho de SQA ser efetivo, deve haver bons profissionais na equipe e um
completo apoio da gerncia, no sentido de investimento mesmo.

Sistemas de Gerenciamento de Qualidade

Personal Software Process (PSP)
O estmulo original para desenvolver o PSP surgiu de questes sobre o Capability
Maturity Model (CMM) do Software Engineering Institute (SEI). Muitos viam o CMM como
projetado para grandes organizaes e no entendiam como ele poderia ser aplicado a trabalhos
individuais e em times pequenos de projeto. Apesar do CMM poder ser aplicado para ambas,
pequenas e grandes organizaes, uma orientao mais especfica se tornava claramente
necessria. Aps alguns anos de pesquisa, 12 das 18 reas-chave de processo do CMM (ver
seo 7.2) foram adaptadas para o trabalho de engenheiros de software individuais.
O principal objetivo do PSP fazer com que os engenheiros de software fiquem
atentos no processo que eles usam para fazer seus trabalhos e estejam sempre verificando suas
performances no processo. Engenheiros de software so treinados individualmente para um
conjunto de objetivos pessoais, definindo os mtodos a serem usados, medindo seus trabalhos,

analisando os resultados, e ajustando os mtodos para atingir seus objetivos. O PSP uma
estratgia para o desenvolvimento pessoal com o objetivo de aumento de produtividade.
Trabalhos experimentais foram iniciados em algumas corporaes para verificar
como engenheiros experientes poderiam reagir ao PSP e explorar a introduo de seus mtodos.
Foi verificado que os engenheiros de software geralmente so atrados pela estratgia do PSP e
encontram mtodos que ajudam em seus trabalhos. Nas palavras de um engenheiro, Isto no
para a empresa, para mim. O leitor interessado pode obter informaes adicionais em [SEI] e
[Humphrey].
O PSP aplica princpios de processo para o trabalho do engenheiro de software
por:
Fornecer um padro de processo pessoal definido.
Introduzir uma famlia de medidas de processo.
Usar essas medidas para trilhar e avaliar a performance.
Se esforar para obter critrios de qualidade e melhorar os objetivos.
Usando o PSP, engenheiros:
Desenvolvem um plano para todo projeto.
Registram seu tempo de desenvolvimento.
Trilham seus defeitos.
Mantm dados de um projeto em relatrios resumidos.
Usam esses dados para planos de projetos futuros.
Analisam dados que envolvem seus processos a fim de aumentar suas
performances.
Capability Maturity Model (CMM)
O Modelo de Maturidade de Capacidade para Software (CMM) foi desenvolvido
pelo Instituto de Engenharia de Software (SEI). Ele descreve os princpios e prticas relacionados
maturidade do processo de software, e seu objetivo ajudar as organizaes a melhorarem seus
processos de software em termos de um caminho evolutivo que vai de ad hoc e processos
caticos a processos de software maduros e disciplinados.
O CMM organizado em cinco nveis de maturidade. Um nvel de maturidade
uma base evolucionria bem definida direcionada a obter um processo de software maduro. Cada
nvel de maturidade fornece uma camada como base para um processo de melhora contnuo.
Os Cinco Nveis de Maturidade
As seguintes caracterizaes dos cinco nveis de maturidade destacam as
mudanas do processo primrio feitas em cada nvel [Paulk94]:
1. Inicial: O processo de software caracterizado como ad hoc e,
ocasionalmente catico mesmo. Poucos processos so definidos e o
sucesso depende de esforos individuais e hericos.
2. Reproduzvel: Os processos de administrao do projeto bsico so
estabelecidos para trilhar custo, cronograma e funcionalidade. A
disciplina de processo necessria estabelecida para se repetir sucessos
anteriores em projetos com aplicaes similares.
3. Definido: O processo de software para as atividades de administrao e
engenharia documentado, padronizado e integrado num processo de

software padro para a organizao. Todos os projetos usam uma

verso aprovada e feita sob medida do processo de software padro da
organizao para desenvolvimento e manuteno de software.
4. Gerenciado: Medidas detalhadas do processo de software e da
qualidade do produto so coletadas. Ambos, o processo de software e o
produto, so entendidos e controlados quantitativamente.
5. Otimizado: Um processo de melhora contnuo capacitado por retorno
quantitativo do processo e das idias e tecnologias inovadoras.

reas-Chave de Processo
Exceto para o nvel 1, cada nvel de maturidade decomposto em vrias
reas-chave de processo que indicam as reas que uma organizao deveria enfocar para
melhorar seu processo de software. Cada rea-chave de processo (KPA) identifica um grupo de
atividades relacionadas que, quando realizadas coletivamente, atingem um conjunto de objetivos
considerados importantes para a melhoria da capacidade do processo.
Por definio, no existem reas-chaves de processo para o nvel 1.
As reas-chave de processo para o nvel 2 enfocam os interesses
relacionados ao estabelecimento de controle bsico de administrao de projeto.
As reas-chave de processo para o nvel 3 enfocam os problemas
organizacionais e de projeto, como a organizao estabelece uma infra-estrutura que
institucionaliza uma engenharia de software efetiva e uma administrao de processos em todos
os projetos.
As reas-chave de processo para o nvel 4 enfocam em estabelecer um
entendimento quantitativo de ambos, o processo de software e o produto sendo construdo.
As reas-chave de processo para o nvel 5 cobrem os problemas que
ambos, organizao e projetos, devem enderear para implementar uma melhora contnua e
mensurvel do processo de software.

Nvel de Maturidade reas-Chave de Processo

1. Inicial
No possui reas-chave de processo.
2. Reproduzvel
Administrao dos Requisitos, Planejamento de Projeto de
Software, Acompanhamento de Projeto de Software,
Gerenciamento de Subcontrato de Software, Garantia de
Qualidade de Software e Gerenciamento de Configurao de
Software.
3. Definido
Foco no Processo da Organizao, Definio do Processo da
Organizao, Programa de Treinamento, Administrao de
Software Integrado, Engenharia de Produto de Software e
Revises.
4. Gerenciado
Gerenciamento da Qualidade de Software e Gerenciamento
Quantitativo do Processo.
5. Otimizado
Preveno de Defeito, Gerenciamento de Mudana de
Tecnologia e Gerenciamento de Mudana no Processo.
processo para cada nvel de maturidade:

A
tabela
abaixo
mostra
todas
as
reaschave
de

Por convenincia, cada uma dessas reas-chave de processo organizada por caractersticas
comuns, que so atributos que indicam quando a implementao e institucionalizao de uma
rea-chave de processo efetiva, reproduzvel e durvel. So elas: Compromisso a Realizar,
Habilidade para Realizar, Atividades Realizadas, Medio e Anlise e Verificao da
Implementao [Paulk94].
Cada rea-chave de processo descrita em termos de prticas chave que
contribuem para satisfazer seus objetivos. As prticas chave descrevem a infra-estrutura e as
atividades que contribuem para a implementao e institucionalizao efetiva da rea-chave de
processo.
ISO 9001
Um sistema de controle de qualidade pode ser definido em termos de estrutura
organizacional, responsabilidades, procedimentos, processos e recursos para implementar
gerenciamento de qualidade. A srie de padres ISO 9000 um conjunto de documentos que
trabalham com sistemas de qualidade que podem ser usados para propostas de garantia de
qualidade externa. O ISO 9000 (Padres de Gerenciamento e de Garantia de Qualidade -

Diretrizes para Seleo e Uso) descreve elementos de garantia de qualidade em termos genricos
que podem ser aplicados para qualquer empresa de produtos ou servios oferecidos.
Para uma empresa ser registrada com o certificado ISO 9000, o sistema de
qualidade da empresa e as operaes so investigadas por trs auditores para verificar se o padro
e as operaes esto de acordo com as normas estabelecidas. Verificaes peridicas so
efetuadas para verificar se os padres esto sendo mantidos.
O modelo de garantia de qualidade ISO 9000 trata uma empresa como uma rede de
processos interconectados. Para um sistema de qualidade estar de acordo com a ISO, esses
processos devem enderear as reas identificadas no padro e devem ser documentados e
praticados como desejado. Documentar um processo ajuda uma organizao a entender, controlar
e melhorar o mesmo.
O ISO 9000 descreve os elementos de sistemas de garantia de qualidade em
termos gerais. Esses elementos incluem a estrutura organizacional, procedimentos, processos e
recursos necessrios para implementar o plano de qualidade, o controle de qualidade, a garantia
de qualidade e o melhoramento da qualidade. Entretanto, o ISO 9000 no descreve como uma
organizao poderia implementar esses elementos de sistemas de qualidade.
O ISO 9001 (Sistemas de Qualidade - Modelo para Garantia de Qualidade em
Projeto/Desenvolvimento, Produo, Instalao e Servio) o padro de garantia de qualidade
que aplicado para engenharia de software. O padro contm 20 requerimentos que devem estar
presentes para um sistema de garantia de qualidade efetivo. Como o padro ISO 9001 aplicado
a todas as disciplinas de engenharia, um conjunto especial de guia ISO (ISO 9000-3) tem sido
desenvolvido para ajudar a interpretar o padro para uso no processo de software.
O ISO 9001 define os 20 maiores requerimentos sobre um sistema gerenciador de
qualidade [McDermid94]:
1. Gerncia de responsabilidades. A organizao deve definir e documentar
polticas de gerenciamento e objetivos que se comprometem com a qualidade e
devem garantir que essas polticas so entendidas, implementadas e mantidas
em todos os nveis da organizao.
2. Um sistema de qualidade documentado. Esse sistema deve cobrir o controle de
todas as atividades em desenvolvimento e ter a documentao de todos os
procedimentos.
3. Revises de contrato. Isso includo para garantir que um contrato inicie com
os requerimentos do sistema conhecidos por ambas as partes e que o
desenvolvedor seja capaz de entregar para o comprador o que foi estabelecido.
4. Controle de projeto. O padro requer que o desenvolvimento tenha, e use,
procedimentos para controlar e verificar a qualidade do projeto do sistema para
garantir que ele encontre seus requerimentos.
5. Documentao e controle de mudanas. Esta uma rea especialmente
importante para o desenvolvimento de software, onde muito do que
desenvolvido toma a forma de documentos e dados: especificao, projeto,
cdigo, dados de teste, etc.
6. Compra/aquisio. Verificar a qualidade, de alguma forma, se desejar
incorporar alguma coisa no sistema.
7. Produtos fornecidos pelo comprador. Esta seo de padro requer
procedimentos para verificao, armazenamento e manuteno dos itens
comprados/fornecidos.

8. Identificao do produto e traceability. Este tem sido um importante

procedimento para desenvolvedores de software os quais, como outros
engenheiros, constrem suas aplicaes a partir de muitos componentes
pequenos.
9. Controle do processo. Isto um requerimento geral em que o processo de
produo ele mesmo deve ser planejado e monitorado.
10.
Inspees e testes. O padro requer que inspees e testes devem ser feitos
durante o processo de desenvolvimento. Registros dos testes devem ser
conservados.
11.
Inspees, medidas e testes de equipamentos. Poderamos considerar
equipamentos como ferramentas de software, que devem ser controladas com
relao qualidade, verso, etc.
12.
Inspees e status do teste. A qualidade de todos os itens em todos os
estgios de seu desenvolvimento deve ser claramente conhecida e o status de
teste deve ser conhecido de alguma forma todo o tempo.
13.
Controle dos produtos que no esto em conformidade com o padro.
Produtos que no esto enquadrados aos padres no devem ser usados.
14.
Ao corretiva. Se um erro encontrado em um item quando uma
checagem de controle feita sobre ele existem duas coisas que devem ser feitas.
Primeiro, o erro deve ser removido do item; segundo, o processo envolvido na
sua produo necessita ser checado para verificar se ele deve ser trocado para
evitar que tal erro volte a acontecer.
15.
Manuseio, armazenamento, empacotamento e entrega do produto. Uma
organizao que faz e vende um produto de software necessita considerar que
seus produtos devem ser replicados de forma confivel, para garantir que
verses corretas do software sejam entregues aos clientes corretos.
16.
Registros de qualidade. O padro requer que o desenvolvedor garanta que
registros suficientes so mantidos para demonstrar que a qualidade requerida
tem sido alcanada e que o sistema de gerenciamento de qualidade est
operando eficientemente.
17.
Auditoria de qualidade interna.
18.
Treinamento. Se a equipe no adequadamente treinada para fazer seu
trabalho claro que o trabalho das pessoas da equipe no ir atingir o grau de
qualidade desejado.
19.
Servicing.
20.
Tcnicas estatsticas. So usadas para verificar a aceitao das
caractersticas do produto.
Comparao entre ISO 9001 x CMM
O CMM e o ISO 9001 compartilham interesses comuns com qualidade e
gerenciamento de processo. Alm de possurem interesses similares, eles so intuitivamente
correlacionados.
Questes que podem surgir quando comparando os dois so:
Em que nvel do CMM poderia se encaixar uma organizao em conformidade
com o ISO 9001?

Uma organizao de nvel 2 (ou 3) no CMM poderia ser considerada em

conformidade com o ISO 9001?
Meus esforos na melhoria do processo e no gerenciamento de qualidade
deveriam ser baseados no ISO 9001 ou no CMM?
Uma anlise feita das diferenas e similaridades entre o CMM e o ISO 9001 indica
que, embora uma organizao em conformidade com o ISO 9001 no necessariamente satisfaria
todas as reas-chave de processo do nvel 2 do CMM, ela satisfaria a maioria dos objetivos do
nvel 2 e muitos dos objetivos do nvel 3. Devido existncia de prticas no CMM que no so
endereadas no ISO 9001, possvel para uma organizao no nvel 1 receber um certificado ISO
9001; similarmente, existem reas endereadas pelo ISO 9001 que no so endereadas no CMM.
Uma organizao no nvel 3 poderia ter pouca dificuldade em obter um certificado ISO 9001, e
uma organizao no nvel 2 poderia ter vantagens significativas em obter o mesmo certificado
[Paulk94].
A maior diferena, contudo, entre esses dois documentos a nfase do CMM no
contnuo processo de melhora. O ISO 9001 enfoca o critrio mnimo para um sistema de
qualidade aceitvel. Alm disso, o CMM enfoca estritamente o software, enquanto que o ISO
9001 tem um escopo mais abrangente: software, hardware, materiais processados e servios.
A maior similaridade que para ambos, o CMM e o ISO 9001, a linha base
dizer o que fazer e fazer o que diz. A premissa fundamental do ISO 9001 que todo processo
importante deveria ser documentado e tudo que entregue deveria ter sua qualidade testada
atravs de uma atividade de controle de qualidade. O ISO 9001 requer uma documentao que
contm instrues ou um guia do que deveria ser feito ou como deveria ser feito. O CMM
compartilha essa nfase em processos que so documentados. Viso Crtica sobre Controle de
Qualidade de Software

O grande problema no controle de qualidade de software ainda a falta de conscincia de

muitas empresas e profissionais que lidam com sistemas complexos em adotarem uma poltica de
qualidade nos trabalhos a serem desenvolvidos.
Como prova disso, recorremos a uma pesquisa realizada em 1995 pelo Subprograma
Setorial da Qualidade e Produtividade em Software (SSQP/SW), onde foi indicado que
[CESAR97]:
apenas 38,9% das empresas incluem sistematicamente metas ou diretrizes para
qualidade em seus planos;
25,1% delas coletam sistematicamente indicadores de qualidade de seus produtos e
servios;
apenas 11,5% tm um programa de qualidade total implantado;
a grande maioria (85,9%) no conhece o modelo CMM;
66,6% no adota nenhum procedimento especfico de garantia da qualidade do
produto de software;
a avaliao de desempenho dos funcionrios feita periodicamente em apenas 16,4%
das empresas. 54,1% delas disseram faz-la informalmente.
O importante no o modelo a ser seguido. Quando o objetivo otimizar a qualidade do
software, deve-se ter cuidado, porm, em definir certos limites para os resultados a serem
alcanados. A criao de software com qualidade requer um esforo tanto a nvel financeiro
quanto a nvel de conscientizao das pessoas envolvidas no processo, sem, no entanto, sarmos
da rbita em que o cliente o termmetro da qualidade de um determinado produto. Mesmo se o
produto (software) alcanar grande parte dos requisitos de qualidade, mas ultrapassar uma data

que seja de vital importncia para o cliente, o produto no ter qualquer serventia e, por isso,
deve-se ter um compromisso, com prazos e outras coisas mais e, em certos casos, desejvel
restringir o escopo da qualidade (partindo do mximo da qualidade para uma qualidade muito
boa) a ser atingida, a fim de satisfazer as necessidades do cliente. Esta uma viso realstica de
encarar qualidade de software nos sistemas a serem desenvolvidos.

Notas
Qualidade um conceito complexo, porque ela significa diferentes coisas para diferentes
pessoas, ela altamente dependente do contexto. Ento, no h uma simples medida para
qualidade de software que seja aceitvel para todos os projetos de todas as empresas.
Para estabelecer ou melhorar a qualidade de software, o que se deve fazer definir os
aspectos de qualidade nos quais se est interessado e, ento, decidir como fazer para med-los.
Antes de projetar a qualidade num software, os desenvolvedores devem concordar nas
caractersticas que denotam a qualidade e nos termos que vo descrever essas caractersticas.
Apesar dos custos elevados para a introduo de certos sistemas de gerenciamento de
qualidade de software, como o CMM ou o ISO 9001, importante tais mtodos serem
introduzidos, a fim de que uma empresa sobreviva por um longo tempo e possa estar sempre
atualizada, com um nvel de produo de software de alta qualidade, satisfazendo sempre as
necessidades de seus clientes.