qualidade de software unid iiwalderson.com/site/wp-content/uploads/2015/07/unid_2.pdfqualidade de...
TRANSCRIPT
24
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
Unidade II
5
10
15
20
2 QUALIDADE DE SOFTWARE
2.1 Introdução
Segundo Molinari (2003), a norma internacional ISO 9126, publicada em 1991, e que na versão brasileira de agosto de 1996 recebeu o número NBR 13596, define qualidade de software como:
A totalidade de características de um produto de software que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas.
Necessidades explícitas são as condições e objetivos propostos por aqueles que produzem o software. São, portanto, fatores relativos à qualidade do processo de desenvolvimento do produto e são percebidos somente pelas pessoas que trabalham no seu desenvolvimento.
Necessidades implícitas são subjetivas dos usuários (inclusive operadores, destinatários dos resultados do software e mantenedores do produto) e são também chamadas de fatores externos e podem ser percebidas tanto pelos desenvolvedores quanto pelos usuários. As necessidades implícitas são também chamadas de qualidade em uso e devem permitir aos usuários atingirem metas com efetividade, produtividade, segurança e satisfação em um contexto de uso especificado.
25
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
De acordo com Côrtes & Chiossi (2001), hoje em dia muita gente fala em qualidade de software, mas nem sempre as pessoas têm uma noção clara desse conceito. Pode-se considerar qualidade sob diferentes pontos de vista e, portanto, pode-se ter diferentes definições, sendo algumas das mais comuns listada a seguir:
• qualidade de software é software sem defeitos;
• qualidade de software é software adequado ao uso, conforme a definição de qualidade de Juran (2002);
• qualidade de software é software que atende às especificações, conforme a definição de qualidade de Crosby (1979);
• qualidade de software é software produzido por uma empresa que possui certificado ISO 9000 para seu sistema de qualidade;
• qualidade de software é software que possui confiabilidade, usabilidade e manutenibilidade.
Razões que devem ser levadas em conta com relação à qualidade de software:
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 usuários não querem apenas que a empresa fale que tem qualidade, mas que mostre a todos a sua qualidade através de certificação nacional ou internacional de qualidade (CMMI, MPsBR, ISO15504 etc.). Uma certificação pode acarretar vantagem competitiva.
3. Qualidade é essencial para a sobrevivência. Clientes estão exigindo qualidade. Se a empresa não tiver habilidade de sobreviver em um mercado altamente competitivo, ela está em risco no mercado.
5
10
15
20
25
30
26
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
4. A maioria das grandes organizações, principalmente fora do Brasil, está reduzindo o número de fornecedores, e um meio de escolher os fornecedores é verificar quais deles têm certificações de qualidade.
5. O mercado brasileiro é vulnerável a produtos importados que, normalmente, têm mais qualidade.
6. Qualidade é custo/benefício. Um sistema de qualidade direciona para o aumento da produtividade e permanentemente reduz custos, habilitando o gerenciamento para reduzir a correção de defeitos e dar ênfase à prevenção.
7. Todas as empresas sabem que corrigir defeitos após o desenvolvimento do software é mais dispendioso do que corrigi-los antes. Prevenir defeitos primeiramente pode resolver muita coisa e economizar bastante.
8. Qualidade retém consumidores e aumenta lucros. Pouca qualidade normalmente custa muito mais do que contratar mais desenvolvedores e ainda continuar sem qualidade.
9. A maioria dos consumidores não irão tolerar falta de qualidade e irão procurar outros desenvolvedores. Mais qualidade aumenta a satisfação dos consumidores e assegura os que já são clientes há mais tempo.
A qualidade de software resulta de um conjunto completo de atividades interdependentes, entre as quais a análise e os testes que são necessários, mas estão longe de serem suficientes. As atividades de análise e teste ocorrem ao longo do desenvolvimento e da evolução de sistemas de software, desde o início da engenharia de requisitos até a entrega e subsequente evolução. A qualidade depende de cada parte do processo de software, não apenas da análise e do teste. Nenhuma quantidade de teste pode compensar a baixa qualidade causada por outras atividades do processo. Por outro lado, uma característica essencial dos processos de software que geram produtos
5
10
15
20
25
30
27
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
de alta qualidade é que o teste e análise do software estão profundamente integrados ao processo e não são algo pensado a posteriori (Pezzé & Young, 2008).
2.2 Garantia de produto de software
Conforme Guerra & Colombo (2009), pode-se definir qualidade de produto de software como a conformidade a requisitos funcionais e de desempenho declarados explicitamente, padrões de desenvolvimento claramente documentados e características implícitas que são esperadas de todo software desenvolvido profissionalmente. As definições de qualidade podem variar em alguns aspectos, porém o aspecto que se refere à satisfação do cliente ou usuáruio não deve ser esquecido.
De acordo com Capovilla (1999), existem diferenças importantes entre produtos de software e produtos manufaturados que não podem deixar de ser notadas, sendo elas:
1. Complexidade
Normalmente, um produto de software tem muitas regras a serem cumpridas; muitas linhas de código a serem implementadas; e, frequentemente, diversos desenvolvedores envolvidos, que têm ideias diferentes e algumas vezes divergentes, mas que podem levar à mesma solução.
2. Invisibilidade e intangibilidade
O software é invisível para o usuário ou cliente. O que se vê são as consequências da execução do software, diferentemente de um produto manufaturado. Os desenvolvedores necessitam utilizar modelos para representar o sistema de software. Essa intangibilidade
5
10
15
20
25
28
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
causa grandes dificuldades de comunicação, tanto entre os elementos da equipe de desenvolvimento como entre a equipe e o cliente, podendo acarretar problemas no produto de software.
3. Conformidade e modificabilidade
O software é a interface entre diversas entidades do meio no qual é utilizado.
4. Produção sob medida
Para software não existe produção em série, cada usuário é um cliente que usa o software a sua maneira, com ênfase em partes diferentes.
5. Não se degasta com o uso
Em software os componentes lógicos são duráveis. A falha do software resulta de erros humanos cometidos durante o processo de desenvolvimento.
6. Não tem prazo de validade
O software não é sensível a problemas ambientais e nem sofre qualquer tipo de defeito devido ao uso cumulativo.
7. O custo final 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 são as metas da qualidade de software, e a qualidade do processo consitui os meios para se atingir essas metas. Por exemplo, processos de desenvolvimento com um alto grau de visibilidade são necessários para a criação
5
10
15
20
25
29
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
de produtos de alta confiança. As qualidades de um produto de software podem ser divididas entre aquelas que são diretamente visíveis para o cliente e aquelas que afetam principalmente o desenvolvimento de software. A confiabilidade de um produto é diretamente visível pelo cliente, já a manutenibilidade afeta basicamente à área de desenvolvimento, embora suas consequências possam afetar ao cliente de forma indireta, aumentando o tempo entre a liberação de novas versões, por exemplo. Propriedades que são diretamente visíveis pelos usuários do produto de software, tais como confiança, latência, usabilidade e taxa de atendimento, são chamadas de propriedades externas. Propriedades que não são diretamente visíveis por usuários finais, tais como manutenibilidade, reusabilidade e rastreabilidade, são chamadas internas, mesmo quando seu impacto no processo de desenvolvimento e evolução do software pode afetar aos usuários indiretamente (Pezzé & Young, 2008).
Apesar de todas as iniciativas em relação à melhoria da qualidade de software, infelizmente, a realidade das empresas, 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 características de qualidade de um produto de software em subcaracterísticas, e estas em atributos. Dentre as iniciativa destaca-se o subcomitê de software da ISO e IEC que vêm trabalhando desde a década de 1990 na elaboração de normas e relatórios técnicos que permitam especificar e avaliar a qualidade dos produtos de software, consolidando as diversas visões de qualidade.
2.3 Garantia da qualidade de software
A história da garantia da qualidade no desenvolvimento de software tem paralelo com a história da qualidade na manufatura
5
10
15
20
25
30
30
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
de hardware. Durante os primórdios da computação, a qualidade era uma responsabilidade exclusiva do programador. Padrões de garantia de qualidade para o software foram introduzidos no desenvolvimento de software sob contrato militar nos Estados Unidos durante a década 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 esforços serão feitos para garantir que os produtos de software tenham a qualidade desejada. Essas atividades devem: minimizar o número de defeitos; criar mecanismos para controlar o desenvolvimento e a manutenção de forma a preservar prazos e custo; garantir que o produto possa ser usado no mercado; melhorar a qualidade de versões futuras do produto ou de novos produtos (Côrtes & Chiossi, 2001).
A garantia de qualidade de software (SQA) é uma atividade que é aplicada ao longo de todo o processo de engenharia de software, abrange:
• métodos e ferramentas de análise, projeto, codificação e teste;
• revisões técnicas formais que são aplicadas durante cada fase de engenharia de software;
• uma estratégia de testes de múltiplas fases;
• controle da documentação de software e das mudanças feitas nela;
• um procedimento para garantir a adequação aos padrões de desenvolvimento de software;
• mecanismos de medição e divulgação.
A garantia da qualidade de software enfatiza três pontos importantes:
5
10
15
20
25
30
31
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
1. Os requisitos de software são a base a partir da qual a qualidade é medida.
A falta de conformidade aos requisitos significa falta de qualidade.
2. Padrões especificados definem um conjunto de critérios de desenvolvimento que orientam a maneira segundo a qual o software passa pelo trabalho de engenharia.
Se os critérios não forem seguidos, o resultado quase que seguramente será a falta de qualidade.
3. Há um conjunto de requisitos implícitos que frequentemente não são mencionados.
Se o software se adequar aos seus requisitos explícitos, mas deixar de cumprir seus requisitos implícitos, a qualidade de software será suspeita
O processo de requisitos deve identificar e definir as características de um produto em particular que é de necessidade do cliente e distingui-los dos menos importantes. É importante que, na entrega do produto final, o sistema tenha pouquíssimos ou nenhum defeito e que não falhe em produção e seja fácil de utilizá-lo. A comunicação entre o desenvolvedor e o cliente é a chave para a definição correta dos requisitos. O desenvolvedor deverá trabalhar em conjunto com o cliente para definir corretamente as especificações do software, isto é a definição do escopo do sistema.
Dessa forma, o desenvolvimento de software deve:
• utilizar as melhores práticas da engenharia de software (técnicas de reuniões, modelagem de requisitos, documentação padronizada, inspeção, revisões etc.);
5
10
15
20
25
32
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
• ser executado por pessoal treinado com responsabilidades e instruções (pessoas qualificadas e um processo padronizado de trabalho);
• dar ênfase na prevenção de defeitos assim que forem detectados (aplicação de um processo de detectar e corrigir defeitos);
• gerar registros para demonstrar efetividade e eficiência (registros permitem a geração de bases históricas e determina as lições aprendidas);
• utilizar destes registros para aumentar a performance no futuro (melhoria contínua de processos).
A garantia da qualidade de software compreende uma variedade de tarefas. A seguir apresentamos as consideradas as sete grandes atividades da SQA:
• aplicação de métodos técnicos comprovados (uso de normas tipo ISO e modelos de qualidade);
• realizações de revisões técnicas formais utilizando técnicas de reunião, revisão por pares, inspeção, walkthrougs etc.;
• atividades de testes de software;
• aplicações de padrões e normas preestabelecidas pela organização, aderência a padrões reconhecidos no mercado;
• controle de mudanças, práticas bem-sucedidas na gestão de mudanças – manutenção evolutiva;
• medição do processo e da qualidade do produto, métricas e processo de medição;
• manutenção de registros e relatórios para feedback superior (feedback e rastreabilidade).
5
10
15
20
25
33
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
A SQA inicia-se de fato com o conjunto de métodos e ferramentas técnicas que ajudam o desenvolvedor a conseguir uma especificação de elevada qualidade e assim desenvolver um projeto de qualidade. Assim que uma especificação e um projeto tiverem sido criados, seus artefatos devem ser avaliados quanto à qualidade.
A atividade central que leva a efeito a avaliação da qualidade é a revisão técnica formal (inspeção da qualidade). A revisão técnica formal é um encontro realizado pelo pessoal técnico com o propósito único de descobrir problemas de qualidade.
De acordo com Weinberg (1997), na resolução 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 prevenção de efeitos colaterais na correção de falhas ou defeitos. Uma equipe adequadamente estruturada consegue prever melhor os efeitos colaterais de qualquer indivíduo sozinho. Weinberg (1997) apresenta um relato sobre a eficiência das revisões técnicas em uma organização americana em grandes projetos de software que possuem pelo menos 2,5 milhões de linhas de código de alto nível:
pode-se encontrar aproximadamente um defeito para cada homem-hora investido. Cada hora gasta em inspeções evita uma média de 33 horas de manutenção subsequente. As inspeções podem ser até 20 vezes mais efeiciente que os testes.
O grau em que padrões e procedimentos formais são aplicados no processo de engenharia de software varia de empresa para empresa e em muitos casos os padrões são determinados pelos clientes ou por imposições reguladoras. Em outras situações os padrões são autoimpostos. Se existirem padrões formais, uma atividade SQA deve ser estabelecida para garantir que eles sejam seguidos.
5
10
15
20
25
30
34
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
Uma grande ameaça à qualidade de software vem de uma fonte aparentemente benigna: as mudanças. Toda mudança no software tem potencial para introduzir erros ou criar efeitos colaterais que propagam erros. O processo de controle de mudanças contribui diretamente para a qualidade do software ao formalizar pedidos de mudança, avaliar a natureza da mudança e controlar o impacto da mudança. A aplicação de modelos de gestão de serviços, tal como o modelo ITIL, contribui para organizar as mudanças necessárias oriundas de defeitos registrados nos softwares em produção.
Um objetivo importante da SQA é rastrear a qualidade de software e avaliar o impacto das mudanças metodológicas e procedimentais sobre a qualidade do software. Para realizar isso, uma métrica de software deve ser coletada. A anotação e manutenção de registros para a garantia de qualidade de software oferecem procedimentos para a coleta e disseminação de informações de SQA. Os resultados de revisões, auditorias, controle de mudanças, testes e outras atividades SQA devem tornar-se parte do registro histórico 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 serão apresentadas nos próximos capítulos – possuem processos específicos e práticas para atender a essas demandas pela qualidade.
2.4 Evolução da qualidade de software.
No início, o software era produzido de maneira que ninguém tinha compromisso com o que estava sendo feito; iniciativas isoladas procuravam melhorar o produto final. Conforme Molinari (2003):
• na década de 1980, o importante era descobrir “bugs” de software; era a verdadeira caça às “bruxas”;
5
10
15
20
25
30
35
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
• na década de 1990, o enfoque voltou-se para os negócios: o software deveria suportar o negócio, isto é, se o caminho usado sempre funcionasse, as exceções eram desprezadas.
Agora é muito mais, qualidade de software, que veio à tona no final da última década, passa por um processo de evolução 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 estão descobrindo na prática que teste é fundamental, ainda mais dependendo do negócio. A atividade de teste de software combina uma estratégia de múltiplos passos com uma série de métodos de projeto, de casos, de testes que ajudam a garantir uma detecção de erros e defeitos efetiva.
2.5 Fatores de qualidade de software
Os fatores que afetam a qualidade de software podem ser categorizados em dois amplos grupos:
• fatores que podem ser medidos diretamente (por exemplo:, número de erros/KLOC – quantidade de linhas de código/unidade de tempo);
• fatores que podem ser medidos apenas de forma indireta (por exemplo: usabilidade ou manutenibilidade).
Em cada caso deve ocorrer medição, ou seja, devemos comparar o software com algum dado presente ou histórico e chegar a uma indicação de qualidade. Em relação aos fatores temos as seguintes descrições:
5
10
15
20
25
36
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
1. Corretude
À medida que um sistema satisfaz sua especificação e cumpre os objetivos visados pelo cliente.
2 Confiabilidade
À medida que se pode esperar que um sistema execute sua função pretendida com a precisão exigida.
3.Eficiência
A quantidade de recursos de computação e de código exigida para que um programa execute sua função.
4. Integridade
À medida que o acesso ao software ou a dados por pessoas não autorizadas pode ser controlado.
5. Usabilidade
O esforço para aprender, operar, preparar a entrada e interpretar a saída de um programa.
6. Manutenibilidade
O esforço exigido para localizar e reparar erros num programa.
7. Flexibilidade
O esforço exigido para modificar um programa/sistema operacional.
8. Testabilidade
O esforço exigido para testar um programa a fim de garantir que ele execute sua função pretendida.
5
10
15
20
37
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
9. Portabilidade
O esforço exigido para transferir o programa de um ambiente de sistema de hardware e/ou software para outro.
10. Reusabilidade
À medida que um programa/componente pode ser reusado em outras aplicações – relacionada ao empacotamento e escopo das funções que o programa executa.
11. Interoperabilidade
O esforço 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 forneça uma indicação da estabilidade de um software (baseada em mudanças que ocorreram em cada versão do produto). As seguintes informações são determinadas:
SMI = [Mt – (Fa + Fc + Fd)] Mt
Onde:
• Mt = número de módulos da versão atual.
• Fc = número de módulos da versão atual que foram mudados.
• Fa = número de módulos da versão atual que foram adicionados.
5
10
15
20
38
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
• Fd = número de módulos da versão anterior que foram suprimidos da liberação atual.
O índice da maturidade de software é computado da seguinte maneira:
À medida que o SMI se aproxima de 1,0 o produto começa a se estabilizar. O SMI também pode ser usado como métrica para planejar as atividades de manutenção do software.
O tempo médio para produzir um software pode estar relacionado com o SMI, e os modelos empíricos para o esforço de manutenção podem ser desenvolvidos. Os indicadores da qualidade permitem o surgimento da garantia estatística de qualidade.
A garantia estatística da qualidade reflete uma crescente tendência de toda a indústria para se tornar mais quantitativa em relação à qualidade. Para o software, a garantia estatística da qualidade implica os seguintes passos:
• coleta das informações sobre os defeitos de software; essas informações devem ser organizadas por categorias;
• rastrear cada defeito até suas causas subjacentes (por exemplo, não conformidade às especificações, erros de projeto, comunicação ruim com o cliente);
• usando o princípio de Pareto, que diz que 80% dos defeitos podem remeter-se a 20% de todas as causas possíveis, esses 20% devem ser mitigados;
• uma vez que as causas pouco vitais tenham sido identificadas, tome providências para corrigir os problemas que causaram os defeitos.
2.7 Confiabilidade de software
Não há dúvida de que a confiabilidade de um programa de computador é um elemento importante de sua qualidade global.
5
10
15
20
25
39
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
Se um programa deixar de funcionar repetida e frequentemente, pouco importa se outros fatores da qualidade de software são aceitáveis.
A confiabilidade de software, ao contrário de muitos outros fatores de qualidade, pode ser medida diretamente e estimada usando-se dados históricos e de desenvolvimento. A confiabilidade de software é definida em termos estatísticos como “a probabilidade de operação livre de falhas de um programa de computador num ambiente específico durante determinado tempo”.
Conforme Pezzé & Young (2008), a confiabilidade é uma aproximação estatística da corretude, no sentido que uma confiabilidade de 100% é indistinguível de corretude. Simplificando, a confiabilidade é uma medida da probabilidade de funcionamento correto em alguma unidade de comportamento, que pode ser uma única execução ou um período de tempo. A confiabilidade é relativa a uma especificação a qual determina se uma unidade de comportamento será contada como sucesso ou falha. A confiabilidade também é relativa a um perfíl de uso específico. O mesmo programa pode ser mais ou menos confiável dependendo de como é utilizado.
2.8 Medidas de confiabilidade de software
Ao se considerar o sistema computadorizado, uma medida simples da confiabilidade é o tempo médio entre a ocorrência de falha (MTBF), onde MTBF = MTTF + MTTR. Muitos pesquisadores afirmam que o MTBF é uma medida bem mais útil do que os defeitos/KLOC.
As siglas utilizadas nas medidas de confiabilidade significam:
• MTBF – Mean Time between Failures – tempo médio entre falhas.
5
10
15
20
25
30
40
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
• MTTR – Mean Time to Repair – tempo médio de reparo de uma falha ou defeito.
• MTTF – Mean Time to Fail – tempo médio até a ocorrência de falha.
Um usuário final está preocupado com a ocorrência de falhas, não com a contagem total de erros. Uma vez que cada erro contido num programa não apresenta o mesmo índice de falhas, a contagem total de erros oferece poucos indícios da confiabilidade de um sistema. Por exemplo, consideramos um programa que tenha estado em operação durante 14 meses. Muitos erros desse programa permanecem sem ser detectados durante décadas antes de serem revelados. O MTBF de tais erros obscuros poderia ser de 50 ou até mesmo 100 anos. Outros erros, ainda não revelados, poderiam ter um índice de falha de 18 ou 24 meses. Mesmo se todos os erros de primeira categoria fossem removidos, o impacto sobre a confiabilidade do software seria significante.
De acordo com Pezzé & Young (2008), a disponibilidade é uma métrica apropriada quando uma falha pode durar um período de tempo. A partir de uma medida de confiabilidade 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 período de tempo, ela é definida como:
Disponibilidade = MTTF * 100% (MTTF + MTTR)
2.9 Controle de qualidade
De acordo com Molinari (2003), controle de qualidade é definido como os processos e métodos usados para monitorar o trabalho e os requerimentos envolvidos. É focado nas revisões e remoção de defeitos antes da entrega do produto. Controle
5
10
15
20
25
41
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
de qualidade deve ser responsabilidade da unidade de produção do produto dentro da organização. É possível ter um mesmo grupo que construa o produto e execute a função de controle de qualidade, ou ter um grupo de controle de qualidade ou um departamento na unidade de produção.
Consiste em verificações do produto bem definidas e que sejam especificadas dentro do plano de garantia de qualidade. Para produtos de software, controle de qualidade inclui revisões de especificação, inspeções de códigos e documentos, e verificações de entrega ao usuário.
Segundo Pressman (2006), o controle de qualidade envolve a série de inspeções, revisões e testes usada ao longo do processo de software para garantir que cada produto de trabalho satisfaça aos requisitos para ele estabelecidos. O controle de qualidade inclui um ciclo de realimentação no processo de trabalho que criou o produto. A combinação de medida e realimentação permite ajustar o processo quando os produtos de trabalho criados deixam de satisfazer a suas especificações. Um conceito-chave do controle de qualidade é que todos os produtos de trabalho têm especificações definidas e mensuráveis com as quais se pode comparar o resultado de cada processo. O ciclo de realimentação é essencial para minimizar os defeitos produzidos.
Inspeções de documentos e produtos são conduzidas dentro de marcos no ciclo de vida para demonstrar que itens produzidos são especificados através de critérios no plano de garantia de qualidade. Esses critérios são normalmente providenciados através das especificações de requisitos, seja em nível conceitual ou detalhado, e casos de teste. Esses documentos gerados aos usuários são requisitos, resultado dos testes de aceitação dos usuários, código do software, guia de usuário de manutenção e operação de sistema.
Existe uma subárea de controle de qualidade que assumiu a gerência de requisitos. O maior desafio é controlar os requisitos,
5
10
15
20
25
30
42
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
vendo se foram definidos, elaborados, validados, detalhados, implementados e realmente testados no ambiente que representa a realidade.
2.10 Prevenção X Detecção
Segundo Molinari (2003), qualidade não pode ser alcançada pelo acesso a um produto já pronto e completo. O clamor é, entretanto, em primeiro lugar prevenir a qualidade dos defeitos ou das deficiências e fazer com que o produto possa ter uma garantia de qualidade através de medições.
Pode-se realmente gerenciar aquilo que consegue medir e vice-versa. Algumas medidas de qualidade incluem: estruturação de um processo de desenvolvimento com métodos, técnicas e ferramentas. Em adição à preparação do produto, um processo de preparação é importante num programa de gerência de qualidade. Isto inclui documentação de padrões de códigos, descrição de uso de padrões, métodos, ferramentas, procedimentos de recuperação de dados, gerência de mudanças, ou configuração como é mais conhecida, documentação dos defeitos encontrados e reconciliação, ou rastreabilidade.
O gerenciamento da qualidade diminui os custos porque cedo um defeito será localizado e corrigido, e o custo de defeitos encontrados será menor ao longo do tempo. Um investimento inicial deve ser significativo de modo a garantir ao longo do tempo produtos de alta qualidade e com custos de manutenção reduzidos. O custo total efetivo do gerenciamento de qualidade é a soma dos quatro fatores: prevenção + inspeção + falha interna + falha externa.
Prevenir custos consiste no conjunto de ações tomadas para prevenir os defeitos antes que eles apareçam primeiro. Custos de inspeção consistem em medir, avaliar e auditar produtos ou serviços para avaliar a conformidade com os padrões e especificações. Custos de falhas internas consistem
5
10
15
20
25
30
43
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
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 será para a reputação da organização ou resultará em perda de faturamento. O grande retorno “de investimento” é com prevenção. Incrementando a ênfase na prevenção, se origina uma redução do número de defeitos encontrados pelo usuário, melhoria da qualidade, e redução do custo de produção e manutenção.
2.11 Verificação e validação
Segundo Molinari (2003), estes dois termos são usados de forma indiscriminada, o que é um erro típico da maioria dos analistas e consultores na área de teste de software:
• verificação prova que o produto vai ao encontro dos requisitos especificados durante as preciosas atividades executadas corretamente no desenvolvimento do produto;
• validação verifica se o sistema vai ao encontro dos requisitos do consumidor.
A criação de um teste de um produto está muito mais perto de validação do que de verificação. Tradicionalmente teste de software é considerado um processo de validação, isto é, uma fase do ciclo de desenvolvimento do produto. Depois que o programa é terminado, o sistema é validado ou testado para determinar sua funcional e operacional performance.
Quando verificação é incorporada ao teste, o teste corre durante o desenvolvimento também. É uma prática combinar verificação com validação no processo de testes. Verificação inclui procedimentos sistemáticos de revisão, análise e testes empregados durante o desenvolvimento, começando com as
5
10
15
20
25
30
44
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
fases de requerimentos de software e continuando através da codificação do produto. Verificação garante a qualidade do software na produção e na manutenção.
A verificação “impõe” um organizado e sistemático desenvolvimento de tal forma que um programa qualquer possa ser facilmente compreendido e avaliado de modo independente. Verificação “emergiu” anos atrás como resultado das necessidades da indústria aeroespacial americana, de modo que garantisse extrema confiabilidade de software nos sistemas, de maneira que um mínimo erro no programa resultaria em falha da missão e em enorme tempo e atraso financeiro, ou em simples ameaças em quaisquer situações.
O conceito de verificação inclui dois critérios fundamentais:
1) O software tem de executar todas as funções desejadas.
2) O software, durante sua execução, não deve passar por nenhum caminho que não tenha sido testado em alguma combinação com as outras funções, em outras palavras “todas as possibilidades, caminhos e funções têm de estar mapeados, codificados e testados”.
A meta global de verificação é garantir através do desenvolvimento do software que ele vai ao encontro das necessidades dos requerimentos de software documentados. Verificação estabelece uma rastreabilidade entre várias seções do software documentado e associado às devidas partes das especificações dos requerimentos. Compreensiva verificação garante que a performance do software e qualidade dos requerimentos são adequadamente testadas e os resultados dos testes possam ser repetidos, mesmo depois de qualquer mudança no software.
Verificação é um “processo de melhoria” que não tem fim. Deve ser usado para garantir a operação e manutenção do
5
10
15
20
25
30
45
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
sistema. Quando procedimentos de verificação são usados, o gerenciamento pode assegurar que os desenvolvedores seguem um formal e sequencial processo de desenvolvimento, com um mínimo de atividades que garanta a qualidade do sistema.
Alguns autores mais críticos dizem que verificação incrementa consideravelmente o custo de desenvolvimento. Todavia, têm-se comprovado que a verificação reduz o custo geral do software na prevenção, se for usado através do processo de desenvolvimento. Os dados obtidos na prática mostram uma redução de defeito de 4 para 1. Quando se aplica a verificação se diminui os custos do retrabalho, pois um defeito encontrado em produção custa de 20 a 100 vezes mais do que se fosse encontrado antes.
2.12 Revisões Técnicas Formais (RTF)
O objetivo principal das revisões técnicas formais é achar erros durante o processo de desenvolvimento de software, de modo que eles não se transformem em defeitos depois da entrega do software. O benefício óbvio das revisões técnicas formais é a descoberta antecipada de erros, de forma que eles não se propaguem para o passo seguinte do processo de software. Vários estudos da indústria (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 análise de todos os defeitos) durante o processo de software. Todavia, foi mostrado que as revisões técnicas formais são 75% efetivas na descoberta de erros de projeto. Detectando e removendo uma alta porcentagem desses erros, o processo de revisão reduz substancialmente o curso dos passos subsequentes nas de desenvolvimento e manutenção (Pressman, 2006).
Independentemente da técnica escolhida (walkthrougs, inspeções, revisões etc.), cada reunião de revisão deve atender às seguintes restrições:
5
10
15
20
25
30
46
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
• entre três e cinco pessoas devem ser envolvidas na revisão (o autor do trabalho, um registrador dos resultados -escriba, um especialista do assunto, um desenvolvedor mais experiente etc.);
• preparativos devem ser feitos, os quais não devem exigir mais de duas horas de trabalho de cada pessoa;
• a duração da reunião de revisão deve ser inferior a duas horas;
• uma RTF focaliza uma parte específica e pequena de todo o software, restringindo-se o foco, a RTF tem maior probabilidade de descobrir erros;
• como resultado um relatório resumido ou ata da revisão é confeccionado e deve responder a três questões: O que foi revisado? Quem fez a revisão?Quais foram as descobertas e conclusões?
2.13 Testes de software
Embora durante todo o processo de desenvolvimento de software sejam utilizados métodos, técnicas e ferramentas a fim de se evitar que erros sejam introduzidos no produto, a atividade de teste continua sendo de fundamental importância para a eliminação dos erros que persistem, conforme Maldonado (1991). Por isso, o teste de software é um elemento crítico para a garantia de qualidade do produto e representa a última revisão, projeto e codificação, de acordo com Pressman(2002).
Teste é um processo de execução de um programa ou de um sistema com a finalidade de encontrar erros. Um bom caso de teste é aquele que tem alta probabilidade de encontrar um erro ainda não descoberto. Se o teste for conduzido de maneira bem-sucedida, ele descobrirá erros de software.
Existem muitos tipos de testes. Os testes têm como foco a detecção de defeitos e existem muitos meios de tornarem mais
5
10
15
20
25
30
47
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
eficientes e efetivos os esforços relacionados aos testes, pois teste de software é um elemento crítico da garantia de qualidade de software e representa a revisão final da especificação, projetos e geração de código (Molinari, 2003; Pressman, 2006; Rios et al, 2007; Pezzé & Young, 2008).
As técnicas de teste de software fornecem diretrizes sistemáticas para projetar testes que exercitam a lógica interna dos componentes de software, e também os domínios de entrada e saída do programa para descobrir erros na função, comportamento e desempenho do programa.
Durante os primeiros estágios 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 são importantes para encontrar o maior número possível de erros. Testes devem ser conduzidos sistematicamente e casos de teste devem ser projetados usando técnicas disciplinadas.
Um plano de testes deve contemplar as técnicas de testes existentes mais adequadas à realidade da empresa que desenvolve o software. Um erro pode ser o resultado de: uma especificação errada ou de falta de um requisito; a especificação pode conter um requisito impossível de se implementar, considerando o hardware e o software estabelecidos; o projeto do sistema pode conter um defeito, banco de dados e linguagem de programação; o projeto do programa pode conter um defeito ou o código do programa pode estar errado, segundo Pfleeger (2003).
O software é testado de duas perspectivas diferentes: a lógica interna do programa é exercitada usando técnicas de projeto de casos de testes, de caixa-branca. Requisitos de software são exercitados usando técnicas de projeto de casos de teste caixa-preta. Em ambos os casos, o objetivo é encontrar o maior número de erros com a menor quantidade de esforço e tempo. Um conjunto de casos de teste planejado para exercitar tanto
5
10
15
20
25
30
48
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
a lógica interna quanto os requisitos externos são projetados e documentados, os resultados esperados são definidos e os resultados reais são registrados.
Para garantir que os testes foram executados corretamente, deve-se modificar 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 princípios de testes de software, segundo Pressman (2002) são:
• todos os testes devem ser relacionados aos requisitos do cliente;
• os testes devem ser planejados muito antes do início do teste;
• o Princípio de Pareto se aplica ao teste de software, isto é, 80% de todos os erros descobertos durante o teste vão provavelmente ser relacionados a 20 % de todos os componentes do programa;
• o problema é isolar os componentes suspeitos e testá-los;
• o teste deve começar “no varejo”, isto é, nos componentes individuais, para depois progredir até o teste “no atacado”, em todo o sistema;
• teste completo não é possível, mas pode-se cobrir adequadamente a lógica do programa e garantir que todas as condições 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 é testável quando possui as características:
1. Operabilidade: quando melhor funciona, mais eficientemente pode ser testado.
5
10
15
20
25
30
49
QUALIDADE DE SOFTWARE
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
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.
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 rápido se pode testar.
6. Estabilidade: quanto menos modificações, menos interrupções no teste.
7. Compreensibilidade: quanto mais informações se têm, mais racionalmente será testado.
Com relação ao testes, Pressman (2002) sugere os seguintes atributos para um bom teste:
• um bom teste tem uma alta probabilidade de encontrar um erro;
• não é redundante;
• deve ser boa cepa1: em um grupo de teste que tem um objetivo semelhante, as limitações de tempo e recursos podem ser abrandadas no sentido da execução de apenas um subconjunto desses testes;
• não deve ser muito simples, nem muito complexo.
2.14 Conclusão
Este capítulo apresentou conceitos desenvolvidos com produto e processo de software. Diversos autores foram utilizados para dar uma visão resumida e abrangente da problemática envolvida com a qualidade de software. Ele mostra que diversas facetas se apresentam na qualidade de software:
5
10
15
20
25
1 Em inglês: “of good stock”, expressão que pode significar de boa origem ou bem produzido.
50
Unidade II
Revi
são:
Jul
iana
- D
iagr
amaç
ão: L
éo -
01/
09/2
010
fatores, controle, garantia da qualidade, prevenção e termina com a filosofia 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 ser medidos e acompanhados durante todo o processo. Outra contribuição importante dos autores e especialistas é que corrigir defeitos é muito caro. Mais uma vez o “dito” popular prevalece “é melhor prevenir do que remediar”.
5