engenharia de software ii - instituto de computação -...

Aula 25 - 19/07/2006 1

Engenharia de Software II

Aula 25

http://www.ic.uff.br/~bianca/engsoft2/

Aula 25 - 19/07/2006 2

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 3

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 4

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 5


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


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


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


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


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

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 11


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


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

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 14


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

Erros amplificados 1:x


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

Porcentagem de eficiência na detecção de erros

Erros que atravessaram

Erros recém gerados

Defeitos Detecção

Erros passados para o próximo passo

Erros advindos do passo anterior

Aula 25 - 19/07/2006 16

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 17

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 18

Reunião de revisã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.

Produtor Líder do projeto

Líder da revisão

Revisor

Produto pronto

Cópia

Antes da reunião

Revisor

Revisor

Cópia

Cópia

2 horas de estudo e revisão individual

Aula 25 - 19/07/2006 19

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 20

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 21

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.

Aula 25 - 19/07/2006 22

Abordagens Formais para SQA

LINGUAGEM DE PROGRAMAÇÃO=

Sintaxe e Semântica rigorosas

ESPECIFICAÇÃO DOS REQUISITOS DE SOFTWARE

Desenvolvimento de algo similar

PROVASMATEMÁTICAS

PARADEMONSTRAR

ACORRETUDE

Aula 25 - 19/07/2006 23

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 24

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

Garantias Estatísticas da Qualidade de Software

Aula 25 - 19/07/2006 25

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 26

Exemplo: Dados coletados para SQA Estatística

Aula 25 - 19/07/2006 27

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 28

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 29

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 30

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 31

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 32

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 33


• Uma medida simples de confiabilidade para sistemas baseados em computador é“mean-time-between-failure” (MTBF)

MTBF = MTTF + MTTR

ondeMTTF = mean-time-to-failureMTTF = mean-time-to-repair

Aula 25 - 19/07/2006 34


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


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

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 37


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


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

engenharia de software ii - instituto de computação -...

Documents