Estudo Dirigido Curso: sistema de informação Disciplina: PE- medidas do esforço no desenvolvimento de software Módulo: Eixo: Aula 06: Estimativas de esforço e prazo – coco mo/coco mo II Todos os itens abaixo elencados são de preenchimento obrigatório pelo autor conteudista que deverá preencher um documento deste a cada aula da disciplina. Legenda: ** Instruções para o conteudista preparar o conteúdo a ser inserido em cada ícone. * Texto padrão a ser utilizado pelo conteudista caso não haja conteúdo a ser inserido no ícone. – Exemplo: utilizar o texto padrão para Livro no campo Livro se não existir nenhuma indicação de capítulo para a aula em questão.
**Redigir objetivos claros e diretos. Começar objetivos com verbos. Não ser prolixo ao enumerar aos objetivos. Usar os objetivos como uma ferramenta que direcione o que o aluno deve ter como foco ao relacionar os objetivos apresentados ao conteúdo da aula. Cuidado! Geralmente pensamos em objetivos do tipo: Estudar o panorama da economia mundial pós-guerra. Isso não pode ser o objetivo do aluno. Nesse caso, poderia ser Identificar três aspectos que afetaram a economia mundial no período pós-guerra. *Nesta aula, você irá:
Nesta aula você irá: - Aprender a fazer
estimativas de prazo e esforço utilizando métodos COCOMO - Analisar as limitações de estimativas dependendo da fase do projeto que a estimativa é feita (erro estimado) - Aprender como utilização dos métodos de estimativa com ponto função. - Classificar o software em grau de dificuldade, segundo critérios do COCOMO, para produzir à estimativa. - Aprender a diferença do COCOMO II e o COCOMO.
Introdução da Aula 06
**Escrever um pequeno texto (no máximo 3 parágrafos) apresentando o tema que será estudado e motivando o aluno para a realização do estudo. Neste ícone, o conteudista dá uma visão geral dos tópicos a serem abordados na aula, introduzindo o assunto ao aluno. *A partir deste texto introdutório, você será capaz de entender melhor os conceitos estudados nesta aula, sendo capaz de relacionar o conteúdo que será aprendido ao contexto em que está inserido. Olá! Nesta aula vamos aprender como podemos produzir estimativas para um projeto ou parte do projeto. É muito importante saber produzir estimativas, com razoável precisão, para avaliar os custos e prazos que estão envolvidos no projeto. Além de uma estimativa é necessário avaliarmos as possíveis distorções sobre estes valores. Você saberá dialogar com o seu contrate com mais segurança, pois conhecerá um método super conhecido, para você estimar suas ações
Aula teletransmitida
** Neste ícone, o conteudista discrimina os tópicos a serem abordados na aula. É importante verificar se os tópicos aqui apresentados estão relacionados aos da aula online para que não
haja disparidade entre os conteúdos apresentados em cada modalidade. É importante destacar: - Principais tópicos a serem abordados. - Conceitos a serem tratados na aula. - Enfoques que serão dados aos tópicos estudados. - Indicação do assunto no Livro Universitário (Customizado): indicar as páginas, capítulos pertinentes para cada tópico.
* Assista à aula teletransmitida 00 que aborda os seguintes tópicos: - Tópico 1. - Tópico 2. - Tópico 3. - explicar as limitações de uma estimativa para o software - fatores que influenciam uma estimativa (prazo e esforço) - explicar por que se deve fazer estimativa de esforço e os modelos matemáticos empíricos ajustados. - a origem e a construção do modelo COCOMO - destacar os modelos do COCOMO e suas características - formulas do COCOMO e sua aplicação, interpretação - proposta do COCOMO II - diferenças do COCOMO II e COCOMO. - Principais aspectos do COCOMO II - Aplicações do COCOMO II
Livro
** Neste ícone, o conteudista indica a bibliografia a ser lida pelo aluno, ou seja, os capítulos do material didático que o aluno recebe a serem lidos nesta aula. Antes de indicar o livro, verificar se o mesmo está disponível na pasta do professor (https://pastadoprofessor.com.br/) ou no pool de editoras participantes.
*Não deixe de reler o material didático que você recebeu. Também aumente o seu conhecimento pesquisando sobre os tópicos abordados na aula. Desta forma, você vai estar se preparando melhor para realizar suas avaliações. No caso de dúvidas, entre em contato com seu professor online. Acesse a biblioteca virtual da sua disciplina e leia o material disponível.
-
Medidas de tamanho melhorias de software.
de
desenvolvimento
e
de
Título: Engenharia de Software Editora: Pearson Education Autor: Pressman,Roger S. EAN-13: 9788587918369 Ano: 2006 Edição: 6ª Capítulo23: ESTIMATIVAS DE PROJETO DE SOFTWARE - Título: 23.7 Modelos de estimativa Empíricos Pagina 519 a 543.
(24 páginas).
Aula online
*Estude o conteúdo da sua aula online prestando atenção aos objetivos apresentados. Percorra atentamente o conteúdo da aula e realize todas as atividades propostas. Realize os exercícios propostos e se autoavalie. Após concluir o estudo, verifique se entendeu todo o conteúdo e, se tiver alguma dúvida, procure esclarecê-la com seu professor online. Para isso, utilize os recursos do ambiente de aprendizagem.
Para esta aula sugiro que: Leia o texto condutor da aula.
Leia o capítulo 23 do livro Engenharia de Software do prof Pressman
Faça o desafio.
Participe do Fórum
Coloque, no mural, o resultado de sua pesquisa
Aprenda mais!
** Neste ícone, o conteudista irá indicar sites complementares, artigos a serem lidas, pesquisas, vídeos a serem assistidos ou qualquer outro material que possa ser usado para aumentar o conhecimento do aluno. Os temas dos fóruns, bem como as aulas em que eles entrarão também devem ser apontados neste espaço. *Para saber mais sobre os tópicos estudados nesta aula, pesquise na internet sites, vídeos e artigos relacionados ao conteúdo visto. Se ainda tiver alguma dúvida, fale com seu professor online utilizando os recursos disponíveis no ambiente de aprendizagem.
**Reforçar os principais pontos estudados e seus objetivos. Por exemplo: *Nesta aula, você: Nesta aula você aprendeu. - Compreendeu as limitações impostas pelos modelos construídos experimentais. - aprendeu sobre modelo COCOMO 81 de estimativas e suas utilizações.
a partir de dados
Aprendeu a usar o modelo COCOMO81 Aprendeu os conceitos de utilização do COCOMO II Aprendeu sobre os modelos que o coco mo II. Aprendeu a usar as fórmulas do COCOMO 2 E COCOMO 81.
Próxima aula
** Neste ícone, deverá entrar sempre os tópicos a serem estudados na aula seguinte. *Na próxima aula, você vai estudar sobre os assuntos seguintes: - Assunto 1. - Assunto 2. - Assunto 3. Na próxima aula vamos: - aprender sobre outros métodos de fazer estimativas, este novo método tem uma visão mais dinâmica do processo de desenvolvimento. - aprender a utilizar outros métodos de acordo com o processo. - aprender a utilizar ponto função para determinar prazos e esforço -
**Elaborar de 2 a 5 questões objetivas de múltipla escolha (5 opções de resposta) com gabarito.
INSERIR AQUI OS EXERCÍCIOS DE AUTOCORREÇÃO
Considere a tabela abaixo, que contém dados sobre dez projetos e que será utilizado para estima o esforço e o prazo para um novo projeto.
prazo prazo Projetos (mês)*homem (mês) projeto 1 11 8 projeto 2 19 10 projeto 3 20 12 projeto 4 8 6 projeto 5 10 10 projeto 6 21 16 projeto 7 13 9 projeto 8 13 9 projeto 9 18 14 projeto 10 14 12
media
14,7
10,6
Baseado na recomendação do PMI sobre estimativas de prazos podese afirmar: A) O esforço estimado deve ser de 14,63 mês*homem e o prazo 10,73 meses. B) O esforço estimado deve ser de 14,63 mês*homem e o prazo 8,00 meses C) O esforço estimado deve ser de 14,70 mês*homem e o prazo 10,73 meses D) O esforço estimado deve ser de 21,00 mês*homem e o prazo 16,00 meses E) O esforço estimado deve ser de 8,00 mês*homem e o prazo 6,00 meses Resposta: letra a
2 questão: Considere o Gráfico mostrado abaixo (Boehm) Desafio: Considere as formulas abaixo, do modelo básico:
Considere as afirmativas abaixo e assinale a afirmativa correta: a) Ao se estimar o prazo, este valor deve ser constante ao longo das fases do projeto. Vamos fazer um softwareum simples, paraexemplo, acesso a8 um banco de dados, valor com uma b) Ao se determinar valor, por meses o verdadeiro na equipe fase de programadores experientes> Os requisitos estão definidos, mas podem de requisitos é de 32 meses*homem e para o e meses para o ser alterados. O Produto servirá para apoiar o controle de vendas e terá módulos prazo de apoio ao controle de pedidos e controle de clientes. As informações estatísticas c) O gráfico mostra o nível de incerteza que temos para cada fase do indicam que este software terá aproximadamente 2,34 mil linhas de código desenvolvimento d) A Curva mostra que a entrega do software pode varias de um a 25 Que valores devem ser incorporados nas equações. meses e) As estimativas têm dois limites: inferior e superior. E, nós devemos Resposta: escolher o limite inferior O software é relativamente simples, a equipe com experiência. Os requisitos são definidos. Temos apenas uma pequena equipe. Podemos então classificar este software como orgânico. Verificando a tabela: Resposta c software Projeto de ab bb cb db Orgânico 2,4 1,05 2,5 0,38 3Semi – Um software do tipo por várias 0,35 equipes. destacado 3,0 ERP deverá 1,12 ser desenvolvido 2,5 Os requisitos estão formalizados. Neste caso para este software de %,8 Embutido 3,6 1,20 2,5 0,32 Kloc. Não temos sobre a plataforma de hardware, experiência Temos a primeira linhainformações como resultada: das pessoas ou método de desenvolvimento. As formulas ficam: Neste caso classificaríamos o desenvolvimento segundo Boehm como: E (esforço em homem*mês) 2,4 * (Kloc) EXP (1,05) a) Intermediário e semi=destacado E = b) 2,4Básico * 2,34eexp (1,05)= 2,4*2,4416 =5,86 homem*mês orgânico Resposta esforço de homem*meses c) Intermediário5,86 e orgânico d) Intermediário e restrito Desafio: e) básico restrito Determine o prazo para o problema (dica use a formula) letraacima. a
ConteĂşdo Online Texto
(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 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) 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:
N = E/D Onde:
(número de pessoas recomendadas)
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
cb 2,5 2,5 2,5
são fornecidos de
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. 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 Onde o coeficiente a e o expoente b são fornecidos pela tabela: Projeto de software
a
b
Orgânico Semi destacado Embutido
3,2 3,0 2,8
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:
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
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
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
O modelo supõem que não há esforços adicionais.
alta Muito alta alta Muito alta 25 50
tabela
de
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.
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