Qualidade de Software

Aprenda as metodologias e tcnicas mais modernas para o desenvolvimento de software

Segunda Edio

Andr Koscianski Michel dos Santos Soares

Novatec

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 qualidade para estabelecer 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 de que h mais de quatro mil anos os egpcios estabeleceram um padro de medida de comprimento: o cbito. 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%1.
1

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 nem 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 efervescncia, 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.

Captulo 1 O que qualidade?

fora de controle controlado reduo da varincia

19

LS M 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 recolhido 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 qualidade. 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 normal2, pouco provvel que uma srie de peas apresente 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 Ishikawa, 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
2

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

20

Qualidade de Software

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 Falta de luvas Trabalhadores Distrao por cansao Acidentes de trabalho Treinamento Mtodos Antiquadas Mquinas

Figura 1.2 Diagrama de Ishikawa.

No ps-guerra, o impulso recebido pelas indstrias se manteve. Os computadores 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 mais importante.

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 apenas 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 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.

Captulo 1 O que qualidade?

21

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". 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 ligao 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 Computing Machinery), criada em 1947 e que edita uma revista cientfica, Communications of the ACM, desde 1957.

22

Qualidade de Software

Hoje, mais de trinta anos depois, quais so os problemas enfrentados na construo 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 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 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.

Captulo 1 O que qualidade?

Projeto e realizao de uma ponte

23

Qualidade do ao e concreto apropriada? Especificaes obtidas por clculos e simulaes Dimensionamento dos pilares correto? Incertezas existentes nos ensaios de material Incertezas no clculo estrutural

Desconhecido 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 mudaro 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! 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 semelhantes a 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?

Esforo de desenvolvimento necessrio? Qualidade do produto final em funo dos requisitos?

Raramente requisitos no mudam No existem ou so muitas vezes desconhecidos

Algoritmos preexistentes aplicveis?

Estimativas no combinam bem com criatividade

Desconhecido Conhecido
Gap semntico

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) uma 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

24

Qualidade de Software

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 desenvolvidas, 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 tempo, garantindo uniformidade: quando 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 abordar 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.

Captulo 1 O que qualidade?

25

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 cotidianamente, 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 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. Contudo, essas especificaes garantem a qualidade? O problema de definir e avaliar qualidade ainda no est completamente resolvido 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.

26

Qualidade de Software

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:

qualidade = f (observado, especificado) = observado especificado

ou seja, a qualidade de um produto dada pela diferena 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 diferena (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 relao a uma longa lista de caractersticas. A lmpada 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 caracterizar um produto. Um exemplo disso, em informtica, so os efeitos de memria cache no desempenho medido de computadores (benchmarks). O erro de observao pode ser representado assim:

qualidade = observado especificado +

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.

Captulo 1 O que qualidade?

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.

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 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.

28

Qualidade de Software

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.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 discusso 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 chocada 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?

Captulo 1 O que qualidade?

29

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 apresentava falhas que apareciam apenas sob certas condies, como trabalhar com textos muito longos. Procurado 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 importncia. 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. A importncia relativa II: o sistema de tipografia TEX lendrio pela qualidade de resultado impresso, por ser gratuito e pelo fato de que, depois de anos, 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

30

Qualidade de Software

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 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.

Captulo 1 O que qualidade?

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;

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 , interrupo da execuo provocado pela diviso b/a. A primeira 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 programa 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.

32

Qualidade de Software

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 profissionais 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 na interrupo 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.

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.

1.6.3 Isolar um defeito

Isolar um defeito consiste em determinar sob quais condies ele ocorre. O objetivo 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 geralmente 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 crash do programa so certamente bastante 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.

34

Qualidade de Software

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 de 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 possibilidade 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 se desviou de sua trajetria e se autodestruiu com uma exploso. O custo desse desastre 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 acidente3 descreveu os eventos em ordem cronolgica inversa, como segue.
O foguete comeou a desintegrar-se a 39 segundos, em razo de 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
3

Ariane 5 Flight 501 Failure Report by the Inquiry Board, J. L. Lions. Disponvel na Internet.

Captulo 1 O que qualidade? 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.

35

Mas o que, de fato, causou o problema? Uma exceo uma condio inesperada em um programa, que tratada geralmente 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 interrompido. No caso do Ariane 5, a exceo tambm foi proveniente de um clculo: um nmero 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 converses 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: 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

son, 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. O operador 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 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 diferentes 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

Captulo 1 O que qualidade?

37

concorrentes em que race conditions4 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.

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 computador 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.

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 quantidade de informao aumentou de tal modo que a especializao profissional tornou-se comum, seno mesmo necessria5 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].
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

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 conhecimentos mesmo em outros domnios. A teoria da computao, por exemplo, no existe como uma entidade separada da matemtica. As classificaes 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, formando uma estrutura hierrquica para catalogar os assuntos. No caso da rea de qualidade, essa organizao hierrquica apresentada na Figura 1.8.
Qualidade de Software

Fundamentos de Qualidade de SW Cultura e tica de Eng. de SW Valor e Custo da Qualidade Modelos e Caractersticas de Qualidade Melhoria de Qualidade

Processos de Gerncia de Qualidade de SW Garantia de Qualidade de SW Verificaes e Validaes Revises e Auditoria

Consideraes Prticas Requisitos de Qualidade do Software Caracterizao de Defeitos Tcnicas de Gerenciamento de Qualidade de SW Medio de Qualidade de Software

Figura 1.8 Diviso em tpicos da qualidade SWEBOK, 2004.

Captulo 1 O que qualidade?

39

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 requisitos 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 [1965], um professor do MIT preocupado com questes ticas, discutiu questes fundamentais sobre esse assunto dentro da rea de computao: "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 possivelmente 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 planejados 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.

40

Qualidade de Software

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 trabalhar 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. A auditoria 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 automatizadas 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

Captulo 1 O que qualidade?

41

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? 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. Existem diferenas? Qual cronograma parece mais realstico? A definio de qualidade de Crosby tem ao menos trs pontos positivos e trs pontos negativos, conforme comentado no texto. Relacione esses pontos comparando-os diretamente. 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. Uma fbrica de tapetes est preocupada em vender seus produtos. Naturalmente, um objetivo ser fabricar tapetes bonitos e de qualidade. a. Aparncia um item separado do modelo de qualidade? Justifique sua resposta. b. Faa uma lista de caractersticas de qualidade para um tapete. 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. 5. 6. Um programa que no tem defeitos pode falhar? Por qu? 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). Volte ao problema 4 b. Repita-o para duas faixas de preo diferentes.

2.

3.

4.

7.

42

Qualidade de Software

8. 9.

Elabore uma forma de comparar dois programas para saber qual deles tem mais qualidade. Um editor de textos ASCII utilizado por um usurio inexperiente para abrir arquivos binrios e abortado. Isso significa que o programa pouco seguro? Discuta onde est o problema que causou a falha, entre as alternativas a seguir: a. treinamento do usurio; b. documentao do programa; c. interface do programa (mensagens e informaes apresentadas na interface); d. construo interna do programa.

10. Qual foi o defeito que causou o desastre do Ariane 5? (A resposta no o overflow de uma converso.) 11. (Discusso em grupo) A engenharia de software foi criada para resolver os problemas da crise do software, ou seja, para que os softwares produzidos tivessem qualidade a um preo e prazo razoveis e que pudessem ser corretamente planejados. Mas os fatores que levaram pesquisadores a denominarem o termo crise de software esto ainda presentes. Discuta se o termo crise adequado e quais as principais conquistas dos ltimos trinta anos da rea.