Estimativa de Esforço de Software Orientado a Objetos Mestrado em Ciência da Computação Engenharia de Software Antônio Valença 25/3/2003.

Apresentação em tema: "Estimativa de Esforço de Software Orientado a Objetos Mestrado em Ciência da Computação Engenharia de Software Antônio Valença 25/3/2003."— Transcrição da apresentação:

1 Estimativa de Esforço de Software Orientado a Objetos Mestrado em Ciência da Computação Engenharia de Software Antônio Valença 25/3/2003

2 Prediction is very difficult, especially about the future. Niels Bohr (1885 - 1962)

3 Cenário Atual Ausência de prática consolidada Necessidade de conhecimento aprofundado do problema Dependência de especialistas Complexidade das técnicas Desrespeito às particularidades de cada organização

4 Questões Chave para uma efetiva estimativa* Manter ela simples; Usar o que aconteceu no passado; Aprender com a experiência * Martin Fowler – Planning Extreme Programming

5 Técnicas estudadas Pontos de função COCOMO Metodologias agéis Pontos de caso de uso

6 Solução proposta – Pontos de caso de uso Pontos negativos  Baixa adoção (proposto originalmente por Gustav Karner em 1993);  Subjetividade;  Necessidade de entendimento razoável dos requisitos; Pontos positivos  Baseado em escopo definido;  Grau de expertise necessário para o uso não é grande;  Baseado em casos de uso, que é uma técnica largamente adotada pela indústria de software e facilmente compreendida por usuários finais além de serem mais estáveis que pontos de função;  Possibilidade de uso em tempo de proposta.

7 Modelo proposto Casos de Uso  Número ideal entre 10 e 50 (não mais que 100)  Não confundir cenários de uso com casos de uso  Focar em casos de uso externos  Evitar o uso de generalizações entre atores  Descrição nome de identificação e/ou um número nome do ator iniciante breve descrição do objetivo do caso de uso seqüência numerada de passos (entre 3 e 8 passos) que descrevem o principal cenário de sucesso

8 Modelo proposto Não utilização de fatores de complexidade técnica Fatores ambientais  Novo fator para Arquitetura  Novo fator para Customização do processo  Novo fator para Experiência nas ferramentas de desenvolvimento utilizadas  Aumento do peso do fator ambiental Linguagem de Programação Difícil E o especialista? Refinamento de pesos em fatores ambientais e complexidade Riscos  known unknown  unknown unknown Capital Humano necessário  Homens-hora no projeto X homens-hora por papel no projeto

9 Modelo proposto Passo 1 – Identificar atores classificando-os por nível de complexidade ComplexidadeDefiniçãoPeso SimplesUm ator é simples se ele representa outro sistema com uma API (application programming interface) definida. 1 MédioUm ator é médio se ele é: 1.Uma interação com outro sistema através de um protocolo; 2.Uma interação humana via interface não gráfica. 2 ComplexoUm ator é complexo se ele interage através de um interface gráfica (GUI). 3

10 Modelo proposto Passo 2 – Levantar todos os casos de uso externos do sistema, classificando-os por nível de complexidade ComplexidadeDefiniçãoPeso SimplesUm caso de uso é simples se ele tem 3 ou menos transações, incluindo fluxos alternativos. Você deve poder realizar o caso de uso com menos de 5 objetos de análise. 5 MédioUm caso de uso é médio se ele tem entre 4 e 7 transações incluindo os fluxos alternativos. Você deve poder realizar o caso de uso com uma quantidade de 5 a 10 objetos de análise. 10 ComplexoUm caso de uso é complexo se ele tem mais que 7 transações incluindo os fluxos alternativos. O caso de uso deve necessitar de pelo menos 10 objetos de análise para ser realizado. 15

11 Modelo proposto Passo 3 – Calcular o UUCP (Pontos de Caso de Uso Não Ajustados) considerando os pesos dos atores e os casos de uso conjuntamente 6 UUCP =  n i * Pi, onde n i é o número de itens de variedade i. i=1

12 Modelo proposto Passo 4 – Calcular o Fator Ambiental (EF) 11 EF = C 1 + EFP, onde EFP = C 2  F i * P i ; C 1 = 1,4; C 2 = -0,022 i=1 Fi é um fator que é classificado em uma escala de 0 a 5. 0 significa que é irrelevante e 5 significa que ele é essencial. Se o fator não é importante nem irrelevante ele receberá o valor 3. Se todos os fatores tiverem o valor 3 o EF será 1. FiFi Fatores que contribuem para a eficiênciaPiPi 1Familiar com o processo de desenvolvimento de software utilizado1,5 2Experiência com a aplicação0,5 3Experiência com orientação a objetos1 4Capacidade do Analista Líder0,5 5Motivação1 6Requisitos estáveis2 7Arquitetura utilizada2 8Tailoring do processo1,5 9Trabalhadores em tempo parcial 10Linguagem de programação difícil-2 11Experiência com ferramentas de desenvolvimento utilizadas

13 Modelo proposto Passo 5 – Calcular o UCP (Pontos de Casos de Uso) UCP = UUCP * EF

14 Modelo proposto Passo 6 – Calcular o total de homens-hora (THH)  Considere EFQ = ((Quantidade de EF 1 a EF 8 com valor 3)), onde EF i é o Fator ambiental i  THH = UCP * HHUCP CenárioHHUCP - Homens-hora por UCP Se EFQ <= 320 Se EFQ >= 4 E EFQ <= 528 Se EFQ >= 636

15 Modelo proposto Passo 7 – Estimar (em horas-homem) atividades não associadas a casos de uso  Somar a estimativa ao THH

16 Modelo proposto Passo 8 – Calcular o número de profissionais a serem alocados de acordo com o perfil  Se THH <= 880 usar TP = ARREDONDAR.PARA.CIMA(THH / 176);  Se THH > 880 usar TP = ROUND(THH / 176);  Total Profissionais por Mês - TPm = ROUND(TP / m) Gerente de ProjetoAnalista de NegóciosArquiteto de SoftwareEngenheiro de Software 120%10%70% - 1

17 F1: Familiar com o processo de desenvolvimento de software utilizado Na lista de fatores originais proposta por Karner, este fator é chamado de “Familiar com o RUP (Rational Unified Process)”. Contudo, experiência da indústria mostra que nem sempre os projetos usam o RUP. Este inclusive é o caso do CESAR, que usa um projeto baseado no RUP, mas adaptado às necessidades da empresa e adequando ao PMBOK [PMI00] e ao CMM [SEI93]. Score 0: o time não é familiarizado com o processo; Score 1: o time têm conhecimento teórico do processo de desenvolvimento; Score 2: até 30% dos membros do time usaram o método uma ou mais vezes; Score 3: entre 30% e 70% dos membros do time usaram o método uma ou mais vezes; Score 4: mais de 70% dos membros do time têm experiência usando o método em projetos diferentes; Score 5: o time todo têm experiência usando o método em diversos projetos diferentes. <<<

18 F9: Trabalhadores em tempo parcial Ter de treinar novas pessoas ou não ter um time estável influencia a produtividade negativamente. Score 0: não existem trabalhadores em tempo parcial; Score 1: poucos trabalhadores (em torno de 20%) em tempo parcial; Score 2: poucos trabalhadores (em torno de 40%) em tempo parcial; Score 3: parcela razoável dos trabalhadores (em torno de 60%) em tempo parcial; Score 4: grande maioria dos trabalhadores (em torno de 80%) em tempo parcial; Score 5: todo o time é composto de trabalhadores em tempo parcial <<<