Implantação de processo de estimativa de esforço de desenvolvimento de software caso real

Texto

(1)Pós-Graduação em Ciência da Computação. “Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real” Por. Antônio do Rêgo Valença Dissertação de Mestrado. Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao. RECIFE, AGOSTO/2007.

(2) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. ANTÔNIO DO RÊGO VALENÇA. “Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real”. ESTE TRABALHO FOI APRESENTADO À PÓSGRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.. Orientador: Sílvio Romero de Lemos Meira. Recife, Agosto/2007.

(3) Valença, Antônio do Rêgo Implantação de processo de estimativa de esforço de desenvolvimento de software – caso real / Antônio do Rêgo Valença. – Recife: O Autor, 2007. xiii, 167 folhas : il., fig., tab. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2007. Inclui bibliografia, glossário e apêndices. 1. Software – Desenvolvimento. 2. Software – Medição. I. Título.. 005.14. CDD (22.ed.). MEI2008-031.

(4) Dedico este trabalho à minha família que sempre me apoiou e acompanhou nesta jornada, e a meus pais que com seu exemplo e valores me permitiram chegar aqui.. iv.

(5) Agradecimentos Agradeço acima de tudo à vida que me deu oportunidade de realizar este trabalho e a todos os meus familiares que me apoiaram e compreenderam as noites insones, as ausências e as idas e vindas que a jornada de um Mestrado exige. Agradeço ao Prof. Sílvio Meira pelo acompanhamento e incentivo, sem o qual eu dificilmente teria chegado até o final. Um agradecimento especial também a todos os amigos do C.E.S.A.R e PITANG que participaram da implantação do processo e que deram contribuições relevantes para que obtivéssemos um processo consistente e adequado.. v.

(6) Resumo Para estimar recursos necessários em um projeto de desenvolvimento de software, foram propostas e utilizadas pela indústria várias técnicas ao longo dos últimos 40 anos. Algumas se consolidaram nos últimos anos, como COCOMO e Pontos de Função, e outras ainda estão em processo de consolidação, tal como Pontos de Caso de Uso. Todas estas técnicas tentam responder com um nível alto de acurácia a principal dúvida que persegue todo desenvolvedor de software quando necessita estimar o custo e duração de um projeto: que tamanho terá o software que eu estou prestes a construir? Para responder a esta dúvida, neste trabalho são estudadas as principais técnicas para estimativa de tamanho de software, considerando a adoção das mesmas pela indústria e literatura. É definido um processo de seleção de uma técnica para a empresa estudo de caso do trabalho (PITANG1), explicitando os motivos da seleção e detalhando a implementação da técnica selecionada, considerando o processo, ferramentas, guias, templates e métricas criadas e utilizadas em tal implementação. A aplicação do processo definido – fluxos de suporte à pré-venda e de acompanhamento de projetos – em 36 projetos da organização estudada, permite o refinamento do processo proposto, gerando como resultado final um processo de estimativa ágil, baseado em requisitos, negociável com o usuário e facilmente replicável. Consideramos por fim, que a adoção do processo detalhado neste trabalho contribuirá para que empresas possam disciplinar e melhorar a qualidade de seus processos de desenvolvimento de software, usando um processo de estimativas estruturado, de fácil institucionalização e adequado às demandas do mercado.. Palavras chave: pontos de função, estimativa de esforço de desenvolvimento de software, processo de gestão de estimativas, método de seleção de técnica de estimativas. 1. http://www.pitang.com.br, uma empresa focada em oferecer serviços de desenvolvimento de projetos, consultoria, outsourcing e fábrica de software, e fundada em dezembro de 2004, no Recife como um spin-off dos projetos de fábrica de software do C.E.S.A.R (http://www.cesar.org.br). vi.

(7) Abstract To estimate the necessary resources in a software development project were proposed and used by the industry a large variety of techniques along the last 40 years. Some have consolidated during last years, as COCOMO and Function Points, and others are still consolidating, as Use Case Points. All these techniques try to answer with a high accuracy level the main question in the head of every software developer when need to estimate the cost and duration of a project: what size will have the software I am about to build? To answer this question, in this work are studied the main techniques for software size estimation, considering their adoption by the industry and literature. It is defined a selection process to choose a technique for the case study company (PITANG2), showing the motives for selection of the technique and detailing its implementation, considering the processes, tools, guides, templates and metrics created and used for this implementation. The defined process application – in 36 projects of the studied organization, allows the refining of the proposed process, generating as final result an agile estimation process, based in requirements, negotiable wit the user and easily replicable. At last, we consider that the adoption of the process detailed on this work will contribute for the companies to discipline and improve the quality of their development process, using a structured estimation process, that allows its institutionalization in a quick way and adequate to market demands. Keywords: function points, software estimative effort in software development, estimative management process, estimative technique selection method. 2. http://www.pitang.com, a company focused to offer services of project development, consulting, outsourcing and software factory, and founded in December, 2004, at Recife, as a spin-off of C.E.S.A.R software factory projects (http://www.cesar.org.br). vii.

(8) Índice 1.. 2.. Introdução .........................................................................................................................................................1 1.1.. Motivação do Trabalho.............................................................................................................................4. 1.2.. Objetivo do Trabalho ................................................................................................................................6. 1.3.. Organização deste Trabalho....................................................................................................................7. Técnicas para Estimativa de Esforço de Software ...........................................................................................8 2.1 Conceituando Estimativa.................................................................................................................................8 2.2 Histórico de Técnicas de Estimativa .............................................................................................................13 2.3 Classificação de Técnicas de Estimativa ......................................................................................................14 2.3.1 Técnica de Julgamento de Especialistas ..............................................................................................14 2.3.2 Estimando por Analogia.........................................................................................................................15 2.3.3 Técnicas Paramétricas ou Algorítmicas ................................................................................................15 2.3.4 Precificando para Vencer ......................................................................................................................16 2.4 Estudo Detalhado das Principais Técnicas de Estimativa ............................................................................16 2.4.1 Wideband Delphi....................................................................................................................................16 2.4.2 Pontos de Função..................................................................................................................................18 2.4.2.1. Processo Utilizado para Estimar Pontos de Função.................................................................21. 2.4.2.2. Tipos de Contagem ...................................................................................................................21. 2.4.2.3. Identificando o Escopo da Contagem e a Fronteira da Aplicação............................................22. 2.4.2.4. Estimando Funções de Dados ..................................................................................................23. 2.4.2.5. Estimando Funções de Transação ...........................................................................................25. 2.4.2.6. Calculando o Contador de Pontos de Função Não Ajustados (UFC).......................................29. 2.4.2.7. Calculando o Fator de Ajuste (VAF) .........................................................................................30. 2.4.2.8. Calculando Pontos de Função Ajustados .................................................................................31. 2.4.2.8.1. Calculando Pontos de Função em Projetos de Desenvolvimento............................................31. 2.4.2.8.2. Calculando Pontos de Função em Projetos de Melhoria (Manutenção) ..................................32. 2.4.2.8.3. Calculando Pontos de Função Para Aplicações Prontas .........................................................33. 2.4.2.8.3.1. Cálculo de Pontos de Função de Aplicação Implementada .................................................33. 2.4.2.8.3.2. Cálculo de Pontos de Função de Aplicação Depois de Uma Melhoria ................................34. 2.4.2.9. Considerações Sobre Pontos de Função .................................................................................34. 2.4.2.10. Técnica Holandesa – NESMA...................................................................................................35. 2.4.2.11. Derivando Indicadores a Partir da Contagem de Pontos de Função .......................................38. 2.4.3 COCOMO (COnstructive COst MOdel) .................................................................................................38 2.4.3.1. COCOMO Original ....................................................................................................................39. 2.4.3.1.1. Básico........................................................................................................................................39. 2.4.3.1.2. Intermediário .............................................................................................................................39. 2.4.3.1.3. Avançado ..................................................................................................................................41. 2.4.3.2. COCOMO II...............................................................................................................................42. 2.4.3.2.1. O Modelo Application Composition ...........................................................................................43. viii.

(9) 2.4.3.2.2. O Modelo Early Design .............................................................................................................45. 2.4.3.2.3. Modelo Post-Architecture..........................................................................................................50. 2.4.4 Técnica ISBSG ......................................................................................................................................53 2.4.4.1. Estimando Usando Equações...................................................................................................53. 2.4.4.1.1. Tipo de Projeto: Geral ...............................................................................................................54. 2.4.4.1.2. Tipo de Projeto: Mainframe.......................................................................................................54. 2.4.4.1.3. Tipo de Projeto: Midrange.........................................................................................................54. 2.4.4.1.4. Tipo de Projeto: Desktop...........................................................................................................54. 2.4.4.1.5. Tipo de Projeto: Linguagem de Terceira Geração....................................................................54. 2.4.4.1.6. Tipo de Projeto: Linguagem de Quarta Geração ......................................................................55. 2.4.4.1.7. Tipo de Projeto: Melhoria ..........................................................................................................55. 2.4.4.1.8. Tipo de Projeto: Novo Desenvolvimento...................................................................................55. 2.4.4.2. Estimando Usando Comparação ..............................................................................................56. 2.4.4.3. Estimando Usando Analogia.....................................................................................................57. 2.4.5 Processos Ágéis ....................................................................................................................................58 2.4.5.1. Pontos de Estória ......................................................................................................................60. 2.4.6 Pontos de Casos de Uso .......................................................................................................................62 2.4.6.1. Detalhamento de Casos de Uso ...............................................................................................64. 2.4.6.2. Pontos de Caso de Uso Não Ajustados (UUCP) ......................................................................66. 2.4.6.3. Fatores de Complexidade Técnica (TCF) .................................................................................68. 2.4.6.4. Fator Ambiental (EF) .................................................................................................................69. 2.4.6.5. Pontos de Caso de Uso Ajustados (UCP) ................................................................................70. 2.4.6.6. Experiências de uso relatadas pela indústria ...........................................................................70. 2.5 Conclusão .....................................................................................................................................................72 3.. Seleção da Técnica de Estimativas (Caso Real)............................................................................................73 3.1 Definição de Método de Seleção ..................................................................................................................73 3.1.1 Definição de Critérios de Seleção .........................................................................................................73 3.1.2 Selecionar Técnicas Candidatas ...........................................................................................................74 3.1.3 Escolher a Técnica Mais Apropriada .....................................................................................................74 3.1.4 Reavaliar a Escolha ...............................................................................................................................74 3.2 Aplicação de Método de Seleção na Empresa Estudo de Caso ..................................................................75 3.2.1 Definição dos Critérios de Seleção da Empresa Estudo de Caso ........................................................75 3.2.2 Detalhamento dos Critérios de Seleção da Empresa Estudo de Caso.................................................76 3.2.2.1. Atendimento do Mercado (Critérios 1 a 4) ................................................................................76. 3.2.2.2. Acompanhamento de Projetos em Execução (Critério 5).........................................................78. 3.2.2.3. Calibragem com Dados da Organização (Critério 6) ................................................................80. 3.2.2.4. Adequado para Projetos de Diferentes Tamanhos (Critério 7).................................................82. 3.2.2.5. Compatível com Estilo do Processo de Desenvolvimento (Critério 8) .....................................84. 3.2.2.6. Calibrada de Acordo com a Confiabilidade Desejada para o Software (Critério 9)..................85. 3.2.2.7. Calibrada de Acordo com a Complexidade dos Algoritmos (Critério 10) .................................85. ix.

(10) 3.2.2.8. Calibrada de Acordo com a Capacidade e Experiência da Equipe (Critério 11)......................86. 3.2.2.9. Adequada a Diferentes Ambientes Tecnológicos (Critério 12).................................................86. 3.2.3 Detalhamento das Notas Atribuídas na Abordagem Fatores-Pesados pela Empresa Estudo de Caso ........................................................................................................................................................................87 3.2.3.1. IFPUG .......................................................................................................................................87. 3.2.3.2. UCP...........................................................................................................................................88. 3.2.3.3. NESMA Estimada......................................................................................................................89. 3.2.3.4. COCOMO II Early Design .........................................................................................................90. 3.2.3.5. Comparação - ISBSG................................................................................................................90. 3.2.3.6. COCOMO II Post-Architecture ..................................................................................................91. 3.2.3.7. Analogia - ISBSG ......................................................................................................................91. 3.2.3.8. NESMA Indicativa .....................................................................................................................92. 3.2.3.9. NESMA Detalhada ....................................................................................................................92. 3.2.3.10. Pontos de Estória ......................................................................................................................93. 3.2.3.11. Wideband Delphi .......................................................................................................................93. 3.2.3.12. COCOMO II Application Composition - Pontos de Aplicação...................................................94. 3.2.4 Técnica de Estimativa Selecionada na Instituição Estudo de Caso......................................................95 3.3 Conclusão .....................................................................................................................................................97 4.. Aplicação de Técnica de Estimativas na PITANG..........................................................................................98 4.1 Identificando Métricas com Base em Projetos Reais....................................................................................98 4.2 Derivando Esforço e Custos..........................................................................................................................99 4.3 Definição de Processo de Pré-Venda .........................................................................................................103 4.3.1 Processo de Pré-Vendas – Passo a Passo.........................................................................................105 4.3.1.1. Detalhar Requisitos (Funcionais e Não-funcionais) ....................................................................105. 4.3.1.2. Realizar Estimativa ......................................................................................................................107. 4.3.1.3. Construir Cronograma .................................................................................................................108. 4.3.1.4. Preencher Check-list de Estimativas...........................................................................................112. 4.3.1.5. Preencher Planilha de Riscos .....................................................................................................113. 4.3.1.6. Lançar Custos no SGC................................................................................................................115. 4.3.1.7. Escrever Proposta Técnica .........................................................................................................117. 4.3.1.8. Tramitar proposta no SGC ..........................................................................................................118. 4.4 Definição de Processo de Acompanhamento de Projetos..........................................................................119 4.5 Conclusão ...................................................................................................................................................120 5.. Conclusão .....................................................................................................................................................121 5.1 Principais Contribuições..............................................................................................................................123 5.2 Trabalhos Relacionados..............................................................................................................................124 5.3 Trabalhos Futuros .......................................................................................................................................126 5.4 Considerações Finais..................................................................................................................................127. Apêndice A – Guia para Definição das GSCs.......................................................................................................131 Apêndice B – Detalhamento de Direcionadores de Custo COCOMO II ...............................................................142. x.

(11) Apêndice C – UCP - Cálculo do Valor dos Fatores Técnicos ...............................................................................148 Apêndice D – UCP - Cálculo do Valor dos Fatores Ambientais............................................................................151 Apêndice E – Exemplo de Caso de Uso ...............................................................................................................155 Apêndice F – Cálculo de Horas por Mês...............................................................................................................157 Apêndice G – Check-list de Estimativas PITANG .................................................................................................158 Apêndice H – Glossário de Termos.......................................................................................................................165. xi.

(12) Lista de Tabelas Tabela 1.1– Refinamento de Estimativa de Esforço ao Longo de um Projeto [SEL-90] ..........................................3 Tabela 2.1 – Técnicas de Estimativa.......................................................................................................................13 Tabela 2.2 – Matriz complexidade para ILFs e EIFs [Garmus-01]..........................................................................24 Tabela 2.3 – Matriz complexidade para EIs [Garmus-01] .......................................................................................27 Tabela 2.4 – Matriz complexidade para EOs [Garmus-01] .....................................................................................28 Tabela 2.5 – Matriz complexidade para EQs [Garmus-01] .....................................................................................29 Tabela 2.6 – Pesos Atribuídos por Complexidade [Garmus-01].............................................................................29 Tabela 2.7 – Características Gerais do Sistema [Garmus-01]................................................................................30 Tabela 2.8 – NESMA - Técnicas de Contagem de Pontos de Função [NESMA-07]..............................................36 Tabela 2.9 – Esforço para os três modos do COCOMO Básico [Boehm-00] .........................................................39 Tabela 2.10 – Parâmetros de esforço para os três modos de COCOMO Intermediário [Boehm-00].....................40 Tabela 2.11 – Multiplicadores de Esforço para desenvolvimento de software [Boehm-00] ...................................40 Tabela 2.12 – Multiplicador de esforço para Capacidade do Analista em COCOMO Avançado [Boehm-00] .......41 Tabela 2.13 – Níveis de complexidade de pontos de aplicação para telas [Boehm-00] ........................................43 Tabela 2.14 – Níveis de complexidade de pontos de aplicação para relatórios [Boehm-00] .................................44 Tabela 2.15 – Pesos por complexidade para pontos de aplicação [Boehm-00] .....................................................44 Tabela 2.16 – Taxas de produtividade média baseadas na experiência dos desenvolvedores e a maturidade/capacidade ICASE [Boehm-00] ....................................................................................................45 Tabela 2.17 – Quantidade de linhas de código fonte por ponto de função por linguagem [Stutzke-05] [Boehm-00] ..........................................................................................................................................................................45 Tabela 2.18 – Fatores de Escala COCOMO II [Boehm-00] ....................................................................................46 Tabela 2.19 – Direcionadores de Custo Early Design [Boehm-00].........................................................................49 Tabela 2.20 – Direcionadores de Custo Early Design [Boehm-00].........................................................................49 Tabela 2.21 – Direcionadores de custo Post-Architecture [Boehm-00] ..................................................................51 Tabela 2.22 – Escalas de Pontos de Estória Mais Comuns [McConnell-06] ..........................................................60 Tabela 2.23 – Exemplo de Lista de Estórias e Pontos de Estória Atribuídos [McConnell-06]................................60 Tabela 2.24 – Exemplo de Lista de Estórias e Pontos de Estória Atribuídos [McConnell-06]................................61 Tabela 2.25 – Projeção Inicial para o Restante do Projeto [McConnell-06]............................................................61 Tabela 2.26 – Atores com pesos [Karner-93]..........................................................................................................66 Tabela 2.27 – Casos de Uso com Pesos [Karner-93] .............................................................................................66 Tabela 2.28 – Fatores que contribuem para a complexidade [Karner-93]..............................................................68 Tabela 2.29 – Fatores Ambientais [Karner-93] .......................................................................................................69 Tabela 3.1 – Critérios de Seleção (Abordagem Fatores-Pesados) ........................................................................76 Tabela 3.2 – Percentual de Empresas que Utilizam Métricas em Relação ao Total de Empresas [MCT-06]........78 Tabela 3.3 – Análise Qualitativa das Técnicas de Estimativa Estudadas...............................................................95 Tabela 3.4 – Número de CFPS por País (em janeiro de 2007) [BFPUG-07]..........................................................97 Tabela 4.1 – Base Histórica de Projetos PITANG...................................................................................................98 Tabela B.1 – Níveis de Classificação PERS [Boehm-00] .....................................................................................142. xii.

(13) Tabela B.2 – Níveis de Classificação RCPX [Boehm-00] .....................................................................................143 Tabela B.3 – Níveis de Classificação RUSE [Boehm-00] .....................................................................................144 Tabela B.4 – Níveis de Classificação PDIF [Boehm-00] .......................................................................................144 Tabela B.5 – Níveis de Classificação PREX [Boehm-00] .....................................................................................145 Tabela B.6 – Níveis de Classificação FCIL [Boehm-00] .......................................................................................145 Tabela B.7 – Níveis de Classificação SCED [Boehm-00] .....................................................................................146 Tabela B.8 – Sumário de Níveis de Direcionadores de Custo Post-Architecture [Boehm-00] .............................146 Tabela B.9 – Sumário de Níveis de Direcionadores de Custo Post-Architecture [Boehm-00] .............................147 Tabela C.1 – Fatores Técnicos Comuns – UCP e FPA ........................................................................................148 Tabela G.1 – Check-list de Estimativas de Pré-Vendas PITANG [SGQP-07] ......................................................159 Tabela G.2 – Check-list de Estimativas PITANG - Orientações de Preenchimento [SGQP-07] ..........................164. xiii.

(14) Lista de Figuras Figura 1.1 – Cone da Incerteza [McConnell-98]........................................................................................................2 Figura 2.1 – Processo de Estimativas .....................................................................................................................10 Figura 2.2 – Processo de Estimativa [Kival-99].......................................................................................................10 Figura 2.3 – Derivando Esforço, Cronograma e Custo ...........................................................................................11 Figura 2.4 – Sensibilidade do processo de estimativa à qualidade dos dados de entrada ....................................11 Figura 2.5 – Desenvolvimento de Técnicas para FSM [Braungarten-05] ...............................................................20 Figura 2.6 – Processo Utilizado Para Estimar Pontos de Função [Shazan-03]......................................................21 Figura 2.7 – Conceituação das funções de um sistema [Stutzke-05] .....................................................................23 Figura 2.8 – NESMA – Contagem Estimada x Contagem Detalhada [NESMA-07]................................................37 Figura 2.9 – NESMA – Contagem Indicativa x Contagem Detalhada [NESMA-07] ...............................................37 Figura 2.10 – COCOMO II – Aplicação de Modelos no Cone da Incerteza [Boehm-00] ........................................42 Figura 2.11 – Aplicação Valores SLOC de Acordo com Características de Projeto [ISBSG-07] ...........................46 Figura 2.12 – Fatores COCOMO II Organizados por Influência no Esforço [McConnell-06]..................................52 Figura 2.13 – Velocidade por Iteração – Time de Projeto Hipotético......................................................................59 Figura 2.14 – Exemplo de Diagrama de Casos de Uso [Rankin-05] ......................................................................62 Figura 3.1 – Acurácia de Estimativas X Níveis CMM [McConnell-06] ....................................................................80 Figura 3.2 – Tamanho x Complexidade em Projetos [MPMM-07] ..........................................................................82 Figura 4.1 – Estimativa de Esforço em Pontos de Função [SGQP-07] ................................................................100 Figura 4.2 – Distribuição de Esforço [SGQP-07]...................................................................................................100 Figura 4.3 – Distribuição Sugerida de Esforço Mês a Mês – SGC – PITANG [SGQP-07] ...................................102 Figura 4.4 – Visão Macro do Processo de Estimativas PITANG [SGQP-07]........................................................103 Figura 4.5 – Exemplo de Detalhamento de Requisito Funcional [SGQP-07] .......................................................105 Figura 4.6 – Efeitos de Comprimir ou Expandir um Cronograma Nominal [McConnell-06]..................................109 Figura 4.7 – Vias de Comunicação de Acordo com Tamanho de Time de Projeto ..............................................110 Figura 4.8 – Template de Cronograma para Projetos de Desenvolvimento [SGQP-07] ......................................111 Figura 4.9 – PITANG – Guia de Identificação de Riscos (Adaptado de J. Hallows [Hallows-01]) [SGQP-07] .....113 Figura 4.10 – PITANG – Cálculo do Fundo de Contingência de Riscos [SGQP-07]............................................114 Figura 4.11 – Fluxo de Tramitação – SGC – PITANG [SGQP-07] .......................................................................115 Figura 4.12 – Definindo Duração de Projeto no SGC [SGQP-07] ........................................................................116 Figura 4.13 – Lançamento de Esforço de Pessoal no SGC [SGQP-07]...............................................................117 Figura 5.1 – Evolução do Índice de Acerto de Esforço para Java-Struts [SGQP-07]...........................................122. xiv.

(15) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. Capítulo 1 1. Introdução “É a característica de uma mente instruída repousar satisfeita com o nível de precisão ao qual a natureza do assunto admite, e não procurar exatidão quando apenas uma aproximação da verdade é possível” – Aristóteles, 350 A.C.. Ao longo do tempo a Engenharia de Software vem tentando criar e utilizar técnicas que reflitam a produtividade das organizações, as tecnologias utilizadas e os requisitos funcionais. O problema comum a estas técnicas é que normalmente elas necessitam de um detalhamento profundo dos requisitos, além de envolverem um número muito grande de variáveis, que tornam o seu uso complexo. Por conta disto, ainda é comum o uso exclusivo de opiniões de especialistas, o que torna o processo de estimativas subjetivo e não acurado em projetos que envolvam novas tecnologias ou novos processos de negócios, além de nem sempre se ter especialistas disponíveis quando é necessário realizar as estimativas. O processo de captura e entendimento dos requisitos de um software a ser desenvolvido, bem como a transformação deste entendimento em uma estimativa de esforço de desenvolvimento confiável e acurada é um dos maiores desafios que envolvem a Engenharia de Software. A estimativa de esforço é necessária para que o custo do projeto seja estimado e a negociação com o cliente possa ser realizada. Como normalmente isto é feito com base em requisitos que foram levantados em tempo escasso, é comum o erro destas estimativas, implicando. em. prejuízos. para desenvolvedores,. atrasos, difíceis renegociações e. cancelamento de projetos. Em linhas gerais, a Engenharia de Software, além de ser uma nova ciência, é vasta em processos e técnicas capazes de prover instrumentos de medidas ao processo de desenvolvimento de software. No entanto a tentativa de estimar o esforço, tempo e custo do software a ser desenvolvido não é uma atividade trivial ou ciência exata. Podemos confirmar isto através dos trabalhos de diversos especialistas e instituições: •. Lewis [Lewis-01] coloca que existem fortes limites em nossa habilidade de estimar esforço de desenvolvimento de software. Ele afirma que não existe técnica objetiva para obter uma boa estimativa da complexidade de uma atividade de desenvolvimento de software antes de completar a mesma. Ele usa “objetiva” para significar uma técnica mecânica, formal, que não se baseie em intuição humana. Sua afirmativa é suportada. Centro de Informática – UFPE. Página 1.

(16) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. por uma prova matemática. Lewis está matematicamente correto, mas ele está correto apenas para uma definição muito restrita do problema de estimativa de software. Na vida real, engenheiros de software e pesquisadores no campo de processo de software não estão tentando resolver o problema que Lewis aborda. •. Steve McConnel [McConnell-98] chega a afirmar que em função das incertezas que cercam os estimadores na definição inicial do projeto, que a estimativa acurada neste momento é teoricamente impossível. Para isso ele usa o “Cone da Incerteza” (ver Figura 1.1) no qual ele exibe graficamente como a tomada de decisão em um projeto de software evolui de um amplo espectro de variação para um pequeno espectro durante a execução do projeto. A conclusão que ele chega é que “cedo em um projeto você pode ter metas de custo e cronograma rígidos ou um conjunto de funcionalidades rígidas, mas não ambos”. É importante ressaltar que, considerado o “cone”, a acurácia de uma estimativa melhora rapidamente para os primeiros 30% do projeto, melhorando de +- 4x para +- 1,25x (na finalização do projeto de interface do usuário).. Figura 1.1 – Cone da Incerteza [McConnell-98]. •. O Chaos Report do Standish Group reporta que 66% dos projetos são entregues atrasados ou acima do orçamento previsto, ou pior, não terminam [Softwaremag-04].. •. O PMI [PMI-00] afirma que em projetos em geral existem três tipos de estimativa: Order Of Magnitude, com uma margem de erro de -25% a +75%, Budget, com uma margem de erro de -10% a +25, e Definitive, com uma margem de erro de -5% a +10%. Cada uma destas estimativas ocorre em um momento diferente do projeto, mas mesmo a Definitive, que é realizada após detalhado conhecimento do projeto, prevê uma margem de erro. Podemos concluir que o PMI também indica que não existem estimativas 100% acuradas.. Centro de Informática – UFPE. Página 2.

(17) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. •. O Laboratório de Engenharia de Software da NASA (SEL), uma das mais bem sucedidas organizações de software no mundo, cria uma estimativa inicial do projeto apenas depois que os requisitos foram definidos, e refina as estimativas cinco vezes ao longo do projeto, nos pontos mostrados na Tabela 1.1 [SEL-90]. Em cada ponto de estimativa, o time de projeto faz uma estimativa base do trabalho restante. O intervalo de incerteza na estimativa é então expresso multiplicando a estimativa base pelo limite superior e inferior da Tabela 1.1. Adicionalmente o Manual de Gestão de Projetos do SEL [SEL-90] avisa que estimativas tipicamente crescem 40% ao longo do projeto. Ponto de Estimativa. Limite Superior. Limite Inferior. Fim da especificação e definição de requisitos. X 2,00. X 0,50. Fim da análise de requisitos. X 1,75. X 0,57. Fim do projeto preliminar. X 1,40. X 0,71. Fim do projeto detalhado. X 1,25. X 0,80. Fim da implementação. X 1,10. X 0,91. Fim dos testes de sistema. X 1,05. X 0,95. Tabela 1.1– Refinamento de Estimativa de Esforço ao Longo de um Projeto [SEL-90]. •. “Uma estimativa é a predição mais otimista que tem uma probabilidade diferente de zero de se tornar verdade” - Tom DeMarco [DeMarco-82]. Considerando que o processo de estimativa não é 100% acurado, o que nos leva a realizá-lo? Com todo o exposto, e todas as incertezas que cercam o estimador, deveríamos concluir que é impossível obter uma estimativa precisa e acurada no início de um projeto, e concordar com Lewis [Lewis-01] que afirma que nós deveríamos colocar mais fé nas pessoas que em técnicas quando criando estimativas de software. Ele afirma que boas estimativas requerem experiência e julgamento, e que a indústria de software deveria valorizar a experiência, intuição, e sabedoria humanas. Concordamos totalmente com esta colocação. Bons profissionais que saibam o que estão fazendo são inestimáveis ao processo de desenvolvimento de software. Em adição a isto, nós devemos também continuar a buscar técnicas formais de estimativa de software, que forneçam estimativas acuradas para a maioria das atividades de desenvolvimento. A existência de tais técnicas não é excluída pelos resultados expostos anteriormente. Estes apenas demonstram que nós temos que entender os limites das técnicas de estimativas e sermos cuidadosos quando interpretando seus resultados.. Centro de Informática – UFPE. Página 3.

(18) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. 1.1. Motivação do Trabalho Este trabalho foca em mostrar que embora as incertezas existam, e devam ser consideradas na estimativa, é possível realizar uma estimativa confiável no início de um projeto, permitindo que o mesmo seja gerenciável, dando resposta ao axioma que diz: “Você não pode gerenciar o que você não pode medir”. São essas as diretrizes que buscaremos através do estudo das diferentes técnicas de estimativa disponíveis, seleção da mais adequada à realidade da organização estudo de caso, e posterior adoção da mesma nesta organização. Esta adoção é necessária para que o custo e prazo de um projeto de desenvolvimento de software possam ser estimados com a acurácia que permita a negociação do projeto com todos os patrocinadores do mesmo, possibilitando determinar se as metas do projeto (entradas no processo) são realistas o suficiente para permitir que as mesmas sejam alcançadas com uma gestão efetiva do projeto. Conforme citam diversos especialistas [McConnell-06] [Stutzke-05] [Boehm-00], se o intervalo entre a estimativa realizada e a meta do projeto for menor ou igual a 20%, o Gerente de Projeto terá espaço suficiente de manobra para controlar as funcionalidades que serão implementadas, o cronograma, o tamanho do time, e outros parâmetros para atingir os objetivos de negócios do projeto. Se este intervalo for maior que 20%, a estimativa servirá como base para discussão, permitindo que esta seja focada nas alterações no escopo, prioridades e restrições (as entradas do processo de estimativa), sendo novamente estimado o projeto com base em um processo consistente e confiável. Desta forma as estimativas ajudam a determinar a viabilidade de completar projetos dentro das restrições de tempo, custo e funcionalidades impostas pelos patrocinadores. Como visto anteriormente, a Engenharia de Software embora disponha de diversas técnicas de estimativa em utilização pelo mercado, não dispõe de uma técnica que seja universal, adequada a qualquer realidade e contexto de utilização. Sendo assim é necessário estudar as técnicas disponíveis, e verificar a adequação das mesmas às necessidades específicas de uma organização de software. O trabalho apresentado nesta dissertação está inserido no contexto do projeto de melhoria organizacional da empresa estudo de caso, que iniciou a implementação deste projeto estratégico desde a sua fundação, abrangendo todos os seus processos organizacionais. As principais metas deste projeto englobam a certificação ISO 9001 da ISO (International Organization for Standardization) no processo de desenvolvimento de software (obtida em Centro de Informática – UFPE. Página 4.

(19) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. abril de 2006) e a implantação em 2007 das áreas de processo definidas no nível 2 e 3 do modelo CMMI (V1.2) (Capability Maturity Model Integration) do SEI (Software Engineering Institute), organização americana que objetiva melhorar a qualidade e a produtividade das práticas de engenharia de software. Por sua vez, o escopo deste trabalho está inserido no âmbito do processo de desenvolvimento de software da empresa estudo de caso, focado mais especificamente nas atividades de pré-venda e planejamento e acompanhamentos dos projetos desta instituição. O processo de engenharia de software Rational Unified Process – RUP foi adotado como base referencial do processo de software padrão da empresa, o qual é denominado "SGQP – Sistema de Gestão da Qualidade PITANG". Os projetos de pré-venda e de fábrica de software utilizam este processo, e foram usados como estudos de caso para este trabalho, no período de setembro de 2005 a março de 2007.. Centro de Informática – UFPE. Página 5.

(20) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. 1.2. Objetivo do Trabalho Neste trabalho, está sendo proposto um processo para selecionar técnicas de estimativa de software, e definido um processo que se usa da técnica escolhida para suportar as atividades de estimativa no contexto de uma organização de desenvolvimento de software. O processo proposto tem como objetivo definir as atividades de estimativa desde a fase inicial de pré-venda, incluindo a definição dos objetivos e necessidades de informações. Para definir o processo proposto, este trabalho se concentrou nas seguintes atividades: •. Um aprofundado estudo das técnicas e processos de estimativa de Software, enfatizando principalmente as técnicas e processos de maior aceitação no mercado de software mundial (Capítulo 2);. •. Definição de modelo de seleção de técnicas, para selecionar técnica de estimativa a ser adotada na empresa estudo de caso (Capítulo 3);. •. Definição da técnica a ser utilizada na empresa estudo de caso (Capítulo 3);. •. Acompanhamento de estudos de caso de estimativas de esforço utilizando a técnica definida (Capítulo 4);. •. Finalmente, a incorporação de uma técnica para estimativa de esforço de desenvolvimento de projetos de software (Capítulo 4).. A estratégia adotada na escolha e configuração de um processo de estimativa de esforço de desenvolvimento de software permitiu alcançar o objetivo final deste trabalho, que é definir e adotar um processo de estimativa rápido, baseado em requisitos e facilmente negociável com o usuário, que permita sua institucionalização de forma rápida e independentemente de pessoas, sendo ainda facilmente replicável. Este processo deve atender às três questões chave para uma estimativa efetiva [Beck-01]: •. Manter ela simples;. •. Usar o que aconteceu no passado;. •. Aprender com a experiência.. Centro de Informática – UFPE. Página 6.

(21) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. 1.3. Organização deste Trabalho Além deste capítulo introdutório, este trabalho está organizado da seguinte forma: O Capítulo 2, apresenta as principais práticas utilizadas pela indústria de software para a estimativa de esforço de desenvolvimento de software; O Capítulo 3 descreve o processo de seleção da técnica de estimativa implantada na empresa estudo de caso; O Capítulo 4 apresenta como o esforço e custo derivam da estimativa de tamanho realizada, e apresenta o processo de gestão de estimativas de software implantado na PITANG, que utiliza a abordagem de pontos de função. Esta técnica é a base do fluxo de prévenda do SGQP, propondo os artefatos e atividades deste fluxo; O Capítulo 5 apresenta a conclusão deste trabalho, descrevendo alguns trabalhos relacionados com a área de estimativas de esforço de desenvolvimento de projetos de software, os trabalhos deixados para serem continuados no futuro, as contribuições deste trabalho e algumas considerações finais; O Apêndice A, apresenta um detalhamento das características gerais do sistema da técnica de Pontos de Função, buscando uniformizar a valoração destes níveis de influência para o cálculo do valor do fator de ajuste (VAF); O Apêndice B apresenta um detalhamento dos direcionadores de custo usados em COCOMO II; O Apêndice C apresenta um detalhamento dos escores usados no cálculo de fator técnico na métrica de Pontos de Casos de Uso; O Apêndice D apresenta um detalhamento dos escores usados no cálculo de fator ambiental da técnica de Pontos de Casos de Uso; O Apêndice E contém um exemplo de escrita de um caso de uso dentro de padrões adequados para a estimativa usando a técnica de Pontos de Casos de Uso; O Apêndice F mostra como chegamos ao número de horas úteis trabalhadas por mês, usado para o cálculo de esforço; O Apêndice G apresenta o check-list de estimativas usado para refletir no processo de pré-vendas todas as lições aprendidas na experiência acumulada em projetos da empresa estudo de caso; Por fim, o Apêndice H, contém um glossário dos termos técnicos utilizados neste trabalho. Centro de Informática – UFPE. Página 7.

(22) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. Capítulo 2 2. Técnicas para Estimativa de Esforço de Software "Previsão é muito difícil, especialmente sobre o futuro" - Niels Bohr (1885-1962). Este capítulo conceitua estimativa e estuda com uma visão crítica as principais técnicas que são atualmente utilizadas pela indústria de software para estimar esforço de desenvolvimento de projetos de software.. 2.1 Conceituando Estimativa Iniciaremos o nosso estudo das diferentes técnicas de estimativas, conceituando o que é estimativa. Para isto podemos iniciar consultando um dicionário, onde obteremos as seguintes definições para estimativa: •. Definir por aproximação ou por tentativas o valor, custo, ou significância. •. Determinar de forma grosseira o tamanho, extensão, ou natureza. •. Produzir uma definição do custo aproximado. Pelas definições acima, estimativa deveria ser uma “aproximação”, uma “determinação grosseira”. No entanto não é isto que temos em mente ou que esperam de nós quando iniciamos um trabalho de estimativa. Quando nos pedem uma estimativa, geralmente esperam um compromisso ou um plano para atingir uma meta. Uma meta é uma definição de um objetivo desejado de negócios. O que temos que estar atentos é para que estas metas não se transformem na estimativa. Afinal de contas uma meta de negócios, ainda que obrigatória, pode não ser factível no tempo ou recursos que se dispõe. O compromisso é o que se espera como saída da estimativa, ou seja, uma promessa de entrega de determinadas funcionalidades, dentro do custo, prazo e qualidade definidos previamente.. Centro de Informática – UFPE. Página 8.

(23) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. A realização de uma boa estimativa passa por evitarmos os “Pecados Mortais” de um processo de estimativa: •. As estimativas mais fortes vêm de quem tem cordas vocais mais fortes;. •. Criar estimativa de um novo projeto baseado na estimativa de um anterior (e não no realizado de um anterior);. •. Assumir que vendas estima melhor que engenharia;. •. Assumir 8 horas por dia e esquecer o improdutivo;. •. Estimativas muito precisas mas pouco acuradas;. •. Assumir que as estimativas estão superfaturadas sem considerar a história de entrega de projetos no prazo da organização;. •. Confundir metas com estimativas;. •. Dizer sim quando deveria dizer não (falta de processo e senioridade);. •. Comprometer-se com estimativas sem necessário conhecimento dos requisitos;. •. Assumir que subestimar ou superestimar tem impactos neutros no resultado dos projetos;. •. Estimar na “zona do impossível” 3 (na ânsia de atender o cliente);. •. Superestimar economias de novas ferramentas ou técnicas;. •. Não suportar o seu trabalho com ferramentas;. •. Não incluir o impacto dos riscos nas estimativas;. •. Processo indefinido de estimativas;. •. Otimismo exagerado (nem tudo sai certo na primeira vez);. •. Não considerar atividades custodiais, de gerenciamento e controle;. •. Subestimar requisitos não funcionais.. O fato de estarmos atentos a estes “pecados”, e evitarmos incorrer nos mesmos, é um grande passo para uma estimativa de qualidade. Um outro importante ponto que devemos ter sempre em mente, é colocado por Jim Highsmith [Highsmith-02] quando ele discute a diferença entre a gerência sênior dar uma data de finalização para o projeto e perguntar quando o mesmo se encerrará. Ele conclui, “talvez não sejam nossas habilidades de estimativa que necessitem de atualização, mas sim as de negociação”.. 3. Ver Figura 4.6 Centro de Informática – UFPE. Página 9.

(24) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. A qualidade de qualquer estimativa se baseia na completude dos requisitos e quão bem eles foram especificados, e na habilidade da organização de controlar requisitos que mudam durante a execução do projeto. Estimativas iniciais são mais bem sucedidas se: •. Elas resultam de um processo disciplinado de definição de escopo;. •. Servem de entrada tanto para estimadores “humanos” quanto de software;. •. São rastreadas ao longo do projeto.. Um bom processo de estimativa pode então ser modelado como a Figura 2.1. Escopo Técnico Prioridades. Esforço Estimado Processo Padrão de Estimativa. Restrições. Cronograma Estimado. Custo Estimado. Dados Históricos. Características Estimadas. Figura 2.1 – Processo de Estimativas. O SEI (Software Engineering Institute de Carnegie Mellon) afirma no CMMI (Capability Maturity Model Integration) que a estimativa de custo de um projeto deve ser baseada no esforço necessário para construí-lo, sendo o esforço por sua vez calculado em função do tamanho estimado para o software a ser desenvolvido [SEI-07]. Sendo assim tudo se baseia na estimativa de tamanho e na sua acurácia. Um processo adequado de estimativa deve usar as informações de escopo, prioridades, restrições e dados históricos, para determinar o tamanho do software a ser desenvolvido (conforme Figura 2.2 [Kival-99]).. Figura 2.2 – Processo de Estimativa [Kival-99] Centro de Informática – UFPE. Página 10.

(25) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. A partir do tamanho é determinado o esforço necessário. Deste esforço são então derivados o cronograma, os custos e as funcionalidades que o software virá a ter (que funcionalidades “cabem” no cronograma e custos, considerando as prioridades e restrições). Isto pode ser visualizado na Figura 2.3. Cronograma Tamanho. Esforço Custo. Figura 2.3 – Derivando Esforço, Cronograma e Custo. É essencial perceber aqui, que as saídas são mudadas pela alteração dos dados de entrada (escopo, prioridades e restrições), e nunca pela alteração do processo de estimativa. Adicionalmente devemos atentar que o processo de estimativa é totalmente sensível à qualidade dos dados de entrada, conforme ilustrado na Figura 2.4. Entra Lixo. Processo de Estimativa. Sai Lixo. Figura 2.4 – Sensibilidade do processo de estimativa à qualidade dos dados de entrada. O processo de estimativa definido deve ser suportado por uma técnica de estimativa. Testes provam que se 10 gerentes de projetos de diferentes áreas tentam estimar esforço de projetos sem uma abordagem sistemática, incluindo técnicas FSM, a relação entre a menor e maior estimativa é de 1 para 6, sendo o pior caso 1 para 12 [ISBSG-07]. Logo, o uso de uma técnica sistemática é essencial para um processo adequado de estimativas. Segundo o PMI [PMI-00], a adoção de uma técnica formal minimiza a subjetividade na elaboração da estimativa. Os resultados esperados pela adoção de uma técnica são: 1. Estabelecer uma forma técnica de estimar na organização; 2. Possibilitar que não-especialistas também consigam estimar com um bom grau de certeza; 3. Viabilizar a comparação e refino gradual da técnica de forma muito mais efetiva e objetiva que o aprendizado do especialista a partir de suas próprias estimativas; 4. Registrar as premissas nas quais foram baseadas as estimativas, de modo que estas sejam repetíveis; 5. Facilitar a defesa das estimativas quando questionados ou solicitados a reduzi-las, pois elas têm um racional por trás; 6. Aumentar a previsibilidade, pois a uma técnica e fórmula de estimativa é inerente a existência de limites para os resultados possíveis. Centro de Informática – UFPE. Página 11.

(26) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. O processo de estimativa tem o objetivo de modelar em um método a experiência do especialista, requerendo menor experiência para seu uso, pois esta estará refletida no próprio método, o que a tornará repetível. Um método de estimativa não é a verdade absoluta, mas constitui-se na melhor aproximação possível desta verdade em um determinado momento, devendo ser constante e incessantemente revisto e calibrado com base no histórico de estimativas que é coletado. Um bom método de estimativa deve estar documentado, para ser repetido sempre da mesma forma por qualquer um na organização, ser simples para poder ser bem entendido e ser realimentado pelo histórico, visto que através dos dados históricos iremos convergir em nossas estimativas até o nível de qualidade exigido.. Centro de Informática – UFPE. Página 12.

(27) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. 2.2 Histórico de Técnicas de Estimativa Conforme vemos na Tabela 2.1, ao longo da história do desenvolvimento de software, várias técnicas já foram propostas, tendo algumas vingado, e outras caído no esquecimento. Nome do Técnica. Organização/Pesquisador. Ano. Delphi. Rand Corp.. 1959. Nelson's SDC. SDC. 1966. Wolverton. TRW. 1974. RCA Price-S System. RCA. 1976. Halstead. M.H.Halstead. 1977. Walston and Felix. IBM. 1977. SLIM - Software Lifecycle Management. QSM. 1978. Function-point Method. IBM. 1979. Parr Model. F.N. Parr. 1980. COCOMO-Model. TRW. 1981. Wideband Delphi. Barry Boehm. 1981. SOFTCOST. JPL. 1981. Bailey and Basili. NASA. 1981. Bang Metrics. Tom DeMarco. 1982. Feature Points. Software Productivity Research. 1986. SEER-SEM - System Evaluation and Estimation of Resources. Galorath Incorporated. 1988. MARK II Function Points. United Kingdom Software Metrics Association. 1988. NESMA. Netherlands Software Metrics Association. 1989. 3D Function Points. Boeing Company. 1992. Use Case Points. Objectory. 1993. Object Points. Banker D. R. 1994. - Software Engineering Model. COCOMO II. University of Southern California. 1995. Proxy Based Estimation (PROBE). SEI - Software Engineering Institute. 1996. COBRA. Fraunhofer Institute for Experimental Software Engineering. 1997. Full Function Points. COSMIC - Common Software Measurement International Consortium 1997. Class-Method Points. Galorath Incorporated. 1999. Web Objects. Reifer Consultants, Inc. 2000. Web Points. CHARISMATEK Software Metrics. 2000. Planning Game - Extreme Programming. Beck and Fowler. 2001. Internet Points. Cost Xpert Group. 2001. Planning Poker - Extreme Programming. Object Mentor. 2002. Data Web Points. Computer Sciences Department. University of Chile. 2003. Agile COCOMO II. USC Center for Software Engineering. 2003. Story Points. Mike Cohn. 2003. OO-Method Function Points (OOmFP). Department of Information System, Valencia University of Technology 2004. TUCP – Technical Use Case Points. UNIFOR – Universidade de Fortaleza – Tatiana Monteiro. 2005. Tabela 2.1 – Técnicas de Estimativa Centro de Informática – UFPE. Página 13.

(28) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. 2.3 Classificação de Técnicas de Estimativa Depois de 40 anos de pesquisa, existem muitas técnicas de estimativa de software disponíveis, sendo classificadas em técnicas algorítmicas, técnicas por analogia, técnicas de julgamento de especialistas, e técnica precificando para vencer. Apresentaremos a seguir uma breve descrição desta classificação de técnicas. 2.3.1 Técnica de Julgamento de Especialistas Técnicas de julgamento de especialistas envolvem a consulta de um ou mais especialistas em estimativa de software para usar suas experiências e conhecimento em projetos similares ao do projeto proposto para obter uma estimativa de seu esforço de desenvolvimento. As técnicas baseadas na experiência de especialistas são úteis na ausência de dados quantitativos. Estudos em diferentes áreas de conhecimento demonstram que o uso de 3 a 5 especialistas com formações diferentes parecem ser suficientes [Libby-78][Jørgensen-021]. Adicionalmente, é útil ter especialistas com diferentes formações, diferentes papéis, ou que usam técnicas diferentes [Jørgensen-021]. Mecanismos de consenso como a técnica Wideband Delphi ou PERT são usados para resolver as inconsistências nas estimativas. Esta técnica de estimativa traz quatro conseqüências imediatas: 1. Por ser um processo subjetivo, não há um parâmetro racional para gerar as estimativas, isto é, se houver uma alteração nas premissas, dificilmente será possível reaproveitar ou readequar as estimativas; 2. Tem-se a tendência a estimar com base na experiência individual e produtividade de cada um, o que pode não refletir a experiência e produtividade de um determinado time de projeto; 3. Cria-se uma dependência e um gargalo nos especialistas em estimativa, pois só eles detêm alguma fórmula empírica e subjetiva para estimar; 4. Não há um racional sólido para defender as estimativas quando questionados ou pressionados a reduzi-las (tudo se resume ao sentimento do especialista), e elas podem ser rotuladas de hipóteses, sugestões (mesmo que corretas) e tornarem-se sensíveis à pressão. É inegável, no entanto, que várias organizações têm um bom registro de acerto médio em suas estimativas por especialistas, observado nos projetos. Porém, o que se necessita nas estimativas realizadas, para que possuam qualidade, é aumentar o grau de previsibilidade (certeza) do que é estimado, e não necessariamente conseguir manter uma boa média. Isto é, a média pode estar perfeita, mas é para a previsibilidade que o foco deve ser direcionado. Centro de Informática – UFPE. Página 14.

(29) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. 2.3.2 Estimando por Analogia A estimativa por analogia é a técnica mais comum de estimativa na indústria de software [Jørgensen-02]. Estimar por analogia significa comparar o objeto proposto aos projetos similares previamente completados, onde as informações do desenvolvimento dos mesmos são conhecidas. Dados dos projetos completados são extrapolados para estimar o projeto proposto. Esta técnica pode ser usada tanto em nível de sistema quanto em nível de componente. A analogia é geralmente realizada por especialista em estimativas (com base na experiência de projetos anteriores) ou por algoritmos de busca de projetos similares (disponíveis em base de dados) [ISBSG-07]. Esta abordagem requer um conhecimento detalhado do projeto, para identificar as diferenças específicas entre o projeto proposto e projetos anteriores, que foram usados como base para realizar a estimativa. 2.3.3 Técnicas Paramétricas ou Algorítmicas A estimativa é calculada usando informações históricas que relacionam algumas das métricas de software (normalmente o tamanho) ao esforço do projeto. Uma estimativa é feita daquela métrica, e a técnica prevê o esforço requerido. As técnicas paramétricas assumem que existe um relacionamento matemático entre o tamanho, esforço, prazo e qualidade e que o relacionamento é afetado por fatores mensuráveis de desempenho também chamados parâmetros. A técnica é projetada para prover algumas equações matemáticas para realizar a estimativa de software. Estas equações matemáticas são baseadas em pesquisa e dados históricos e usam entradas tais como linhas de código fonte (SLOC), número de funções a realizar, e outros direcionadores de custo tais como linguagem, metodologia de projeto, níveis de conhecimento, exposição a riscos, tamanho do time, etc. As técnicas algorítmicas têm sido largamente estudadas, sendo desenvolvidas diversos, tais como as técnicas COCOMO, e as baseadas em unidades funcionais. Para obter melhores resultados, as técnicas paramétricas devem ser calibradas com dados do ambiente local de desenvolvimento [McGarry-01].. Centro de Informática – UFPE. Página 15.

(30) Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real. 2.3.4 Precificando para Vencer O custo do software é estimado para ser o que o cliente tem disponível para gastar no projeto. O esforço estimado depende do orçamento do cliente e não da funcionalidade do software. A noção de “Precificando para Vencer” pode parecer antiética e desvantajosa para negociação. Contudo, ela tem algumas vantagens. Um custo de projeto é acordado na base de uma proposta esboço. Negociações então podem ser feitas entre o cliente e fornecedor para estabelecer uma especificação detalhada do projeto. Esta especificação é restringida pelo custo acordado. O comprador e o vendedor precisam concordar em qual é a funcionalidade aceitável do sistema. O fator fixo em muitos projetos não é o conjunto de requisitos do projeto, mas o custo. Os requisitos podem ser alterados desde que o custo não seja excedido.. 2.4 Estudo Detalhado das Principais Técnicas de Estimativa Conforme vimos nas Seções 2.2 e 2.3, diferentes técnicas existem, sendo classificadas de acordo com a forma que abordam a estimativa. Estudaremos nesta seção as principais técnicas de estimativa em uso pela indústria de software, a fim de criar uma conceituação teórica base para a seleção da técnica mais adequada à instituição estudo de caso (Capítulo 3). 2.4.1 Wideband Delphi Wideband Delphi é uma técnica estruturada de estimativa por grupo. A técnica original Delphi foi desenvolvida para previsão de tendências em tecnologia [Boehm-81]. O nome Delphi vem do antigo oráculo grego de Delfos (Delphi em inglês). A técnica básica consiste em convocar diversos especialistas para criar estimativas independentes e então colocá-los em uma reunião que durará o quanto for necessário para que eles convirjam, ou ao menos concordem, em uma única estimativa. Um estudo desta técnica promovido por Barry Boehm [Boehm-81] mostrou que ela não era mais acurada que um encontro de grupo menos estruturado. Ele concluiu que a técnica era muito sujeita a pressão política e também tendia a ser dominada pelos estimadores mais assertivos no grupo. Consequentemente, ele estendeu a técnica básica para o que ficou conhecido como Wideband Delphi. A mesma funciona da seguinte forma:. Centro de Informática – UFPE. Página 16.