Aula 3 - Controle da Qualidade de Produtos de Software

Prévia do material em texto

Parte 3 – Controle da 
Qualidade de Produtos de 
Software
Prof. David Zanetti
 3 vertentes:
 Garantia da Qualidade (Qualidade de Produto/Processo)
 Verificação (Qualidade de Produto)
 Validação (Qualidade de Produto)
Qualidade de Software
 Qualidade de Software:
 Produtos precisam respeitar um conjunto mínimo de 
requisitos.
 Conformidade com especificações e padrões de 
desenvolvimento documentados.
 Atendimento das necessidades dos usuários.
 Que necessidades? Que usuários?
Garantia da Qualidade
 Garantia de Qualidade do Software:
 Mecanismo sistemático que assegura que padrões, práticas, 
procedimentos e métodos do processo são efetivamente utilizados.
 Atividades técnicas aplicadas durante todo o processo de 
desenvolvimento.
 Objetivo: garantir que o processo de desenvolvimento e o produto 
de software atinjam níveis de qualidade especificados (mínimos).
Garantia da Qualidade
Garantia da Qualidade
 Envolve:
 Avaliar a conformidade dos processos e dos produtos.
 Registrar os problemas encontrados.
 Comunicar e acompanhar a resolução desses problemas
 Relatar os resultados destas atividades à alta gerência.
 Apoiar a equipe no seguimento ao processo e aos padrões de qualidade da 
organização.
 Identificar tendências de qualidade nos processos e nos produtos.
 Instrumento: Checklist
Exemplos
 Critérios para Especificação de Requisitos:
 Foi elaborada a especificação de requisitos? ( ) Sim ( ) Não
 Foi utilizada a ultima versão do template? ( ) Sim ( ) Não
 O preenchimento está completo? ( ) Sim ( ) Não
 Todos os requisitos possuem associação? ( ) Sim ( ) Não
 .....
Verificação X Validação
 Verificação
 Processo de avaliação de um software ou produto intermediário
para determinar se satisfaz ao que foi requerido nas especificações 
internas.
 Estamos desenvolvendo o produto corretamente?
 Validação
 Processo de avaliação de um software ou produto intermediário, 
durante ou após o desenvolvimento, para determinar se satisfaz 
aos requisitos do cliente/usuário.
 Estamos desenvolvendo o produto correto?
Verificação
Validação
Comparativo
Garantia da 
Qualidade
Verificação Validação
• Garantia da qualidade • Controle da qualidade • Controle da qualidade
• Avalia se os processos
estão sendo seguidos.
• Avalia o formato dos 
planos e demais produtos.
• Avalia o conteúdo dos 
produtos com relação aos 
requisitos especificados.
• Avalia o entendimento/ 
funcionamento do produto 
com relação ao ambiente 
para o qual foi 
desenvolvido.
• Avaliação de 
conformidade
• Teste
• Revisão por par
• Aprovação
• Testes de Aceitação
• Grupo de garantia da 
qualidade
• Especialista com 
conhecimento específico
• Membro da equipe do 
projeto com perfil 
semelhante
• Cliente
• Equipe independente do 
projeto
• Hierarquia adequada
• Equipe do projeto -
Verificação e Validação
 Métodos:
 Análise Estática:
 Revisões de Software.
 Análise Dinâmica:
 Testes de Software.
Verificação e Validação
 Análise Estática
 Não envolve a execução do produto
 Determinar propriedades do produto válidas para qualquer execução do 
produto final
 Exemplos:
 Inspeção automática de código
 Revisões Técnicas ou Revisões por Pares
 Inspeção de Código:
 Ferramentas que varrem o código fonte à procura de falhas e anomalias
 São um complemento muito útil para a inspeção
 Tipos de checagem:
 falhas de dados
 falhas de controle
 falhas de E/S
 falhas de interface
 falhas de armazenamento
Análise Estática
 Falha de dados
 Como são usadas as variáveis do programa?
 variáveis usadas antes de serem inicializadas
 variáveis declaradas mas que nunca são utilizadas
 variáveis definidas duas vezes mas não utilizadas nenhuma vez 
entre as duas definições
 possibilidade de índice fora de limites para arrays
 variáveis não declaradas
Análise Estática
 Falhas de controle
 trechos de código não alcançáveis
 desvio para interior de laços
 Falhas de entradas/saída:
 variáveis são usadas em comandos de saída duas vezes sem 
que seu valor seja alterado entre uma e outra
Análise Estática
 Falhas de interface
 Uso de rotinas é consistente com sua declaração?
 tipos de parâmetros incompatíveis
 número de parâmetros incompatível
 valor de retorno de funções não é utilizado
 funções ou procedimentos não são chamados
 Falhas de armazenamento
 apontadores não inicializados
 aritmética de apontadores
Análise Estática
Verificação e Validação
 Análise Dinâmica
 Envolve a execução do produto (código ou modelo executável)
 Visa a encontrar falhas ou erros no produto
 Exemplos:
 Simulação
 Execução simbólica
 Testes
Defeito, Erro e Falha
 Defeito Erro Falha
 Defeito: 
 Deficiência mecânica ou algorítmica que se ativada pode levar a uma falha.
 Erro: 
 Item de informação ou estado de execução inconsistente.
 Falha:
 Evento notável onde o sistema viola suas especificações.
Defeito, Erro e Falha
Defeito, Erro e Falha
 Maior parte é de origem humana.
 Gerados na comunicação e transformação da 
informação.
 Maior parte em partes do software raramente utilizadas 
e/ou executadas.
Defeito, Erro e Falha
 Principal causa: 
 tradução incorreta de 
informações.
 Quanto antes a presença do defeito for revelada, menor o custo
de correção do defeito e maior a probabilidade de corrigi-lo
corretamente.
 Solução:
 Introduzir atividades de VV&T ao longo de todo o ciclo de
desenvolvimento.
Revisões de Software
 Processo de leitura de um produto intermediário do processo de 
software para garantir que ele cumpre sua especificação e atende às 
necessidades de seus usuários.
 Objetivo:
 Realizar validação e verificação estática de artefatos de software.
 Pode ser aplicada a qualquer artefato produzido ao longo do 
processo de desenvolvimento de software.
Revisões de Software
 Aumentam a probabilidade de defeitos serem 
encontrados.
 Independência dos revisores.
 Avaliação objetiva e sem conflitos de interesse.
Revisões de Software
 Quando e em que tipos de artefato aplicar revisões de 
software?
Revisões de Software
 Tipos de Revisão de Software:
 4.1 – Inspeções de Software.
 4.2 – Walkthroughs.
Inspeções
 Tipo de revisão de software mais estudado e utilizado
 Processo rigoroso e bem definido.
 Evidências Experimentais:
 Redução do Esforço 
 Aumento da Produtividade
 Redução do Tempo
 Redução dos Custos
 Capturam em média 60% dos defeitos
Walkthrough
 Processo menos rigoroso que inspeções de software.
 Papéis sugeridos:
 Líder, Autor, Escrivão e Revisores
 Procedimento:
 Participantes são guiados através dos artefatos pelo líder (que eventualmente é o próprio autor) em 
uma reunião. 
 Reunião devem interromper a apresentação caso encontrem defeitos. 
 Muitas vezes condições de entrada e saída e decisões são pressupostos pelo líder que segue sua 
linha de raciocínio durante a apresentação.
Walkthrough
 Custo igual ao de inspeções mas resultados inferiores:
 Medidas
 Não fornecem base para a aplicação de controle estatístico
 Utilizados para brainstorming, explorar alternativas de 
projeto e resolução de problemas. 
 Inspeções são mais focadas em encontrar defeitos.