Métricas em Engenharia de Software

Apresentação em tema: "Métricas em Engenharia de Software"— Transcrição da apresentação:

1 Métricas em Engenharia de Software
PONTOS POR CASO DE USO PONTOS POR FUNÇÃO 2008-1

2 TI - Sistemática de Métricas
“Não se consegue controlar o que não se consegue medir” Tom DeMarco

3 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?

4 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.

5 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

6 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

7 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

8 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

9 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

10 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

11 Gerenciar integradamente...
Escopo Contratos Tempo Comunicação Integração Custo Riscos RH Qualidade

12 O que seria um bom método?
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.

13 Principais Métodos Avaliação sem compromisso técnico
Avaliações por similaridade Avaliações baseadas em fórmulas.

14 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....

15 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.

16 Porque Métricas ? Vamos fazer uma analogia com outra Engenharia
Engenharia Civil Como se contrata a construção de uma casa ? OU Como se compra uma casa ? Já imaginaram fazer isto sem a unidade m ou m2, ou sem CUB?

17 Como se compra um aplicativo ?
Porque Métricas ? Vamos ver como funciona com Software... Como se contrata a construção de um aplicativo ? OU Como se compra um aplicativo ? Que métrica utilizamos ?

18 Qual métrica utilizamos ?

19 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 ....

20 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;

21 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;

22 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;

23 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

24 Valores já calculados: UAW = 12
Pontos por Caso de Uso No caso do exemplo: Tipo de Ator Peso Nº de atores Resultado Ator Simples 1 Ator Médio 2 Ator Complexo 3 4 12 Total UAW Valores já calculados: UAW = 12

25 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;

26 Valores já calculados: UAW = 12, UUCW = 210
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

27 Valores já calculados: UAW = 12, UUCW = 210, UUCP = 222
Pontos por Caso de Uso Passo 3: Cálculo do UUCP (Unadjusted Use Case Points) UUCP = UAW + UUCW No caso do exemplo: UUCP = = 222 Valores já calculados: UAW = 12, UUCW = 210, UUCP = 222

28 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;

29 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 T3 Eficiência 1 T4 Processamento complexo T5 Código reusável T6 Facilidade de instalação 0.5 T7 Facilidade de uso T8 Portabilidade T9 Facilidade de mudança T10 Concorrência T11 Recursos de segurança T12 Acessível por terceiros T13 Requer treinamento especial

30 Pontos por Caso de Uso No caso do exemplo: Fator Requisito Peso
Influência Resultado T1 Sistema distribuído 2 1 T2 Tempo de resposta 3 6 T3 Eficiência T4 Processamento complexo T5 Código reusável T6 Facilidade de instalação 0.5 T7 Facilidade de uso 5 2.5 T8 Portabilidade T9 Facilidade de mudança T10 Concorrência T11 Recursos de segurança T12 Acessível por terceiros T13 Requer treinamento especial Tfactor 19,5

31 Valores já calculados: UUCP = 222, Tfactor = 19.5, TCF = 0.795
Pontos por Caso de Uso Passo 5: Cálculo do TCF (Technical Complexity Factor) TCF = (0.01  Tfactor) No caso do exemplo: TCF = (0.01  19.5) = 0.795 Valores já calculados: UUCP = 222, Tfactor = 19.5, TCF = 0.795

32 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 E1 Familiaridade com RUP ou outro processo formal 1.5 E2 Experiência com a aplicação em desenvolvimento 0.5 E3 Experiência em Orientação a Objetos 1 E4 Presença de analista experiente E5 Motivação E6 Requisitos estáveis 2 E7 Desenvolvedores em meio-expediente -1 E8 Linguagem de programação difícil

33 Pontos por Caso de Uso No caso do exemplo: Fator Descrição Peso
Influência Resultado E1 Familiaridade com RUP ou outro processo formal 1.5 5 7.5 E2 Experiência com a aplicação em desenvolvimento 0.5 E3 Experiência em Orientação a Objetos 1 E4 Presença de analista experiente 2.5 E5 Motivação E6 Requisitos estáveis 2 3 6 E7 Desenvolvedores em meio-expediente -1 E8 Linguagem de programação difícil Efactor 26 Valores já calculados: UUCP = 222, TCF = 0.795, Efactor = 26

34 Pontos por Caso de Uso Passo 7: Cálculo do ECF (Environmental Complexity Factor) ECF = (-0.03  Efactor) No caso do exemplo: ECF = (-0.03  26) = 0.62 Valores já calculados: UUCP = 222, TCF = 0.795, Efactor = 26, ECF = 0.62

35 ECF = 222  0.795  0.62 = 109.42 ou 109 Use Case Points
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.62 = ou 109 Use Case Points Valores já calculados: UUCP = 222, TCF = 0.795, ECF = 0.62

36 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

37 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

38 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 = ,00 Assim neste caso teríamos um custo de desenvolvimento de R$ ,00 (quinze mil reais)

39 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.

40 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

41 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;

42 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.

43 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

44 Mudanças nos Requisitos
Aplicativo Entregue Projeto Funcional Projeto Detalhado 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ço Cronograma Custo + 1 mês + 2 semanas + $5000 + 0.5 meses + $2500 meses + 2.5 dias + $1250

45 Como Contar Pontos de Função
Telas Relatórios Arquivos Mestres Tamanho Arquivos de Controle Arquivos de Referência Sinais

46 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

47 Visão Geral da APF: O Que é Contado
EE P1 Atualizar Arquivo Mestre P2 SE Relatório Resumo Semanal ALI Arquivo Produzir Relatório Semanal Mestre Fronteira do Sistema Chave P3 Arquivo Referência Detalhes Arquivo em AIE Detalhes Mestre Outro Sistema CE

48 Armazenamento de Dados
Arquivo Lógico Interno (ALI) Grupo lógico de dados mantido pelo aplicativo (por exemplo, Cadastro de Empregados) Arquivo Interface Externa (AIE) Grupo lógico de dados referenciado mas não mantido (p.ex., tabela de estados)

49 Transações Entrada Externa (EE) Saída Externa (SE)
Mantém ALI ou passa dados de controle para o aplicativo Saída Externa (SE) Dados formatados enviados para fora do aplicativo, com valor adicionado (p.ex., totais calculados) Consulta Externa (CE) Dados formatados enviados para fora do aplicativo, sem valor adicionado.

50 Tamanho Funcional (Não Ajustado)
Tipo de Função Baixa Média Alta EE x x x 6 SE x x x 7 CE x x x 6 ALI x x x 15 AIE x x x 10

51 Diagrama de Funções Fronteira da Aplicação
Arquivos de Interface Externa Entrada Externa Saída Externa Consulta Externa Aplicativo Outros Aplicativos Arquivo Lógico Interno

52 Determinação de Pontos de Função Brutos
Tipo de Complexidade Complexidade Total do Função Funcional Total Tipo de função ALIs 4 Simples X 7 = 28 Média X 10 = Complexa X 15 = 28 AIEs 4 Simples X 5 = 20 Média X 7 = Complexa X 10 = 20 EEs 4 Simples X 3 = 12 2 Média X 4 = 8 1 Complexa X 6 = 6 26 SEs 4 Simples X 4 = 16 2 Média X 5 = 10 Complexa X 7 = 26 CEs 5 Simples X 3 = 15 Média X 4 = Complexa X 6 = 15 Total de Pontos de Função Brutos = 115

53 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ência 1 - Influência mínima 2 - Influência moderada 3 - Influência média 4 - Influência significante 5 - Influência forte Variação máxima de 35 %

54 Características Gerais de Sistema
1. Comunicação de Dados 2. Processamento de Dados Distribuído (Funções Distribuídas) 3. Performance 4. Configuração do equipamento 5. Volume de Transações 6. Entrada de Dados On-Line 7. Interface com o usuário 8. Atualização On-Line 9. Processamento Complexo 10. Reusabilidade 11. Facilidade de Implantação 12. Facilidade Operacional 13. Múltiplos Locais 14. Facilidade de mudanças.

55 Classificar os quatorze itens de acordo o nível de influência.
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

56 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

57 PFM = [(INC + ALT + PFC) * FAD] + (EXC * FAA) Onde:
Para manutenção PFM = [(INC + ALT + PFC) * FAD] + (EXC * FAA) Onde: PFM - Pontosde função do projeto de manutenção INC - 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.

58 Para cálculo de uma aplicação
PFA = [(PFB + INC + ALTD) - (ALTA + EXC)] * FAD Onde: PFA - Ponto de Função Ajustados da aplicação PFB - Ponto de Função Bruto da Aplicação antes do projeto de manutenção INC - 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.

59 Gerenciando Mudanças nos Requisitos
Aplicativo Entregue Projeto Funcional Projeto Detalhado Requisitos 100 PFs 120 PFs 130 PFs 135 PFs

60 Quadro comparativo: APF X PCU
Mais antiga e mais utilizada no mundo Relativamente nova e pouco utilizada Padrão internacional desde 2002 Ainda 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 literatura Tem 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ção Ainda não oferece treinamentos e certificação

61 Tipos de Métricas Sim +- Pontos p/ Função Não
5. Utilizado em estimativas 4. Significância para o usuário final 3. Avaliação por usuários sem conhecimento de PD 2. Produção de resultados consistentes 1. Independência de tecnologia Casos de Uso Sistema Halstead Linha de Código Características

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

63 Evitando a Região Impossível
Custo do Esforço (75% de Td) Td To Tempo de Desenvolvimento 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.

64 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

65 Comprar os seus sapatos com base no tamanho médio do pé do brasileiro
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.

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

67 IFPUG e BFPUG BFPUG

68