Fundamentos de Engenharia de Software
Gestão de Qualidade
ou
Garantia da Qualidade de Software
Engenharia de Software:
• OBJETIVO
– Produção econômica de software de qualidade
• Produto Software
• Processo de Produção de Software
• Qualidade
Software: produto
• Produção intelectual, portanto humana
• Maleabilidade problemática
• O “produto software” inclui o código objeto e os
manuais de uso e mais, os requisitos, o projeto, o
código fonte, os dados de teste, enfim todos os
artefatos produzidos no processo de produção.
Software: processo de produção
• Dinâmica das atividades envolvidas na
“produção” de software
• atividades técnicas e gerenciais
• modelos prescritivos de processo
• Problema: como organizar e controlar essa
dinâmica de forma a produzir
economicamente software de qualidade?
Qualidade de Software
• Perspectivas
– Conceitual
• o que é qualidade de software?
– Quantitativa
• objetivo revisto: produção mais econômica de
software de mais qualidade
– Processual
• a “produção” da qualidade
Qualidades do produto
Correção, Confiabilidade e Robustez
– Correção: aderência à especificação.
– Confiabilidade: confiança que o usuário deposita no SW
– Robustez: capacidade de lidar com situações não previstas
Desempenho:
capacidade de uso econômico dos recursos computacionais
Ergonomia:
Facilidade de uso, representada pela interface
Verificabilidade:
Facilidade com que propriedades podem ser verificadas
Qualidades do produto
Manutenibilidade:
– Manutenção não é o termo correto
– Manutenção pode ser : corretiva, adaptativa e perfectiva
– Consome 60% dos recursos durante a vida
Reusabilidade:
– Fator importante do custo
– Aplicado em vários níveis : especificação, projeto e rotinas
Portabilidade:
– Capacidade de ser executado em vários ambientes
– Variações de CPUs e Sistemas operacionais
Qualidades do produto
Compreensibilidade:
Facilidade do usuário compreender o sistema
Interoperabilidade:
– Capacidade de coexistir e cooperar com outros Sws.
– Sistema aberto: conjunto extensível de aplicações, independentes
que cooperam para atuar como um sistema integrado.
Qualidades do processo
Produtividade:
– Eficiência do processo
– Recursos necessários para atingir a qualidade
Pontualidade:
– Capacidade do processo de entregar produto no prazo
– Problemas: estimativa, mudança de requisitos
Transparência:
– Importante para : tomada de decisões, rotação de pessoal
– Documentação do processo
Qualidade de Software
• Perspectivas
– Conceitual
• o que é qualidade de software?
– Quantitativa (=> Métricas)
• objetivo revisto: produção mais econômica de
software de mais qualidade
– Processual
• a “produção (garantia)” da qualidade
Produção da Qualidade
• Mecanismos
– o processo (técnico) de produção de software
(métodos, técnicas e ferramentas)
– a Gestão de Qualidade (ou Garantia de
Qualidade de Software)
Gestão de Qualidade
• Alguns conceitos
– controle de qualidade
– garantia da qualidade
– custo da qualidade
• custo de prevenção
• custo de falha
Custo do Erro
Custo Relativo da Correção de Erros
10000
1000
100
10
1
Requisitos
Análise e Projeto
Código
Teste
Produção
Gestão de Qualidade
Qualidade de software: Conformidade com
os requisitos funcionais e de performance
explicitamente declarados, com os padrões de
desenvolvimento explicitamente documentados,
e características implícitas que são esperadas
de todo software profissionalmente
desenvolvido
Gestão de Qualidade
• Tipos de atividades
– atividades GQS (ou do grupo GQS)
• verificar e garantir as conformidades
– revisões técnicas
• detectar erros
Atividades GQS – (1)
1. Preparar um plano SQA para o projeto
•
•
•
•
•
•
Avaliações a serem realizadas;
Auditorias e revisões a serem efetivadas;
Padrões aplicáveis ao projeto;
Procedimentos para informar e acompanhar os erros;
Documentos a serem produzidos pelo grupo SQA;
Quantidade de feedback a ser fornecido à equipe de software.
2. Participar no desenvolvimento da descrição do processo de
software do projeto
3. Rever atividades para verificar a conformidade ao processo
definido
Atividades GQS – (2)
4. Auditar alguns produtos selecionados para verificar
conformidade com suas especificações segundo o
processo;
5. Assegurar que os desvios nas atividades e nos produtos
sejam documentados e tratados segundo um procedimento
documentado.
6. Registrar toda não conformidade e informar a gerência do
projeto
7. Coordenar o controle e gerência das mudanças.
8. Ajudar a coletar e analisar métricas
Gestão de Qualidade
• Tipos de atividades
– atividades GQS (ou do grupo GQS)
• verificar e garantir as conformidades
– revisões técnicas
• detectar erros
Modelo de Amplificação de Defeitos
Passo de desenvolvimento
Defeitos
Erros advindos
do passo anterior
Erros que atravessaram
Erros amplificados 1:x
Erros recém-gerados
Detecção
Percentual
de eficiência
na detecção
de erros
Erros passados para o
próximo passo
Modelo de Amplificação de Defeitos
(sem revisões)
Projeto preliminar
0
0
0%
10 6
10
4
Projeto detalhado (x=1.5)
Código/
6
Teste de unidade (x=3)
37 10
4 x 1.5 0%
10
27
94
25
27 x 3 20%
Teste de integração
47
94
0
0
25
Teste de validação
Teste de sistema
50%
24
0
0
50%
12
0
0
50%
Modelo de Amplificação de Defeitos
(com revisões)
Projeto preliminar
0
0
70%
3
10
2
1
Projeto detalhado (x=1.5)
Código/
2
Teste de unidade (x=3)
15 5
1 x 1.5 50%
5
10
24
25
10 x 3 60%
Teste de integração
12
24
0
0
25
Teste de validação
Teste de sistema
50%
6
0
0
50%
3
0
0
50%
Diferença de custos
?
Custo
Custo
Custo
Custo
Total
para projeto
antes do teste
durante o teste
após a entrega
Unidade Com Revisão
1,5
6,5
15
67
22
36
21
3
33
234
315
201
783
Sem Revisão
0
22
82
12
0
143
1230
804
2177
Revisões técnicas formais
• Objetivos:
– Descobrir erros na função, lógica, ou implementação de qualquer
representação do software;
– Verificar se o software (representação) atende aos requisitos.
– Garantir que o software tenha sido representado conforme padrões
pré-definidos.
– Obter softwares que sejam desenvolvidos mais uniformemente.
– Tornar os projetos mais gerenciáveis.
• A FTR serve como espaço de treinamento e para promover
backup e a continuidade.
Reunião de revisão
• Restrições à reunião:
– Entre 3 e 5 pessoas, uma preparação antecipada (que dure não mais que
duas horas) e duração da reunião inferior a 2 horas
• O foco da reunião FTR é um produto – um componente de
software.
• Atividades preparatórias: produtor, líder do projeto, revisor
líder, revisores.
• Reunião: participantes, agenda, escriba.
• Ao final da reunião, os participantes devem decidir:
– Aceitam o produto.
– Rejeitam o produto (após correção dos erros, outra revisão deve ser
realizada).
– Aceitam o produto provisoriamente (nenhuma revisão adicional é
exigida)
Registro da revisão
• Sumário de revisão
1. O que foi revisado?
2. Quem fez a revisão?
3. Quais foram as descobertas e conclusões?
• Acompanhamento
Diretrizes para a revisão
•
•
•
•
•
•
•
•
•
•
Revise o produto, não o produtor.
Fixe e mantenha uma agenda.
Limite o debate e a contestação.
Enuncie as áreas problemáticas, mas não tente resolver cada
problema anotado.
Faça anotações por escrito.
Limite o número de participantes e insista numa preparação
antecipada.
Desenvolva uma lista de conferência para cada produto que
será revisto.
Atribua recursos e uma programação de tempo para as FTRs.
Realize um treinamento para todos os revisores.
Reveja suas antigas revisões.
Garantia Estatística de Qualidade de Software
• Objetivo
– identificar, estatisticamente, deficiências do processo
que estejam ocasionando erros e corrigi-las.
• Etapas
–
–
–
–
–
coletar dados sobre erros
identificar causas
categorizar as causas
totalizar por categoria
aplicar o Princípio de Pareto
Garantia Estatística de Qualidade de SW
Garantia Estatística de Qualidade de SW
Incomplete or Erroneus Specification
Misinterpretation of Customer Comunication
Intentional Deviation from Specifications
Violation of Programming Standards
Error in Data Representation
Inconsistent Component Interface
Error in Design Logic
Incomplete or Erroneus Testing
Inaccurate or Incomplete Documentation
Error in Programming Language Translation
Inconsistent Human / Coomputer Interface
Miscellaneous
Confiabilidade de Software
TBF
TTR
TTF
• Confiabilidade
– probabilidade de operação livre de falhas em
um dado ambiente por um dado tempo
– MTBF = MTTF + MTTR
• Disponibilidade
– = (MTTF/(MTTF + MTTR) x 100%
BIBLIOGRAFIA
• Capítulo 26, Pressman, R., Engenharia de
Software, 6a edição, McGraw Hill, 2006.
• Yourdon, E., Revisões Estruturadas,
tradução de Structured Walkthroughs, 4a
edição, Editora Campus, 1989