Escolar Documentos
Profissional Documentos
Cultura Documentos
Qualidade de Software - Aprenda As Metodologias e Técnicas Mais Modernas - 1capitulo PDF
Qualidade de Software - Aprenda As Metodologias e Técnicas Mais Modernas - 1capitulo PDF
Segunda Edio
Andr Koscianski
Michel dos Santos Soares
Novatec
Captulo 1
O que qualidade?
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 de que 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
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?
LS
LI
tempo
LS = Limite superior; M = Mdia; LI = Limite inferior.
Treinamento Antiquadas
Mtodos Mquinas
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.
Captulo 1 O que qualidade? 21
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".
Os erros parecem estar por toda 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.
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
Uma vez terminado o projeto, contudo, existem respostas para a maior parte
das questes que dizem respeito realizao. Os carros que iro trafegar no mu-
daro de largura nem de comprimento repentinamente; a quantidade de veculos
e, portanto, o peso mximo a ser suportado so calculados utilizando-se software
de simulao. 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!
No existem ou Desconhecido
so muitas vezes Gap semntico
desconhecidos Conhecido
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 a 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.
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.
26 Qualidade de Software
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
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 do que ela precisa. 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.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.
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 profissionais 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.
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.
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.
Captulo 1 O que qualidade? 33
Como foi dito antes, as falhas que chamam mais a ateno so certamente aquelas
em que o programa trava. Contudo, toda falha potencial pode ser perigosa, mesmo
se o programa no for paralisado.
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.
Ariane 5 Flight 501 Failure Report by the Inquiry Board, J. L. Lions. Disponvel na Internet.
Captulo 1 O que qualidade? 35
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.
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:
o caractere determinante dos requisitos sobre os resultados;
a dificuldade de garantir que requisitos sejam consistentes em projetos
complexos;
Testes no garantem a ausncia de erros (Dijkstra);
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 [Lever-
36 Qualidade de Software
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.
concorrentes em que race conditions podiam ocorrer. Mensagens 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 em cinco casas decimais um resultado, a rigor, muito improvvel.
Seis pacientes foram vtimas dos erros de projeto do Therac-25.
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.
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.
38 Qualidade de Software
Qualidade de
Software
Modelos e Tcnicas de
Revises e
Caractersticas Gerenciamento de
Auditoria
de Qualidade Qualidade de SW
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. Existem diferenas? Qual cronograma
parece mais realstico?
c. Na lista que voc fez, identifique uma caracterstica que, quando presente
com mais intensidade, aumenta a qualidade; e outra que, quando presente
com mais intensidade, reduz a qualidade.
6. O que voc pensa dos termos isolar defeitos e isolar falhas: h diferenas?
Descreva alguns passos que voc julga necessrios para realizar cada uma
dessas atividades (caso estas sejam diferentes).
8. Elabore uma forma de comparar dois programas para saber qual deles tem
mais qualidade.
a. treinamento do usurio;
b. documentao do programa;