Unidade II

Unidade II
2 QUALIDADE DE SOFTWARE 2.1 Introduo

Segundo Molinari (2003), a norma internacional ISO 9126, publicada em 1991, e que na verso brasileira de agosto de 1996 recebeu o nmero NBR 13596, dene qualidade de software como: 5 A totalidade de caractersticas de um produto de software que lhe confere a capacidade de satisfazer necessidades explcitas e implcitas.

Necessidades explcitas so as condies e objetivos propostos por aqueles que produzem o software. So, portanto, 10 fatores relativos qualidade do processo de desenvolvimento do produto e so percebidos somente pelas pessoas que trabalham no seu desenvolvimento. Necessidades implcitas so subjetivas dos usurios (inclusive operadores, destinatrios dos resultados do 15 software e mantenedores do produto) e so tambm chamadas de fatores externos e podem ser percebidas tanto pelos desenvolvedores quanto pelos usurios. As necessidades implcitas so tambm chamadas de qualidade em uso e devem permitir aos usurios atingirem metas com 20 efetividade, produtividade, segurana e satisfao em um contexto de uso especificado.

24

QUALIDADE DE SOFTWARE
De acordo com Crtes & Chiossi (2001), hoje em dia muita gente fala em qualidade de software, mas nem sempre as pessoas tm uma noo clara desse conceito. Pode-se considerar qualidade sob diferentes pontos de vista e, portanto, pode-se ter 5 diferentes denies, sendo algumas das mais comuns listada a seguir: qualidade de software software sem defeitos; qualidade de software software adequado ao uso, conforme a denio de qualidade de Juran (2002); 10 qualidade de software software que atende s especicaes, conforme a denio de qualidade de Crosby (1979); qualidade de software software produzido por uma empresa que possui certicado ISO 9000 para seu sistema de qualidade; qualidade de software software que possui conabilidade, usabilidade e manutenibilidade. Razes que devem ser levadas em conta com relao qualidade de software: 20 1. Qualidade competitividade a nica maneira de diferenciar o produto do competidor pela qualidade do software e do suporte que fornecido juntamente. 2. Como o mercado amadurece, cliente ou usurios no querem apenas que a empresa fale que tem qualidade, mas que mostre a todos a sua qualidade atravs de certicao nacional ou internacional de qualidade (CMMI, MPsBR, ISO15504 etc.). Uma certicao pode acarretar vantagem competitiva. 3. Qualidade essencial para a sobrevivncia. Clientes esto exigindo qualidade. Se a empresa no tiver habilidade de sobreviver em um mercado altamente competitivo, ela est em risco no mercado.

15

25

30

25

Unidade II
4. A maioria das grandes organizaes, principalmente fora do Brasil, est reduzindo o nmero de fornecedores, e um meio de escolher os fornecedores vericar quais deles tm certicaes de qualidade. 5 5. O mercado brasileiro vulnervel a produtos importados que, normalmente, tm mais qualidade. 6. Qualidade custo/benefcio. Um sistema de qualidade direciona para o aumento da produtividade e permanentemente reduz custos, habilitando o gerenciamento para reduzir a correo de defeitos e dar nfase preveno. 7. Todas as empresas sabem que corrigir defeitos aps o desenvolvimento do software mais dispendioso do que corrigi-los antes. Prevenir defeitos primeiramente pode resolver muita coisa e economizar bastante. 8. Qualidade retm consumidores e aumenta lucros. Pouca qualidade normalmente custa muito mais do que contratar mais desenvolvedores e ainda continuar sem qualidade. 20 9. A maioria dos consumidores no iro tolerar falta de qualidade e iro procurar outros desenvolvedores. Mais qualidade aumenta a satisfao dos consumidores e assegura os que j so clientes h mais tempo.

10

15

A qualidade de software resulta de um conjunto completo de atividades interdependentes, entre as quais a anlise e 25 os testes que so necessrios, mas esto longe de serem sucientes. As atividades de anlise e teste ocorrem ao longo do desenvolvimento e da evoluo de sistemas de software, desde o incio da engenharia de requisitos at a entrega e subsequente evoluo. A qualidade depende de cada parte do processo de 30 software, no apenas da anlise e do teste. Nenhuma quantidade de teste pode compensar a baixa qualidade causada por outras atividades do processo. Por outro lado, uma caracterstica essencial dos processos de software que geram produtos

26

QUALIDADE DE SOFTWARE
de alta qualidade que o teste e anlise do software esto profundamente integrados ao processo e no so algo pensado a posteriori (Pezz & Young, 2008).
2.2 Garantia de produto de software

Conforme Guerra & Colombo (2009), pode-se denir 5 qualidade de produto de software como a conformidade a requisitos funcionais e de desempenho declarados explicitamente, padres de desenvolvimento claramente documentados e caractersticas implcitas que so esperadas de todo software desenvolvido prossionalmente. As denies de 10 qualidade podem variar em alguns aspectos, porm o aspecto que se refere satisfao do cliente ou usuruio no deve ser esquecido. De acordo com Capovilla (1999), existem diferenas importantes entre produtos de software e produtos 15 manufaturados que no podem deixar de ser notadas, sendo elas: 1. Complexidade Normalmente, um produto de software tem muitas regras a serem cumpridas; muitas linhas de cdigo a serem implementadas; e, frequentemente, diversos desenvolvedores envolvidos, que tm ideias diferentes e algumas vezes divergentes, mas que podem levar mesma soluo. 2. Invisibilidade e intangibilidade 25 O software invisvel para o usurio ou cliente. O que se v so as consequncias da execuo do software, diferentemente de um produto manufaturado. Os desenvolvedores necessitam utilizar modelos para representar o sistema de software. Essa intangibilidade

20

27

Unidade II
causa grandes diculdades de comunicao, tanto entre os elementos da equipe de desenvolvimento como entre a equipe e o cliente, podendo acarretar problemas no produto de software. 5 3. Conformidade e modicabilidade O software a interface entre diversas entidades do meio no qual utilizado. 4. Produo sob medida 10 Para software no existe produo em srie, cada usurio um cliente que usa o software a sua maneira, com nfase em partes diferentes. 5. No se degasta com o uso Em software os componentes lgicos so durveis. A falha do software resulta de erros humanos cometidos durante o processo de desenvolvimento. 6. No tem prazo de validade O software no sensvel a problemas ambientais e nem sofre qualquer tipo de defeito devido ao uso cumulativo. 20 7. O custo nal do software basicamente o custo do projeto e do desenvolvimento. 8. O software o nico produto que, quando apresenta defeito, o cliente paga para corrigir. As qualidades do produto so as metas da qualidade de software, e a qualidade do processo consitui os meios para se 25 atingir essas metas. Por exemplo, processos de desenvolvimento com um alto grau de visibilidade so necessrios para a criao

15

28

QUALIDADE DE SOFTWARE
de produtos de alta conana. As qualidades de um produto de software podem ser divididas entre aquelas que so diretamente visveis para o cliente e aquelas que afetam principalmente o desenvolvimento de software. A conabilidade de um produto 5 diretamente visvel pelo cliente, j a manutenibilidade afeta basicamente rea de desenvolvimento, embora suas consequncias possam afetar ao cliente de forma indireta, aumentando o tempo entre a liberao de novas verses, por exemplo. Propriedades que so diretamente visveis 10 pelos usurios do produto de software, tais como conana, latncia, usabilidade e taxa de atendimento, so chamadas de propriedades externas. Propriedades que no so diretamente visveis por usurios nais, tais como manutenibilidade, reusabilidade e rastreabilidade, so chamadas internas, mesmo 15 quando seu impacto no processo de desenvolvimento e evoluo do software pode afetar aos usurios indiretamente (Pezz & Young, 2008). Apesar de todas as iniciativas em relao melhoria da qualidade de software, infelizmente, a realidade das empresas, 20 tanto as nacionais, como as internacionais, est distante do ideal, e os problemas de qualidade nos produtos persistem (Guerra & Colombo, 2009). Rocha (2001) aponta diversas iniciativas e diversos modelos que foram desenvolvidos detalhando as caractersticas de 25 qualidade de um produto de software em subcaractersticas, e estas em atributos. Dentre as iniciativa destaca-se o subcomit de software da ISO e IEC que vm trabalhando desde a dcada de 1990 na elaborao de normas e relatrios tcnicos que permitam especicar e avaliar a qualidade dos produtos de 30 software, consolidando as diversas vises de qualidade.
2.3 Garantia da qualidade de software

A histria da garantia da qualidade no desenvolvimento de software tem paralelo com a histria da qualidade na manufatura

29

Unidade II
de hardware. Durante os primrdios da computao, a qualidade era uma responsabilidade exclusiva do programador. Padres de garantia de qualidade para o software foram introduzidos no desenvolvimento de software sob contrato militar nos Estados 5 Unidos durante a dcada de 1970 e espalharam-se rapidamente para o mundo comercial. A garantia de qualidade de software SQA (Software Quality Assurance) um conjunto de atividades que assegura que todos os esforos sero feitos para garantir que os produtos de 10 software tenham a qualidade desejada. Essas atividades devem: minimizar o nmero de defeitos; criar mecanismos para controlar o desenvolvimento e a manuteno de forma a preservar prazos e custo; garantir que o produto possa ser usado no mercado; melhorar a qualidade de verses futuras do produto ou de novos 15 produtos (Crtes & Chiossi, 2001). A garantia de qualidade de software (SQA) uma atividade que aplicada ao longo de todo o processo de engenharia de software, abrange: 20 mtodos e ferramentas de anlise, projeto, codicao e teste; revises tcnicas formais que so aplicadas durante cada fase de engenharia de software; uma estratgia de testes de mltiplas fases; 25 controle da documentao de software e das mudanas feitas nela; um procedimento para garantir a adequao aos padres de desenvolvimento de software; mecanismos de medio e divulgao. A garantia da qualidade de software enfatiza trs pontos 30 importantes:

30

QUALIDADE DE SOFTWARE
1. Os requisitos de software so a base a partir da qual a qualidade medida. A falta de conformidade aos requisitos signica falta de qualidade. 5 2. Padres especicados denem um conjunto de critrios de desenvolvimento que orientam a maneira segundo a qual o software passa pelo trabalho de engenharia. Se os critrios no forem seguidos, o resultado quase que seguramente ser a falta de qualidade. 10 3. H um conjunto de requisitos implcitos que frequentemente no so mencionados. Se o software se adequar aos seus requisitos explcitos, mas deixar de cumprir seus requisitos implcitos, a qualidade de software ser suspeita O processo de requisitos deve identicar e denir as caractersticas de um produto em particular que de necessidade do cliente e distingui-los dos menos importantes. importante que, na entrega do produto nal, o sistema tenha pouqussimos ou nenhum defeito e que no falhe em produo e seja fcil de 20 utiliz-lo. A comunicao entre o desenvolvedor e o cliente a chave para a denio correta dos requisitos. O desenvolvedor dever trabalhar em conjunto com o cliente para denir corretamente as especicaes do software, isto a denio do escopo do sistema. 15 25 Dessa forma, o desenvolvimento de software deve: utilizar as melhores prticas da engenharia de software (tcnicas de reunies, modelagem de requisitos, documentao padronizada, inspeo, revises etc.);

31

Unidade II
ser executado por pessoal treinado com responsabilidades e instrues (pessoas qualicadas e um processo padronizado de trabalho); 5 dar nfase na preveno de defeitos assim que forem detectados (aplicao de um processo de detectar e corrigir defeitos); gerar registros para demonstrar efetividade e ecincia (registros permitem a gerao de bases histricas e determina as lies aprendidas); 10 utilizar destes registros para aumentar a performance no futuro (melhoria contnua de processos). A garantia da qualidade de software compreende uma variedade de tarefas. A seguir apresentamos as consideradas as sete grandes atividades da SQA: 15 aplicao de mtodos tcnicos comprovados (uso de normas tipo ISO e modelos de qualidade); realizaes de revises tcnicas formais utilizando tcnicas de reunio, reviso por pares, inspeo, walkthrougs etc.; 20 atividades de testes de software; aplicaes de padres e normas preestabelecidas pela organizao, aderncia a padres reconhecidos no mercado; 25 controle de mudanas, prticas bem-sucedidas na gesto de mudanas manuteno evolutiva; medio do processo e da qualidade do produto, mtricas e processo de medio; manuteno de registros e relatrios para feedback superior (feedback e rastreabilidade).

32

QUALIDADE DE SOFTWARE
A SQA inicia-se de fato com o conjunto de mtodos e ferramentas tcnicas que ajudam o desenvolvedor a conseguir uma especicao de elevada qualidade e assim desenvolver um projeto de qualidade. Assim que uma especicao e um projeto 5 tiverem sido criados, seus artefatos devem ser avaliados quanto qualidade. A atividade central que leva a efeito a avaliao da qualidade a reviso tcnica formal (inspeo da qualidade). A reviso tcnica formal um encontro realizado pelo pessoal tcnico 10 com o propsito nico de descobrir problemas de qualidade. De acordo com Weinberg (1997), na resoluo de falhas, as maiores perdas podem vir de efeitos colaterais ou falhas introduzidas ao se resolver outras falhas. As equipes devem ser treinadas para trabalhar na preveno de efeitos colaterais na 15 correo de falhas ou defeitos. Uma equipe adequadamente estruturada consegue prever melhor os efeitos colaterais de qualquer indivduo sozinho. Weinberg (1997) apresenta um relato sobre a ecincia das revises tcnicas em uma organizao americana em grandes projetos de software que 20 possuem pelo menos 2,5 milhes de linhas de cdigo de alto nvel: pode-se encontrar aproximadamente um defeito para cada homem-hora investido. Cada hora gasta em inspees evita uma mdia de 33 horas de manuteno subsequente. As inspees podem ser at 20 vezes mais efeiciente que os testes.

25

O grau em que padres e procedimentos formais so aplicados no processo de engenharia de software varia de empresa para empresa e em muitos casos os padres so determinados pelos 30 clientes ou por imposies reguladoras. Em outras situaes os padres so autoimpostos. Se existirem padres formais, uma atividade SQA deve ser estabelecida para garantir que eles sejam seguidos.

33

Unidade II
Uma grande ameaa qualidade de software vem de uma fonte aparentemente benigna: as mudanas. Toda mudana no software tem potencial para introduzir erros ou criar efeitos colaterais que propagam erros. O processo de controle de 5 mudanas contribui diretamente para a qualidade do software ao formalizar pedidos de mudana, avaliar a natureza da mudana e controlar o impacto da mudana. A aplicao de modelos de gesto de servios, tal como o modelo ITIL, contribui para organizar as mudanas necessrias oriundas de defeitos 10 registrados nos softwares em produo. Um objetivo importante da SQA rastrear a qualidade de software e avaliar o impacto das mudanas metodolgicas e procedimentais sobre a qualidade do software. Para realizar isso, uma mtrica de software deve ser coletada. 15 A anotao e manuteno de registros para a garantia de qualidade de software oferecem procedimentos para a coleta e disseminao de informaes de SQA. Os resultados de revises, auditorias, controle de mudanas, testes e outras atividades SQA devem tornar-se parte do registro histrico 20 de um projeto e devem ser levados ao conhecimento do pessoal de desenvolvimento. Os modelos de qualidade de software, tais como o CMMI e a ISO 15504 que sero apresentadas nos prximos captulos possuem processos especcos e prticas para atender a essas 25 demandas pela qualidade.
2.4 Evoluo da qualidade de software.

No incio, o software era produzido de maneira que ningum tinha compromisso com o que estava sendo feito; iniciativas isoladas procuravam melhorar o produto nal. Conforme Molinari (2003): 30 na dcada de 1980, o importante era descobrir bugs de software; era a verdadeira caa s bruxas;

34

QUALIDADE DE SOFTWARE
na dcada de 1990, o enfoque voltou-se para os negcios: o software deveria suportar o negcio, isto , se o caminho usado sempre funcionasse, as excees eram desprezadas. 5 Agora muito mais, qualidade de software, que veio tona no nal da ltima dcada, passa por um processo de evoluo que busca tornar o desenvolvimento de software coberto, garantido e assistido por todas as etapas de um processo de software.

Os testes de software passaram a ser uma parte importante deste processo e muitas empresas esto descobrindo na prtica que teste fundamental, ainda mais dependendo do negcio. A atividade de teste de software combina uma estratgia de mltiplos passos com uma srie de mtodos de projeto, de 15 casos, de testes que ajudam a garantir uma deteco de erros e defeitos efetiva. 10
2.5 Fatores de qualidade de software

Os fatores que afetam a qualidade de software podem ser categorizados em dois amplos grupos: 20 fatores que podem ser medidos diretamente (por exemplo:, nmero de erros/KLOC quantidade de linhas de cdigo/unidade de tempo); fatores que podem ser medidos apenas de forma indireta (por exemplo: usabilidade ou manutenibilidade). Em cada caso deve ocorrer medio, ou seja, devemos 25 comparar o software com algum dado presente ou histrico e chegar a uma indicao de qualidade. Em relao aos fatores temos as seguintes descries:

35

Unidade II
1. Corretude medida que um sistema satisfaz sua especicao e cumpre os objetivos visados pelo cliente. 2 Conabilidade 5 medida que se pode esperar que um sistema execute sua funo pretendida com a preciso exigida. 3.Ecincia A quantidade de recursos de computao e de cdigo exigida para que um programa execute sua funo. 10 4. Integridade medida que o acesso ao software ou a dados por pessoas no autorizadas pode ser controlado. 5. Usabilidade 15 O esforo para aprender, operar, preparar a entrada e interpretar a sada de um programa. 6. Manutenibilidade O esforo exigido para localizar e reparar erros num programa. 7. Flexibilidade 20 O esforo exigido para modicar um programa/sistema operacional. 8. Testabilidade O esforo exigido para testar um programa a m de garantir que ele execute sua funo pretendida.

36

QUALIDADE DE SOFTWARE
9. Portabilidade O esforo exigido para transferir o programa de um ambiente de sistema de hardware e/ou software para outro. 5 10. Reusabilidade medida que um programa/componente pode ser reusado em outras aplicaes relacionada ao empacotamento e escopo das funes que o programa executa. 11. Interoperabilidade 10 O esforo exigido para se acoplar um sistema a outro.
2.6 Indicadores de qualidade de software

Dentro dos diversos indicadores criados ao longo do tempo, o IEEE Standard (The Institute of Electrical and Eletronics Engineers, INC) sugere um ndice de maturidade de software (SMI) que fornea uma indicao da estabilidade 15 de um software (baseada em mudanas que ocorreram em cada verso do produto). As seguintes informaes so determinadas: SMI = [Mt (Fa + Fc + Fd)] Mt Onde: 20 Mt = nmero de mdulos da verso atual. Fc = nmero de mdulos da verso atual que foram mudados. Fa = nmero de mdulos da verso atual que foram adicionados.

37

Unidade II
Fd = nmero de mdulos da verso anterior que foram suprimidos da liberao atual. O ndice da maturidade de software computado da seguinte maneira: 5 medida que o SMI se aproxima de 1,0 o produto comea a se estabilizar. O SMI tambm pode ser usado como mtrica para planejar as atividades de manuteno do software.

O tempo mdio para produzir um software pode estar relacionado com o SMI, e os modelos empricos para o esforo 10 de manuteno podem ser desenvolvidos. Os indicadores da qualidade permitem o surgimento da garantia estatstica de qualidade. A garantia estatstica da qualidade reete uma crescente tendncia de toda a indstria para se tornar mais quantitativa 15 em relao qualidade. Para o software, a garantia estatstica da qualidade implica os seguintes passos: coleta das informaes sobre os defeitos de software; essas informaes devem ser organizadas por categorias; 20 rastrear cada defeito at suas causas subjacentes (por exemplo, no conformidade s especicaes, erros de projeto, comunicao ruim com o cliente); usando o princpio de Pareto, que diz que 80% dos defeitos podem remeter-se a 20% de todas as causas possveis, esses 20% devem ser mitigados; 25 uma vez que as causas pouco vitais tenham sido identicadas, tome providncias para corrigir os problemas que causaram os defeitos.
2.7 Conabilidade de software

No h dvida de que a conabilidade de um programa de computador um elemento importante de sua qualidade global.

38

QUALIDADE DE SOFTWARE
Se um programa deixar de funcionar repetida e frequentemente, pouco importa se outros fatores da qualidade de software so aceitveis. A conabilidade de software, ao contrrio de muitos 5 outros fatores de qualidade, pode ser medida diretamente e estimada usando-se dados histricos e de desenvolvimento. A conabilidade de software denida em termos estatsticos como a probabilidade de operao livre de falhas de um programa de computador num ambiente especco durante 10 determinado tempo. Conforme Pezz & Young (2008), a conabilidade uma aproximao estatstica da corretude, no sentido que uma conabilidade de 100% indistinguvel de corretude. Simplicando, a conabilidade uma medida da probabilidade de 15 funcionamento correto em alguma unidade de comportamento, que pode ser uma nica execuo ou um perodo de tempo. A conabilidade relativa a uma especicao a qual determina se uma unidade de comportamento ser contada como sucesso ou falha. A conabilidade tambm relativa a um perfl de uso 20 especco. O mesmo programa pode ser mais ou menos convel dependendo de como utilizado.
2.8 Medidas de conabilidade de software

Ao se considerar o sistema computadorizado, uma medida simples da conabilidade o tempo mdio entre a ocorrncia de falha (MTBF), onde MTBF = MTTF + MTTR. Muitos pesquisadores 25 armam que o MTBF uma medida bem mais til do que os defeitos/KLOC. As siglas utilizadas nas medidas de conabilidade signicam: 30 MTBF Mean Time between Failures tempo mdio entre falhas.

39

Unidade II
MTTR Mean Time to Repair tempo mdio de reparo de uma falha ou defeito. MTTF Mean Time to Fail tempo mdio at a ocorrncia de falha. Um usurio nal est preocupado com a ocorrncia de falhas, no com a contagem total de erros. Uma vez que cada erro contido num programa no apresenta o mesmo ndice de falhas, a contagem total de erros oferece poucos indcios da conabilidade de um sistema. Por exemplo, consideramos um 10 programa que tenha estado em operao durante 14 meses. Muitos erros desse programa permanecem sem ser detectados durante dcadas antes de serem revelados. O MTBF de tais erros obscuros poderia ser de 50 ou at mesmo 100 anos. Outros erros, ainda no revelados, poderiam ter um ndice de 15 falha de 18 ou 24 meses. Mesmo se todos os erros de primeira categoria fossem removidos, o impacto sobre a conabilidade do software seria signicante. 5 De acordo com Pezz & Young (2008), a disponibilidade uma mtrica apropriada quando uma falha pode durar um perodo 20 de tempo. A partir de uma medida de conabilidade pode-se desenvolver uma medida de disponibilidade. A disponibilidade de software a probabilidade de que um programa esteja operando de acordo com os requisitos em determinado perodo de tempo, ela denida como: 25 Disponibilidade = MTTF * 100% (MTTF + MTTR)
2.9 Controle de qualidade

De acordo com Molinari (2003), controle de qualidade denido como os processos e mtodos usados para monitorar o trabalho e os requerimentos envolvidos. focado nas revises e remoo de defeitos antes da entrega do produto. Controle

40

QUALIDADE DE SOFTWARE
de qualidade deve ser responsabilidade da unidade de produo do produto dentro da organizao. possvel ter um mesmo grupo que construa o produto e execute a funo de controle de qualidade, ou ter um grupo de controle de qualidade ou um 5 departamento na unidade de produo. Consiste em vericaes do produto bem denidas e que sejam especicadas dentro do plano de garantia de qualidade. Para produtos de software, controle de qualidade inclui revises de especicao, inspees de cdigos e documentos, e 10 vericaes de entrega ao usurio. Segundo Pressman (2006), o controle de qualidade envolve a srie de inspees, revises e testes usada ao longo do processo de software para garantir que cada produto de trabalho satisfaa aos requisitos para ele estabelecidos. O controle de qualidade inclui 15 um ciclo de realimentao no processo de trabalho que criou o produto. A combinao de medida e realimentao permite ajustar o processo quando os produtos de trabalho criados deixam de satisfazer a suas especicaes. Um conceito-chave do controle de qualidade que todos os produtos de trabalho 20 tm especicaes denidas e mensurveis com as quais se pode comparar o resultado de cada processo. O ciclo de realimentao essencial para minimizar os defeitos produzidos. Inspees de documentos e produtos so conduzidas dentro de marcos no ciclo de vida para demonstrar que itens 25 produzidos so especicados atravs de critrios no plano de garantia de qualidade. Esses critrios so normalmente providenciados atravs das especicaes de requisitos, seja em nvel conceitual ou detalhado, e casos de teste. Esses documentos gerados aos usurios so requisitos, resultado dos 30 testes de aceitao dos usurios, cdigo do software, guia de usurio de manuteno e operao de sistema. Existe uma subrea de controle de qualidade que assumiu a gerncia de requisitos. O maior desao controlar os requisitos,

41

Unidade II
vendo se foram denidos, elaborados, validados, detalhados, implementados e realmente testados no ambiente que representa a realidade.
2.10 Preveno X Deteco

Segundo Molinari (2003), qualidade no pode ser alcanada 5 pelo acesso a um produto j pronto e completo. O clamor , entretanto, em primeiro lugar prevenir a qualidade dos defeitos ou das decincias e fazer com que o produto possa ter uma garantia de qualidade atravs de medies. Pode-se realmente gerenciar aquilo que consegue 10 medir e vice-versa. Algumas medidas de qualidade incluem: estruturao de um processo de desenvolvimento com mtodos, tcnicas e ferramentas. Em adio preparao do produto, um processo de preparao importante num programa de gerncia de qualidade. Isto inclui documentao de padres 15 de cdigos, descrio de uso de padres, mtodos, ferramentas, procedimentos de recuperao de dados, gerncia de mudanas, ou congurao como mais conhecida, documentao dos defeitos encontrados e reconciliao, ou rastreabilidade. O gerenciamento da qualidade diminui os custos porque 20 cedo um defeito ser localizado e corrigido, e o custo de defeitos encontrados ser menor ao longo do tempo. Um investimento inicial deve ser signicativo de modo a garantir ao longo do tempo produtos de alta qualidade e com custos de manuteno reduzidos. O custo total efetivo do gerenciamento de qualidade 25 a soma dos quatro fatores: preveno + inspeo + falha interna + falha externa. Prevenir custos consiste no conjunto de aes tomadas para prevenir os defeitos antes que eles apaream primeiro. Custos de inspeo consistem em medir, avaliar e auditar 30 produtos ou servios para avaliar a conformidade com os padres e especicaes. Custos de falhas internas consistem

42

QUALIDADE DE SOFTWARE
em corrigir defeitos dos produtos antes de serem entregues. Custos de falhas externas consistem nos custos descobertos depois que os produtos foram entregues e liberados. Quanto mais falhas externas forem encontradas, mais desastroso 5 ser para a reputao da organizao ou resultar em perda de faturamento. O grande retorno de investimento com preveno. Incrementando a nfase na preveno, se origina uma reduo do nmero de defeitos encontrados pelo usurio, melhoria da qualidade, e reduo do custo de produo e 10 manuteno.
2.11 Vericao e validao

Segundo Molinari (2003), estes dois termos so usados de forma indiscriminada, o que um erro tpico da maioria dos analistas e consultores na rea de teste de software: 15 vericao prova que o produto vai ao encontro dos requisitos especicados durante as preciosas atividades executadas corretamente no desenvolvimento do produto; validao verica se o sistema vai ao encontro dos requisitos do consumidor. A criao de um teste de um produto est muito mais perto de validao do que de vericao. Tradicionalmente teste de software considerado um processo de validao, isto , uma fase do ciclo de desenvolvimento do produto. Depois que o programa terminado, o sistema validado ou testado para 25 determinar sua funcional e operacional performance. 20 Quando vericao incorporada ao teste, o teste corre durante o desenvolvimento tambm. uma prtica combinar vericao com validao no processo de testes. Vericao inclui procedimentos sistemticos de reviso, anlise e testes 30 empregados durante o desenvolvimento, comeando com as

43

Unidade II
fases de requerimentos de software e continuando atravs da codicao do produto. Vericao garante a qualidade do software na produo e na manuteno. A vericao impe um organizado e sistemtico 5 desenvolvimento de tal forma que um programa qualquer possa ser facilmente compreendido e avaliado de modo independente. Vericao emergiu anos atrs como resultado das necessidades da indstria aeroespacial americana, de modo que garantisse extrema conabilidade de software nos sistemas, de maneira 10 que um mnimo erro no programa resultaria em falha da misso e em enorme tempo e atraso nanceiro, ou em simples ameaas em quaisquer situaes. O conceito de vericao inclui dois critrios fundamentais: 1) O software tem de executar todas as funes desejadas. 15 2) O software, durante sua execuo, no deve passar por nenhum caminho que no tenha sido testado em alguma combinao com as outras funes, em outras palavras todas as possibilidades, caminhos e funes tm de estar mapeados, codicados e testados.

A meta global de vericao garantir atravs do desenvolvimento do software que ele vai ao encontro das necessidades dos requerimentos de software documentados. Vericao estabelece uma rastreabilidade entre vrias sees do software documentado e associado s devidas partes das 25 especicaes dos requerimentos. Compreensiva vericao garante que a performance do software e qualidade dos requerimentos so adequadamente testadas e os resultados dos testes possam ser repetidos, mesmo depois de qualquer mudana no software. 20 30 Vericao um processo de melhoria que no tem m. Deve ser usado para garantir a operao e manuteno do

44

QUALIDADE DE SOFTWARE
sistema. Quando procedimentos de vericao so usados, o gerenciamento pode assegurar que os desenvolvedores seguem um formal e sequencial processo de desenvolvimento, com um mnimo de atividades que garanta a qualidade do sistema. Alguns autores mais crticos dizem que vericao incrementa consideravelmente o custo de desenvolvimento. Todavia, tm-se comprovado que a vericao reduz o custo geral do software na preveno, se for usado atravs do processo de desenvolvimento. Os dados obtidos na prtica 10 mostram uma reduo de defeito de 4 para 1. Quando se aplica a vericao se diminui os custos do retrabalho, pois um defeito encontrado em produo custa de 20 a 100 vezes mais do que se fosse encontrado antes. 5
2.12 Revises Tcnicas Formais (RTF)

O objetivo principal das revises tcnicas formais achar 15 erros durante o processo de desenvolvimento de software, de modo que eles no se transformem em defeitos depois da entrega do software. O benefcio bvio das revises tcnicas formais a descoberta antecipada de erros, de forma que eles no se propaguem para o passo seguinte do processo de 20 software. Vrios estudos da indstria (TRW, Nippon Electric, Mitre Corp., entre outros) indicam que as atividades de projeto introduzem entre 50% e 65% de todos os erros (e em ltima anlise de todos os defeitos) durante o processo de software. Todavia, foi mostrado que as revises tcnicas 25 formais so 75% efetivas na descoberta de erros de projeto. Detectando e removendo uma alta porcentagem desses erros, o processo de reviso reduz substancialmente o curso dos passos subsequentes nas de desenvolvimento e manuteno (Pressman, 2006). 30 Independentemente da tcnica escolhida (walkthrougs, inspees, revises etc.), cada reunio de reviso deve atender s seguintes restries:

45

Unidade II
entre trs e cinco pessoas devem ser envolvidas na reviso (o autor do trabalho, um registrador dos resultados escriba, um especialista do assunto, um desenvolvedor mais experiente etc.); 5 preparativos devem ser feitos, os quais no devem exigir mais de duas horas de trabalho de cada pessoa; a durao da reunio de reviso deve ser inferior a duas horas; 10 uma RTF focaliza uma parte especca e pequena de todo o software, restringindo-se o foco, a RTF tem maior probabilidade de descobrir erros; como resultado um relatrio resumido ou ata da reviso confeccionado e deve responder a trs questes: O que foi revisado? Quem fez a reviso?Quais foram as descobertas e concluses?
2.13 Testes de software

15

Embora durante todo o processo de desenvolvimento de software sejam utilizados mtodos, tcnicas e ferramentas a m de se evitar que erros sejam introduzidos no produto, a atividade de teste continua sendo de fundamental importncia 20 para a eliminao dos erros que persistem, conforme Maldonado (1991). Por isso, o teste de software um elemento crtico para a garantia de qualidade do produto e representa a ltima reviso, projeto e codicao, de acordo com Pressman(2002). Teste um processo de execuo de um programa ou de 25 um sistema com a nalidade de encontrar erros. Um bom caso de teste aquele que tem alta probabilidade de encontrar um erro ainda no descoberto. Se o teste for conduzido de maneira bem-sucedida, ele descobrir erros de software. Existem muitos tipos de testes. Os testes tm como foco a 30 deteco de defeitos e existem muitos meios de tornarem mais

46

QUALIDADE DE SOFTWARE
ecientes e efetivos os esforos relacionados aos testes, pois teste de software um elemento crtico da garantia de qualidade de software e representa a reviso nal da especicao, projetos e gerao de cdigo (Molinari, 2003; Pressman, 2006; Rios et al, 5 2007; Pezz & Young, 2008). As tcnicas de teste de software fornecem diretrizes sistemticas para projetar testes que exercitam a lgica interna dos componentes de software, e tambm os domnios de entrada e sada do programa para descobrir erros na funo, 10 comportamento e desempenho do programa. Durante os primeiros estgios de teste, um engenheiro de software realiza todos os testes. No entanto, medida que os processos de testes progridem, especialistas podem ser envolvidos. Os testes so importantes para encontrar o 15 maior nmero possvel de erros. Testes devem ser conduzidos sistematicamente e casos de teste devem ser projetados usando tcnicas disciplinadas. Um plano de testes deve contemplar as tcnicas de testes existentes mais adequadas realidade da empresa que desenvolve 20 o software. Um erro pode ser o resultado de: uma especicao errada ou de falta de um requisito; a especicao pode conter um requisito impossvel de se implementar, considerando o hardware e o software estabelecidos; o projeto do sistema pode conter um defeito, banco de dados e linguagem de programao; 25 o projeto do programa pode conter um defeito ou o cdigo do programa pode estar errado, segundo Peeger (2003). O software testado de duas perspectivas diferentes: a lgica interna do programa exercitada usando tcnicas de projeto de casos de testes, de caixa-branca. Requisitos de software 30 so exercitados usando tcnicas de projeto de casos de teste caixa-preta. Em ambos os casos, o objetivo encontrar o maior nmero de erros com a menor quantidade de esforo e tempo. Um conjunto de casos de teste planejado para exercitar tanto

47

Unidade II
a lgica interna quanto os requisitos externos so projetados e documentados, os resultados esperados so denidos e os resultados reais so registrados. Para garantir que os testes foram executados corretamente, 5 deve-se modicar o ponto de vista, tentando quebrar arduamente o software. Projetar casos de teste de um modo disciplinado e revisar os casos de teste que se cria. Os princpios de testes de software, segundo Pressman (2002) so: 10 todos os testes devem ser relacionados aos requisitos do cliente; os testes devem ser planejados muito antes do incio do teste; o Princpio de Pareto se aplica ao teste de software, isto , 80% de todos os erros descobertos durante o teste vo provavelmente ser relacionados a 20 % de todos os componentes do programa; o problema isolar os componentes suspeitos e testlos; 20 o teste deve comear no varejo, isto , nos componentes individuais, para depois progredir at o teste no atacado, em todo o sistema; teste completo no possvel, mas pode-se cobrir adequadamente a lgica do programa e garantir que todas as condies no projeto no que diz respeito ao componente, tenham sido exercitadas. A testabilidade de software a facilidade com que um programa de computador pode ser testado. Um software testvel quando possui as caractersticas: 1. 30 Operabilidade: quando melhor funciona, mais ecientemente pode ser testado.

15

25

48

QUALIDADE DE SOFTWARE
2. Observabilidade: o que se v o que se testa. 3. Controlabilidade: quanto mais se pode controlar o software, mais o teste pode ser automatizado e otimizado. 5 4. Decomponibilidade: controlando o escopo do teste, pode-se isolar problemas mais rapidamente e realizar retestagem mais racionalmente. 5. Simplicidade: quanto menos h a testar, mais rpido se pode testar. 10 6. Estabilidade: quanto menos modicaes, menos interrupes no teste. 7. Compreensibilidade: quanto mais informaes se tm, mais racionalmente ser testado. Com relao ao testes, Pressman (2002) sugere os seguintes 15 atributos para um bom teste: um bom teste tem uma alta probabilidade de encontrar um erro; no redundante; 20 deve ser boa cepa1: em um grupo de teste que tem um objetivo semelhante, as limitaes de tempo e recursos podem ser abrandadas no sentido da execuo de apenas um subconjunto desses testes; no deve ser muito simples, nem muito complexo.
2.14 Concluso

Este captulo apresentou conceitos desenvolvidos com 25 produto e processo de software. Diversos autores foram utilizados para dar uma viso resumida e abrangente da problemtica envolvida com a qualidade de software. Ele mostra que diversas facetas se apresentam na qualidade de software:
1 Em ingls: of good stock, expresso que pode signicar de boa origem ou bem produzido.

49

Unidade II
fatores, controle, garantia da qualidade, preveno e termina com a losoa envolvida com os testes de software. Fica claro que somente se pode gerenciar a qualidade de um processo e um produto de software se os mesmos puderem 5 ser medidos e acompanhados durante todo o processo. Outra contribuio importante dos autores e especialistas que corrigir defeitos muito caro. Mais uma vez o dito popular prevalece melhor prevenir do que remediar.

50