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.
Defeitos Detecção
Erros
Erros que atravessaram
advindos Porcentagem Erros passados
do passo de eficiência para o próximo
anterior Erros amplificados 1:x na detecção passo
de erros
Erros recém gerados

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
2 horas de estudo e
Antes da reunião revisão individual

Cópia Revisor

Produtor Líder do Líder da

Revisor
Produto projeto revisão Cópia
pronto
Cópia 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 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 21
Abordagens Formais para SQA

LINGUAGEM DE PROGRAMAÇÃO
=
Sintaxe e Semântica rigorosas
PROVAS
MATEMÁTICAS
PARA
DEMONSTRAR
A
CORRETUDE
ESPECIFICAÇÃO DOS REQUISITOS
DE SOFTWARE
Desenvolvimento de algo similar

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