Estimativa de Esforo de Software Orientado a Objetos

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

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

Cenário Atual n n n 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

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

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

Solução proposta – Pontos de caso de uso n Pontos negativos q q q n Baixa adoção (proposto originalmente por Gustav Karner em 1993); Subjetividade; Necessidade de entendimento razoável dos requisitos; Pontos positivos q q 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.

Modelo proposto n Casos de Uso q q q 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 n n 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

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

Modelo proposto n Passo 1 – Identificar atores classificando-os por nível de complexidade Complexidade Definição Peso Simples Um ator é simples se ele representa outro sistema com uma API (application programming interface) definida. 1 Médio Um 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 Complexo Um ator é complexo se ele interage através de um interface gráfica (GUI). 3

Modelo proposto n Passo 2 – Levantar todos os casos de uso externos do sistema, classificando-os por nível de complexidade Complexidade Definição Peso Simples Um 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édio Um 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 Complexo Um 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

Modelo proposto n 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 = ni * Pi , onde ni é o número de itens de variedade i. i=1

Modelo proposto n Passo 4 – Calcular o Fator Ambiental (EF) 11 EF = C 1 + EFP, onde EFP = C 2 Fi * Pi; C 1 = 1, 4; C 2 = -0, 022 i=1 n 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. Fi Fatores que contribuem para a eficiência Pi 1 Familiar com o processo de desenvolvimento de software utilizado 1, 5 2 Experiência com a aplicação 0, 5 3 Experiência com orientação a objetos 1 4 Capacidade do Analista Líder 0, 5 5 Motivação 1 6 Requisitos estáveis 2 7 Arquitetura utilizada 2 8 Tailoring do processo 1, 5 9 Trabalhadores em tempo parcial -1 10 Linguagem de programação difícil -2 11 Experiência com ferramentas de desenvolvimento utilizadas -1

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

Modelo proposto n Passo 6 – Calcular o total de homens-hora (THH) q q Considere EFQ = ((Quantidade de EF 1 a EF 8 com valor < 3) + (Quantidade de EF 9 a EF 11 com valor > 3)) , onde EFi é o Fator ambiental i THH = UCP * HHUCP Cenário HHUCP - Homens-hora por UCP Se EFQ <= 3 20 Se EFQ >= 4 E EFQ <= 5 28 Se EFQ >= 6 36

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

Modelo proposto n Passo 8 – Calcular o número de profissionais a serem alocados de acordo com o perfil q q q 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 Projeto Analista de Negócios Arquiteto de Software Engenheiro de Software 1 20% 10% 70% - 1