Métricas em Engenharia de Software

PONTOS POR CASO DE USOPONTOS POR FUNÇÃO

2008-1

TI - Sistemática de Métricas

“Não se consegue controlar

o que não se consegue medir”

Tom DeMarco

Aspectos a discutir

Projetos O que são métricas de software? Porque devem ser utilizadas O que se deve medir? Como podem ser feitas estas medidas? Quais os principais métodos para

estimar prazos e custos? Quais os problemas de cada um?

Projetos

Projeto é um empreendimento não repetitivo, caracterizado por uma seqüência lógica e clara de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade.

Projetos - Porque gerenciá-los?

Competição Padrões de qualidade Redução das margens de lucro Resultados financeiros Fatores tecnológicos Aspectos Legais Aspectos sociais Fatores políticos Pressões econômicas

Projetos beneficiados com gerência

De tamanho maior ($, pessoal e tempo) Mais interdependentes Com grande importância (grau de

risco...) Afetam a reputação da organização Envolvem recursos compartilhados São não-familiares à equipe Envolvem incerteza do mercado

O projeto bem sucedido

Concluído no tempo previsto Concluído no orçamento previsto Com utilização otimizada de recursos Com qualidade e performance desejadas Com o mínimo possível de alterações Com alto grau de aceitação pelo usuário Com adaptação cultural adequada

Estimulando o sucesso do projeto

Seleção correta da equipe Alto grau de comprometimento da equipe Sinergia com parceiros Identificação precoce de pontos de melhoria Estimativas (prazos, custo, tamanho) realistas Planos de contingência Modificações sob controle Prioridade para alcance das metas Linhas de comunicação informais Inexistência de pressões externas à equipe

Gerenciamento de Projetos Benefícios

Evitar surpresas durante a execução Estabelecer diferencial competitivo Antecipar situações desfavoráveis Adaptar trabalho ao cliente Dispor de orçamento antes dos gastos Agilizar decisões Aumentar controle gerencial sobre as fases Facilitar revisões na estrutura do projeto Otimizar a alocação de recursos Facilitar novas estimativas

Fracasso de projetos: causas

Externas: mudanças na estrutura, tecnologia, ambiente, preços e cenário político

Metas e objetivos mal estabelecidos Pouca compreensão da complexidade Estimativas deficientes Planejamento inadequado Gerência de projeto ineficiente Falta de treinamento e capacitação Falta de padronização e metodologias Avaliação incorreta dos riscos Clientes com expectativas não atendidas

Gerenciar integradamente...Escopo

TempoContratos

Comunicação

Riscos

Qualidade

RH

CustoIntegração

Aquele que fosse capaz de permitir a realização de previsões com um alto grau de acerto em relação ao item avaliado.

Aquele que permitisse a realização da estimativa o mais rápido possível dentro do ciclo de vida de desenvolvimento.

O que seria um bom método?O que seria um bom método?

Principais Métodos

Avaliação sem compromisso técnico

Avaliações por similaridade

Avaliações baseadas em fórmulas.

Dados para avaliação Para que boas avaliações possam ser realizadas, é

fundamental que existam dados, colhidos de projetos anteriores.

Os dados relevantes básicos são tamanho esforço distribuição das habilidades na equipe

Muitos aspectos tornam difícil a comparação: tipo de software metodologia utilizada grau de complexidade ambiente de desenvolvimento nível cultural da equipe e mais....

Uma das maiores dificuldades no gerenciamento de projetos de informática é saber a dimensão do que esta sendo gerenciado

Muitas aplicações que parecem pequenas, quando em desenvolvimento, mostram-se muitas vezes maiores do que o previsto inicialmente.

Porque Métricas ?

Vamos fazer uma analogia com outra Engenharia

Engenharia Civil

Como se contrata a construção de uma casa ?

OUComo se compra uma casa ?

Já imaginaram fazer isto sem a unidade m ou m2, ou sem CUB?

Porque Métricas ?

Vamos ver como funciona com Software...

Como se contrata a construção de um aplicativo ?

OUComo se compra um aplicativo ?

Que métrica utilizamos ?

Qual métrica utilizamos ?

Tipos de Métricas

Contagem de Linhas de Código Fonte (LOCs) Halstead (operandos e operadores) Análise de Pontos por Função Análise por Casos de uso Outras Técnicas ....

Pontos por Caso de Uso 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;

Pontos por Caso de Uso O Método de Use Case Points foi criado

para que seja possível estimar o tamanho de um sistema já na fase de levantamento de Casos de Uso;

Ele utiliza-se dos próprios documentos gerados nesta fase de análise como subsídio para o cálculo dimensional;

Pontos por Caso de Uso 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;

Pontos por Caso de Uso Passo 1: Cálculo do UAW (Unadjusted

Actor Weight)

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

Pontos por Caso de Uso 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

Valores já calculados: UAW = 12

Pontos por Caso de Uso Passo 2: 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;

Pontos por Caso de Uso No caso do exemplo:

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 = 12, UUCW = 210

Pontos por Caso de Uso Passo 3: Cálculo do UUCP (Unadjusted

Use Case Points)UUCP = UAW + UUCW

No caso do exemplo:UUCP = 12 + 210 = 222

Valores já calculados: UAW = 12, UUCW = 210, UUCP = 222

Pontos por Caso de Uso 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;

Pontos por Caso de Uso 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;

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

Pontos por Caso de Uso 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

Pontos por Caso de Uso Passo 5: 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

Valores já calculados: UUCP = 222, Tfactor = 19.5, TCF = 0.795

Pontos por Caso de Uso 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;

Fator

Descrição Peso

E1Familiaridade com RUP

ou outro processo formal1.5

E2Experiência com a

aplicação em desenvolvimento

0.5

E3Experiência em

Orientação a Objetos1

E4Presença de analista

experiente0.5

E5 Motivação 1

E6 Requisitos estáveis 2

E7Desenvolvedores em

meio-expediente-1

E8Linguagem de

programação difícil 2

Pontos por Caso de Uso No caso do exemplo:

Fator

Descrição Peso

Influência

Resultado

E1Familiaridade com RUP ou outro

processo formal1.5 5 7.5

E2Experiência com a aplicação em

desenvolvimento0.5 0 0

E3Experiência em Orientação a

Objetos1 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

E7Desenvolvedores em meio-

expediente-1 0 0

E8Linguagem de programação

difícil2 0 0

Efactor 26

Valores já calculados: UUCP = 222, TCF = 0.795, Efactor = 26

Pontos por Caso de Uso Passo 7: 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

Valores já calculados: UUCP = 222, TCF = 0.795, Efactor = 26, ECF = 0.62

Pontos por Caso de Uso Passo 8: 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

Valores já calculados: UUCP = 222, TCF = 0.795, ECF = 0.62

Pontos por Caso de Uso 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 = 109 * 20 = 2180 horas de

trabalho

Valores já calculados: UCP = 109

Estimativa de Custo de Desenvolvimento

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, pode-se considerar R$ 50,00

Estimativa do Custo de Desenvolvimento.

É 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)

Estimativa do Custo de Desenvolviemtno

Para cada empresa que desenvolve software, estes valores devem ser ajustados em função do que realmente ocorreu nos projetos já terminados e entregues ao usuário.

Com o tempo, pode-se chegar a estimativas da proporcionalidade do envolvimento de programadores e analistas no projeto, fazendo-se cálculos mais realistas.

Estimativa de Custo do Projeto

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

Conclusões - UCP Devido à amplitude do assunto

tratado, vários temas não foram abordados;

O método de Use Case Points parece ser muito bom para quem precisa de dados de estimativa em um curto espaço de tempo;

Tanto APF quanto PCU são métricas muito subjetivas;

Conclusões - UCP É evidente o problema de que a

granularidade de cada caso de uso varia muito entre analistas, causando uma significativa variação nos resultados de PCU;

As métricas específicas para OO apresentadas servem mais para controle de qualidade do que para cálculo de tamanho.

Análise de Pontos por Função

Medir o software através da quantificação da funcionalidade solicitada e adquirida pelo cliente,

tendo como base primária o projeto lógico

Medir o desenvolvimento e manutenção de software independentemente da tecnologia utilizada na

implementação

Medir o desenvolvimento e manutenção de software consistentemente em todos os projetos e

organizações

Mudanças nos Requisitos

100 PFs 120 PFs 130 PFs 135 PFs

Tela de entrada do código do estado alterada (3 PFs)

Acrescentada interface arquivo N&A (10 PFs)

Consulta N&A e ao código do estado acrescentadas (7 PFs)

• Nova tabela legal acrescentada (10 PFs)

• Relatório resumo incluído (5 PFs)

Impacto

EsforçoCronogramaCusto

+ 1 mês+ 2 semanas+ $5000

+ 0.5 meses+ 2 semanas+ $2500

+ 0.25 meses+ 2.5 dias+ $1250

Aplicativo Entregue

ProjetoDetalhado

ProjetoFuncionalRequisitos

Como Contar Pontos de Função

Telas

Relatórios

Arquivos Mestres Tamanho

Arquivos de Referência

Sinais

Arquivos de Controle

Passos na Contagem de PF

Determine o Tipo de Contagem Identifique o Escopo da Contagem e

a Fronteira da Aplicação Conte as Funções de Dados Conte as Funções Transacionais Determine os Pontos de Função Não

Ajustados Determine o Fator de Ajuste Calcule os Pontos de Função

Ajustados

Visão Geral da APF: O Que é Contado

EE

ALI

AIE

CE

Chave

Detalhes

P1

Atualizar Arquivo

Mestre

Arquivo

Mestre

P3

Detalhes ArquivoMestre

Relatório Resumo Semanal

P2

Produzir Relatório

Semanal

Arquivo

Referência

Outro

Sistema

em

Fronteira

do

Sistema

SE

Tamanho Funcional(Não Ajustado)

Tipo de Função Baixa Média Alta

EE x 3 x 4 x 6

SE x 4 x 5 x 7

CE x 3 x 4 x 6

ALI x 7 x 10 x 15

AIE x 5 x 7 x 10

Arquivos de Interface ExternaEntrada Externa

Saída Externa

Consulta Externa

Aplicativo

Outros Aplicativos

Saída Externa

Entrada Externa

Consulta Externa

ArquivoLógicoInterno

Diagrama de Funções Fronteira da Aplicação

Determinação de Pontos de Função Brutos

Tipo deFunção

ComplexidadeFuncional

Complexidade Total

Total doTipo de função

ALIs 4 Simples X 7 = 280 Média X 10 = 00 Complexa X 15 = 0

28

AIEs 4 Simples X 5 = 200 Média X 7 = 00 Complexa X 10 = 0

20

EEs 4 Simples X 3 = 122 Média X 4 = 81 Complexa X 6 = 6

26

SEs 4 Simples X 4 = 162 Média X 5 = 100 Complexa X 7 = 0

26CEs 5 Simples X 3 = 15

0 Média X 4 = 00 Complexa X 6 = 0

15

Total de Pontos de Função Brutos = 115

Determinação do Fator de Ajuste

O FA (Fator de Ajuste) é baseado em 14 características gerais de sistema que determina a funcionalidade geral da aplicação que está sendo contada.O nível (grau) de influência varia de 0 a 5.

0 - Nenhuma influência1 - Influência mínima2 - Influência moderada3 - Influência média4 - Influência significante5 - Influência forte

Variação máxima de 35 %

Características Gerais de Sistema

1. Comunicação de Dados2. Processamento de Dados Distribuído (Funções

Distribuídas)3. Performance4. Configuração do equipamento5. Volume de Transações6. Entrada de Dados On-Line7. Interface com o usuário8. Atualização On-Line9. Processamento Complexo10. Reusabilidade11. Facilidade de Implantação12. Facilidade Operacional13. Múltiplos Locais

14. Facilidade de mudanças.

Procedimento

Classificar os quatorze itens de acordo o nível de influência.

Aplicar a fórmula FA = (NI * 0,01) + 0,65

Variação de 0,65 até 1,35

Determinação dos Pontos de Função Ajustados

Para desenvolvimento PFD = (PFB + PFC) * FA Onde:

PFD - Ponto de Função de Desenvolvimento PFC - Ponto de Função de Conversão FA - Fator de Ajuste

Para manutençãoPFM = [(INC + ALT + PFC) * FAD] + (EXC * FAA)Onde:

PFM - Pontosde função do projeto de manutençãoINC - Ponto de função brutos que foram incluídos na aplicação pelo projeto de manutenção.ALT - Ponto de função que foram alterados na aplicação pelo projeto de manutenção.PFC - Ponto de função que foram adicionados pelo processo de conversão.FAD - Fator de ajuste da aplicação depois do projeto de manutenção.EXC - Ponto de função brutos que foram excluídos da aplicação pelo projeto de manutenção.FAA - Fator de ajuste da aplicação antes do projeto de manutenção.

Para cálculo de uma aplicaçãoPFA = [(PFB + INC + ALTD) - (ALTA + EXC)] * FADOnde:

PFA - Ponto de Função Ajustados da aplicaçãoPFB - Ponto de Função Bruto da Aplicação antes do projeto de manutençãoINC - Pontos de função brutos que foram adicionados pelo projeto de manutenção.ALTD - Pontos de função brutos correspondentes às funções que sofreram alteração durante o projeto de manutenção. Este número reflete as funções depois da manutenção.ALTA - São os Pontos de função brutos correspondentes às funções que sofreram alteração durante o projeto de manutenção. Esse número reflete as funções antes da manutenção.EXC - Pontos de função brutos correspondentes às funções que foram excluídas da aplicação pelo projeto de manutenção.FAD - Fator de ajuste da aplicação verificado depois do projeto de manutenção.

Gerenciando Mudanças nos Requisitos

100 PFs 120 PFs 130 PFs 135 PFs

Aplicativo Entregue

ProjetoDetalhado

ProjetoFuncionalRequisitos

Quadro comparativo:APF X PCU

APF PCU

Mais antiga e mais utilizada no mundo Relativamente nova e pouco utilizada

Padrão internacional desde 2002Ainda não alcançou o nível de padronização e nem foi incorporada em ferramentas populares

Não requer o uso de notação padrão, mas é baseada no modelo funcional e independente de tecnologia

Baseada no modelo de casos de uso

Largamente discutida na literaturaTem aumentado o uso e a publicação de estudos na literatura

É suportada pelo IFPUG e diversos grupos nacionais de usuários e bases históricas de medidas realizadas

Ainda não possui bons históricos de produtividade

Possui regras de contagem padronizadas

Há dúvidas de qual o nível apropriado de detalhe que cada caso de uso deve possuir

Alto nível de maturidade Em fase de amadurecimento

Oferece treinamento e certificaçãoAinda não oferece treinamentos e certificação

Tipos de Métricas

Sim

Sim

+-

Sim

Sim

Pontos p/ Função

SimNãoNão5. Utilizado em estimativas

SimNãoNão4. Significância para o usuário final

SimNãoNão3. Avaliação por usuários sem conhecimento de PD

SimSimSim2. Produção de resultados consistentes

Sim Sim Não 1. Independência de tecnologia

Casos

de Uso

Sistema Halstead

Linha de Código

Características

Exemplos de Aplicações

Aplicação PF Aplicação PF1. Produtos de Software 2. Sist. Comerciais DiversosFerramenta CASE IEF (Texas) 20.000 Imposto de Renda Pessoal 2.000Compilador Visual Basic (MS) 3.000 Contabilidade Geral 1.500SGBD IMS (IBM) 3.500 Processamento de Pedidos 1.250Gerenciador de TP CICS (IBM) 2.000 Recursos Humanos 1.200Word 7.0 (Microsoft) 2.500 Suporte a Vendas 975Excel 6.0 (Microsoft) 2.500 Preparação de Orçamento 750

Região Impossível

Evitando a Região ImpossívelC

usto

do

Esf

orço

Tempo de Desenvolvimento

Td To

Região Impossível(75% de Td)

Observações:1) Td é o tempo ótimo de desenvolvimento.2) To é o tempo que acarreta o menor custo.3) To = 2 Td.4) É impossível terminar em menos que 0,75 * Td.

Os 7 Pecados Capitais¹

• Falta de Comunicação (com o seu pessoal)

• Confiança Cega (no parceiro)

• Cinismo e Desconfiança (com o parceiro)

• O Contrato é “a Bíblia” (falta de flexibilidade)

• “Ir Dormir Aborrecido” (fazer bola de neve)

• Má Prática de Métricas (ambas as partes devem entender os critérios)

• Cobiça e Oportunidade (explorar falhas do contrato)

¹ Dekkers, C., Management of Outsourcing: How to Avoid Common Mistakes, Software Management Conference, San Jose, February 2000

O Oitavo Pecado¹

Comprar os seus sapatos com base no tamanho

médio do pé do brasileiro

¹ Aguiar, M., Contratando o Desenvolvimento com Base em Métricas, Developers Magazine, setembro de 2000.

Obtenha Suas Próprias Medidas através de um Programa de Métricas

IFPUG e BFPUG

BFPUG