A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "Métricas em Engenharia de Software PONTOS POR CASO DE USO PONTOS POR FUNÇÃO 2008-1."— Transcrição da apresentação:

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

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 Tempo Contratos Comunicação Riscos Qualidade RH Custo Integração

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

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 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 AtorPesoDescrição Ator Simples1Outro sistema acessado através de uma API de programação Ator Médio2Outro sistema acessado interagindo através da rede Ator Complexo3Um usuário interagindo através de uma interface gráfica

24 Pontos por Caso de Uso No caso do exemplo: Tipo de AtorPesoNº de atoresResultado Ator Simples100 Ator Médio200 Ator Complexo3412 Total UAW12 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 Pontos por Caso de Uso No caso do exemplo: TipoPesoNº de Casos de UsoResultado Simples5735 Médio Complexo15345 Total UUCW210 Valores já calculados: UAW = 12, UUCW = 210

27 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; FatorRequisitoPeso T1Sistema distribuído2 T2Tempo de resposta2 T3Eficiência1 T4Processamento complexo1 T5Código reusável1 T6Facilidade de instalação0.5 T7Facilidade de uso0.5 T8Portabilidade2 T9Facilidade de mudança1 T10Concorrência1 T11Recursos de segurança1 T12Acessível por terceiros1 T13Requer treinamento especial1

30 Pontos por Caso de Uso No caso do exemplo: FatorRequisitoPesoInfluênciaResultado T1Sistema distribuído212 T2Tempo de resposta236 T3Eficiência133 T4Processamento complexo133 T5Código reusável100 T6Facilidade de instalação0.500 T7Facilidade de uso T8Portabilidade200 T9Facilidade de mudança133 T10Concorrência100 T11Recursos de segurança100 T12Acessível por terceiros100 T13Requer treinamento especial100 Tfactor19,5

31 Pontos por Caso de Uso Passo 5: Cálculo do TCF (Technical Complexity Factor) TCF = (0.01 Tfactor) No caso do exemplo: TCF = ( ) = 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; FatorDescriçãoPeso 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 0.5 E5Motivação1 E6Requisitos estáveis2 E7 Desenvolvedores em meio- expediente E8 Linguagem de programação difícil 2

33 Pontos por Caso de Uso No caso do exemplo: FatorDescriçãoPesoInfluênciaResultado E1 Familiaridade com RUP ou outro processo formal E2 Experiência com a aplicação em desenvolvimento E3Experiência em Orientação a Objetos155 E4Presença de analista experiente E5Motivação155 E6Requisitos estáveis236 E7Desenvolvedores em meio-expediente00 E8Linguagem de programação difícil200 Efactor26 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.62 Valores já calculados: UUCP = 222, TCF = 0.795, Efactor = 26, ECF = 0.62

35 Pontos por Caso de Uso Passo 8: Cálculo dos UCP (Use Case Points) UCP = UUCP TCF ECF No caso do exemplo: ECF = = 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 100 PFs120 PFs130 PFs135 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 + $ meses + 2 semanas + $ meses dias + $1250 Aplicativo Entregue Projeto Detalhado Projeto Funcional Requisitos

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

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 ALI AIE CE Chave Detalhes P1 Atualizar Arquivo Mestre Arquivo Mestre P3 Detalhes Arquivo Mestre Relatório Resumo Semanal P2 Produzir Relatório Semanal Arquivo Referência Outro Sistema em Fronteira do Sistema SE

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

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

52 Determinação de Pontos de Função Brutos Tipo de Função Complexidade Funcional Complexidade Total Total do Tipo de função ALIs4Simples X 7 =28 0Média X 10 =0 0Complexa X 15 =0 28 AIEs4Simples X 5 =20 0Média X 7 =0 0Complexa X 10 =0 20 EEs4Simples X 3 =12 2Média X 4 =8 1 Complexa X 6 =6 26 SEs4Simples X 4 =16 2Média X 5 =10 0 Complexa X 7 =0 26 CEs5Simples X 3 =15 0Média X 4 =0 0 Complexa X 6 =0 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 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 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 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 100 PFs120 PFs130 PFs135 PFs Aplicativo Entregue Projeto Detalhado Projeto Funcional Requisitos

60 Quadro comparativo: APF X PCU APFPCU Mais antiga e mais utilizada no mundoRelativamente 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 maturidadeEm fase de amadurecimento Oferece treinamento e certificação Ainda não oferece treinamentos e certificação

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

62 Exemplos de Aplicações

63 Região Impossível Evitando a Região Impossível Custo do Esforço Tempo de Desenvolvimento TdTo 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.

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


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

Apresentações semelhantes


Anúncios Google