Aula 2 Documentos Iniciais de um Software - Estimativa Por Caso de Uso

Prévia do material em texto

O que são Métricas de Software?
 Uma métrica é a medição de um atributo 
(propriedades ou características) de uma 
determinada entidade (produto, processo ou 
recursos).
 Exemplos:
 Tamanho do produto de software (ex: Número 
de Linhas de Código – LOC)
 Número de pessoas necessárias para preparar a 
especificação técnica de uma aplicação.
 Número de defeitos encontrados no documento 
de requisitos do software
 Exemplos:
 Tempo, em dias, para realizar a 
programação de um sistema
 Custo, em R$, para a realização de uma 
tarefa
 Grau de satisfação do cliente com um 
determinado software (muito satisfeito, 
satisfeito, pouco satisfeito)
 Avaliar a produtividade do processo de 
desenvolvimento
 Melhorar a gerência de projetos e o 
relacionamento com clientes
 Reduzir frustrações e pressões de cronograma
 Gerenciar contratos de software
 Indicar a qualidade de um produto de software.
 Avaliar os benefícios (em termos de 
produtividade e qualidade) de novos métodos e 
ferramentas de engenharia de software
 Avaliar retorno de investimento
 Qual o produto do trabalho? 
 –Obter um conjunto de métricas (tempo, custo, 
recurso) de software que nos forneça uma idéia 
do processo e entendimento do projeto.
1. Tempo, em dias, para realizar a programação 
de um sistema
2. Custo, em R$, para a realização de uma 
tarefa.
3. Grau de satisfação do cliente com um 
determinado software (muito satisfeito / 
satisfeito / pouco satisfeito) 
 Medida 
 •Fornece uma indicação quantitativa da extensão, quantidade, 
dimensão, capacidade ou tamanho de algum atributo de um 
produto, ou de um processo (PRESSMAN,2002) 
 •Ex: Quantidade de Funcionalidades de um sistema, quantidade de 
telas, etc. 
 Medição 
 •É o ato de determinação de uma medida
 •Ex: Em um sistema acadêmico foram encontrados 10 telas, 40 
funções e 10 tabelas de dados.
 Ex.: custo, esforço, número de linhas de código, número de 
páginas, número de diagramas e número de defeitos.
 Tamanho – Quantidade de software a ser produzida – 
Ex. número de linhas de código, número de requisitos 
funcionais, número de casos de uso 
 Esforço – Derivado da estimativa de tamanho – Ex. 
estimativa de tamanho X produtividade (qtde diagramas 
X tpo gasto para 1 analista preparar 1 diagrama = 
esforço (dias) 
 Prazo – Geralmente é baseado em datas requisitadas 
pelo cliente • Qualidade – Medidas de resultados – Ex. 
defeitos por fase, esforço de mudanças.
 Indicador 
 •É uma métrica ou a combinação delas, que fornece 
compreensão do processo de software, de um projeto 
ou do produto 
 •Um indicador fornece compreensão que possibilita ao 
gerente de projeto ou aos engenheiros de software 
ajustar o processo, projeto ou produto para tornar as 
coisas melhores. 
 Ex: Foi constatado que um formulário de coleta de 
requisitos A otimiza o trabalho , economizando 20% do 
tempo em relação ao formulário B, logo, o formulário A 
será adotado como padrão em medições futuras 
 Uma vez calculados, os pontos por função 
são usados como forma de normalizar 
medidas de produtividade, qualidade e 
outros atributos de software. Tais como:
 Erros por FP
 Defeitos por FP
 $ por FP
 Páginas de documentação por FP
 FP por mês.
 obter auto-conhecimento (interna)
 atender a uma pressão imediata (externa)
 preparar-se para o futuro (tendência)
 Indicar a qualidade do produto; 
 Avaliar a produtividade dos que desenvolvem o 
produto; 
 Determinar os benefícios derivados de novos 
métodos e ferramentas de engenharia de 
software; 
 Formar uma base para as estimativas futuras; 
 Ajudar na justificativa de aquisição de novas 
ferramentas ou de treinamentos adicionais; 
 Foi proposto em 1993 por Gustav Karner;
 Baseou-se na Análise por Pontos de 
Função;
 Trata de estimar o tamanho de um 
sistema de acordo com:
◦ o modo como os usuários o utilizarão;
◦ a complexidade de ações requerida por cada 
tipo de usuário;
◦ uma análise em alto nível dos passos 
necessários para a realização de cada tarefa;
 Caso de uso são:
◦ Independente de tecnologia;
◦Unidade de medida padrão para o 
software;
◦ Simples;
◦Consistente e intercambiável;
◦Compreensível por não-técnicos;
◦Utilizável desde o início do sistema
◦Um caso de uso (UC) representa a
especificação de uma sequência
de ações, 
◦ incluindo variantes, que o sistema
pode executar quando interagindo
com os atores do sistema.
◦Um ator representa qualquer
entidade que interage com o 
sistema.
 Um modelo de UC descreve as funções do 
sistema e seu ambiente. 
 Constitui de 2 partes:
1. Um diagrama que fornece uma visão geral
dos atores e os UCs bem como suas
interações.
2. A descrição dos UCs detalhando os
requisitos e documentando o fluxo de 
eventos entre os atores e o sistema (Caso de 
uso Extendido).
 Um cenário representa uma sequência
específicade de ação ilustrando um 
comportamento - ilustra uma interação de uma
instância do UC.
Cliente
Fazer pedido
Sistema de 
Inventório
Consultar o pedido
Representante de 
Vendas
Cancelar o pedido
Elementos utilizado no cálculo
 Passo 1: Cálculo do UAW (Unadjusted Actor 
Weight – Peso do ator não ajustado)
Tipo de Ator Peso Descrição 
Ator Simples 1 Outro sistema acessado através de uma 
API de programação
Ator Médio 2 Outro sistema acessado interagindo através 
da rede ou de um protocolo de 
comunicação como TCP/IP, FTP, ou 
mesmo através de linha de comando
Ator Complexo 3 Um usuário interagindo através de uma 
interface gráfica (Web)
 No caso do exemplo:
Tipo de Ator Peso Nº de atores Resultado 
Ator Simples 1 0 0
Ator Médio 2 1 2
Ator Complexo 3 2 6
Total UAW 8
Valores já calculados: UAW = 8
Cliente
Fazer pedido
Sistema de 
Inventório
Consultar o pedido
Representante de 
Vendas
Cancelar o pedido
1 Ator Médio: Sistema de 
Inventário
2 Ator complexo: Cliente e 
Representante de vendas
 Passo 2: Cálculo do UUCW (Unadjusted Use 
Case Weight - Peso do caso de uso não 
ajustado)
◦ Para fins de cálculo, dividimos os casos de uso em três
níveis de complexidade:
Caso de Uso Descrição Peso
Simples
< 3 transações ou < 5 classes de análise ou 
Entidades
5
Médio
4-7 transações ou 5 a 10 classes de análise ou 
Entidades
10
Complexo
> 7 transações ou > 10 classes de análise ou 
Entidades
15
Observação: Incluir na contagem os passos alternativos.
 Passo 2: Cálculo do UUCW (Peso do caso de uso 
não ajustado)
 Contagem de Transações
 O que é uma transação? 
 –“É um conjunto de atividades atômicas, as 
quais são executadas completamente ou não”; 
 –“É um evento que ocorre entre o ator e o 
sistema”; 
 –“São passos dos fluxos de eventos de casos de 
uso, que deve ser executado por completo, ou a 
realização de algum processamento complexo”; 
 Passo 2: Cálculo do UUCW (Peso do caso de uso 
não ajustado)
 Contagem de Transações
 O que contar? 
 –passos que contenham campos de entrada 
possuindo valores passíveis de escolha 
originados de leitura de dados (listas de 
opções, combos e grids); 
 –passos que apresentem retorno de consultas 
com filtros preenchidos por buscas em bancos 
de dados; 
 Passo 2: Cálculo do UUCW (Peso do caso de uso 
não ajustado)
 Contagem de Transações
 O que contar? 
 –passos que proporcionem validações 
complexas de negócio; 
 –passos que contenham uma geração de 
relatório são considerados como uma transação, 
e cada filtro originado da leitura de dados das 
consultas será considerado uma outra 
transação; 
 Passo 2: Cálculo do UUCW (Peso do caso de uso 
não ajustado)
 Contagem de Transações
 O que contar? 
passos onde existirem validações simples de campo 
de entrada de dados são considerados como uma 
única transação, se a quantidade de validações for 
menor ou igual a 10. 
Se a quantidade de validações for maior que 10, 
conta-se uma transação a cada grupo de 5 
validações; 
 Exemplo hipotético:
 Concluímos após analisar todos os casos de 
uso de umexemplo hipotético: 7 casos de 
uso simples, 13 casos de uso Médios e 3 
casos de uso Complexos.
Tipo Peso Nº de Casos de Uso Resultado 
Simples 5 7 35
Médio 10 13 130
Complexo 15 3 45
Total UUCW 210
Valores já calculados: UAW = 8 (Atores) , UUCW (transações) = 210
Passo 1 (Ator) + Passo 2 (Caso de uso)
 Passo 3: Cálculo do UUCP (Pontos de caso de uso 
não ajustados - Unadjusted Use Case Points)
UUCP = UAW + UUCW
Pontos de caso de uso = Peso do ator + Peso do 
caso de uso
 No caso do exemplo:
UUCP = 8 + 210 = 218
Valores já calculados: UAW (atores) = 8, UUCW (transações)= 210, UUCP (caso de uso não 
ajustados) = 218
 Calculando fatores de ajuste:
◦O método de ajuste é bastante 
similar ao adotado pela Análise por 
Pontos de Função e é constituído de 
duas partes:
 Cálculo de fatores técnicos: cobrindo 
uma série de requisitos funcionais do 
sistema;
 Cálculo de fatores de ambiente: 
requisitos não-funcionais associados ao 
processo de desenvolvimento;
 Passo 4: Cálculo do 
Tfactor
◦ Para cada requisito 
listado na tabela, deve 
ser atribuído um valor 
que determina a 
influência do requisito 
no sistema, variando 
entre 0 e 5;
◦ 0 – não 
◦ 1 – pouco 
◦ 2 – razoável 
◦ 3 - médio 
◦ 4 - muito 
◦ 5 - elevado
Fator Requisito Peso
T1 Sistema distribuído 2
T2 Tempo de resposta 2
T3 Eficiência 1
T4 Processamento complexo 1
T5 Código reusável 1
T6 Facilidade de instalação 0.5
T7 Facilidade de uso 0.5
T8 Portabilidade 2
T9 Facilidade de mudança 1
T10 Concorrência 1
T11 Recursos de segurança 1
T12 Acessível por terceiros 1
T13 Requer treinamento especial 1
 No caso do exemplo:
Fator Requisito Peso Influência Resultado
T1 Sistema distribuído 2 1 2
T2 Tempo de resposta 2 3 6
T3 Eficiência 1 3 3
T4 Processamento complexo 1 3 3
T5 Código reusável 1 0 0
T6 Facilidade de instalação 0.5 0 0
T7 Facilidade de uso 0.5 5 2.5
T8 Portabilidade 2 0 0
T9 Facilidade de mudança 1 3 3
T10 Concorrência 1 0 0
T11 Recursos de segurança 1 0 0
T12 Acessível por terceiros 1 0 0
T13 Requer treinamento especial 1 0 0
Tfactor 19,5
 Passo 5: Cálculo do TCF (Fator de 
Complexidade Técnica - Technical 
Complexity Factor)
TCF = 0.6 + (0.01  Tfactor)
 No caso do exemplo:
TCF = 0.6 + (0.01  19.5) = 0.795
Valores já calculados: UUCP = 218, Tfactor = 19.5, TCF = 0.795
 Passo 6: Cálculo do 
Efactor
◦ Para cada requisito 
listado na tabela, deve 
ser atribuído um valor 
que determina a 
influência do requisito 
no sistema, variando 
entre 0 e 5;
◦ 0 – não 
◦ 1 – pouco 
◦ 2 – razoável 
◦ 3 - médio 
◦ 4 - muito 
◦ 5 - elevado
Fator Descrição Peso
E1
Familiaridade com RUP ou 
outro processo formal
1.5
E2
Experiência com a aplicação 
em desenvolvimento
0.5
E3
Experiência em Orientação a 
Objetos
1
E4
Presença de analista 
experiente
0.5
E5 Motivação 1
E6 Requisitos estáveis 2
E7
Desenvolvedores em meio-
expediente
-1
E8
Linguagem de programação 
difícil 
-1
 No caso do exemplo:
Fator Descrição Peso Influência Resultado
E1
Familiaridade com RUP ou outro 
processo formal
1.5 5 7.5
E2
Experiência com a aplicação em 
desenvolvimento
0.5 0 0
E3 Experiência em Orientação a Objetos 1 5 5
E4 Presença de analista experiente 0.5 5 2.5
E5 Motivação 1 5 5
E6 Requisitos estáveis 2 3 6
E7 Desenvolvedores em meio-expediente -1 0 0
E8 Linguagem de programação difícil -1 0 0
Efactor 26
Valores já calculados: UUCP = 218, TCF = 0.795, Efactor = 26
 Passo 7: Cálculo do ECF (Fator de 
Complexidade Ambiental - Environmental 
Complexity Factor)
ECF = 1.4 + (-0.03  Efactor)
 No caso do exemplo:
ECF = 1.4 + (-0.03  26) = 0.62
Valores já calculados: UUCP = 218, TCF = 0.795, Efactor = 26, ECF = 
0.62
 Passo 8: Cálculo dos UCP (Use Case Points)
UCP = UUCP  TCF  ECF
Pontos por caso de uso = Pontos de caso de uso 
não ajustados X Fator de Complexidade Técnica 
X Fator de Complexidade Ambiental 
 No caso do exemplo:
ECF = 218  0.795  0.62 = 107.45 ou 108 Use 
Case Points
Valores já calculados: UUCP = 218, TCF = 0.795, ECF = 0.62
 Passo 9: Cálculo do tempo de trabalho 
estimado
◦ Para simplificar, utilizaremos a média de 20 horas 
por Ponto de Casos de Uso
 No caso do exemplo:
Tempo estimado = 108 * 20 = 2160 horas de 
trabalho
Valores já calculados: UCP = 108
	Slide 1: Documentos Iniciais de um Software Engenharia de Requisitos
	Slide 2: Documentos Iniciais de um Software Engenharia de Requisitos
	Slide 3: O que são Métricas de Software?
	Slide 4: O que são Métricas de Software?
	Slide 5: Por que Medir Software?
	Slide 6: Estimativas baseada em casos de uso
	Slide 7: O que são métricas?
	Slide 8: O que significa?
	Slide 9: Tipos de estimativa
	Slide 10: O que significa?
	Slide 11: Indicadores por ponto de função?
	Slide 12: Por que medir ?
	Slide 13: Pontos por Caso de Uso
	Slide 14: Motivação
	Slide 15: Tipos de Estimativas de Software
	Slide 16: Caso de Uso
	Slide 17: Modelagem de Casos de Uso
	Slide 18: Ex. Diagrama de UC
	Slide 19: Pontos de caso de uso
	Slide 20: Passo 1: Cálculo do UAW (Unadjusted Actor Weight – Peso do ator não ajustado)
	Slide 21: Pontos por Caso de Uso
	Slide 22: Pontos por Caso de Uso
	Slide 23: Passo 2: Cálculo do UUCW Peso do caso de uso não ajustado. (Unadjusted Use Case Weight )
	Slide 24: Pontos por Caso de Uso
	Slide 25: Pontos por Caso de Uso
	Slide 26: Pontos por Caso de Uso
	Slide 27: Pontos por Caso de Uso
	Slide 28: Pontos por Caso de Uso
	Slide 29
	Slide 30: Pontos por Caso de Uso
	Slide 31: Passo 3: Cálculo do UUCP (Pontos de caso de uso não ajustados - Unadjusted Use Case Points)
	Slide 32: Pontos por Caso de Uso
	Slide 33: Pontos por Caso de Uso
	Slide 34: Cálculo de fatores técnicos - Tfactor
	Slide 35: Pontos por Caso de Uso Cálculo de fatores técnicos - Tfactor
	Slide 36: Pontos por Caso de Uso
	Slide 37: Passo 5: Cálculo do TCF (Fator de Complexidade Técnica - Technical Complexity Factor)
	Slide 38: Pontos por Caso de Uso
	Slide 39: Cálculo de fatores de ambiente Efactor
	Slide 40: Pontos por Caso de Uso Cálculo de fatores de ambiente Efactor 
	Slide 41: Pontos por Caso de Uso
	Slide 42: Passo 7: Cálculo do ECF (Fator de Complexidade Ambiental - Environmental Complexity Factor)
	Slide 43: Pontos por Caso de Uso
	Slide 44: Passo 8: Cálculo dos UCP (Pontos de caso de Uso - Use Case Points)
	Slide 45: Pontos por Caso de Uso
	Slide 46: Pontos por Caso de Uso