Gerenciamento da Qualidade de Software 3.pptx

Professor Roberto Nunes
Gerenciamento e Qualidade de
Software

TÉCNICAS DE REVISÃO DE SOFTWARE
Uma forma efetiva para melhorar a Qualidade de Software. Devendo ser
aplicadas em vários pontos durante o desenvolvimento do software.
Pode ser vista como uma maneira de usar a diversidade de um grupo de
pessoas para:
• Apontar melhorias necessárias ao produto;
• Confirmar as partes de um produto em que uma melhoria não é
desejada ou não é necessária;
• Realizar um trabalho técnico com uma qualidade mais uniforme de
forma a tornar este trabalho técnico mais administrável.

Defeito de Software
O termo defeito muitas vezes é utilizado de forma genérica.
No entanto, é importante ter em mente que sua interpretação
dependerá do contexto em que ele for utilizado.
Defeitos encontrados através de revisões estarão relacionados às faltas
no artefato sendo revisado.
Quando um defeito se manifesta através de atividades de teste, por sua
vez, estaremos lidando com uma falha no software.
Estas definições seguem a terminologia padrão para Engenharia de
Software do IEEE (IEEE 610.12, 1990):

Defeito de Software
Erro: É um defeito cometido por um indivíduo ao tentar entender uma
determinada informação, resolver um problema ou utilizar um método
ou uma ferramenta.
Defeito (ou Falta): É uma manifestação concreta de um erro num
artefato de software. Um erro pode resultar em diversos defeitos.
Falha: É o comportamento operacional do software diferente do
esperado pelo usuário. Uma falha pode ter sido causada por diversas
faltas e algumas faltas podem nunca causar uma falha.

Defeito de Software
Para obter uma classificação para os defeitos encontrados nas revisões
(as faltas), parte-se do fato de que todos os artefatos gerados durante o
desenvolvimento de software utilizam como base o documento de
requisitos ou artefatos gerados a partir deste.
Desta forma, as classes de defeito seriam os tipos de defeito presentes
em documentos de requisitos acrescidos dos tipos de defeitos
introduzidos pela transformação de artefatos ao longo do
desenvolvimento de software.

Revisões de Software
As revisões são um filtro para o processo de software.
• São aplicadas em vários pontos do processo.
• Servem para descobrir erros e defeitos que podem depois ser removidos.
Diferentes tipos de revisões podem ser conduzidos.
• Conversas informais sobre problemas técnicos.
• Apresentação formal do projeto para uma audiência de clientes e gerência.
• A revisão técnica formal é o filtro mais efetivo para garantia de qualidade.
Tem como objetivo encontrar erros antes que eles sejam passados para outra
atividade ou entregues ao usuário final.

Impacto no custo de defeitos de software
• Estudos da indústria indicam que as atividades de projeto introduzem
entre 50% e 65% de todos os erros durante o processo de software.
• Revisões técnicas formais são 75% efetivas na descoberta de erros de
processo.
- Reduz substancialmente o custo dos passos subsequentes.
- Estudos demonstram que se um erro descoberto na fase de
projeto custa 1 unidade para ser corrigido, este mesmo erro custa 15
unidades depois do teste e entre 60 e 100 unidades depois da entrega .

Amplificação e remoção de defeitos.
• Um modelo de amplificação de defeitos pode ser usado para ilustrar
a geração e a detecção de erros durante os passos do processo.
• Uma caixa representa cada passo do processo.

Revisões Técnicas Formais
A revisão técnica formal (FTR) é uma atividade de SQA realizada por engenheiros de
software.
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.
A FTR também serve como espaço de treinamento e para promover continuidade.
• Cada FTR é conduzida como uma reunião.
Inclui walkthroughs, inspeções, revisões em rodízio e outras avaliações técnicas.

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.
• Maior probabilidade de encontrar erros.
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)depois do teste e entre 60 e 100 unidades depois da entrega .

Reunião de revisão
Antes a reunião
Durante a reunião
• Um dos revisores assume o papel de registrador.
• O produtor faz um “walkthrough” (percorre) do produto de trabalho
e explica o material, enquanto os revisores levantam questões
baseadas na preparação.

Registros de revisão
Durante a FTR, o registrador registra todos os tópicos que foram levantados.
Ao final da reunião, eles são resumidos em dois documentos:
• 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?
• Lista de questões de revisão:
1. Identifica áreas problemáticas do produto.
2. Serve como uma checklist que orienta o produtor à medida que as correções
forem feitas.
O líder da revisão deve fazer um acompanhamento para garantir que os itens
na lista de questões sejam corrigidos.

Diretrizes para a revisão
• Revise o produto, não o produtor.
• Fixe e mantenha uma agenda.
• Limite o debate e a réplica.
• Enuncie as áreas problemáticas, mas não tente resolver cada
problema anotado.
• Tome nota por escrito em um quadro de parede.

Diretrizes para a revisão
• Limite o número de participantes e insista numa preparação
antecipada.
• Desenvolva uma checklist para cada produto que será revisado.
• Atribua recursos e uma programação de tempo para as FTRs.
• Realize um treinamento para todos os revisores.
• Reveja suas primeiras revisões.

Revisões guiadas por amostras
Se o tempo disponível para revisões é curto, uma estratégia razoável é
fazer revisões guiadas por amostras.
Os seguintes passos são sugeridos:
• Inspecione uma fração ai de cada produto de trabalho i. Registre o
número de falhas fi.
• Estime o número total de falhas multiplicando fi por 1 / ai.
• Ordene os produtos de trabalho em ordem decrescente da estimativa
do número de falhas.
• Enfoque os recursos de revisão disponíveis naqueles produtos que
tem o maior número estimado de falhas.
A fração dos produtos amostrada deve ser representativa e significativa.

Abordagens Formais para SQA

Garantias Estatísticas da Qualidade de Software
Tendência crescente da indústria de tornar-se mais quantitativa em
relação à qualidade.
Implica nos seguintes passos:
• Coletar e categorizar informações a respeito dos defeitos.
Ex: falta de conformidade com as especificações, violação dos padrões,
comunicação com o usuário deficiente, etc.
• Tentar encontrar a causa de cada defeito
• Utilizar o princípio de Pareto, isolando os 20%.
80% dos defeitos podem ser mapeados em 20% de todas as causas
possíveis.
• Corrigir os problemas que tenham causado os defeitos.

Garantias Estatísticas 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.
Em resumo:
• Gaste seu tempo melhorando as coisas que realmente importam,
mas tenha certeza que você sabe o que realmente importa.

Seis Sigma para Engenharia de Software
Seis Sigma é a estratégia mais amplamente usada para garantia de
qualidade estatística na indústria.
• Popularizada pela Motorola na década de 1980.
“Seis sigma” = 6σ = 6 desvios-padrão
• 3.4 defeitos por milhão de ocorrências.
• Norma de qualidade extremamente alta.

Seis Sigma para Engenharia de Software
A metodologia Seis Sigma define três passos centrais:
• Defina os requisitos, os artefatos para entrega e os objetivos através
de métodos de comunicação o cliente.
• Meça o processo e sua saída para determinar o atual desempenho de
qualidade.
• Analise métricas de defeito e determine as poucas causas vitais.
Se é necessário aperfeiçoamento são adicionados mais dois passos:
• Aperfeiçoe o processo pela eliminação das causas básicas dos
defeitos.
• Controle o processo para garantir que o trabalho futuro não
reintroduza as causas dos defeitos.

Confiabilidade de Software
Em termos estatísticos confiabilidade significa: “a probabilidade de
operação livre de falhas de um programa, em um ambiente específico,
durante um tempo específico.”
• Falha = não-conformidade com os requisitos.
• Podem ser catastróficas ou apenas inoportunas.
• Podem ser corrigidas em segundos ou em semanas.
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
medida diretamente e estimada utilizando dados históricos e de
desenvolvimento.

Confiabilidade de 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.

Segurança de Software
É uma atividade de garantia de qualidade, que focaliza a identificação e
a avaliação de riscos potenciais, que podem afetar o software
negativamente e causar uma falha de todo o sistema.
Exemplo em um sistema de controle de navegação de um automóvel:
• Aceleração descontrolada, que não pode ser parada.

Segurança de Software
Inicialmente, riscos são identificados e categorizados por criticalidade.
Técnicas de análise são utilizadas para determinar a severidade e
probabilidade de ocorrência dos riscos.
O software deve ser analisado no contexto do sistema como um todo.
• Técnicas de análise como análise de falha em árvore, lógica de tempo
real ou redes de Petri podem ser usadas para prever a cadeia de
eventos que podem causar riscos e a probabilidade de cada evento
ocorrer.

Gerenciamento da Qualidade de Software 3.pptx

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Gerenciamento da Qualidade de Software 3.pptx

Semelhante a Gerenciamento da Qualidade de Software 3.pptx (20)

Gerenciamento da Qualidade de Software 3.pptx