Gerência de Desenvolvimento de Sistemas

Garantia da Qualidade de SW

Prof. E.A.Schmitz

Garantia da qualidade do software

Engenharia de software: produção econômica de software de qualidade.

A qualidade está associada:produto: código gerado

processo: de construção do software.

Garantia da qualidade de Software (SQA)

atividade “guarda-chuva”.

Conceitos de qualidade

Controle de variação: atividade de controle de qualidade objetivo é minimizar a variação entre amostras

produzidas em um processo de manufatura. Controle de variação em software?

Minimizar as diferenças entre os recursos estimado para concluir um projeto e os recursos realmente empregados.

Reduzir a variação do número de erros encontrados entre versões.

Reduzir a variação entre do tempos necessários de mudança.

Conceitos de qualidade Dois tipos de qualidade:

qualidade de projeto: refere-se as características de especificação.

qualidade de conformidade: o grau de conformidade do produto segundo sua especificação.

Como se controla a qualidade do software? inspeções, revisões e testes de cada produto obtido ao

longo do processo. ajustes no processo quando o produto criado não atende

suas especificações.

Custos da qualidade1. Custos com prevenção:

planejamento da qualidade, revisões técnicas formais, equipamento de teste e treinamento.

2. Custos de avaliação: manutenção e calibração do equipamento, inspeção do

processo e inter-processo e testes.

3. Custos de falha: Custo interno de falha: erros encontrados antes da

entrega do software para o usuário. Custo externo de falha: defeitos descobertos após o

produto ter sido entregue ao usuário.

Custos de qualidade

Os custos associados as atividades de controle e garantia de qualidade são compensadores quando comparados aos custos de correção de erro após entrega do produto.

O objetivo das atividades de garantia de qualidade é fornecer à gerência dados sobre a qualidade do produto.

Se os dados identificam problemas, compete a gerência abordar os problema e empenhar recursos para resolvê-los.

Total Quality Management Um programa TQM envolve quatro passos

básicos.1. Melhora contínua no processo. O objetivo é desenvolver

um processo que seja visível, repetitivo e mensurável.2. Exame de fatos que afetem o processo visando a

melhora na qualidade do software.3. Exame do uso do produto.4. Busca por oportunidades através da observação do uso

do produto no mercado. Esse passo é orientado ao negócio.

Garantia da qualidade do software

Qualidade do software: Conformidade com os requisitos funcionais e de

performance, com os padrões de desenvolvimento especificados, e características implícitas como um software de boa manutenibilidade e amigável ao usuário.

Garantia da qualidade do software? Padrão de ações planejadas e sistemáticas,

necessárias à garantia de um software de qualidade. Quem é responsável:

Engenheiros de software, gerentes, clientes, pessoal de vendas, e o grupo de SQA (Software Quality Assurance).

Responsabilidades do Grupo SQA

1-Preparação do plano SQA para o projeto contendo: Avaliações a serem realizadas; Auditorias e revisões a serem efetivadas; Critérios de desenvolvimento aplicáveis ao projeto; Procedimentos para relatório e acompanhamento dos

erros; Documentos a serem gerados pelo grupo SQA; e O feedback a ser proporcionado à equipe de software.

Responsabilidades do Grupo SQA

2-Revisão da descrição do processo de software para verificar se está em conformidade com a política organizacional e padrões impostos externamente (ex.: ISO-9001).

3-Revisão das atividades para verificar se estão em conformidade com aquelas definidas no processo de software.

4-Execução de auditorias nos produtos gerados durante o processo de desenvolvimento de software.

5-Assegurar que desvios no trabalho e nos produtos sejam documentados e acompanhados segundo critérios estabelecidos.

6-Registro de qualquer item que não esteja em conformidade com o processo especificado.

7-Coordenação do controle e gerência de mudanças.

Revisões devem ser aplicadas em várias etapas do desenvolvimento de software, visando a descoberta de erros e falhas que possam ser removidas.

O objetivo de uma revisão: descobrir erros durante o processo, antes do software ser

liberado reduzir o número de erros que são passados para uma

outra atividade no processo de software.

O processo de revisão reduz custos: das etapas subsequentes do processo da fase de suporte.

Revisões

Erros daEtapa

Anterior

ErrosPassados para

a PróximaEtapa

Defeitos Detecção

Erros Passados

Erros Amplificados 1 : x

Novos Erros Gerados

Percentualde

Detecçãode Erros

Etapa de Desenvolvimento

Modelo da Amplificação de defeitos

Revisões técnicas formais

Objetivos: Descoberta de erros na função, lógica, ou

implementação; Verificar se o software atende aos requisitos. Garantir que o software tenha sido representado

conforme padrões pré-definidos. Obter softwares que sejam desenvolvidos

uniformemente. Tornar os projetos mais gerenciáveis.

Serve como espaço de treinamento e para promover backup e a continuidade.

Reunião de revisão

ProdutorLíder do projeto

Líder da revisão Revisores

Produto pronto

cópias

Etapas de comunicação para execução de uma FTR.

Reunião de revisão

Restrições à reunião: Entre 3 e 5 pessoas, uma preparação antecipada e duração da

reunião inferior a 2 horas

O foco da reunião FTR é um produto – um componente de software.

Ao final da reunião, os participantes da reunião FRT 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)

Registros da revisão

Lista de questões de revisão:1. Identificar áreas problemáticas do produto.2. Servir como uma lista de conferência que oriente ao

produtor do componente de software quando correções forem feitas.

Relatório de revisão resumido:1. O que foi revisado?2. Quem fez a revisão?3. Quais foram as descobertas e conclusões?

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 da Qualidade de Software

Tendência crescente da indústria de se tornar mais quantitativa em relação à qualidade.

Implica nos seguintes passos: Coletar e categorizar informações a respeito dos defeitos Tentar encontrar a causa de cada defeito Utilizar o princípio Pareto, isolando os 20% (vital few) Corrigir os problemas que tenham causado os defeitos.

Garantia Estatística da Qualidade de Software

Conceito relativamente simples

Representa um importante passo na direção da criação de um processo de engenharia de software adaptativo

Mudanças são feitas para melhorar os elementos do processo que introduzem erros.

Exemplo

Defeitos foram mapeados nas seguintes causas:

Especificação incorreta (IES) Interpretação errônea da comunicação com o

usuário (MCC) Desvio intencional das especificações (IDS) Violação dos padrões (VPS) Erro na representação dos dados (EDR)

Dados coletados

Exemplo

A tabela indica que IES, MCC e EDR são as “causas vitais, que contabilizam 53% de todos os erros. Ou, IES, EDR, PLT e EDL se considerarmos apenas os erros graves.

Uma vez que as causas vitais foram descobertas, ações corretivas podem ser tomadas.

Por exemplo, para corrigir EDR, pode ser adquirida uma ferramenta CASE para a modelagem dos dados além de executar revisões mais rigorosas no design dos dados.

Garantia Estatística da Qualidade de Software

As ações corretivas focam primeiramente as causas vitais. Após a correção destas, as seguintes são elevadas para o topo da lista.

Com essas técnicas, em alguns casos, as empresas tem atingido um percentual de redução de defeitos de 50%.

Índice de Erros

Índice de erros (EI) para cada passo principal do processo de software.

Após a análise, projeto, codificação, teste e distribuição, os seguintes dados são coletados:

Ei = nº de erros encontrados durante o iésimo passo do processo Si = nº de erros graves Mi = nº de erros moderados Ti = nº de erros triviais PS = tamanho do produto (em LOC, pág de documentação, ...) ws, wm, wt = peso aplicado aos tipos de erro

Índice de Erros

Os valores recomendados: wS = 10, wM = 3 e wT = 1

Fatores aumentam nas fases mais adiantadas do processo

A cada fase do processo é calculado um índice (PI) PI = wS (Si / Ei) + wM (Mi / Ei) + wT (Ti / Ei)

O índice de erros: EI = (i x PIi) / PS

= (PI1 + 2PI2 + 3PI3 + ... + iPIi) / PS

Confiabilidade do software

Não há dúvida que confiabilidade de um programa é um elemento importante na sua qualidade geral.

Confiabilidade, ao contrário de outros fatores de qualidade, pode ser mensurada diretamente e estimada utilizando dados históricos e de desenvolvimento.

Em termos estatísticos significa: “a probabilidade de falha em um programa, em um ambiente específico e em um tempo específico.”

Confiabilidade do software –exemplo

Estima-se que o programa X tenha confiabilidade de 0.96, transcorridas 8 horas de processamento.

Isso significa, que se o programa for executado 100 vezes, requerendo 8 horas de execução, irá funcionar corretamente (sem falhas) 96 vezes.

O que significa falha?

No contexto da qualidade e confiabilidade do software, falha significa falta de conformidade com os requisitos de software.

Falhas podem ser catastróficas ou apenas inoportunas. Algumas podem ser corrigidas em segundos e outras em semanas.

A correção de uma falha pode resultar na introdução de outros erros.

Medidas de Confiabilidade e disponibilidade

Trabalhos iniciais em confiabilidade de software tentaram extrapolar a matemática das teorias de confiabilidade de hardware.

A maioria dos modelos relacionados à confiabilidade do hardware são dedicados a falhas devido ao uso, ao invés de falhas devido a defeitos de projeto

Em hardware : falhas devido ao uso físico são mais prováveis do que as relacionadas ao projeto.

Para software, acontece o oposto

Medidas de Confiabilidade - MTBF

“Mean-time-between-failures” (MTBF)

MTBF = MTTF + MTTROnde:

MTTF = mean-time-to-failureMTTF = mean-time-to-repair

Medidas de Confiabilidade - MTBF

Muitos pesquisadores defendem que MTBF é uma medida mais útil do que defeitos por KLOC ou por FP

Exemplo Considere um programa em operação por 14 meses. Muitos erros permaneceram por décadas sem serem

descobertos O MTBF desses erros obscuros é de 50 ou 100 anos O impacto da remoção desses erros na confiabilidade

do software é insignificante.

Medidas de Disponibilidade

É a probabilidade de um programa estar operando de acordo com os requisitos em um determinado momento do tempo

Availability = [MTTF / (MTTF +MTTR)] X 100%