Copyright 2003 Rafael Marques. Todos os direitos reservados. [email protected] Estimando Projetos de...

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br

Estimando Projetos de Software Usando Pontos de Caso de Uso


Disciplina : Tópicos Avançados em Engenharia de Software III

Aluno: Rafael Marques - [email protected]

Universidade Federal de Pernambuco - Mestrado

Data: 10/12/2003

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Visão Geral Motivação

Introdução

Modelagem de Caso de Uso

Estimativas usando Pontos de Caso de Uso

Exercício

Referências

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Motivação

Medidas de tamanho de software

SLOC - Source Lines of Code

Pontos de Função - FP

Pontos de Caso de Uso - UCP Gustav Karmer 1993

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Introdução

Para processos de desenvolvimento dirigidos a Caso de Uso, logo no início do projeto já é disponibilizado um modelo de Caso de Uso.

Problema na variação de estilos, o que gera caos na comparação entre produtos de diferentes empresas. Deve haver uma padronização de estilos.

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Caso de Uso

[UML]

Um caso de uso (UC) representa a especificação de uma sequência de ações, que um sistema desempenha para produzir um resultado.

Algumas Características:

- É sempre iniciado por um ator- É completo- Provê valor a um ator

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


UCs são: Independente de tecnologia; Unidade de medida padrão para o software; Simples; Compreensível por não-técnicos; Utilizável desde o início do sistema.

Só podem ser utilizadas por empresas que adotem os casos de uso como forma de expressão de requisitos.

Introdução

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Caso de Uso

A identificação de Caso de Uso é feita através da colecta e análise dos requisitos.

Exemplos: “dar informação sobre produto”, “fazer encomenda”, “cancelar encomenda”

Questões p/ identificar use cases:

Que funções um ator vai querer do sistema? O sistema armazena informação?

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Atores

Definição

Um ator é um agente que interage com o sistema, um tipode usuário ou categoria com papel definido, podendo ser seres humanos, máquinas, dispositivos ou outros sistemas.

Exemplos de atores:

Cliente, usuário, gerente, computador, impressora, etc

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Atores Cada ator deve se comunicar com pelo menos 1 Caso de

Uso; São humanos, não humanos, ativos, passivos Questões p/ identificar actores

Quem utiliza o sistema? Quem está interessado nos resultados do sistema? Quem é responsável pela administração do sistema? Com que outros sistemas o sistema deve se comunicar? Quem fornece informação ao sistema? Quem necessita do sistema para poder realizar suas

atividades diárias?

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Modelagem de Casos de Uso

Definição

A modelagem de caso de uso é um técnica utilizada para descrever a funcionalidade de um sistema através de atores externos interagindo em casos de uso.

Modelo de Caso de Uso define o escopo funcional do sistema a ser desenvolvido.

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Modelagem de Casos de Uso Um modelo de Caso de Uso descreve as funções do

sistema e seu ambiente.

É formada por duas 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.

Um cenário representa uma sequência específica de ação ilustrando um comportamento.

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Modelagem de Casos de Uso

Um cenário é uma sequência de ações que ilustra um comportamento do sistema

No cenário descreve-se quando o use case interage com os atores

Tipo de cenário:

Principal: descreve a situação quando tudo corre bem (happy day scenario)

Alternativo ou secundário: permite uma sequência diferente de eventos em relação ao cenário principal (e.g. Exceções ou outras acções possíveis)

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Ex. Diagrama de UC

Cliente Fazer pedido

Sistema de Inventório

Consultar o pedido

Representante de Vendas

Cancelar o pedido

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Descrição de UC

Nome do UC: Fazer pedidoDescrição: O cliente fornece o endereço e os códigos do produtos

desejados. O sistema confirma a ordem.Fluxo Básico de Eventos:1.O cliente fornece nome e endereço2.O cliente fornece os códigos dos itens que deseja comprar3.O sistema fornece uma descrição e o preço de cada item4. O sistema calcula o total do pedido5.O cliente fornece as informações de seu cartão de crédito6.O sistema valida as informações7.O sistema confirma ao cliente o pedido

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Descrição do UC (Cont.)Fluxos Alternativos:

1.1 O produto está fora de estoque1.1.1 O sistema informa ao cliente que o respectivo produto está fora de estoque

2.1 Cartão de crédito inválido2.1.1 O sistema informa ao cliente que o cartão é inválido2.1.2 O cliente informa novamente as informações do cartão de crédito ou cancela o pedido.

Pre-Condições:O cliente está logado no sistema

Post-Condições:O pedido foi realizado

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Pontos de Caso de Uso

Histórico Desenvolvido por Gustav Karner [1993]

Foi desenvolvido baseado em Pontos de Função. Vantagem: Não precisa de tanto detalhes das

informações. Esse método tem sido avaliado através de

estudos de casos por empresas como: Mogul.com, Cap Gemini Ernst & Young, IBM,

Ericsson e Sun

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br



Atribuir peso aos atores

Atribuir peso aos Casos de Uso

Calcular o valor não ajustado dos UCP

Atribuir peso aos fatores técnicos

Atribuir peso aos fatores ambentais

Calcular o valor ajustado dos UCP

Estimar o esforço do Projeto

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br



Definições Fatores ambientais - Fatores referentes ao

nível de experiência da equipe de desenvolvimento.

Fatores técnicos - Fatores técnicos do projeto, referentes a arquitetura do sistema.

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Método de Estimativas1. Cada ator e UC são categorizados de acordo com

sua complexidade e atribuído um determinado peso

2. Pontos de UC sem ajustes são calculados a partir do somatório dos pesos para cada ator e UC do sistema

3. Pontos de UC são ajustados em função dos valores de 13 fatores técnicos e 8 fatores ambientais

4. Finalmente o UCP é multiplicado por um valor de produtividade

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Classificando Atores

Simples, médio e complexo

SIMPLES: sistemas que se comunicam via interface bem definida, por exemplo, API.

MÉDIO: sistemas que se comunicam através de algum tipo de protocolo, por exemplo, TCP/IP ou HTTP

COMPLEXO: pessoas interagindo através de interface gráfica ou Web Page

Obs: Fácil, Moderado, Difícil








Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Classificando Atores

UAW = Atores * Pesos

Tipo de Ator Descrição Peso QT. Atores Total

UAW - Unadjusted Actors Weight

Simples Interface (API) 1 2 2

Médio Protocolo 2 2 4

Complexo Interface Gráfica 3 4 12

18

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Classificando UC

Simples, médio e complexo SIMPLES: casos de uso com <= 3 de

transações MÉDIO: casos de uso com >=4 e <7

transações COMPLEXO: casos de uso com >=7

transações

Uma transação é um conjunto atômico de atividades. O número de transações pode ser determinado contando o número de passos do caso de uso, incluindo os fluxos alternativos.








Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Classificando UC

UUCW = UC* Peso

Tipo UC Descrição Peso QT. UC Total

UUCW - Unadjusted Use Case Weight

Simples 1 - 3 Transações 5 8 40

Médio 4 - 6 Transações 10 12 120

Complexo 7 - Transações 15 4 60

220

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Classificando UC

UUCW = UC* Peso

Tipo UC Descrição Peso QT. UC Total

UUCW - Unadjusted Use Case Weight

Simples 1 - 4 Classes 5 8 40

Médio 5 - 10 Classes 10 12 120

Complexo > 10 Classes 15 4 60

220

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Classificando UC

UUCP = UUCW + UAW

UUCW - Unadjusted Use Case Weight 220UUCP - Unadjusted Use Case Points 238

UAW - Unadjusted Actors Weight 18








Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Determinando Fatores TécnicosFator Descrição Peso Valor FatorT1 Sistema distribuído 2 0 0

T2 Tempo de resposta 1 3 3

T3 Eficiência p/ usuário 1 5 5

T4 Complexidade de processamento

1 1 1

T5 Reuso 1 0 0

T6 Fácil de instalar 0.5 5 2.5

T7 Fácil de usar 0.5 5 2.5

T8 Portável 2 0 0

T9 Fácil de mudar 1 4 4

T10 Concorrência 1 0 0

T11 Segurança 1 3 3

T12 Acesso direto 1 5 5

T13 Treinamento especial 1 1 1

Faixa de 0 a 5

Id.Fator Descrição Peso Valor FatorAtribuir peso

aos Casos de Uso







Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Determinando Fatores Técnicos

Technical Complexity Factor (TCF) = 0.6 + (0.01*TFactor)

TFactor = (Valor atribuído T)x(Peso T)

TFactor = 27

TCF = 0.6 + (0.01*27) TCF = 0.87

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br









Determinando Fatores Ambientais

Fator Descrição Peso Valor FatorE1 Familiaridade com o modelo usado 1.5 1 1.5

E2 Experiência na aplicação 0.5 4 2

E3 Experiência OO 1 1 1

E4 Capacidade do analista 0.5 5 2.5

E5 Motivação 1 5 5

E6 Requisitos estáveis 2 2 4

E7 Equipe em tempo parcial -1 3 -3

E8 Linguagem de programação -1 1 -1

Id.Fator Descrição Peso Valor Fator

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Determinando Fatores Ambientais

Environment Factor (EF) = 1.4 + (-0.03*EFactor)

EFactor = (Valor F1..F8)*Peso F

EFactor = 12

EF = 1.4 + (-0.03*12)EF = 0.755

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Determinando Pontos de UC

UCP = UUCP*TCF*EF

UCP = 237*0.87*0.755UCP = 155.637

Karner sugeriu 20 man-hours por ponto de UC

Man-hours = 155.637*20Man-hours = 3113.469








Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Variação para Determinar o Esforço Experiência na área de desenvolvimento tem

demonstrado que o esforço estimado para realização de UC está na faixa de 15-30 Homem-hora por UCP

Schneider e Winters Verificar os fatores de E1-E6 > 3 Verificar os fatores de E7-E8 < 3 Se o total for <=2, um UCP equivale a 20 Homem-

horas Se for >2 e <4, um UCP equivale a 28 Homem-horas Se for >4, reaviliar o projeto Outra possibilidade é ajustar um UCP para 36 Homem-

horas Planilha de Estimativas








Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Problemas Associados aos UCP

Variedade de estilo na especificação do UC Não existe padrão para especificar UC

Alguns especialistas da área desaconselham a derivação do esforço a partir dos UCP

Os requisitos não-funcionais não contribuem efetivamente no cálculo das estimativas

UCP não foi testado efitivamente em projetos de grande e médio porte Muito ajustes e pesquisas devem ser realizados

para comprovar efetivamente a eficácia do processo

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Exercício

Cop

yrig

ht 2

003

Raf

ael M

arqu

es. T

odos

os d

ireito

s res

erva

dos.

rm2@

cin.

ufpe

.br


Referências Karner, Gustav. Resource Estimation for Objectory Projects

Banerjee, Gautam. Use Case Points, An Estimation Approach. August, 2001. Url:

Smith, Jonh. The Estimation of Effort Based on Use Case, Rational Software white paper

Aguiar, Murício. Pontos de Função ou Pontos de Caso de Uso?

Galen, Robert. A Survey of Software Estimating & Planing Techniques, 2001.

Furlan, Jose. Modelagem de Obketos atraves da UML, Makron Books,1998

Anda, Bente, Comparing Efforc Estimates Based on Use Cases - Experience from Industry, In: 4Th International Conference on the Unified Modeling Language (UML2001).

Copyright 2003 Rafael Marques. Todos os direitos reservados. [email protected] Estimando Projetos de...

Documents

Transcript of Copyright 2003 Rafael Marques. Todos os direitos reservados. [email protected] Estimando Projetos de...