Estimativa de Esforço de Software Orientado a Objetos

Mestrado em Ciência da ComputaçãoEngenharia de SoftwareAntônio Valença25/3/2003

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

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

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

Técnicas estudadas

Pontos de função COCOMO Metodologias agéis Pontos de caso de uso

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.

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

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

Modelo proposto

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

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

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 Passo 4 – Calcular o Fator Ambiental (EF) 11

EF = C1 + EFP, onde EFP = C2 Fi * Pi; C1 = 1,4; C2 = -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.

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

Passo 5 – Calcular o UCP (Pontos de Casos de Uso)

UCP = UUCP * EF

Modelo proposto

Passo 6 – Calcular o total de homens-hora (THH) Considere EFQ = ((Quantidade de EF1 a EF8 com valor < 3) + (Quantidade de EF9 a EF11

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

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

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 Projeto Analista de Negócios Arquiteto de Software Engenheiro de Software

1 20% 10% 70% - 1