Gerência de Desenvolvimento de Sistemas

Apresentação em tema: "Gerência de Desenvolvimento de Sistemas"— Transcrição da apresentação:

1 Gerência de Desenvolvimento de Sistemas
Garantia da Qualidade de SW Prof. E.A.Schmitz

2 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”.

3 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.

4 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.

5 Custos da qualidade Custos com prevenção: Custos de avaliação:
planejamento da qualidade, revisões técnicas formais, equipamento de teste e treinamento. Custos de avaliação: manutenção e calibração do equipamento, inspeção do processo e inter-processo e testes. 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.

6 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.

7 Total Quality Management
Um programa TQM envolve quatro passos básicos. Melhora contínua no processo. O objetivo é desenvolver um processo que seja visível, repetitivo e mensurável. Exame de fatos que afetem o processo visando a melhora na qualidade do software. Exame do uso do produto. Busca por oportunidades através da observação do uso do produto no mercado. Esse passo é orientado ao negócio.

8 Garantia da 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).

9 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.

10 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.

11 Revisões 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. Dentro do contexto do processo de software, os termos defeito e falha são sinônimos. Ambos representam problemas na qualidade que são descobertos após o software ter sido liberado para o usuário (ou para uma outra atividade no processo de software). O termo erro descreve um problema na qualidade descoberto antes que o software seja liberado para os usuários finais (ou para uma outra atividade no processo de software).

12 Modelo da Amplificação de defeitos

13 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.

14 Reunião de revisão Etapas de comunicação para execução de uma FTR.
Produtor Líder do projeto Líder da revisão Revisores Produto pronto cópias

15 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)

16 Registros da revisão Lista de questões de revisão:
Identificar áreas problemáticas do produto. 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: O que foi revisado? Quem fez a revisão? Quais foram as descobertas e conclusões?

17 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.

18 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.

19 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.

20 Defeitos foram mapeados nas seguintes causas:
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)

21 Dados coletados

22 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.

23 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%.

24 Í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

25 Os valores recomendados: wS = 10, wM = 3 e wT = 1
Í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 + 3PI iPIi) / PS

26 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.”

27 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.

28 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.

29 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

30 Medidas de Confiabilidade - MTBF
“Mean-time-between-failures” (MTBF) MTBF = MTTF + MTTR Onde: MTTF = mean-time-to-failure MTTF = mean-time-to-repair

31 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.

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