Estima de pontos de caso de uso Trabalho substitutivo ao Projeto Integrador

Estima de pontos de caso de uso Trabalho substitutivo ao Projeto Integrador Curso: Gestão da Tecnologia da Informação Disciplina: Gerencia de Projetos Professor: Elias Batista Ferreira Aluna: Kaysmier Castro

O que e A técnica de estimativa por Pontos de Caso de Uso foi proposta em 1993 por Gustav Karner, da Objectory (hoje, Rational Software). Ela baseia-se em dois métodos bastante utilizados - o mecanismo de Pontos de Função e uma metodologia conhecida como Mk II, uma adaptação da técnica de PFs, bastante utilizada na Inglaterra. A forma de lançar uma estimativa é o principal diferencial da métrica por Casos de Uso: o método 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 e uma análise em alto nível dos passos necessários para a realização de cada tarefa, em um nível muito mais abstrato que a técnica de Pontos de Função. Seus objetivos A técnica de análise de Pontos por Casos de Uso foi criada para permitir que seja possível estimar o tamanho do sistema ainda na fase de levantamento de Casos de Uso, utilizando-se dos próprios documentos gerados nesta fase de análise como subsídio para efetuar estimativas de tamanho, prazo e custo de software. O processo de contagem da métrica PCU é constituída por seis passos descritos a seguir: 1. Contar os atores e atribuir o grau de complexidade; 2. Contar os casos de uso e atribuir a complexidade; 3. Somar o total dos atores com o total de casos de uso para obter o PCU não ajustado; 4. Determinar a complexidade do fator técnico; 5. Determinar a complexidade do fator ambiente; 6. Calcular o PCU ajustado; A medição permite aos gerentes planejar, controlar, melhorar e aperfeiçoar o processo de desenvolvimento de software. Medição resulta em mudança cultural. Coletar dados, calcular e analisar métricas são três passos que devem ser implementados para iniciar um programa de métricas. O custo e o esforço necessários para construir software, mesmo em linhas de código produzidas são fáceis de coletar, desde que convenções específicas para a medição sejam estabelecidas antecipadamente. O software orientado a objetos é fundamentalmente diferente do software desenvolvido utilizando métodos convencionais. Por esse motivo as métricas para os sistemas orientados a objetos devem ser ajustadas considerando as características que a distinguem do software convencional. Existem várias métricas que podem ser utilizadas,

dentre as quais encontram-se o número de linhas de código e a Análise de Pontos por Função (APF). Esta última muito utilizada nas organizações de software. A métrica Pontos de Casos de Uso foi escolhida por ser uma métrica baseada fortemente na UML e mais especificamente pelos casos de uso e ainda pelo fato da empresa estar iniciando o uso da UML. Procedimentos de contagem Considerando-se a contagem de PF de funcionalidades entregues em mais de uma midia, a aplicação das regras de contagem de Pontos de Função definidas no CPM tem levado a duas abordagens alternativas, a saber: single instance e multiple instance. A abordagem single instance considera que a entrega de uma função transacional em múltiplas mídias não deve ser utilizada na identificação da unicidade da função. A abordagem multiple instance leva em consideração que a mídia utilizada na entrega da funcionalidade é uma característica de identificação da unicidade da função. Assim, funcionalidades únicas são reconhecidas no contexto da mídia na qual elas são requisitadas para operar. É importante enfatizar que o IFPUG reconhece ambas abordagens, single instance e multiple instance, para a aplicação das regras definidas no CPM. A determinação da contagem de PF seguindo a abordagem multiple instance ou single instance depende da avaliação da Coordenação de Métricas da organização. As estimativas e contagens de PF abordadas neste documento serão baseadas em multiple instance, com exceção dos casos de consultas em.pdf,.doc,.xls e consultas idênticas em tela e papel, que serão consideradas uma única funcionalidade. A seguir são descritos os termos comuns definidos pelo IFPUG [IFPUG, 2009]: Canal: também refere-se a mídia. Múltiplos canais é sinônimo de múltiplas midias. Mídia: descreve a maneira que os dados ou informações se movimentam para dentro e para fora de uma fronteira de aplicação, por exemplo, apresentação de dados em tela, impressora, arquivo, voz. Este termo é utilizado para incluir, dentre outros: diferentes plataformas técnicas e formatos de arquivos como diferentes mídias. Múltiplas Mídias: quando a mesma funcionalidade é entregue em mais de uma mídia. Frequentemente, somente uma mídia é requisitada para um usuário específico em um determinado momento, por exemplo consulta de extrato bancário via internet como oposto a consulta de extrato bancário via terminal do banco. Multi-Mídia: quando mais de uma mídia é necessária para entregar a função, por exemplo, uma nova notícia publicada na Internet que é apresentada em

vídeo e texto. Observe que a notícia completa só é apresentada para o usuário se ele ler o texto e assistir o vídeo. Abordagem Single Instance: esta abordagem não reconhece que a mídia utilizada na entrega da função transacional é uma característica de diferenciação na identificação da unicidade da função transacional. Se duas funções entregam a mesma funcionalidade usando mídias diferentes, elas são consideradas a mesma Roteiro de Métricas de Software do SISP 40 Funcionalidade em uma contagem de Pontos de Função. Abordagem Multiple Instance: esta abordagem especifica que o tamanho funcional é obtido no contexto do objetivo da contagem, permitindo uma função de negócio ser reconhecida no contexto das mídias que são requisitadas para a funcionalidade ser entregue. A abordagem multiple instance reconhece que a mídia para entrega constitui uma característica de diferenciação na identificação da unicidade da função transacional. Pesos, Fatores e Ajustes no ca lculo. O processo de contagem dessa métrica consiste nos seguintes passos: 1 -Relacionar os atores, classificá-los de acordo com seu nível de complexidade (simples, médio ou complexo) atribuindo respectivamente os pesos 1, 2 ou 3., conforme a tabela 1. Calcule o TPNAA (Total de Pesos não Ajustados dos Atores) somando os produtos da quantidade de atores pelo seu peso. Complexidade do ator Simples Médio Complexo Descrição Muito poucas entidades de Banco de Dados envolvidas e sem regras de negócio complexas Poucas entidades de Banco de Dados envolvidas e com algumas regras de negócio complexas Regras de negócios complexas e muitas entidades de Bancos de Dados presentes Peso 1 2 3 2 - Contar os casos de uso e atribuir o grau de complexidade sendo a complexidade baseada no número de classes e transações. Calcule o

TPNAUC (Total de Pesos não ajustados dos casos de usos) somando os produtos da quantidade de casos de usos pelo respectivo peso conforme a tabela 2. Tipo de Caso de Descrição Uso Simples Considerar até 3 transações com menos de 5 classes de análise Médio Considerar de 4 a 7 transações com 5 a 10 classes de análise Complexo Considerar de 7 transações com pelo menos de 10 classes de análise Peso 5 10 15 3 - Calcular PCU s não ajustados, também chamados de PCUNA, de acordo com a seguinte fórmula: PCUNA = TPNAA+ TPNAUC 4 - Determinar o fator de complexidade técnica. Os fatores de complexidade técnica variam numa escala de 0 a 5, de acordo com o grau de dificuldade do sistema a ser construído. O valor 0 indica que a grau não está presente ou não é influente, 3 influência média e o valor 5 indica influência significativa através de todo o processo. Após determinar o valor dos fatores, multiplicar pelo respectivo peso ilustrado na tabela 3, somar o total e aplicar a seguinte fórmula: Fator de complexidade técnica (FCT) = 0.6 + (0.01 * Somatório do Fator técnico) Descrição Peso Peso Sistemas Distribuídos 2,0 Desempenho da aplicação 1,0 Eficiência do usuário final (on-line) 1,0 Processamento interno complexo 1,0 Reusabilidade do código em outras aplicações 1,0 Facilidade de instalação 0,5 SisteUsabilidade (facilidade operacional) 0,5 Portabilidade 2,0 Facilidade de manutenção 1,0 Concorrência 1,0 Características especiais de segurança 1,0 Acesso direto para terceiros 1,0 Facilidades especiais de treinamento 1,0

5 - Determinar o fator de complexidade ambiental: os fatores de complexidade ambientais indicam a eficiência do projeto e estão relacionados ao nível de experiência dos profissionais. Esses fatores descritos na tabela 4 são determinados através da escala de 0 a 5, onde 0 indica baixa experiência, 3 indica média experiência e 5 indica alta experiência. Após determinar o valor de cada fator, multiplicar pelo peso e somar o total dos valores. Em seguida, aplicar a seguinte fórmula: Fator de complexidade ambiental (FCA) = 1,4 + (-0,03 * Somatório do Fator Ambiental) 6 - Calcular os PCU s ajustados: esse cálculo é realizado com base na multiplicação dos PCU não ajustados, na complexidade técnica e na complexidade ambiental através da seguinte fórmula: PCUA = PCUNA * Fator de complexidade técnica * Fator de complexidade ambiental Fator Descrição Peso F1 Familiaridade com o processo de desenvolvimento de software 1,5 F2 Experiência na aplicação 0,5 F3 Experiência com OO, na linguagem e na técnica de 1,0 desenvolvimento F4 Capacidade do líder de análise 0,5 F5 Motivação 1,0 F6 Requisitos estáveis 2,0 F7 Trabalhadores com dedicação parcial -1,0 F8 Dificuldade da linguagem de programação -1,0 7 - Calcular a estimativa de horas de programação. Karner, o criador da estimativa, sugere a utilização de 20 pessoas-hora por unidade de PCU. Schneider e Winters sugerem o seguinte refinamento : X = total de ítens de F1 a F6 com pontuação abaixo de 3 Y = total de ítens de F7 a F8 com pontuação acima de 3 Se X + Y <= 2, usar 20 como unidade de homens/hora Se X + Y = 3 ou X + Y = 4, usar 28 como unidade de homens/hora Se X + Y >= 5, deve-se tentar modificar o projeto de forma a baixar o número, pois o risco de insucesso é relativamente alto. Estimativa de horas = PCUA * pessoas hora por unidade de PCU.

Aplicaça o Estimativa de esforço baseado em Pontos de Casos de Uso 1.0. Mensurando Complexidade dos Atores Ator Interface Peso Qtd. Atores Valor Simples Interface de programa (API) 1 0 0 Médio Protocolo (Ex.:TCP/IP) ou interface em modo texto 2 0 0 Complexo Interface gráfica 3 2 6 Total 2 6 2.0. Mensurando Complexidade dos Use Cases Caso de Uso Descrição Peso Qtd. UC Valor Simples < 3 transações ou < 5 classes de análise 5 8 40 Médio 4-7 transações ou 5 a 10 classes de análise 10 1 10 Complexo > 7 transações ou > 10 classes de análise 15 0 0 Total 9 50 PCUNA 56 PCUNA = Pontos de Casos de Uso Não Ajustados 3.0. Considerando Fatores Técnicos do Projeto Fator Descrição Peso Atribuído Valor T1 Sistema distribuído 2 3 6 T2 Objetivos de performance 1 5 5 T3 Eficiênca on-line 1 4 4 T4 Complexidade de processamento 1 2 2 T5 Código reusável em outras aplicações 1 0 0 T6 Facilidade de instalação 0,5 1 0,5 T7 Facilidade de uso 0,5 4 2 T8 Portabilidade 2 3 6 T9 Facilidade de alterações (changeability ) 1 0 0 T10 Concorrência 1 5 5 T11 Segurança 1 4 4 T12 Acesso direto a terceiros 1 5 5 T13 Necessidade de facilidades especiais de treinamento para usuários 1 0 0 FatorT 39,5 FCT 0,995 FCT = Fator de Complexidade Técnica

4.0. Considerando Fatores Ambientais Fator Descrição Peso Atribuído Valor F1 Familiaridade da equipe com RUP 1,5 3 4,5 F2 Experiência da equipe 0,5 3 1,5 F3 Experiência da equipe em OO 1 3 3 F4 Capacidade dos analistas da equipe 0,5 5 2,5 F5 Motivação 1 3 3 F6 Estabilidade dos requisitos 2 3 6 F7 Estagiários ou funcionários em tempo parcial -1 0 0 F8 Domínio da tecnologia e configuração do ambiente -1,5 3-4,5 FatorA 16 FA 0,92 FA = Fator Ambiental 5.0. Pontos de Caso de Uso PCU PCUNA*FCT*FA 51,26 Pessoa-hora por unidade de PCU Estimativa em pessoa-hora Tamanho da equipe Estimativa em horas Estimativa em meses 20 1025,25 5 205,05 1,28 pessoa-hora/pcu pessoas horas meses Uso dos Pontos de Caso de Uso para estimativa de prazo do estudo de caso: Após estimar o esforço necessário para o desenvolvimento do estudo de caso, o próximo passo é estimar o prazo do projeto. Inicialmente o prazo é gerado de forma empírica considerando o esforço estimado e o tamanho da equipe para o desenvolvimento do projeto através de algumas considerações 1 mês possui 22 dias úteis Com a jornada de trabalho de 8horas/dia, a produtividade do profissional no Brasil é de 6 horas/dia. Considerando as considerações propostas aplica-se a equação: Prazo (em dias) = Esforço (em horas) / (Tamanho da equipe * 6)

Considerando que a equipe é compreendida de 3 componentes, então temos: Prazo (em dias) = 516,88 / (3* 6) = 28,71 dias Como exemplo: Ele utiliza-se dos próprios documentos gerados nesta fase de análise como subsídio para o cálculo dimensional; Sistema que será usado como exemplo: Site de suporte de produtos para uma grande companhia de software; A estimativa foi feita a partir dos casos de uso de nível muito alto (business modelling), que foram criados em tempo de levantamento de requisitos; Os atores, nessa vez, foram os diferentes tipos de usuários identificados nesses casos de uso; Como exemplos usaremos 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 Ator Complexo 3 Um usuário interagindo através de uma interface gráfica No caso do exemplo: Tipo de Ator Peso Nº de atores Resultado Ator Simples 1 0 0 Ator Médio 2 0 0 Ator Complexo 3 4 12 Total UAW 12

Cálculo do UUCW (Unadjusted Use Case Weight) Para fins de cálculo, dividimos os casos de uso em três níveis de complexidade: Simples (peso 5): Tem até 3 transações, incluindo os passos alternativos, e envolve menos de 5 entidades; Médio (peso 10): Tem de 4 a 7 transações, incluindo os passos alternativos, e envolve de 5 a 10 entidades; Complexo (peso 15): Tem acima de 7 transações, incluindo os passos alternativos, e envolve pelo menos de 10 entidades; Tipo Peso Nº de Casos de Uso Resultado Simples 5 7 35 Médio 10 13 130 Complexo 15 3 45 Total UUCW 210 Cálculo do UUCP (Unadjusted Use Case Points) UUCP = UAW + UUCW No caso do exemplo: UUCP = 12 + 210 = 222 Cálculo do Tfactor 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 Cálculo do TCF (Technical Complexity Factor) TCF = 0.6 + (0.01 Tfactor) No caso do exemplo: TCF = 0.6 + (0.01 19.5) = 0.795 Fator Descrição Peso Influência Resultado E1 E2 Familiaridade com RUP ou outro processo formal Experiência com a aplicação em desenvolvimento 1.5 5 7.5 0.5 0 0 E3 Experiência Orientação Objetos em a 1 5 5

E4 Presença analista experiente de 0.5 5 2.5 E5 Motivação 1 5 5 E6 E7 E8 Requisitos estáveis Desenvolvedores em meioexpediente Linguagem programação difícil de 2 3 6-1 0 0-1 0 0 Efactor 26 Cálculo do ECF (Environmental Complexity Factor) ECF = 1.4 + (-0.03 Efactor) No caso do exemplo: ECF = 1.4 + (-0.03 26) = 0.62 Cálculo dos UCP (Use Case Points) UCP = UUCP TCF ECF No caso do exemplo: ECF = 222 0.795 0.62 = 109.42 ou 109 Use Case Points 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 = 109 * 20 = 2180 horas de trabalho Para efeito de cálculos usaremos os valores: - O custo da hora-desenvolvimento varia de acordo com a especialização do profissional que irá realizar a tarefa. - Para analistas, este valor se situa entre 80 e 100 reais por hora. - Para programadores, entre 30 e 60 reais a hora. - Na média, para horas de desenvolvimento de cada caso de uso, podese considerar R$ 50,00

É obtida a partir da multiplicação do número de casos de uso estimados, pelo valor médio da hora de desenvolvimento. Exemplo: para um sistema de 300 UCP, teríamos: 300 * 50,00 = 15.000,00 Assim neste caso teríamos um custo de desenvolvimento de R$ 15.000,00 (quinze mil reais) Devem ser somados todos os custos envolvidos, desde o início do projeto até o seu final: Custo de treinamento Custo de hw Custo do sw de apoio (licenças de BD, Ferramenta CASE, etc.) Custo do desenvolvimento Outros Bibliografia: 1 - [Hazan, 2008] HAZAN, C. Análise de Pontos de Função: Uma Aplicação nas Estimativas de Tamanho de Projetos de Software. Engenharia de Software Magazine, Edição 2, Devmedia, pp.25-31. 2 - http://www.inf.furb.br/seminco/2005/artigos/130-vf.pdf 3 - http://www.ip.pbh.gov.br/ano7_n1_pdf/ip7n1_andrade.pdf Acesso em 11/agosto/2009. 4 - http://livros01.livrosgratis.com.br/cp005579.pdf