O documento discute a qualidade de software, definindo-a como a conformidade aos requisitos dos clientes. Apresenta diferentes visões de qualidade de software e discute padrões e normas importantes como ISO 9126 para garantir a qualidade. Também descreve exemplos históricos de bugs caros que ocorreram por falta de qualidade.

1. Qualidade de Software
Leinylson Fontinele Pereira
Engenharia de Software

2. 2
Introdução
• Qualidade de software
– Emergiu na década de 80
– Necessidade básica para a competitividade do mercado:
• Empresas que desenvolvem software de qualidade são mais
competitivas;
• Empresas que tem qualidade em seus processos podem, em
geral, oferecer um melhor serviço a um preço mais competitivo.

3. Visões de Qualidade de Software
• Visão Popular
– Algo abstrato
– Perfeição
– Luxo e questão de gosto
• Visão Profissional
– Conformidade aos requisitos
– Adequação ao uso

4. Visões de Qualidade de Software
• Características:
– Defeito zero
– Grande número de funções
– Codificação elegante
– Alto desempenho
– Baixo custo de desenvolvimento
– Desenvolvimento rápido
– Facilidade para o usuário

5. Visões de Qualidade de Software

6. Definição de qualidade
• Definição genérica:
– “Propriedade, atributo ou condição das coisas ou das
pessoas capaz de distingui-las das outras e de lhes
determinar a natureza” (Aurélio).
• Definições de qualidade de software:
– Qualidade é estar em conformidade com os
requisitos dos clientes;
– Qualidade é antecipar e satisfazer os desejos dos
clientes;

7. Bugs históricos
• Mariner I – 1962
– Missão observar planeta Vênus
– Fórmula matemática foi
equivocadamente transcrita para o
computador
– Desviou do curso e foi destruído 4 min
após lançamento
– Prejuízo: US$ 18,5 mi

8. Bugs históricos
• Therac-25 – 1985/1987
– Dispositivo de terapia por radiação
sobre células cancerosas
– Libera doses letais de radiação em
vários consultórios médicos
– Condição de disputa no SO
– 5 mortes, várias pessoas feridas

9. Bugs históricos
• Míssil Patriot – 1991
– Míssil de defesa
– Erro de software no relógio do míssil: a cada 100
horas o relógio interno do sistema desviava um
terço de segundo
– Resultado: 600 metros de erro na distância em
uma interceptação
– 28 soldados americanos mortos

10. Bugs históricos
• Pentium da Intel – 1993
– Erro na divisão de pontos flutuantes (erro
~0,006%)
– 3 a 5 milhões de peças com defeito
– Recall para todos que quiseram trocar
– Custou à Intel US$ 475 milhões

11. Bugs históricos
• Bug do milênio (Y2K) – 2000
– Datas com apenas 2 dígitos para o ano
– Uma das maiores histerias da história
– Ao virar o ano 2000, a preocupação
era que contasse como 1900
– Entre US$ 300 e US$ 500 bi no mundo
todo

12. Bugs históricos
• Toyota Prius – 2010
– Problema no software dos freios ABS
– Recall de 400.000 veículos
– Prejuízo de ~ US$ 2 bilhões, desvalorização de 15%
nas ações

13. Bugs históricos
• Play Station Network - 2011
– Invasão do sistema
– Dados privados e de cartão de crédito de ~70 mi
de pessoas foram roubados

14. Bugs Recentes
• Sistema de bagagens (aeroporto Alemanha) - 2016
– Malas retidas (ano bissexto)
– Sistema de 70 milhões de euros não reconheceu o 29
de fevereiro.
– Esteiras pararam – despacho manual de bagagens
transportadas entre 25 mil e 50 mil malas por dia!.
– 1.200 malas acabaram não sendo despachadas

15. Engenharia de Software
• A Engenharia de Software é uma disciplina que
aplica os princípios de engenharia com o
objetivo de produzir software de alta
qualidade a baixo custo.
O que é um
software de
qualidade?

16. A Qualidade depende do Tipo de
Aplicação
Sistema de Missão
Crítica
Fazer aquilo que eu quero
Comportar-se com precisão
Ser fácil de usar
Rodar bem no hardware
Fácil de alterar
Qualidade Importante
Software Embarcado
EXEMPLO

17. Software para Folha
de Pagamento
Fazer aquilo que eu quero
Se comportar com precisão
Ser fácil de usar
Rodar bem no hardware
Fácil de alterar
Qualidade Importante
Software Interativo
com o usuário
EXEMPLO
A Qualidade depende do Tipo de
Aplicação

18. A Qualidade depende do ponto de vista
A qualidade do produto não pode ser
desvinculada dos interesses da
organização: custos e prazos.
A qualidade fica mais voltada às
características internas do software:
legibilidade, testabilidade, eficiência.
O interesse fica concentrado
principalmente no uso do software:
facilidade de uso, requisitos atendidos.
desenvolvedor
gerente
usuário

19. Qualidade de Software
“A qualidade de um projeto engloba o grau de
atendimento às funções e características
especificadas no modelo de requisitos”
[Pressman,2011]
satisfação do usuário = produto compatível + boa qualidade + entrega
no prazo + entrega dentro do orçamento

20. Aspectos Importantes para QS
1. Requisitos de software:
– Métrica fundamental para medir a qualidade do
software.
• A falta de conformidade aos requisitos significa falta de
qualidade.
2. Padrões:
– Definem um conjunto de critérios que orientam o
desenvolvimento do software.
• Se os critérios não forem seguidos, o resultado seguramente
será a falta de qualidade.

21. Aspectos Importantes para QS
3. Requisitos implícitos:
– Conjunto de requisitos que geralmente não são
mencionados na especificação.
– Ex: “boa manutenibilidade”
• Se o software atende aos requisitos explícitos, mas falha nos
requisitos implícitos, a qualidade é suspeita.
4. Qualidade de software (na visão gerencial):
– O software é considerado de qualidade desde que
possa ser desenvolvido dentro do prazo e do
orçamento especificados.

22. Aspectos Importantes para QS
Processo de
Desenvolvimento
SOFTWARE
PRODUTO
PROCESSO DE
SOFTWARE
PadrõesDesenvolvedor Requisitos
Usuário
Organização
SOFTWARE COM QUALIDADE
Requisitos
atendidos
Padrões
atendidos

23. Aspectos Importantes para QS
– A qualidade não pode ser
incorporada ao produto
depois de pronto.
– Para que a qualidade possa ser
efetivamente incorporada ao
produto, ela deve ser um
objetivo constante do
processo de desenvolvimento.
DEFINIÇÃO
CONSTRUÇÃO
MANUTENÇÃO
SOFTWARE PRODUTO

24. Garantia de Qualidade
• Padrões de Qualidade de Software
– Padrões de produto:
• Se aplicam ao produto de software em desenvolvimento.
• Incluem padrões de documentos (estrutura do documento
de requisitos); especificação de como uma linguagem de
programação deve ser usada; etc.
– Padrões de processo:
• Definem os processos que devem ser seguidos durante o
desenvolvimento de software.

25. Padrões de Qualidade de Software
• Especificações baseadas no conhecimento das
melhores e mais apropriadas práticas para a
empresa.
– O conhecimento freqüentemente é adquirido
somente após um grande número de tentativas e
erros.
• Ajudam a evitar a repetição de erros cometidos no
passado.

26. Padrões de Qualidade de Software
• Provêem um framework conceitual para a
implementação do processo de garantia de
qualidade.
• A garantia da qualidade procura assegurar que
os padrões apropriados foram selecionados e
usados.

27. Padrões de Qualidade
• ISO 9126 – Qualidade de produto de software
• ISO 12207 – Qualidade do processo de software
• ISO 27000 – Segurança da informação
• IEEE 829 – Documentação de testes
• IEEE 1028 – Revisão de software
• IEEE 1044 – Classificação de incidentes
• CMM (Capability Maturity Model)
• SPICE (Soft. Process Improvement & Capability
dErtemination)

28. Padrão ISO/IEC 9126
• ISO (The International Standardization Organization):
– Referência mundial para qualidade de software;
– Formado por 127 países membros;
– Cria padrões e normas técnicas em âmbito mundial.
• IEC (The International Electrotechnical Commission)
– Conta com mais de 50 países membros;
– Publica normas internacionais relacionadas com
eletricidade, eletrônica e áreas relacionadas.

29. Padrão ISO/IEC 9126
• Baseada em três níveis:
– Características,
– Sub-características
– Métricas.
• Cada característica é refinada em um conjunto de sub-
características e cada sub-característica é avaliada por um
conjunto de métricas.
NOTA: ISO/IEC 9126 foi substituída em 2011 pela ISO/IEC 25010

30. Padrão ISO/IEC 9126
característica
subcaracterísticas

31. FUNCIONALIDADE - Satisfaz as necessidades implícitas e explícitas do
usuário?
SUBCARACTERÍSTICA PERGUNTA-CHAVE
• Adequação É adequado as necessidades do usuário?
• Acurácia Faz o que foi proposto de forma correta?
• Interoperabilidade É capaz de interagir com os sistemas especificados?
• Conformidade Está de acordo com as normas de funcionalidade?
• Segurança de Acesso Evita acesso não autorizado a programas e dados?
Padrão ISO/IEC 9126

32. CONFIABILIDADE - o software, durante um período de tempo, funciona de
acordo com as condições pré-estabelecidas?
SUBCARACTERÍSTICA PERGUNTA-CHAVE
• Maturidade Com que freqüência apresenta falhas?
• Tolerância a Falhas Ocorrendo falhas, como ele reage?
• Recuperabilidade É capaz de recuperar dados após uma falha?
• Conformidade Está de acordo com as normas de confiabilidade?
Padrão ISO/IEC 9126

33. USABILIDADE – O software é fácil de usar?
SUBCARACTERÍSTICA PERGUNTA-CHAVE
• Intelegibilidade É fácil entender os conceitos utilizados?
• Apreensibilidade É fácil aprender a usar?
• Operacionalidade É fácil operar e controlar?
• Atratividade É atrativo ao usuário?
• Conformidade Está de acordo com as normas relacionadas à usabilidade?
Padrão ISO/IEC 9126

34. EFICIÊNCIA – O software não desperdiça recursos?
SUBCARACTERÍSTICA PERGUNTA-CHAVE
• Comportamento em Qual é o tempo de resposta e de processamento?
Relação ao Tempo
• Comportamento em Quanto recurso usa? Durante quanto tempo?
Relação aos Recursos
• Conformidade Está de acordo com as normas relacionadas à eficiência?
Padrão ISO/IEC 9126

35. MANUTENIBILIDADE – O software é fácil de alterar?
SUBCARACTERÍSTICA PERGUNTA-CHAVE
• Analisabilidade É fácil encontrar uma falha, quando ocorre?
• Modificabilidade É fácil modificar e remover defeitos?
• Estabilidade Existe risco de efeitos inesperados ao fazer alterações?
• Testabilidade É fácil testar o software modificado?
• Conformidade Está de acordo com as normas de manutenibilidade?
Padrão ISO/IEC 9126

36. PORTABILIDADE - É fácil de usar em outro ambiente?
SUBCARACTERÍSTICA PERGUNTA-CHAVE
• Adaptabilidade É fácil adaptar a ambientes diferentes?
• Capacidade para É fácil instalar?
ser instalado
• Capacidade para É fácil usar para substituir outro?
substituir
• Conformidade Está de acordo com as normas relacionadas à portabilidade?
• Co-existência Pode coexistir com outros produtos compartilhando recursos?
Padrão ISO/IEC 9126

37. Métricas de Qualidade
• Usadas para medir a qualidade de um software
• Tipos de métricas:
• Métricas dinâmicas
•Durante teste ou uso do sistema
• Métricas estáticas
•Tamanho do código, tamanho de identificadores

38. Métricas de Qualidade
• Exemplos de métricas
– Comprimento de código
– Complexidade ciclomática
– Comprimento de identificadores
– Profundidade de aninhamento condicional

39. Outras normas de qualidade
• ISO/IEC 12119:
• Estabelece os requisitos de qualidade para pacotes de
software e instruções para teste, considerando esses
requisitos
• ISO/IEC 14598-5:
• Define um processo de avaliação da qualidade de
produto de software