QSW 01 Unidade I Capitulo1 - Qualidade de SW PDF

Captulo 1
O que qualidade?
A qualidade relativa. O que qualidade para uma pessoa

pode ser falta de qualidade para outra.
G. Weinberg
A idia de qualidade aparentemente intuitiva; contudo, quando examinado mais

longamente, o conceito se revela complexo. Definir um conceito de qualidade para es-
tabelecer objetivos , assim, uma tarefa menos trivial do que aparenta a princpio.
Este captulo enfatiza como a noo de qualidade pode ser relativa e introduz
as dificuldades bsicas relacionadas ao tratamento desse assunto.
1.1 Histria
Embora o controle de qualidade e o uso de padres como ISO sejam algo que tenha
atrado bastante ateno nas ltimas dcadas, historicamente o assunto muito
antigo. Existem relatos histricos segundo os quais h mais de quatro mil anos
os egpcios estabeleceram um padro de medida de comprimento: ocbito. Essa
medida correspondia ao comprimento do brao do fara reinante. Curiosamente, a
troca de fara significava que a medida deveria ser atualizada. Todas as construes
deviam ser realizadas utilizando o cbito como unidade de medida. Para isso eram
empregados bastes cortados no comprimento certo e periodicamente a cada
lua cheia o responsvel por uma construo devia comparar o padro que estava
sendo utilizado com o padro real. Se isso no fosse feito e houvesse um erro de
medio, o responsvel poderia ser punido com a morte [Juran e Gryna, 1988]. O
resultado da preocupao com rigor evidente na construo das pirmides, em
que os egpcios teriam obtido precises da ordem de 0,05%.
Site Internet da EOS (Egyptian Organization for Standardization and Quality Control)
(2005).
17
18 Qualidade de Software
A histria da qualidade prosseguiu com inmeros exemplos de resultados extra-

ordinrios: os grandes templos construdos na Grcia e Roma antigas, os feitos de
navegao no sculo XVI, as catedrais medievais. Em todas essas realizaes, no se
dispunha de instrumentos de preciso ou tcnicas sofisticadas Na Frana, os cons-
trutores de catedrais utilizavam simples compassos e cordas com ns a intervalos
regulares para desenhar e construir edifcios [Vincent, 2004].
Em geral, espera-se que obter mais preciso exija mais recursos ou mais tecno-
logia. Assim, a regulagem da carburao de um motor de um veculo moderno no
pode ser feita como no passado, quando, com uma lmpada, um mecnico conseguia
acertar o ponto do distribuidor. O exemplo dos antigos egpcios nos faz pensar
uma questo curiosa: como teriam sido as pirmides se, na poca, os trabalhadores
dispusessem de medidores a laser?
Como veremos ao longo do livro, a qualidade de software ainda depende princi-

palmente do correto emprego de boas metodologias pelos desenvolvedores. Embora
eles sejam apoiados por vrias ferramentas, ainda restam problemas srios sem tal
suporte. As tcnicas para verificao automtica, dentre as quais a interpretao
abstrata [Cousot, 2000] um excelente exemplo, ainda so incipientes.
Um grande marco na histria da qualidade foi, com certeza, a revoluo indus-

trial. Esse perodo tambm associado a profundas mudanas econmicas e sociais,
como o incio da automao e o surgimento do consumo de massa. Durante essa
poca de efervesncia, milhares de novas empresas surgiram. A criao de diversas
indstrias levou rapidamente concorrncia entre elas, o que, por sua vez, desen-
cadeou um processo de melhoria contnua que perdura at hoje. O aumento da
eficincia tornou-se uma condio imprescindvel para garantir a sobrevivncia.
Uma ilustrao clara disso a extino de centenas de fbricas de automveis
nos Estados Unidos: no incio do sculo XX, esse pas contava com cerca de 1.800
fabricantes diferentes.
Na dcada de 1920 surgiu o controle estatstico de produo. Nas fbricas que

produziam grande quantidade de itens tornou-se impossvel garantir a qualidade
individual de cada pea, ao contrrio do que se fazia (e ainda se faz) no trabalho
artesanal. Dessa forma foi preciso desenvolver mecanismos diferentes e a resposta
veio da estatstica. Um dos primeiros trabalhos associados ao assunto o livro pu-
blicado por Walter Shewhart em 1931, Economic Control of Quality of Manufactured
Product. Shewhart, dos Bell Laboratories, teria introduzido os diagramas de controle
(control charts ou Shewhart chart). A Figura 1.1 apresenta um exemplo desse tipo
de diagrama.
Captulo 1 O que qualidade? 19
fora de controle controlado reduo da

varincia
LS
LI
tempo
LS = Limite superior; M = Mdia; LI = Limite inferior.
Figura 1.1 Diagrama de Shewhart.
Para entender o diagrama, vamos supor que o problema tratado consista em

controlar o dimetro de parafusos. O diagrama apresenta trs linhas verticais que
definem o valor mdio e os limites superior e inferior mximos tolerados. Cada
ponto no diagrama representa o valor de uma amostra, isto , um parafuso reco-
lhido aleatoriamente na sada da fbrica. O grfico permite verificar se os processos
esto sendo bem controlados e se h tendncias de melhora ou piora da qualida-
de. Por exemplo, se a varincia nas medidas diminui, isso indica uma melhora da
fabricao, enquanto um aumento pode indicar um problema como desgaste das
mquinas. Outro exemplo de anlise possvel detectar desvios: se uma srie de
medidas est acima do valor mdio, isso pode indicar necessidade de calibragem.
Para um processo seguindo uma distribuio estatstica normal, pouco provvel
que vrias peas estejam todas com dimenses acima da mdia.
Na dcada de 1940 surgiram vrios organismos ligados qualidade; por exemplo,

a ASQC (American Society for Quality Control), a ABNT (Associao Brasileira de
Normas Tcnicas) e, ainda, a ISO (International Standardization Organization). A
Segunda Guerra Mundial tambm contribuiu com o processo, quando as tcnicas
de manufatura foram aprimoradas para fabricao de material blico.
Na dcada de 1940 o Japo destacou-se como um importante plo no assunto

e contribuiu com diversas novas ferramentas: o mtodo de Taguchi para projeto
experimental, a metodologia 5S ou, ainda, os diagramas de causa e efeito de Ishi-
kawa, tambm conhecidos como diagramas espinha de peixe.
A Figura 1.2 apresenta um diagrama de Ishikawa tpico. A tcnica utilizada para

identificar as causas de um problema e, de preferncia, deve ser utilizada durante
uma reunio em que todos os envolvidos discutam livremente, sem sanes. Um
problema especfico que afeta a empresa representado no eixo central do diagrama.
Em seguida, linhas diagonais so includas contendo elementos que fazem parte
No Captulo 3 so apresentadas algumas frmulas bsicas e teis em estatstica.

do cenrio como trabalhadores e mquinas. Tais elementos so chamados de

categorias. Depois, para cada categoria procura-se identificar fatores (causas) que
possam contribuir para aumentar ou reduzir o problema (efeitos). Dependendo do
tipo de indstria, sugere-se usar diferentes categorias:
para manufatura: mo-de-obra, mtodos, materiais e mquinas;
para servios e administrao: equipamentos, procedimentos, polticas e

pessoas.
Materiais Trabalhadores
Falta de luvas Distrao por cansao

Acidentes de trabalho
Treinamento Antiquadas
Mtodos Mquinas
Figura 1.2 Diagrama de Ishikawa.
No ps-guerra o impulso recebido pelas indstrias se manteve. Oscomputadores

digitais j estavam em uso nessa poca, embora estivessem restritos sobretudo a
meios militares e acadmicos. Alguns anos mais tarde, quando as mquinas se
tornaram mais acessveis e um maior nmero de pessoas as utilizava, a qualidade
dos softwares comeou a se mostrar um objetivo importante.
Nas dcadas de 1960 e 1970 ocorreram mudanas tecnolgicas importantes

que afetaram a construo dos computadores e, em conseqncia, a de software.
O perodo conhecido como crise de software e as repercusses so sentidas at
hoje [Pressman, 2002].
1.2 Uma crise de mais de trinta anos

Um dos fatores que exerce influncia negativa sobre a qualidade de um projeto a
complexidade, que est associada a uma caracterstica bastante simples: o tamanho
das especificaes.
Construir um prdio de 10 andares implica tratar um nmero de problemas muito

maior do que os existentes em uma simples residncia: a diferena entre as duas
construes, claro, est longe de ser resolvida com um nmero de tijolos maior. Em
programas de computador, o problema de complexidade e tamanho ainda mais
grave, em razo das interaes entre os diversos componentes do sistema.
Por volta da dcada de 1950 acreditava-se em uma relao chamada lei de Grosch
[Pick et al., 1986]: o desempenho de um computador seria proporcional ao quadra-
do de seu preo. Nessa poca e de acordo com essa lei uma idia interessante
era reunir um grupo de usurios para adquirir um computador de grande porte
(mainframe). Era comum tambm alugar uma mquina diretamente do fabricante.
Problemas maiores significavam apenas a necessidade de mquinas maiores.
E como eram as mquinas grandes nessa poca?
At a dcada de 1970 ainda eram utilizadas as memrias de ncleo (core me-

mory): caras, lentas e consumidoras de muita energia. A memria semicondutora
s foi criada em 1966 (por Robert H. Dennard, na IBM) e fabricada, pela primeira
vez, pela Intel, em 1970. Logo aps, em 1971, surgiu o primeiro microprocessador em
silcio: o Intel 4004, uma CPU de 4 bits utilizando menos de 3 mil transstores, mas
com tanto poder de processamento quanto o ENIAC, que possua 18 mil vlvulas.
Assim, um computador grande, em 1960, era uma mquina ocupando uma sala
de dezenas de metros quadrados!
A mudana tecnolgica teve um efeito dramtico na produo de software. Num

breve perodo de tempo, os recursos de hardware aumentaram muito e permitiram
que produtos mais complexos fossem criados. Traando um paralelo, seria como se
os engenheiros civis, depois de anos construindo apenas casas ou pequenos prdios
de 2 ou 3 andares, se vissem repentinamente com a tarefa de construir grandes
arranha-cus [Dijkstra, 1972]:
A maior causa da crise do software que as mquinas tornaram-

se vrias ordens de magnitude mais potentes! Em termos diretos,
enquanto no havia mquinas, programar no era um problema;
quando tivemos computadores fracos, isso se tornou um problema
pequeno e agora que temos computadores gigantescos, programar
tornou-se um problema gigantesco.
Mas a situao ainda era agravada por outro motivo: os primeiros programadores
no possuam ferramentas como dispomos hoje. A tarefa que enfrentavam poderia
ser comparada, em certos aspectos, a erguer prdios empilhando mais e mais tijolos.
Embora a noo de ciclo de vida j houvesse sido esboada [Naur e Randell, 1968],
no havia tcnicas consagradas de trabalho. No havia escolas ou sequer a profisso
de programador; as pessoas aprendiam e exerciam essa atividade de maneira emp-
rica [Dijkstra, 1972]: "... em 1957, casei-me e os ritos holandeses requerem declarar a
profisso; declarei ser um programador. Mas as autoridades municipais de Amsterd
no aceitaram, com base em que no havia tal profisso".
Provavelmente a primeira vez em que se utilizou o termo Engenharia de

Software foi em uma conferncia com esse nome, realizada em 1968, na Alemanha.
A conferncia foi realizada por uma entidade que, a rigor, no possua nenhuma liga-
o com a rea: o Comit de Cincia da NATO (North Atlantic Treaty Organisation
Organizao do Tratado do Atlntico Norte). Curiosamente j havia instituies
relacionadas com informtica: a primeira delas foi a ACM (Association for Compu-
ting Machinery), criada em 1947 e que edita uma revista cientfica, Communications
of the ACM, desde 1957.
Hoje, mais de trinta anos depois, quais so os problemas enfrentados na cons-

truo e utilizao de software? Ao lermos o relatrio da conferncia da NATO de
1968 e outros documentos produzidos na dcada de 1970, fazemos uma descoberta
assustadora: os problemas so os mesmos que encontramos atualmente.
Faamos uma pequena lista:
cronogramas no observados;
projetos com tantas dificuldades que so abandonados;
mdulos que no operam corretamente quando combinados;
programas que no fazem exatamente o que era esperado;
programas to difceis de usar que so descartados;
programas que simplesmente param de funcionar.
Os erros parecem estar por toda a parte, como uma epidemia que no conse-
guimos controlar depois de dcadas de trabalho e pesquisas. O ltimo exemplo e
certamente mais conhecido o bug do milnio, quando foi predito o apocalipse da
sociedade da informao: avies cairiam, contas bancrias seriam zeradas, equipa-
mentos militares perderiam o controle e bombas seriam disparadas. Embora seja
verdade que poucos problemas de fato aconteceram, tambm verdade que o erro
realmente existia em muitos sistemas. O assunto ser provavelmente lembrado no
ano de 2100 como uma boa piada. Hoje em dia, contudo, no h motivos para rir, pois
a pergunta permanece: no somos capazes de produzir software de qualidade? Essa
questo no simples de ser respondida, mas podemos aventar algumas razes.
O aspecto no repetitivo do desenvolvimento de software torna essa atividade

difcil e, sobretudo, em boa medida imprevisvel. Apenas uma pequena parcela
da construo de software corresponde a atividades que poderamos chamar de
"montagem. Quando se constri uma rodovia ou, por exemplo, uma ponte, os
processos de clculo de estruturas, correo de inclinaes, preparao do terreno
e pavimentao so conhecidos. Algumas vezes ocorrem surpresas, como descobrir
que o solo de uma seo da estrada no correspondia ao que era imaginado; mas
em geral, as diversas etapas so cumpridas sempre da mesma maneira. durante
o projeto dessa ponte que h mais questes em aberto e solues de engenharia
devem ser desenvolvidas. Assim, por exemplo, antes do projeto no se conhece o
traado que ser mais confortvel, seguro e econmico para os futuros usurios. O
problema comentado na Figura 1.3.
Projeto e realizao de uma ponte
Qualidade do ao e
concreto apropriada?
Especificaes Incertezas existentes
obtidas por clculos Dimensionamento dos nos ensaios de material
e simulaes pilares correto? Desconhecido
Incertezas no
clculo estrutural
Conhecido
Figura 1.3 Zonas de sombra em um projeto de engenharia.
Uma vez terminado o projeto, contudo, existem respostas para a maior parte das
questes que dizem respeito realizao. Os carros que iro trafegar no muda-
ro de largura nem de comprimento repentinamente; a quantidade de veculos e,
portanto, o peso mximo a ser suportado so calculados com boa preciso. Fatores
como vento podem ser superdimensionados para garantir margens de segurana.
Dificilmente um pilar dever ser deslocado cinco centmetros para a direita depois
que a construo j foi iniciada!
Comparativamente, quando estamos tratando de software essa zona de sombra

que envolve fatores desconhecidos bem mais abrangente. Quem j trabalhou
no desenvolvimento de software sabe como comum resolver problemas como
encurtar ou alongar uma ponte, apenas alguns centmetros alguns dias antes de
sua inaugurao. A Figura 1.4 ilustra alguns aspectos.
Projeto e implementao de software
Requisitos conhecidos e Esforo de desenvol-

garantidos contra mudanas? vimento necessrio?
Raramente Estimativas no
requisitos combinam bem
no mudam Algoritmos preexistentes Qualidade do produto com criatividade
aplicveis? final em funo dos requisitos?
No existem ou Desconhecido
so muitas vezes Gap semntico
desconhecidos Conhecido
Figura 1.4 Zonas de sombra em projeto de software.

As dificuldades em informtica comeam durante as etapas iniciais de um

projeto: delimitar o escopo de um sistema est longe de ser uma tarefa trivial. A
volatilidade dos requisitos (Captulo 9) um das maiores causas de insucesso de
projetos de software. Uma mudana nas necessidades declaradas por um usurio
pode repercutir em vrios elementos da estrutura do programa. Mais tarde, embora
a soluo tenha sido projetada, ainda no se conhecem de antemo e em detalhes
os algoritmos que efetivamente resolvem o problema. Em conseqncia, comumente
se considera que bastante difcil prever como ser o programa acabado apesar
de a estrutura toda j ter sido desenhada.
No bastassem as dificuldades inerentes a esse carter mutvel ou voltil do

software, as pessoas que trabalham com ele contribuem bastante para piorar os
problemas. O trabalho intelectual que necessrio construo de programas
pode, ao mesmo tempo, influenciar na existncia de obstculos ao sucesso de um
projeto. Um exemplo de dificuldade tratar os aspectos no tcnicos que vm
tona quando se realizam revises de projetos [Yourdon, 1989]:
Mas voc no pode remover o elemento humano de uma reviso. O

autor, cujo trabalho de arte est sendo revisto, possui sentimentos
e emoes humanas. E os revisores tambm possuem seus prprios
sentimentos.
Conciliar a necessidade de disciplina fundamental para garantir uma certa

previsibilidade de resultados com o carter relativamente aleatrio da criao de
solues talvez seja um dos maiores desafios. As metodologias tm sido desenvolvi-
das, testadas e adaptadas h dcadas, buscando reduzir a um mnimo a necessidade
de inventar solues. Em grande parte, as metodologias tm carter pedaggico:
mostram o que preciso fazer para conduzir um projeto, quais procedimentos adotar
e como realiz-los, como trabalhar em equipes de maneira a evitar a veiculao de
informaes dbias etc.
Alm de metodologias, outro aspecto que contribui para combater o problema

o desenvolvimento de tecnologias e ferramentas. Existem vrias tarefas que podem
ser automatizadas, diminuindo a carga de trabalho das pessoas e, ao mesmo tem-
po, garantindo uniformidade: se uma ferramenta que executa a tarefa, h menos
chances de o resultado ser diferente porque diversas pessoas a utilizaram.
Mas a discusso sobre problemas de software no estar completa sem abor-

dar o assunto que o foco deste livro: a qualidade. Os mtodos e ferramentas de
engenharia de software servem, entre outras coisas, ao propsito de garantir, ou
pelo menos facilitar, a obteno do objetivo de ter qualidade nos programas. E
qualidade um conceito que, do ponto de vista da engenharia, bastante complexo.
Sem definir precisamente qual esse objetivo a atingir, o uso de todo arsenal de
engenharia de software de que dispomos pode se revelar menos eficaz. Este um
dos objetivos principais deste livro: auxiliar a definir o alvo a ser atingido e discutir
como aplicar a engenharia de software para aproximar-se o mximo possvel do
resultado desejado.
1.3 Qualidade e requisitos

Uma das primeiras questes a responder quando o assunto qualidade como
julg-la. Por exemplo: se estamos diante de produtos alternativos, como escolher
o melhor? Esse problema de julgamento acontece com qualquer pessoa cotidiana-
mente, quando se consomem itens como roupas, msica, comida ou filmes. Mas
curiosamente, apesar da freqncia com que avaliamos os objetos nossa volta,
muito difcil obter consenso a respeito da qualidade de um produto. Isso se traduz,
por exemplo, no fato de existir uma profuso de marcas de eletrodomsticos e haver
clientes felizes adquirindo aparelhos de marcas diferentes.
Uma escolha torna-se mais clara quando se estabelecem critrios que sirvam para
julgar um produto. Em algumas situaes, tais critrios so relativamente simples
de identificar e estabelecer. Por exemplo: em domnios como engenharia eltrica ou
mecnica, as informaes necessrias so obtidas em funo da finalidade a que se
destina um determinado produto. Para dispositivos simples, como um fusvel ou
uma engrenagem, no difcil enumerar algumas caractersticas que provavelmente
so relevantes: ponto de fuso, condutncia trmica, resistncia a cisalhamento ou
dimenses fsicas. Passando para objetos mais complexos, como um transistor ou
um amortecedor, a complexidade e quantidade de requisitos tendem a aumentar.
Finalmente, quando se consideram sistemas compostos de subsistemas, natural
que a especificao de caractersticas seja realizada tambm de maneira hierrquica.
Assim, a fonte de alimentao e o disco rgido de um computador possuem cada
um sua prpria srie de especificaes tcnicas, o mesmo ocorrendo com o motor
ou carburador de um carro.
Contudo, essas especificaes garantem a qualidade?
O problema de definir e avaliar qualidade ainda no est completamente re-

solvido pelos requisitos. Todavia, um grande passo da soluo consiste em ligar os
dois conceitos:
Isto nos leva famosa definio de Crosby [1992]: "A qualidade conformidade
aos requisitos". Essa definio interessante, pois deixa explcito o fato de que
preciso um ponto de referncia para julgar um produto. Traz embutida a idia de
como efetuar esse julgamento e, por fim, mostra como o processo todo pode ser
documentado, analisado e os resultados transmitidos a outras pessoas.
H, contudo, trs fatos que perturbam essa definio, os quais preciso conhecer
para poder aplic-la corretamente.
Em primeiro lugar, a definio nos deixa com a tarefa de definir o que confor-
midade. Em alguns casos, isso se traduz em uma deciso booleana: uma lmpada de
60W no uma lmpada de 100W. Mas, em geral, h poucos requisitos que possam
ser tratados dessa maneira. O que se faz, ento, especificar margens de preciso:
uma lmpada que consuma 59,9W melhor que outra consumindo 60,1W. Esse
exemplo nos leva naturalmente a considerar que possam existir intensidades ou
graus de qualidade. Podemos escrever isso assim:
qualidade = f (observado, especificado)
= observado especificado
ou seja, a qualidade de um produto dada pela distncia entre as caractersticas

observadas e as caractersticas que foram especificadas para sua construo.
A frmula mostra que o problema ainda no est resolvido: precisamos definir

uma medida de distncia (indicada pelo smbolo || na expresso). evidente que
quanto mais longe estivermos das especificaes, pior ser o produto; entretanto,
isto no indica o que fazer quando comparamos dois produtos diferentes em rela-
o a uma longa lista de caractersticas. Almpada que consome 60,1W talvez seja
mais brilhante que a de 59,9W; alm disso, possvel que aquea menos, sendo
mais eficiente.
O segundo ponto diz respeito realizao da observao do produto. Como

sabemos que a lmpada consome exatamente 60,1W? No seriam talvez 60,2W?
Existem vrias fontes de erro que podem corromper os dados utilizados para carac-
terizar um produto. Um exemplo disso, em informtica, so os efeitos de memria
cache no desempenho medido de computadores (benchmarks). Oerro de observao
pode ser representado assim:
qualidade = observado especificado + E
onde representa um erro de medio que no podemos controlar.

Por fim, o terceiro ponto a considerar o papel de diferentes clientes em um

mesmo projeto. Uma tima exposio do assunto feita por Weinberg [1994]: os
requisitos foram definidos por algum, logo a qualidade depende das escolhas que
algum efetuou. Segundo [Sommerville, 2003]:
Diferentes stakeholders tm em mente diferentes requisitos e podem

express-los de maneiras distintas. Os engenheiros de requisitos
precisam descobrir todas as possveis fontes de requisitos e encontrar
pontos comuns e os conflitos.
Isto , com freqncia, um problema no muito simples de resolver. Projetos gran-

des, envolvendo muitas funes e pessoas diferentes (diversos tipos de operadores,
usurios das informaes, gerentes etc. coletivamente chamados de stakeholders),
provavelmente tm mais chances de conter requisitos conflitantes. Isso ocorre por
falta de consenso em relao a como certas tarefas devem ser feitas, ou mesmo para
decidir quais tarefas so mais importantes implementar ou no. Em cenrios desse
tipo, pode existir uma deficincia de dilogo que antecede o projeto do software.
Os desenvolvedores do produto podem se encontrar face a um duplo problema:
resolver ou, pelo menos, minimizar o problema organizacional do cliente que con-
trata o desenvolvimento do software e, depois, obter uma especificao coerente
que atenda aos interessados.
1.4 Papel da subjetividade

A qualidade de um produto tem um propsito: satisfazer o cliente. Esse objetivo
implica tratar um domnio, em geral, bastante nebuloso. Para compreender o motivo,
considere novamente o caso de uma pessoa que deve adquirir um produto comum
no mercado. Ningum compra uma camisa pensando nas propriedades mecnicas
do tecido com o qual ela foi fabricada: Que bela camisa! Pode resistir a 10 kg de
trao!. Em vez disso, so fatores muito difceis de medir que, em geral, tero maior
peso na deciso.
Tomemos outro exemplo: a especificao de um automvel de qualidade. Essa
especificao consistiria em uma lista de itens que se deseja que o veculo tenha. Por
exemplo: direo hidrulica, teto solar, freios ABS, espao para bagagens, conforto e
potncia. A maioria das pessoas concordaria, vendo essa lista, que o veculo sendo
especificado certamente um produto de bastante qualidade. Entretanto, para o
engenheiro preocupado com a construo de um produto, essa viso superficial:
no se sabe qual a potncia do carro ou o que caracteriza o conforto desejado.
Alm disso, em vrios aspectos a especificao incompleta. Dois exemplos podem
demonstrar a razo disso.
Primeiro, considere um comprador que no tem recursos financeiros para ad-

quirir um carro com essa lista de itens. Esse comprador ir procurar um veculo,
realizar uma avaliao de possibilidades e, para um dado oramento, voltar para
casa com o carro de melhor qualidade que encontrou. A qualidade no pode ser
uma entidade abstrata, mas um objetivo concreto com o qual o fabricante, comer-
ciantes e compradores devem tratar. Por causa disso, o custo um fator integrante
de um modelo de qualidade.
Segundo ponto, considere que algum deseja comprar outro veculo; mas o
problema a ser resolvido deslocar-se vez por outra dentro da cidade e, nos finais
de semana, transportar um saco de rao de 200 kg para os ces que cuidam do
stio da famlia. Nesse caso evidente que teto solar ou mesmo conforto tenham
menor importncia. Como foi ressaltado antes, os requisitos foram especificados
por uma pessoa: logo, preciso saber claramente como ela pensa. Mais do que
isso, preciso saber como cada pessoa envolvida no projeto cliente, projetistas,
gerentes influi sobre os requisitos para conhecer com preciso o objetivo que se
pretende alcanar.
1.5 Qualidade e bugs I: insetos inofensivos

Como em qualquer outra rea de conhecimento, em computao existem alguns
equvocos bastante comuns no uso de terminologia. Muitos deles so inofensivos,
como no saber distinguir entre programao usando tipos abstratos de dados e
programao orientada a objetos. Outros equvocos so, talvez, um pouco menos
incuos, como afirmar que o uso de saltos incondicionais incompatvel com
programao estruturada [Knuth, 1974]. A relao entre bugs e qualidade, s vezes
tambm causa certas confuses.
Geralmente o simples fato de pronunciar a palavra bug equivale a acionar um
alarme e fazer uma equipe de programadores estressados entrar em pnico. A dis-
cusso sobre o assunto se resume tipicamente equao inexata
qualidade = bug
isto , qualidade de software e bugs so coisas opostas e incompatveis. Assumir

essa idia cegamente faz tanto sentido quanto dizer que um programa que tem uma
instruo goto no um programa estruturado.
A maioria das pessoas, sobretudo estudantes de computao, fica em geral cho-
cada com a idia de que um programa de computador possa ter erros e continuar
sendo um produto de qualidade. Segundo se pensa geralmente, um bug (inseto em
ingls veja a Figura 1.5) algo a ser exorcisado a todo custo, pois no possvel
dizer que um programa errado um programa bom.
Como poderia ser diferente?
Figura 1.5 Foto de um inseto encontrado em um computador em 1945

(Copyright: U.S. Naval Historical Center Photograph).
Vamos considerar essa questo luz de alguns exemplos.
O dilema gerencial: este caso narrado por Weinberg [1994]: a histria

de um programa de edio de texto. O programa tinha falhas que apareciam
apenas sob certas condies, como trabalhar com textos muito longos. Pro-
curado por algum insatisfeito, o fabricante do programa explicou que estava
ciente da falha, mas que esta era rara: menos de 1% dos clientes tiveram
o problema. Alterar o cdigo para corrigir o defeito implicaria mudanas
profundas e poderia introduzir novos problemas um risco muito grande.
Assim, em nome dos 99% de clientes satisfeitos, o gerente tinha razo em
no corrigir o programa.
A importncia relativa I: muitos programas de computador possuem

defeitos conhecidos e considerados pelos usurios como de menor impor-
tncia. Como exemplo, vrios jogos possuem imperfeies no tratamento
de coliso entre slidos e, assim, objetos atravessam paredes, o que no
impede que os usurios continuem se divertindo e mesmo recomendando
tais produtos. Programas mais srios tambm apresentam erros; embora
seja um defeito raro, o Matlab R12, por vezes, trava. Isso no impede que
milhares de cientistas usem o Matlab para realizar clculos algo que o
programa faz extremamente bem.
A importncia relativa II: o sistema de tipografia TEX lendrio pela qua-

lidade de resultado impresso, pelo preo ( gratuito) e pelo fato de que,
depois de anos de uso, poucos erros terem sido encontrados. Entretanto, seu
uso requer conhecimento especializado, exigindo certo tempo de adaptao
mesmo para um usurio que seja programador. A ferramenta continua
sendo a escolha preferida para escrita de livros cientficos, artigos e teses,
mas no adequada para enviar rapidamente um oramento a um cliente,
contendo algumas tabelas com diversos formatos e alguns grficos: nesses
casos ser prefervel usar outro programa.
A qualidade de um software, como se pode ver, depende de se decidir o que

significa qualidade! No um assunto que possa ser tratado com dogmas: No
cometers erros de programao. Em vez disso, preciso adotar uma perspectiva
tcnica e considerar diversos fatores que afetam a construo do produto e que
influenciem no julgamento dos usurios:
tamanho e complexidade do software sendo construdo;

nmero de pessoas envolvidas no projeto;
ferramentas utilizadas;
custos associados existncia de erros;
custos associados deteco e remoo de erros.
Um estudante de computao, cercado de provas e de matria a estudar no final

de um perodo letivo, normalmente est pronto para aceitar uma nota 7 em troca de
alguns bugs. Um programador de uma empresa pressionado por cronogramas e chefes
irritados, em rarssimos casos consegue lutar contra o ambiente e dizer: Vou atrasar
a entrega para realizar mais testes. Finalmente, uma equipe militar responsvel pelo
programa de controle de um mssil, provavelmente, no iniciaria um projeto sem haver
includo no estudo de viabilidade condies estritas de oramento, realizao de testes
e revises, que, certamente, no existem nos dois casos anteriores.
H um conceito chamado de zero-defeitos; trata-se com certeza, de um conceito

interessante e um ideal a ser buscado. Mas, de um ponto de vista de administrao
e de engenharia, mais realstico se perguntar at que ponto pode-se evitar os erros
em um dado projeto e, o que decisivo, qual o custo e quais os lucros esperados.
1.6 Um erro um defeito, uma falha ou bug?

Qual a melhor palavra para explicar que um programa travou ou no funciona
corretamente?
H termos relacionados com erros de programao que, algumas vezes, provocam

um pouco de confuso. Embora evoquem idias parecidas, defeito, erro e falha no
so sinnimos entre si e so usadas para designar conceitos distintos.
1.6.1 Defeito
Defeito uma imperfeio de um produto. O defeito faz parte do produto e, em
geral, refere-se a algo que est implementado no cdigo de maneira incorreta.
Considere, por exemplo, o cdigo a seguir:

a = input ();
c = b/a;
d = a ? b/a : 0;
A expresso que calcula o valor para c pode apresentar um problema: se a varivel

a contiver um valor nulo, a operao de diviso por zero provocar algo anormal
na execuo do programa. A linha seguinte, onde uma atribuio feita varivel
d, no apresenta esse problema.
O comportamento anormal do programa provavelmente um crash, isto , in-

terrupo ou aborto da execuo provocado pela diviso b/a. Aprimeira idia,
ento, dizer que essa linha de cdigo defeituosa. Existe, entretanto, uma outra
hiptese: o defeito pode estar na rotina input(): imagine que a especificao dessa
rotina estabelea que ela no deve jamais retornar um valor nulo. Nesse caso, o erro
foi cometido pelo programador responsvel por essa rotina. Esta segunda hiptese
bastante razovel, pois para a maioria dos programas irrealstico preceder cada
operao de diviso com um teste if.
Mas a palavra defeito no significa apenas um problema que faz um progra-

ma no funcionar. Um programa defeituoso, segundo o dicionrio Houaiss, um
programa que no funciona como deve.
Realizar testes e gastar tempo com revises apenas procurando possibilidades

de crash no suficiente. claro que um programa que sofre muitas paralisaes
deve ser corrigido, mas existem outros tipos de erros a serem tratados.
Considere o exemplo que aparece na Figura 1.6:

Figura 1.6 Falha provocada por impreciso de clculo.
O cdigo, em C++, faz o seguinte:
atribui 10.000.000.000 varivel a;
soma 0.1 a esse valor e o armazena em b;
subtrai 10.000.000.000 desse valor.
Qual o resultado desse clculo? Obviamente, 0.1. Mas, por que, ento, o programa
apresenta a mensagem na tela?
Este trecho de cdigo um exemplo bem conhecido dos engenheiros que tra-
balham com clculo numrico. Embora o programa esteja aparentemente correto,
h aqui um problema semntico: as variveis possuem uma preciso limitada. Isso
significa que certos clculos tero resultados incorretos, no porque o programador
escreveu algo errado, mas porque no h casas decimais suficientes para representar
os valores. O defeito, neste caso, pode ser resolvido simplesmente trocando os tipos
das variveis por uma representao mais adequada por exemplo, um double. Em
programas extensos, a situao bem mais complexa, pois existe o fenmeno de
propagao de erros de um clculo a outro.
Podem existir inmeros outros tipos de defeitos que no resultam no aborto do

programa. Tais erros so menos aparentes, mas podem ser igualmente graves.
1.6.2 Falha
Falha o resultado errado provocado por um defeito ou condio inesperada. No
primeiro exemplo de cdigo defeituoso uma diviso por zero possvel que o
programa funcione durante longos anos, sem que jamais ocorra uma falha: tudo
depender dos valores retornados pela rotina input (). Um exemplo consta na
Figura 1.7.
Figura 1.7 Falha provocada por uma diviso por zero.
Os defeitos podem existir, mas nem sempre ser visveis. Falhas tambm podem
ocorrer por fatores externos ao programa, como corrupo de bases de dados ou
invases de memria por outros programas.
Como foi dito antes, as falhas que chamam mais a ateno so certamente aque-
las em que o programa aborta. Contudo, toda falha potencial pode ser perigosa,
mesmo se o programa no for paralisado.
1.6.3 Isolar um defeito

Isolar um defeito consiste em determinar sob quais condies ocorre. Oobjetivo
encontrar as causas dentro de um programa que esto ocasionando falhas e isso
implica descobrir em qual linha de cdigo ocorre uma falha como um crash (ou
seja, o programa abortado).
Isolar um defeito pode ser bastante difcil: apenas olhando janelas como as
que aparecem na Figura 1.6, seria, em princpio, impossvel determinar onde, em
um programa extenso, est localizada a linha defeituosa que provocou a diviso
por zero. Alm disso, preciso que se consiga repetir a falha sistematicamente. Se
impossvel repeti-la, improvvel que o defeito possa ser encontrado.
Algumas falhas so bastante difceis de reproduzir. preciso encontrar precisamente

a combinao de fatores como entradas de dados e comandos executados na interface
que fazem que ela se manifeste. A tarefa tambm pode ser cara: em um software no
qual um dos autores trabalhou, era preciso que o sistema (um simulador) funcionasse
durante algumas dezenas de minutos antes que ocorresse o problema!
Muitos programadores (e, sobretudo, gerentes) desconhecem a existncia de

tcnicas e ferramentas que permitem facilitar a tarefa de depurao de cdigo.
Falaremos disso nos Captulos 15 e 16.
1.6.4 Estabilizar um programa

Estabilizar um programa o termo, em geral, utilizado para referir-se a correes
que resultam na diminuio na freqncia de falhas. Um programa estvel apresenta
poucas falhas um indicativo de que deve possuir poucos defeitos. De maneira
bastante geral, a estabilidade est ligada idade de um programa. Mais tempo de uso
representa mais possibilidades de encontrar e corrigir problemas de execuo.
1.7 Qualidade e bugs II: catstrofes

Os defeitos de software que levam ao aborto do programa so certamente bastan-
te inconvenientes. Mas, como foi dito antes, no constituem o nico aspecto que
determina a qualidade de um produto: h outros fatores, como o preo, que no
devem ser desprezados quando se busca determinar a qualidade.
A gravidade de uma falha de software relativa. Existem falhas com as quais
usurios podem conviver, a tal ponto que o sucesso de aplicao de um produto
no seja afetado; em outros casos, a falha do programa representa um completo
fracasso comercial. Finalmente, h programas de computador responsveis pelo
controle de equipamentos valiosos ou que podem colocar em risco a segurana
fsica de pessoas.
Erros de software j foram responsveis por prejuzos milionrios e mesmo a
perda de vidas humanas. A importncia de garantir a qualidade evidente luz desta
citao [Pressman, 2002]: "O software de computadores... est embutido em sistemas
de todas as naturezas: de transportes, mdicos, de telecomunicaes, militares, de
processos industriais, de produtos de escritrio,... a lista quase sem-fim".
A anlise de falhas que tenham sido identificadas e documentadas abre a possi-
bilidade para que sejam estudadas tcnicas para evitar erros no futuro.
Nas prximas sees apresentaremos alguns erros de software cujas conseqncias
foram dramticas.
1.7.1 Ariane 501

Em 4 de junho de 1996, foi lanado o primeiro foguete Ariane 5. Decorridos 40
segundos da seqncia de lanamento e a uma altitude de 3.700 metros, o foguete
desviou-se de sua trajetria e se autodestruiu com uma exploso. Ocusto desse de-
sastre foi avaliado em mais de 300 milhes de dlares, quantia suficiente para pagar
um salrio de 2,5 mil dlares a cem programadores que trabalhassem durante um
sculo.
A trajetria do foguete era medida por um sistema de referncia inercial (SRI),

cujos dados alimentavam um computador. Os equipamentos eram redundantes:
havia duas unidades SRI exatamente idnticas. Caso a principal falhasse (SRI-2), o
computador passava imediatamente a utilizar a de reserva (SRI-1). Havia tambm
um segundo computador redundante. O relatrio que analisou o acidente descreveu
os eventos em ordem cronolgica inversa, como segue.
O foguete comeou a desintegrar-se a 39 segundos, em razo a uma
carga aerodinmica excessiva: a presso do ar contra o veculo estava
muito elevada. O motivo foi o ngulo de ataque muito pronunciado,
ou seja, em vez de cortar o ar na vertical, o foguete estava em um
ngulo de 20 graus.
O ngulo exagerado de ataque foi causado por um comando de
direcionamento dos motores. Esse comando foi enviado pelo
computador com base nos dados fornecidos pelo SRI-2. Entre esses
dados havia um padro de bits significando um cdigo de erro,
incorretamente interpretado como informao de vo.
O SRI-2 no forneceu dados corretos, mas um cdigo de erro, em
virtude de uma exceo de software. O sistema de reserva (SRI-1) no
pde ser utilizado porque ele prprio j havia reportado a mesma falha,
72 milissegundos antes.
Mas, o que causou, de fato, o problema?
Uma exceo uma condio inesperada em um programa, que tratada geral-

mente por uma sub-rotina-padro. Nos exemplos de cdigo apresentados na Seo 1.6,
a diviso por zero em um processador Intel causa uma exceo que , em geral, tratada
pelo sistema operacional. Tipicamente, o programa simplesmente abortado.
No caso do Ariane 5, a exceo tambm foi proveniente de um clculo: um n-

mero em ponto flutuante representado com 64 bits foi convertido para um inteiro
com sinal de 16 bits. O nmero era demasiado grande para ser representado com 16
bits e isso causou uma falha. Existiam outros pontos do mesmo cdigo com conver-
ses semelhantes, mas que eram protegidos por testes. O trecho do software havia
sido copiado do Ariane 4, onde funcionava corretamente; no Ariane 5, o clculo se
tornava defeituoso em razo do comportamento diferente do foguete. Pior do que
isso, tal clculo sequer era necessrio.
Embora o erro no cdigo fosse muito pequeno (podendo ser tratado por um
simples comando if), fcil perceber que do ponto de vista de projeto o defeito era
bem mais complexo. Este exemplo ilustra diversos aspectos que cercam a qualidade
de software:
Ariane 5 Flight 501 Failure Report by the Inquiry Board, J. L. Lions. Disponvel na
Internet.
o caractere determinante dos requisitos sobre os resultados;

a dificuldade de garantir que requisitos sejam consistentes em projetos
complexos;
a lei de Dijkstra, segundo a qual testes no garantem a ausncia de erros;
a dificuldade de verificar e validar programas.
1.7.2 Therac-25
O Therac-25 era uma mquina utilizada em terapia radiolgica. Diferente de suas
verses anteriores, era totalmente controlado por um computador, um PDP-11.
Enquanto as verses anteriores possuam travas mecnicas para impedir erros
de operao, no Therac-25 toda segurana ficou a cargo do software. Infelizmente,
havia diversos erros no projeto do equipamento, que levaram morte de pacientes
[Leverson, 1995]. As mensagens de erro no eram claras: algumas se limitavam
palavra malfunction, seguida de um nmero entre 1 e 64. A ocorrncia de falhas
era bastante comum; no obstante, os operadores teriam recebido a informao
de que havia diversos mecanismos de segurana e que, por isso, no era preciso se
preocupar.
Em 26 de julho de 1985, na Ontario Cancer Foundation, em Ontrio, Canad, um
operador acionou a mquina e decorridos cinco segundos ela parou de funcionar. O
display mostrava a mensagem: htilt error, erro de posicionamento horizontal. Havia
indicaes de no dose, ou seja, nenhuma radiao teria sido emitida; e treatment
pause, a mquina estava em simples pausa aguardando para continuar a operao.
Como se tratava de mensagens comuns, o operador simplesmente ativou outra
vez o Therac-25. A mquina desligou-se novamente com as mesmas mensagens.
Ooperador insistiu um total de cinco vezes, quando, ento, o Therac-25 entrou em
um modo de suspenso que obrigava uma reinicializao do computador. Um tc-
nico do hospital foi chamado e no verificou nada de anormal com o equipamento;
no seria a primeira vez que isso teria acontecido.
A paciente faleceu em 3 de novembro. Uma autpsia revelou que a superexposio
radiao causou tantos danos que, se ela tivesse sobrevivido, seria preciso receber
uma prtese para a cabea do fmur praticamente destruda pela radiao.
Depois da ocorrncia de outros acidentes em diversos hospitais, o mdico Frank
Borger, da Universidade de Chicago, decidiu investigar por seus prprios meios
o que estava acontecendo. Ele havia percebido que quando um grupo de novos
estudantes iniciava o uso de um Therac-20 (o modelo anterior), cerca de trs vezes
por semana havia fusveis queimados no equipamento. Depois de algum tempo, os
erros desapareciam misteriosamente, at que um novo grupo comeasse a usar a

mquina pela primeira vez.
O mdico orientou um novo grupo de alunos a testar vrios tipos de erros dife-
rentes e a serem criativos ao introduzirem parmetros na mquina. Por meio dessa
experimentao, ele descobriu que certas seqncias de comandos e de edio de
parmetros resultavam em fusveis queimados e outras falhas na operao.
O que Borger estava fazendo era uma excelente demonstrao de como isolar um
defeito de software. Curiosamente, aparentemente ningum na empresa responsvel,
a AECL (Atomic Energy of Canada Limited) pensou em fazer o mesmo.
Os acidentes continuaram acontecendo, revelando possveis falhas mecnicas,

erros de cdigo e no projeto como um todo. O software continha procedimentos
concorrentes em que condies de corrida (race conditions) podiam ocorrer. Men-
sagens de erro que eram empregadas apenas pelos desenvolvedores do software
foram vistas no display por operadores do Therac-25. Finalmente, as declaraes
de confiabilidade feitas pela AECL careciam de embasamento; a cada incidente, a
empresa publicava relatrios de melhoria. Em um desses relatrios, afirmava-se que
a possibilidade de erros havia sido reduzida de cinco casas decimais um resul-
tado, a rigor, muito improvvel. Seis pacientes foram vtimas dos erros de projeto
do Therac-25.
1.8 Qualidade e o SWEBOK

As bases tericas dos computadores modernos remontam a 1936, com o trabalho
de Alan Turing: isso significa somente 64 anos antes do bug do milnio. O compu-
tador ABC comeou a ser construdo em 1937, na Iowa State University, enquanto
o ENIAC foi concludo em 1946. Comparativamente, a mecnica newtoniana data
de 1664, uma diferena de trs sculos. O tempo permite no apenas que novos
conhecimentos sejam produzidos, mas tambm que tais conhecimentos sejam
verificados, corrigidos e melhorados. Kuhn [1996] mencionou assim, o papel que
o tempo exerce na evoluo histrica da cincia:
Se a cincia o conjunto de fatos, teorias e mtodos... o desenvolvimento

cientfico torna-se o processo fragmentrio pelo qual esses elementos foram
reunidos, separadamente ou em combinao, ao fundo comum em contnuo
crescimento que constitui a tcnica e o conhecimento cientficos.
Quando h possibilidade de que dois processos possam acessar uma regio crtica em
funo da seqncia em que as instrues so executadas, diz-se que h uma condio
de corrida.
Nas ltimas dcadas, tornou-se claro o desdobramento da computao em uma

extensa lista de subreas de estudo. Alm de um crescimento explosivo da tecnologia,
ocorreu tambm uma evoluo importante dos alicerces, isto , da cincia. A quantida-
de de informao aumentou de tal modo que a especializao profissional tornou-se
comum, seno mesmo necessria se for desejado um nvel de excelncia.
Uma das reas de computao a Engenharia de Software passou por um

estudo de uma comisso internacional de especialistas, visando a uma definio
das fronteiras que a delimitam. Esse estudo foi conduzido no mbito da IEEE e
chama-se SWEBOK (Software Engineering Body Of Knowledge, ou Corpo de
Conhecimento de Engenharia de Software) [SWEBOK, 2004].
A Engenharia de Software dividida no SWEBOK em um total de onze reas de

conhecimento (KA: Knowledge Area): requisitos, gerncia de engenharia, projeto,
mtodos e ferramentas de engenharia, construo, processo de engenharia, testes,
qualidade, manuteno, disciplinas relacionadas e gerncia de configurao.
Como acontece em todas as cincias, cada uma dessas divises trabalha em

conjunto com as demais e envolve a aplicao (e desenvolvimento) de conhecimen-
tos mesmo em outros domnios. A teoria da computao, por exemplo, no existe
como uma entidade separada da matemtica. Asclassificaes so teis para que
possamos organizar o conhecimento e direcionar esforos. Pessoas diversas podem
adotar divises um pouco diferentes.
Em relao qualidade, o SWEBOK fez uma distino entre tcnicas estticas e
dinmicas. As primeiras aparecem sob a rea de conhecimento Qualidade, enquanto
as ltimas figuram na rea de Testes. A norma internacional ISO/IEC 25000 SQuaRE,
que trata da qualidade de produtos de software, abrange esses dois tpicos.
Na verdade, todas as subreas da engenharia de software tm alguma relao
com a qualidade de programas de computador. O SWEBOK inclui qualidade como
uma rea de conhecimento especfica, mas no deve ser considerada estanque do
restante daquele guia. Outro exemplo a Ergonomia de Software: no SWEBOK,
tratada dentro de disciplinas relacionadas, mas sabe-se que requisitos de ergono-
mia podem causar impacto at sobre a segurana de operao de um produto. Um
exemplo disso so softwares de controle de trfego areo.
Cada rea de conhecimento no SWEBOK subdividida em at dois nveis, for-
mando uma estrutura hierrquica para catalogar os assuntos. No caso da rea de
qualidade, essa organizao hierrquica apresentada na Figura 1.8.
O leitor convidado a ler Ponto de Mutao, de Fritjof Capra, para uma discusso
abrangente sobre os malefcios resultantes da especializao e a importncia da
interdisciplinaridade em todas as profisses.
Qualidade de
Software
Fundamentos de Quali- Processos de Gerncia de Consideraes

dade de SW Qualidade de SW Prticas
Cultura e tica de Garantia de Requisitos de

Eng. de SW Qualidade de SW Qualidade do Software
Valor e Custo da Verificaes e Caracterizao de

Qualidade Validaes Defeitos
Modelos e Tcnicas de
Revises e
Caractersticas Gerenciamento de
Auditoria
de Qualidade Qualidade de SW
Melhoria de Quali- Medio de

dade Qualidade de Software
Figura 1.8 Diviso em tpicos da qualidade SWEBOK, 2004.
A diviso em tpicos ser rapidamente descrita nas prximas subsees.
1.8.1 Fundamentos de qualidade

Este tpico abrange, sobretudo, a noo de qualidade, ou seja, sua definio. Essa
definio, no caso de um produto, materializa-se por meio da definio de requisi-
tos e estes dependem de um modelo. Um dos modelos mais importantes existentes
atualmente a norma SQuaRE, ISO/IEC 25000. Este livro contm um captulo
especial dedicado a essa norma.
Os aspectos ticos do trabalho com software tm se tornado mais evidentes

com nossa dependncia da tecnologia; toda uma nova classe de problemas surgiu
com os crimes de computador. Respostas sociais, ticas e de legislao esto sendo
desenvolvidas para procurar tratar adeqadamente cada caso. Como acontece com
outros aspectos atuais da qualidade de software, o problema j havia sido previsto
h muito tempo. Norbert Wiener, um professor do MIT preocupado com questes
ticas, discutiu questes fundamentais sobre esse assunto dentro da rea de com-
putao [Wiener, 1965]: "Muito antes de Nagasaki e da informao pblica sobre
a bomba atmica, ocorreu-me que estvamos em presena de outra potencialidade
social, de importncia no conhecida, para o bem e para o mal".
A tica profissional um tpico estudado em alguns cursos de computao no

Brasil, em disciplinas como Informtica e Sociedade; at o ano 2000, havia possi-
velmente uma nica publicao em portugus sobre o assunto [Masiero, 2000].
O prximo tpico sob fundamentos da qualidade a relao entre valor e custo

e abrange basicamente dois aspectos: os prejuzos causados pela falta de qualidade
de um produto e os custos com que preciso arcar para garantir um determinado
nvel de exigncia quanto ao funcionamento do software.
1.8.2 Processos de gerncia de qualidade

Os processos de gerncia abrangem todos os aspectos de construo do produto.
Por conta disso, todos elementos de um projeto esto envolvidos: ferramentas como
sistemas para controle de verso e linguagens, metodologias para reviso do produto,
tcnicas organizacionais e de administrao de pessoas etc.
O propsito da subrea de garantia da qualidade assegurar que os objetivos pla-

nejados no incio do projeto sero cumpridos. De forma geral, isso significa estabelecer
sistemas para controlar tudo o que ocorre durante o ciclo de vida, com o propsito
de garantir que o programa que ser fabricado far aquilo que se espera dele.
As verificaes e validaes (V&V) consistem em atividades com um carter um

tanto diferente do que foi dito at aqui, pois nelas se considera a possibilidade de
que algo esteja errado no produto. Idealmente, a garantia da qualidade deve traba-
lhar de maneira a que essas atividades no sejam necessrias. Ao mesmo tempo, isso
no significa em absoluto que as atividades de V&V percam importncia ou sejam
realizadas com menos intensidade na realidade, o que acontecer o oposto. Se
a subrea de Garantia de Qualidade for bem-sucedida, o que se observar com as
atividades de V&V ser uma aprovao do produto com pouca ou sequer nenhuma
restrio.
As auditorias so, em conceito, independentes da construo do software. Uma

boa poltica consiste em empregar auditores que no participaram do projeto, ou
ainda, auditores externos contratados de outra empresa. Aauditoria relacionada
tanto a normas famosas, como a ISO 9000, como a padres internos elaborados
pela prpria organizao.
1.8.3 Consideraes prticas

Este tpico contm observaes de ordem prtica, isto , recomendaes gerais
sobre como transcorre a execuo das atividades relacionadas com qualidade. No
h uma descrio explcita para este tpico no SWEBOK [2004].
H quatro subtpicos; o primeiro requisitos de qualidade de software. Nele so

mencionados itens como fatores de influncia sobre requisitos: oramento para
realizao; usurios envolvidos; ferramentas e mtodos necessrios etc. Alm disso
so considerados os aspectos relacionados com a segurana de funcionamento e as

conseqncias que as falhas podem causar.
A caracterizao (e deteco) de erros diz respeito, em ltima anlise, a verificar

a no-conformidade aos requisitos. H diversas tcnicas relacionadas, como: vrios
tipos de teste de software, revises, inspees, auditorias e ferramentas automati-
zadas de verificao.
As tcnicas para gerenciamento de qualidade so classificadas no SWEBOK em

quatro tipos: orientadas a pessoas (people-intensive), como o caso de revises e
auditorias; estticas, que no envolvem execuo do produto; dinmicas, que so
efetuadas durante a execuo do software; e, finalmente, as tcnicas analticas, que
fazem uso de mtodos formais.
O ltimo subtpico medio da qualidade. Um conjunto de dados obtidos

por medidas um recurso de extrema ajuda para auxiliar a tomada de decises
gerenciais. Embora para muitos gerentes parea mais natural que as medidas sejam
usadas para saber o estado da implementao de um produto, no esto restritas
ao estgio final do desenvolvimento do software. Como prope a norma SQuaRE,
o ideal que os valores desejados para as medidas sejam estabelecidos no incio do
projeto, durante a fase de definio de requisitos.
1.9 Exerccios
1. Voc alguma vez elaborou um cronograma para um software que tivesse
que implementar, como a soluo de um projeto de faculdade? Experi-
mente: procure um projeto em um bom livro de estruturas de dados (por
exemplo, Tenembaum, Langsam e Augenstein) e elabore um cronograma.
Inclua tempo para estudo e projeto, para programao e testes e acrescente
uma margem de segurana. Pea a um colega seu para fazer a mesma coisa
e depois compare os resultados. Por que h diferenas? Qual cronograma
parece mais realstico?
2. A definio de qualidade de Crosby tem ao menos trs pontos positivos

e trs pontos negativos, conforme comentados no texto. Relacione esses
pontos comparando-os diretamente.
3. Dois clientes ao comprarem uma mesma camisa tero, possivelmente,

opinies muito diferentes sobre o produto. Isto um exemplo de rudo de
medio de qualidade? Justifique sua resposta.

QSW 01 Unidade I Capitulo1 - Qualidade de SW PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

QSW 01 Unidade I Capitulo1 - Qualidade de SW PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Captulo 1

A qualidade relativa. O que qualidade para uma pessoa

A idia de qualidade aparentemente intuitiva; contudo, quando examinado mais

A histria da qualidade prosseguiu com inmeros exemplos de resultados extra-

Como veremos ao longo do livro, a qualidade de software ainda depende princi-

Um grande marco na histria da qualidade foi, com certeza, a revoluo indus-

Na dcada de 1920 surgiu o controle estatstico de produo. Nas fbricas que

fora de controle controlado reduo da

Figura 1.1 Diagrama de Shewhart.

Para entender o diagrama, vamos supor que o problema tratado consista em

Na dcada de 1940 surgiram vrios organismos ligados qualidade; por exemplo,

Na dcada de 1940 o Japo destacou-se como um importante plo no assunto

A Figura 1.2 apresenta um diagrama de Ishikawa tpico. A tcnica utilizada para

No Captulo 3 so apresentadas algumas frmulas bsicas e teis em estatstica.

do cenrio como trabalhadores e mquinas. Tais elementos so chamados de

para manufatura: mo-de-obra, mtodos, materiais e mquinas;

para servios e administrao: equipamentos, procedimentos, polticas e

Falta de luvas Distrao por cansao

Figura 1.2 Diagrama de Ishikawa.

No ps-guerra o impulso recebido pelas indstrias se manteve. Oscomputadores

Nas dcadas de 1960 e 1970 ocorreram mudanas tecnolgicas importantes

1.2 Uma crise de mais de trinta anos

Construir um prdio de 10 andares implica tratar um nmero de problemas muito

E como eram as mquinas grandes nessa poca?

At a dcada de 1970 ainda eram utilizadas as memrias de ncleo (core me-

A mudana tecnolgica teve um efeito dramtico na produo de software. Num

A maior causa da crise do software que as mquinas tornaram-

Provavelmente a primeira vez em que se utilizou o termo Engenharia de

Hoje, mais de trinta anos depois, quais so os problemas enfrentados na cons-

O aspecto no repetitivo do desenvolvimento de software torna essa atividade

Figura 1.3 Zonas de sombra em um projeto de engenharia.

Comparativamente, quando estamos tratando de software essa zona de sombra

Requisitos conhecidos e Esforo de desenvol-

Figura 1.4 Zonas de sombra em projeto de software.

As dificuldades em informtica comeam durante as etapas iniciais de um

No bastassem as dificuldades inerentes a esse carter mutvel ou voltil do

Mas voc no pode remover o elemento humano de uma reviso. O

Conciliar a necessidade de disciplina fundamental para garantir uma certa

Alm de metodologias, outro aspecto que contribui para combater o problema

Mas a discusso sobre problemas de software no estar completa sem abor-

1.3 Qualidade e requisitos

Contudo, essas especificaes garantem a qualidade?

O problema de definir e avaliar qualidade ainda no est completamente re-

ou seja, a qualidade de um produto dada pela distncia entre as caractersticas

A frmula mostra que o problema ainda no est resolvido: precisamos definir

O segundo ponto diz respeito realizao da observao do produto. Como

onde representa um erro de medio que no podemos controlar.

Por fim, o terceiro ponto a considerar o papel de diferentes clientes em um

Diferentes stakeholders tm em mente diferentes requisitos e podem

Isto , com freqncia, um problema no muito simples de resolver. Projetos gran-

1.4 Papel da subjetividade

Primeiro, considere um comprador que no tem recursos financeiros para ad-

1.5 Qualidade e bugs I: insetos inofensivos

isto , qualidade de software e bugs so coisas opostas e incompatveis. Assumir

Como poderia ser diferente?

Figura 1.5 Foto de um inseto encontrado em um computador em 1945

Vamos considerar essa questo luz de alguns exemplos.

O dilema gerencial: este caso narrado por Weinberg [1994]: a histria

A importncia relativa I: muitos programas de computador possuem

A importncia relativa II: o sistema de tipografia TEX lendrio pela qua-

A qualidade de um software, como se pode ver, depende de se decidir o que

tamanho e complexidade do software sendo construdo;

Um estudante de computao, cercado de provas e de matria a estudar no final