Prof. Horácio ribeiro
Disciplina: PE- medidas do esforço no desenvolvimento de software Aula 06: Estimativas de esforço e prazo – cocomo/cocomo II
(aula 6 ) ESTIMATIVAS – COCOMO Para decidir-se se devemos fazer um desenvolvimento para uma nova aplicação devemos saber quanto tempo será necessário, e quanto vai custar? Vale a pena? As estimativas de custos e prazos em software não são ciência exata, mas temos necessidades de diminuirmos à nível de erro das nossas estimativas. Existem muitos aspectos que podem influenciar nas estimativas. Um erro na estimativa pode comprometer o projeto e serem desastrosos para os desenvolvedores. As estimativas normalmente são feitas a partir de uma série histórica baseada em projetos feitos anteriormente. Neste caso registraram-se várias informações, tempo por fase do projeto, tempo de codificação, quantidade de programadores e outras informações. Estas informações após tratadas são a base para estimar e acompanhar a execução de novos projetos. Os dados podem ser colocados em gráficos e estes gráficos definem famílias de curvas. Estas curvas são ajustadas a funções matemáticas. Estas funções matemáticas são usadas para valores que não constam nas tabelas. Quando não se tem nenhuma informação é comum fazer as estimativas baseadas na experiência dos profissionais. Neste caso podem-se registrar as estimativas de vários profissionais e trabalharmos com valores resultantes destes valores. Podese, por exemplo, usar a forma ponderada, baseado na fórmula: PM + Pm + 4*Pmedio Prazo estimado = __________________ 6 Onde : PM é o maior prazo dado Pm é o menor prazo dado Pmedio é a media dos prazos dados A formula é uma recomendação do PMI para estimativas de tarefas, e aceita pelos gestores de projetos, pois o PM considera o caso mais pessimista e o Pm o caso mais otimista. Desta forma pode-se compensar alguma distorção na execução das tarefas. Exemplo de aplicação, 9 técnicos experientes deram uma estimativa de prazo para uma determinada tarefa que não temos nenhum registro. Tecnico1: 10 dias tecnico2: 20 dias tecnico3: 15 dias Técnico4: 12 dias tecnico5: 8 dias tecnico6: 25 dias Tecnico7: 15 dias tecnico8: 12 dias tecnico9: 15 dias
Texto experimental: emails pelo site WWW.espacodoprofessor.com
Prof. Horácio ribeiro
Para estimar o prazo de projeto temos de calcular a média dos prazos: Prazo médio=(10+20+15+12+8+25+15+12+15)/9 = 15 dias Prazo de projeto =( 25 + 8 + 4*15)/6 = 15,5 entendendo: 15 dias + meio dia Se convertermos em horas de trabalho, considerando que um dia tem 8 horas de trabalho, a tarefa está estimada em levar 15*8 + 4 =124 horas Existe também a possibilidade de se usar o método de DELPHOS com os 9 profissionais, mas este assunto deverá ser tratado em Gerencia de projeto. O processo de estimativa envolve basicamente quatro atividades: 1 2 3 4
– – – –
estimar Estimar estimar estimar
o o a o
tamanho do produto a ser gerado. esforço empregado na execução do projeto duração do projeto custo do projeto
Para se fazer estimativa usam-se duas unidades básicas: 1000 linhas de código (KLOC) e Ponto Função (PF). As estimativas utilizando o tamanho (KLOC) para serem confiáveis deve-se estar em fases adiantadas do projeto, devido à incerteza. O gráfico abaixo [sommerville, Ian] mostra o Nível de variação de erro de uma estimativa nas diversas fases do projeto. Apenas na fase de codificação se torna mais próxima do real.
Um dos primeiros pesquisadores de software a se preocupar com o assunto de estimativas e estudar os custos envolvidos em projetos foi Barry Boehm, em seu livro sobre engenharia econômica do software em 1891. Neste trabalho foram estudados mais de 5000 projetos de software. Estes softwares foram classificados segundo uma hierarquia de modelos que recebeu o nome de COCOMO que vem de COnstructive COst MOdel (Modelo de Custos Construtivos)
Texto experimental: emails pelo site WWW.espacodoprofessor.com
Prof. Horácio ribeiro
A hierarquia de modelos serve para classificar o tipo do software que desejamos estimar: Modelo 1 (básico): Chamado de COCOMO Básico é um modelo é um modelo estático de valor simples que computa o esforço de desenvolvimento de software como uma função do tamanho expresso em linhas de código. (Pressman) Modelo 2 (intermediário) Chamado de COCOMO intermediário computa o esforço de desenvolvimento como uma função do tamanho, e de um conjunto de direcionadores de custo (definidos em tabelas) que incluem avaliações subjetivas do produto, hardware, experiência do pessoal e dos atributos do projeto. (Pressman) Modelo 3 (avançado) Chamado de COCOMO avançado incorpora a versão intermediária e faz uma avaliação dos impactos nos direcionadores de custo sobre cada passo do processo de desenvolvimento ( analise, projeto, codificação, testes...) Usando a terminologia de Boehm o COCOMO pode ser aplicado em três classes de projeto: 1 – Modo Orgânico ou convencional: projetos de software simples, pequenos, pequenas equipes com relativa experiência. Trabalha-se um conjunto de requisitos não tão rígidos, pode-se exemplificar pequenos sistemas. 2 – Modo Semi destacado ou difuso: Projetos de software intermediário (em tamanho e complexidade) na qual temos equipes com vários níveis de experiência que devem programar uma combinação de requisitos rígidos. Por exemplo um sistema de processamento de transações. 3 – Modo Embutido ou restrito – um projeto que deve ser desenvolvido dentro de restrições operacionais, como por exemplo sistema de controle de telefonia. As equações para o COCOMO básico são:
Texto experimental: emails pelo site WWW.espacodoprofessor.com
Prof. Horácio ribeiro N = E/D
(número de pessoas recomendadas)
Onde: E é o esforço aplicado em pessoas-mês. D é o tempo de desenvolvimento em meses cronológicos. KLOC é o número estimado de linhas de código do projeto (em milhares) Os coeficientes N número de pessoas recomendadas no projeto
, , e os expoentes acordo com a tabela abaixo:
Projeto de software Orgânico Semi destacado Embutido
ab 2,4 3,0 3,6
bb 1,05 1,12 1,20
e
são fornecidos de
cb 2,5 2,5 2,5
db 0,38 0,35 0,32
NO modelo intermediário o básico é ampliado considerando-se 4 grandes categorias direcionadoras de custos,. A – Atributos do produto: I – Confiabilidade exigida do software II – Tamanho do Banco de dados. III – Complexidade do software B – Atributos do Hardware I – Restrições de desempenho de run-time II - Restrições de memória III – Mudanças do ambiente de software IV – Tempo de resposta – turnaround C – Atributos de pessoal I – Capacidade dos analistas II – Capacidade dos programadores III – Experiência na aplicação IV – Experiência no ambiente de Hardware V - Experiência com a linguagem de programação D – atributos de projeto I – Uso de ferramenta de software. Texto experimental: emails pelo site WWW.espacodoprofessor.com
Prof. Horácio ribeiro II – técnicas modernas de programação III – Prazo requerido para o desenvolvimento Cada um dos itens acima (15) deve ser avaliado (em importância e valor) numa escala de 6 pontos: -
muito baixo baixo Normal Alto Muito alto Extra alto
Com esta avaliação para cada um dos 15 itens entra-se na tabela de Multiplicadores de Esforço de Desenvolvimento de Software e um multiplicador de esforço é determinado para cada item:
.
O produto dos índices encontrados na tabela torna-se o EAF E a formula de determinação do esforço (E) fica E = a (loc) exp (b) * EAF
Texto experimental: emails pelo site WWW.espacodoprofessor.com
Prof. Horácio ribeiro Onde o coeficiente a e o expoente b são fornecidos pela tabela: Projeto de software Orgânico Semi destacado Embutido
a 3,2 3,0 2,8
b 1,05 1,12 1,20
Exemplo de uso do COCOMO 81. Considere um software
com 33,3 Kloc, usando o modelo semi destacado temos:
E = 3,0 (loc0 exp (1,12) = 3,0 (33,3) elevado a 1,12 = 152 pessoas-mês Duração do projeto: D = 2,5 (E) exp (0,35) = 2,5 *(152)elevado a 0,35 = 14 meses O número ideal de pessoas no projeto N = E/D. = 152/14,5 = 11 pessoas Pode-se balancear o número de pessoas variando o prazo de duração. Exemplo 2: Considere que se deseja fazer estimativas de esforços para um software que irá apoiar o controle de equipamentos de uma empresa. Após uma análise de ponto função determinou-se que o tamanho do software é de 236 PF não ajustado. Como as formulas do COCOMO81 foram construídas com KLOC, devemos buscar em uma tabela de transformação o número de Linhas para cada função. Se utilizarmos a linguagem ACESS temos:
Texto experimental: emails pelo site WWW.espacodoprofessor.com
Prof. Horácio ribeiro
Usando o COCOMO intermediário, o gerente considerou o projeto como orgânico E usaremos as formulas:
EAF
Analisando os 15 direcionadores o gerente concluiu os seguintes resultados: Complexidade do software: alta Restrições quanto ao uso da memória: Alto Experiência com a linguagem de programação: Baixa Capacidade dos programadores: Baixa Os outros atributos foram considerados normais
Texto experimental: emails pelo site WWW.espacodoprofessor.com
Prof. Horรกcio ribeiro
Assim pode-se determinar o EAF EAF = (1,15 * 1,06*1,14*1,17) = 1,63 Desta forma pode-se estimar o esforรงo:
E o prazo:
Com os dados pode-se concluir que iremos necessitar de: 52,42 / 11,26
Texto experimental: emails pelo site WWW.espacodoprofessor.com
Prof. Horácio ribeiro
Que nos indica 5 profissionais para trabalhar no projeto durante 11 meses. COCOMO II O COCOMO II é uma melhora do COCOMO-81 e leva em consideração que há abordagens diferentes para o desenvolvimento, incorpora um conjunto de sub modelos que produzem estimativas detalhadas. Os sub modelos são: A – Um modelo de Composição de aplicação: B – Um modelo de projeto preliminar C – Um modelo de Reuso D – Um modelo de pós arquitetura Modelo de Composição de Aplicação É usado para estimar o esforço necessário para projetos de prototipação e projetos em que o software é desenvolvido pela composição de componentes existentes. A estimativa considera a produtividade do programador, da experiência e capacitação do desenvolvedor e na capacidade de ferramentas cãs usadas para apoiar o desenvolvimento. O método baseia-se na estimativa de pontos de objetos ponderada dividido por uma estimativa padrão de produtividade. A composição da aplicação envolve, normalmente, o reuso significativo do software, por isto deve-se ajustar a estimativa baseada do uso total ao percentual de reuso esperado. A formula de cálculo de esforço é: PM = (NAP * ( 1 - %reuso)/100)/PROD Onde : PM é o esforço estimado em pessoa-mês. NAP é o número total de pontos de aplicação no sistema PROD é a produtividade em pontos de objeto consultada produtividade. (NOP/mês – Número de pontos de Objeto/mês )
na
Tabela de produtividade: Experiência e capacitação desenvolvedor Maturidade e capacitação case PROD( NOP/mês)
do Muito baixa de Muito baixa 4
baixa
Nominal
baixa
nominal
7
13
alta Muito alta alta Muito alta 25 50
O modelo supõem que não há esforços adicionais. Texto experimental: emails pelo site WWW.espacodoprofessor.com
tabela
de
Prof. Horácio ribeiro
Modelo preliminar Usado quando os requisitos do usuário já foram estabelecidos e os estágios iniciais do projeto já estão realizados. É uma estimativa inicial. Faz-se várias suposições simplificadoras. As estimativas neste estágio baseiam-se na tela padrão: Esforço = A * Tamanho elevado a B * M O coeficiente A deve ser 2,94 (proposto por Boehm) o Esforço é em KLOC. O expoente B reflete o crescimento de esforço necessário à medida que cresce o tamanho do projeto, pode variar de 1,1 a 1,24 dependendo do grau de inovação, flexibilidade do desenvolvimento, processos de resolução de riscos, experiência da equipe, maturidade do processo. O multiplicador M baseia-se em um conjunto de características do processo. Estas características usadas no modelo são confiabilidade e complexidade do produto (RCPX) e o reuso (RUSE), a dificuldade da plataforma (PDIF), a capacidade do pessoal (PERS) a experiência do pessoal (PREX), O PRAZO (SCED) e os recursos de apoio (FCIL). Você estima os valores desses atributos usando uma escala de seis pontos, sendo 1 muito baixo e 6 corresponde a valores muito altos. Tem-se a fórmula: PM = 2,94 * Tamanho elevado a B * M Sendo: M = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED
Modelo de reuso A maioria dos sistemas hoje tem um alto índice de re aproveitamento. O modelo de reuso é usado para estimar o esforço necessário para integrar o código gerado e re usável. Considera dois tipos de reuso: caixa preta, neste caso não se considera esforço. Quando considera esforço no reuso chama-se de caixa branca, Existe também a geração de código automaticamente por tradutores ferramentas case. A formula derivada para esta situação é: PM = (ASLOC * AT / 100) / ATPROD. (Gerado) AT é um percentual de código adaptado gerado automaticamente. ATPROD é a produtividade na integração do código é um valor perto de 2400 declarações fonte por mês. ASLOC é o numero de linhas de código nos componentes de quem ser adaptados. Exemplo: Se existir um total de 20 000 linhas de código, com 30% de geração automática temos: (20000 * 30/100)/2400 = 2,5 pessoa-mês.
Texto experimental: emails pelo site WWW.espacodoprofessor.com
Prof. Horácio ribeiro Outro componente é quando o sistema inclui código novo e alguns componentes dêem ficar integrados. Desta forma calcula-se um valor que representa as linhas de código. As estimativas neste modelo de reuso: A formula abaixo é usada para calcular o número de calculo novo. ESLOC = ASLOC * ( 1- AT/100) * AAM Onde: ESLOC número equivalente as linhas de código novo ASLOC é o numero de linhas de código nos componentes de quem ser adaptados. AT percentual de código aproveitado AAM é o multiplicador de ajuste de adaptação e leva em conta o esforço necessário para reutilizar o código. De Maneira simplista AMM é a soma de três componentes: a) Um componente de adaptação (AAF) representa os custos de implementar uma mudança de um código re uso e inclui componentes na mudança do projeto, codificação e de integração. b) Um entendimento do componente (SU) varia de 50 para código complexo ate 10 para código escrito por objetos. c) Fator de avaliação (AA) representa o custo de entendimento do código. varia de 0 a 8 dependendo do esforço de análise.
AA
O modelo de reuso não é linear. Quanto mais reuso se tem os custos de unidade de código diminuem à medida que os custos de entendimento e avaliação estão espalhados pelo meio do código Conclusão: Os modelos baseados em linhas de código têm sido abandonados. Nestes modelos há vários aspectos de complexidade, experiência de equipe, que não existe uma padronização de contagem. Assim, ao se estabelecer um padrão em uma empresa, estas estimativas são usadas, mas ao se precisar trocar informações entre empresas encontra-se dificuldade na padronização da avaliação. Os modelos baseados em PONTO FUNÇÂO são mais consistentes e permitem a inter operação entre empresas pois na definição da quantidade d ponto função já foram considerados aspectos de complexidade, características do software já padronizadas no COM (manual de contagem). Esta aula considera o modelo COMO 81 e COCOMO II pois ainda são muito citados na literatura e são adotados em algumas empresas. Pode-se também usar estes modelos para conferir e validar as estimativas, lembrando-se da imprecisão assumida quando trabalhamos com linha de código
Texto experimental: emails pelo site WWW.espacodoprofessor.com