Escolar Documentos
Profissional Documentos
Cultura Documentos
Livro de Qualidade de Software
Livro de Qualidade de Software
O que qualidade?
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 extraordinrios: 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 construtores 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 tecnologia. 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 principalmente 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 industrial. 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, desencadeou 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 publicado 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.
19
controlado
reduo da
varincia
LS
M
LI
tempo
20
Qualidade de Software
Materiais
Falta de luvas
Treinamento
Mtodos
Mquinas
21
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 quadrado 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 memory): 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 tornaramse 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 emprica [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".
22
Qualidade de Software
cronogramas no observados;
Os erros parecem estar por toda a parte, como uma epidemia que no conseguimos 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, equipamentos 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
23
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
obtidas por clculos
e simulaes
Dimensionamento dos
pilares correto?
Desconhecido
Conhecido
Incertezas existentes
nos ensaios de material
Incertezas no
clculo estrutural
Uma vez terminado o projeto, contudo, existem respostas para a maior parte das
questes que dizem respeito realizao. Os carros que iro trafegar no mudaro 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
garantidos contra mudanas?
Raramente
requisitos
no mudam
No existem ou
so muitas vezes
desconhecidos
Algoritmos preexistentes
aplicveis?
Estimativas no
combinam bem
com criatividade
Desconhecido
Conhecido
Gap semntico
24
Qualidade de Software
25
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.
26
Qualidade de Software
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 conformidade. 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:
27
Isto , com freqncia, um problema no muito simples de resolver. Projetos grandes, 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 contrata o desenvolvimento do software e, depois, obter uma especificao coerente
que atenda aos interessados.
28
Qualidade de Software
Primeiro, considere um comprador que no tem recursos financeiros para adquirir 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, comerciantes 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.
29
30
Qualidade de Software
A importncia relativa II: o sistema de tipografia TEX lendrio pela qualidade 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.
ferramentas utilizadas;
31
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;
32
Qualidade de Software
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 trabalham 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.
33
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 aquelas em que o programa aborta. Contudo, toda falha potencial pode ser perigosa,
mesmo se o programa no for paralisado.
34
Qualidade de Software
35
36
Qualidade de Software
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 tcnico 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
37
38
Qualidade de Software
39
Fundamentos de Qualidade de SW
Processos de Gerncia de
Qualidade de SW
Consideraes
Prticas
Cultura e tica de
Eng. de SW
Garantia de
Qualidade de SW
Requisitos de
Qualidade do Software
Valor e Custo da
Qualidade
Verificaes e
Validaes
Caracterizao de
Defeitos
Modelos e
Caractersticas
de Qualidade
Revises e
Auditoria
Tcnicas de
Gerenciamento de
Qualidade de SW
Melhoria de Qualidade
Medio de
Qualidade de Software
40
Qualidade de Software
41
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? Experimente: 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.