Medida de Esforço de Desenvolvimento de Software

Transcrição

1 Unidade IV Técnicas de Estimativa de Esforço e Prazo Luiz Leão luizleao@gmail.com

2 Conteúdo Programático Unidade IV Técnicas de estimativa de esforço e prazo COCOMO (Básico Intermediário detalhado) COCOMO II Estimativas de prazo Estimativas de custo Estimativas de defeitos pré-release Estimativas de esforço de retrabalho Método de Putnam Estimativa de custos e esforço para a manutenção de software Outros métodos Estudo de casos Acompanhar projetos (método EVA).

3 COCOMO

4 COCOMO - Introdução Construtive Cost Model Criado por Barry Boehm no seu livro Economia da Engenharia de Software (1981) É um modelo desenvolvido para estimar esforço, prazo, custo e tamanho da equipe para um projeto de software. Como foi desenvolvido em 1981, ficou conhecido como COCOMO 81

5 COCOMO - Introdução O método foi derivado e baseado nas análises feitas em um conjunto de 63 projetos, cobrindo áreas como: negócios, controle, científica, suporte e sistema operacional. Os programas examinaram de a linhas de código em linguagens de programação de Assembly a PL/I.

6 COCOMO Modos de Desenvolvimento Definidos por Boehm para caracterizar o desenvolvimento de software, podem ser: Orgânico Semi-Destacado Embutido

7 COCOMO Modos de Desenvolvimento ORGÂNICO: Equipes relativamente pequenas desenvolvem sistemas num ambiente altamente familiar. Nesse modo de desenvolvimento, a maior parte das pessoas engajadas no projeto tem experiência prévia com sistemas similares na organização e entendimento completo do sistema.

8 COCOMO Modos de Desenvolvimento ORGÂNICO (Cont.): Outras características do modo orgânico são: Ambiente estável de desenvolvimento com pouca necessidade de inovação Inexistência de requisitos de entrega rígidos; Uso de algoritmos simples Tamanho relativamente pequeno, com projetos na faixa de até linhas de código.

9 COCOMO Modos de Desenvolvimento ORGÂNICO (Cont.): Outras características do modo orgânico são: Ambiente estável de desenvolvimento com pouca necessidade de inovação Inexistência de requisitos de entrega rígidos; Uso de algoritmos simples Tamanho relativamente pequeno, com projetos na faixa de até linhas de código.

10 COCOMO Modos de Desenvolvimento SEMIDESTACADO: O modo semidestacado é aplicado em projetos de software com características situadas entre os modos orgânico e embutido. Suas características básicas são: A equipe mescla grande e pouca experiência com a aplicação e com a tecnologia O tamanho do software pode chegar a linhas de código.

11 COCOMO Modos de Desenvolvimento EMBUTIDO: O principal fator que distingue um projeto de software de modo embutido ou restrito é a necessidade de seguir restrições rigorosas. O produto a ser desenvolvido deverá operar dentro de um contexto complexo de hardware, software e regras e procedimentos operacionais. São projetos de software caracterizados por serem relativamente grandes, com muita necessidade de inovação, que demandam altos custos de verificação e validação.

12 COCOMO Modos de Desenvolvimento EMBUTIDO (Cont.): Exemplos de projetos do modo embutido são: Projeto de sistema de transferência eletrônica de fundos Projeto de sistema de controle de tráfego aéreo Projeto de Controle de Hidroelétrica Etc.

13 COCOMO MODELOS O COCOMO possui 3 diferentes modelos que refletem a complexidade de desenvolvimento do produto: Básico Intermediário Avançado ou Detalhado

14 COCOMO - BÁSICO Calcula o esforço do desenvolvimento de software em função do tamanho estimado do programa expresso em linhas de código estimadas.

15 COCOMO - BÁSICO FÓRMULAS: Esforço aplicado por pessoa no mês: Projeto de Software ab bb cb db E b = ab (KLOC) bb Orgânico Semi-Destacado Embutido Onde: ab, bb = Coeficientes de Desenvolvimento KLOC = Quantidade de milhares de linhas de código

16 COCOMO - BÁSICO FÓRMULAS: Tempo de Desenvolvimento: Projeto de Software ab bb cb db D = cb (E) db Orgânico Semi-Destacado Embutido Onde: cb, db = Coeficientes de Desenvolvimento E = Esforço aplicado pelo desenvolvedor

17 COCOMO - BÁSICO FÓRMULAS: Quantidade de Desenvolvedores Necessários: Projeto de Software ab bb cb db P = E / D Orgânico Semi-Destacado Embutido Onde: E = Esforço aplicado pelo desenvolvedor D = Tempo de Desenvolvimento

18 COCOMO - BÁSICO COCOMO básico é bom por ser rápido em estimativas e custos de software, mas sua exatidão é limitada. Ele não leva em conta as limitações de hardware, a qualidade do pessoal e experiência, o uso de ferramentas e técnicas modernas, e outros atributos do projeto conhecido por ter uma influência significativa sobre os custos de software, o que limita a sua precisão

19 COCOMO INTERMEDIÁRIO Calcula o esforço de desenvolvimento de software em função do tamanho do programa e de um conjunto de direcionadores de custo, alternativamente chamados atributos ou fatores de software, que incluem avaliações subjetivas do produto, do hardware, do pessoal e dos atributos do projeto.

20 COCOMO INTERMEDIÁRIO Direcionador de Custo: É uma característica de desenvolvimento de software que tem efeito aumentativo ou diminutivo na quantidade de esforço de desenvolvimento final do projeto, como por exemplo, a experiência da equipe de projeto, ou ainda, a confiabilidade requerida do software [COCOMOII, 2000].

21 COCOMO INTERMEDIÁRIO FATOR DE AJUSTAMENTO DE ESFORÇO (EAF): No Modelo Intermediário são utilizados itens de avaliação do modelo básico e criados mais alguns, tais como: Atributos de Produto, Atributos de Hardware, Atributos Pessoais, Atributos de Projeto.

22 COCOMO INTERMEDIÁRIO FATOR DE AJUSTAMENTO DE ESFORÇO (EAF): Para cada um dos atributos é dado um valor, de 0 a 6 onde 0 = muito baixo e 6 = muito alto, posteriormente é feita uma multiplicação dos resultados para a criação do EAF(Effort, Adjustment Factor), ou, Fator de Ajustamento de Esforço.

23 COCOMO INTERMEDIÁRIO

24 COCOMO - INTERMEDIÁRIO FÓRMULAS: Esforço aplicado pelo desenvolvedor: Projeto de Software ai bi E = ai (LOC) (bi).eaf Início (orgânico) Meio (semidestacado) Fim (embutido) Onde: ai, bi = Coeficientes de Desenvolvimento LOC = Quantidade de linhas de código EAF = Fator de Ajustamento de Esforço

25 COCOMO - AVANÇADO Também conhecido como Detalhado, ele incorpora todas as características da versão intermediária, incluindo a avaliação do impacto dos atributos do software e da equipe desenvolvedora em cada passo do processo de engenharia de software.

26 Modelos Paramétricos Relação matemática entre tamanho, esforço, prazo e qualidade Essa relação é afetada por fatores de performance, ou parâmetros Ex: COCOMO II, SLiM, KnowledgePan, etc.

27 COCOMO II

28 COCOMO II Devido à idade dos projetos que embasaram o modelo, assim como sua incapacidade de lidar com ciclos de vida iterativos e com a utilização de componentes Commercial-Off-The-Shelff COTS (Comerciais de Prateleira), o COCOMO 81 é atualmente considerado obsoleto, tendo sido substituído por sua versão II, publicada em Foi Obtido e Calibrado com base em 161 projetos cuidadosamente selecionados a partir de 2000 projetos candidatos Antes de ser usado, o modelo deve ser calibrado a partir dos dados históricos de projetos semelhantes àqueles que se deseja estimar

29 COCOMO II Calibrando o Esforço

30 COCOMO II Calibrando o Esforço

31 COCOMO II Estimando Produtividade

32 COCOMO II Possui 22 parâmetros (5 com efeito exponencial e 17 com efeito linear) que permitem ajustar as características de um projeto específico.

33 COCOMO II O COCOMO II é compatível com os métodos iterativos e incrementais tais como RUP (Rational Unified Process) A Rational e a Microsoft são empresas que ajudam a financiar o COCOMO II O modelo encontra-se em um livro e a USC promove encontros anuais sobre o método

34 COCOMO II Ele evoluiu para um modelo de estimativa de custo de software mais abrangente Assim como o seu predecessor, o COCOMO II é na realidade uma hierarquia de modelos de estimativa que trata as seguintes áreas: Modelo de Composição de aplicação Modelo de Estágio do Início do Projeto Modelo do Estágio Pós-Arquitetura

35 COCOMO II Modelo de Composição de Aplicação Usado durante os primeiros estágios da engenharia de software, em que: Protótipo das interfaces de usuário; Consideração da interação de software e sistema; Avaliação do desempenho; Avaliação da maturidade da tecnologia; São de suma importância

36 COCOMO II Modelo de Estágio do Início do Projeto Usado quando os requisitos tiverem sido estabilizados e a arquitetura básica de software tiver sido estabelecida.

37 COCOMO II Modelo de Estágio Pós-Arquitetura Usado durante a construção do software.

38 COCOMO II Assim como todos os modelos de estimativa para software, os modelos COMO II requerem informações de tamanho. Há disponíveis 3 diferentes opções como parte da hierarquia de modelo: Pontos de Objeto Pontos de Função Linhas de Código-Fonte

39 COCOMO II O modelo de composição de aplicação COCOMO II utiliza pontos de objeto e é ilustrado nos próximos parágrafos Devemos observar que há também disponíveis outros modelos de estimativa mais sofisticados (Usando PF e KLOC) como parte do COCOMO II

40 COCOMO II Pontos de Objeto Assim como os Pontos de Função, o Ponto de Objeto é uma medida indireta de software calculada por meio de contagens dos números de: Telas (na interface do usuário) Relatórios Componentes que podem ser necessários para construir a aplicação

41 Roteiro de Estimativa

42 Ferramenta USC-COCOMO II

43 COCOMO II Fórmula

44 Método de Putnam

45 Método de Putnam É um modelo dinâmico de múltiplas variáveis que pressupõe uma distribuição de esforço específica ao longo da existência de um projeto de desenvolvimento de software. O modelo foi construído a partir de uma distribuição de mão-de-obra encontrada em grandes projetos (esforço total de 30 pessoas-ano ou mais), porém a aplicação desse método para projetos de software menores é possível.

46 Modelo Putnam Fórmula A estimativa de Putnam relaciona linhas de código ao tempo e esforço de desenvolvimento, utilizando as seguintes equações:

47 Modelo Putnam Fórmulas

48 Modelo Putnam Fórmulas Os valores típicos para a constante do estado da tecnologia são: Para um ambiente pobre¹: Ck = Para um ambiente de desenvolvimento de bom nível²: Ck = Para um ambiente excelente³: Ck =

49 Modelo Putnam Fórmulas ¹Ambiente de Desenvolvimento Pobre é um ambiente sem base metodológica, sem documentação e com revisões precárias ²Ambiente de Desenvolvimento Bom é um ambiente que aplica metodologias, com documentação ³Ambiente de Desenvolvimento Excelente é um ambiente com ferramentas e técnicas automatizadas

50 Modelo Putnam Fórmulas O valor da constante de tecnologia (Ck) também pode ser derivado das condições locais utilizando dados históricos coletados no esforço do desenvolvimento

51 Modelo Putnam O valor da constante de tecnologia (Ck) também pode ser derivado das condições locais utilizando dados históricos coletados no esforço do desenvolvimento

52 Modelo Putnam A estimativa de Putnam permite a troca de tempo pelo esforço. Ao acrescentar pessoas num projeto, diminui-se o tempo do desenvolvimento. Em contra partida aumenta-se o custo do projeto. Ao ultrapassar o ponto máximo para esta troca, o projeto torna-se incontrolável Por outro lado, os administradores podem simular outras situações, verificando o tempo, o esforço e o custo do projeto. Quanto menor o tempo, maior o esforço e o custo do desenvolvimento de um projeto

53 Modelo Putnam Esta estimativa permite o cálculo da produtividade média constante através da fórmula:

54 Modelo Putnam Isso significa que a produtividade média constante (PR) está relacionada ao tempo (T) e ao esforço do desenvolvimento do sistema (K). Por isso, conclui-se que é difícil medir a produtividade de um projeto com base em outro, por que ambos devem ter o mesmo grau de dificuldade (mesmo número de arquivos, mesmo número de consultas, relatórios,...) e o mesmo tempo

55 Modelo Putnam A equação utilizada pela estimativa de Putnam (também conhecida como equação do software) apresenta como resultado uma função, fazendo com que o usuário defina valores para determinar a curva (Rayleigh- Norden - Tempo x Esorço) e decidir qual será o esforço e o tempo necessário para o desenvolvimento do software.

56 Modelo Putnam Curva Rayleigh-Norden

57 Modelo Putnam Curva Rayleigh-Norden Barry Boehm fez um interessante estudo em tentativas para diminuir o cronograma de projetos; Ele examinou mais de 700 projetos que tentaram entregar código em menos tempo do que o ponto de entrega nominal Tn. Nenhum dos projetos foram bem sucedidos na redução do cronograma abaixo de 75% do valor nominal ponto de entrega Tn, e ele batizou a área de "Região Impossível" para indicar que você não pode comprimir tempo para além deste ponto. (Veja Barry Boehm Software Engineering Economics, Prentice Hall, 1981),

58 Método EVA

59 Método EVA Earned Value Analysis Análise de Valor Agregado É uma técnica de medição de desempenho para medir a performance do projeto. Isto de maneira conjunta, pois análises isoladas de prazo, custo, qualidade, esforço tendem a mascarar a performance do projeto. Foi utilizado pela primeira vez na década de 60 pela Força Aérea dos EUA no projeto do míssil Minuteman ; Em 1998 foi reconhecido pelo ANSI sendo divulgado fortemente entre segmentos industriais;

60 Método EVA A análise de valor agregado é uma ferramenta que vem sendo bastante utilizada no gerenciamento de projetos. Nesse contexto, consiste em analisar o desempenho do projeto considerando três dimensões: Tempo Custo Trabalho (Escopo).

61 Conceitos Complementares Linha de Base (Baseline): É o planejamento aprovado para os itens de projeto. Os itens do projeto podem ser Escopo, Custo e Tempo ou ainda parâmetros Técnicos e de Qualidade. De uma forma geral as linhas de base são criadas após a aprovação de um planejamento ou de um replanejamento. Linha de Andamento: Linha de Andamento ou Data de Andamento é gerada por meio da coleta de informação de execução realizada do projeto em um determinado momento para os itens estabelecidos.

62 Conceitos Complementares A Linha de Base e a Linha de Andamento servem para auxiliar o controle do projeto por meio da comparação dos parâmetros de planejamento contra os de execução e com isso verificar se ocorreram desvios entre o previsto e o realizado. Ocorrendo desvios é necessários efetuar uma análise para descobrir a causa desse desvio e assim tomar uma ação corretiva adequada para corrigir o problema

63 Método EVA De forma resumida, significa analisar três curvas de desempenho: (i) Uma curva representa o valor planejado para o projeto (dado pelo custo previsto para o projeto em sua baseline). (ii) Outra curva representa o valor planejado para o projeto para o trabalho a ser realizado até um dado momento (dado pelo custo previsto para o projeto até aquele momento). (iii) A terceira curva representa o valor real do trabalho realizado para o projeto naquele dado momento (dado pelo custo real do projeto naquele momento).

64 Método EVA Gráfico

65 Variáveis para cálculo do Valor Agregado Planned Value ou Custo Orçado do Trabalho Agendado (PV COTA): É o custo planejado para o trabalho que deve ser realizado até um dado momento do projeto em sua baseline. Earned Value ou Custo Orçado do Trabalho Realizado (EV COTR): É o custo planejado para o trabalho realizado até o momento. Corresponde ao Valor Agregado Actual Cost ou Custo Real do Trabalho Realizado (AC CRTR): É o custo real para o trabalho realizado até o momento.

66 Principais Indicadores da Análise de Valor Agregado Variação de Custo (VC) ou Cost Variance (CV) É uma medida do desempenho, em termos de custo, em um projeto. É a diferença algébrica entre o valor agregado (earned value) e o custo real (actual cost). Um valor positivo indica um bom desempenho. CV = EV - AC

67 Principais Indicadores da Análise de Valor Agregado Variação de Cronograma ou SV (Schedule Variance) É uma medida do desempenho ao atender o cronograma de um projeto. É a diferença algébrica entre o valor agregado (earned value) e o valor planejado (planned value). Um valor positivo demonstra que a entrega do valor é antecipado. Vale observar que isto não significa necessariamente que haja antecipação do marco final do projeto, pois para que se possa afirmar uma antecipação efetiva, todas as variações observadas devem ser no caminho crítico do projeto. SV = EV - PV

68 Principais Indicadores da Análise de Valor Agregado Índice de Desempenho de Prazos (IDP) ou Schedule Performance Index (SPI ) É uma medida da eficiência ao atender o cronograma de um projeto. É a razão entre o valor agregado (earned value) e o valor planejado (planned value). Índice de Performance de Cronograma maior ou igual a 1 indica ritmo eficiente de avanço no cronograma SPI = EV/PV

69 Principais Indicadores da Análise de Valor Agregado Índice de Desempenho de Custo (IDC) ou Cost Performance Index (CPI ) É uma medida da eficiência, em termos de custo, em um projeto. É a razão entre o valor agregado (earned value) e o custo real (actual cost). Índice de Desempenho de Custo maior ou igual a 1 indica que os recursos do projeto estão sendo utilizados de forma eficiente. CPI = EV/AC

70 Exemplo Custo total orçado: R$ ,00 (custo da baseline) Duração total: 69 dias COTA (PV Custo Planejado) x COTR (EV Custo planejado para o Trabalho Realizado) x CRTR (AC Custo Real do Trabalho Realizado) O projeto está atrasado (linha azul) e acima do custo previsto (linha vermelha

71 Previsões de Custos e Prazos usando EVA Método Otimista: Todo o trabalho futuro do projeto será realizado de acordo com o ritmo previsto inicialmente Custo Previsto (Otimista) = (AC EV ) + custo da baseline Duração Prevista (Otimista) = Atraso Atual + duração da baseline Atraso Atual = (1 SPI) x tempo decorrido Exemplo: Para o projeto hipotético representado no Gráfico 1, após decorridos 32 dias do projeto, EV é R$ , PV é R$ e AC é R$ As previsões otimistas para esse projeto são: Custo Previsto (Otimista) = (AC - EV )+ custo da baseline = = R$ Duração Prevista (Otimista) = Atraso Atual + duração da baseline = ((1 SPI) x Tempo decorrido) + 69 = ((1-0,68) x 32) + 69 = 10, = 79,24 dias

72 Previsões de Custos e Prazos usando EVA Método Realista (ou do Valor Mais Provável): O ritmo do projeto continuará com a mesma taxa de desvio que apresenta atualmente Custo Previsto (Realista) = custo da baseline/cpi Duração Prevista (Realista) = duração da baseline/spi Exemplo: Para o projeto citado anteriormente, as previsões realistas são: Custo Previsto (Realista) = custo da baseline/cpi = / 0,42 = R$ Duração Prevista (Realista) = duração da baseline/spi = 69 / 0,68 = 101 dias

73 Previsões de Custos e Prazos usando EVA Método Pessimista: O projeto vai custar ainda mais, pois mais recursos serão empregados para entregar no prazo Custo Previsto (Pessimista) = custo da baseline/(cpi x SPI) Exemplo: Para o projeto citado anteriormente, a previsão de custo pessimista é: Custo Previsto (Pessimista) = custo da baseline/(cpi x SPI) = / (0,42 x 0,68) = R$ ,00

74 Comparando Estimativas de Custo Otimista Realista Pessimista Custos Duração 79,

75 Exercício Os valores a seguir representam o desempenho de um projeto hipotético em seu 30º dia, utilizando-se a análise de valor agregado. O custo total previsto para o projeto é de R$ e a duração total prevista é de 130 dias. Variáveis Nomenclatura Valor Custo Planejado para o Trabalho do Projeto Planned Value (PV) Custo Planejado para o Trabalho Realizado Earned Value (EV) Custo Real do Trabalho Realizado Actual Cost (AC) Indicadores Nomenclatura Valor Índice de Desempenho do Tempo Schedule Perfomance Index (SPI=EV/PV) 0,83 Índice de Desempenho do Custo Cost Performance Index (CPI=EV/AC) 0,93 a)o que o gerente do projeto pode concluir a partir dos valores apresentados na tabela? b)com esses valores, faça as previsões otimista e realista para os custos e a duração do projeto.

76 Leitura Complementar Por que é importante fazer análise de Valor Agregado?