ucp_ use case points

8/6/2019 UCP_ Use Case Points

1/21

PLATAFORMA DE DESENVOLVIMENTO PINHO PARAN

MTRICA PARA ESTIMATIVA DE PROJETOS UCP

Agosto/2006


2/21

Sumrio de Informaes do Documento

Tipo do Documento: Definio

Ttulo do Documento: Mtrica para estimativa de projetos - UCP

Estado do Documento: Elaborado

Responsveis: Danielle Mayer

Palavras-Chaves: Mtricas, UCP, Framework

Resumo: Documento que apresenta o mtodo UCP (use case points) para estimativas de projeto

Nmero de pginas: 21

Software utilizados: Oppen Office

Verso Data Mudanas

1.0 02/01/06 Elaborao

1.0 13/04/06 Atualizao

1.0 06/09/06Reviso


3/21

SUMARIO

1 INTRODUO...................................................................................................................................................4

2 UCP - USE CASE POINTS................................................................................................................................4

A)CALCULARO UUCP(UNADJUSTED USE CASE POINT):............................................................................................5B)CALCULARO TCF(TECHNICAL COMPLEXITY FACTOR):............................................................................................6C)CALCULARO EF (ENVIRONMENTAL FACTOR)........................................................................................................13D)CALCULARO UCP (USE CASE POINTS)...............................................................................................................16E)ESTIMAROPROJETOEMHORAS.............................................................................................................................16

3 ESTUDOS DE CASOS (UCP).........................................................................................................................16

A)ESTUDOSDE CASOSAPRESENTADOSNOARTIGODE GUSTAV KARNER.........................................................................16B)ESTUDOSDE CASOSAPRESENTADOSNOARTIGODEVIVIANEHEIMBERG E EVERALDOARTURGRAHL................................18

4 CONCLUSO...................................................................................................................................................20

5 REFERNCIAS................................................................................................................................................20


4/21

4

1 INTRODUO

O uso do Framework Pinho prope uma especificao mais detalhada do sistema a ser

desenvolvido, gerando desta forma a impresso errnea que o a utilizao de seus padres

aumentam o tempo de especificao de um sistema, o que no verdade, o Framework define

os produtos/modelos/materiais de apoio para orientar e auxiliam o trabalho da equipe de

desenvolvimento visando a padronizao e qualidade.

O que acontecia antes da implantao do Framework era que a especificao de um sistemalimitava se a regras de neg cio fase de An lise sem a realizao da fase de Projeto, por

isso, tem se a impress o de que hoje existe uma considervel demora na especificao de

sistemas. Aquela prtica com certeza aumentava o tempo de Construo, j que a Fase de

Projeto ficava embutida na Construo, e prejudicava a abstrao do reuso de componentes.

A estimativa de tempo para realizar um determinado sistema depende da complexidade e

tamanho do sistema a ser desenvolvido. Esta estimativa pode ser realizada a partir da

aplicao de mtricas, como por exemplo, UCP Use Case Points.

possvel determinar a estimativa do desenvolvimento de um sistemas atravs de base

histrica de outros desenvolvimentos. A base histrica pode auxiliar tambm na determinao

do ndice de converso de UCP para horas.

O prximo tpico deste documento visa apresentar como realizado o clculo atravs do

mtodo UCP Use Case Points.

PLATAFORMA DE DESENVOLVIMENTO PINHO PARAN - CELEPAR


5/21

2 UCP USE CASE POINTS

Mtodo criado por Gustav Karner, em 1993, para medir projetos de software orientado a

objetos. Este mtodo permite mensurar projetos baseado no modelo de caso de uso o que

permite realizar a estimativa logo no incio dos projetos, durante o levantamento de requisitos.

Alm da avaliao do modelo de casos de uso so considerados fatores de complexidade

tcnica(TCF), cuja finalidade determinar o grau de complexidade do projeto a ser

construdo, e fatores ambientais(EF), cuja finalidade determinar a eficincia do projeto e o

nvel de experincia dos profissionais relacionados.

Os passos para realizar esta medio so descritos abaixo:

A)Calcular o UUCP(Unadjusted Use Case Point):

Relacionar e classificar os atores envolvidos, de acordo com o nvel de complexidaderepresentado abaixo:

Relacionar e classificar os casos de usos, de acordo com o n vel de complexidaderepresentado abaixo:

Complexidade Definio Peso

Simples 1

Mdio 2

Complexo 3

Quando o ator representa um sistemaexterno que acessado atravs deAPI(Application Programming Interface)

Quando o ator representa um sistemaexterno, acessado atravs de um protocolode comunicao(por exemplo: TCP/IP)

Quando o ator interage com o sistemaatravs de uma inteface grfica(GUI)


6/21

Calcular efetivamente o UUCP, como segue:

UUCP = Total de pesos dos atores relacionados + Total de pesos dos casos de uso

relacionados.

B)Calcular o TCF(Technical Complexity Factor):

Atribuir um valor a cada fator numa escala de 0 a 5, onde 0 significa que o fator irrelevante e 5 significa que essencial. Se o fator no importante e no irrelevantedeve se atribuir valor 3.

Multiplicar o Valor(Fator) atribudo pelo respectivo peso (coluna resultado)

Totalizar o resultado da multiplicao ( TFator)

Complexidade Definio Peso

Simples 5

Mdio 10

Complexo 15

Quando o caso de uso possui 3 ou menostransaes, incluindo cenrios alternativos, e suarealizao deve acontecer menos de 5objetos(classes de anlise)

Quando o caso de uso possui de 4 a 7 transaes,incluindo cenrios alternativos, e sua realizaodeve acontecer com 5 a 10 objetos(classes deanlise)

Quando o caso de uso possui mais de 7 transaes,incluindo cenrios alternativos, e sua realizaodeve acontecer com mais de 10 objetos(classes deanlise)

Descrio do fator Peso Resultado

F1 Sistema distribudo 2 0F2 Performance 1 0F3 Eficincia para o usurio final (online) 1 0F4 Processamento interno complexo 1 0F5 Cdigo deve ser reusvel 1 0F6 Fcil para instalar 0,5 0

F7 Fcil para usar 0,5 0F8 Portvel 2 0F9 Fcil para mudar 1 0F10 Concorrente 1 0F11 Seguro 1 0

F12 1 0

F13 1 0

CdigoFator

Valor(Fator)

Fornece acesso direto para third parties(sistemas/componentes externos)

requerido treinamento do usuriopara usar o software


7/21

Calcular o fator de complexidade de acordo com a seguinte formula:

TCF = 0.6 + (0.01 * Tfator)

Segue abaixo uma lista de caractersticas para alguns dos fatores de complexidade tcnica,

com o objetivo de auxiliar a definio de seu respectivo valor:

F1 Sistema Distribudo: Dados ou Processamento distribudo entre vrias unidades de

processamento CPU

0 ( ) A aplicao no auxilia na transferncia de dados ou processamento entre asCPUs da instalao.

1 ( ) A aplicao prepara dados para o usurio final processar em outra CPU dainstalao. Por exemplo, planilhas eletrnicas ou gerenciadores de banco de dados dePC.

2 ( ) Os dados so preparados para transferncia, transferidos e processados em umaoutra CPU da instalao (mas NO para processamento pelo usurio final como visto

no item 1).

3 ( ) Processamento distribudo e transferncia de dados on line apenas em umadireo.

4. ( ) Processamento distribudo e transferncia de dados on line em ambas dire es.

5 ( ) As funes de processamento so executadas dinamicamente na CPU maisapropriada.

F2 Performance: Identifica os objetivos de performance da aplicao estabelecidos e

aprovados pelo usurio

0 ( ) Nenhuma exigncia especial de performance foi fixada pelo usurio.

1 ( ) Requisitos de performance foram estabelecidos e revisados, mas nenhuma ao

especial foi necessria.

2 ( ) O tempo de resposta crtico durante as horas de pico. O intervalo de tempo


8/21

limite (deadline) do processamento sempre para o prximo dia til. Nenhumaconsiderao especial para utilizao de CPU foi requerida.

3 ( ) O tempo de resposta crtico durante todo o horrio de utilizao. Os requisitosde prazo de processamento com outros sistemas so limitantes. No foi necessrionenhum procedimento especial para utilizao de CPU.

4. ( ) Os requisitos de performance estabelecidos pelo usurio so rigorosos o bastantepara requerer tarefas de anlise de performance na fase de anlise e projeto daaplicao.

5 ( ) Alm do descrito no item 4, ferramentas de anlise de performance foram usadasnas fases de projeto, desenvolvimento e/ou implementao a fim de proporcionar aperformance estabelecida pelo usurio.

F3 Efici ncia para o usurio final (online): As funes online fornecidas enfatizam um

projeto da aplicao voltado para a eficincia do usurio final.

Menus

Documentao/Help online

Movimento automtico do cursor

Movimento de Tela (scrolling) vertical e horizontal

Impresso remota (via transaes online)

Teclas de Funo prdefinidas Execuo de jobs batch a partir de transaes online

Seleo de dados da tela via movimentao do cursor

Uso intenso de vdeo reverso, brilho intensificado, sublinhado, cores e outros recursos devdeo

Documentao de transaes online via hardcopy

Interface para mouse

PopUp Windows

O mnimo possvel de telas para executar as funes do negcio

Fcil navegao entre telas (por exemplo, atravs de teclas de funo)

Suporte bilnge (suporta dois idiomas, contar como quatro itens)

Suporte multilinge (suporta mais de dois idiomas, contar como seis itens)

0 ( ) A aplicao no apresenta nenhum dos itens acima.

1 ( ) Apresenta de 1 a 3 dos itens acima.

2 ( ) Apresenta de 4 a 5 dos itens acima.


9/21

3 ( ) Apresenta 6 ou mais dos itens acima, mas no h nenhum requisito do usuriorelacionado eficincia.

4. ( ) Apresenta 6 ou mais dos itens acima, e os requisitos estabelecidos para efici nciado usurio so rigorosos o suficiente para que a fase de projeto da aplicao incluafatores para: minimizar a digitao, maximizar os defaults, , utilizar templates etc.

5. ( ) Apresenta 6 ou mais dos itens acima, e os requisitos estabelecidos para efici nciado usurio so rigorosos o suficiente para que seja necessrio o uso de ferramentas eprocessos especiais para demonstrar que os objetivos de eficincia foram alcanados.

F4 Processamento interno complexo A complexidade de processamento influncia no

dimensionamento do sistema, e, portanto, deve ser quantificado o seu grau de influncia com,

base nas seguintes categorias:

Processamento especial de auditoria e/ou processamento especial de segurana

Processamento lgico extensivo.

Processamento matemtico extensivo.

Grande quantidade de processamento de excees, resultante de transaes incompletasque necessitam de reprocessamento. Por exemplo: transaes incompletas de ATMscausadas por interrupes de comunicao, valores de dados ausentes ou validaes deerros.

Processamento complexo para manipular mltiplas possibilidades de entrada/sada. Porexemplo: mltiplos meios e independncia de equipamentos.

0 ( ) No apresenta nenhum dos itens acima.

1 ( ) Apresenta um dos itens acima.

2 ( ) Apresenta dois dos itens acima.

3 ( ) Apresenta trs dos itens acima.

4 ( ) Apresenta quatro dos itens acima.

5 ( ) Apresenta todos os itens acima.

F 5 Cdigo deve ser reusvel A aplicao e o s e u cdigo foram especificamente

projetados, desenvolvidos e suportados para serem reutilizados em outras aplicaes


10/21

0 ( ) No apresenta cdigo reutilizvel

1 ( ) O cdigo reutilizvel usado somente dentro da aplicao.

2 ( ) Menos de 10% da aplicao foi feita, levando se em conta a sua utiliza o poroutras aplicaes

3 ( ) 10% ou mais da aplicao foi feita, levando se em conta a sua utiliza o poroutras aplicaes.

4. ( ) A aplicao foi projetada e documentada para facilitar a reutilizao de cdigo ea aplicao customizada

pelo usurio a nvel do cdigo fonte.

5. ( ) A aplicao foi projetada e documentada para facilitar a reutilizao de cdigo

F6 Fcil para instalar Indica o nvel de preparao de procedimentos e ferramentas para

instalao do sistema

0 ( ) Nenhuma considerao especial foi feita pelo usurio e nenhum procedimentoespecial foi requerido instalao.

1 ( ) Nenhuma considerao especial foi feita pelo usurio, mas um procedimentoespecial foi requerido para instalao.

2 ( ) Requisitos de instalao foram fixados pelo usurio.

3 ( ) Requisitos de instalao foram fixados pelo usurio e roteiros de instalao forampreparados e testados.

4. ( ) Alm do descrito no item 2, ferramentas automatizadas de instalao forampreparadas e testadas.

5. ( ) Alm do descrito no item 3, ferramentas automatizadas de instalao forampreparadas e testadas.

F7 Fcil para usar (Facilidade operacional) Procedimentos efetivos de inicializao,

backup e recuperao foram desenvolvidos e testados. A aplicao minimiza a necessidade de

atividades manuais, tais como montagem de fitas magnticas,manuseio de formulrios e

interveno manual do operador

0 ( ) Nenhuma considerao especial sobre facilidade operacional, alm dos

procedimentos normais de backup,foi feita pelo usurio.1 ( ) Procedimentos eficientes de inicializao, backup e recuperao forampreparados, mas a interveno do operador necessria.


11/21

2 ( ) Procedimentos eficientes de inicializao, backup e recuperao forampreparados, mas nenhuma interveno do operador necessria (contar como doisitens).

3 ( ) A aplicao minimiza a operao de montagem de fitas magnticas.

4 ( ) A aplicao minimiza a necessidade de manuseio de formulrios.5. ( ) A aplicao foi projetada para no precisar de interveno do operador no seufuncionamento normal. Apenas a inicializao e parada do sistema ficam a cargo dooperador. A recuperao automtica de erros uma caracterstica da aplicao.

F8 Portvel: A aplicao foi especificamente projetada, desenvolvida e suportada para ser

instalada em mltiplas plataformas (Windows, Unix, Linux, etc)

0 ( ) Nenhuma solicitao do usurio para considerar a necessidade de instalar aaplicao em mais de uma plataforma

1 ( ) Necessidade de instalao em mltiplas plataformas foi levada em consideraono projeto do sistema e a aplicao foi projetada para operar somente em ambientes

idnticos de hardware e software2 ( ) Necessidade de instalao em mltiplas plataformas foi levada em consideraono projeto do sistema e a aplicao foi projetada para operar somente em ambientessimilares de hardware e software

3 ( ) Necessidade de instalao em mltiplas plataformas foi levada em consideraono projeto do sistema e a aplicao foi projetada para operar inclusive em plataformasdiferentes.

4. ( ) Um plano de documentao e manuteno foi elaborado e testado para suportar a

aplicao em mltiplas plataformas e a aplicao atende aos itens 1 e 2.

5. ( ) Um plano de documentao e manuteno foi elaborado e testado para suportar aaplicao em mltiplas plataformase a aplicao atende ao item 3.

F9 F cil para mudar:A aplicao foi especificamente projetada, desenvolvida para suportar

manuteno, visando facilidade de mudanas. Por exemplo:

capacidade de consultas/relatrios flexveis est disponvel


12/21

dados de controle do negcio so agrupados em tabelas passveis de manuteno pelousurio.

0 ( ) Nenhum requisito especial do usurio para projetar a aplicao, visandominimizar ou facilitar mudanas.

1 ( ) fornecido recurso da consulta/relatrios flexveis capaz de manipularsolicitaes simples de consulta (query\requests). Por exemplo: lgica de and/oraplicada a somente um Arquivo Lgico Interno (contar como um item).

2 ( ) fornecido recurso de consulta/relatrios flexveis capaz de manipularsolicitaes de consulta (query\requests) de mdia complexidade. Por exemplo: lgicade and/or aplicada a mais de um Arquivo Lgico Interno (contar como dois itens).

3 ( ) fornecido recurso de consulta/relatrios flexveis capaz de manipularsolicitaes complexas de consulta (query\requests). Por exemplo: combinaes delgica de and/or aplicadas a um ou mais Arquivos Lgicos Internos (contar como trsitens).

4 ( ) Dados de controle so mantidos em tabelas que so atualizadas pelo usurioatravs de processos on line e interativos, mas as altera es s so efetivadas noprximo dia til.

5 ( ) Dados de controle so mantidos em tabelas que podem ser atualizadas pelousurio atravs de processos on line e interativos e as altera es so efetivadasimediatamente (contar como dois itens)

F10 Concorrente: Indica o volume de acesso simultneo a aplicao.

0 ( ) No esperado acesso simultneo

1 ( ) So esperados acessos simultneos esporadicamente

2 ( ) Acessos simultneos so esperados.

3 ( ) Acessos simultneos so esperados diariamente

4 ( ) Muitos acessos simultneos foram fixados pelo usurio para a aplicao, o quefora a execuo de tarefas de anlise de performance na fase de projeto da aplicao.

5 ( ) Requer o uso de ferramentas controle de acesso nas fases de projeto

desenvolvimento e/ou implantao, alm das consideraes acima.

F11 Seguro (Caractersticas especiais de segurana): Indica o nvel de segurana exigido

pela aplicao.

0 ( ) Nenhuma solicitao do usurio para considerar a necessidade de controle de


13/21

segurana da aplicao

1 ( ) Necessidade de controle de segurana foi levada em considerao no projeto dosistema

2 ( ) Necessidade de controle de segurana foi levada em considerao no projeto do

sistema e a aplicao foi projetada para ser acessada somente por usurios autorizados3 ( ) Necessidade de controle de segurana foi levada em considerao no projeto dosistema e a aplicao foi projetada para ser acessada somente por usurios autorizados.O acesso ser controlado e auditado.

4. ( ) Um plano de segurana foi elaborado e testado para suportar o controle de acessoa aplicao.

5. ( ) Um plano de segurana foi elaborado e testado para suportar o controle deacesso a aplicao e a auditoria.

F13 requerido treinamento do usurio para usar o software: Indica o nvel de

facilidade de treinamento de usurios

0 ( ) Nenhuma solicitao do usurio para considerar a necessidade de treinamentoespecial

1 ( ) Necessidade de treinamento especial foi levada em considerao no projeto dosistema

2 ( ) Necessidade de treinamento foi levada em considerao no projeto do sistema e aaplicao foi projetada para ser acessada com facilidade pelos usurios

3 ( ) Necessidade de treinamento especial foi levado em considerao no projeto dosistema e a aplicao foiprojetada para ser utilizada por usurios de diversos nveis

4 5 ( ) Um plano de treinamento foi elaborado e testado para facilitar o uso daaplicao

C)Calcular o EF (Environmental Factor)

Atribuir um valor a cada fator numa escala de 0 a 5, onde 0 significa que o fator irrelevante e 5 significa que essencial. Se o fator no importante e no irrelevantedeve se atribuir valor 3.


14/21

Multiplicar o Valor(Fator) atribudo pelo respectivo peso (coluna resultado) Totalizar o resultado da multiplicao ( EFator)

Calcular o fator de complexidade de acordo com a seguinte formula:

EF = 1.4 + ( 0.03 * EFator)

Segue abaixo uma lista de caractersticas para os fatores ambientais que visam auxiliar a

definio de seu respectivo valor:

F1 Familiaridade com o processo de desenvolvimento orientado a objetos adotado:

Indica a experincia da equipe com o processo/mtodo utilizado para desenvolvimento do

projeto.

0 ( ) A equipe no familiar com o processo de desenvolvimento de software

1 ( ) A equipe tem conhecimento terico do processo de desenvolvimento de software

2 3 ( ) Um ou mais membros utilizou o processo uma ou poucas vezes

3 4 ( ) Pelo menos a metade dos membros da equipe tem experi ncia no uso doprocesso em diferentes projetos

5. ( ) Toda a equipe tem experincia no uso do processo em vrios projetos diferentes.

F2 Colaboradores de meio perodo: Mede a estabilidade da equipe e a influencia do

trabalho parcial na produtividade.

Descrio do fator Peso Resultado

F1 1,5 0F2 Colaboradores de meio perodo -1 0F3 Capacidade de anlise 0,5 0

F4 0,5 0F5 Experincia em Orientao a Objetos 1 0F6 Motivao 1 0

F7Dificuldade na linguagem de programao -1 0

F8 Requisitos estveis 2 0

CdigoFator

Valor(Fator)Familiaridade com o processo de

desenvolvimento orientado a objetosadotado.

Experincia em desenvolvimento deaplicaes deste gnero


15/21

( ) No tem membro com dedicao parcial

1 2 ( ) Poucos membros (20%) trabalham em per odo parcial

3 4 ( ) A metade dos membros da equipe trabalham em per odo parcial

5. ( ) Toda os membros da equipe trabalham em perodo parcial

F3 Capacidade de anlise: Indica a experincia do lder com anlise de requisitos e

modelagem.

0 ( ) O lder do projeto novato.1 2 ( ) Possui experi ncia de poucos projetos

3 4 ( ) Pelo menos 2 anos de experi ncia com vrios projetos

5. ( ) Pelo menos 3 anos de experincia com projetos variados

F4 Experincia em desenvolvimento de aplicaes deste gnero: Indica a experincia

com diferentes tipos de aplicao ou com o tipo de aplicao que est sendo desenvolvida.

0 ( ) Todos os membros da equipe so novatos

1 2 ( ) Poucos membros da equipe possuem alguma experi ncia (de 1 a 1 ano). Osoutros so novatos.

3 ( ) Todos os membros tem mais de 1 ano de experincia

4 ( ) A maioria da equipe tem 2 anos de experincia

5. ( ) Todos os membros so experientes

F5 Experincia em Orientao a Objeto: Mede a experincia da equipe com anlise e

projeto OO, modelagem de casos de uso, classes e componentes.

0 ( ) A equipe no familiar com anlise e projeto OO.

1 ( ) Todos os membros tem menos de 1 ano de experincia.

2 3 ( ) Todos os membros tem de 1 a 1 ano de experincia

4 ( ) A maioria da equipe tem mais de 2 anos de experincia


16/21

5. ( ) Todos os membros so experientes ( mais de 2 anos)

F6 Motivao: Descreve a motivao total da equipe.

0 ( ) No motivada

1 2 ( ) Pouca motivada

3 4 ( ) A equipe est motivada para fazer um bom trabalho

5. ( ) A equipe est muito motivada e inspirada

F7 Dificuldade na linguagem de programao: Indica a experincia com ferramentas

primrias de desenvolvimento e com a linguagem de programao escolhida.

0 ( ) Todos os membros da equipe so programadores experientes1 ( ) A maioria dos membros da equipe possuem mais de 2 anos de experincia

2 ( ) Todos os membros tem mais de 1 ano de experincia

3 ( ) A maioria da equipe tem mais de 1 ano de experincia

4 ( ) poucos membros da equipe tem alguma experincia (1 ano). Os outros sonovatos.

5. ( ) Todos os membros da equipe so novatos.

F8 Requisitos Estveis: Mede o grau de mudana de requisitos e inseguranas sobre o

significado dos requerimentos.

0 ( ) Requisitos muito instveis com mudanas freqentes

1 2 ( ) Requisitos inst veis. Clientes demandam algumas mudanas realizadas emdiversos intervalos

3 4 ( ) Estabilidade global. Pequenas mudan as so necessrias

5. ( ) Requisitos estveis ao longo do desenvolvimento

D)Calcular o UCP (Use Case Points)

Finalmente calcular o UCP utilizando os clculos obtidos anteriormente:

UCP = UUCP * TCF * EF


17/21

E)Estimar o projeto em horas

Karner sugere a aplicao de 20 horas/homem por ponto de UCP.

Estimativa(horas) = UCP * 20;

3 ESTUDOS DE CASOS (UCP)

Neste tpico sero relatados alguns estudos de caso que demonstram a utilizao de UCP.

A)Estudos de Casos apresentados no artigo de Gustav Karner

Projeto A: Desenvolvimento de um sistema para gerenciar a performance em redes de

telecomunicaes. A equipe de projeto era de poucas pessoas e estas eram iniciantes noprocesso de desenvolvimento adotado, mas eram pessoas muito motivadas. A estimativa

foi a seguinte:

UUCP(Unadjusted Use Case Point) = 110 Nmero de Atores = 5 atores de complexidade mdia.

Nmero de Casos de uso = 10 casos de uso de

complexidade mdia.

TCF(Technical Complexity Factor) = 1 Todos os fatores tiveram atribuio de valor 3.

EF(Environmental Factor) = 0,975 O fator Familiaridade com o processo de

desenvolvimento orientado a objetos adotado teve

atribuio de valor 1.

O fator Motivao teve atribuio do valor 5.

O fator Requisitos Estveis teve atribuio do valor 4.

Os demais fatores tiveram atribuio do valor 3

UCP = UUCP * TCF * EF = 107.25 Multiplicando o valor de UCP por 20 horas/homem d

um total de 2145 horas.

Os projeto levou 2150 horas para ser realizado o que

representa 2150/107.25 = 20,046...


18/21

Projeto B: Desenvolvimento de um projeto de gerenciamento de redes LAN. A equipe era

composta de pessoas que no tinha nenhuma experincia anterior no processo dedesenvolvimento adotado.



complexidade mdia.





O fator Requisitos Estveis teve atribuio do valor 1



um total de 11985 horas

Os projeto levou 12.500 horas para ser realizado o

que representa 12500/599.25= 20,859....

Projeto C: Desenvolvimento de um sistema de telecomunicaes. A equipe no sabiamuito sobre o processo de desenvolvimento adotado.



complexidade mdia.





O fator Requisitos Estveis teve atribuio do valor 2

O fator Experincia em Orientao a Objetos teve

atribuio do valor 2.



19/21



complexidade mdia.


um total de 3760horas

Os projeto levou 5400 horas para ser realizado o que

representa 5400/188.0 = 28,723..

B)Estudos de Casos apresentados no artigo de viviane heimberg E everaldo artur

grahl.

Este artigo relata a anlise de 3 projetos: Sistema de Clculo em Folha de Pagamento(Projeto

1), Sistema Contbil (Projeto 2) e o sistema de Carto Ponto(Projeto 3). Para cada projeto foi

realizada as fases de concepo e a primeira iterao da fase de elaborao do Processo

Unificado. Segue abaixo a tabela com os resultados da estimativa realizada aps a primeira

iterao da fase de elaborao:

Projetos Atores Casos de

Uso

FCT FCA PCUNA PCUA Horas

Estimadas

Projeto 1 4 5 1 0,81 72 58,68 1173,6

Projeto 2 6 8 1,02 0,81 87 72,32 1446,46

Projeto 3 7 4 1,03 0,81 64 53,72 1074,5

Observao: Este artigo utilizou uma nomenclatura traduzida e que difere um pouco da

proposta pelo mtodo do Karner:

FCT equivale a TCF

FCA equivale a EF

PCUNA equivale a UUCP

PCUA equivale a UCP


20/21

Para o clculo das horas estimadas foi utilizado o ndice de 20 horas/homem. Porm, aps

verificar os resultados os membros das equipes de desenvolvimento e os coordenadores dos

projetos acharam que a estimativa estava muito acima dos obtidos em projetos semelhantes.

Os coordenadores identificaram que 20 horas/homem por total de tempo de unidade de

PCUA(UCP) era um nmero muito alto e no representava corretamente uma boa mdia para

todos os tipos de tempos por nvel de complexidade de casos de uso.

Alm disso, a metodologia de desenvolvimento de sistemas da empresa utiliza uma camada

de cdigo que abstrai grande parte da gerao de cdigo bsica dos seus sistemas. Sendo

assim, optaram por reduzir a quantidade de horas/homem para uma mdia de 10 horas e

ajustaram o pesos dos casos de uso e o resultado foi o seguinte:

Projetos Atores Casos de

Uso

FCT FCA PCUNA PCUA Horas

Estimadas

Projeto 1 4 5 1 0,81 54 43,74 437,4

Projeto 2 6 8 1,02 0,81 76 61,5 615,6

Projeto 3 7 4 1,03 0,81 57 46,17 461,7

Observao: Este artigo utilizou uma nomenclatura traduzida e que difere um pouco da

proposta pelo mtodo do Karner:

FCT equivale a TCF

FCA equivale a EF

PCUNA equivale a UUCP


21/21

PCUA equivale a UCP

4 CONCLUSO

Os estudos de casos relatados neste documento demonstram a importncia da adoo de uma

tcnica de medio de software. A tcnica adotada pode ser ajustada ao longo do seu uso

tendo como base dados histrico e aplicao de novos padres de desenvolvimento, como o

caso da utilizao de um Framework.

5 REFERNCIAS

KARNER, G. Use Case Points: resource estimation for Objectory projects. Objective Systems

SF AB (copyright owned by Rational/IBM), 1993.

HEIMBERG, V; GRAHL,E : Estudo de Caso de Aplicao da Mtrica de Pontos de Casos de

Uso numa Empresa de Software, www.inf.furb.br/seminco/2005/artigos/130 vf.pdf.

Andrade, Edmia Leonor Pereira. Pontos de Caso de Uso e Pontos de Funo na gesto de

estimativa de tamanho de projetos de software orientados a objetos

http://www.bfpug.com.br/Artigos/UCP/Tese%20Edmeia.zip
http://www.inf.furb.br/seminco/2005/artigos/130-vf.pdfhttp://www.bfpug.com.br/Artigos/UCP/Tese%20Edmeia.ziphttp://www.bfpug.com.br/Artigos/UCP/Tese%20Edmeia.ziphttp://www.inf.furb.br/seminco/2005/artigos/130-vf.pdf

ucp_ use case points

Documents