Qualidade de Software

Prévia do material em texto

QUALIDADE 
DE SOFTWARE
Priscila Gonçalves 
Abordagens formais e 
garantia estatística de 
qualidade de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Conceituar as abordagens formais e a garantia estatística de qualidade 
de software.
  Classificar as abordagens formais e as garantias estatísticas de quali-
dade de software.
  Demonstrar as principais abordagens formais e garantias estatísticas 
de qualidade de software.
Introdução
A garantia da qualidade de software envolve uma série de atividades 
predefinidas que atribuem confiança ao produto, garantindo que as 
exigências sejam atendidas e que o software esteja em conformidade 
com as normas especificadas. Para tanto, deve-se criar um processo de 
software que seja adaptável e no qual as mudanças sejam realizadas 
visando à melhoria dos elementos do processo que introduzem os pro-
blemas. Tais problemas devem ser identificados previamente, por meio 
de métricas; é a partir delas que será possível aplicar a garantia estatística 
da qualidade de software.
Neste capítulo, você vai estudar o conceito de abordagens formais 
e garantia estatística de qualidade de software, verificando como se dá 
a classificação dessas abordagens e quais são os principais métodos 
empregados nesse âmbito.
Conceitos essenciais
A palavra qualidade possui diferentes signifi cados para diversas áreas. Segundo 
a norma NBR ISO 9000:2005, “[...] qualidade é o grau no qual um conjunto de 
características inerentes satisfaz aos requisitos” (ASSOCIAÇÃO BRASILEIRA 
DE NORMAS TÉCNICAS, 2005, p. 8). Dessa forma, pode-se dizer que se 
algum produto atende às especifi cações que constam nos requisitos, ele possui 
a qualidade desejada. Essa qualidade pode ser medida a partir da satisfação 
do cliente; porém, para algumas pessoas, o produto pode estar em um nível 
satisfatório, enquanto, para outras, esse produto pode ser insatisfatório. Essa 
subjetividade torna a avaliação de qualidade uma difícil tarefa.
O termo qualidade em relação ao software geralmente é mal interpretado, 
pois está ligado ao termo excelência, que não o objetivo primário dos enge-
nheiros de software. O que geralmente ocorre em empresas de software é 
fazer com que o software funcione conforme o esperado, ou seja, sem bugs.
É sabido que todo profissional de software deve primar pela alta quali-
dade, e que esta deve ser pensada desde o princípio pelos desenvolvedores 
de software. Para que fosse possível projetar softwares que tivessem uma 
garantia de qualidade, surgiu a necessidade de concentrar esforços em métodos 
de SQA (do inglês software quality assurance, ou garantia da qualidade de 
software). Nesses métodos, membros do grupo de SQA devem verificar se a 
entrega dos desenvolvedores está correta, para que o trabalho seja executado 
corretamente. Essa garantia se aplica a todo o processo de software, verificando 
se foram elaborados padrões nos quais o software deve ser desenvolvido e 
se os procedimentos de monitoramento foram estabelecidos, garantindo a 
qualidade do produto entregue.
A garantia da qualidade de software envolve vários aspectos, dentre eles:
  adoção de normas e padrões internacionais (ISO e IEEE);
  revisões técnicas e testes de software para encontrar erros;
  análise e coleta dos erros;
  auditorias, para assegurar que as diretrizes estão sendo seguidas;
  utilização de gerenciamento de mudanças;
  educação continuada de seus engenheiros de software;
  gerência dos fornecedores; e
  adoção de políticas de segurança e gestão de riscos.
Abordagens formais e garantia estatística de qualidade de software2
Nas últimas três décadas, percebeu-se que era necessária uma abordagem 
mais formal, utilizando provas matemáticas para demonstrar a adequação do 
programa às suas especificações, conforme Pressman e Maxim (2016).
O princípio de Pareto, segundo seu criador, Joseph Moses Juran, afirma que, para uma 
determinada quantidade de eventos, aproximadamente 80% dos problemas decorrem 
de apenas 20% das causas. Acesse o link abaixo e saiba mais.
https://goo.gl/5VyRZn
Abordagens formais e garantias estatísticas
A garantia estatística da qualidade de software aborda uma tendência que 
cresce na indústria de software, que busca que a análise de qualidade seja 
mais quantitativa em relação à frequência em que os erros ocorrem e às in-
consistências nos softwares que são verifi cadas por certo período de tempo. 
As etapas apresentadas abaixo fazem parte da garantia estatística de qualidade 
de software:
  coletar e classificar informações sobre erros e defeitos de software;
  realizar tentativas de associar cada erro e defeito à causa subjacente;
  utilizar o princípio de Pareto;
  no momento em que as causas forem identificadas, dá-se andamento à 
correção dos problemas que provocaram os erros ou defeitos.
Diante dessa informação, pode-se criar um processo de software que seja 
adaptável e no qual as mudanças sejam realizadas visando à melhoria dos 
elementos do processo que introduzem os problemas. Antes que o produto de 
software seja desenvolvido, medições devem ser realizadas durante a análise 
de requisitos, determinando qual o tempo máximo que o software poderá 
demorar a dar retorno sobre uma ação executada.
A utilização de métricas se refere à influência de fatores subjetivos, utiliza-
dos para julgar a qualidade de um produto e que servem para detectar áreas do 
3Abordagens formais e garantia estatística de qualidade de software
software que necessitam de um olhar mais atento. Pressman e Maxim (2016) 
descreveram algumas metas que devem ser seguidas para atingir a quali-
dade. Essas metas, mostradas no Quadro 1, focam a correção, a completude 
e a consistência dos requisitos, dos indicadores da qualidade do projeto, do 
código-fonte e da eficiência do controle de qualidade.
Meta Atributo Métricas
Qualidade dos 
requisitos
Ambiguidade Nú mero de modificadores ambí guos 
Completude Nú mero de TBA, TBD
Compreensibilidade Nú mero de seç õ es/subseç õ es
Volatilidade Nú mero de mudanç as por requisito
Tempo (por atividade) quando 
é solicitada a mudanç a
Rastreabilidade Nú mero de requisitos nã o 
rastreá veis ao projeto/có digo
Clareza do modelo Nú mero de modelos UML 
Número de pá ginas 
descritivas por modelo
Qualidade 
do projeto
Integridade da 
arquitetura
Existê ncia do modelo de arquitetura
Completude dos 
componentes
Nú mero de componentes mapeados 
no modelo de arquitetura
Complexidade do projeto procedural
Complexidade 
da interface
Nú mero mé dio de cliques para chegar 
a uma funç ã o ou conteú do tí pico
Adequaç ã o do layout
Padrõ es Nú mero de padrõ es usados
 Quadro 1. Metas, atributos e métricas para qualidade de software 
(Continua)
Abordagens formais e garantia estatística de qualidade de software4
Segundo Koscianski e Soares (2007), as métricas devem:
  ter significância, isto é, os resultados obtidos devem agregar informação 
útil à avaliação de qualidade;
  ter custo e complexidade de aplicação compatíveis com a avaliação 
que deverá ser realizada;
  ser repetíveis, pois se uma medição é realizada várias vezes e nenhuma 
condição for alterada, os resultados devem ser sempre os mesmos 
(caso não possam ser repetíveis, um tratamento estatístico poderá ser 
utilizado);
  ser reproduzíveis, pois isso significa que os resultados de uma medição 
devem ser os mesmos para diferentes avaliadores;
 Fonte: Adaptado de Pressman e Maxim (2016). 
Meta Atributo Métricas
Qualidade 
do có digo
Complexidade Complexidade ciclomá tica
Facilidade de 
manutenção
Fatores de projeto
Compreensibilidade Porcentagem de comentá rios internos
Convenç õ es de atribuiç ã o de variá veis
Reutilizaç ã o Porcentagem de componentes 
reutilizados
Documentaç ã o Índice de legibilidade
Eficiê ncia do 
controle de 
qualidade
Alocaç ã o de 
recursos
Porcentagem de horas de 
pessoal por atividade
Taxa de 
completude
Tempo de conclusã o real versus previstoEficá cia da revisã o Métricas de revisão
Eficá cia dos testes Nú mero de erros encontrados 
e gravidade 
Esforç o exigido para corrigir um erro
Origem do erro 
 Quadro 1. Metas, atributos e métricas para qualidade de software 
(Continuação)
5Abordagens formais e garantia estatística de qualidade de software
  ser objetivas, pois a opinião de pessoas envolvidas deve ser limitada 
ou ainda evitada em sua totalidade;
  ser imparciais, principalmente com relação à maneira como as avaliações 
são realizadas (uma escolha criteriosa de parâmetros do ambiente de 
execução pode levar a resultados diferentes, favorecendo ou não um 
dado produto);
  prover evidência para sua validação, uma vez que o resultado de uma 
avaliação é uma curva de tendência.
Também há critérios mais quantitativos utilizados para as métricas, que 
são sugeridos por Weyuker (1988) e citadas por Koscianski e Soares (2007) 
em seu livro Qualidade de software:
  Significância de permutação: uma entidade de um programa A consiste 
em um rearranjo de outra entidade B, então m (A) # m (B), e esse 
resultado depende do “rearranjo” que tenha sido feito.
  Significância de implementação: duas entidades diferentes, A e B, 
produzem a mesma saída para a mesma entrada, cujo critério deveria 
ser válido para métricas que analisassem a estrutura, e não o funcio-
namento do software.
  Monotonicidade: dadas duas entidades de programa diferentes, A e B, 
m (A) ≤ m (A+B) e m (B) ≤ m (A+B).
  Complexidade de interação: dadas duas entidades A e B, m (A) + m (B) 
≤ m (A##B), cujos símbolos ## significam concatenação.
Dentre as métricas que devem ser realizadas, a métrica de funcionalidade 
pode ser concebida no início do desenvolvimento do software, quando esti-
ver na fase de arquitetura do projeto de software, o que ocorre, na maioria 
das vezes, em forma de revisões. Ainda sobre a métrica de funcionalidade, 
pode-se programá-la junto à fase de revisão de coleta de dados, na qual é 
projetada a lógica do sistema. Na funcionalidade, existe a subcaracterística 
de interoperabilidade; esta é avaliada de forma estática, em que é verificado 
se a arquitetura de software projetada contemplará a implementação das 
funcionalidades necessárias.
Contemplando o tópico métricas, falaremos sobre a acurácia, que pode ser 
obtida por meio de contagens realizadas com testes do software, cujos resulta-
dos dependem do funcionamento de componentes internos e de interações com 
o ambiente. A métrica de manutenibilidade pode ser realizada para prever o 
esforço para realizar modificações no software ou para criar uma base de dados 
Abordagens formais e garantia estatística de qualidade de software6
que contenha o histórico para que se possa acompanhar o desenvolvimento. 
A manutenção do software pode ser classificada em quatro tipos:
  Corretiva: modificações são realizadas com a finalidade de corrigir 
defeitos ou não conformidades.
  Adaptativa: utilizada para responder a modificações de requisitos, 
quando as partes de um produto de software já foram projetadas e 
implementadas.
  Incremental: são acrescidas às especificações as funções que não foram 
previstas.
  Preventiva: o software é alterado de maneira que ajude na realização 
de outros três tipos de manutenções.
As medidas de tamanho também podem contribuir como indicadores para 
diversas características de um software — por exemplo, o tempo tomado por 
desenvolvedores para escrever softwares grandes, levando em consideração 
um maior custo para sua produção e uma maior complexidade de escrita.
Dentre as métricas abordadas, temos também a métrica de complexidade 
estrutural, a qual faz a avaliação da construção interna do programa, como 
número de componentes, quantidade e relação entre eles. Não menos impor-
tantes, também existem as métricas de complexidade ciclomática, a métrica 
de Halstead, e as métricas baseadas em fluxo de dados, acoplamento e 
coesão, UML e orientação a objetos.
A usabilidade é medida por fatores não quantificáveis, como itens de 
interface. Já a confiabilidade é medida pela probabilidade de ocorrência de 
falhas, ou seja, a contagem de defeitos, também muito difícil de quantificar 
com precisão, assim como ocorre na usabilidade.
As métricas de disponibilidade estão relacionadas à fração de tempo 
durante a qual um software pode ser utilizado; geralmente são medidas do 
tempo médio entre falhas e o tempo médio para falhar. Para o cálculo da 
disponibilidade de um sistema, utilizamos a seguinte fórmula: divisão do 
tempo médio de falhas pelo tempo médio entre falhas, multiplicados por 
100; o resultado será o percentual de disponibilidade de software. Exemplo:
1 falha de 7 horas por dia
(7/24) *100 = 29,16%
Falhas de 1h a cada 7h
(1/7) *100 = 14,28%
7Abordagens formais e garantia estatística de qualidade de software
Pode-se citar a classificação de falhas, o que ajuda a equipe de desenvol-
vedores a tratar os defeitos da melhor maneira possível. Essas falhas podem 
ser classificadas em quatro níveis de gravidade, conforme Koscianski e Soares 
(2007):
  Falha catastrófica: causa perda total do sistema.
  Falha crítica: causa prejuízos graves ao sistema principal.
  Falha marginal: causa prejuízos menores ao sistema, originando atrasos 
e perda de disponibilidade.
  Falha pequena: causa danos, porém de fácil recuperação.
A medição por eficiência, segundo a norma ISO/IEC 9126, trata a eficiência 
em duas medidas possíveis: comportamento temporal e utilização de recursos. 
O comportamento temporal é de fácil definição, como o número de transações 
por segundo; a dificuldade está em definir o contexto em que devem ser 
aplicadas as métricas. Já para a utilização de recursos, estão relacionados os 
elementos físicos utilizados pelo programa, como espaço em disco, volume 
de tráfego de rede, entre outros.
A métrica referente à portabilidade trata da adaptabilidade do software 
para ser utilizado em plataformas diferentes; ou seja, trata do esforço necessário 
para a adaptação e execução do software em outro ambiente.
Depois de realizar as medições, há a análise de resultados, que traz como 
retorno o nível global de qualidade do produto. Essa informação é muito útil 
para decisões em nível gerencial e aborda questões referentes à aceitação do 
software em seu estado atual ou a necessidade de efetuar correções cabíveis, 
assim como decisões de comprar ou não determinado programa.
Como a quantidade de métricas que podem ser utilizadas para garantir a 
qualidade de software é muito grande, alguns métodos são utilizados para 
auxiliar no processo. As seções a seguir descrevem dois desses métodos, o 
Seis Sigma e o método GQM.
Seis Sigma para engenharia de software
A estratégia Seis Sigma é a estratégia para a garantia estatística da qualidade 
de software mais utilizada, tendo sido popularizada pela Motorola em 1980. 
Trata-se de uma metodologia que possui rigor e disciplina e que utiliza a análise 
estatística e de dados para mensurar e melhorar o desempenho operacional 
de uma empresa, por meio da identifi cação e da eliminação de defeitos em 
processos de fabricação e relacionados a serviços.
Abordagens formais e garantia estatística de qualidade de software8
Essa metodologia possui três etapas fundamentais, conforme Pressman 
e Maxim (2016): 
  definir requisitos do cliente e o que deve ser entregue, assim como as 
metas do projeto, por meio de métodos bem definidos de comunicação 
com o solicitante;
  medir o processo e o seu resultado, para que se possa determinar o 
desempenho da qualidade atual;
  analisar as métricas de defeitos, determinando as poucas causas vitais.
Caso já exista uma gestão de qualidade que precise de aperfeiçoamento, 
são sugeridas mais duas etapas pela metodologia Seis Sigma:
  melhorar o processo, por meio da eliminação das causas básicas de 
defeitos;
  controlar o processo, a fim de garantir que os próximos trabalhos não 
coloquem novamente as causas dos defeitos.
Se a gestão de qualidadeestiver sendo desenvolvida em uma empresa, 
mais duas etapas devem ser incluídas junto às fundamentais:
  projetar o processo, evitando assim causas básicas de defeitos, e atender 
aos requisitos do solicitante;
  verificar se esse modelo de processo evitará defeitos e atenderá aos 
requisitos.
Método GQM 
Um modelo muito utilizado para realizar medições bem defi nidas de acordo 
com objetivos específi cos, a fi m de obter uma melhora na efetividade, é o GQM 
(do inglês goal-question-metric), ou meta-questão-métrica). Esse modelo é 
utilizado para defi nir, implantar, medir, analisar e melhorar os processos, 
conforme conceituam Basili, Caldiera e Rombach (1994). Dentre as caracte-
rísticas desse modelo, pode-se citar a abordagem de cima para baixo, também 
conhecida como top-down, que estabelece uma medição voltada para metas de 
desenvolvimento de software. Nela, a equipe geralmente inicia com as metas 
da organização, defi ne a medição dessas metas, levanta questões a respeito 
dos objetivos e identifi ca métricas que trarão respostas às questões levantadas. 
O modelo de medição GQM está dividido em três níveis:
9Abordagens formais e garantia estatística de qualidade de software
  Conceitual: mensura os objetivos que envolvem produtos, processos 
e recursos.
  Operacional: no qual as questões visam a caracterizar o objeto de me-
dição, no que diz respeito à qualidade, a partir de uma perspectiva.
  Quantitativo: as métricas identificam medidas necessárias para res-
ponder às perguntas.
A Figura 1 apresenta a estrutura hierárquica da abordagem GQM.
Figura 1. Estrutura hierárquica da abordagem GQM.
Fonte: Basili, Caldiera e Rombach (1994).
Vejamos algumas características da aplicação do método GQM que pos-
sibilitam sua eficácia: 
  traz a definição explícita de objetivos de medição;
  possibilita o planejamento cuidadoso do programa de medição, assim 
como a elaboração de documentação;
  considera o contexto;
  mantém o foco nas metas e analisa os dados;
  assegura o compromisso de a gerência permanecer apoiando os resul-
tados das medições;
  não cria falsas métricas para a medição;
  assegura que a métrica será usada como ferramenta, e não como ob-
jetivo final.
Podem-se citar alguns benefícios em sua utilização quando o modelo é 
aplicado para a melhoria do processo sistemático; dentre eles, estão:
Abordagens formais e garantia estatística de qualidade de software10
  compreensão e nivelamento das práticas de software na empresa;
  orientação para os processos de software, assim como o acompanha-
mento dos mesmos;
  comparar novas tecnologias de engenharia de software e avaliar me-
lhorias nas atividades, certificando-as;
  ganhos financeiros;
  melhor sinergia do grupo; e
  aumento da qualidade e envolvimento, garantindo a qualidade.
Segundo Basili, Caldiera e Rombach (1994), o método GQM é importante 
para o planejamento dos mecanismos de coleta de dados e também para o 
planejamento dos resultados da medição dos dados. Ele tem como atribuições 
organizá-los e apresentá-los de forma que seu valor seja maximizado, para 
que os interessados os interpretem em relação aos objetivos.
As fases de implementação do modelo são, respectivamente: planejamento, 
definição, coleta de dados e interpretação do GQM. O método GQM é dividido 
em seis etapas, conforme apontam Basili, Caldiera e Rombach (1994):
  desenvolver um conjunto de metas organizacionais e metas de medições 
associadas para produtividade e qualidade;
  gerar perguntas (baseadas nos modelos) que definam objetivos da forma 
mais completa possível, quantitativamente;
  especificar as medidas necessárias para obter respostas às questões, 
acompanhando os processos e produtos de acordo com os objetivos;
  desenvolver formas de coleta de dados;
  coletar, validar e analisar o dado em tempo real, para que se possa 
realizar a ação corretiva;
  analisar o dado, avaliando de acordo com as metas e propondo futuras 
melhorias.
Diante do que foi abordado nesse tópico, pode-se dizer que o GQM é um 
método orientado por métodos e envolve a medição de produtos de software, 
com utilização na engenharia de software. Esse método, portanto, baseia-se 
no princípio de que a coleta de dados deve ter lógica baseada em um objetivo 
ou meta. Após definir essas metas, deve ser feito um plano GQM elaborado 
para cada uma das metas, em que exista um conjunto de perguntas que espe-
cifiquem as medidas adequadas para a avaliação. Essas medidas definirão os 
dados, que serão coletados para responder aos questionamentos.
11Abordagens formais e garantia estatística de qualidade de software
Principais abordagens formais e garantias 
estatísticas de qualidade de software
Pressman e Maxim (2016) exemplifi caram o uso dos métodos estatísticos, 
trazendo o caso de uma organização de engenharia de software que colheu 
dados de um ano sobre a quantidade de erros encontrados no processo de 
desenvolvimento e defeitos identifi cados após os softwares terem sido libe-
rados. A empresa pôde associar todos os erros e defeitos às seguintes causas:
  IES (Incomplete or erroneous especifications): especificações incom-
pletas ou realizadas de forma errada.
  MCC (Misinterpretation of customer communication): má interpretação 
da comunicação do cliente.
  IDS (Intentional deviation from especifications): desvio intencional 
das especificações.
  VPS (Violation of programming standards): violação dos padrões de 
programação.
  EDR (Error in data representation): erro na representação de dados.
  ICI (Inconsistent components interface): interface inconsistente de 
componentes.
  EDL (Error in design logic): erro na lógica do projeto.
  IET (Incomplete or erroneus testing): testes incompletos ou errôneos.
  IID (Inaccurate or incomplete documentation): documentação imprecisa 
ou incompleta.
  PLT (Error in programming language translation of design): erro na 
tradução do projeto para linguagem de programação.
  HCI (Ambiguous or inconsistent human/computer interface): interface 
homem-máquina ambígua ou inconsistente.
  MIS (Miscellaneous): outros.
A Figura 2 traz um exemplo da aplicação estatística da qualidade de 
software, com a ponderação das causas de erros que foram descobertos.
Abordagens formais e garantia estatística de qualidade de software12
Figura 2. Coleta de dados para estatística de SQA.
Fonte: Pressman e Maxim (2016, p. 457).
A figura acima indica que IES, MCC e EDR são as causas responsáveis 
por 53% dos erros existentes. Por meio da determinação das causas vitais, a 
organização de engenharia de software pode iniciar a correção, escolhendo 
as abordagens indicadas para resolver os problemas. Para melhorar o MCC, 
talvez seja suficiente melhorar a comunicação com o cliente e as especificações 
dos requisitos. Para diminuir o EDR, ferramentas de modelagem de dados 
podem ser adotadas, junto com revisões mais rigorosas do projeto de dados. 
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). NBR ISO 9000. Sistemas de 
gestão da qualidade: fundamentos e vocabulário. Rio de Janeiro, 2005.
BASILI, V. R.; CALDIERA, G.; ROMBACH, H. D. The goal question metric approach. 1994. Dis-
ponível em: . Acesso em: 30 jan. 2019.
KOSCIANSKI, A.; SOARES, M. S. Qualidade de software: aprenda as metodologias e técnicas 
mais modernas para o desenvolvimento de software. 2. ed. São Paulo: Novatec, 2007. 
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. 
ed. Porto Alegre: Bookman, 2016. 
13Abordagens formais e garantia estatística de qualidade de software
Leituras recomendadas
BEZERRA, F. Princípio de pareto: o que é e como funciona? 2017. Disponível em: . Acesso 
em: 30 jan. 2019.
IEEE Standard Glossary of Software Engineering Terminology. C/S2ESC: software & 
systems engineering standards committee. 1990. Disponível em:ieee.org/findstds/standard/610.12-1990.html>. Acesso em: 30 jan. 2019.
Abordagens formais e garantia estatística de qualidade de software14
Conteúdo: