Buscar

Introdução à Engenharia de Software

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

introdução à engenharia de software/sliders prova 2/IEC993-Aula24-testes.pdf
18/02/2014
1
IEC993 – INTRODUÇÃO À ENGENHARIA DE
SOFTWARE – 2013/2 
TESTES DE SOFTWARE
D.Sc. Arilo Claudio Dias Neto
arilo@icomp.ufam.edu.br
72
Arilo Claudio Dias Neto
Análise do Valor Limite
 Por razões não completamente identificadas, um grande
número de erros tende a ocorrer nos limites do domínio
de entrada invés de no “centro”
 Análise do Valor Limite é uma técnica de teste que explora
os limites dos valores para preparar os casos de teste
 Está técnica complementa o particionamento em classes
de equivalência
18/02/2014
2
Arilo Claudio Dias Neto
Análise do Valor Limite
 Um dos critérios de teste mais básico que existe.
 Auxilia na seleção de um pequeno subconjunto de casos de teste que
mantém um boa cobertura do código.
 Exemplo (mesmo usado para particionamento por equivalência)
◦ Observe que os limites, tal como o 16, aparece em duas classes de equivalência.
◦ O mesmo ocorre com o 18 e o 55.
Arilo Claudio Dias Neto
Análise do Valor Limite
 As condições anteriores, na verdade, deveriam ser
escritas como:
◦ Na primeira regra, 16 não deve ser incluído.
◦ Na segunda, 16 pode ser empregado em tempo parcial.
18/02/2014
3
Arilo Claudio Dias Neto
Análise do Valor Limite
 A implementação abaixo implementa as regras:
VALORES LIMITES:
•REGRA 1 (não empregar): Inferior (-1 e 0) e Superior (15 e 16)
•REGRA 2 (parcial): Inferior (15 e 16) e Superior (17 e 18)
•REGRA 3 (integral): Inferior (17 e 18) e Superior (54 e 55)
•REGRA 4 (não empregar): Inferior (54 e 55) e Superior (99 e 100)
Arilo Claudio Dias Neto
Análise do Valor Limite
 Passos de Aplicação
1. Identificar as classes de equivalência.
2. Identificar os limites de cada classe.
3. Criar casos de teste para os limites escolhendo:
◦ Um ponto abaixo do limite inferior.
◦ O limite inferior.
◦ O limite superior.
◦ Um ponto acima do limite superior.
4. Observe que “acima” e “abaixo” são termos relativos e dependente do valor
dos dados.
◦ Números inteiros: limite = 16; abaixo = 15; acima = 17.
◦ Números reais: limite = $5,00; abaixo = $4,99; acima = $5,01.
 Se os valores fora da classe invadem “outra” classe, não precisamos repeti-
los
18/02/2014
4
Arilo Claudio Dias Neto
Análise do Valor Limite
Arilo Claudio Dias Neto
Análise do Valor Limite: Exemplo
 Consideremos a seguinte situação:
◦ "... o cálculo do desconto de IR por dependente é feito da seguinte forma:
 A entrada é a idade do dependente que deve estar restrita ao intervalo [0..24].
 Para dependentes até 12 anos (inclusive) o desconto é de 15%.
 Entre 13 e 18 (inclusive) o desconto é de 12%.
 Dos 19 aos 21 (inclusive) o desconto é de 5%;
 e dos 22 aos 24 de 3%..."
◦ Aplicando o teste de valor limite convencional serão obtidos casos de teste
semelhantes a este:
 (-1 {inválido}, 0 {15%}, 12 {15%}, 13 {12%}, 18 {12%}, 19 {5%}, 21 {5%}, 22 {3%}, 24
{3%}, 25 {0%})
18/02/2014
5
Arilo Claudio Dias Neto
Análise do Valor Limite: Exercício
 Teste um programa que calcula o índice de massa
corporal (IMC) de uma pessoa, através da fórmula
IMC = peso / altura2. Para o resultado, considere a
tabela a seguir:
Condição IMC em Mulheres IMC em Homens
abaixo do peso < 19,1 < 20,7
no peso normal 19,1 – 25,8 20,7 - 26,4
marginalmente acima do peso 25,9 – 27,3 26,5 - 27,8
acima do peso ideal 27,4 – 32,3 27,9 - 31,1
obeso > 32,3 > 31,1
Arilo Claudio Dias NetoArilo Claudio Dias Neto
Análise do Valor Limite: 
Exercício
(Resposta)
HOMEM MULHER
 20,6: Abaixo
 20,7 : Normal
 26,4 : Normal
 26,5: Marginalmente Acima
 27,8: Marginalmente Acima
 27,9 : Acima
 31,1: Acima
 31,2: Obeso
 19,0: Abaixo
 19,1 : Normal
 25,8 : Normal
 25,9: Marginalmente
 27,3: Marginalmente
 27,4 : Acima
 32,3: Acima
 32,4: Obeso
81
18/02/2014
6
Arilo Claudio Dias Neto
Análise do Valor Limite: Exercício
(Resposta)
 E quais casos de teste testam essas condições?
82
ID SEXO PESO ALT RESULTADO
1 H 20,6
2 H 20,7
3 H 26,4
4 H 26,5
5 H 27,8
6 H 27,9
7 H 31,1
8 H 31,2
Arilo Claudio Dias Neto
Análise do Valor Limite: Exercício
(Resposta)
 E quais casos de teste testam essas condições?
83
ID SEXO PESO ALT RESULTADO
1 M 19,0
2 M 19,1
3 M 25,8
4 M 25,9
5 M 27,3
6 M 27,4
7 M 32,3
8 M 32,4
18/02/2014
7
Arilo Claudio Dias Neto
Análise do Valor Limite
 Limitação em testes baseados em partições
de equivalência ou análise de valores-
limite:
◦ consideram cada valor de entrada isoladamente
 ... e se existirem combinações de valores
que constituam situações interessantes a
serem testadas?
Arilo Claudio Dias Neto
Grafo de Causa-Efeito
 Critério necessário quando se deseja testar
combinações de entradas
 Utiliza tabelas de decisão e árvores de
decisão
◦ grafo causa-efeito como modelo auxiliar
 Técnica para identificação de casos de teste
que explora as condições lógicas e as ações
correspondentes
18/02/2014
8
Arilo Claudio Dias Neto
Grafo de Causa-Efeito
Para cada módulo, Causas (condições de entrada) e efeitos 
(ações realizadas às diferentes condições de entrada) são 
relacionados, atribuindo-se um identificador para cada um.
Em seguida, um grafo de causa-efeito (árvore de decisão) é 
desenhado. 
Neste ponto, transforma-se o grafo numa tabela de decisão. 
As regras da tabela de decisão são, então, convertidas em 
casos de teste. 
Arilo Claudio Dias Neto
Grafo de Causa-Efeito
 Definições
◦ Causas: condições de entrada (valor lógico)
◦ Efeitos: ações realizadas em resposta às
diferentes condições de entrada
 Exemplo:
◦ causa: preço ≥ 50 & 0 ≤ qtd ≤ 99 (restrição do sistema)
◦ efeito: fornecer 5% de desconto
18/02/2014
9
Arilo Claudio Dias Neto
Árvore de Decisão
Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99
Efeito: fornecer 5% de desconto
qtd
preço
Preço normal
Desconto
Mensagem de erro
Arilo Claudio Dias Neto
Tabela de Decisão
18/02/2014
10
Arilo Claudio Dias Neto
Construção da Tabela de Decisão
Causas
Efeitos
Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99
Efeito: fornecer 5% de desconto
Arilo Claudio Dias Neto
Construção da Tabela de Decisão
Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99
Efeito: fornecer 5% de desconto
Causas
Preço ≥ 50
0 ≤ Qtd ≤ 99
Efeitos
18/02/2014
11
Arilo Claudio Dias Neto
Construção da Tabela de Decisão
Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99
Efeito: fornecer 5% de desconto
Causas
Preço ≥ 50
0 ≤ Qtd ≤ 99
Efeitos
Fornecer desconto
Valor normal
Mensagem de Erro
Arilo Claudio Dias Neto
Construção da Tabela de Decisão
Causas
Preço ≥ 50 V F V F
0 ≤ Qtd ≤ 99 V V F F
Efeitos
Fornecer desconto
Valor normal
Mensagem de Erro
Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99
Efeito: fornecer 5% de desconto
18/02/2014
12
Arilo Claudio Dias Neto
Construção da Tabela de Decisão
Causas
Preço ≥ 50 V F V F
0 ≤ Qtd ≤ 99 V V F F
Efeitos
Fornecer desconto
Valor normal
Mensagem de Erro
Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99
Efeito: fornecer 5% de desconto
Arilo Claudio Dias Neto
Construção da Tabela de Decisão
Causas
Preço ≥ 50 V F V F
0 ≤ Qtd ≤ 99 V V F F
Efeitos
Fornecer desconto
Valor normal
Mensagem de Erro
Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99
Efeito: fornecer 5% de desconto
18/02/2014
13
Arilo Claudio Dias Neto
Construção da Tabela de Decisão
Causas
Preço ≥ 50 V F V F
0 ≤ Qtd ≤ 99 V V F F
Efeitos
Fornecer desconto
Valor normal
Mensagem de Erro
Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99
Efeito: fornecer 5% de desconto
Arilo Claudio Dias Neto
Construção da Tabela de Decisão
Causas
Preço ≥ 50 V F V F
0 ≤ Qtd ≤ 99 V V F F
Efeitos
Fornecer desconto
Valor normal
Mensagem de Erro
Causa: preço ≥ 50 & 0 ≤ qtd ≤ 99
Efeito: fornecer 5% de desconto
18/02/2014
14
Arilo Claudio Dias Neto
Limitação das Tabelas de Decisão
 Tamanho!
◦ nº de regras = 2N, onde N é o nº de causas
Arilo Claudio Dias Neto
Geração de testes
 Tabela de decisão
◦ critério: exercitar cada regra pelo menos 1 vez
 Árvore de decisão
◦ critério: exercitar cada caminho da raiz até a
folha pelo menos 1 vez
99
18/02/2014
15
Arilo Claudio Dias Neto
Exemplo
 Supor um sistema bancário que trate somente duas
transações:
◦ depósito nº da conta quantia
◦ saque nº da conta quantia
 Requisitos:
◦ se o comando é depósito e o nº da conta é válido então a quantia é
depositada
◦ se o comando é saque e o nº da conta é válido e a quantia é válida
(0 < quantia ≤ saldo) então a quantia sacada
◦ se o comando ou nº da conta ou a quantia for inválido então exibir
mensagem de erro apropriada
100
Arilo Claudio Dias Neto
Exemplo
 Causas:
◦ c1. Comando é depósito
◦ c2. Comando é saque
◦ c3. Nº da conta é válido
◦ c4. Quantia é válida
 Efeitos:
◦ e1. Exibir “comando inválido”
◦ e2. Exibir “nº da conta inválido”
◦ e3. Exibir “quantia inválida”
◦ e4. Depositar a quantia
◦ e5. Sacar a quantia
101
Nº de regras = 24 = 16
Será que todas interessam?
18/02/2014
16
Arilo Claudio Dias Neto
Exemplo
 Grafo de Causa-Efeito:
102
comando
conta
Conta inválida
Quantia Depositada
inválida
Comando inválido
saque conta
Conta inválida
quantia
Saque 
realizado
Quantia 
inválida
Arilo Claudio Dias Neto
Exemplo
 Tabela de decisão:
103
Causas
Comando é depósito
Comando é saque
Nº da conta é válido
Quantia é válida
Efeitos
comando inválido
nº da conta inválido
quantia inválida
Depositar a quantia
Sacar a quantia
18/02/2014
17
Arilo Claudio Dias Neto
Exemplo
 Tabela de decisão:
104
Causas
Comando é depósito F V V
Comando é saque F V V V
Nº da conta é válido F V F V V
Quantia é válida F V
Efeitos
comando inválido x
nº da conta inválido x X
quantia inválida X
Depositar a quantia X
Sacar a quantia X
Arilo Claudio Dias Neto
Grafo Causa-Efeito: Exercício
 Considere uma função com duas variáveis de entrada: Cliente e Qtd, e
uma variável de saída, Desconto. Cliente pode ser do tipo A, B ou C e
Qtd pode variar de 1 a 1000. A função calcula Desconto de acordo
com as seguintes regras:
◦ Clientes do tipo A não recebem desconto se nº de itens comprados for
inferior a 10; recebem 5% desconto para compras entre 10 e 99 itens; 10%
de desconto a partir de 100 itens.
◦ Clientes do tipo B recebem 5% de desconto para compras abaixo de 10
itens; 15% de desconto entre 10 e 99 itens; 25% de desconto a partir de
100 itens.
◦ Clientes do tipo C não recebem desconto se nº de itens comprados for
inferior a 10; 20% de desconto entre 10 e 99 itens; 25% de desconto a
partir de 100 itens.
18/02/2014
18
Arilo Claudio Dias Neto
Teste de Software
 Diferente tipos de aplicações (ex: 00, aplicações web, software
embarcados) possuem características específicas
◦ Isso impacta nas atividades desenvolvimento e testes
 Técnicas diferenciadas para desenvolvimento e testes
 Por exemplo, Software Orientado a Objetos:
◦ trabalha com o encapsulamento das estruturas de informações e seus
comportamentos
◦ Não existe um fluxo de execução definido para o software
◦ utiliza um modelo homogêneo para representação do software
introdução à engenharia de software/sliders prova 2/IEC993-Aula20-projeto.pdf
05/02/2014
1
IEC993 – INTRODUÇÃO À ENGENHARIA DE
SOFTWARE – 2013/2
PROJETO E MODELAGEM DE SOFTWARE
D.Sc. Arilo Claudio Dias Neto
arilo@icomp.ufam.edu.br
1
Arilo Claudio Dias Neto
Da Análise ao Projeto
Elicitação
de 
Requisitos
Análise do 
Sistema
Projeto Codificação
Executar 
Testes
A análise se concentra na questão "O quê?"
•Objetivo é prover um entendimento dos requisitos,
conceitos e operações relacionados a um sistema
05/02/2014
2
Arilo Claudio Dias Neto
Da Análise ao Projeto
•A próxima fase é a de Projeto, onde a questão
"Como?" é abordada
Elicitação
de 
Requisitos
Análise do 
Sistema
Projeto Codificação
Executar 
Testes
Arilo Claudio Dias Neto
Projeto de Software
 O que é?
◦ Conjunto de princípios, conceitos e práticas técnicas que levam ao
desenvolvimento de um sistema com qualidade
◦ É o lugar em que a criatividade impera!
◦ Cria uma representação ou modelo de software que fornece
detalhes sobre a estrutura dos dados, arquitetura, interface e
componentes do software
 Quem faz?
◦ Arquiteto ou projetista
4
05/02/2014
3
Arilo Claudio Dias Neto
Projeto de Software
 Importância do Projeto
“ ... tentamos resolver o problema passando 
rapidamente pelo projeto (design) para que sobre 
tempo suficiente no final para detectar e corrigir 
defeitos que foram introduzidos porque 
dedicamos pouco tempo ao projeto.”
Arilo Claudio Dias Neto
Projeto de Software
• Transforma elementos estruturais da arquitetura de 
software em uma descrição dos componentes
Projeto em 
Nível de 
componente
• Descreve como o software se comunica 
com outros sistemas e com seus usuários
Projeto de 
Interface
• Define o relacionamento entre os 
principais elementos estruturais do 
software, estilos arquiteturais e 
padrões de projeto
Projeto Arquitetural
• Transforma modelo de 
análise em classes de 
projeto e nas estruturas de 
dados dos requisitos
Projeto de dados/classes
6
05/02/2014
4
Arilo Claudio Dias Neto
Projeto de Software
 “Há dois modos de construir um projeto de
software: um é fazê-lo tão simples que
obviamente não haja deficiências, o outro é
fazê-lo tão complicado que não haja
deficiências óbvias.
 O primeiro modo é muito mais difícil.”
C.A.R. Honre
7
Arilo Claudio Dias Neto
Projeto de Software
 Conceitos de Projeto de Software
◦ Abstração
 É um dos modos fundamentais pelos quais nós, seres
humanos, enfrentamos a complexidade
◦ Arquitetura
 Estrutura global do software, representada por modelos
◦ Padrão
 Descreve um problema que ocorre repetidas vezes em
nosso ambiente, e então descreve o núcleo de solução
daquele problema
8
05/02/2014
5
Arilo Claudio Dias Neto
Projeto de Software
 Conceitos de Projeto de Software
◦ Modularidade
 Divisão do software em componentes nomeados
separadamente e endereçáveis
◦ Ocultamento de Informações
 Definição e imposição de restrições de acesso aos módulos
de um sistema
◦ Independência Funcional
 Consequência
da modularidade e ocultamento de
informações
 Desenvolvimento de módulos independentes
9
Arilo Claudio Dias NetoArilo Claudio Dias Neto
PROJETO DE 
DADOS/CLASSES
Modelagem conceitual
10
05/02/2014
6
Arilo Claudio Dias Neto
Modelagem Conceitual
 A Modelagem de Dados Conceitual é a
etapa responsável pela identificação dos
requisitos de informação no negócio e pela
estruturação do banco de dados em um
nível lógico.
Arilo Claudio Dias Neto
Modelagem Conceitual
 Utilizaremos o diagrama de classes da UML
como ferramenta para desenhar o modelo
de dados conceitual do sistema que
desejamos projetar.
05/02/2014
7
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 Utilizado na construção do modelo de classes, desde o nível de
análise até o nível de especificação
 É o diagrama mais rico da UML, em termos de notação
 É o diagrama mais utilizado da UML
 Pode ser mapeado diretamente para uma linguagem OO
 Ajuda no processo transitório dos requisitos para o código
 Pode representar visualmente o código do sistema
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 Diagrama de casos de uso:
◦ Fornece uma perspectiva do sistema do ponto
de vista Externo
 Diagrama de Classes
◦ Visão interna: descrição do funcionamento
interno do software
◦ Dois aspectos internos: dinâmico e estrutural
estático
05/02/2014
8
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 Aspecto Estrutural Estático:
◦ Permite compreender como o sistema está estruturado
internamente, para que as funcionalidades
externamente visíveis sejam produzidas.
◦ Estático: Não apresenta informações de como os
objetos interagem no decorrer do tempo
◦ Estrutural: Representação da estrutura das classes e de
suas relações
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 Aspecto Dinâmico:
◦ Descreve a troca de mensagens entre os
objetos, e a sua reação a eventos que ocorrem
no sistema. É realizada pelas modelagens de
interação e de estados.
05/02/2014
9
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 À medida que o sistema é desenvolvido, o modelo
de classes é incrementado com novos detalhes.
 Ele evolui em três níveis de abstração:
◦ Modelo de classes de domínio
◦ Modelo de classes de especificação
◦ Modelo de classes de implementação
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 Modelo de classes de domínio
◦ Construído na fase de análise
◦ Representa as classes no domínio do negócio em
questão
◦ Não leva em consideração aspectos inerentes à
tecnologia de implementação (tecnologia perfeita e
custo zero)
05/02/2014
10
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 Modelo de classes de especificação
◦ Construído na fase de projeto
◦ Adiciona ao modelo de classes de domínio detalhes
específicos, conforme a solução de software escolhida
◦ Pode definir novas classes necessárias para desenvolver
a solução do problema
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 Modelo de classes de implementação
◦ Estende o modelo de classes de especificação
◦ Corresponde à implementação das classes em
alguma linguagem de programação
05/02/2014
11
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 Classe: grupo de objetos semelhantes.
 Uma classe descreve esses objetos através de
atributos e operações.
◦ Os atributos correspondem às informações que um
objeto armazena.
◦ As operações correspondem às ações que um objeto
sabe realizar.
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 A 1Km de distância...
◦ Caixas representando as classes
◦ Linhas representando os relacionamentos
05/02/2014
12
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 A 1metro de distância...
◦ As classes são representadas por caixas contendo:
 Nome (obrigatório)
 Lista de atributos
 Lista de operações
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 A 1cm de distância dos atributos...
◦ Atributos são descritos via
 Visibilidade
 Nome
 Tipo
 Multiplicidade
 Valor padrão
05/02/2014
13
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 A 1cm de distância das associações...
◦ Guarda as mesmas informações dos atributos
◦ Utiliza uma notação gráfica
◦ Deve ser utilizado para propriedades que são relevantes ao
diagrama
◦ Determina o papel das classes na associação
◦ Tipos: Generalização, Composição, Agregação, Dependência e
Classe de Associação
Arilo Claudio Dias Neto
Diagrama de Classes da UML
Dicas:
 Inicie com um diagrama simples
 O que normalmente tem em todo diagrama
◦ Classes
◦ Atributos
◦ Operações
◦ Associações
 Use os demais recursos da linguagem somente quando for
realmente necessário
05/02/2014
14
Arilo Claudio Dias Neto
Diagrama de Classes da UML
Dicas: Possíveis candidatos à classes
 Entidades externas que produzem ou consomem informações
(ex.: sistema de validação do cartão de crédito)
 Conceitos que são parte do problema e que são informações
compostas (ex.: Produto)
 Eventos que ocorrem durante a operação do sistema (ex.:
Pedido)
 Papéis que interagem com o sistema (ex.: Cliente)
 Unidades organizacionais relevantes (ex.: Rede de lojas)
 Lugares que fornecem o contexto do problema ou do sistema
(ex.: Loja)
 Estruturas definidas no problema (ex.: Estoque)
Arilo Claudio Dias Neto
Diagrama de Classes da UML
Dicas: Possíveis candidatos a:
 Atributos
◦ Informação primitiva que precisa ser memorizada (ex.: Preço)
 Associações
◦ A classe A precisa se relacionar com a classe B para atender a
operações específicas (ex.: Cliente – Pedido)
 Operações
◦ Funcionalidades que devem ser providas por uma classe para
viabilizar o uso do sistema (ex.: calculaTotal em Pedido)
05/02/2014
15
Arilo Claudio Dias Neto
Diagrama de Classes da UML
 Exemplo
Arilo Claudio Dias NetoArilo Claudio Dias Neto
PROJETO 
ARQUITETURAL
30
05/02/2014
16
Arilo Claudio Dias Neto
Projeto de uma arquitetura
 O que é um projeto arquitetural?
◦ Decisões estratégicas que terão consequências profundas
◦ As decisões são tomadas num alto nível
 Observe que sempre deve-se ter um olho na
satisfação dos requisitos levantados
◦ Principalmente requisitos NÃO-FUNCIONAIS!!!
Arilo Claudio Dias Neto
Projeto de Alto Nível
 Os modelos de projeto arquitetural devem:
◦ Especificar a decomposição do sistema em subsistemas
(modelo da arquitetura do sistema)
◦ Mostrar o relacionamento entre os subsistemas (modelo
de controle do sistema)
◦ Decompor os subsistemas em módulos (modelo da
arquitetura dos módulos)
05/02/2014
17
Arilo Claudio Dias Neto
Projeto de uma arquitetura
 Exemplos de decisões:
◦ Modularização do projeto em subsistemas
◦ Escolha da divisão de trabalho entre membros de uma
equipe ou entre equipes de desenvolvimento
◦ Definição das interfaces entre subsistemas para
possibilitar o trabalho paralelo de desenvolvimento
◦ Escolha de uma estratégia de persistência, incluindo
SGBD
◦ Determinação de oportunidades para reuso de software
◦ Atendimento a requisitos não-funcionais
Arilo Claudio Dias Neto
Modularização
 Característica do software
que permite a sua
inteligibilidade, permite dividi-lo em componentes
menores, chamados módulos.
 Leva a um esforço menor para resolver problemas
C(x)=complexidade do problema
E(x)=esforço para resolver o problema
C(P1) > C(P2) E(P1) > E(P2)
C(P1+P2) > C(P1)+C(P2)  E(P1+P2)>E(P1) + E(P2)
 Como saber se eu dividi o suficiente?
05/02/2014
18
Arilo Claudio Dias Neto
Decomposição do sistema: partições 
e camadas
 Lembre que subsistemas devem ser coesos (trata de
responsabilidades fortemente relacionadas)
◦ Tem forte acoplamento dentro de um subsistema
◦ Tem fraco acoplamento entre subsistemas
 Para minimizar o acoplamento, camadas frequentemente se
comunicam apenas com as camadas "vizinhas“
 Decomposição pode terminar quando atingir subsistemas com temas
claros que sejam simples de entender
 Alguns sistemas muito pequenos não necessitam de camadas e
partições
Arilo Claudio Dias Neto
Coesão e Acoplamento
 Coesão: medida da funcionalidade de um
módulo; o quanto ele realiza uma tarefa específica
◦ Deve ser maximizado
 Acoplamento: mede o grau de interdependência
entre módulos
◦ Deve ser minimizado
05/02/2014
19
Arilo Claudio Dias Neto
Arquiteturas em N camadas
 Para sistemas de informação que incluam uma
interface com o usuário e persistência (isto é,
quase todos!), usa-se frequentemente
uma arquitetura em 3 camadas
Arilo Claudio Dias Neto
Arquiteturas em N camadas
 As camadas verticais são:
◦ Apresentação: janelas, relatórios, etc.
 Também chamada de Camada de Interface/Serviço com o
Usuário
◦ Lógica da Aplicação: tarefas e regras que governam o
processo
 Também chamada de Camada de Aplicação
◦ Dados: mecanismo de armazenamento persistente
 Também chamada de Camada de Gerência de Dados ou Camada
de Armazenamento
05/02/2014
20
Arilo Claudio Dias Neto
Arquiteturas em N camadas
 Arquitetura em 3 camadas permite:
◦ Usar o browser como cliente universal, levando ao
conceito de Intranet
◦ Evitar instalação em computadores de clientes,
parceiros, fornecedores, etc.
◦ Implementar serviços automáticos de persistência,
tolerância a falhas com failover, gerência de transações,
balanceamento de carga, resource pooling, etc.
 Enterprise JavaBeans, COM+
Arilo Claudio Dias Neto
Uso de UML para modelar a 
arquitetura
 UML provê diagramas que possibilitam
representar a estrutura ou comportamento de
sistemas
 Notação que pode ser usada para representar a
arquitetura do software
05/02/2014
21
Arilo Claudio Dias Neto
UML – Breve Revisão
 Significa Linguagem de Modelagem Unificada;
 Notação para especificação de sistemas;
 Surgiu nos anos 1990s como um esforço para
reunir o melhor dos principais modelos
existentes na época;
 Virou logo um padrão para modelagem de
software e design;
Arilo Claudio Dias Neto
Sucesso da UML
 Facilita a compreensão de sistemas
complexos durante todo o ciclo de vida;
 Simplifica o reuso de modelos e código;
 Orientada por natureza para programação
OO (além disso a UML não depende da plataforma);
05/02/2014
22
Arilo Claudio Dias Neto
O que mudou da 1.x para a 2.0
 Diagrama de Classes quase nada;
 Diagrama de Sequencia praticamente igual;
 Diagramas de Colaboração e de Estados só
mudaram a nomenclatura;
 São os mais novos diagramas: o de Tempo e o de
Estrutura Composta;
Arilo Claudio Dias Neto
Diagramas providos pela UML 2.0
 São 13 diagramas, divididos em 3 grupos:
44
Diagramas 
Estruturais
Classes
Objeto
Componentes
Instalação
Pacotes
Estrutura
Diagramas 
Comportamentais
Casos de Uso
Transição de 
Estados
Atividade
Diagramas de 
Interação
Sequência
Interatividade
Colaboração ou 
Comunicação
Tempo
05/02/2014
23
IEC993 – INTRODUÇÃO À ENGENHARIA DE
SOFTWARE – 2013/2
PROJETO E MODELAGEM DE SOFTWARE
D.Sc. Arilo Claudio Dias Neto
arilo@icomp.ufam.edu.br
45
introdução à engenharia de software/sliders prova 2/IEC993-Aula26-manutencao.pdf
24/02/2014
1
IEC993 – INTRODUÇÃO À ENGENHARIA DE
SOFTWARE – 2013/2 
MANUTENÇÃO DE SOFTWARE
D.Sc. Arilo Claudio Dias Neto
arilo@icomp.ufam.edu.br
1
Arilo Claudio Dias Neto
O que é a manutenção?
O processo de modificar um sistema de
software ou componente, depois da
entrega, para corrigir falhas, melhorar
desempenho ou outros atributos, ou
adaptar a mudanças no ambiente.
IEEE Std 620.12 1990
2
24/02/2014
2
Arilo Claudio Dias Neto
Definição
 Manutenção de Software:
“atividade durante a qual ocorrem modificações
em um ou mais artefatos resultantes do
desenvolvimento de um software, buscando
mantê-lo disponível, corrigir suas falhas,
melhorar seu desempenho e adequá-lo aos
requisitos novos ou modificados.”
(ANSI/IEEE, 1993)
3
Arilo Claudio Dias Neto
Definição
 Manutenção de Software:
“o custo associado à modificação de um sistema de
software ou componente depois de entregue para
corrigir falhas, melhorar o desempenho ou outros
atributos, ou para adaptá-lo a um ambiente
modificado.” (SEI, 2005)
4
24/02/2014
3
Arilo Claudio Dias Neto
Motivações
 Modificação de software – inevitável
◦ Surgem novos requisitos
◦ O ambiente do negócio muda
◦ Erros devem ser reparados
◦ Novo equipamento deve ser incorporado
◦ O desempenho do software pode ser
melhorado
5
Arilo Claudio Dias Neto
Por que fazer bem feito?
 Por que é mais barato!
◦ Historicamente, 60% a 80% do esforço total ocorre na
manutenção
 Por que é mais rápido!
◦ Não ter tempo para fazer bem feito agora significa ter
tempo para refazer depois
 Por que é mais fácil!
◦ Desenvolvimento ocorre uma única vez
◦ Manutenção é para sempre
6
24/02/2014
4
Arilo Claudio Dias Neto
Sistemas Legados
 Software antigos, e que são modificados para satisfazer
mudanças de requisitos e novas plataformas.
 Características de sistemas legados:
◦ Normalmente de baixa qualidade
◦ Projetos não-extensíveis, dificultando evoluções
◦ Documentação pobre ou inexistente
◦ Casos de teste e resultados não arquivados
◦ Histórico de modificações mal geridos
◦ Porém, muito importantes para o negócio da empresa!!!
7
Arilo Claudio Dias Neto
Processo de Software
 O Trabalho em ES pode ser dividido em 3 fases genéricas (Pressman, 2001):
◦ Definição: foco – O que?
 Quais são os requisitos funcionais e não-funcionais? Quais são as regras de
negócio? Quais são os dados de entrada e saída?
 Atividades: Análise de Requisitos.
◦ Desenvolvimento: foco – Como?
 Como os dados devem ser estruturados? Como deve ser a arquitetura do sistema
para atender aos atributos de qualidade estabelecidos? Como as funções devem ser
realizadas na arquitetura?
 Atividades: Projeto (Projeto de Alto Nível e Projeto Detalhado ou de Baixo Nível),
Codificação (ou Implementação) e Testes.
◦ Suporte: foco – Mudança.
 A fase de suporte reaplica as atividades definidas nas fases de Definição e
Desenvolvimento no contexto de um software existente.
 Atividades:Manutenção (corretiva, adaptativa, evolutiva e preventiva).
8
24/02/2014
5
Arilo Claudio Dias Neto
Quando inicia a manutenção?
Leonardo Murta Introdução à ES 9
Desenvolvimento
ManutençãoRelease
Arilo Claudio Dias Neto
Quando inicia a manutenção?
10
Desenvolvimento ManutençãoRelease
Desenv.
Manut.
Release
Desenv. Release
Manut.
Desenv.
24/02/2014
6
Arilo Claudio Dias Neto
Quais são os tipos de manutenção?
11
Manutenção
Correção
Corretiva Emergencial Preventiva
Evolução
Adaptativa Perfectiva
Arilo Claudio Dias Neto
Quais são os tipos de manutenção?
 Manutenção corretiva
◦ Reativa
◦ Corrige problemas reportados
◦ Faz o software voltar a atender aos requisitos
 Manutenção emergencial
◦ Não programada
◦ Mantém temporariamente o sistema funcionando
◦ Necessita uma manutenção corretiva posterior
 Manutenção preventiva
◦ Pró-ativa
◦ Corrige problemas latentes
12
24/02/2014
7
Arilo Claudio Dias Neto
Quais são os tipos de manutenção?
 Manutenção adaptativa
◦ Mantém o software usável após mudanças no
ambiente
 Manutenção perfectiva
◦ Provê melhorias para o usuário
◦ Melhora atributos de qualidade do software
13
Arilo Claudio Dias Neto
Quanto consome?
14
25%
Adaptativa
50% Evolutiva
21%
Corretiva/ 
Emergencial
4%Preventiva
24/02/2014
8
Arilo Claudio Dias Neto
Características da Manutenção
 Atividades Gerais:
◦ Análise do Problema (categorização/priorização da manutenção);
◦ Avaliação do pedido de manutenção (análise do esforço, riscos,
custos);
 Avaliação da documentação de projeto e Análise de impacto das
mudanças (partes do software atingidas, efeitos colaterais);
◦ Implementação das mudanças (modelos e código);
◦ Revisão e Aceitação: Testes de Regressão e Inspeções;
◦ Migração.
15
Arilo Claudio Dias Neto
Evolução do Software
 Software evolui com o tempo
◦ Independentemente do seu tamanho, complexidade ou domínio de
aplicação
 Manutenções fazem parte da vida de um software
 Razões para evolução:
◦ Adaptação a um novo ambiente
◦ Cliente solicitando novas funcionalidades
◦ Reengenharia da aplicação para um contexto moderno
16
24/02/2014
9
Arilo Claudio Dias Neto
Evolução do Software
 Lehman propôs “leis” que se aplicavam a software quando
eles evoluiam:
1. Lei da modificação contínua (1974)
2. Lei da complexidade crescente (1974)
3. Lei da auto-regulação (1974)
4. Lei da conservação da estabilidade organizacional (1980)
5. Lei da conservação da familiaridade (1980)
6. Lei do crescimento contínuo (1980)
7. Lei da qualidade declinante (1996)
8. Lei de realimentação do sistema (1996)
17
Arilo Claudio Dias Neto
Evolução do Software
18
24/02/2014
10
Arilo Claudio Dias Neto
Evolução do Software
19
Arilo Claudio Dias Neto
Evolução do Software
20
24/02/2014
11
Arilo Claudio Dias Neto
Evolução do Software
21
Arilo Claudio Dias Neto
Evolução do Software
22
24/02/2014
12
Arilo Claudio Dias Neto
Evolução do Software
23
Arilo Claudio Dias Neto
Evolução do Software
24
24/02/2014
13
Arilo Claudio Dias Neto
Evolução do Software
25
Arilo Claudio Dias Neto
Ferramental de Apoio à Manutenção
 Ferramentas de bug tracking
◦ Software projetado para apoiar
desenvolvedores a rastrear issues (defeitos e
pedidos de mudança) em projetos.
26
24/02/2014
14
Arilo Claudio Dias Neto
Processo de Manutenção
“Conjunto de etapas bem definidas, que 
direcionam as atividades de manutenção de 
software, com o objetivo primordial de 
satisfazer às necessidades dos usuários de 
maneira planejada e controlada”. 
(Pigosky, 1996)
27
Arilo Claudio Dias Neto
Processo de Manutenção
 Objetivo:
◦ Modificar um produto de software existente, preservando a
sua integridade (norma NBR ISO 12207).
 Início:
◦ quando uma necessidade de modificação é identificada ou
seja, quando se necessita corrigir problemas, realizar
adaptações ou melhorias.
 Término:
◦ No momento da descontinuação do software, ou seja,
quando não se vai mais utilizá-lo.
28
24/02/2014
15
Arilo Claudio Dias Neto
Processo de Manutenção
29
Solicitação de 
Modificação
Análise da Requisição de 
Modificação
Implementação 
da Modificação
Aceitação/Revisão 
da Modificação
Planejamento
Migração
Descontinuidade
Arilo Claudio Dias Neto
Processo de Manutenção
 Planejamento:
◦ Nesta etapa, são estabelecidos planos e procedimentos para
registrar e controlar a atividade de manutenção e os pedidos feitos
pelos clientes.
 Solicitação de Modificação:
◦ Este evento ocorre quando alguma solicitação de modificação é
feita, ou pelos clientes, ou pelos próprios mantenedores.
 Análise da Requisição de Modificação:
◦ Nesta etapa, é feita uma verificação minuciosa da solicitação por
parte do mantenedor, para que este possa oferecer opções de
solução para o problema identificado.
30
24/02/2014
16
Arilo Claudio Dias Neto
Processo de Manutenção
 Implementação da Modificação:
◦ nesta etapa, são realizadas as tarefas propriamente
ditas de alteração do produto de software, incluindo
código, documentação etc. Nela, deve-se garantir a
perfeita execução para se chegar à solução proposta.
 Aceitação/Revisão da Modificação:
◦ Nesta etapa, são feitas as revisões e testes a fim de
garantir a integridade do produto, bem como a
homologação e aprovação junto ao solicitante para
que o produto possa ser liberado.
31
Arilo Claudio Dias Neto
Processo de Manutenção
 Migração:
◦ Nesta etapa, o produto gerado é colocado no
ambiente de produção e uma avaliação deve ser
conduzida para confirmar a execução perfeita da
alteração.
 Descontinuação do Software:
◦ nesta etapa, o software chega ao seu último
estágio no ciclo de vida, onde não haverá mais
modificações no mesmo.
32
24/02/2014
17
Arilo Claudio Dias Neto
Manutenibilidade
 Facilidade com que um software pode ser entendido, corrigido,
adaptado e/ou aumentado.
 Representa um requisito não-funcional ou atributo de qualidade de
um software (ISO/IEC 9126-1).
 Características relacionadas a manutenibilidade do software: Refere-
se ao esforço necessário para fazer modificações específicas no
software. São elas:
◦ Modificabilidade: Avalia o esforço necessário para a modificação e
remoção de defeitos;
◦ Testabilidade: Avalia o esforço necessário para validar as modificações
realizadas.
33
Arilo Claudio Dias Neto
Manutenibilidade
 Fatores que influenciam:
◦ Arquitetura da aplicação: Camadas, MVC, Tubos e Filtros,
Cliente-Servidor etc.
◦ Adoção de Princípios de Projeto: Modularidade (Coesão e
Acoplamento), Ocultação de Informação, Encapsulamento,
Separação de Objetivos, Generalização (Abstração).
◦ Utilização de Padrões de Projeto.
◦ Utilização de Padrões de Programação.
◦ Comentários em Programas.
◦ Documentação de Análise e Projeto atualizadas.
34
24/02/2014
18
Arilo Claudio Dias Neto
Manutenibilidade
 Medida indireta de software.
◦ Medida através dos atributos da atividade de manutenção que
podem ser medidos.
 Métricas:
◦ Tempo gasto para o reconhecimento do problema.
◦ Tempo gasto na análise do problema (análise da solução, análise de
impacto)
◦ Tempo gasto na especificação
das mudanças (documentos).
◦ Tempo de correção ou modificação (implementação).
◦ Tempo de testes.
35
Arilo Claudio Dias Neto
Problemas na Manutenção
 Geralmente, a única fonte de informação disponível sobre o software
é o código fonte.
◦ Código é complexo e de difícil leitura sem uma documentação de apoio.
◦ Documentação de análise (requisitos) e projeto desatualizada.
◦ Dificuldade em avaliar o impacto da manutenção pela falta de modelos do software.
 Dificuldade em se realizar Testes de Regressão quando não existe
nenhum registro de testes.
 Os mantenedores, em geral, não são os mesmos profissionais que
desenvolveram o software e os desenvolvedores originais nem
sempre se encontram disponíveis.
36
24/02/2014
19
Arilo Claudio Dias Neto
Problemas na Manutenção
 Baixa estima dos mantenedores: geralmente os
profissionais acham que é mais “nobre” a tarefa
de desenvolver novos sistemas do que a tarefa de
manter sistemas existentes.
 A maioria do software não é projetada para sofrer
mudanças.
37
Arilo Claudio Dias Neto
Métodos para Apoio à Manutenção
 Engenharia Reversa.
 Reengenharia.
 Gerência de Configuração.
 Reutilização de Software.
38
24/02/2014
20
Arilo Claudio Dias Neto
Engenharia Reversa
 Engenharia Reversa:
◦ Processo de análise dos componentes do
sistema e dos seus relacionamentos, a fim de
descrever este sistema em um nível de
abstração mais alto do que o código fonte
original (GANNOD, 1999).
39
Arilo Claudio Dias Neto
Reengenharia
 Reengenharia:
◦ Recuperação de informações de projeto de um
software existente, a fim de reconstituir o
sistema de modo a melhorar a sua qualidade
global. Envolve: Engenharia Reversa,
Reestruturação e Engenharia Progressiva.
40
24/02/2014
21
Arilo Claudio Dias Neto
Gerência de Configuração
 Gerência de Configuração:
◦ “Disciplina para identificar e documentar as
características físicas e funcionais de um item de
configuração, controlar as modificações sobre
estas características, gravar e relatar o
processamento da mudança e o status da sua
implementação, e verificar a sua adequação aos
requisitos especificados.” [IEEE]
41
Arilo Claudio Dias Neto
Reutilização de Software
 Reutilização:
◦ Processo de Incorporar em um novo Produto:
código, especificações de requisito e de projeto,
planos de teste, qualquer produto gerado
durante desenvolvimentos anteriores (Werner,
2002).
42
24/02/2014
22
IEC993 – INTRODUÇÃO À ENGENHARIA DE
SOFTWARE – 2013/2 
MANUTENÇÃO DE SOFTWARE
D.Sc. Arilo Claudio Dias Neto
arilo@icomp.ufam.edu.br
43
introdução à engenharia de software/sliders prova 2/IEC993-Aula23-testes.pdf
15/02/2014
1
IEC993 – INTRODUÇÃO À ENGENHARIA DE
SOFTWARE – 2013/2 
TESTES DE SOFTWARE
D.Sc. Arilo Claudio Dias Neto
arilo@icomp.ufam.edu.br
29
Arilo Claudio Dias Neto
Estratégias para Re-Teste
 Podem ocorrer para qualquer estratégia de
teste, em caso de mudanças no software no
planejamento dos testes
 Dois tipos:
◦ Regressão
◦ “Fumaça” (smoke testing)
15/02/2014
2
Arilo Claudio Dias Neto
Teste de Regressão
 Estratégia importante para redução de “efeitos colaterais”
 Consiste em se aplicar, a cada nova versão do software ou
a cada ciclo, todos os testes que já foram aplicados nas
versões ou ciclos de teste anteriores do sistema.
◦ Execute testes de regressão toda vez que uma modificação maior é
realizada no software (incluindo a integração de novos módulos)
◦ Efetue a gerência de configuração
Arilo Claudio Dias Neto
Teste “Fumaça”
 Pode ser caracterizado como estratégia de
integração incremental.
 O software é reconstruído (com novos
componentes incorporados) e exercitado
diariamente.
15/02/2014
3
Arilo Claudio Dias Neto
Teste de Aceitação
 Foco nos requisitos – nas características imediatamente aparentes para o
usuário final
 Testes realizados, geralmente, por um grupo restrito de usuários finais do
sistema
 Teste conduzido para determinar se um sistema satisfaz ou não seus critérios
de aceitação definidos pelo cliente
◦ Critérios para Teste de Aceitação
 A funcionalidade (caso de uso) ou características de desempenho estão de acordo com o especificado e são
aceitas
 Uma variação da especificação é descoberta e uma lista de discrepâncias (deficiências) é criada
Arilo Claudio Dias Neto
Teste de Aceitação
 Teste Alfa e Beta
◦ Alfa: executado na instalação do desenvolvedor
pelo cliente
◦ Beta: executado na instalação de um ou mais
clientes pelo usuário final do software
15/02/2014
4
Arilo Claudio Dias Neto
Teste de Instalação
 Consiste em instalar o sistema nos locais em que estão os
usuários
◦ Dispensado no caso do teste de aceitação ter sido executado no
ambiente do usuário
 Focam:
◦ A integridade do sistema instalado; e
◦ A verificação quanto a se alguma característica funcional ou não
funcional foi afetada pelas condições do local de operação
Arilo Claudio Dias NetoArilo Claudio Dias Neto
MÓDULO II
Técnicas de Teste de Software
15/02/2014
5
Arilo Claudio Dias Neto
Módulo II: Roteiro
 Técnicas de Teste:
◦ Funcional x Estrutural x Baseada em Erros
 Particionamento Por Equivalência
 Análise do Valor Limite
 Grafo de Causa-Efeito
 Exercícios
Arilo Claudio Dias Neto
Técnicas para Teste de Software
 Técnicas:
◦ Funcional (ou caixa preta/caixa fechada)
◦ Estrutural (ou caixa branca/caixa aberta)
◦ Baseada em erros
 A questão não está em qual delas utilizar e sim
como combiná-las de forma a maximizar os
benefícios das atividades de teste!
15/02/2014
6
Arilo Claudio Dias Neto
Técnica Estrutural
 É baseada no conhecimento da estrutura interna da implementação
 Teste dos detalhes procedimentais
 A maioria dos critérios dessa técnica utiliza uma representação de
programa conhecida como grafo de programa ou grafo de fluxo de
controle
 Dependente de apoio ferramental
 Detalhes: DISCIPLINA IEC484 – TESTE DE SOFTWARE (7º PERÍODO)
Arilo Claudio Dias Neto
Técnica Estrutural (Grafo de Programa)
 Detalhes considerados:
◦ nó
◦ arco
◦ caminho:
 simples
 completo
 livre de laço
◦ fluxo de controle
15/02/2014
7
Arilo Claudio Dias Neto
Técnica Estrutural (Grafo de Programa)
 Nós:
◦ blocos “indivisíveis”
 não existe desvio para o meio do bloco
 uma vez que o primeiro comando do bloco é
executado, os demais comandos são executados
seqüencialmente
 Arestas ou Arcos:
◦ representam o fluxo de controle entre os nós
Arilo Claudio Dias NetoArilo Claudio Dias Neto
Técnica Estrutural
 Critérios de Fluxo de Controle
◦ Todos-Nós:
 1,2,3,4,5,6,7,4,8,9,11
 1,3,4,8,9,10,11
◦ Todos-Arcos:
 <1,2>,<2,3>,<3,4>,<4,5>,<5,6>,<6,7>
,<7,4>,<4,8>,<8,9>,<9,11>
 <1,3>,<3,4>,<4,5>,<5,7>,<7,4>,<4,8>
,<8,10>,<10,11>
◦ Todos-Caminhos
 ??????
15/02/2014
8
Arilo Claudio Dias Neto
Técnica Funcional
 Baseia-se na especificação do software para derivar os
requisitos de teste
 Aborda o software de um ponto de vista macroscópico
 Envolve dois passos principais:
◦ identificar as funções que o software deve realizar (especificação
dos requisitos, casos de uso)
◦ criar casos de teste capazes
de verificar se essas funções estão
sendo executadas corretamente
Arilo Claudio Dias Neto
Técnica Funcional
15/02/2014
9
Arilo Claudio Dias Neto
Técnica Funcional
 Problema:
◦ Dificuldade em quantificar a atividade de teste -
não se pode garantir que partes essenciais ou
críticas do software foram executadas
 Critérios da Técnica Funcional:
◦ Particionamento em Classes de Equivalência
◦ Análise do Valor Limite
◦ Grafo de Causa-Efeito
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
 Critério utilizado para reduzir o número de caso de teste procurando
garantir uma boa cobertura do código do produto em teste.
 Empregado intuitivamente pelos programadores mesmo sem
conhecer o critério.
 Exemplo:
◦ sistema de recursos humanos – empregar pessoas com base na idade
 Como deveriam ser derivados casos de teste para o exemplo acima?
15/02/2014
10
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
 O módulo deveria ser testado considerando as idades: 0, 1, 2, 3, 4, 5,
6, 7, 8, ..., 90, 91, 92, 93, 94, 95, 96, 97, 98, 99?
 Considere que o módulo que resolve o problema anterior tenha sido
implementado como ilustrado abaixo:
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
 Caso o programa tenha sido implementado desta forma, a
única forma de testá-lo adequadamente seria executar o
módulo com valores de idade de 0..99.
 Caso haja tempo suficiente, esse é o melhor teste a ser
realizado.
 O problema é que da forma como o código acima foi
implementado, a execução de um dado caso de teste não
diz nada a respeito da execução do próximo.
15/02/2014
11
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
 Agora considere essa outra implementação (bem melhor) do mesmo
problema:
 Dada essa implementação, fica claro que não é necessário testar para
todos os valores 0, 1, 2, · · · , 14, 15 e 16, por exemplo.
 Apenas um valor precisa ser testado.
 Qual seria esse valor?
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
 RESPOSTA:
◦ Qualquer valor dentro do intervalo tem a mesma importância, ou
seja, qualquer valor escolhido é adequado.
◦ O mesmo se aplica para os demais intervalos de dados
◦ Tais intervalos determinam o que é chamado de classe de
equivalência
◦ Qualquer valor no intervalo de uma classe é considerado
equivalente em termos de teste. Assim sendo:
 Se um caso de teste de uma classe de equivalência revela uma falha
qualquer caso de teste da mesma classe também revelaria e vice-versa.
15/02/2014
12
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
 Tal critério de teste assume que na especificação de requisitos existe
uma indicação precisa das classes de equivalência.
 Observe que com esse critério de teste o número de casos de teste é
reduzido de 100 para 4 (um para cada classe de equivalência).
 Além disso, também é assumido que o programador não
implementou algo estranho como ilustrado abaixo:
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
 Divide o domínio de entrada do programa em classes de dados
(classes de equivalências)
 Uma classe de equivalência representa um conjunto de estados
válidos e inválidos para uma condição de entrada
◦ Tipicamente uma condição de entrada pode ser um valor numérico
específico, uma faixa de valores, um conjunto de valores
relacionados, ou uma condição lógica.
 Os dados de teste são derivados a partir das classes de equivalência
◦ Eventualmente, pode se considerar o domínio de saída como
referência
15/02/2014
13
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
 2 Passos
1. Identificar classes de equivalência (é um processo heurístico)
 Se uma condição de entrada especifica uma faixa de valores ou requer
um valor específico, 1 classe de equivalência válida e 2 inválidas são
definidas;
 Se uma condição de entrada especifica um membro de um conjunto ou
é lógica, uma classe de equivalência válida e uma inválida são definidas
2. Definir os casos de teste
 enumeram-se as classes de equivalência
 casos de teste para as classes válidas
 casos de teste para as classes inválidas
15/02/2014
14
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
15/02/2014
15
Arilo Claudio Dias Neto
Particionamento em Classes de 
Equivalência
 Em geral, não há tempo para a criação de um caso
de teste para cada classe válida.
 Solução:
◦ Criar o menor número possível de casos de teste que
cubram todas as classes válidas.
◦ Criar um caso de teste para cada classe inválida
Arilo Claudio Dias Neto
Exemplo 1
 Função:
◦ Considere uma função que aceita como entradas de 4 a
6 valores inteiros de 2 dígitos maiores do que 10.
 Identificação das variáveis de entrada e das
condições que estas devem satisfazer:
◦ nro_entradas ∈ [ 4, 6 ]
◦ valor ∈ [ 10, 99 ]
58
15/02/2014
16
Arilo Claudio Dias Neto
Exemplo 1
 Determinação das classes de equivalência:
Número de entradas (nro_entradas)
Condições de Entrada Classes Válidas Classes Inválidas
4  nro_entradas  6
(C1)
Valor informado (valor)
nro_entradas < 4
(C3)
nro_entradas > 6
(C4)
10  valor  99
(C2)
valor < 10
(C5)
valor > 99
(C6)
Arilo Claudio Dias Neto
Exemplo 1
 Casos de teste:
◦ Selecionar casos de testes cobrindo as classes
válidas das diferentes variáveis
60
nro-entradas C1 C2 C3 C4 C5 C6
4..6
< 4
> 6
valor
10..99
< 10
> 99
15/02/2014
17
Arilo Claudio Dias Neto
Exemplo 1
 Casos de teste:
◦ Dica: “Congela” uma variável como válida e
alterna as outras
61
nro-entradas C1 C2 C3 C4 C5 C6
4..6
< 4
> 6
valor
10..99
< 10
> 99
Arilo Claudio Dias Neto
Exemplo 1
 Casos de teste:
◦ Selecionar casos de testes cobrindo as classes
válidas das diferentes variáveis
62
nro-entradas C1 C2 C3 C4 C5 C6
4..6 X
< 4
> 6
valor
10..99 X
< 10
> 99
15/02/2014
18
Arilo Claudio Dias Neto
Exemplo 1
 Casos de teste:
◦ Para cada classe inválida escolha um caso de
teste que cubra 1 e somente 1 de cada vez
63
nro-entradas C1 C2 C3 C4 C5 C6
4..6 X
< 4 X
> 6
valor
10..99 X X
< 10
> 99
Arilo Claudio Dias Neto
Exemplo 1
 Casos de teste:
◦ Para cada classe inválida escolha um caso de
teste que cubra 1 e somente 1 de cada vez
64
nro-entradas C1 C2 C3 C4 C5 C6
4..6 X X X
< 4 X
> 6 X
valor
10..99 X X X
< 10 X
> 99 X
15/02/2014
19
Arilo Claudio Dias Neto
Exemplo 2
 Verificação de uma senha válida:
◦ Considere o teste do procedimento: Valida_Nova_Senha
que recebe como entrada uma senha e valida-a
conforme as seguintes regras:
 uma senha deve ter de 6 a 10 caracteres
 o primeiro caractere dever ser alfabético, numérico ou um “?”
 os outros caracteres podem ser quaisquer, desde que não sejam
caracteres de controle
 a senha não pode existir em um dicionário
 Exemplo:
acdn25 (válido); 
senha*1 (inválido);
1pass (inválido);
a12345678910 (inválido) 
Arilo
Claudio Dias Neto
Exemplo 2
 Classes de equivalência
15/02/2014
20
Arilo Claudio Dias Neto
Exemplo 2
1 2 3 4 5 6 7 8 9
1
2
3
4
5
6
7
8
9
10
11
12
C
la
ss
e
s 
d
e
 e
q
u
iv
al
ê
n
ci
a
Casos de Teste Casos de Teste
1.
2.
3.
4.
5.
6.
7.
8.
9.
Arilo Claudio Dias Neto
Exemplo 2
1 2 3 4 5 6 7 8 9
1 X X X X X X X X
2 X X
3 X X
4 X X
5 X X X X X X X X
6 X X X X X X X X
7 X
8 X
9 X
10 X
11 X
12 X
C
la
ss
e
s 
d
e
 e
q
u
iv
al
ê
n
ci
a
Casos de Teste Casos de Teste
1. senhaok
2. 1senha
3. ?senha
4. senha
5. senhacorreta
6. [esc]senha
7. *senha
8. senha[esc]ok
9. invalida [no dicionário]
15/02/2014
21
Arilo Claudio Dias Neto
Classe de Equivalência: Exercício
 Verificação de um número primo:
O programa deve determinar se um número natural é primo ou não. Um
número primo é divisível por ele e por 1.
 Exemplo:
5 (primo); 
2 (primo);
4 (não primo);
15 (não primo) 
Classes de Equivalência
Não Primo
Primo
Casos deTeste Resultado Esperados
4 Não Primo
7 Primo
Caso 0
Caso 1
0 Não Primo
1 Não Primo
0 nem 1 são números primos!!!
Arilo Claudio Dias Neto
Classe de Equivalência: Exercício
 Problema do dia, mês e ano:
◦ Dado o seguinte problema: "um programa
recebe 3 valores pela linha de comando: dia,
mês, ano e imprime a data do dia seguinte.
◦ O dia, o mês e o ano tem valores numéricos
inteiros: 1<= dia <= 31, 1<= mês <= 12 e 1812 <=
ano <= 2012“.
◦ Determine as classes de equivalência e os casos
de teste para esse programa.
introdução à engenharia de software/sliders prova 2/IEC993-Aula14-qualidade.pdf
07/01/2014
1
IEC993 – INTRODUÇÃO À ENGENHARIA DE
SOFTWARE – 2013/2
QUALIDADE DE SOFTWARE
D.Sc. Arilo Claudio Dias Neto
arilo@icomp.ufam.edu.br
1
Arilo Claudio Dias Neto
Engenharia de Software
 Conjunto de princípios, métodos e técnicas
que tratam o software como produto de
engenharia que requer planejamento, projeto,
implementação e manutenção.
 Objetivo:
◦ Produzir software de alta qualidade!
 Mas...
◦ O que é qualidade de software?
07/01/2014
2
Arilo Claudio Dias Neto
Qualidade de Software
 Pensamento de alguns desenvolvedores:
◦ Qualidade de software é algo com que você começa a se preocupar
depois que o código foi gerado.
◦ Resultado esperado do projeto seguido por estes profissionais...
Arilo Claudio Dias Neto
Qualidade de Software
 Gestão da Qualidade (ou apenas Garantia da Qualidade de
Software) é uma atividade guarda-chuva que é aplicada ao
longo de todo o processo de desenvolvimento.
Análise Projeto Codificação Testes
Qualidade de Software
07/01/2014
3
Arilo Claudio Dias Neto
Qualidade de Software
 Qualidade de Software abrange:
1. Um processo de garantia de qualidade de software.
2. Tarefas específicas de garantia e controle de qualidade (incluindo revisões
técnicas e estratégias de teste).
3. Prática de Engenharia de Software efetiva (métodos e ferramentas
adequados).
4. Controle dos produtos de trabalho de software e suas modificações.
5. Procedimento para garantir satisfação a normas estabelecidas.
6. Mecanismos de medição e análise do desenvolvimento.
Arilo Claudio Dias Neto
Qualidade de Software
 Quem faz?
◦ Todos os envolvidos no processo de engenharia de um software são
responsáveis pela qualidade.
 Por que é importante?
◦ Temos 2 opções:
 (1) fazer direito ,
 (2) fazer novamente.
◦ Se uma equipe enfatiza qualidade em todas as atividades, reduz a
quantidade de retrabalho.
 menores custos e melhor prazo para entrega do produto!
07/01/2014
4
Arilo Claudio Dias Neto
Qualidade de Software
 O que seria?
◦ Estar em conformidade com especificações e padrões de desenvolvimento
documentados.
◦ Prover o atendimento das necessidades dos usuários.
 Como fazer?
◦ Conjunto de atividades técnicas aplicadas durante todo o processo de
desenvolvimento.
 Qual o objetivo?
◦ Garantir que tanto o processo de desenvolvimento quanto o produto de
software atinjam níveis de qualidade especificados.
7
Arilo Claudio Dias Neto
Verificação & Validação de Software 
(V&V)
 Definições (IEEE):
◦ Verificação: Avalia um sistema para determinar se os
produtos de uma dada atividade de desenvolvimento
satisfazem as condições impostas no início desta
atividade.
◦ Validação: Avalia um sistema para determinar se ele
satisfaz os requisitos para ele especificados.
8
07/01/2014
5
Arilo Claudio Dias Neto
Verificação & Validação de Software 
(V&V)
 Esclarecendo:
◦ Verificação:
 “Estamos construindo certo o produto?”;
 Os artefatos construídos devem estar de acordo com a
especificação do software.
◦ Validação:
 “Estamos construindo o produto certo?”;
 O software deve atender às necessidades dos usuários.
9
Arilo Claudio Dias Neto
Métodos de V&V
 Principais Métodos para Verificação e
Validação:
◦ Verificação:
 Estática:
 Revisões de Software.
 Dinâmica:
 Testes de Software.
◦ Validação:
 Revisões e Testes de Software.
10
07/01/2014
6
Arilo Claudio Dias Neto
Métodos de V&V
 Por que utilizar métodos de Verificação e
Validação?
◦ Indústria de Software:
 Seu uso tem mostrado resultados positivos considerando tanto
produtividade quanto qualidade.
◦ Pesquisa científica:
 Estudos experimentais evidenciam benefícios da utilização 
destes métodos no desenvolvimento de software.
11
Arilo Claudio Dias Neto
Curiosidade sobre V&V
 Inspeções aumentam significativamente a produtividade,
qualidade e estabilidade dos projetos (Fagan, 1976).
 Inspeções e Testes encontram diferentes tipos de defeitos (Boehm
e Basili, 2001).
 Qualidade melhora a produtividade (Travassos e Kalinowski, 2008).
◦ Se sei encontrar defeitos, evito sua inserção...
 Prevenção de defeitos é melhor do que remoção de defeitos
(Mays, 1990).
12
07/01/2014
7
Arilo Claudio Dias Neto
Curiosidade sobre V&V
 Corrigir um defeito após a entrega do produto é
frequentemente 100 vezes mais caro do que corrigi-lo
durante as atividades de requisitos e projeto do sistema
(Boehm e Basili, 2001).
13
Arilo Claudio Dias Neto
Curiosidade sobre V&V
 Em projetos recentes de software, teríamos um esforço de
retrabalho entre 35% e 50% do esforço total (Boehm e Basili,
2001).
14
10% 20% 15% 20% 35%
Análise Projeto Codificação Testes Retrabalho
07/01/2014
8
Arilo Claudio Dias Neto
Curiosidade sobre V&V
 Em projetos recentes de software, teríamos um esforço de
retrabalho entre 35% e 50% do esforço total (Boehm e Basili,
2001).
 Projeto de 10 meses
 3 meses e meio até 5 meses do projeto foi usado para
RETRABALHO!!!
15
Arilo Claudio Dias Neto
Curiosidade sobre V&V
 Esta é (talvez) a área da Engenharia de Software que possui
mais evidências científicas sobre seus benefícios e impacto
positivo em um projeto de software.
 Exemplo de evidências:
 Inspeções de software (qualquer artefato) revelam cerca de 60%
dos defeitos
 Testes funcionais de software revelam cerca de 55% das falhas
 Combinar Inspeções + Teste é uma estratégia positiva
 Cada método identifica um tipo diferente de defeito/falha
16
07/01/2014
9
Arilo Claudio Dias Neto
Terminologia - Padrão IEEE 610.12-1990
 Conceitos importantes da qualidade do
software:
17
Engano 
[mistake]
(causado 
pela equipe)
Leva a 
um
Defeito 
[fault]
(inserido em 
algum 
artefato)
Irá
provoca
r
Falha [failure]
(durante a 
execução do 
software)
Deixará o 
sistema em 
estado de 
Erro [error]
(inserido 
em algum 
artefato)
Arilo Claudio Dias Neto
Terminologia - Padrão IEEE 610.12-1990
 Engano (mistake):
◦ Ação humana que produz um resultado incorreto.
◦ Exemplo 1: o analista esqueceu de especificar uma regra
de negócio dizendo que a quantidade de um produto
deve ser verificada antes da venda.
◦ Exemplo 2: o desenvolvedor interpretou um requisito de
forma incorreta e entendeu que valores maiores que 10
eram válidos (o correto é menor que 10).
18
07/01/2014
10
Arilo Claudio Dias Neto
Terminologia - Padrão IEEE 610.12-1990
 Defeito (fault):
◦ Deficiência mecânica ou algorítmica que se ativada pode
levar a uma falha. Passo, processo ou definição de dados
incorretos
◦ Exemplo 1: não existe regra de negócio informando que
apenas produtos em estoque podem ser vendidos.
◦ Exemplo 2: um IF no código está incorreto com X > 10
em vez de X < 10.
19
Arilo Claudio Dias Neto
Terminologia - Padrão IEEE 610.12-1990
 Falha (failure):
◦ Evento notável onde o sistema viola suas especificações.
Produção de uma saída incorreta com relação à
especificação.
◦ Exemplo 1: o sistema aceita uma venda de um produto que
não está em estoque
◦ Exemplo 2: o sistema permitiu que operações com valores
maiores que 10 fossem aceitas
20
07/01/2014
11
Arilo Claudio Dias Neto
Terminologia - Padrão IEEE 610.12-1990
 Erro (error):
◦ Diferença entre o valor obtido e o valor esperado. Qualquer
estado intermediário incorreto ou resultado inesperado.
◦ Exemplo 1: o sistema possui uma venda que não pode ser
atendida
◦ Exemplo 2: o sistema possui uma operação inválida aceita
como válida
21
Arilo Claudio Dias Neto
Terminologia adotada
 Defeito: não faremos distinção entre os termos
defeito, engano e erro. Todos serão tratados como
defeito, que estará associado à causa de um
comportamento incorreto.
 Falha: usaremos este termo para designar um
comportamento incorreto, ou seja, a
consequência.
22
07/01/2014
12
Arilo Claudio Dias Neto
Defeitos de Software
 A maior parte é de origem humana.
 São gerados na comunicação e na transformação de
informações.
 Permanecem presentes nos diversos produtos de software
produzidos e liberados.
 A maioria encontra-se em partes do produto de software
raramente utilizadas e/ou executadas.
23
Arilo Claudio Dias Neto
Defeitos de Software
 Principal causa:
◦ tradução incorreta de
informações.
 Quanto antes a presença do defeito for revelada, menor o
custo de correção do defeito e maior a probabilidade de
corrigi-lo corretamente.
◦ Solução:
 Introduzir atividades de VV&T ao longo de todo o ciclo de
desenvolvimento.
24
07/01/2014
13
Arilo Claudio Dias Neto
Monitorando Introdução & Detecção
25
0
50
100
150
200
250
300
Análise de 
Requisitos
Projeto Codificação Integração Testes de 
Aceitação
Em produção
Estimado
Introdução
Detecção
Real
Introdução
Detecção
Arilo Claudio Dias Neto
Defeitos de Software
 Taxonomia definida por Shull (1998) a partir do padrão IEEE (IEEE 830,
1998) para documentos de requisitos:
26
Tipo de Defeito Definição
Omissão Informação necessária não incluída 
Ambiguidade Informação passível de ter múltiplas interpretações.
Inconsistência Informações conflitantes 
Fato Incorreto Informação que não é verdadeira para as condições 
especificadas. 
Informação Estranha Informação desnecessária 
07/01/2014
14
Arilo Claudio Dias Neto
Defeitos de Software
 Taxonomia aplicável também a outros artefatos.
27
Arilo Claudio Dias Neto
Defeitos de Software
 Omissão
◦ (1) Algum requisito importante relacionado à funcionalidade,
ao desempenho, às restrições de projeto, ao atributo, ou à
interface externa não foi incluído;
◦ (2) não está definida a resposta do software para todas as
possíveis situações de entrada de dados;
◦ (3) faltam seções na especificação de requisitos;
◦ (4) faltam referências de figuras, tabelas, e diagramas;
◦ (5) falta definição de termos e unidades de medidas.
28
07/01/2014
15
Arilo Claudio Dias Neto
Defeitos de Software
 Exemplo de Omissão:
29
Caso de Uso – CONSULTAR MENSAGEM
FP. O sistema exibe todas as informações da mensagem com detalhes.
Quais informações? Como saber isso?
-Para poder realizar o cadastro, projetista/testadores/desenvolvedores 
precisam saber quais campos fazem parte do cenário.
- Esta informação foi omitida da descrição da funcionalidade, logo temos 
um defeito.
Arilo Claudio Dias Neto
Defeitos de Software
 Ambiguidade
◦ Um requisito tem várias interpretações devido a
diferentes termos utilizados para uma mesma
característica ou vários significados de um
termo para um contexto em particular.
30
07/01/2014
16
Arilo Claudio Dias Neto
Defeitos de Software
 Exemplo de Ambigüidade:
31
Caso de Uso – CADASTRAR CLIENTE
[RN1] O sistema verifica os dados informados.
O mesmo contato não pode ser cadastrado mais de uma vez.
A informação pode ser traduzida incorretamente.
Como verificar se o contato está cadastrado (nome, email, 
ambos)?
Arilo Claudio Dias Neto
Defeitos de Software
 Inconsistência
◦ Dois ou mais requisitos apresentam
informações conflitantes.
32
07/01/2014
17
Arilo Claudio Dias Neto
Defeitos de Software
 Exemplo de Inconsistência
33
Caso de Uso –ALERTAR MENSAGEM
[RN1] O sistema avisa as mensagens a serem repassadas aos destinatários
1 hora antes da data prevista pelo cliente.
[RN2] Serão exibidas apenas as mensagens cuja data e hora de envio seja
menos que 1 hora antes da data atual do sistema.
A informação foi descrita de forma inconsistente
Como o conhecimento de domínio não nos permite saber qual
a informação está correta, temos um defeito.
Arilo Claudio Dias Neto
Defeitos de Software
 Fato Incorreto
◦ Um requisito descreve um fato que não é
verdadeiro, considerando as condições
solicitadas para o sistema.
34
07/01/2014
18
Arilo Claudio Dias Neto
Defeitos de Software
 Exemplo de Fato Incorreto:
35
A informação não foi traduzida corretamente.
Em nossa entrevista, definimos mais formas de consulta, lembra?
Mais escolhidas, preço, etc...
Em seguida, escolho o opção e clico consultar?
Não preencho nenhum dado de consulta?
Caso de Uso – CONSULTAR MENSAGEM
1. O sistema exibe uma tela com opções de busca por título ou por categoria.
2. O usuário escolhe a opção desejada e clica em consultar.
Arilo Claudio Dias Neto
Defeitos de Software
 Informação Estranha
◦ As informações fornecidas
no requisito não são
necessárias ou mesmo usadas.
36
07/01/2014
19
Arilo Claudio Dias Neto
Defeitos de Software
 Exemplo de Informação Estranha:
37
Uma informação estranha foi introduzida.
Uma informação que, apesar de poder estar correta, pode causar
problemas já que não faz parte do sistema. 
Como isto pode ser testado?
Caso de Uso – CONSULTAR CLIENTE
1. O ator passa o mouse em cima do cliente e o sistema lista os dados do usuário
2. O ator confirma se os dados confere com os dados registrados em sua pasta
Arilo Claudio Dias Neto
Defeitos de Software
 Considerações sobre documentos de requisitos:
◦ Primeiro artefato tangível a ser produzido.
◦ Descreve todas as características e as funções que o software a ser
desenvolvido deve possuir.
◦ Atua como um contrato entre o cliente e o desenvolvedor.
◦ Base para todas as etapas subsequentes do desenvolvimento.
◦ Normalmente escrito em linguagem natural.
38
07/01/2014
20
Arilo Claudio Dias Neto
Ambiguidade em Linguagem Natural
39
“O vendedor disse ao cliente que 
seu preço estava incorreto”
O meu preço estava 
incorreto!!
O meu preço estava 
incorreto!!
Vendedor Cliente
Arilo Claudio Dias Neto
Defeitos de Software
 Defeitos em Documentos de Requisitos: Distribuição varia
de acordo com a realidade da organização.
40
Adaptado de (DAVIS,1990).
Tipo Percentagem(%)
Fato Incorreto 40
Omissão 31
Inconsistência 13
Ambiguidade 5
Localização Incorreta 2
07/01/2014
21
Arilo Claudio Dias Neto
Defeitos de Software
Tipos de Defeito
10%
17%
11%
35%
11%
16%
Informações
Inconsistentes
Ambiguidades
Fatos Incorretos
Omissões
Informações Estranhas
Outros Defeitos
41
(Kalinowski et al., 2007).
Arilo Claudio Dias Neto
Defeitos de Software
 Consequências:
◦ Estimativas de esforço e prazo deixam de fazer sentido.
◦ Desperdício de recursos.
◦ Produto final não atende as necessidades do usuário;
◦ Corrigir defeitos após a entrega do produto pode ser até cem vezes
mais caro que corrigi-los nas primeiras fases do desenvolvimento
(em projetos menores, 5:1).
◦ Em projetos recentes de software, teríamos um esforço de
retrabalho entre 40% e 50% do esforço total.
42
07/01/2014
22
IEC400 – INTRODUÇÃO À ENGENHARIA DE
SOFTWARE – 2013/1
QUALIDADE DE SOFTWARE
D.Sc. Arilo Claudio Dias Neto
arilo@icomp.ufam.edu.br
43
IEC993 – INTRODUÇÃO À ENGENHARIA DE
SOFTWARE – 2013/2
QUALIDADE DE SOFTWARE
D.Sc. Arilo Claudio Dias Neto
arilo@icomp.ufam.edu.br
44
introdução à engenharia de software/sliders prova 2/IEC993-Aula16-revisao.pdf
11/01/2014
1
IEC993 – INTRODUÇÃO À ENGENHARIA DE
SOFTWARE – 2013/2 
REVISÕES DE SOFTWARE
D.Sc. Arilo Claudio Dias Neto
arilo@icomp.ufam.edu.br
1
Arilo Claudio Dias Neto
Revisões de Software
 Definição:
◦ Processo ou atividade para leitura de um artefato de software visando
assegurar que ele cumpre sua especificação e atende às necessidades de
seus usuários.
 Objetivo:
◦ Realizar verificação e validação estática de artefatos de software.
 Pode ser aplicada a qualquer artefato produzido ao longo
do processo de desenvolvimento de software.
2
11/01/2014
2
Arilo Claudio Dias Neto
Revisões de Software
 Revisões por pares (peer-reviews) aumentam a
probabilidade de defeitos serem encontrados.
 Comumente utilizam:
◦ Anonimidade;
 Relacionamentos pessoais não afetam a revisão.
◦ Independência dos revisores em relação ao artefato a ser revisado.
 Permite uma avaliação objetiva sem conflitos de interesse.
3
Arilo Claudio Dias Neto
Revisões de Software
 Quando e em que tipos de artefato aplicar
revisões de software?
4
Revisão
11/01/2014
3
Arilo Claudio Dias Neto
Revisões de Software
 Utilização na Prática
◦ De acordo com resultados de um survey descritos em Ciolkowski et
al. (2003):
 Muitas organizações realizam revisões de software.
 Realização pouco sistematizada e potencial raramente é
explorado.
◦ No Brasil também tem sido muito utilizado (SBQS e MPS.BR)
 Tipos de Revisão de Software:
◦ Walkthroughs.
◦ Inspeções de Software.
5
Arilo Claudio Dias Neto
Walkthroughs
 Reuniões informais para avaliação dos produtos
 Pouca ou nenhuma preparação requerida
 O desenvolvedor guia os presentes através do
produto
 O objetivo é comunicar ou receber aprovação
 São úteis principalmente para requisitos e
modelos.
11/01/2014
4
Arilo Claudio Dias Neto
Walkthroughs
 Alternativa com um processo menos rigoroso do que o de
inspeções de software.
 Papéis sugeridos:
◦ Líder: conduz a revisão do artefato indicando os eventuais defeitos
identificados.
◦ Autor: profissional que criou o documento a ser revisado.
◦ Escrivão: toma nota dos eventuais defeitos sugeridos pelos
revisores.
◦ Revisores: quem irá ler o documento com o propósito de identificar
eventuais problemas que podem ser classificados futuramente
como defeitos.
7
Arilo Claudio Dias Neto
Walkthroughs
 Participantes – O autor seleciona os participantes, porém papeis
específicos não são estabelecidos.
 Passos:
◦ O líder seleciona os revisores, obtém o aceite do convite
e agenda a reunião.
◦ Normalmente, os participantes recebem o documento com certa
antecedência para efetuar sua leitura.
◦ É marcada uma reunião onde todos os revisores devem participar para
expor os problemas que identificaram.
◦ O líder apresenta o produto de trabalho aos inspetores durante a reunião.
◦ Durante a reunião devem interromper a apresentação caso encontrem
possíveis não-conformidades ou tenham comentários/sugestões.
◦ Baseado nas informações apresentadas o autor faz as devidas correções
◦ defeitos.
11/01/2014
5
Arilo Claudio Dias Neto
Walkthroughs
 Possuem custo aproximadamente igual ao de inspeções
mas seus resultados são inferiores (SEI, 2005):
◦ Não providenciam resultados mensuráveis;
◦ Não fornecem base para a aplicação de controle estatístico de
processos, necessário para evoluir na maturidade de processos de
software.
 Podem ser utilizados para atividades de brainstorming,
para explorar alternativas de projeto e resolução de
problemas.
◦ Inspeções são mais focadas em encontrar defeitos.
9
Arilo Claudio Dias Neto
Exercício Prático
 Revisar uma receita de bolo de chocolate
usando walkthrough
10
11/01/2014
6
Arilo Claudio Dias Neto
Fazendo um bolo de chocolate...
 Nossa meta é fazer um bolo de chocolate para o
aniversário do Joãozinho, só que não sei como
fazer...
 Que artefato me ajudaria a fazer um bolo?
◦ RECEITA DO BOLO
 Sem saber como fazer o bolo, como saber se a
receita de fato me ajudará?
◦ REVISAR A RECEITA
11
Arilo Claudio Dias Neto
Revisando a receita do bolo...
 Ingredientes
◦ 2 xícaras de chá de açúcar
◦ 1 1/2 xícara de chá de leite
◦ Ovos
◦ 100g de manteiga sem sal
◦ 1 xícara de chocolate em pó
◦ 1 xícara de suco de laranja
◦ 1/2 colher de sopa de fermento em pó
12
11/01/2014
7
Arilo Claudio Dias Neto
Revisando a receita do bolo...
 Modo de Preparo
1. Misture a manteiga com açúcar e bata por 5 minutos
2. Separe claras e gemas dos ovos e bata

Teste o Premium para desbloquear

Aproveite todos os benefícios por 3 dias sem pagar! 😉
Já tem cadastro?

Outros materiais