Engenharia de Software II

Engenharia de Software II Aula 25 http://www.ic.uff.br/~bianca/engsoft2/ Aula 25-19/07/2006 1

Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software Métricas para software Gestão de projetos de software Conceitos (Cap. 21) Métricas (Cap. 22 Seções 22.1 e 22.2) Estimativas (Cap. 23 Seções 23.1 a 23.7) Cronogramação (Cap. 24) Gestão de risco (Cap. 25) Gestão de qualidade (Cap. 26 Seções 26.1 a 26.7) Gestão de modificações Reengenharia e engenharia reversa Aula 25-19/07/2006 2

Gestão de Qualidade Todos concordam que produzir software de alta qualidade é importante. Mas o que é qualidade de software? Como fazemos para atingí-la? Gestão de qualidade = Garantia de qualidade de software = Software Quality Assurance (SQA) É uma atividade guarda-chuva. Especifica atividades e métricas para aperfeiçoar o processo de software. Aula 25-19/07/2006 3

Conceitos de Qualidade Controle de variação é fundamental para controlar a qualidade. Na produção industrial, controla-se a variação nas características de um produto produzido em série. Na engenharia de software, controla-se a variação no processo genérico que aplicamos. Minimizar a diferença entre os recursos previstos e os recursos usados (pessoal, equipamento e tempo). Minimizar a variância no número de erros de uma versão pra outra. Minimizar as diferenças na velocidade e na precisão de respostas aos problemas de clientes. Aula 25-19/07/2006 4

Conceitos de Qualidade Qualidade = Característica ou Atributo Para um objeto físico, qualidade se refere a características físicas. Comprimento, cor, propriedades elétricas, maleabilidade, etc. O software é informação (não é físico), mas tem propriedades que podemos medir. Complexidade ciclomática, coesão, pontos por função, linhas de código, etc. Aula 25-19/07/2006 5

Conceitos de Qualidade Qualidade de projeto Características que os projetistas especificam para um certo item. Na engenharia de software, abrange os requisitos, as especificações e o projeto. Qualidade de conformidade É o grau com que as especificações de projeto são seguidas durante a fabricação. Aula 25-19/07/2006 6

Conceitos de Qualidade Controle de qualidade Envolve uma série de inspeções, revisões e testes usada ao longo do projeto de software. Garante que cada produto de trabalha satisfaça os requisitos estabelecidos para ele. Inclui um ciclo de realimentação no processo que gerou o produto. Permite ajustar o processo. Todos os produtos de trabalho devem ter especificações mensuráveis para permitir a comparação. Aula 25-19/07/2006 7

Conceitos de Qualidade Garantia de qualidade Conjunto de funções de auditoria e relatório que avaliam a efetividade das atividades de controle de qualidade. Fornece à gerência dados sobre a qualidade do produto. Se os dados identificam problemas, é responsabilidade da gerência aplicar os recursos necessários. Aula 25-19/07/2006 8

Conceitos de Qualidade Custos da qualidade Custos de prevenção Planejamento da qualidade, revisões técnicas formais, equipamento de teste e treinamento. Custos de avaliação Inspeção intra e interprocessos, calibração e manutenção de equipamento e teste. Custos de falha São os que desapareciam se nenhum defeito fosse encontrado. Custos de falha interna Ocorrem antes da entrega e envolvem refazer, reparar e analisar o modo como a falha ocorreu. Custos de falha externa Ocorrem depois da entrega e envolvem solução de queixas e substituição do produto. Aula 25-19/07/2006 9

Garantia da Qualidade de Software Definição de qualidade de software: Conformidade com requisitos funcionais e de desempenho, normas de desenvolvimento explicitamente documentadas e outras características implícitas. A definição enfatiza três pontos importantes: Requisitos: base pela qual a qualidade é medida. Normas: conjunto de critérios que guia o modo pelo qual é submetido. Requisitos implícitos: a qualidade do software é baixa se ele não satisfaz características como facilidade de uso e boa manutenibilidade. Aula 25-19/07/2006 10

Garantia da Qualidade de Software Atividades de SQA Associadas a duas partes diferentes: Engenheiros de software Fazem o trabalho técnico. Aplicam métodos e medidas técnicas sólidas, conduzem revisões técnicas formais e efetuam testes. Grupo SQA Planejamento, supervisão, registro, análise e relato da garantia de qualidade. Deve olhar o software do ponto de vista do cliente. Garante que a qualidade de software é mantida. Aula 25-19/07/2006 11

Garantia da Qualidade de Software Atividades do grupo SQA Prepara um plano SQA para o projeto. Participa no desenvolvimento da descrição do processo de software do projeto. Revê as atividades de engenharia de software para verificar a satisfação do processo de software definido. Audita os produtos de trabalho de software para verificar a satisfação do que foi definido como parte do processo de software. Garante que os desvios do trabalho de software e dos produtos do trabalho sejam documentados e manipulados de acordo com um procedimento documentado. Registra qualquer eventual não-satisfação e a relata à gerência superior. Aula 25-19/07/2006 12

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. Aula 25-19/07/2006 13

Revisões de Software 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 subseqüentes. 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. Aula 25-19/07/2006 14

Revisões de Software 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. Erros advindos do passo anterior Defeitos Erros que atravessaram Erros amplificados 1:x Erros recém gerados Detecção Porcentagem de eficiência na detecção de erros Erros passados para o próximo passo Aula 25-19/07/2006 15

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. Aula 25-19/07/2006 16

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) Aula 25-19/07/2006 17

Reunião de revisão Antes da reunião 2 horas de estudo e revisão individual Cópia Revisor Produtor Produto pronto Líder do projeto Líder da revisão Cópia Cópia Revisor Revisor 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. Aula 25-19/07/2006 18

Registros da 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. Aula 25-19/07/2006 19

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. 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. Aula 25-19/07/2006 20

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 a i de cada produto de trabalho i. Registre o número de falhas f i. Estime o número total de falhas multiplicando f i por 1/a i. 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. Aula 25-19/07/2006 21

Abordagens Formais para SQA LINGUAGEM DE PROGRAMAÇÃO = Sintaxe e Semântica rigorosas ESPECIFICAÇÃO DOS REQUISITOS DE SOFTWARE Desenvolvimento de algo similar PROVAS MATEMÁTICAS PARA DEMONSTRAR A CORRETUDE Aula 25-19/07/2006 22

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. Aula 25-19/07/2006 23

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. Aula 25-19/07/2006 24

Exemplo Uma organização coleta informação sobre defeitos durante um período de um ano. Os defeitos são rastreados até uma das 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) Interface de componente inconsistente (ICI) Erro na lógica do projeto (EDL) Teste incompleto ou errôneo (IET) Documentação imprecisa ou incompleta (IID) Erro na tradução do projeto para a linguagem de programação (PLT) Interface ambígua ou inconsistente (HCI) Miscelânia (MIS) Aula 25-19/07/2006 25

Exemplo: Dados coletados para SQA Estatística Aula 25-19/07/2006 26

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 projeto dos dados. Aula 25-19/07/2006 27

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. Aula 25-19/07/2006 28

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 dsempenho 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. Conhecido como método DMAIC. Aula 25-19/07/2006 29

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. Aula 25-19/07/2006 30

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. Aula 25-19/07/2006 31

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 Para hardware: falhas devidas a desgaste físico são mais prováveis do que as relacionadas a projeto. Efeitos de temperatura, corrosão e choque. Para software, não existe desgaste. Falhas são sempre de projeto. Aula 25-19/07/2006 32

Medidas de Confiabilidade e Disponibilidade Uma medida simples de confiabilidade para sistemas baseados em computador é mean-time-between-failure (MTBF) MTBF = MTTF + MTTR onde MTTF = mean-time-to-failure MTTF = mean-time-to-repair Aula 25-19/07/2006 33

Medidas de Confiabilidade e Disponibilidade 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. Aula 25-19/07/2006 34

Medidas de Confiabilidade e Disponibilidade Somado a medida da confiabilidade, podemos desenvolver uma medida de disponibilidade. É a probabilidade de um programa estar operando de acordo com os requisitos em um dado momento. Disponibilidade = [MTTF / (MTTF +MTTR)] 100% É mais sensível a MTTR que a MTBF. Aula 25-19/07/2006 35

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. Aula 25-19/07/2006 36

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. Aula 25-19/07/2006 37

Segurança de Software Uma vez identificados e analisados os riscos requisitos relacionados à segurança podem ser especificados para o software. Embora confiabilidade e segurança sejam intimamente relacionadas, é importante notar a diferença sutil entre elas. A confiabilidade utiliza análise estatística para determinar a probabilidade de ocorrência de uma falha. Entretanto, essa falha não necessariamente implicará em uma risco ou infortúnio. A segurança examina os meios pelos quais falhas podem resultar em acidentes. Falhas são analisadas no contexto de todo o sistema. Aula 25-19/07/2006 38