Métricas em Engenharia de Software PONTOS POR CASO DE USO PONTOS POR FUNÇÃO 2008-1.
Transcript of Métricas em Engenharia de Software PONTOS POR CASO DE USO PONTOS POR FUNÇÃO 2008-1.
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