Gestão de Configuração & Mudanças 2. Estimativas de Esforços

1. Gestão de Configuração & Mudanças2. Estimativas de Esforços Márcio Aurélio Ribeiro Moreira marcio.moreira@pitagoras.com.br http://si.lopesgazzani.com.br/docentes/marcio/

2. Como estimar o esforço do projeto?

3. Margens de Erro por Fase do Ciclo de Vida Fonte: Boehm 1995.

4. Técnica Delphi (Empírica) Delphi PERT Criação: 1950: Marinha Americana Popularização: Década 70 em projetos (PMI) Ideia: Combinar visões Otimista, Realista e Pessimista Equações: A Média ± Desvio tem 90% de chance de ocorrer • Criação: • 1944: General Henry Arnold • Popularização: • 1964: Gordon e Helmer • Ideia: • A visão de um grupo é melhor que a visão de uma pessoa • Método: • Pelo menos 3 especialistas estimam o esforço a partir da descrição do problema

5. Técnicas Formais • Análise de Pontos de Função (FPA): • 1979: Allan J. Albrecht na IBM • 1986: Criado o International Function Point User Group(IFPUG) • Requer decomposição funcional • Pontos de Caso de Uso (UCP): • 1993: Gustav Karner • Baseada nos Pontos de Função • Não requer decomposição funcional • COCOMO II: • COnstructiveCOstMOdel • 1981: Barry W. Boehm – 1ª versão • 1995: 2ª versão – COCOMO II • Requer definição dos requisitos

6. Pontos de Função (Allan J. Albrecht) • Para cada função: • Conte o número de parâmetros utilizando os seguintes fatores: • A: Número de entradas externas • B: Número de saídas externas • C: Número de consultas externas (entradas externas interativas) • D: Número de arquivos externos (permanentes) • E: Número de arquivos internos (temporários) • Decida a complexidade de cada fator utilizando as tabelas nos slides seguintes

7. Entradas, Saídas e Consultas Externas A: Entradas Externas B: Saídas Externas C: Consultas Externas (entrada) C: Consultas Externas (saídas)

8. Arquivos Externos e Internos D: Arquivos Externos E: Arquivos Internos Identifique os Pontos de Cada Fator na Tabela

9. Pontos de Função Não Ajustado

10. Fator de Complexidade Técnica(Technical Complexity Factor)

11. Pontos de Função & Linhas de Código Pontos de Função Linhas de Código (LOC) • Calculando os pontos das funções (FP): • FP = UFP × TCF • Onde: • UFC: Pontos de Função Não Ajustado • TCF: Fator de Complexidade Técnica • Cálculo do Esforço: • Esforço = FP x 16 horas (média) • Duração = Esforço / Pessoas • Pessoas = Esforço / Duração Nota: Entretanto, a correlação entre FP e LOC não é tão adequada. Isto foi provado num estudo de 1985 da Xerox (XER85).

12. Limitações e benefícios dos Pontos de Função Limitações da FPA Benefícios da FPA Foi padronizado pela ISO/IEC 20926 Manual de contagem dos pontos Uma das primeiras métricas a medir o tamanho do software com alguma precisão Mesmo com as limitações, a técnica é bem melhor que as previsões por linha de código • No começo foi amplamente usada. Charles Symons reportou limitações • A complexidade das funções e o peso não é suficientes • A forma de utilizar arquivos evoluiu muito nestes anos • A interação humana é muito mais online do que batch • Faltam fatores ambientais nos fatores técnicos

13. Extensão dos métodos: Pontos de Função e Pontos de Função MK II Era parte integrante do RUP até a versão 6 O método permite a estimativa de esforço já à partir do desenho dos Casos de Uso Ideia: Ponderar o peso de cada Caso de Uso e de cada Ator envolvido Considerar a complexidade técnica e ambiental Considerar a produtividade da empresa Pontos Por Casos de Uso (Karner)

14. Peso dos Casos de Uso (Use Case Weight) • Transação: • É o conjunto de atividades que devem ser executadas atomicamente. • Normalmente, é o número de passos de um Caso de Uso (incluindo os fluxos alternativos). • Comentário: • Se um caso de uso está muito complexo é sinal que ele deve ser dividido.

15. Peso dos Atores (Actor Weight) • Complexidade: • A interface do ator com o software que está em desenvolvimento é o determinante do esforço necessário para realizar a interface dos atores com os casos de uso do sistema • As interfaces gráficas, orientadas a eventos são as mais complexas

16. Fator de Complexidade Técnica(Technical Complexity Factor)

17. Fator de Complexidade Ambiental(Environmental Complexity Factor)

18. Pontos de Caso de Uso & Esforço Pontos de UC Esforço Esforço = UCP x Horas Homem Horas Homem (HH): Karner sugeriu 20 em 1993 Schneider e Winters (1998): P1 = Número de Pontos de E1 a E6 que são menores que 3 P2 = Número de Pontos de E7 a E8 que são maiores que 3 Se (P1 – P2) ≤ 2 então HH = 20 Se (P1 – P2) = 3 ou 4 então HH = 28 Se (P1 – P2) > 4 então reveja o projeto ou use HH = 36 • Calculando os pontos dos Casos de Uso (UCP): • UCP = (UUCW + UAW) x TFC x ECF • Onde: • UUCW: Peso Não Ajustado dos Casos de Uso • UAW: Peso Não Ajustado dos Atores • TCF: Fator de Complexidade Técnica • ECF: Fator de Complexidade Ambiental

19. Exemplo: Sistema de Compras Online S S C C M S C M M C C C C C

20. Peso dos Atores e Casos de Uso do Exemplo Atores Casos de Uso

21. Fator de Complexidade Técnica do Exemplo

22. Fator de Complexidade Ambiental do Exemplo

23. Pontos de Caso de Uso & Esforço do Exemplo • Calculando os pontos dos Casos de Uso (UCP): • UCP = (UUCW + UAW) x TFC x ECF • UCP = (100 + 13) x 1,02 x 1,085 = 125,06 • Calculando o esforço: • Esforço = UCP x Horas Homem • Karner: • Esforço = 125,06 x 20 = 2501 • Schneider e Winters: • P1 = 5 • P2 = 1 • P1 – P2 = 4  suspender o projeto ou utilizar HH = 36 • Esforço = 125,06 x 36 = 4502 • Dicas de mercado sobre Horas Homem: • Se tem histórico: • HH = ( ∑ Horas / ∑ UCP ) Reais • Se não tem histórico: • Avalie a maturidade da equipe como um todo • Considere HH: • Experts: HH = 15 • Másters: HH = 20 • Sênior: HH = 25 • Pleno: HH = 30 • Júnior: HH = 36

24. Limitações e benefícios do método de Karner Limitações dos UCP Benefícios dos UCP É baseado em escopo definido É de fácil utilização pelos técnicos É de fácil entendimento pelos clientes e usuários finais É baseado em UC, que são muito utilizados pela indústria de software São mais estáveis que os pontos de função Pode ser utilizado em tempo de concepção do projeto, ou seja, em tempo de proposta comercial • Os UC não devem ultrapassar o nível complexo • Se necessário, quebre o UC • Devido à subjetividade, a padronização dos UC é impossível, isto dificulta a aplicação do método • Alguns especialistas desaconselham o método devido ao risco • Os requisitos não-funcionais não são tratados pelo método • Não existem registros publicados de testes com projetos grandes e médios

25. COCOMO II (Boehm) • Hierarquia de modelos de estimativas • Mede: Esforço, Prazo e Custo • Entradas: PF (Pontos de Função) e LOC (Linhas de Código)

26. Modelo Básico Equações Tipo de Projeto • Onde: • Esforço: Horas mensais / Pessoa • Duração: Em meses • KLOC: Milhares de LOC estimadas para o projeto. Estimadas pelo método Delphi e PERT • Fatores: Vide tabela ao lado, considerando o tipo do projeto • Orgânico: • Projetos pequenos, simples, com requisitos rígidos, equipe pequena e experiente na aplicação • Semi-orgânico: • Projetos intermediários, com requisitos semi-rígidos, equipes com diferentes níveis de experiência • Embarcados: • Software para rodar no hardware

27. Modelo Intermediário - Fatores de Ajuste

28. Modelo Intermediário • Equação: • Onde: • FAE: Fator de Ajuste de Esforço • Tipo de Projeto: • Calibragem dos Fatores: • Os parâmetros originais vem calibrados com base em 161 projetos de sucesso. • Estes projetos foram escolhidos entre 2000, seguindo critérios científicos e estatísticos. • O importante é calibrar estes fatores com dados históricos de sua empresa.

29. Modelo Avançado de Pontos de Objeto Ideias Equações Pontos dos Objetos (PO): Pontos Ajustados (APO): Produtividade: Utilize dados históricos Esforço: • Calcular o Tamanho do Objeto (TO) por meio de: • Telas de interface com o usuário • Relatórios • Componentes do software • Fatores adicionais: • Ponderação de cada objeto pelas tabelas do método • % de reutilização de código • Produtividade da equipe

30. Modelo Avançado - Esforço no Ciclo de Vida • É um modelo de várias variáveis que distribui o esforço ao longo do ciclo de vida de desenvolvimento • Equação: • Onde: • Esforço: em pessoas por mês • KLOC: Milhares de linha de código • B: Fator especial de habilidades (vide tabela no artigo original) • P: Fator de produtividade

31. Exemplo de aplicação do COCOMO II • Contexto: • Projeto complexo, mas conhecido • Tamanho estimado = 96 KLOC • Pouca experiência sobre a aplicação • Conhecimento da linguagem de programação: muito baixo • Tamanho do DB elevado • Metodologia de desenvolvimento: nenhuma • O custo do pessoal é $3K por mês • Pergunta: • Usando estimativas intermediárias, valeria a pena investir: • $100K em metodologias • $120K em treinamento em linguagem de programação • Objetivo: Alcançar o valor nominal para tais características • Cálculos: • O esforço é 762 pessoas mês • Custo em pessoal é $(762 * 3K) = $2286K • Treinamento em Metodologia: • Estimativas reduzidas em 70 pessoas mês = $210K • A economia é de $110K • Treinamento em Linguagem de Programação: • Estimativas reduzidas em 94 pessoas mês = $282K • A economia é de $162K

32. Quadro Comparativo das Técnicas

33. Tabela de Distribuição de Esforços x Fase • Projetos Típicos: • Projetos Complexos: • Planejamento da Elaboração:

34. Resultados de Projeto Real Distribuição de Horas Premissas Concepção feita antes Modelagem de negócios inclusa na Concepção Erro de estimativa: -5% Distribuição utilizada:

35. Referências