fundamentos de engenharia de software gestão de qualidade ou garantia da qualidade de software

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

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 produto

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

Qualidades 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

1

10

100

1000

10000

Requisitos Análise e Projeto Código Teste Produção

Cu

sto

Re

lati

vo d

a C

orr

eç

ão

de

Err

os

Custo do Erro

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 Detecção

Erros advindos do passo anterior Erros que atravessaram

Erros amplificados 1:x

Erros recém-gerados

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)

0 0%

0

10 4 x 1.5 0%

6

25 27 x 3 20%

10

25

0 50%

0 0 50%

0 0 50%

0

Projeto preliminar

Projeto detalhado (x=1.5)

Código/Teste de unidade (x=3)

Teste de integração

Teste de validaçãoTeste de sistema

10 6

437 10

27 94

94 47

24

12

Modelo de Amplificação de Defeitos(com revisões)

0 70%

0

10 1 x 1.5 50%

2

25 10 x 3 60%

5

25

0 50%

0 0 50%

0 0 50%

0

Projeto preliminar

Projeto detalhado (x=1.5)

Código/Teste de unidade (x=3)

Teste de integração

Teste de validaçãoTeste de sistema

3 2

115 5

10 24

24 12

6

3

Diferença de custos

Unidade

Custo para projeto 1,5 22 33 0 0Custo antes do teste 6,5 36 234 22 143Custo durante o teste 15 21 315 82 1230Custo após a entrega 67 3 201 12 804

Total 783 2177

Com Revisão Sem Revisão?

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ão1. 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 SpecificationMisinterpretation of Customer ComunicationIntentional Deviation from SpecificationsViolation of Programming StandardsError in Data RepresentationInconsistent Component InterfaceError in Design LogicIncomplete or Erroneus TestingInaccurate or Incomplete DocumentationError in Programming Language TranslationInconsistent Human / Coomputer InterfaceMiscellaneous

Confiabilidade de Software

• 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%

TTR TTF

TBF

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