Unidade II
Unidade II
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:
5
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,
10 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
15 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
20 efetividade, produtividade, segurança e satisfação em um
contexto de uso especificado.
24
QUALIDADE DE SOFTWARE
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
5 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);
10
15
• 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:
20
25
30
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.
25
Unidade II
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
10
15
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.
20
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
25 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
30 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
26
QUALIDADE DE SOFTWARE
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
5 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
10 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
15 manufaturados que não podem deixar de ser notadas, sendo
elas:
1. Complexidade
20
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
25
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
27
Unidade II
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.
5
3. Conformidade e modificabilidade
O software é a interface entre diversas entidades do meio
no qual é utilizado.
4. Produção sob medida
10
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
15
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.
20
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
25 atingir essas metas. Por exemplo, processos de desenvolvimento
com um alto grau de visibilidade são necessários para a criação
28
QUALIDADE DE SOFTWARE
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
5 é 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
10 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
15 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,
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 características de
25 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
30 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
29
Unidade II
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
5 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
10 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
15 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:
20
• 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;
25
• 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
30 importantes:
30
QUALIDADE DE SOFTWARE
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.
5
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.
10
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
20 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.
15
25
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.);
31
Unidade II
• ser executado por pessoal treinado com responsabilidades
e instruções (pessoas qualificadas e um processo
padronizado de trabalho);
5
• 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);
10
• 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:
15
• 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.;
20
• atividades de testes de software;
• aplicações de padrões e normas preestabelecidas pela
organização, aderência a padrões reconhecidos no
mercado;
25
• 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).
32
QUALIDADE DE SOFTWARE
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
5 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
10 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
15 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
20 possuem pelo menos 2,5 milhões de linhas de código de alto
nível:
25
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
30 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.
33
Unidade II
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
5 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
10 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.
15 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
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 serão apresentadas nos próximos capítulos
– possuem processos específicos e práticas para atender a essas
25 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):
30
34
• na década de 1980, o importante era descobrir “bugs” de
software; era a verdadeira caça às “bruxas”;
QUALIDADE DE SOFTWARE
• 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.
5
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
15 casos, de testes que ajudam a garantir uma detecção 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:, 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
25 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:
35
Unidade II
1. Corretude
À medida que um sistema satisfaz sua especificação e
cumpre os objetivos visados pelo cliente.
2 Confiabilidade
5
À 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.
10
4. Integridade
À medida que o acesso ao software ou a dados por pessoas
não autorizadas pode ser controlado.
5. Usabilidade
15
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
20
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.
36
QUALIDADE DE SOFTWARE
9. Portabilidade
O esforço 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 aplicações – relacionada ao empacotamento e
escopo das funções que o programa executa.
11. Interoperabilidade
10
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
15 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:
20
• 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.
37
Unidade II
• 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:
5
À 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
10 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
15 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;
20
• 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;
25
• 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.
38
QUALIDADE DE SOFTWARE
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
5 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
10 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
15 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
20 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
25 afirmam que o MTBF é uma medida bem mais útil do que os
defeitos/KLOC.
As siglas utilizadas nas medidas de confiabilidade
significam:
30
• MTBF – Mean Time between Failures – tempo médio entre
falhas.
39
Unidade II
• 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
10 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
15 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.
5
De acordo com Pezzé & Young (2008), a disponibilidade é uma
métrica apropriada quando uma falha pode durar um período
20 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:
25
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
40
QUALIDADE DE SOFTWARE
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
5 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
10 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
15 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
20 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
25 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
30 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,
41
Unidade II
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
5 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
10 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
15 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
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 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
25 é 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
30 produtos ou serviços para avaliar a conformidade com os
padrões e especificações. 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 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
10 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:
15
• 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
25 determinar sua funcional e operacional performance.
20
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
30 empregados durante o desenvolvimento, começando com as
43
Unidade II
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
5 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
10 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.
15
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
25 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.
20
30
44
Verificação é um “processo de melhoria” que não tem fim.
Deve ser usado para garantir a operação e manutenção do
QUALIDADE DE SOFTWARE
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
10 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.
5
2.12 Revisões Técnicas Formais (RTF)
O objetivo principal das revisões técnicas formais é achar
15 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
20 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
25 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).
30
Independentemente da técnica escolhida (walkthrougs,
inspeções, revisões etc.), cada reunião de revisão deve atender
às seguintes restrições:
45
Unidade II
• 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.);
5
• 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;
10
15
• 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
20 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
25 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
30 detecção de defeitos e existem muitos meios de tornarem mais
46
QUALIDADE DE SOFTWARE
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,
5 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,
10 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
15 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
20 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;
25 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
30 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
47
Unidade II
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,
5 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:
10
• todos os testes devem ser relacionados aos requisitos do
cliente;
• os testes devem ser planejados muito antes do início do
teste;
15
• 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;
20
25
• 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.
30
48
Operabilidade: quando melhor funciona, mais
eficientemente pode ser testado.
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 rápido se
pode testar.
10
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
15 atributos para um bom teste:
• um bom teste tem uma alta probabilidade de encontrar
um erro;
• não é redundante;
20
• 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
25 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:
1 Em inglês: “of good stock”, expressão que pode significar de boa
origem ou bem produzido.
49
Unidade II
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
5 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”.
50