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

Apresentação em tema: "Gestão de Configuração & Mudanças 2. Estimativas de Esforços"— Transcrição da apresentação:

1 Gestão de Configuração & Mudanças 2. Estimativas de Esforços
Márcio Aurélio Ribeiro Moreira

2 Como estimar o esforço do projeto?
Disciplina Elementos Disponíveis Qual a melhor opção? Modelagem de Negócio Casos de Uso de Negócio Processos ou Operações Casos de Uso de Sistema Requisitos Lista de Features Análise & Projeto Arquitetura do Software Classes & Diagramas Implementação Modelo de Implementação Código Fonte Testes Casos de Teste Distribuição Plano de Distribuição Diagrama de Distribuição Gestão de Configuração e Mudanças Itens de Configuração Mudanças Gestão do Projeto Plano de Desenvolvimento do Software Ambiente Processo & Ferramentas

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

4 Técnica Delphi (Empírica)
PERT 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 Criação: 1950: Marinha Americana Popularização: Década 70 em projetos (PMI) Ideia: Combinar visões Otimista, Realista e Pessimista Equações: 𝑀é𝑑𝑖𝑎= 𝑂+4 𝑥 𝑅+𝑃 6 , 50% 𝑐ℎ𝑎𝑛𝑐𝑒 𝐷𝑒𝑠𝑣𝑖𝑜= 𝑃 − 𝑂 6 A Média ± Desvio tem 90% de chance de ocorrer

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: COnstructive COst MOdel 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 Tipos ≠ de Arquivos Tipos ≠ de Campos 1 a 4 5 a 15 ≥ 16 0 ou 1 Simples Médio 2 Complexo ≥ 3 Tipos ≠ de Arquivos Tipos ≠ de Campos 1 a 5 6 a 19 ≥ 20 0 ou 1 Simples Médio 2 ou 3 Complexo ≥ 4 C: Consultas Externas (entrada) C: Consultas Externas (saídas) Tipos ≠ de Arquivos Tipos ≠ de Campos 1 a 4 5 a 15 ≥ 16 0 ou 1 Simples Médio 2 Complexo ≥ 3 Tipos ≠ de Arquivos Tipos ≠ de Campos 1 a 5 6 a 19 ≥ 20 0 ou 1 Simples Médio 2 ou 3 Complexo ≥ 4

8 Arquivos Externos e Internos
D: Arquivos Externos E: Arquivos Internos Tipos ≠ de Registros Tipos ≠ de Campos 1 a 19 20 a 50 ≥ 51 1 Simples Médio 2 a 5 Complexo ≥ 6 Tipos ≠ de Registros Tipos ≠ de Campos 1 a 19 20 a 50 ≥ 51 1 Simples Médio 2 a 5 Complexo ≥ 6 Identifique os Pontos de Cada Fator na Tabela Fator Simples Médio Complexo A 3 4 6 B 5 7 C D 10 15 E

9 Pontos de Função Não Ajustado
Complexidade  Simples Médio Complexo Total de Pontos  Fatores Número Peso A: Entradas Externas S 3 M 4 C 6 Sx3 + Mx4 + Cx6 B: Saídas Externas 5 7 C: Consultas Externas D: Arquivos Externos 10 15 E: Arquivos Internos Pontos de Função Não Ajustado (UFP: Unadjusted Function Points): ∑

10 Fator de Complexidade Técnica (Technical Complexity Factor)
Descrição Grau de Influência 1 Nível de comunicação de dados Defina o grau de influência do fator utilizando a escala: 0: Irrelevante 1: Baixa 2: Moderada 3: Média 4: Alta 5: Crítica 2 Nível de distribuição das funções 3 Nível de performance requerido (desempenho) 4 Nível de padronização da configuração utilizada 5 Taxas de transação utilizadas 6 Nível de entrada de dados online 7 Nível de adequação do projeto à eficiência do usuário 8 Nível de atualizações online 9 Nível de complexidade de processamento 10 Nível de reutilização esperada deste software 11 Nível de facilidade de instalação 12 Nível de facilidade de uso 13 Nível de utilização em locais (sites) diferentes 14 Nível de facilidade de mudança necessário TCF = 0,65 + 0,1 x DI DI = ∑ Grau de Influência

11 Pontos de Função & Linhas de Código
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 Linguagem Média de LOC ou FP Assembler 300 COBOL 100 FORTRAN Pascal 90 Ada 70 PL/1 65 Orientadas a Objeto 30 4ª Geração (4GL) 20 Gerador de Código 15 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 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 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

13 Pontos Por Casos de Uso (Karner)
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 dos Atores Pontos dos Casos de Uso Complexidade Técnica Fatores Ambientais Produtividade Estimativa de Esforço

14 Peso dos Casos de Uso (Use Case Weight)
Complexidade Número de Transações Peso Simples Até 3 transações [  Realizáveis com até 5 objetos de análise (classes) e 1 entidade de Banco de Dados ] 5 Médio De 4 a 7 transações [  Realizáveis com 6 a 10 objetos de análise e até 2 entidades de Banco de Dados ] 10 Complexo Acima de 7 transações [  Realizáveis com mais de 10 objetos de análise e até 3 entidades de Banco de Dados ] 15 Peso Não Ajustado dos UC (UUCW) = UC Simples x 5 + UC Médios x 10 + UC Complexos x 15 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 Número de Transações Peso Simples Sistema externo que se comunica com o nosso via interface bem definida. Ex.: API 1 Médio Sistema externo que se comunica com o nosso via protocolos padrões. Ex.: TCP/IP, FTP, HTTP ou SQL [ Interação humana via interface clássica (texto, não gráfica) ] 2 Complexo Pessoas interagindo com nosso sistema via interface gráfica (GUI) orientada a eventos 3 Peso Não Ajustado dos Atores (UAW) = Atores Simples + Atores Médios x 2 + Atores Complexos x 3 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)
Descrição Peso Valor Pontos T1 Nível de distribuição do sistema 2,0 Defina a importância deste fator para o software a ser desenvolvido: 0: Irrelevante 1: Baixa 2: Média 3: Alta 4: Muito alta 5: Crítica X T2 Agressividade dos tempos de resposta 1,0 T3 Nível de eficiência para o usuário T4 Nível de complexidade interna de processamento T5 Nível de reuso de código T6 Facilidade de instalação necessária 0,5 T7 Facilidade de uso necessária T8 Necessidade de portabilidade para outras plataformas T9 Nível de facilidade de manutenção necessário T10 Nível de processamento concorrente ou paralelo T11 Nível dos recursos de segurança T12 Nível de acesso externo para terceiros T13 Nível de treinamento dos usuários TCF = 0,6 + (TF / 100) TF = ∑ ( Peso x Valor)

17 Fator de Complexidade Ambiental (Environmental Complexity Factor)
Descrição Peso Valor Pontos E1 Familiaridade com o processo de desenvolvimento 1,5 Defina o nível de experiência da equipe: 0: Inexperiente 1: Júnior 2: Pleno 3: Sênior 4: Máster 5: Especialista X E2 Nível de experiência na aplicação 0,5 E3 Nível de experiência com a orientação a objeto 1,0 E4 Nível de capacidade do analista E5 Nível de motivação da equipe E6 Nível de estabilidade dos requisitos 2,0 E7 Nível de pessoas com dedicação parcial na equipe -1,0 E8 Nível de dificuldade da linguagem de programação ECF = 1,4 + (-0,03 x EF) EF = ∑ ( Peso x Valor)

18 Pontos de Caso de Uso & Esforço
Pontos de UC Esforço 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 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

19 Exemplo: Sistema de Compras Online

20 Peso dos Atores e Casos de Uso do Exemplo
Complexidade Peso Quantidade Pontos Simples 1 Médio 2 Complexo 3 4 12 Peso Não Ajustado dos Atores - UAW: 13 Complexidade Peso Quantidade Pontos Simples 5 2 10 Médio 3 30 Complexo 15 4 60 Peso Não Ajustado dos UC - UUCW: 100

21 Fator de Complexidade Técnica do Exemplo
Descrição Peso Valor Pontos T1 Nível de distribuição do sistema 2,0 5 10 T2 Agressividade dos tempos de resposta 1,0 T3 Nível de eficiência para o usuário 3 T4 Nível de complexidade interna de processamento 2 T5 Nível de reuso de código T6 Facilidade de instalação necessária 0,5 1 T7 Facilidade de uso necessária 2,5 T8 Necessidade de portabilidade para outras plataformas 4 T9 Nível de facilidade de manutenção necessário T10 Nível de processamento concorrente ou paralelo T11 Nível dos recursos de segurança T12 Nível de acesso externo para terceiros T13 Nível de treinamento dos usuários TFC = 0,6 + (TF / 100) = 0,6 + (42 / 100) = 1,02 TF: 42

22 Fator de Complexidade Ambiental do Exemplo
Descrição Peso Valor Pontos E1 Familiaridade com o processo de desenvolvimento 1,5 3 4,5 E2 Nível de experiência na aplicação 0,5 E3 Nível de experiência com a orientação a objeto 1,0 2 2,0 E4 Nível de capacidade do analista 5 2,5 E5 Nível de motivação da equipe E6 Nível de estabilidade dos requisitos 1 E7 Nível de pessoas com dedicação parcial na equipe -1,0 0,0 E8 Nível de dificuldade da linguagem de programação 4 -4,0 ECF = 1,4 + (-0,03 x EF) = 1,4 + (-0,03 x 10,5) = 1,085 EF: 10,5

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

25 COCOMO II (Boehm) Avançado – Desenvolvimento (Implementação)
Hierarquia de modelos de estimativas Mede: Esforço, Prazo e Custo Entradas: PF (Pontos de Função) e LOC (Linhas de Código) Avançado – Desenvolvimento (Implementação) Esforço = função(anteriores, impacto deles por fase) Intermediário – Arquitetura (Projeto Antecipado) Esforço = função(tamanho, produto, hardware, pessoal e atributos) Básico – Prototipação (Composição do Software) Esforço = função(tamanho em LOC)

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 Tipo a b c d Orgânico 2,4 1,05 2,5 0,38 Semi-orgânico 3,0 1,12 0,35 Embarcados 3,6 1,2 0,32 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
Fatores de Ajuste do Esforço (FAE) Muito Baixo Normal Alto Altíssimo Atributos do Produto: Confiabilidade do sistema 0,75 0,88 1,00 1,15 1,40 Tamanho do aplicativo 0,94 1,08 1,16 Complexidade do produto 0,70 0,85 1,30 1,65 Atributos de Hardware: Restrições de performance 1,11 1,66 Restrições de memória 1,06 1,21 1,56 Máquina virtual 0,87 Recuperação de falhas 1,07 Atributo de Pessoal: Capacidade de análise 1,46 1,19 0,86 0,71 Capacidade de engenharia de software 1,29 1,13 0,91 0,82 Experiência no domínio 1,42 1,17 Experiência com máquina virtual 1,10 0,90 Experiência na linguagem de programação 1,14 0,95 Atributos do Projeto: Disponibilidade de ferramentas para o uso 1,24 Aplicação de métodos de engenharia de software 0,83 Cronograma de desenvolvimento 1,23 1,04

28 Modelo Intermediário Equação: Tipo de Projeto: Calibragem dos Fatores:
𝐸𝑠𝑓𝑜𝑟ç𝑜=𝑎 𝑥 𝐾𝐿𝑂𝐶 𝑏 𝑥 𝐹𝐴𝐸 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. Tipo a b Orgânico 3,2 1,05 Semi-orgânico 3,0 1,12 Embarcados 2,8 1,20

29 Modelo Avançado de Pontos de Objeto
Ideias Equações 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 Pontos dos Objetos (PO): 𝑃𝑂= 𝑇𝑂 𝑥 𝑃𝑜𝑛𝑑𝑒𝑟𝑎çã𝑜 Pontos Ajustados (APO): 𝐴𝑃𝑂=𝑃𝑂 𝑥 (1 −%𝑅𝑒𝑢𝑠𝑜) Produtividade: 𝑃𝑟𝑜𝑑𝑢𝑡𝑖𝑣𝑖𝑑𝑎𝑑𝑒 = 𝐴𝑃𝑂 𝑃𝑒𝑠𝑠𝑜𝑎𝑠 𝑀ê𝑠 Utilize dados históricos Esforço: 𝐸𝑠𝑓𝑜𝑟ç𝑜= 𝐴𝑃𝑂 𝑃𝑟𝑜𝑑𝑢𝑡𝑖𝑣𝑖𝑑𝑎𝑑𝑒

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: 𝐸𝑠𝑓𝑜𝑟ç𝑜= ( 𝐾𝐿𝑂𝐶 𝑥 𝐵 0,333 𝑃 ) 3 𝑥 ( 1 𝑇 ) 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
Parâmetro Delphi/PERT FPA UCP COCOMO II É independente de linguagem de programação Sim Não Fornece algum programa de certificação É independente de expertise humana Margem de Erro clássica (inferência empírica) ±40% Requisitos: ±30% Projeto: ±10% ±30% ±20% Disciplina de entrada M. Negócio Requisitos Projeto Nível de detalhamento Menor Médio Maior Principal fator limitante Necessidade de Expertise Falta de Fatores Ambientais Falta atualizar o método Subjetivismo Requisitos Não Funcionais e Falta Testes Estimativa tardia e Depende do KLOC Principal benefício Simplicidade Padronização e adoção Uso em tempo de propostas Precisão

33 Tabela de Distribuição de Esforços x Fase
Projetos Típicos: Projetos Complexos: Planejamento da Elaboração: Gastos x Fases Concepção Elaboração Construção Transição Tempo Gasto 10% 30% 50% Recursos Gastos 5% 20% 65% Gastos x Fases Concepção Elaboração Construção Transição Tempo Gasto 20% 33% 40% 7% Recursos Gastos 8% 24% 60% Fases Modelo de Negócios Completado Casos de Uso Identificados Descritos Analisados Projetados, Implementados e Testados Concepção 50% a 70% 50% 10% 5% Uma pequena percentagem Só as provas de conceito Elaboração Perto de 100% 80% ou mais 40% a 80% 20% a 40% Menos de 10% Construção 100% se Mantido

34 Resultados de Projeto Real
Distribuição de Horas Premissas Resumo % Gestão de Requisitos 10% Análise & Projeto 16% Implementação 24% Testes 23% CRs Gestão de Projetos/Config. E Mudança 6% Ambiente e Distribuição 7% Testes de Aceite 3% Total: 100% Concepção feita antes Modelagem de negócios inclusa na Concepção Erro de estimativa: -5% Distribuição utilizada: Disciplina % M.Negócio/Requisitos 10% Análise 8% Projeto 22% implementação 35% Teste 16% Gerenciamento Ambiente 1%

35 Referências Sigla Referência BBO95
Barry Boehm, Bradford Clark, at al. Cost Models for Future Software Life Cycle Processes: COCOMO 2.0. Annals of Software Engineering S&W98 Geri Schneider & Jason P. Winters. Applying Use Cases: A Practical Guide. Addison Wesley. 1998 GKA93 Gustav Karner. Resource Estimation for Objectory Projects. Objective Systems SF AB JOS99 John Smith. A Estimativa de Esforço Baseada em Casos de Uso. Rational KRB01 Kirsten Ribu. Estimating Object-Oriented Software Projects with Use Cases. Master of Science Thesis, University of Oslo, Department of Informatics M&C08 Manfred Bundschuh & Carol Dekkers. The IT Measurement Compendium. Estimating and Benchmarking Sucess with Functional Size Measurement. Springer MTD09 Marlise There Dias. Um guia para estimativa de projetos de software em micro e pequenas empresas. Univali PVI03 Paul Vickers. An Introduction to Function Point Analysis. Computing UNN RKC06 Roy K. Clemmons. Project Estimation With Use Case Points. CROSSTALK XER85 Xerox. A Cooperative Industry Study: Software Development/Maintenance Productivity; Xerox Corporation