Implantação de Processo de Estimativa de Esforço de … › bitstream › 123456789 › 2685 ›...

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 [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, AGOSTO/2007

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ÓS-GRADUAÇÃ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

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

iv

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.

v

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.

vi

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)

vii

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)

viii

Índice 1. Introdução .........................................................................................................................................................1

1.1. Motivação do Trabalho.............................................................................................................................4

1.2. Objetivo do Trabalho................................................................................................................................6

1.3. Organização deste Trabalho....................................................................................................................7

2. 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

ix

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

x

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

xi

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

xii

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

xiii

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

xiv

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

Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real

Centro de Informática – UFPE Página 1

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



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.



• 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.



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



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.



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.



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.



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.



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



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.

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]

Processo Padrão de Estimativa

Escopo Técnico

Prioridades

Restrições

Dados Históricos

Esforço Estimado

Cronograma Estimado

Custo Estimado

Características Estimadas



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.

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.

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.

Processo de

Estimativa

Entra Lixo Sai Lixo

Tamanho EsforçoCronograma

Custo



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.



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

- Software Engineering Model

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

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



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.



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].



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:



1. Coordenador apresenta a cada especialista a especificação e um formulário de

estimativa.

2. Especialistas preenchem os formulários anonimamente (Opcionalmente, este passo

pode ser realizado após o passo 3).

3. Coordenador convoca um encontro em que os especialistas discutem as questões de

estimativas com o coordenador e entre si. Se o grupo concorda com uma estimativa

única sem muita discussão, o coordenador atribui a alguém o papel de advogado do

diabo.

4. Especialistas dão suas estimativas individuais para o coordenador anonimamente.

5. Coordenador prepara e distribui um sumário da estimativa.

6. Coordenador convoca um encontro do grupo, especialmente focado em discutir entre

os especialistas os pontos em que suas estimativas variaram mais fortemente.

7. Especialistas votam anonimamente em se eles aceitam a estimativa média (obtida pela

média das estimativas de cada especialista). Se qualquer dos especialistas votar “não”,

eles retornam para o passo 3.

8. A estimativa final é a estimativa única obtida pelo uso da técnica, ou o intervalo criado

pela discussão dos especialistas, sendo a estimativa única o cenário mais provável.

Estudos conduzidos por Steve McConnel [McConnell-06] mostram que o uso da mesma

reduz erros de estimativa em aproximadamente 40% quando comparada com a simples

média inicial do grupo.

Como esta técnica requer reuniões, ela gasta bastante tempo do time, tornando-se uma

forma cara de estimar. Não consideramos a mesma apropriada para estimativas detalhadas

de tarefas. A mesma é útil se você está estimando em uma área nova de negócios, em uma

nova tecnologia, ou um tipo novo de software. É útil para criar estimativas de “ordens de

magnitude” no momento de definição do produto ou de concepção do software, antes que os

requisitos tenham sido muito detalhados.



2.4.2 Pontos de Função

Em meados dos anos 70, a IBM designou um engenheiro de nome Allan Albrecht e seus

colegas para explorar métricas e medidas de software. Os motivos para esta designação

foram a crescente importância de software dentro da IBM, bem como os problemas e

limitações das métricas de linhas de código. Depois de mais de um ano de pesquisa e

discussão, Albrecht e seu time formularam a primeira versão da métrica agora conhecida

como pontos de função. A métrica foi concebida como um meio de medir tamanho de

software e produtividade, usando entidades lógicas, funcionais tais como entradas, saídas e

consultas que tendem a se relacionar mais de perto com as funções realizadas pelo software

quando comparadas a outras medidas, tais como linhas de código.

Depois de alguns anos de uso interno na IBM, a métrica de pontos de função foi lançada

para os clientes da IBM e para a indústria de software como um todo. A definição e medição

de pontos de função evoluíram substancialmente, tendo sido fundado em 1984 o International

Function Point Users Group (IFPUG), que atua ativamente trocando informações em análise

de pontos de função (FPA). O Comitê de Práticas de Contagem do IFPUG promulga o

Manual de Práticas de Contagem (CPM), o qual contém os padrões e guias correntes para o

processo de contagem. A versão atual do CPM é a 4.2, em vigor desde maio de 2004.

A métrica original foi aumentada e refinada para cobrir mais que a tese original de

processamento de dados relacionado a processos. Seu principal mérito reside na abordagem

das funções e características de um sistema sob o ponto de vista do que ele faz para o

usuário, num enfoque do negócio da empresa, com base nos requisitos funcionais e não nos

técnicos, o que torna a técnica de contagem independentemente do hardware (porte,

geração, fabricante) e da tecnologia de desenvolvimento (linguagem, software de apoio,

geradores de aplicação, etc.).



FPA se tornou geralmente aceito como uma forma efetiva de:

• Medir a Produtividade – com a utilização dos pontos de função, temos uma medida independente que nos permite comparar o desempenho de pessoas e equipes no desenvolvimento de sistemas e comparar a empresa com o mercado;

• Estimar o Desenvolvimento e a Manutenção - FPA é antes de tudo uma técnica de estimativa. Estimar é necessário para a análise do custo X benefício. A FPA torna as decisões estratégicas de desenvolvimento algo pautado em medidas acuradas;

• Monitorar Acordos de Terceirização – Como é uma medida aceita pela indústria, a FPA se presta a ser a base para os acordos, cobranças e compromissos feitos pelas partes contratadas;

• Normalizar outras medidas – Medidas diferentes podem ser comparadas com os pontos de função. Por exemplo, 100 defeitos encontrados não é uma medida significativa, agora, 100 defeitos em um sistema de 5.000 PF é uma medida com um significado claro.

Análise de pontos de função é uma metodologia provada e largamente aceita para

determinar o tamanho de um projeto de desenvolvimento de software ou de uma aplicação de

software instalada. As regras de contagem vêm sendo atualizadas ao longo do tempo para

prover contagens mais consistentes e uma correlação mais apurada entre o tamanho e o

esforço de um projeto. A técnica foi oficializada através do padrão internacional ISO/IEC

20926 de 2002, sendo aceita como uma medida funcional de tamanho de software (FSM).

Medida funcional de tamanho de software é um conceito definido pelo padrão ISO/IEC 14143-

1:1998 e refere-se à medição do tamanho do software considerando-se apenas a

funcionalidade solicitada e recebida pelos respectivos usuários, de forma independente da

linguagem ou método de desenvolvimento, tecnologia ou capacidade da equipe envolvida.

Existem várias técnicas de medição de tamanho funcional (FSM) disponíveis. Pelo menos

cinco diferentes técnicas podem ser chamadas de FSM. Elas são:

• COSMIC-FFP Functional size measurement method v2.2 - http://www.lrgl.uqam.ca/cosmic-ffp/about.html;

• IFPUG 4.2 Unadjusted - www.IFPUG.org; • Mk II Function Point Analysis 1.3.1 Unadjusted - www.uksma.co.uk/; • NESMA FPA method 2.1 - www.NESMA.nl/english/; • FISMA FSM 1.1 – http://www.fisma.fi/in-english/.



As abordagens mais utilizadas internacionalmente são a do IFPUG, NESMA e COSMIC

FFP. Outras abordagens compatíveis com o padrão ISO são primariamente baseadas em

seus países de origem: FISMA (Finlândia) e MARK ll (Reino Unido). A técnica mais

comumente usada, e também a mais antiga, é o do IFPUG (International Function Point

Users Group). A evolução das técnicas FSM pode ser visualizada na Figura 2.5 [Braungarten-

05]. Neste trabalho aprofundaremos o estudo das técnicas IFPUG e NESMA.

Figura 2.5 – Desenvolvimento de Técnicas para FSM [Braungarten-05]

Pontos de função medem o tamanho em termos da quantidade de funcionalidade em um

sistema. Não é mais que um fator de normalização para comparação de software, assim

como outras unidades padrão de tamanho – ex., metros quadrados, litros, quilogramas,

quilômetros. Contagens de pontos de função por si só não dizem nada sobre seus valores ou

custos; outros fatores precisam ser considerados em estimativas de custo, valor ou

necessidades de recursos para a aquisição, desenvolvimento, ou manutenção de software.

Isto não diminui o valor da FPA; ao contrário, a coloca em perspectiva com outros padrões

consistentes de medida. O tamanho de uma aplicação, em pontos de função, pode ser usado

em conjunto com outras características da aplicação (ex., requisitos de desempenho,

segurança, complexidade algorítmica) e atributos do projeto (tais como nível de conhecimento

dos desenvolvedores, linguagens a serem utilizadas, a metodologia e tecnologia a ser

utilizada, e as tarefas a serem realizadas) para estimar o custo e recursos requeridos.



2.4.2.1 Processo Utilizado para Estimar Pontos de Função

O processo usado para estimar pontos de função pode ser sumarizado em sete passos

(Figura 2.6 [Shazan-03]):

1. Determinar o tipo de contagem de ponto de função;

2. Identificar o escopo da contagem e a fronteira da aplicação;

3. Identificar todas as funções de dados (arquivos lógicos internos e arquivos de

interface externa) e suas complexidades;

4. Identificar todas as funções de transação (saídas externas, entradas externas, e

consultas externas) e suas complexidades;

5. Determinar a contagem de ponto de função não ajustada;

6. Determinar o valor do fator de ajuste;

7. Calcular o valor da contagem ajustada de pontos de função;

Figura 2.6 – Processo Utilizado Para Estimar Pontos de Função [Shazan-03]

2.4.2.2 Tipos de Contagem

1. Projeto de desenvolvimento – mede a funcionalidade provida aos usuários finais com a primeira instalação da aplicação. Inclui a funcionalidade que irá ser contada na contagem inicial de pontos de função da aplicação, assim como as funcionalidades requeridas para a conversão de dados;

2. Projeto de melhoria – mede modificações em aplicações existentes e inclui as funcionalidades providas aos usuários finais pela adição de novas funções, exclusão de velhas funções, e alteração de funções existentes;

3. Aplicação – mede uma aplicação instalada (em produção). Mede as funcionalidades correntemente providas para os usuários finais da aplicação.

Identificar escopo da contagem e fronteira

da aplicação

Contar Funções de Dados

Contar Funções de Transação

Deteminar Contagem de

Pontos de Função Não Ajustados

Deteminar Valor do Fator de Ajuste

Calcular Contagem de Pontos de

Função Ajustada Determinar Tipo

de Contagem



2.4.2.3 Identificando o Escopo da Contagem e a Fronteira da Aplicação

O escopo da contagem é determinado pelo propósito da contagem. Identifica os sistemas,

aplicações, ou subconjuntos de uma aplicação que irá ser estimada. Pode incluir funções que

irão ser tratadas pela compra de um pacote, pode incluir todas as aplicações que serão

terceirizadas, pode se restringir às funções dentro de uma aplicação que se aplicam a um

propósito específico – ex.: relatórios. Já a fronteira da aplicação é a linha entre a aplicação

sendo medida e aplicações externas. O IFPUG define regras específicas para identificar

fronteiras:

• A fronteira é baseada na visão do usuário. O usuário deve poder definir o escopo da aplicação e as funcionalidades de negócio na sua linguagem.

• A fronteira entre aplicações relacionadas é baseada em funcionalidades separadas de negócios ao invés de considerações técnicas. O Microsoft Office consiste do Word, Excel, PowerPoint, e Access; cada um é uma aplicação separada. Um sistema X pode ter entrada de dados on-line que é seguida por um processamento batch noturno; o sistema X é uma única aplicação que inclui tantos os processos on-line quanto batch.

• A fronteira inicial já estabelecida para uma aplicação não é influenciada pelo escopo da contagem. A fronteira de uma aplicação sendo melhorada (manutenção) permanece como está, exceto, é claro, se a funcionalidade adicionada expandir a fronteira, ou a funcionalidade excluída reduzir a fronteira. Uma melhoria não se transforma na sua própria fronteira de aplicação, mas é definida pelo escopo da contagem. Projetos de desenvolvimento e projetos de manutenção frequentemente abrangem mais que uma única aplicação. Nestes casos, as múltiplas fronteiras de aplicação são identificadas dentro do escopo de contagem, mas elas são contadas separadamente.



2.4.2.4 Estimando Funções de Dados

Funções de dados se relacionam com dados lógicos armazenados e disponíveis para

atualização, referência, e recuperação. Funções de dados são identificadas como Arquivos

Lógicos Internos (ILFs) ou Arquivos de Interface Externa (EIFs). Ambos são grupos,

identificáveis pelo usuário, de dados logicamente relacionados ou de informações de controle.

Desta forma eles são agrupamentos lógicos e não representações físicas destes

agrupamentos de dados. É possível, mas muito improvável, que o lógico corresponda ao

físico; consequentemente, ILFs e EIFs devem ser contabilizados de uma forma similar

independentemente de como o banco de dados está fisicamente implementado. ILFs são

mantidos dentro da fronteira da aplicação sendo contada, mas EIFs só podem ser lidos e/ou

referenciados dentro da fronteira da aplicação sendo contada. EIFs são mantidos em uma

fronteira de aplicação diferente (ver Figura 2.7 [Stutzke-05]).

Figura 2.7 – Conceituação das funções de um sistema [Stutzke-05]

Um arquivo lógico interno (ILF) é um grupo, identificável pelo usuário, de dados

logicamente relacionados ou de informações de controle mantido dentro da fronteira da

aplicação. A intenção primária de um ILF é armazenar dados mantidos através de um ou

mais processos elementares da aplicação sendo contada.

Um arquivo de interface externa (EIF) é um grupo, identificável pelo usuário, de dados

logicamente relacionados ou de informações de controle referenciado pela aplicação, mas

mantido dentro da fronteira de uma aplicação diferente. A intenção primária de um EIF é

armazenar dados referenciados através de um ou mais processos elementares da aplicação

sendo contada. Um EIF contado para uma aplicação precisa ser um ILF em outra aplicação.

Usuários

Entradas Externas

Saídas Externas

Consultas Externas

Arquivos Lógicos Internos

Arquivos de Interface Externa

Algoritmos

Consultas Externas

Saídas Externas

Entradas Externas

Outras Aplicações

Arquivos Lógicos Internos

Fronteira da Aplicação Medida



A contagem física de ILFs e EIFs, em conjunto com a complexidade funcional relativa de

cada, determina a contribuição de cada tipo de função de dados para a contagem de pontos

de função não ajustados. Cada ILF e EIF identificado precisa ter assinalado a complexidade

funcional baseada no número de tipos de elementos de dados (DETs) e tipos de elementos

de registros (RETs) associados com cada ILF ou EIF (ver Tabela 2.2 [Garmus-01]).

• Complexidade funcional é a classificação assinalada a cada função de dados. Os

escores possíveis baixo, médio e alto são atribuídos de acordo com a matriz de

complexidade , que considera o número de DETs e RETs.

• Tipos de elementos de dados (DETs) são campos ou atributos únicos,

reconhecíveis pelos usuários e não repetíveis.

• Tipos de elementos de registros (RETs) são subgrupos (opcionais ou

mandatórios) de elementos de dados contidos em uma EIF ou ILF. Subgrupos são

tipicamente representados em um diagrama de entidade relacionamento como

subtipos de entidade ou entidades fracas, comumente chamadas relacionamentos

pai-filho.

As seguintes regras do IFPUG se aplicam a contagem de DETs e RETs para EIFs e ILFs:

• Conte um DET para cada campo não repetível, reconhecido pelo usuário, mantido

em ou recuperado de um ILF ou EIF;

• Quando duas ou mais aplicações mantém e/ou referenciam o mesmo ILF ou EIF,

mas usam DETs separados, conte apenas os DETs sendo usados por cada

aplicação para estimar o ILF ou EIF;

• Conte um DET para cada dado requerido pelo usuário para estabelecer um

relacionamento com outro ILF ou EIF;

• Conte um RET para cada subgrupo opcional ou mandatório do ILF ou EIF;

• Se não existirem subgrupos, conte um RET para o ILF ou EIF.

Tipos de Elementos de Dados 1 - 19 20 - 50 >= 51

1 Baixo Baixo Médio 2 - 5 Baixo Médio Alto

Tipos de Elementos de Registro > 5 Médio Alto Alto

Tabela 2.2 – Matriz complexidade para ILFs e EIFs [Garmus-01]



2.4.2.5 Estimando Funções de Transação

Sistemas de informação são usualmente desenvolvidos para mecanizar tarefas manuais;

espera-se que estas tarefas sejam realizadas mais economicamente e efetivamente se elas

forem automatizadas. As atividades que foram mecanizadas são identificadas como funções

transacionais, as quais representam as funcionalidades providas para o usuário para o

processamento de dados por uma aplicação.

Uma Entrada Externa (EI) é um processo elementar da aplicação que processa dados ou

informações de controle que vêm de fora da fronteira da aplicação. Dados processados

mantêm um ou mais ILFs; informação de controle processada pode ou não manter um ILF. O

propósito primário de uma EI é manter um ou mais ILFs e/ou alterar o comportamento da

aplicação através de sua lógica de processamento (ver Figura 2.7 [Stutzke-05]).).

Uma Saída Externa (EO) é um processo elementar da aplicação que gera dados ou

informações de controle que vão para fora da fronteira da aplicação. O propósito primário de

uma EO é apresentar informação para um usuário através de sua lógica de processamento,

podendo ainda recuperar dados ou informações de controle. A lógica de processamento deve

conter no mínimo uma fórmula matemática ou cálculo, criar dados derivados, manter um ou

mais ILFs, e/ou alterar o comportamento do sistema (ver Figura 2.7 [Stutzke-05]).).

Uma Consulta Externa (EQ) é um processo elementar da aplicação que resulta em

recuperação de dados ou informações de controle que vão para fora da fronteira da

aplicação. O propósito primário de uma EQ é apresentar informação para um usuário através

da recuperação de dados ou informações de controle de um ILF ou EIF. A lógica de

processamento não contém fórmulas matemáticas ou cálculos, e não cria dados derivados.

Nenhum ILF é mantido durante o processamento, e o comportamento da aplicação não é

alterado (ver Figura 2.7 [Stutzke-05]).).



A contagem física de EIs, EOs e EQs em conjunto com a complexidade funcional relativa

de cada, determinam a contribuição de cada entrada externa / saída externa / consulta

externa para a contagem de pontos de função não ajustados. Cada EI / EO / EQ identificada

precisa ter assinalada uma complexidade funcional baseada no número de tipos de

elementos de dados (DETs) e tipos de arquivos referenciados (FTRs) associados com a EI

(ver Tabela 2.3), EO (ver Tabela 2.4) e/ou EQ (ver Tabela 2.5) [Garmus-01].

• Complexidade funcional é a classificação assinalada a cada função de transação. Os escores possíveis baixo, médio e alto são atribuídos de acordo com a matriz de complexidade, que considera o número de DETs e FTRs.

• Tipos de elementos de dados (DETs) são campos ou atributos únicos, reconhecíveis pelos usuários e não repetíveis.

• Tipos de arquivos referenciados (FTRs) referem-se ao número total de ILFs mantidos ou lidos e de EIFs lidos pela transação.

As seguintes regras do IFPUG se aplicam a contagem de DETs para EIs:

• Conte um DET para cada campo ou atributo não repetível, reconhecido pelo usuário, incluindo chaves estrangeiras, que atravessam (entram ou saem) a fronteira da aplicação de forma a completar o processo elementar da EI;

• Não conte um DET para um campo que não é informado pelo usuário (não cruza a fronteira), mas que através de um EI é recuperado ou derivado pela aplicação e mantido em um ILF;

• Conte um DET para um campo lógico que é armazenado fisicamente separado em múltiplos campos mas é requerido pelo usuário como uma única peça de informação, tais como linhas de um endereço;

• Conte um DET para a capacidade de enviar uma resposta do sistema para fora da fronteira da aplicação para indicar que um erro ocorreu durante o processamento, para confirmar processamento completo, ou para confirmar que o processamento deve continuar;

• Conte um DET para a capacidade de especificar a ação a ser executada pela EI ainda que existam múltiplos métodos de invocar o mesmo processo lógico (ex.: chamada de rotinas por teclas de funções ou linhas de comando).

As seguintes regras do IFPUG se aplicam a contagem de FTRs para EIs:

• Conte um FTR para cada ILF mantido pelo processo elementar da EI; • Conte um FTR para cada ILF ou EIF lido durante o processamento da EI; • Conte apenas um FTR para cada ILF que é tanto mantido quanto lido pela EI.




< 2 Baixo Baixo Médio

2 Baixo Médio Alto Tipos de Arquivos

Referenciados > 2 Médio Alto Alto

Tabela 2.3 – Matriz complexidade para EIs [Garmus-01]

As seguintes regras do IFPUG se aplicam a contagem de DETs para EOs:

• Conte um DET para cada campo não repetível, reconhecido pelo usuário, que entra na fronteira da aplicação e é requerido para especificar o Quê, Quando, e/ou Como dados devem ser recuperados e/ou gerados pelo processo elementar;

• Conte um DET para cada campo não repetível, reconhecido pelo usuário, que sai da fronteira da aplicação;

• Se um DET tanto entra quanto sai da fronteira, conte ele apenas uma vez para o processo elementar;


• Conte um DET para a capacidade de especificar a ação a ser executada pela EO ainda que existam múltiplos métodos de invocar o mesmo processo lógico (ex.: botão de OK, teclas de função, clique de mouse).

• Não conte marcas de paginação ou geradas pelo sistema, incluindo números de página, informação de posicionamento (linha x de y), comandos de paginação (prévio, próximo, setas), ou campos de data / hora (gerados pelo sistema);

• Não conte literais, incluindo títulos de relatórios, IDs de tela, cabeçalhos de colunas, e títulos de campo;

• Não conte campos que são mantidos em um ILF durante o processo elementar da EO se os campos não cruzarem a fronteira;

• Conte um DET para um campo lógico que é armazenado fisicamente separado em múltiplos campos mas é requerido pelo usuário como uma única peça de informação;

• Conte um DET para cada tipo de rótulo e cada tipo de equivalente numérico em um display gráfico (ex.: um gráfico de pizza pode ter dois DETs, um para a categoria e um para a percentagem aplicada);

• Conte um DET para informação de texto que pode consistir de uma única palavra, uma sentença, um parágrafo, ou muitos parágrafos.



As seguintes regras do IFPUG se aplicam a contagem de FTRs para EOs:

• Conte um FTR para cada ILF ou EIF lido durante o processamento da EO; • Conte um FTR para cada ILF mantido pelo processo elementar da EO; • Conte apenas um FTR para cada ILF que é tanto mantido quanto lido pela EO.

Tipos de Elementos de Dados

1 - 5 6 - 19 >= 20 < 2 Baixo Baixo Médio

2 - 3 Baixo Médio Alto Tipos de Arquivos


Tabela 2.4 – Matriz complexidade para EOs [Garmus-01]

As seguintes regras do IFPUG se aplicam a contagem de DETs para EQs:

• Conte um DET para cada campo não repetível, reconhecido pelo usuário, que entra na fronteira da aplicação e é requerido para especificar o Quê, Quando, e/ou Como dados devem ser recuperados e/ou gerados pelo processo elementar;

• Conte um DET para cada campo ou atributo não repetível, reconhecido pelo usuário, que sai da fronteira da aplicação;

• Se um DET tanto entra quanto sai da fronteira, conte ele apenas uma vez para o processo elementar;


• Conte um DET para a capacidade de especificar a ação a ser executada pela EQ ainda que existam múltiplos métodos de invocar o mesmo processo lógico (ex.: botão de OK, teclas de função, clique de mouse).

• Não conte marcas de paginação ou geradas pelo sistema, incluindo números de página, informação de posicionamento (linha x de y), comandos de paginação (prévio, próximo, setas), ou campos de data / hora (gerados pelo sistema);

• Não conte literais, incluindo títulos de relatórios, IDs de tela, cabeçalhos de colunas, e títulos de campo;

• Conte um DET para um campo lógico que é armazenado fisicamente separado em múltiplos campos, mas é requerido pelo usuário como uma única peça de informação;



• Conte um DET para cada tipo de rótulo e cada tipo de equivalente numérico em um display gráfico (ex.: um gráfico de pizza pode ter dois DETs, um para a categoria e um para a percentagem aplicada. Um gráfico pode ser uma EQ se não existir nenhum cálculo quando o gráfico for gerado; isto é, a porcentagem é lida de dados armazenados);

• Conte um DET para informação de texto que pode consistir de uma única palavra, uma sentença, um parágrafo, ou muitos parágrafos.

As seguintes regras do IFPUG se aplicam a contagem de FTRs para EQs:

• Conte um FTR para cada ILF ou EIF lido durante o processamento da EQ;


1 Baixo Baixo Médio 2 - 3 Baixo Médio Alto

Tipos de Arquivos


Tabela 2.5 – Matriz complexidade para EQs [Garmus-01]

2.4.2.6 Calculando o Contador de Pontos de Função Não Ajustados (UFC)

Cada tipo de função (ILF, EIF, EI, EO, EQ) é avaliado, recebendo complexidade Baixa,

Média ou Alta, utilizando o método descrito anteriormente. A seguinte tabela (Tabela 2.6

[Garmus-01]) do IFPUG resume o número de pontos de função não ajustados atribuídos a

cada função.

Níveis das Funções Componentes Baixa Média Alta

ILF x 7 x 10 x 15 EIF x 5 x 7 x 10 EI x 3 x 4 x 6 EO x 4 x 5 x 7 EQ x 3 x 4 x 6

Tabela 2.6 – Pesos Atribuídos por Complexidade [Garmus-01]

Cada contagem é multiplicada por seu correspondente peso por complexidade e os

resultados são somados para prover o UFC.



2.4.2.7 Calculando o Fator de Ajuste (VAF)

A funcionalidade disponibilizada por sistemas de informação inclui fatores gerais

pervasivos que não são suficientemente representados pelas funções transacionais e de

dados discutidas previamente. A técnica de pontos de função prevê o uso de um fator de

ajuste (VAF), que é calculado com base em 14 características gerais do sistema (ver Tabela

2.7 [Garmus-01]). O VAF é multiplicado pelo UFC, gerando a contagem ajustada de pontos

de função de uma aplicação. Embora o cálculo de UFC seja largamente adotado no mundo

hoje, o mesmo não se pode dizer do VAF. Muitos usuários decidem não usar o VAF e

consideram o UFC como sendo a contagem final de pontos de função, ou utilizam outros

fatores de ajuste (notadamente COCOMO). Isto acontece principalmente pelo grau de

subjetividade que as a análise dos GSCs insere, bem como pelo fato dos mesmos se

relacionarem melhor com o ambiente de mainframe, pelo fato que estes guias não são

atualizados há anos. Consequentemente estes valores não são realistas. No entanto, dados

da indústria têm sido calculados usando estes guias, o que leva a manter os mesmos para

permitir a retrocompatibilidade.

Característica Geral do Sistema Descrição GSC1 Comunicação de Dados GSC2 Processamento de Dados Distribuídos GSC3 Performance GSC4 Configuração do Equipamento GSC5 Taxa de Transações GSC6 Entrada de Dados On-line GSC7 Interface Com o Usuário GSC8 Atualização On-line GSC9 Processamento Complexo GSC10 Reusabilidade GSC11 Facilidade de Implantação GSC12 Facilidade Operacional GSC13 Múltiplos Locais GSC14 Facilidade de Manutenção (Flexibilidade)

Tabela 2.7 – Características Gerais do Sistema [Garmus-01]



As 14 características gerais do sistema (GSCs) irão ser avaliadas independentemente e

recebem um único valor: o nível de influência (DI). Cada característica tem descrições

associadas que ajudam a determinar o DI de cada característica. O DI de cada característica

varia em uma escala de 0 (nenhuma influência) a 5 (essencial). O IFPUG provê guias,

detalhados no Apêndice A, para atribuição dos DIs.

O VAF é então calculado como:

VAF = 0,65 + 0,01 * (SUM( GSCi ))

O VAF varia de 0,65 (se todos os GSCi tiverem valor 0) a 1,35 (se todos os GSCi tiverem

valor 5). Ou seja, influenciam a contagem em +- 35%.

2.4.2.8 Calculando Pontos de Função Ajustados

De acordo com o tipo de projeto, será escolhido o tipo de contagem a ser utilizada. Como

visto anteriormente, a contagem pode ser para um projeto de desenvolvimento, um projeto de

melhoria (manutenção) ou para uma aplicação pronta.

2.4.2.8.1 Calculando Pontos de Função em Projetos de Desenvolvimento

Uma contagem de pontos de função para um projeto de desenvolvimento consiste de três

componentes de funcionalidade:

1. Contagem de pontos de função não ajustados da aplicação, consistindo de EIs,

EOs, EQs, ILFs, e EIFs;

2. Contagem de pontos de função não ajustados para as funcionalidades de

conversão de dados que serão desenvolvidas para transferir dados nos novos ILFs;

3. Valor do fator de ajuste da aplicação;

A seguinte fórmula é usada para calcular a contagem de pontos de função do projeto de

desenvolvimento:

DFP = (UFP + CFP) * VAF Onde

• DPF é a contagem de pontos de função do projeto de desenvolvimento;

• UFP é a contagem de pontos de função não ajustada;

• CFP é o número de pontos de função incluídos pela conversão de dados;

• VAF é o valor do fator de ajuste.



2.4.2.8.2 Calculando Pontos de Função em Projetos de Melhoria (Manutenção)

Uma contagem de pontos de função para um projeto de melhoria também consiste de três

componentes de funcionalidade, mas eles são diferentes:


EOs, EQs, ILFs, e EIFs que são:

• Adicionados pelo projeto de melhoria (funções que não existem previamente)

• Alteradas pelo projeto de melhoria (funções que existiam previamente mas

agora têm campos diferentes, FTRs, ou requerem processamento diferente)

• Excluídas pelo projeto de melhoria (funções que foram excluídas da aplicação).

2. Contagem de pontos de função não ajustados para as funcionalidades de

conversão de dados que serão desenvolvidas para transferir dados nos novos ILFs;

3. Dois valores de fatores de ajuste da aplicação (pode haver um VAF anterior à

manutenção e um novo VAF posterior à manutenção, dependendo da manutenção

realizada);

A seguinte fórmula é usada para calcular a contagem de pontos de função do projeto de

melhoria:

EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB) Onde

• EFP é a contagem de pontos de função do projeto de melhoria;

• ADD é a contagem de pontos de função não ajustada das funcionalidades a serem

adicionadas pelo projeto de melhoria;

• CHGA é a contagem de pontos de função não ajustada das funcionalidades

modificadas pelo projeto de melhoria (este componente reflete o valor das funções

depois que as modificações ocorreram, não apenas os campos adicionados pela

modificação; um erro típico é contar apenas DETs e FTRs ou RETs alterados, mas

tudo sobre a função deve ser contabilizada para considerar o esforço envolvido

com o teste das funcionalidades existentes assim como das alteradas);

• CFP é o número de pontos de função incluídos pela conversão de dados;

• VAFA é o valor do fator de ajuste da aplicação depois do projeto de melhoria;

• DEL é a contagem de pontos de função não ajustada das funcionalidades excluídas

pelo projeto de melhoria;

• CHGA é o número de pontos de função incluídos pela conversão de dados;

• VAFB é o valor do fator de ajuste da aplicação antes do projeto de melhoria;



2.4.2.8.3 Calculando Pontos de Função Para Aplicações Prontas

Uma contagem de pontos de função para uma aplicação pronta consiste de dois

componentes de funcionalidade (esforço para funcionalidades de conversão não é incluído na

contagem porque ele é parte do esforço de desenvolvimento e não faz parte da aplicação

instalada):


EOs, EQs, ILFs, e EIFs

2. Valor do fator de ajuste da aplicação;

Existem dois momentos diferentes em que devemos fazer uma contagem de pontos de

função de uma aplicação:

1. Quando a aplicação é inicialmente entregue;

2. Quando um projeto de melhoria muda o valor das funcionalidades da aplicação;

Estas variações são refletidas em duas diferentes fórmulas de contagem:

2.4.2.8.3.1 Cálculo de Pontos de Função de Aplicação Implementada

A seguinte fórmula é usada para calcular a contagem de pontos de função da aplicação

implementada:

AFP = ADD * VAF

Onde

• AFP é a contagem de pontos de função da aplicação implementada;

• ADD é a contagem de pontos de função não ajustada das funcionalidades

implementadas pelo projeto de desenvolvimento;

• VAF é o valor do fator de ajuste;



2.4.2.8.3.2 Cálculo de Pontos de Função de Aplicação Depois de Uma Melhoria

A seguinte fórmula é usada para calcular a contagem de pontos de função da aplicação

depois de uma melhoria:

AFP = [(UFPB + ADD + CHGA) – (CHGB + DEL)] * VAFA

Onde

• AFP é a contagem de pontos de função da aplicação;

• UFPB é a contagem de pontos de função não ajustada da aplicação antes do

projeto de melhoria;

• ADD é a contagem de pontos de função não ajustada das funcionalidades

adicionadas pelo projeto de melhoria;

• CHGA é a contagem de pontos de função não ajustada das funcionalidades

alteradas pelo projeto de melhoria (este componente reflete o valor de pontos de

função depois da mudança);

• CHGB é a contagem de pontos de função não ajustada das funcionalidades

alteradas pelo projeto de melhoria antes da mudança;

• DEL é a contagem de pontos de função não ajustada das funcionalidades excluídas

pelo projeto de melhoria;

• VAFA é o valor do fator de ajuste da aplicação depois do projeto de melhoria;

2.4.2.9 Considerações Sobre Pontos de Função

A contagem de Pontos de Função tem muitas características positivas, incluindo:

1. Padronização da abordagem – existe um conjunto de regras compreensivas que

podem ser seguidas para produzir estimativas consistentes de tamanho de projeto.

2. É verificável – você pode ter dois analistas trabalhando sob um conjunto comum de

premissas que obtenham a mesma estimativa.

3. É objetiva – você pode apontar uma linha e dizer “Esta parte da estimativa está

incorreta"

4. Considera as diferenças entre a estimativa inicial de um novo software e

estimativas para mudanças em softwares existentes.

5. Acurácia – erros de estimativa são tratados pela abstração da contagem de

características em generalizações de complexidade.

6. A estimativa é construída a partir do ponto de vista dos usuários, facilitando o

entendimento e comunicação com os mesmos.



7. É independente de plataforma e configurável.

8. Podem ser usados para estabelecer um inventário de todas as transações e

arquivos de um projeto ou aplicação. Este inventário pode ser usado como uma

forma de avaliação de uma aplicação. Se um inventário é usado para um projeto de

desenvolvimento ou projeto de melhoria, então este inventário pode ser usado para

ajudar a manter o escopo controlado e controlar o crescimento do projeto. Mais

importante, este inventário ajuda a entender a magnitude do problema.

9. Pode ajudar organizações a entender o custo unitário de uma aplicação de

software ou projeto. Uma vez que o custo unitário é entendido, linguagens,

plataformas, ferramentas podem ser comparadas quantitativamente ao invés de

subjetivamente. Este tipo de análise é mais fácil de entender que informações

técnicas. Isto é, um usuário não técnico pode facilmente entender Pontos de

Função.

2.4.2.10 Técnica Holandesa – NESMA

Contagem de pontos de função requer a inspeção linha a linha da especificação de

requisitos e literalmente a contagem de cada entrada, saída, arquivo, e assim por diante. Isto

pode consumir muito tempo. Especialistas em estimativa têm proposto uma gama de

abordagens simplificadas para a contagem de pontos de função.

A NESMA (Netherlands Software Metrics Users Association) propõe técnicas para

contagem de pontos de função logo no início do projeto. Esta associação foi fundada em

1989 como o NEFPUG (Netherlands Function Point Users Group). Depois do IFPUG, esta

organização Holandesa foi um dos primeiros grupos de usuários FPA no mundo.

Correntemente tem aproximadamente 120 membros (empresas), e é o maior grupo de

usuários FPA na Europa (incluindo a Rússia). A NESMA mantém seu próprio Manual de

Práticas de Contagem (CPM), que é compatível com o CPM 4.2 do IFPUG, servindo como

um complemento ao mesmo.

A NESMA [NESMA-07] define três tipos de contagem de pontos de função:

• Detalhada

• Estimada

• Indicativa



A contagem Detalhada é realizada da mesma forma que a contagem do IFPUG, exceto

que o ajuste pelas características gerais do sistema não é usada. As contagens Estimada e

Indicativa foram desenvolvidas para permitir a contagem de pontos de função no início do

ciclo de vida de projetos de SW. A contagem Estimada usa valores default para a valoração

das complexidades. A contagem Indicativa usa o apenas o número de objetos de dados (ILF

e EIF) e assume valores médios para as transações associadas. Especificamente, assume

que para cada ILF existem aproximadamente três EIs (para adicionar, alterar, e excluir

informações no ILF), dois EOs, e um EQ; e assume que para cada EIF existem

aproximadamente um EO e um EQ. Usando os pesos do IFPUG temos

• Um ILF = 3 * 4 + 2 * 5 + 1 * 4 + 1 * 10 = 36 • Um ELF = 0 * 4 + 1 * 5 + 1 * 4 + 1 * 7 = 16

Os valores oficiais da NESMA foram definidos como sendo 35 e 15, respectivamente.

Os três tipos de contagem da NESMA estão sumarizados na Tabela 2.8 [NESMA-07].

Contagem Detalhada (idêntica à IFPUG FPA) • Conte as ocorrências de todos os tipos de objetos (EI, EO, EQ, ILF, EIF) • Valore a complexidade de cada ocorrência • Calcule o total de pontos de função não ajustados Contagem Estimada • Conte as ocorrências de todos os tipos de objetos (EI, EO, EQ, ILF, EIF) • Valore a complexidade de cada objeto de dados (ILF, EIF) como Baixa • Valore a complexidade de cada objeto de transação (EI, EO, EQ) como Média • Calcule o total de pontos de função não ajustados Contagem Indicativa • Conte apenas as ocorrências de objetos de dados (ILF, EIF) • Calcule o total de pontos de função não ajustados usando Tamanho (UFP) = 35 * (# ILFs) + 15 * (# EIFs)

Tabela 2.8 – NESMA - Técnicas de Contagem de Pontos de Função [NESMA-07]

A NESMA comparou a exatidão destas três técnicas de contagem usando um banco de

dados de 100 projetos. Ela observou uma grande afinidade entre as contagens detalhadas e

estimadas. As contagens indicativas e detalhadas também eram correlatas, mas mostraram

mais dispersão, como seria de se esperar.



Com base na Figura 2.8, vemos que a diferença obtida entre a detalhada e a estimada é

pequena (alguns autores citam que gira em torno de 10% a 15%) [NESMA-07].

Figura 2.8 – NESMA – Contagem Estimada x Contagem Detalhada [NESMA-07]

Com base na Figura 2.9, vemos que a diferença obtida entre a detalhada e a indicativa

pode ser muito grande em alguns casos (até 50%). O uso desta contagem deve ser muito

cuidadoso, apenas para contagens de ordem de grandeza. A força deste tipo de contagem é

que se pode obter uma estimativa de ordem de grandeza muito rapidamente [NESMA-07].

Figura 2.9 – NESMA – Contagem Indicativa x Contagem Detalhada [NESMA-07]



2.4.2.11 Derivando Indicadores a Partir da Contagem de Pontos de Função

Diversas estimativas de ordens de grandeza associadas ao desenvolvimento de software

e ao tamanho do software podem ser obtidas a partir da contagem de pontos de função (FP).

Para isto podem ser usadas algumas “Rules of Thumb” expressas nas fórmulas sugeridas por

Capers Jones [Jones-07]:

• Linhas de Código: FP * SLOC por FP (em Java 63 SLOC por FP)

• Linhas de Documentação: FP ^ 1,15

• Quantitativo de Pessoal: FP / 150

• Duração do Projeto: FP ^ 0,4

• Esforço em Horas: FP ^ 0,4 * FP / 150

• Quantitativo de Casos de Teste: FP ^ 1,2

• Número de Defeitos Potenciais: FP ^ 1,25 * 0,35 (% de defeitos remanescente depois de revisão de projeto) * 0,4 (% de defeitos remanescente depois de revisão de código)

Simples “Rules of Thumb” não são nunca muito acuradas, mas continuam a ser muito

populares. As apresentadas acima são todas derivadas do uso da métrica de pontos de

função, mas isto não significa que “Rules of Thumb” sejam um substituto para técnicas

formais de estimativas. Elas servem como um suporte para uma rápida estimativa de ordem

de grandeza, podendo amparar tomadas de decisão cedo no projeto.

2.4.3 COCOMO (COnstructive COst MOdel)

Em 1981, Barry Boehm projetou COCOMO (Constructive Cost Model) para possibilitar a

estimativa do número de homens mês que iriam ser necessários para desenvolver um

produto de software. A técnica foi derivada usando dados de um estudo de cerca de 60

projetos da TRW, uma empresa de consultoria Californiana. O estudo examinou programas

variando em tamanho de 2.000 a 100.000 linhas de código, e linguagens de programação

variando de Assembler a PL/I. COCOMO se baseia em entradas relacionadas ao tamanho do

sistema e um número de direcionadores de custo que afetam produtividade. O COCOMO

original foi publicado em 1981. Boehm e seus colegas definiram depois uma versão

atualizada chamada COCOMO II, lançado em 2000, que leva em consideração as recentes

mudanças da Tecnologia da Informação.



2.4.3.1 COCOMO Original

O COCOMO original é uma coleção de três modelos: um modelo Básico que é aplicado

cedo no projeto, um modelo Intermediário que é aplicado depois que os requisitos são

especificados e um modelo Avançado que é aplicado depois que a fase de projeto está

completa. Todos os três modelos tomam a forma:

E = a * Sb * EAF

Onde E é o esforço em pessoas-mês, S é o tamanho medido em milhares de linhas de

código (KLOC), e EAF é um fator de ajuste do esforço (igual a 1 no modelo Básico). Os

fatores a e b dependem do modo de desenvolvimento.

Boehm definiu três modos de desenvolvimento:

1. Modo Orgânico – projetos relativamente simples nos quais times pequenos

trabalham em um conjunto de requisitos informais;

2. Modo Semi-destacado – um projeto intermediário no qual times mistos precisam

trabalhar em um conjunto limitado de requisitos;

3. Modo Embutido – um projeto que deve operar um conjunto rígido de restrições.

2.4.3.1.1 Básico

O modelo COCOMO básico computa o esforço como uma função do tamanho do

programa. A equação básica do COCOMO é:

E = a * KLOCb

Os fatores a e b para este modelo são mostrados na Tabela 2.9 [Boehm-00].

Modo a b

Orgânico 2,4 1,05

Semi-destacado 3,0 1,12

Embutido 3,6 1,20

Tabela 2.9 – Esforço para os três modos do COCOMO Básico [Boehm-00]

2.4.3.1.2 Intermediário

O modelo COCOMO Intermediário computa esforço como uma função do tamanho do

programa e um conjunto de direcionadores de custo. A equação para o COCOMO

Intermediário é:

E = a * KLOCb * EAF



Os fatores a e b para este modelo são mostrados na Tabela 2.10 [Boehm-00].

Modo a b

Orgânico 3,2 1,05

Semi-destacado 3,0 1,12

Embutido 2,8 1,20

Tabela 2.10 – Parâmetros de esforço para os três modos de COCOMO Intermediário [Boehm-00]

O fator de ajuste de esforço (EAF) é calculado usando 15 direcionadores de custo. Os

direcionadores de custo são agrupados em 4 categorias: Produto, Computador, Pessoal e

Projeto. Cada direcionador de custo é estimado com base em uma escala ordinal de seis

pontos, variando de baixa para alta importância. Baseado na estimativa, um multiplicador de

esforço é determinado usando a Tabela 2.11 [Boehm-00]. O produto de todos os

multiplicadores de esforço é o EAF.

Classificação Direcionador

de Custo Descrição Muito Baixo Baixo Nominal Alto Muito

Alto Extra Alto

Produto RELY Disponibilidade requerida do software 0,75 0,88 1 1,15 1,4 - DATA Tamanho do banco de dados - 0,94 1 1,08 1,16 - CPLX Complexidade do produto 0,7 0,85 1 1,15 1,3 1,65

Computador TIME Restrição de tempo de execução - - 1 1,11 1,3 1,66 STOR Restrição de memória principal - - 1 1,06 1,21 1,56 VIRT Volatilidade da máquina virtual - 0,87 1 1,15 1,3 -

TURN Velocidade de processamento do computador - 0,87 1 1,07 1,15 -

Pessoal ACAP Capacidade do analista 1,46 1,19 1 0,86 0,71 - AEXP Experiência na aplicação 1,29 1,13 1 0,91 0,82 - PCAP Capacidade do programador 1,42 1,17 1 0,86 0,7 - VEXP Experiência na máquina virtual 1,21 1,1 1 0,9 - - LEXP Experiência na linguagem 1,14 1,07 1 0,95 - -

Projeto

MODP Práticas de programação modernas 1,24 1,1 1 0,91 0,82 -

TOOL Ferramentas de Software 1,24 1,1 1 0,91 0,83 -

SCED Cronograma de desenvolvimento 1,23 1,08 1 1,04 1,1 -

Tabela 2.11 – Multiplicadores de Esforço para desenvolvimento de software [Boehm-00]



2.4.3.1.3 Avançado

O modelo COCOMO avançado computa esforço como uma função do tamanho do

programa e um conjunto de direcionadores de custo valorados de acordo com cada fase do

ciclo de vida do software. O modelo avançado aplica o modelo Intermediário no nível de

componente, e então uma abordagem baseada na fase é usada para consolidar a estimativa.

As 4 fases usadas no modelo COCOMO avançado são: planejamento de requisitos e

projeto de produto (RPD), projeto detalhado (DD), teste unitário e de código (CUT), e

integração e teste (IT). Cada direcionador de custo é detalhado por fase como no exemplo

mostrado na Tabela 2.12 [Boehm-00].

Direcionador de Custo Classificação RPD DD CUT IT

Muito Baixo 1,80 1,35 1,35 1,50

Baixo 0,85 0,85 0,85 1,20

Nominal 1,00 1,00 1,00 1,00

Alto 0,75 0,90 0,90 0,85

ACAP

Muito Alto 0,55 0,75 0,75 0,70

Tabela 2.12 – Multiplicador de esforço para Capacidade do Analista em COCOMO Avançado [Boehm-00]

Estimativas feitas para cada módulo são combinadas em subsistemas e eventualmente

em uma estimativa total do projeto. Usando os direcionadores de custo detalhados, uma

estimativa é feita para cada fase no ciclo de vida.



2.4.3.2 COCOMO II

Devido à idade dos projetos que embasaram o modelo anterior, assim como sua

incapacidade de lidar com ciclos iterativos e com a utilização de componentes Commercial-

Off-The-Shelf (COTS)4, o COCOMO original é atualmente considerado obsoleto, tendo sido

substituído pela sua versão II, publicada inicialmente em 2000. Esta versão foi definida

também por Barry Boehm, desta vez na Universidade do Sul da Califórnia (USC – University

of Southern California), trabalhando em conjunto com uma equipe de cientistas e

pesquisadores.

COCOMO II provê suporte atualizado a software orientado a objetos, software criado

usando modelos de desenvolvimento em espiral ou incremental e software criado usando

componentes de prateleira. COCOMO II inclui o modelo Application Composition (para

esforços de prototipagem) e os modelos mais detalhados Early Design e Post-Architecture

(para as partes subseqüentes do ciclo de vida). A Figura 2.10 mostra como estes modelos se

inserem no Cone da Incerteza citado na Introdução [Boehm-00].

Figura 2.10 – COCOMO II – Aplicação de Modelos no Cone da Incerteza [Boehm-00]

4 Comercial-off-the-shelf (COTS) são componentes de software prontos para utilização, de terceiros, comercialmente disponíveis, e que se tornam importantes durante a criação do novo software, devendo ser utilizados referencialmente durante a fase de pré-desenvolvimento do produto (software) [Boehm-00].



O COCOMO II, assim como o seu predecessor, busca medir esforço, prazo, tamanho e

custo, necessários para o desenvolvimento de software, desde que se tenha, como premissa,

a dimensão do mesmo. Para o cálculo do custo deve-se conhecer o prazo e equipe de

trabalho, para então chegar ao valor, sendo que para definir o tamanho do programa, torna-

se necessário que se caracterize que medida será adotada (linhas de código ou pontos de

função).

A definição inicial do COCOMO II vem sendo refinada com pesquisas e dados adicionais

sobre projetos que são coletados e analisados pela equipe da USC.

2.4.3.2.1 O Modelo Application Composition

O modelo Application Composition é usado em prototipagem para resolver questões de

potencial alto risco tais como interfaces de usuário, interação software/sistema, performance,

ou maturidade da tecnologia. Pontos de Aplicação são usados para estimar tamanho, ao

invés da tradicional métrica de linhas de código (LOC) ou da métrica de Pontos de Função.

São usados quando o desenvolvimento é feito em linguagens de 4ª geração ou similares (ex.:

Access, Delphi, Natural, Powerbuilder, etc.).

Uma estimativa inicial de tamanho é determinada pela contagem do número de telas,

relatórios e módulos de programas (que necessitam ser desenvolvidos para suplementar o

código do banco de dados) que irão ser usados na aplicação. Cada um destes objetos é

classificado como simples, médio ou difícil usando os guias da Tabela 2.13 e Tabela 2.14

[Boehm-00].

Para Telas

Número e fonte das tabelas de dados

Número de visões5 contidasTotal < 4

(< 2 servidor6

< 3 cliente7)

Total < 8 (2 - 3 servidor3 – 5 cliente)

Total >= 8 (> 3 servidor > 5 cliente)

< 3 Simples Simples Médio

3 - 7 Simples Médio Difícil

>= 8 Médio Difícil Difícil

Tabela 2.13 – Níveis de complexidade de pontos de aplicação para telas [Boehm-00] 5 Se a quantidade de dados é grande, os dados têm de ser divididos em diversos grupos, chamados visões. Visões são tipicamente apresentadas como uma seqüência ou rede de telas.

6 Número de tabelas de dados em servidores (mainframe ou equivalente) usado em conjunto com as Telas ou Relatórios.

7 Número de tabelas de dados em clientes (estações de trabalho pessoais) usado em conjunto com as Telas ou Relatórios.



Para Relatórios

Número e fonte das tabelas de dados

Número de seções8 contidasTotal < 4

(< 2 servidor< 3 cliente)

Total < 8 (2 - 3 servidor3 – 5 cliente)

Total >= 8 (> 3 servidor > 5 cliente)

0 ou 1 Simples Simples Médio

2 - 3 Simples Médio Difícil

>= 4 Médio Difícil Difícil

Tabela 2.14 – Níveis de complexidade de pontos de aplicação para relatórios [Boehm-00]

O número em cada célula é então pesado de acordo com a Tabela 2.15 [Boehm-00]. Os

pesos representam o esforço relativo requerido para implementar uma instância daquele nível

de complexidade.

Tipo de Objeto Simples Médio Difícil

Tela 1 2 3

Relatório 2 5 8

Componente 3GL (módulos de programas) - - 10

Tabela 2.15 – Pesos por complexidade para pontos de aplicação [Boehm-00]

As instâncias pesadas são somadas para prover um único valor de pontos de aplicação.

Reutilização é então levada em consideração. Assumindo que r% dos objetos irão ser

reusados de projetos prévios, o número de novos pontos de aplicação (NAP) é calculado:

NAP = (pontos de aplicação) * (100 – r) / 100

Uma taxa de produtividade é determinada usando a Tabela 2.16 [Boehm-00], que

considera a Experiência e Capacidade dos Desenvolvedores e a Maturidade e Capacidade

em Ambientes de Software Integrados Suportados por Computador (ICASE - Integrated

Computer Aided Software Environment). Estes ambientes provêem construção de interfaces

gráficas de usuário, ferramentas de desenvolvimento de software, e componentes de

aplicação e de composição de infra-estrutura. Exemplo: Produtividade para ICASE Muito

Baixa e Experiência Muito Alta = (50 + 4) / 2 = 27 (média dos dois valores para Experiência e

Maturidade ICASE).

8 Porções do relatório que tem uma altura específica e podem conter objetos de relatório tais como linhas, retângulos, imagens, ou campos de texto.



Experiência e capacidade dos desenvolvedores Muito Baixa Baixa Nominal Alta Muito Alta

Maturidade e Capacidade ICASE Muito Baixa Baixa Nominal Alta Muito Alta

PROD 4 7 13 25 50

Tabela 2.16 – Taxas de produtividade média baseadas na experiência dos desenvolvedores e a maturidade/capacidade ICASE [Boehm-00]

Esforço em pessoas/mês pode então ser estimado usando a seguinte equação:

E = NOP / PROD

2.4.3.2.2 O Modelo Early Design

O modelo Early Design é usado para avaliar arquiteturas alternativas de sistema/software

e conceitos de operação. Uma contagem de pontos de pontos de função não ajustados (UFC)

é usada para estimar tamanho. Este valor é convertido para SLOC usando tabelas tais como

a Tabela 2.17 [Stutzke-05] [Boehm-00].

Linguagem Mínimo (Desvio padrão -1)

Moda (Valor mais comum)

Máximo (Desvio padrão +1)

C 60 128 170 C++ 40 55 140 C# 40 55 80 Cobol 65 107 150 Java 40 55 80 Perl 10 20 30 SQL 7 13 15 MS Visual Basic 15 32 41

Tabela 2.17 – Quantidade de linhas de código fonte por ponto de função por linguagem [Stutzke-05] [Boehm-00]

Desta forma se você tem um sistema de 284 pontos de função para implementar em Java,

você poderia variar de 40 a 80 SLOC por ponto de função, multiplicando este valor por 284

para chegar em uma estimativa de tamanho de 11.360 a 22.270 SLOC, com um valor

esperado de 55 vezes 284, ou 15.675 pontos de função. Para evitar um falso senso de

acurácia, você pode simplificar estes números para 11.000 a 23.000 SLOC, com um valor

esperado de 16.000 SLOC. Estes valores podem ser utilizados conforme a Figura 2.11

[ISBSG-07] indica, devendo os valores serem considerados de acordo com as características

do projeto.



Figura 2.11 – Aplicação Valores SLOC de Acordo com Características de Projeto [ISBSG-07]

A equação do modelo Early Design é:

E = a * KSLOCb * EAF

Onde E é o esforço em pessoas-mês, a é uma constante, definida como 2,94 e b é

calculado como:

b = 1,01 + 0,01 * SUM(SFi)

Onde SF é o conjunto dos 5 fatores de escala mostrados na Tabela 2.18 [Boehm-00].

Fator de Escala (SF) Muito Baixo Baixo Nominal Alto Muito Alto Extra Alto

PREC Reflete a experiência prévia da

organização com este tipo de projeto

Totalmente sem

precedentes

Praticamente sem

precedentes

Poucos precedentes

Alguma familiaridade

Muito familiar

Totalmente familiar

FLEX Reflete o nível de flexibilidade no

processo de desenvolvimento.

Rigor e inflexibilidade exagerados

Alto grau de rigor e

inflexibilidade

Rigor moderado

Alguma flexibilidade, com padrão

Boa flexibilidade, com padrão

Metas gerais,

dentro de padrões normais

RESL Reflete a extensão da análise de riscos realizada.

Especificações são apenas

20% do necessário

40% 60% 75% 90% 100% sob domínio

TEAM Reflete quão bem o time de

desenvolvimento se conhece e trabalha

em conjunto.

Interações muito difíceis

Algumas dificuldades de interação

Interações cooperativas

básicas

Boa interação

Altamente cooperativa

Interação total

PMAT Reflete a maturidade do processo de

desenvolvimento da organização.

CMM 1 (baixo) CMM 1 (alto) CMM 2 CMM 3 CMM 4 CMM 5

Tabela 2.18 – Fatores de Escala COCOMO II [Boehm-00]

Estimativa (Mediana)

Mais Baixa Mais Alta

Projetos neste limite de variação podem refletir um contexto de mais baixo risco, por exemplo: •Time experiente •Gerente de Projeto experiente •Tecnologia conhecida •Cliente comprometido •Entrega em apenas um site •Requerimentos detalhados acordados

Projetos neste limite de variação podem refletir um contexto de mais alto risco, por exemplo: •Time inexperiente •Gerente de Projeto inexperiente •Tecnologia nova •Cliente descomprometido •Entrega em diversos sites •Requerimentos vagos



A valoração dos fatores de escala é realizada atribuindo os valores 0 (Muito Baixo), 1

(Baixo), 2 (Nominal), 3 (Alto), 4 (Muito Alto) e 5 (Extra Alto).

A técnica COCOMO II foi originalmente calibrada com dados de 161 projetos. Os mesmos

foram selecionados entre 2000 projetos candidatos. Para cada um dos 161 projetos

escolhidos foram realizadas entrevistas e visitas, a fim de garantir a consistência das

definições e suposições da técnica. Com base nesta calibragem, Boehm propos que o

coeficiente a deveria ser 2,94. O tamanho do sistema é expresso em KSLOC, que é o número

de milhares de linhas de código fonte.

O expoente b reflete o aumento de esforço requerido quando o tamanho do projeto

aumenta. Ele não é fixo para diferentes tipos de Sistemas, como em COCOMO 81, mas pode

variar de 1,01 a 1,26 dependendo da experiência prévia da organização com este tipo de

projeto, a flexibilidade do processo de desenvolvimento, a extensão da análise de riscos

realizada, a coesão do time de desenvolvimento e a maturidade do processo de

desenvolvimento da organização. Isto reflete os níveis de complexidade do projeto. Enquanto

os projetos vão se tornando mais complexos, os efeitos de aumentar o tamanho do sistema

se tornam mais significativos. Contudo, boas práticas e procedimentos organizacionais

podem controlar esta “deseconomia de escala”. Isto é reconhecido em COCOMO II, onde o

intervalo de valores para o expoente b é contínuo ao invés de discreto.

A partir do valor de b, podem-se capturar os efeitos do projeto e chegar às seguintes

premissas:

b < 1,0: O projeto apresenta economia de escala. Se porventura o tamanho do produto

dobra, o esforço relativo ao projeto é menor que o dobro. A produtividade do projeto aumenta

à medida que aumenta o tamanho do produto. Podem-se alcançar algumas economias de

escala do projeto com ferramentas de projeto específicas. Para projetos pequenos, fixar

custos de saída, tais como reuniões periódicas e ainda relatórios administrativos, são a rigor

uma fonte de economia.

b = 1,0: As economias e gastos estão em um nível de equilíbrio. Este modelo linear é

utilizado a rigor para a estimativa de custo de projetos pequenos.



b > 1,0: O projeto apresenta gastos de escala. Isto se deve normalmente a dois fatores

principais: o crescimento do gasto em comunicações e o gasto em crescimento da integração

de um grande sistema. Os projetos maiores alocam mais recursos humanos, e

conseqüentemente uma maior comunicação e iteração interpessoal produzindo despesas.

Integrar um produto pequeno como parte de um maior não requer apenas esforço de

desenvolver o produto pequeno como também a despesa adicional de esforço para projetar,

manter, integrar e testar suas interfaces com o resto do produto.

O expoente b é obtido através dos fatores de escala. A seleção dos fatores de escala é

embasada na razão de que são recursos significativos de variação exponencial de esforço ou

variação da produtividade do projeto. Cada fator tem um intervalo de níveis de valores que

vão desde Muito Baixo até Extra Alto, conforme é apresentado na Tabela 2.18. Cada nível de

valores possui um peso, SF, e o valor específico do peso é chamado Fator de Escala. Um

fator de escala de um projeto é calculado realizando o somatório de todos os fatores e é

utilizado para determinar o expoente b.

A calibragem da técnica para um ambiente específico consiste no ajuste da constante a,

que indica o percentual de reutilização de código. O objetivo da calibragem é obter a

distribuição da produtividade e atividade de desenvolvimento para um ambiente específico.

Embora o COCOMO II possa ser executado com os parâmetros nominais, sua correta

utilização pressupõe a calibragem para o ambiente-alvo. Com a calibragem em projetos do

mesmo ramo é possível modificar o valor das constantes das fórmulas padrões. Na ausência

de dados históricos disponíveis para o ambiente-alvo em questão, devem ser selecionados

projetos equivalentes para efetuar a calibração. Os dados históricos selecionados devem ser

validados antes de sua utilização, calculando os coeficientes calibrados e, posteriormente,

verificando se a diferença percentual (estimado – real)/estimado encontra-se compatível com

o nível de erro pretendido para as estimativas. Devido ao seu impacto exponencial, não é

recomendável calibrar a técnica quando houver menos de 10 projetos disponíveis para a

calibração [Boehm-00]. A calibragem é suportada por ferramentas de software, alimentadas

com dados históricos da organização.



O fator de ajuste de esforço (EAF) é calculado como na técnica original COCOMO,

usando os sete direcionadores de custo mostrados na Tabela 2.19 e Tabela 2.20 [Boehm-00].

O produto de todos os direcionadores de custo é o EAF. Os direcionadores de custo Early

Design são obtidos pela combinação dos direcionadores Post-Architecture mostrados na

Tabela 2.21 [Boehm-00]. O detalhamento dos direcionadores de custo do COCOMO II pode

ser consultado no Apêndice B.

Direcionador de Custo Descrição Direcionador de Custo Post-

Architecture Combinado

RCPX Confiabilidade e complexidade do produto RELY, DATA, CPLX, DOCU

RUSE Reutilização requerida RUSE

PDIF Dificuldade da plataforma TIME, STOR, PVOL

PERS Capacidade do pessoal ACAP, PCAP, PCON

PREX Experiência do pessoal AEXP, PEXP, LTEX

FCIL Facilidades (uso de ferramentas de software e

desenvolvimento multi-local) TOOL, SITE

SCED Cronograma (restrição de cronograma imposta ao

time de projeto) SCED

Tabela 2.19 – Direcionadores de Custo Early Design [Boehm-00]

Fator de Escala

Extra

Baixo

Muito

Baixo Baixo Normal Alto

Muito

Alto

Extra

Alto

RCPX Disponibilidade de produto e

complexidade 0,73 0,81 0,98 1 1,30 1,74 2,38

RUSE Reutilização requerida 0 0 0,95 1 1,07 1,15 1,24

PDIF Dificuldade da plataforma 0 0 0,87 1 1,29 1,81 2,61

PERS Capacidade do pessoal 2,12 1,62 1,26 1 0,83 0,63 0,50

PREX Experiência do pessoal 1,59 1,33 1,12 1 0,87 0,71 0,62

FCIL Facilidades 1,43 1,30 1,10 1 0,87 0,73 0,62

SCED Cronograma 0 1,42 1,14 1 1 1 0

Tabela 2.20 – Direcionadores de Custo Early Design [Boehm-00]



2.4.3.2.3 Modelo Post-Architecture

O modelo Post-Architecture é usado durante o desenvolvimento e manutenção atual de

um produto. Pontos de função ou LOC podem ser usados para estimar tamanho, com

modificadores para reutilização e manutenção de software. Boehm utiliza o conjunto de guias

proposto pelo Software Engineering Institute na contagem de linhas de código. O modelo

Post-Architecture inclui um conjunto de 17 direcionadores de custo e um conjunto de 5 fatores

determinando os componentes de equilíbrio de projetos. Os 5 fatores substituem os modos

de desenvolvimento (orgânico, semi-destacado, embutido) da técnica COCOMO original.

A equação do modelo Post-Architecture é:

E = a * KLOCb * EAF

Onde E é o esforço em pessoas-mês, a é definido como 2,94 e b é calculado como:

b = 1,01 + 0,01 * SUM(SFi)

onde SF é o conjunto dos 5 fatores de escala mostrados na Tabela 2.18 [Boehm-00].



O EAF é calculado usando os 17 direcionadores de custo mostrados na Tabela 2.21

[Boehm-00]. O produto de todos os direcionadores de custo é o EAF. O detalhamento dos

direcionadores de custo do COCOMO II pode ser consultado no Apêndice B.

Classificação Direcionador de Custo

Descrição

Muito Baixo

Baixo Nominal Alto Muito Alto

Extra Alto

Produto

RELY Confiabilidade requerida pelo software 0,82 0,92 1,00 1,10 1,26 -

DATA Tamanho do banco de dados - 0,90 1,00 1,14 1,28 -

CPLX Complexidade do produto 0,73 0,87 1,00 1,17 1,34 1,74

RUSE Reusabilidade requerida 0,95 1,00 1,07 1,15 1,24

DOCU Documentação (adequação da documentação às necessidades do ciclo de vida)

0,81 0,91 1,00 1,11 1,23 -

Plataforma

TIME Restrição de tempo de execução - - 1,00 1,11 1,29 1,63

STOR Restrição de memória principal - - 1,00 1,05 1,17 1,46

PVOL Volatilidade da plataforma - 0,87 1,00 1,15 1,30 -

Pessoal

ACAP Capacidade do analista 1,42 1,19 1,00 0,85 0,71 -

PCAP Capacidade do programador 1,34 1,15 1,00 0,88 0,76 -

PCON Continuidade do pessoal 1,29 1,12 1,00 0,90 0,81 -

AEXP Experiência na aplicação 1,22 1,10 1,00 0,88 0,81 -

PEXP Experiência na plataforma 1,19 1,09 1,00 0,91 0,85 -

LTEX Experiência com linguagem e ferramental 1,20 1,09 1,00 0,91 0,84

Projeto

TOOL Ferramentas de Software (sofisticação, maturidade e nível de integração com processos e métodos)

1,17 1,09 1,00 0,90 0,78 -

SITE Desenvolvimento multi-local 1,22 1,09 1,00 0,93 0,86 0,80

SCED Prazo requerido para o desenvolvimento 1,43 1,14 1,00 1,00 1,00 -

Tabela 2.21 – Direcionadores de custo Post-Architecture [Boehm-00]



Cada um dos direcionadores de custo e fatores de escala Post-Architecture influencia o

esforço total em diferentes níveis, conforme representado pela Figura 2.12 [McConnell-06].

As barras cinza mostram o potencial para aumentar o esforço total, e as barras azuis o

potencial para diminuir este esforço.

Figura 2.12 – Fatores COCOMO II Organizados por Influência no Esforço [McConnell-06]

Em verdade, os fatores de escala PMAT - Maturidade do Processo, PREC – Precedência,

RESL – Resolução de Riscos e Arquitetura, TEAM – Coesão do Time, e FLEX – Flexibilidade

do Desenvolvimento contribuem para a deseconomia de escala do software. Eles podem

afetar os projetos em diferentes níveis de acordo com o tamanho destes projetos. Logo os

níveis de influência no esforço calculado, dos fatores de escala na Figura 2.12 [McConnell-

06], são válidos para um projeto específico, pois os mesmos variarão muito de acordo com o

tamanho do projeto.

Uma análise dos 161 projetos que serviram de base para a criação da técnica COCOMO

II, feita por Bradford Clark [Clark-99], indica que uma mudança de um nível na maturidade do

processo resulta em uma redução média de 4% a 11% de esforço em projetos. Projetos

maiores obtêm os maiores ganhos. Clark aplicou esta análise nos 5 níveis de maturidade do

Software CMM. Ele especulou que a percentagem de redução em esforço não é uniforme

através de todos os níveis. Ele não pode determinar isto porque o universo de dados não

oferecia um nível de detalhe suficiente para permitir análise de melhoria entre níveis.



2.4.4 Técnica ISBSG

O International Software Benchmarking Standards Group (ISBSG) é uma organização sem

fins lucrativos que mantém e explora dois repositórios de métricas de software:

1. Desenvolvimento de Software e Melhoria 2. Manutenção de Software e Suporte

A missão do ISBSG é ajudar a melhorar o gerenciamento de recursos de TI, tanto

pelas corporações quanto pelo governo, através da provisão e exploração de repositórios

públicos de conhecimento em engenharia de software, os quais são padronizados,

verificados, atualizados e representativos de tecnologias correntes.

Os dados do repositório ISBSG podem ser usados para estimar métricas de projetos de

software usando três técnicas de macro-estimativas:

1. Estimativas usando equações 2. Estimativas usando comparação 3. Estimativas usando analogia

2.4.4.1 Estimando Usando Equações

O ISBSG desenvolveu uma técnica interessante e útil de computar esforço baseado em

três fatores: o tamanho de um projeto em pontos de função, o tipo de ambiente de

desenvolvimento, e o tamanho máximo do time de projeto. Esta técnica envolve o uso de

equações de regressão. Estas equações permitem a você calcular uma estimativa para uma

métrica particular de projeto tal como esforço ou duração, simplesmente inserindo o tamanho

calculado ou estimado do seu projeto na equação apropriada.

Esta técnica de estimativa é comumente usada para produzir estimativas indicativas

(aproximadas) cedo na vida de um projeto. Esta técnica não é suficientemente apurada para

produzir uma estimativa que poderia ser usada para propostas ou casos de negócios. Uma

estimativa indicativa pode ser usada para uma indicação inicial de se uma idéia de projeto é

exeqüível, ou quando você estiver com pouco tempo e sem informações detalhadas.



O ISBSG produziu conjuntos de equações de regressão usando os dados do repositório

ISBSG. As equações produzem uma estimativa em equipe por mês, assumindo 132 horas

focadas em projeto por membro da equipe por mês (isto é, excluindo férias, feriados, dias de

treinamento, encontros da empresa, e assim por diante). A fórmula Geral é uma fórmula de

uso geral para uso em todos os tipos de projetos e é baseado em dados calibrados de cerca

de 600 projetos. As outras categorias são calibradas com dados de 63 a 363 projetos.

Você pode usar estas equações para calcular as seguintes métricas de projeto:

1. Taxa de entrega do projeto (pessoas/hora por unidade de Ponto de Função) 2. Esforço (pessoas/hora) 3. Duração 4. Velocidade de entrega (unidades de Ponto de Função entregues por mês de

calendário)

Equações são providas para:

1. Plataforma, (Mainframe, Midrange, PC) 2. Tipo de Linguagem (3GL, 4GL & Gerador de Aplicação)

É fácil usar as equações ISBSG. Tendo selecionado as equações apropriadas das tabelas

providas, deve-se inserir o tamanho em Pontos de Função do seu projeto e o tamanho

máximo da equipe, para produzir uma estimativa.

2.4.4.1.1 Tipo de Projeto: Geral Pessoas/Mês = 0,512 * PontosDeFunção0,392 * TamanhoMáximoEquipe0,791

2.4.4.1.2 Tipo de Projeto: Mainframe Pessoas/Mês = 0,685 * PontosDeFunção0,507 * TamanhoMáximoEquipe0,464

2.4.4.1.3 Tipo de Projeto: Midrange Pessoas/Mês = 0,472 * PontosDeFunção0,375 * TamanhoMáximoEquipe0,882

2.4.4.1.4 Tipo de Projeto: Desktop Pessoas/Mês = 0,157 * PontosDeFunção0,591 * TamanhoMáximoEquipe0,810

2.4.4.1.5 Tipo de Projeto: Linguagem de Terceira Geração Pessoas/Mês = 0,425 * PontosDeFunção0,488 * TamanhoMáximoEquipe0,697



2.4.4.1.6 Tipo de Projeto: Linguagem de Quarta Geração Pessoas/Mês = 0,317 * PontosDeFunção0,472 * TamanhoMáximoEquipe0,784

2.4.4.1.7 Tipo de Projeto: Melhoria Pessoas/Mês = 0,669 * PontosDeFunção0,338 * TamanhoMáximoEquipe0,758

2.4.4.1.8 Tipo de Projeto: Novo Desenvolvimento Pessoas/Mês = 0,520 * PontosDeFunção0,385 * TamanhoMáximoEquipe0,866

Suponha que você esteja criando uma estimativa de esforço para uma aplicação desktop

de 1450 pontos de função em Java e você tem um tamanho de time máximo de sete

pessoas. A equação Desktop sugere que você irá ter um esforço de 56 Pessoas/Mês:

0,157 * 14500,591 * 70,810

Você pode também usar a equação de Linguagem de Terceira Geração para obter um

estimativa de 58 Pessoas/Mês:

0,425 * 14500,488 * 70,697

Um aspecto interessante da técnica ISBSG é que as fórmulas para esforço dependem do

tamanho máximo do time de projeto, com times menores produzindo estimativas de esforço

total menores. Variar o tamanho máximo do time de 7 para 10 pessoas provoca a variação de

56 para 75 pessoas/mês. De um ponto de vista de estimativa, isto introduz incerteza. De um

ponto de vista de controle de projeto, esta diferença pode levar você a usar um time de

tamanho menor ao invés de um maior.



2.4.4.2 Estimando Usando Comparação

Estimar usando comparação permite alcançar estimativas mais detalhadas que as obtidas

usando equações de regressão. Estimativas usando comparação são alinhadas mais

especificamente aos atributos do projeto sendo planejado, ao invés de se basearem nos

atributos do projeto “médio” do repositório ISBSG.

O projeto planejado deve ser comparado com certo número de projetos do repositório

ISBSG que têm atributos similares ao do projeto planejado. São usados os valores medianos

para esforço, duração, etc., do grupo selecionado de projetos para produzir uma estimativa

da taxa de entrega e velocidade de entrega do projeto, e consequentemente o esforço e

duração do projeto.

Os passos são os seguintes:

1. Defina a plataforma aplicável ao seu projeto e identifique este subconjunto dos dados ISBSG.

2. Defina os outros atributos do projeto a ser estimado (ex.: linguagem, ferramentas, etc.).

3. Pesquise o subconjunto identificado dos dados ISBSG para os projetos com os mesmos atributos.

4. Para cada um dos atributos planejados do projeto, obtenha a mediana da taxa de entrega e velocidade de entrega para todos os projetos no repositório ISBSG que exibem aquele atributo.

5. Determine a média das medianas de taxa de entrega e velocidade de entrega do projeto.

6. O resultado é sua estimativa.

Considerando que os valores resultantes estão alinhados com os atributos específicos do

projeto a ser estimado, eles são melhores estimativas da taxa de entrega e velocidade de

entrega que os valores obtidos das equações que refletem o projeto “médio” do banco de

dados.



2.4.4.3 Estimando Usando Analogia

Estimativa baseada em analogia é outra técnica para macro-estimativa em momentos

iniciais do ciclo de vida. Envolve selecionar um ou dois projetos completos que mais se

assemelham às características do seu projeto planejado. Os projetos escolhidos, ou

análogos, são então usados como a base para sua nova estimativa.

Estimativa baseada em analogia difere da estimativa baseada em comparação citada

anteriormente, na medida em que a estimativa baseada em comparação usa as medianas de

um grupo de projetos similares. Analogia opera com um, ou talvez dois projetos passados

selecionados com base em sua forte similaridade com o projeto proposto. Comparando um

projeto planejado com um projeto passado é comumente usado em uma maneira informal,

consequentemente é uma técnica familiar para o praticante.

Estimar esforço de projetos de software por analogia envolve um número de passos:

1. Estabeleça os atributos do seu projeto planejado (tamanho, tipo de linguagem, etc.) 2. Meça ou estime os valores daqueles atributos de projeto. 3. Pesquise o repositório ISBSG para um projeto que se encaixe nos atributos do seu

projeto planejado. 4. Use o esforço de desenvolvimento conhecido do projeto selecionado (análogo),

como uma estimativa inicial para o projeto alvo. 5. Compare cada um dos atributos escolhidos (tamanho, plataforma, etc.). 6. Estabeleça ou ajuste a estimativa de esforço inicial à luz das diferenças entre o seu

projeto análogo e o planejado.

É muito importante que se excluam análogos inapropriados e evite-se a tentação de

adotar um análogo aproximado sem o devido cuidado.



2.4.5 Processos Ágéis

Para explicar estimativa em processos ágeis, é necessário iniciar explicando o conceito de

feature nestes processos. Em desenvolvimento ágil, uma feature é um bloco de

funcionalidades que agrega valor ao negócio. Features podem incluir adições ou mudanças a

funcionalidades existentes. Para efeitos de planejamento, alguns processos também usam as

noções de “itens de trabalho” que podem incluir features, conserto de bugs, documentos, e

outros artefatos. Contudo, features formam a unidade principal de planejamento. Idealmente,

uma feature deve seguir os seguintes critérios:

1. Deve prover valor para o negócio; 2. Deve ser estimável – precisa ter definição suficiente para que o time de

desenvolvimento possa estimar o trabalho envolvido na sua implementação; 3. Deve ser pequena o suficiente para caber em uma iteração – assim, se for muito

grande, deve ser quebrada em pedaços menores; 4. Deve ser testável – você deve entender qual teste automático ou manual uma

feature deve passar para ser aceitável pelo usuário.

Os diferentes processos usam diferentes terminologias para se referir a features. Extreme

Programming (XP) usa o termo Estórias de Usuários ou Estórias para representar features;

Scrum usa Backlog de Produto para descrever uma lista de features; Feature-Driven

Development usa Feature; e DSDM usa Requisito. Similarmente, existem várias versões

leves do Processo Unificado, ou Agile UP, que usam Requisitos e/ou Casos de Uso para

definir funcionalidade entregue incrementalmente. Ao final, o objetivo é o mesmo – entregar

valor para o negócio regularmente em pequenos incrementos.

A estimativa em processos ágeis tais como XP (eXtreme Programming), SCRUM e FDD

(Feature Driven Development) considera que o processo de estimativa deve ser

extremamente simples e flexível. Partindo do pressuposto que em qualquer desenvolvimento

de software os requisitos, o projeto, as tecnologias e as pessoas, mudam ao longo do tempo,

os usuários de metodologias ágeis defendem que apenas planos grosseiros (pouco

detalhados) sejam feitos para prazos longos, visto que planos de longo prazo vão com

certeza mudar ao longo do tempo. Planos detalhados são feitos apenas para horizontes muito

curtos, normalmente uma iteração (no máximo 3 meses).

No início de cada iteração o esforço é estimado de acordo com o tamanho das Estórias,

as funcionalidades a serem implementadas (que são de valor para o usuário). O tamanho das

estórias é obtido simplesmente inferindo-se com base em experiências passadas do time,



basicamente respondendo a pergunta: Quanto tempo eu levei no passado para implementar

algo como isso? Uma vez respondida esta pergunta, se tem uma estimativa de quanto tempo

cada estória irá levar para ser implementada, e o somatório destas estimativas será a

duração da iteração.

No entanto isto poderia implicar em iterações muito longas, e é aí que entra o conceito de

Velocidade. Velocidade é a soma das estimativas das features entregues (i.e., aceitas) por

iteração. A Velocidade é medida nas mesmas unidades da estimativa de features, quer esta

seja Pontos de Estória, Dias, Dias Ideais, ou Horas – todas são aceitáveis. Uma regra geral é

planejar a velocidade inicial como sendo um terço do tempo disponível se estiver estimando

em tempo ideal de programador, para considerar reuniões, e-mail, projeto, documentação,

retrabalho, colaboração, pesquisa, etc. Como um exemplo, com 6 programadores e iterações

de 2 semanas, um total de 60 dias de programador (6 programadores X 10 dias) está

disponível. Nesta situação, seriam planejados 20 dias ideais de trabalho na iteração 1.

Lembre-se que a velocidade irá rapidamente emergir durante a primeira iteração, Se

subestimada, a velocidade na primeira iteração irá aumentar quando novas features forem

incluídas; e se superestimada, a velocidade irá diminuir quando features forem removidas. A

segunda iteração deve então usar a primeira iteração como um guia.

Este processo é repetido a cada final de iteração, sendo o planejamento realizado ao

longo do projeto. No início do projeto só se tem um nível maior de certeza de quanto vai durar

a primeira iteração. A Figura 2.13 ilustra a velocidade demonstrada por um time hipotético.

0

5

10

15

20

25

30

Iteração 1

Iteração 2

Iteração 3

Iteração 4

Iteração 5

Iteração 6

Iteração 7

Iteração 8

Iteração 9

Iteração 10

Velocidade

Figura 2.13 – Velocidade por Iteração – Time de Projeto Hipotético



Um ponto positivo neste processo de estimativa é que ele tende a melhorar com o uso.

Quanto mais você o usa, todos no time começam a estimar melhor. Este processo deve ser

encorajado. Não se deve esperar muito das estimativas iniciais, mas deve-se esperar que

elas melhorem. Para isto funcionar você precisa rastrear seus trabalhos, registrando quanto

tempo se leva para implementar uma estória.

2.4.5.1 Pontos de Estória

Quando usando Pontos de Estória, o time revisa a lista de estórias (ou features) que está

considerando construir e atribui um tamanho para cada estória. Os valores numéricos

atribuídos seguem normalmente uma das escalas numéricas mostradas na Tabela 2.22

[McConnell-06].

Escala de Pontos de Estória Pontos Específicos na Escala Potências de 2 1, 2, 4, 8, 16 Seqüência de Fibonacci 1, 2, 3, 5, 8, 13

Tabela 2.22 – Escalas de Pontos de Estória Mais Comuns [McConnell-06]

O resultado desta atividade de estimativa é a criação de uma lista como a mostrada na

Tabela 2.23 [McConnell-06].

Estória Pontos Estória 1 2 Estória 2 1 Estória 3 4 Estória 4 8

... Estória 60 2

TOTAL 180

Tabela 2.23 – Exemplo de Lista de Estórias e Pontos de Estória Atribuídos [McConnell-06]

Neste estágio do seu uso, pontos de estória não são tão úteis, visto que eles não se

traduzem em nenhuma unidade - eles não podem ser traduzidos em número de linhas de

código, número de pessoas/dia, ou duração em dias. A idéia crítica por trás de pontos de

estória é que o time os usa para estimar todas as estórias ao mesmo tempo, usando a

mesma escala, e de uma maneira que é substancialmente livre de preconceitos ou

tendências.



A seguir o time irá planejar uma iteração, incluindo o planejamento de entrega de certo

número de pontos de estória. Depois que a iteração estiver completa, o time estará em uma

posição que permitirá uma capacidade real de estimativa. O time pode olhar para quantos

pontos de estória ele produziu, quanto esforço realizou, e quantos dias se passaram, e então

fazer uma calibragem preliminar de como pontos de estória traduz-se em esforço e dias. Isto

é frequentemente chamado de Velocidade (ver exemplo na Tabela 2.24 [McConnell-06]).

Dados para Iteração 1 27 Pontos de Estória produzidos 12 semanas de time gastas 3 semanas gastas Calibragem Preliminar Esforço = 27 pontos de estória / 12 semanas de time = 2,25 pontos de estória/semana de time Cronograma = 27 pontos de estória / 3 semanas = 9 pontos de estória/semana

Tabela 2.24 – Exemplo de Lista de Estórias e Pontos de Estória Atribuídos [McConnell-06]

Esta calibragem inicial permite ao gerente de projeto fazer uma estimativa baseada em

dados históricos (por analogia) para o restante do projeto, como mostrado na Tabela 2.25

[McConnell-06].

Dados para Iteração 1 Hipóteses (da Calibragem Preliminar) Esforço = 2,25 Pontos de Estória/semana de time Cronograma = 9 pontos de estória/semana Tamanho do projeto = 180 pontos de estória Estimativa Preliminar para Todo o Projeto Esforço = 180 pontos de estória / 2,25 pontos de estória/semana de time = 80 semanas de time Cronograma = 180 pontos de estória / 9 pontos de estória/semana = 20 semanas

Tabela 2.25 – Projeção Inicial para o Restante do Projeto [McConnell-06]

De fato, a Tabela 2.25 [McConnell-06] assume que o time irá permanecer o mesmo em

iterações futuras, e a projeção não leva em consideração feriados, férias, e assim por diante.

Mas em projetos iterativos, sem dúvidas permite que sejam realizadas projeções muito cedo

no projeto, permitindo que a estimativa de todo o projeto com base em dados históricos do

próprio projeto. A projeção inicial para todo o projeto deve ser refinada com base nos dados

das iterações seguintes.



2.4.6 Pontos de Casos de Uso Casos de uso especificam o comportamento do sistema ou parte(s) dele e descrevem a

funcionalidade do sistema desempenhada pelos atores. Você pode imaginar um caso de uso

como um conjunto de cenários, onde cada cenário é uma seqüência de passos a qual

descreve uma interação entre um usuário e o sistema. Os casos de uso são representados

em forma de elipse. Um exemplo de diagrama de casos de uso pode ser visto na Figura 2.14

[Rankin-05].

Figura 2.14 – Exemplo de Diagrama de Casos de Uso [Rankin-05]

Existem diferentes abordagens e técnicas para estimar com sucesso com base em casos

de uso. Gustav Karner [Karner-93] da Objectory AB (depois adquirida pela Rational)

desenvolveu a técnica de pontos de caso de uso, influenciado pela técnica de pontos de

função. Poucos pesquisadores, no entanto, testaram a técnica de pontos de caso de uso e

seus resultados. Bente Anda et al. [Anda-01] compararam a técnica de pontos de caso de uso

com estimativas de especialistas feitas por desenvolvedores de software experientes. A

técnica de pontos de caso de uso resultou em uma estimativa que foi próxima a produzida

pelos especialistas. Os resultados deste estudo indicam que a técnica de pontos de casos de

uso pode ser utilizada com sucesso para estimar esforço de desenvolvimento de software.

Usuário

API Sistema

Fronteira do Sistema

Ver Dados Sumarizados

Gravar Autorização Manual

Registrar Crédito

Gravar Transações Automatixadas

Agendar Batches



Arnold e Pedross [Arnold-98] também estudaram e reportaram suas experiências usando

a técnica de pontos de casos de uso. A técnica particular deles era similar, mas não idêntica

à criada por Karner. Os resultados que eles encontraram solidificaram a hipótese inicial que

era confiável realizar estimativas utilizando esta técnica. Eles, contudo, apontaram como

principal elemento de dificuldade a inexistência de padronização de casos de uso quanto ao

seu formato.

Existem ainda outras técnicas alternativas para a estimativa com base em caso de usos.

Uma delas prevê a estimativa de quantidade de pontos de função em cada caso de uso, com

o posterior uso da técnica de pontos de função. A outra abordagem prevê a estimativa de

quantidade de linhas de código para cada caso de uso [Anda-01] e o uso deste valor para a

estimativa de esforço. Estas duas abordagens são tentativas de usar a extensa experiência

da indústria com estimativa de pontos de função e linhas de código.

O uso da técnica de pontos de caso de uso ainda é muito limitado na indústria. Podemos

creditar este fato a diversos fatores tais como a inexistência de ferramentas de estimativa que

suportem a técnica e a relativamente nova utilização de caso de uso como técnica de captura

de requisitos, o que provoca a inexistência de bases históricas em quantidade suficiente para

fornecer bases confiáveis de produtividade.

Se considerarmos que a utilização de casos de uso é praticamente um padrão nos dias

atuais, é estranho que casos de uso ainda não sejam utilizados fortemente como fonte de

estimativa pela indústria. Contudo existem vários pontos que dificultam o uso de estimativas

baseadas em casos de uso [Smith-99]:

• Existem muitas variações de estilos de especificação e formalização de casos de uso que dificultam muito a definição de métricas;

• Casos de uso devem representar a visão externa que um ator tem de um sistema, e assim um caso de uso para um sistema de 500.000 linhas de código (SLOC) está em um nível bem diferente de um escrito para um subsistema de 5.000 SLOC;

• Casos de uso podem diferir em complexidade, tanto explicitamente na forma de escrita quanto implicitamente na realização requerida;

• Um caso de uso deve descrever comportamento do ponto de vista do ator, mas isto pode ser muito complexo, especialmente se o sistema tem estados, como a maioria tem. Assim para descrever este comportamento pode ser requerido um modelo do sistema que possa levar a uma grande quantidade de níveis de decomposição funcional e detalhes, em uma tentativa de capturar a essência do comportamento.



Sendo assim, será que não temos alternativa de usar os casos de uso, e estamos fadados

a nos basearmos em estimativas superficiais? Ou teremos que esperar até que a análise e

projeto estejam adiantados para que possamos realizar uma estimativa? Estas opções

obviamente não atendem, visto que o risco envolvido em estimar superficialmente ou não

realizar nenhuma estimativa no início do projeto não é aceitável na vida real. Desta forma

temos que buscar uma alternativa que nos possibilite uma estimativa com um grau razoável

de certeza, e que refinemos estas estimativas ao longo do projeto. Gustav Karner [Karner-93]

propõe uma técnica inspirada em pontos de função, mas com o benefício de usar a análise

de requisitos baseada em casos de uso. Ele começa com a medida da funcionalidade do

sistema baseado no modelo de caso de uso em uma contagem chamada Pontos de Caso de

Uso Não Ajustados (UUCP). Fatores técnicos envolvidos em desenvolver esta funcionalidade

são considerados, de forma similar a pontos de função. O último passo na estimativa não

existe em Pontos de Função, é um novo fator, chamado Fator Ambiental, proposto por

Karner.

Os pontos de caso de uso (UCP) são o produto destes três fatores. Os UCPs dão a

estimativa do tamanho do esforço para desenvolver o sistema, o qual pode ser mapeado para

horas homem para completar várias fases do RUP ou para completar todo o projeto.

Os pontos de caso de uso podem também ser mapeados para o número de classes ou

linhas de código (LOC) e a partir destes estimar as horas homem usando uma técnica como

COCOMO.

2.4.6.1 Detalhamento de Casos de Uso

John Smith [Smith-99] afirma que o número de casos de uso de um projeto deve ser

pequeno (entre 10 e 50) e observa que um número grande (mais que 100) normalmente

indica uma falha na decomposição funcional, onde um caso de uso não está agregando

nenhum valor para um ator. Devemos ter o cuidado de não confundir cenários de uso com

casos de uso, e focar nos casos de uso externos (casos de uso que descrevem o

comportamento do sistema e de seus atores). Os detalhes do caso de uso devem ser

capturados em descrições textuais escritas em linguagem natural, ou em diagramas de

estado ou de atividades.



Uma descrição de caso de uso deve conter no mínimo um nome de identificação e/ou um

número, o nome do ator iniciante, uma breve descrição do objetivo do caso de uso, e uma

seqüência numerada de passos (entre 3 e 8 passos) que descrevem o principal cenário de

sucesso [Ribu-01]. Deve ser utilizada como regra padrão que se um caso de uso tiver mais

que 10 passos no principal cenário de sucesso, ele deve ser reduzido, quer pela aglutinação

de passos ou pela separação de funcionalidades. Uma importante razão para casos de uso

não serem muito longos é que a escala de complexidade da técnica de pontos de casos de

uso tem apenas 3 níveis: simples, médio e complexo. Isto não é compatível com casos de

uso com muitas transações.

Um caso de uso deve ter o tamanho necessário para descrever com clareza o

comportamento necessário ao mesmo, incluindo inclusive as regras de negócio necessárias à

execução do mesmo, sem detalhes demais ou de menos. Considerando isto, a descrição do

fluxo de eventos pode variar entre 2 e 20 páginas.

Descrever os movimentos dos usuários na operação da interface homem-máquina do

sistema é um erro comum. Se existir um passo “Usuário pressiona botão”, o escritor escolheu

uma ação que entra em detalhes demais. Isto leva a contar transações que não descrevem

funcionalidade, mas a interface com o usuário. A descrição de movimentos na interface do

usuário pertence ao projeto da interface do usuário, não ao documento de requisitos

[Cockburn-00].

Algumas vezes os casos de uso são escritos como se o sistema estivesse olhando para o

mundo e conversando consigo mesmo. As sentenças têm a aparência “Obtenha o cartão de

auto-atendimento e o número do PIN. Deduza o valor do saldo da conta”. Ao invés disto, o

caso de uso deveria ser escrito do ponto de vista do usuário:

• O cliente coloca o cartão de auto-atendimento e o PIN

• O sistema deduz o valor do saldo da conta

Um passo de caso de uso irá descrever uma ação de alcance de objetivo, por exemplo:

• Uma interação entre dois atores (“Cliente entra endereço”)

• Uma validação (“Sistema valida o PIN”)

• Uma mudança interna (“Sistema deduz o valor do saldo da conta”)

Veja um exemplo no Apêndice E – Exemplo de Caso de Uso.



2.4.6.2 Pontos de Caso de Uso Não Ajustados (UUCP)

Para computar os UUCPs cada ator e cada caso de uso devem ser julgados como se

fossem simples, médios ou complexos com a ajuda da Tabela 2.26, para atores, e da Tabela

2.27 [Karner-93], para casos de uso. Apenas casos de uso e atores concretos são

contabilizados. Deve ser evitado o uso de generalização entre atores, pois o número de

atores em um modelo de casos de uso afeta a estimativa. Bente Anda et al. [Anda-01] cita

que se as descrições de dois ou mais atores têm muito em comum, a acurácia da estimativa

é aumentada pela generalização dos atores em um super ator e assim contando os atores

apenas uma vez.

Complexidade Definição Peso Simples Um ator é simples se ele representa outro sistema com uma API (application

programming interface) definida. 1

Médio Um ator é médio se ele é: 1. Uma interação com outro sistema através de um protocolo; 2. Uma interação humana via interface não gráfica.

2

Complexo Um ator é complexo se ele interage através de uma interface gráfica (GUI). 3

Tabela 2.26 – Atores com pesos [Karner-93]

Complexidade Definição Peso Simples Um caso de uso é simples se ele tem 3 ou menos transações, incluindo

fluxos alternativos. Você deve poder realizar o caso de uso com menos de 5 objetos de análise.

5

Médio Um caso de uso é médio se ele tem entre 4 e 7 transações incluindo os fluxos alternativos. Você deve poder realizar o caso de uso com uma quantidade de 5 a 10 objetos de análise.

10

Complexo Um caso de uso é complexo se ele tem mais que 7 transações incluindo os fluxos alternativos. O caso de uso deve necessitar de pelo menos 10 objetos de análise para ser realizado.

15

Tabela 2.27 – Casos de Uso com Pesos [Karner-93]

Uma transação é um conjunto de atividades atômicas, que pode ser realizada

inteiramente ou não [Schneider-98]. A contagem do número de transações pode ser feita

contando o número de passos do caso de uso. Quando tiver a mesma transação em todos os

diagramas de seqüência como logging ou procedimentos de segurança, a transação deve ser

contada apenas uma vez porque a funcionalidade é implementada apenas uma vez e

reutilizada em outros casos de uso [Ribu-01].



Kirsten Ribu [Ribu-01] sugeriu as seguintes regras para identificar casos de uso e suas

respectivas transações:

• Contar os casos de uso estendidos e incluídos separadamente apenas uma vez e não

como uma transação de cada caso de uso que o utiliza;

• Identificar as classes de análise (não as de projeto) que implementam as funções do

caso de uso, para auxiliar na determinação da complexidade do caso de uso. Essas

classes podem ser identificadas na descrição dos casos de uso, nos diagramas de

seqüência ou no diagrama de classes de análise;

• Comparar as transações (descritas no caso de uso) com as transações do diagrama

de seqüência e com o número de classes de análise utilizadas para implementar o

caso de uso, para verificar se a complexidade do caso de uso foi definida

corretamente;

• Quando não houver a especificação do caso de uso, deve-se utilizar o diagrama de

seqüência para contar as transações (apenas aquelas que indicam o que fazer e não

as que indicam o como fazer) ou as classes que implementam o caso de uso.

Nós somamos os pesos dos atores e os casos de uso conjuntamente para obter o UUCP. 6

UUCP = ∑ ni * Pi , onde ni é o número de itens de variedade i. i=1

Se nós não tivermos mais informações sobre o ambiente de implementação do projeto,

nós podemos usar o UUCP para estimativa. Caso contrário, nós iremos ajustar o UUCP para

obter uma estimativa melhor.



2.4.6.3 Fatores de Complexidade Técnica (TCF)

O UUCP é pesado com o fator de complexidade técnica (TCF), o qual varia dependendo

em quão difícil de construir será o sistema. O TCF é similar ao de Pontos de Função, as

diferenças são que Karner adicionou alguns e retirou outros, além de definir pesos diferentes

com base na experiência da Objectory em projetos próprios.

Um fator técnico é um requisito de sistema diferente daqueles relacionados com conteúdo

de informação e que afetam o tamanho da tarefa, e não surgem do ambiente de projeto

[Symons-01].

O TCF é computado da seguinte forma: 13

TCF = 0,6 + 0,01 * ∑ Fi * Pi, onde F e P seguem a Tabela 2.28 [Karner-93]. i=1

Fi Fatores contribuindo para complexidade Pi

1 Sistemas distribuídos 2

2 Objetivos de performance, tanto em tempo de resposta quanto em throughput 1

3 Eficiência do usuário final (on-line) 1

4 Complexidade do processamento interno 1

5 Reusabilidade, o código precisa poder ser usado por outras aplicações 1

6 Facilidade de instalação 0,5

7 Facilidade de operação, Usabilidade 0,5

8 Portabilidade 2

9 Facilidade de manutenção 1

10 Concorrência 1

11 Características especiais de segurança 1

12 Necessidade de prover acesso direto a terceiros 1

13 Facilidades Especiais para Treinamento de Usuários são Requeridas 1

Tabela 2.28 – Fatores que contribuem para a complexidade [Karner-93]

Fi é um fator que é classificado em uma escala de 0 a 5, de acordo com o grau de

dificuldade do sistema a ser construído. O valor 0 indica pouca criticidade e baixa

complexidade (irrelevante para o projeto) e o valor 5 indica alta criticidade e complexidade

(essencial) – ver Apêndice C. Se o fator não é importante nem irrelevante ele receberá o valor

3. Se todos os fatores tiverem o valor 3 o TCF será 1.



2.4.6.4 Fator Ambiental (EF) Nós pesamos o UCP com o Fator Ambiental (EF), o qual nos ajuda a estimar quão

eficiente nosso projeto é, em relação ao time alocado e à estabilidade dos requisitos. 8

EF = 1,4 – 0,03 * ∑ Fi * Pi, onde F e P seguem a Tabela 2.29 [Karner-93]. I=1

Fi Fatores que contribuem para a eficiência Pi

1 Familiaridade com o Processo de Desenvolvimento de Software 1,5

2 Experiência com a aplicação 0,5

3 Experiência com orientação a objetos 1

4 Capacidade do Analista Líder 0,5

5 Motivação 1

6 Requisitos estáveis 2

7 Trabalhadores em tempo parcial -1

8 Dificuldade da Linguagem de Programação -1

Tabela 2.29 – Fatores Ambientais [Karner-93]

Fi é um fator que é classificado em uma escala de 0 a 5 (ver Apêndice D). 0 significa que é

irrelevante e 5 significa que ele é essencial. Se o fator não é importante nem irrelevante ele

receberá o valor 3. Se todos os fatores tiverem o valor 3 o EF será 1.



2.4.6.5 Pontos de Caso de Uso Ajustados (UCP)

Finalmente o Ponto de Casos de Uso (UCP) é calculado:

UCP = UUCP * TCF * EF

Karner propõe em seu trabalho que seja considerado um fator de 20 homens hora por

UCP para realizar a estimativa. Este resultado é uma estimativa do número total de homens

hora necessário para completar o projeto.

Experiência de campo tem mostrado que o esforço pode variar de 15 a 30 horas por ponto

de caso de uso, desta forma converter pontos de caso de uso diretamente para horas pode

resultar em uma medida muito incerta. Schneider e Winters [Schneider-98] sugerem um

refinamento da proposta de Karner com base no nível de experiência do time e estabilidade

do projeto. Devem ser observados os fatores ambientais entre F1 e F8. Devem ser contados

quantos de F1 a F6 estão abaixo de 3 e quantos de F7 a F8 estão acima de 3. Se o total for 2

ou menos, use 20 homens hora por UCP. Se o total for 3 ou 4, use 28. Se o total for 5 ou

mais, o projeto deve ser revisto, para que os números sejam ajustados. De outra forma o

risco de insucesso é muito alto. Kirsten Ribu [Ribu-01] considera que nestes casos pode

também ser usado 36 homens hora por UCP. Quaisquer valores negativos significam que

terão que ser gastas mais horas treinando pessoal ou corrigindo problemas devido à

instabilidade, e com isto menos tempo será dedicado ao projeto. Por conta disto a sugestão

de usar mais homens hora por UCP. É preciso estar atento que qualquer ajuste nos fatores

ambientais pode implicar em grandes mudanças no resultado final da estimativa. Mesmo

meio ponto pode implicar em uma mudança muito significativa.

2.4.6.6 Experiências de uso relatadas pela indústria

O artigo original de Gustav Karner se baseou em apenas três projetos da Objectory, o que

não permitiu conclusões definitivas sobre a efetividade da técnica. O próprio Karner chegou a

esta conclusão, deixando claro que o trabalho estava apenas iniciando e provavelmente

seriam necessários ajustes nos fatores ambientais e técnicos. Infelizmente após a compra da

Objectory pela Rational, não foram mais publicados pela mesma dados da continuidade deste

trabalho.



Como já afirmado anteriormente, não estão disponíveis muitos dados sobre o uso de

pontos de caso de uso pela indústria. Um estudo publicado na tese de mestrado de Kirsten

Ribu [Ribu-01] na Universidade de Oslo traz novos dados e novas reflexões sobre o

problema. Ribu baseou sua tese na avaliação de projetos de estudantes e projetos da

indústria, comparando o esforço real dos projetos concluídos com o esforço estimado através

da estimativa de casos de uso, da avaliação de especialistas e do uso de ferramentas padrão

de estimativa do mercado. As conclusões a que este trabalho chegou são sumarizadas a

seguir:

Descrição textual do caso de uso: Os detalhes do caso de uso devem ser capturados em

descrições textuais escritas em linguagem natural, ou em diagramas de estado ou de

atividades. Uma descrição de caso de uso deve conter no mínimo um nome de identificação

e/ou um número, o nome do ator iniciante, uma breve descrição do objetivo do caso de uso, e

uma seqüência numerada de passos que descrevem o principal cenário de sucesso;

Estruturando os casos de uso: Casos de uso bem escritos devem ter entre 3 e 8 passos;

Contando casos de uso estendidos e inclusos: Contrariando a recomendação de Karner,

os casos de uso estendidos e inclusos devem ser contados, para se ter certeza que toda a

funcionalidade foi considerada, a fim de evitar estimativas abaixo da realidade, principalmente

se as funções descritas nesses casos de uso são essenciais e serão implementadas;

Acurácia da estimativa: A técnica de pontos de casos de uso foi a mais acurada entre as

avaliadas, tendo a menor variação entre o estimado e o real (5 dos 13 projetos investigados

praticamente não tiveram variação). Contudo estes dados não podem ser considerados em

sua plenitude, visto que o esforço real de gerenciamento do projeto não foi considerado nos

totais de esforço atuais usados nas comparações;

Descartar o fator de complexidade técnica: a principal razão para isto está no descarte do

fator de complexidade técnica do MKII Function Point Analisys há alguns anos. Casos de uso

correspondem às transações lógicas da técnica MKII FPA. Além disso, pesquisas mostram

que a omissão dos fatores de complexidade técnica nas estimativas obtidas com a técnica

produz praticamente o mesmo resultado que quando os fatores de complexidade técnica são

considerados;



Manter os fatores ambientais: As estimativas produzidas sem o fator ambiental são

maiores que as produzidas quando este fator é considerado, ficando mais distantes dos

valores reais. Estes fatores devem ser considerados nas estimativas;

Estimando esforço de manutenção: A técnica não prevê nenhum procedimento para a

estimativa de esforço de manutenção de software. Esta é uma extensão que vem sendo

buscada por alguns autores, como a proposta pela TUCP (Technical UCP) [Monteiro-05];

2.5 Conclusão

Este capítulo apresentou diversas técnicas para estimativa de esforço de desenvolvimento

de software, apresentando em detalhes as técnicas mais utilizadas atualmente. Ao final deste

estudo identificamos como estas técnicas se propõem a responder às questões fundamentais

com que todo estimador se depara:

• Quanto esforço é requerido para completar uma atividade?

• Quanto tempo é necessário para completar uma atividade?

• Qual é o custo total de uma atividade?

A predição acurada do tamanho do software (relembrando: tamanho => esforço => custo)

é uma questão crítica para tomar decisões gerenciais acertadas e de forma acurada

determinar quanto esforço e tempo um projeto requererá dos gerentes de projetos, analistas

de negócios e engenheiros de software, bem como o custo esperado do projeto. Como visto

neste capítulo, existem muitas técnicas disponíveis, incluindo técnicas algorítmicas, por

analogia, e por julgamento de especialistas. Nenhuma técnica é necessariamente melhor ou

pior que a outra, de fato suas forças e fraquezas frequentemente se complementam.

Entender suas forças e fraquezas é muito importante quando se quer estimar projetos.

O estudo das técnicas apresentadas neste capítulo, seus pontos fortes e fracos, bem

como a adoção das mesmas pela indústria, é a base fundamental para a escolha da técnica

utilizada atualmente na organização estudo de caso, conforme será apresentado no próximo

capítulo.

Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático


Capítulo 3 3. Seleção da Técnica de Estimativas (Caso Real)

"Quanto ao futuro, sua tarefa não é antevê-lo, mas torná-lo possível" - Antoine de Saint-Exupéry (1900-1944)

3.1 Definição de Método de Seleção

Uma vez definida a necessidade de uma técnica de estimativas, o passo seguinte de

qualquer empresa é responder ao dilema: “Qual técnica devemos usar?”. Com a diversidade

de técnicas de estimativa disponíveis, esta não é uma resposta fácil de obter. Para obtermos

esta resposta é necessária a análise das diversas técnicas segundo um método estruturado,

que permita a comparação das técnicas de estimativas candidatas, avaliando os pontos fortes

e fracos das mesmas, e a sua aderência às necessidades específicas do avaliador. O método

de seleção escolhido foi o sugerido por Daniel Ferens [Ferens-86]. Esta abordagem considera

quatro passos para avaliar a adequação das técnicas às necessidades da empresa. Os

quatro passos são:

• Determinar necessidades (definição de critérios de seleção),

• Selecionar técnicas candidatas,

• Escolher a técnica mais apropriada, e

• Reavaliar a escolha.

3.1.1 Definição de Critérios de Seleção

Consideramos este primeiro passo como o mais crucial. Técnicas diferentes são melhores

de acordo com as necessidades da organização. Devemos então primeiro listar as

necessidades da organização, atribuindo pesos a cada uma delas. A lista de fatores e pesos

obtida (abordagem fatores-pesados) reflete a importância destes fatores para a organização.

Logicamente estes são os considerados importantes para a organização estudada, podendo

diferir bastante de uma organização para outra. Posteriormente, deve ser atribuída uma nota

(valor entre "1" e "10") para cada técnica naquele fator, quantificando como o fator é coberto

pela técnica. Então é multiplicado o peso de cada fator pela nota atribuída ao mesmo; e os

resultados são somados. O total mais alto indica a melhor alternativa. Vale ressaltar que a

lista de fatores e os pesos atribuídos aos mesmos pode ser um processo subjetivo. Como

existe subjetividade no processo, pequenas diferenças podem ser ignoradas. Mesmo com

esta abordagem sendo um tanto quanto subjetiva, ela pode ajudar na avaliação do que é



importante na seleção de técnicas e na quantificação do processo de avaliação.

Adicionalmente, uma listagem deste tipo oferece à organização uma estrutura base para a

consideração de fatores qualitativos de avaliação.

3.1.2 Selecionar Técnicas Candidatas

Considerando os critérios de seleção definidos na Seção 3.1.1, avaliamos a adequação

das técnicas de estimativas estudadas. Para efeitos deste trabalho consideramos as técnicas

detalhadas no Capítulo 2.

3.1.3 Escolher a Técnica Mais Apropriada

Devem ser realizadas análises quantitativas (acurácia) e qualitativas das técnicas

candidatas selecionadas, e escolhidas a melhor técnica ou técnicas para a organização. Para

estimativas de software é recomendado que duas técnicas sejam selecionados para uso

rotineiro: uma como a técnica primária e outra para conferência dos resultados da técnica

primária. Um estudo realizado por Coggins e Russell [Coggins-93] mostrou que diferentes

técnicas de estimativa, mesmo quando usando entradas “equivalentes”, produzem

estimativas significantemente diferentes. A conclusão deles foi que um usuário deve

aprender um ou duas técnicas bem, ao invés de tentar usar diversas técnicas diferentes.

3.1.4 Reavaliar a Escolha

Necessidades de usuários e técnicas podem mudar ao longo do tempo. Algumas técnicas

comerciais são refinadas periodicamente, como é o caso de COCOMO e Pontos de Função

(lançamentos de novos manuais de práticas de contagens). Novas técnicas surgem

ocasionalmente, podendo ser mais adequadas que as correntemente usadas pela

organização. Desta forma, um usuário deve reavaliar sua seleção a cada intervalo de alguns

anos. Não existe razão para estar “casado” com uma técnica ou técnicas em particular por

toda a vida, a menos que elas continuem a ser as melhores disponíveis.



3.2 Aplicação de Método de Seleção na Empresa Estudo de Caso

3.2.1 Definição dos Critérios de Seleção da Empresa Estudo de Caso

Como citado anteriormente, deve-se primeiro listar as necessidades da organização,

atribuindo pesos a cada uma delas. Em abril de 2005, o autor conduziu, junto à organização

estudo de caso, reuniões de brainstorm onde foram discutidas as necessidades da

organização à exaustão, definindo os seguintes critérios de seleção a serem considerados

para a escolha da técnica:

1. Fácil entendimento;

2. Rápida execução, podendo ser realizada na fase de negociação do projeto (com

conhecimento macro dos requisitos);

3. Acurácia adequada da estimativa (a fim de permitir o uso da mesma como base

para contratação e negociação);

4. Adotada pelo mercado (permitindo base de comparação);

5. Permita acompanhamento de projetos em execução (coleta de métricas)

6. Permita calibragem com dados da organização

7. Adequado para projetos de diferentes tamanhos

8. Compatível com estilo do processo de desenvolvimento da organização

9. Calibrada de acordo com a confiabilidade desejada para o software

10. Calibrada de acordo com a complexidade dos algoritmos

11. Calibrada de acordo com a capacidade e experiência da equipe

12. Adequada a diferentes ambientes tecnológicos



Estes critérios estão listados na Tabela 3.1, com seus respectivos pesos, conforme a

abordagem fatores-pesados (Seção 3.1.1). Estes pesos refletem a relevância destes critérios

de seleção para a organização estudo de caso, e foram definidos pela mesma em reuniões

com o uso da técnica Wideband Delphi. O intervalo de valores considerado foi de 12 a 1,

considerando a quantidade de critérios avaliados.

# Critério de Seleção Peso 1 Fácil entendimento 11 2 Execução cedo 11 3 Acurácia adequada 12 4 Adotado pelo mercado 9 5 Acompanhamento execução 8 6 Dados históricos 8 7 Diferentes tamanhos de projeto 1 8 Compatível com RUP (processo da empresa estudo de caso) 8 9 Calibrada com a confiabilidade desejada para o software 5

10 Calibrada de acordo com a complexidade dos algoritmos 5 11 Calibrada de acordo com a capacidade e experiência da equipe 5 12 Adequada a diferentes ambientes tecnológicos 5

Tabela 3.1 – Critérios de Seleção (Abordagem Fatores-Pesados)

3.2.2 Detalhamento dos Critérios de Seleção da Empresa Estudo de Caso

Detalhamos a seguir cada um dos critérios de seleção da organização estudo de caso.

3.2.2.1 Atendimento do Mercado (Critérios 1 a 4)

Para atender o mercado é necessário antes de tudo entender o cenário atual do mesmo:

• Profusão de concorrentes (se você não faz, o da esquina faz).

• Qualidade é commodity (CMMI [SEI-07], ISO [ISO-07] e MPS.BR [MPS.BR-07]

passam a ser não mais diferencial, mas ponto de partida).

• Prazos cada vez mais apertados (a proposta é para ontem e o projeto é para amanhã).

• Cultura de projeto fechado (Preço Fixo).

• Se há confiança, preço e prazo são o que contam.

Para atender o cenário descrito acima, a técnica escolhida deve permitir a geração de

estimativas com base em critérios claros e facilmente entendíveis pelo cliente (usuário), a

fim de servir como base para negociação, permitindo uma resposta rápida, confiável e negociável, do fornecedor às demandas. Cada uma das palavras em negrito na frase

anterior tem um significado implícito específico:



• Critérios Claros9: a técnica deve usar como base medidas que sejam claras, e de

rápida elicitação pelo estimador, facilitando a negociação com o cliente;

• Facilmente Entendíveis10: a técnica deve ser simples e baseada em medidas

compreendidas pelo usuário final (cliente), a fim de facilitar o entendimento entre as

partes;

• Resposta Rápida, Confiável e Negociável11: a técnica deve possibilitar o seu uso na

fase de negociação do projeto (quando se tem um entendimento macro dos requisitos),

sendo este tempo normalmente curto e não remunerado pelo potencial contratante,

forçando o estimador a trabalhar em tempo exíguo e com o grau de entendimento

mínimo dos requisitos que consiga ter neste tempo, a fim de permitir uma rápida

(alguns dias de trabalho) resposta à demanda, porém oferecendo ao mesmo tempo

uma estimativa coerente e acurada, que possa ser comparada com dados históricos da

organização e do próprio mercado. Para atingir esta coerência e acurácia, a técnica

deve permitir a clara associação entre o escopo técnico e as restrições, e o resultado

da estimativa (tamanho do software), bem como ser refinada a partir de dados

históricos da organização calibrando a sua acurácia. Com isto tem-se a base para a

negociação, pois se pode facilmente verificar como mudanças no escopo se refletem

no tamanho estimado para o software, e como este tamanho estimado se reflete no

esforço, cronograma, custo e funcionalidades a serem entregues ao final do projeto.

Desta forma o fornecedor terá base confiável para adequar sua exposição ao risco,

considerando que na maioria das vezes o cliente estará demandando um projeto

fechado.

Para falarmos em atender o mercado, temos que estar aderentes às práticas usadas pelo

mesmo, pois não adianta apenas ter a melhor técnica, ela tem que ser conhecida e usada

pelo mercado, a fim de permitir comparações e negociações com base na mesma (mais uma

vez a confiabilidade)12. A estimativa de tamanho de projeto de software ainda está em

evolução nas empresas brasileiras. Pesquisa de qualidade e produtividade no setor de

software brasileiro, realizada anualmente pela Secretaria de Política de Informática do

Ministério da Ciência e Tecnologia (MCT) vem demonstrando a gradual adoção de técnicas

de estimativa (ver Tabela 3.2 [MCT-06]). A última pesquisa divulgada (6ª edição) demonstrou 9 Critério 1 10 Critério 1 11 Critérios 2 e 3 12 Critério 4



que em uma amostra de 701 organizações do mercado de software brasileiro, apenas 35%

utilizavam algum tipo de métrica para medir a produtividade e a qualidade dos processos de

software. Dentre essas, 16% utilizavam a FPA e 19% utilizavam a UCP [MCT-06]. A 6ª edição

desta pesquisa mostra o aparecimento pela primeira vez da técnica de pontos de casos de

uso, já com um percentual expressivo, maior inclusive que o de pontos de função. Já a FPA

aparenta certa instabilidade, oscilando entre 10% e 20% de uso nas últimas 4 pesquisas

realizadas pelo MCT.

Métrica Utilizada Fonte 1995 1997 1999 2001 2005Pontos de função (FPA) ... 14% 19% 10% 16%Pontos por caso de uso (UCP)

SEPIN... ... ... ... 19%

Tabela 3.2 – Percentual de Empresas que Utilizam Métricas em Relação ao Total de Empresas [MCT-06]

3.2.2.2 Acompanhamento de Projetos em Execução (Critério 5) O acompanhamento dos projetos em execução com a mesma técnica usada para estimá-

los, é condição para permitir a aferição da acurácia da estimativa inicial. Para acompanhar os

projetos em execução é necessário definir e coletar métricas, indicadores de desempenho

destes projetos. A tecnologia de informação exige consideravelmente menos esforço de

gestão ao usar corretamente métricas. Porém apenas medir não é suficiente. A coleção de

dados de tamanho, esforço, tempo, e defeitos é apenas isto – uma coleção de dados. Para

uma organização de TI melhorar, ela precisa usar estes dados para determinar melhores

práticas, melhorias de modelos de processo, estabelecer termos de comparação, analisar

tendências, melhorar estimativas, e educar clientes, orientando as organizações de TI da

gerência aos desenvolvedores. É isto que está sendo buscado com o uso deste critério de

seleção.

Uma medida, tal como pontos de função, é um número que atribui valor relativo.

Combinações de duas ou mais medidas produzem uma métrica tal como taxa de entrega

(horas/ponto de função) ou densidade de defeitos (número de defeitos/pontos de função).

Métricas são padrões pelos quais um processo ou produto pode ser objetivamente avaliado, e

podem ser usadas para identificar melhores práticas, modelar melhorias de processo,

estabelecer uma linha base a partir da qual são determinadas as mudanças, ajudar em

projetos de estimativa e planejamento, gerenciar orçamentos mais efetivamente, identificar a

quantidade e qualidade do produto entregue, comparar a efetividade e eficiência dos

processos e ferramentas correntes, prover uma base para comparações com padrões da

indústria, e habilitar melhor comunicação entre clientes e desenvolvedores.



Janete Russac [IFP02] sugere o programa inicial de métricas listado abaixo. Este é um

programa simples, e deve ser considerado como uma primeira implementação de um

programa de métricas em uma organização. Para o cálculo destas métricas algumas medidas

são fundamentais: Tamanho (FPA, UCP, LOC, etc.), Esforço (horas), Defeitos, e Custo, tendo

o Tamanho sido usado em todas as fórmulas. Vemos assim que mesmo um programa inicial

de métricas depende fortemente da estimativa de tamanho, que é um insumo do processo de

estimativa. Segue o programa de métricas sugerido por Janete Russac em seu trabalho:

• Produtividade: é a medida da eficiência de um processo para consumir entradas e

produzir saídas. No ambiente de TI, produtividade pode ser medida usando a fórmula:

Taxa Produtividade = Esforço em Horas / TS, onde

TS = tamanho do software em linhas de código, pontos de função ou

outra medida de tamanho

• Qualidade: é a medida do processo de software durante o ciclo de vida de

desenvolvimento e o produto de software entregue.

O processo de software pode ser medido pela seguinte fórmula: Mudança de Escopo = ADD + DEL + CHG / TSO, onde

ADD = tamanho das funcionalidades adicionadas;

DEL = tamanho das funcionalidades excluídas;

CHG = tamanho das funcionalidades alteradas; TSO = Tamanho do software original (antes de ADD, DEL e CHG) O produto de software pode ser medido pela seguinte fórmula:

Taxa de Defeitos de Produção = TDP / TS, onde TDP = Total de Defeitos em Produção;

TS = conforme definido anteriormente;

• Custo: este é um dos mais importantes fatores quando decidindo o investimento em

um projeto. Estouros de projeto podem causar o cancelamento de um projeto antes de

seu término – ou no mínimo, resultar em um cliente insatisfeito. Eficiência de custo

pode ser medida pela seguinte fórmula: Eficiência de Custo = Custo Atual / TS, onde

TS = conforme definido anteriormente;



Uma organização precisa definir consistentemente e claramente estas medidas, e capturá-

las efetivamente. Se estas medidas não são confiáveis, as métricas resultantes também não

irão ser confiáveis. A medida de tamanho é o alvo deste trabalho, mas é importante a

compreensão de como a mesma se encaixa em um programa de métricas, suportando-o

como uma das medidas fundamentais.

A importância de um programa de métricas para desenvolvimento de software e

engenharia de sistemas é atestada pela transformação do PSM (Practical Software and

Systems Measurement) em padrão internacional, o ISO/IEC 15939. O PSM foi desenvolvido

para atender os desafios técnicos e de gestão de sistemas de informação. Ele descreve um

processo de medição dirigido a informação para endereçar os objetivos de negócios e

técnicos de uma organização. PSM representa as melhores práticas usadas por profissionais

de medição dentro da comunidade de engenharia de software [ISO/IEC 15939-07].

3.2.2.3 Calibragem com Dados da Organização (Critério 6)

A coleta de métricas durante a execução dos projetos, além de permitir a aferição da

acurácia da estimativa inicial, é essencial para calibrar a técnica de estimativas usada, a fim

de obter um nível maior de exatidão em futuras estimativas (dados históricos de projetos). O

uso de dados históricos é ilustrado no conceito do “Clima de Ontem” da Extreme

Programming: o clima de hoje não irá sempre ser o mesmo de ontem, mas é mais provável

que seja como ontem que como qualquer outro dia [Beck-01]. Além disso o uso de dados

históricos está negativamente relacionado com “estouros” de custo e prazo – isto é, projetos

que foram estimados usando dados históricos tendem a não ter estouros [Lederer-92]

[McConnell-06]. A Figura 3.1 [McConnell-06] mostra como o uso de dados históricos e a

maturidade do processo influenciam a precisão da estimativa.

Figura 3.1 – Acurácia de Estimativas X Níveis CMM [McConnell-06]



É essencial que a técnica de estimativas escolhida permita esta retroalimentação com

dados da organização e da indústria. O uso de dados históricos melhora a acurácia da

estimativa porque [McConnell-06]:

1. Reflete as diferentes influências da organização: a. Complexidade do software (conforme a qualificação da empresa); b. Quantidade de documentação exigida (processo usado); c. Conhecimento do negócio; d. Autonomia do Gerente de Projetos na gestão dos recursos humanos (ex.:

flexibilidade para lidar com pessoas problema); e. Times dedicados ou compartilhados com outros projetos ou com manutenção

de sistemas/produtos legados; f. Nível de suporte formal da organização à realização formal das fases de projeto,

construção, garantia de qualidade, e testes; g. Necessidade de suportar ambientes regulatórios em que a organização atua

(ex.: Sarbannes-Oxley [SOX-02]); h. Nível de turnover; i. Complexidade da arquitetura;

2. Evita subjetividade e otimismo infundado;

3. Reduz política na estimativa, evitando considerar capacidade do pessoal acima da

média histórica.

Dados históricos tendem a ser mais fáceis de coletar se eles são coletados enquanto o

projeto está sendo executado. É muito difícil voltar seis meses depois que um projeto

terminou e levantar dados corretos de tamanho, esforço, defeitos, duração e custo.

Em praticamente todas as técnicas estudadas ficou claro que a utilização da opinião do

especialista torna a estimativa mais exata. Este fato se deve ao fato de que o especialista,

por conhecer o negócio e muito provavelmente já ter trabalhado em sistemas similares, tem

maior confiabilidade em suas estimativas. Considerando uma técnica paramétrica, como

poderíamos inserir a opinião do especialista? Neste caso substituiremos esta opinião pelo

uso de dados históricos de realização de projetos da empresa. Uma revisão de estudos de

acurácia de estimativas conclui que em estudos onde as técnicas de estimativa não foram

calibradas com os dados do ambiente da estimativa, as estimativas de especialistas foram

mais acuradas que as realizadas por técnicas. Mas os estudos que usaram técnicas

calibradas com dados históricos concluíram que as técnicas tiveram uma acurácia igual ou

maior que as estimativas de especialistas [Jørgensen-02].



3.2.2.4 Adequado para Projetos de Diferentes Tamanhos (Critério 7) Tamanho do projeto é outro fator a considerar na escolha da melhor técnica de estimativa.

De acordo com o tamanho de um projeto, diferentes técnicas são mais apropriadas.

Obviamente também não é desejável que se tenha diversas técnicas em uso pela

organização simultaneamente, pois cada diferente técnica demanda capacitação de pessoal

para usá-la, bem como trabalho extra para coleta e armazenamento de diferentes métricas

para a aferição da acurácia da estimativa e para a alimentação da técnica com dados

históricos.

A maioria dos Gerentes de Projetos define o tamanho de um projeto com base no(a): • total de recursos financeiros disponíveis; • número de membros do time envolvidos; • número e tamanho dos entregáveis a serem produzidos; • complexidade dos entregáveis a serem produzidos; e • intervalos de tempo envolvidos na entrega.

À medida que o tamanho do projeto aumenta, a complexidade do mesmo aumenta

proporcionalmente, conforme ilustra a Figura 3.2 [MPMM-07].

Figura 3.2 – Tamanho x Complexidade em Projetos [MPMM-07]

Classificamos a seguir os projetos em 3 diferentes tamanhos, analisando quais as

técnicas de estimativas mais apropriadas para os mesmos:

Pequeno: Um projeto com até 2.500 horas de esforço. Projetos de pequeno porte não

devem usar as técnicas orientadas a estatísticas que projetos maiores usam

porque variações na produtividade individual drenam outros fatores, pois cada

indivíduo representa uma grande parcela da força de trabalho. Projetos

pequenos normalmente usam o mesmo número de pessoas no time pelo



projeto inteiro, o que inviabiliza algumas das técnicas algorítmicas usadas por

projetos maiores. A melhor técnica para projetos pequenos tende a ser a

baseada nas estimativas criadas pelos próprios indivíduos que irão realizar o

trabalho.

Grande: Um projeto com mais de 10.000 horas de esforço. As melhores técnicas pra

projetos grandes variam conforme o estágio do projeto, entre seu início e seu

final. Nos estágios iniciais, a melhor abordagem de estimativa tende a ser uma

das técnicas baseadas em algoritmos e estatísticas. Estas são válidas no

ponto do projeto em que os membros do time ainda não são conhecidos –

quando os planos são baseados em um time que consiste de, por exemplo,

“25 engenheiros, 6 analistas, e 8 testadores” ao invés de indivíduos

específicos. Nos estágios intermediários, uma combinação de técnicas

baseadas nos dados históricos do próprio projeto irá produzir as estimativas

mais acuradas. Nos estágios finais, técnicas de julgamento de especialistas

irão prover as estimativas mais acuradas.

Médio: Um projeto que tenha entre 2.500 e 10.000 horas de esforço. Tem a vantagem

de poderem usar praticamente todas as técnicas de estimativas que os

projetos grandes usam, e diversas das que os projetos pequenos usam

também.

Obviamente a definição do tamanho do projeto com base no esforço esperado para sua

execução nos defronta com o clássico problema de quem vem primeiro: o ovo ou a galinha.

Pois como vimos anteriormente, só temos o esforço a partir do tamanho estimado, e para

saber o tamanho estimado temos que usar uma técnica de estimativa (que deveria ser a

melhor para um projeto de determinado tamanho). Resumindo: ao avaliar este critério,

devemos avaliar se a técnica tem boa acurácia e desempenho para diferentes tamanhos de

projetos (pequeno, médio, grande).



3.2.2.5 Compatível com Estilo do Processo de Desenvolvimento (Critério 8)

Para o propósito de estimativas, os dois maiores estilos de desenvolvimento são o

seqüencial e o iterativo. A terminologia da indústria que cerca projetos iterativos, ágeis, e

seqüenciais pode suscitar dúvidas. Neste trabalho, consideraremos como diferença primária

entre estes tipos de projetos a percentagem de requisitos que são definidos cedo no projeto,

comparada à percentagem dos que são definidos depois que a construção se inicia. A análise

a seguir avalia como as diferentes abordagens de desenvolvimento se encaixam nestes

critérios:

Prototipagem Evolucionária: é usada quando os requisitos são desconhecidos, sendo

uma das razões primárias para o seu uso a ajuda na definição de requisitos [McConnell-

96]. Para efeito de estimativas, este é considerado um estilo de desenvolvimento iterativo.

Extreme Programming: Extreme Programming deliberadamente define apenas os

requisitos que irão ser desenvolvidos na próxima iteração, a qual tipicamente dura menos

que um mês [Beck-04]. Para efeito de estimativas, este é considerado um estilo de

desenvolvimento altamente iterativo.

Entrega Evolucionária: um projeto de entrega evolucionária pode definir nenhum ou a

maioria dos seus requisitos no início do projeto [McConnell-96]. Dependendo da

quantidade de requisitos definidos na partida, um projeto de entrega evolucionária pode

ser tanto seqüencial quanto iterativo. A maioria deles deixam requisitos suficientes

indefinidos no começo da construção o que normalmente enquadra-os no estilo de

desenvolvimento iterativo.

Entrega Estagiada: um projeto de entrega estagiada define a maioria dos seus requisitos

antes do início da construção [McConnell-96]. Ele usa iterações dentro do projeto,

construção e teste, assim, de certa forma, é iterativo. Contudo, para efeito de estimativas,

este é considerado um estilo de desenvolvimento seqüencial.

Rational Unified Process (RUP): o RUP descreve seus estágios como iterações.

Contudo, um projeto RUP procura definir cerca de 80% de seus requisitos antes da

construção iniciar [Jacobson-99]. Para efeito de estimativas, este é considerado um estilo

de desenvolvimento seqüencial.

Scrum: é um estilo de desenvolvimento no qual um time de projeto define um conjunto de

funcionalidades que ele pode implementar em uma “arrancada” de 30 dias [Schwaber-96].



Uma vez que uma arrancada começa, o cliente não pode mudar requisitos naquela

arrancada. Do ponto de vista de uma arrancada individual, para efeitos de estimativa,

Scrum é seqüencial. No entanto, como as funcionalidades não são alocadas para mais de

uma arrancada em um determinado momento, de um ponto de vista de múltiplas

arrancadas (iterações), Scrum é iterativo.

Tanto os projetos iterativos quanto os seqüenciais tendem a iniciar com técnicas

baseadas em estatística e ambos eventualmente migram para técnicas de julgamento de

especialistas. O refinamento das estimativas de projetos iterativos acontece de forma mais

rápida quando eles usam dados do próprio projeto (iterações anteriores).

3.2.2.6 Calibrada de Acordo com a Confiabilidade Desejada para o Software (Critério 9) O software a ser construído pode vir a ter requisitos de alta confiabilidade, podendo sua

execução de forma imperfeita vir a ter conseqüências graves financeiras ou para a vida

humana. Pode ainda exigir taxa de transações alta, influenciando o projeto, desenvolvimento,

instalação e suporte da aplicação a ser desenvolvida. A técnica deve permitir a calibragem da

estimativa de acordo com a confiabilidade desejada para o software, refletindo a necessidade

de processos de testes mais extensos, e de processos mais formais e detalhados na fase de

projeto e construção.

3.2.2.7 Calibrada de Acordo com a Complexidade dos Algoritmos (Critério 10) O software a ser construído pode ter uma alta complexidade para o processamento de

suas regras de negócios e de suas funcionalidades. O mesmo pode requerer processamento

lógico e/ou matemático extensivo, com o controle de operações sofisticadas e complexas, tais

como operações dependentes de máquinas, operações de administração de dados em altos

volumes, manuseio de múltiplas possibilidades de entrada/saída (ex.: multimídia) e

processamento de muitas exceções, que resultem em transações incompletas que devem ser

processadas novamente. O código gerado pode ter que ser reentrante e recursivo,

manuseando interrupções e sincronização de tarefas, com controles de processamento em

tempo real. A técnica deve permitir a calibragem da estimativa de acordo com a

complexidade dos algoritmos necessária para o software, refletindo a necessidade de

processos de testes mais extensos, e de processos mais formais e detalhados na fase de

projeto e construção.



3.2.2.8 Calibrada de Acordo com a Capacidade e Experiência da Equipe (Critério 11) A equipe que irá trabalhar no projeto de desenvolvimento influencia o desempenho do

projeto de forma direta. A formação, motivação, e experiência deste time são fatores

essenciais para este desempenho. A experiência do líder do projeto, a experiência e

proficiência do time com os processos, técnicas, software e negócio do software a ser

desenvolvido devem ser refletidas na estimativa. Além disso a técnica deve refletir a

habilidade do time para se comunicar e cooperar.

3.2.2.9 Adequada a Diferentes Ambientes Tecnológicos (Critério 12) O ambiente tecnológico (hardware e software) em que a aplicação será desenvolvida e

utilizada não deve influenciar o processo de estimativas. O ambiente tecnológico pode variar

bastante, tanto em hardware quanto em software. Podemos estar desenvolvendo desde

aplicações que irão executar em celulares, com restrição de interface (gráfica e de entrada de

dados), baixa capacidade de processamento e memória, sem nenhum banco de dados; à

aplicações que irão executar em servidores web, compartilhando diversos servidores.



3.2.3 Detalhamento das Notas Atribuídas na Abordagem Fatores-Pesados pela Empresa Estudo de Caso

Detalhamos a seguir a atribuição das notas para cada critério de seleção de cada técnica

de estimativas estudada, explicando as premissas para a atribuição destas notas. Estas

refletem a aderência de cada técnica aos critérios definidos pela empresa estudo de caso,

sendo definidas por esta em reuniões, com o uso da técnica Wideband Delphi.

3.2.3.1 IFPUG

Critério Nota Premissas para Nota

1 7 Entendimento é facilitado pelo uso de funções de dados e de funções de transações, que são compreensíveis pelo usuário final/cliente. No entanto a classificação em níveis de complexidade de cada função pode dificultar o entendimento do usuário leigo.

2 5 A necessidade de detalhamento dos atributos de cada arquivo, bem como das funções de transação não permite o uso nos momentos iniciais do projeto, quando se tem um conhecimento macro dos requisitos.

3 8

Para todas as técnicas de medição funcional, dois contadores treinados irão obter estimativas de tamanho com variação em torno de 10%, se os requisitos do usuário forem conhecidos e bem especificados [FISMA-07]. Especialistas em contagem de pontos de função podem produzir resultados que estão dentro de uma margem de erro de 10%, enquanto contadores de pontos de função inexperientes irão variar de 20% a 25% [Kemerer-92] [Stutzke-05]. Pela sua maturidade, a técnica oferece treinamento e certificação.

4 9

Medição funcional de tamanho é atualmente a mais aceita maneira de estimar tamanho na indústria, particularmente naquelas companhias que alcançaram níveis altos na escala CMMI ou em certificação de padrão internacional [Hill-06]. Além mostra um uso relevante disso no mercado brasileiro, conforme atesta a pesquisa da SEPIN/MCT (ver Tabela 3.2).

5 7

O acompanhamento na execução embute certas dificuldades pela incerteza do momento da contabilização das funções de dados. Em que momento as mesmas devem ser contabilizadas? Se as mesmas já foram contabilizadas, como devem ser contadas as funções de transação que as irão usar? Em que momento deve ser contabilizada a construção de uma função de dados?

6 8

Dados históricos serão utilizados para estimar esforço e prazo a partir do tamanho. A métrica de esforço por ponto de função (número de horas) será usada para estimar esforço total e prazo. Por ser largamente utilizada na indústria e por ser suportada por diversos grupos internacionais de usuários, a técnica possui inúmeras bases históricas de contagens realizadas.

7 10 A técnica é adequada para projetos de qualquer tamanho.

8 10 A técnica é adequada a qualquer processo de desenvolvimento (a complexidade do processo se refletirá no número de horas de esforço por ponto de função).

9 6

A confiabilidade pode ser refinada pelas características gerais do sistema 3 (Performance) e 5 (Taxa de Transações). No entanto estas não cobrem a questão de tolerância a falhas, que pode ser essencial em sistemas que lidem com fatores críticos tais como vida humana ou finanças.

10 8 A complexidade dos algoritmos pode ser refinada pela característica geral do sistema 9 (Processamento Complexo).

11 5 A capacidade e experiência do time do projeto não são refletidas na estimativa, mas pode ser indiretamente considerada pelos dados históricos de produtividade de times com capacidade e experiência similares.

12 5 A técnica é adequada para ambientes tecnológicos que utilizem arquivos de alguma forma, além de refletir, nas características gerais do sistema, ambientes antiquados (especificamente mainframes).



3.2.3.2 UCP


1 7 Entendimento é facilitado pelo uso de atores e casos de uso, que são compreensíveis pelo usuário final/cliente. No entanto a classificação em níveis de complexidade de cada caso de uso pode dificultar o entendimento do usuário leigo.

2 7

Execução Cedo é viável, mas com uma acurácia comprometida, visto que neste caso o tamanho do caso de uso é estimado sem a contagem detalhada das suas transações. Documentos de casos de uso são preparados em sua maioria depois da assinatura do contrato com o cliente, logo não estarão preparados em estágios iniciais do projeto. Como elemento facilitador temos o fato que se os Casos de Uso forem estruturados de forma uniforme para uma empresa, podem ser usadas ferramentas de automação da contagem.

3 6

Estudos realizados por Bente Anda [Anda-01] e Kirsten Ribu [Ribu-01] mostram que uma boa acurácia é obtida por esta técnica, embora impactada por alguns pontos: a. Não há padrões para descrever casos de uso – podem variar não apenas de empresa

para empresa, mas também de projeto para projeto. Assim a estimativa varia significativamente de acordo com a estrutura do documento de Casos de Uso. Até a forma de escrever importa muito, bem como são identificados os casos de uso e as transações associadas com os mesmos. Descrições textuais livres podem levar a especificações ambíguas [Arnold-98];

b. Há dúvidas na contagem de casos de uso incluídos e estendidos; c. Há dúvidas para definir o nível correto de detalhe para cada transação do caso de uso; d. Identificação de ator precisa de detalhes técnicos: para o ator ser classificado, nós

precisamos conhecer detalhes técnicos como qual protocolo o ator irá usar. Desta forma a estimativa só pode ser feita por pessoal técnico;

e. A técnica ainda não possui bons históricos de produtividade, pois apenas recentemente começou a ser utilizado pelo mercado.

4 7 Embora seja uma técnica mais recentemente adotada pelo mercado, já começa a mostrar um uso crescente no mercado brasileiro, conforme pesquisa SEPIN/MCT (ver Tabela 3.2).

5 7 O acompanhamento na execução embute certas dificuldades pela incerteza do momento da contabilização dos atores. Em que momento estes devem ser contabilizados? Quando um caso de uso que é utilizado por este ator for construído?

6 7

Dados históricos serão utilizados para estimar esforço e prazo a partir do tamanho. A métrica de esforço por ponto de caso de uso (número de horas) será usada para estimar esforço total e prazo. A baixa disponibilidade de dados de mercado aumenta a dificuldade de uso de dados históricos;


8 10

A técnica é adequada a processos de desenvolvimento que usem casos de uso (a complexidade do processo se refletirá no número de horas de esforço por ponto de caso de uso). Em especial para o RUP, a técnica se encaixa perfeitamente, visto que ambos consideram o uso de casos de uso;

9 6

A confiabilidade pode ser refinada pelos fatores técnicos 2 (Objetivos de performance), 10 (Concorrência) e 11 (Características especiais de segurança). No entanto estes não cobrem a questão de tolerância a falhas, que pode ser essencial em sistemas que lidem com fatores críticos tais como vida humana ou finanças.

10 6

A complexidade dos algoritmos pode ser refinada pelo fator técnico 4 (Complexidade do processamento interno). No entanto, alguns autores defendem o refinamento da contagem de pontos por casos de uso complexos, criando a categoria dos “muito complexos”, para evitar possíveis subestimativas, especialmente quando o número de transações é muito grande [Monteiro-05].

11 8 O fator “capacidade e experiência da equipe” é refinado pelos fatores ambientais 1 a 5 e 7 (ver Tabela 2.29).

12 7 A técnica é adequada para praticamente todos os ambientes tecnológicos, pois o nível de abstração de casos de uso coloca a técnica acima de questões de tecnologia. A única exceção é o fator ambiental 3 (Experiência com orientação a objetos).



3.2.3.3 NESMA Estimada


1 9 Entendimento é facilitado pelo uso de funções de dados e de funções de transações, que são compreensíveis pelo usuário final/cliente. A classificação dos níveis de complexidade de cada função em valores padrão facilita o entendimento do usuário leigo.

2 8 A execução da técnica depende do detalhamento das funções de dados e transacionais, logo um detalhamento mínimo dos requisitos é necessário para o uso da mesma.

3 6 Alguns autores citam que gira em torno de 10% a 15% [NESMA-07].

4 6 Esta técnica vem sendo mais adotada pelo mercado nos últimos anos, como uma técnica que suporta o uso de contagem de pontos de função muito cedo no projeto.

5 6 O acompanhamento na execução será normalmente feito com a contagem detalhada. A estimativa feita inicialmente servirá como base para o acompanhamento.

6 8 Dados históricos serão utilizados para estimar esforço e prazo a partir do tamanho. A métrica de esforço por ponto de função (número de horas) será usada para estimar esforço total e prazo.


8 10 A técnica é adequada a qualquer processo de desenvolvimento (a eventual complexidade do processo se refletirá no número de horas de esforço por ponto de função).

9 5 A NESMA não utiliza as características gerais do sistema para ajustar a contagem de pontos de função. Consideramos neste caso que estas características serão contabilizadas de forma a não influenciar a contagem. Daí a atribuição do valor 5.



12 5 A técnica é adequada para ambientes tecnológicos que utilizem arquivos de alguma forma.



3.2.3.4 COCOMO II Early Design


1 4 Como usa pontos de função, inicia da mesma valoração atribuída à técnica de FPA. A atribuição de valores aos direcionadores de custo e fatores de escala embute certa complexidade para o entendimento pelo usuário leigo.

2 5 Mesmo do IFPUG. 3 9 Mesmo do IFPUG.

4 4 Apresenta baixa adoção pela aparente complexidade demonstrada pelo uso dos direcionadores de custo, principalmente no que diz respeito à calibragem da técnica.

5 7 Mesmo do IFPUG.

6 8 As constantes a, b, e EAF são calibradas por dados históricos da organização. Adicionalmente dados históricos são usados para refinar o número de linhas de código por ponto de função.


9 8 A confiabilidade é refinada pelo direcionador de custo RCPX (Confiabilidade e complexidade do produto).

10 8 A complexidade é também refinada pelo direcionador de custo RCPX (Confiabilidade e complexidade do produto).

11 8 A capacidade e experiência do time do projeto são refletidas pelo fator de escala TEAM (Reflete quão bem o time de desenvolvimento se conhece e trabalha em conjunto) e pelos direcionadores de custo PERS (Capacidade do pessoal) e PREX (Experiência do pessoal).

12 7 Por se basear em linhas de código, a técnica é adequada para diferentes ambientes tecnológicos, desde que seja possível inferir o total de linhas de código da aplicação (tamanho).

3.2.3.5 Comparação - ISBSG


1 9 A comparação com projetos similares na base do ISBSG é facilmente compreensível pelo usuário final/cliente, bastando para isto definir os critérios de comparação.

2 8 Uma vez que sejam definidas as características do projeto que permitam a comparação do mesmo com a base do ISBSG, o processo de estimativa já pode ser iniciado.

3 8 Segundo o ISBSG esta técnica permite alcançar estimativas mais detalhadas que as obtidas usando equações de regressão.

4 4 Apresenta baixa adoção pelo mercado (notadamente o mercado brasileiro). 5 0 A técnica não prevê o acompanhamento de projetos em execução. 6 9 Dados históricos da base de projetos do ISBSG. 7 10 A técnica é adequada para projetos de qualquer tamanho.

8 10 A técnica é adequada a qualquer processo de desenvolvimento (será um dos critérios de comparação a serem utilizados).

9 6 Pode ser um dos critérios de comparação utilizados. 10 7 Pode ser um dos critérios de comparação utilizados.

11 5 Este é um critério bastante subjetivo a ser comparado com a base do ISBSG. Consideramos neste caso que estas características serão contabilizadas de forma a não influenciar a contagem. Daí a atribuição do valor 5.

12 7 Pode ser um dos critérios de comparação utilizados.



3.2.3.6 COCOMO II Post-Architecture


1 4 Como usa pontos de função, inicia da mesma valoração atribuída à técnica de FPA. A atribuição de valores aos direcionadores de custo e fatores de escala embute certa complexidade para o entendimento pelo usuário leigo.

2 4 Como usa pontos de função, inicia da mesma valoração atribuída à técnica de FPA. Adicionalmente a técnica é utilizada apenas após a fase de projeto estar concluída.

3 9 Como usa pontos de função, inicia da mesma valoração atribuída à técnica de FPA. A calibragem dos valores atribuídos aos direcionadores de custo e fatores de escala permite maior acurácia.

4 4 Apresenta baixa adoção pela aparente complexidade demonstrada pelo uso dos direcionadores de custo, principalmente no que diz respeito à calibragem da técnica.

5 7 Mesmo do IFPUG.

6 8 As constantes a, b, e EAF são calibradas por dados históricos da organização. Adicionalmente dados históricos são usados para refinar o número de linhas de código por ponto de função.


9 8 A confiabilidade é refinada pelo direcionador de custo RELY (Confiabilidade requerida pelo software).

10 8 A complexidade é também refinada pelo direcionador de custo CPLX (Complexidade do produto).

11 8

A capacidade e experiência do time do projeto são refletidas pelo fator de escala TEAM (Reflete quão bem o time de desenvolvimento se conhece e trabalha em conjunto) e pelos direcionadores de custo ACAP (Capacidade do analista), e PCAP (Capacidade do programador), PCON (Continuidade do pessoal), AEXP (Experiência na aplicação), PEXP (Experiência na plataforma) e LTEX (Experiência com linguagem e ferramental).

12 7 Por se basear em linhas de código, a técnica é adequada para diferentes ambientes tecnológicos, desde que seja possível inferir o total de linhas de código da aplicação (tamanho).

3.2.3.7 Analogia - ISBSG


1 8 Mesmo princípio que Comparação – ISBSG, mas como o nível de semelhança buscado é maior, esta técnica exige critérios mais detalhados de comparação, sendo ligeiramente mais complexa para o entendimento que a de Comparação.

2 8 Mesmo que Comparação - ISBSG. 3 8 Mesmo que Comparação - ISBSG. 4 4 Mesmo que Comparação - ISBSG. 5 0 Mesmo que Comparação - ISBSG. 6 9 Mesmo que Comparação - ISBSG. 7 10 Mesmo que Comparação - ISBSG. 8 10 Mesmo que Comparação - ISBSG. 9 6 Mesmo que Comparação - ISBSG.

10 7 Mesmo que Comparação - ISBSG. 11 5 Mesmo que Comparação - ISBSG. 12 7 Mesmo que Comparação - ISBSG.



3.2.3.8 NESMA Indicativa


1 9 Entendimento é facilitado pelo uso apenas de funções de dados, que são compreensíveis pelo usuário final/cliente.

2 9 A execução da técnica depende apenas do mapeamento das funções de dados. 3 4 Exibe variações de até 50% em relação à contagem detalhada [NESMA-07].

4 5

Esta técnica vem sendo mais adotada pelo mercado nos últimos anos, como uma técnica que suporta o uso de contagem de pontos de função muito cedo no projeto. No entanto pelo fato de exibir variações muito grandes em relação à contagem detalhada, é normalmente substituída pela contagem estimada.

5 6 O acompanhamento na execução será normalmente feito com a contagem detalhada, utilizando a estimativa feita inicialmente como base.

6 8 Dados históricos serão utilizados para estimar esforço e prazo a partir do tamanho e para refinar os pesos dos ILFs e EIFs. A métrica de esforço por ponto de função (número de horas) será usada para estimar esforço total e prazo.


8 10 A técnica é adequada a qualquer processo de desenvolvimento (a complexidade do processo se refletirá no número de horas de esforço por ponto de função).




12 5 A técnica é adequada para ambientes tecnológicos que utilizem arquivos de alguma forma.

3.2.3.9 NESMA Detalhada

Critério Nota Premissas para Nota 1 7 Mesmo do IFPUG. 2 5 Mesmo do IFPUG. 3 8 Mesmo do IFPUG. 4 6 Mesmo do IFPUG. 5 7 Mesmo do IFPUG. 6 8 Mesmo do IFPUG. 7 10 Mesmo do IFPUG. 8 10 Mesmo do IFPUG. 9 5 Mesmo da NESMA Indicativa.

10 5 Mesmo da NESMA Indicativa. 11 5 Mesmo do IFPUG. 12 5 Mesmo da NESMA Indicativa.



3.2.3.10 Pontos de Estória Critério Nota Premissas para Nota

1 7 O entendimento é facilitado pelo uso de estórias (requisitos), porém é bastante subjetivo no que diz respeito à escala de pontos atribuída as estórias.

2 8 O uso de estórias e a estimativa com base na simples listagem destas estórias possibilitam o uso desta técnica muito cedo no projeto.

3 6 A acurácia é comprometida pela subjetividade da técnica de estimativa. No entanto à medida que se avança nas iterações, o conhecimento da velocidade do time torna possível uma estimativa mais acurada.

4 4 Apresenta baixa adoção pelo mercado.

5 6 Permite o acompanhamento da velocidade de execução do time, mas com uma granularidade muito alta, visto que só se consegue acompanhar no nível de estórias.

6 8 A partir da segunda iteração o conhecimento da velocidade das iterações anteriores, bem como o refinamento da escala de pontos atribuídos às estórias permite refinar a estimativa.

7 10 A técnica é adequada para projetos de qualquer tamanho. 8 6 A técnica é adequada a processos ágeis, que mapeiam requisitos em estórias. 9 5 Com base na opinião do time.

10 5 Com base na opinião do time. 11 5 Com base na opinião do time.

12 7 É adequada a diferentes ambientes tecnológicos, na medida em que se baseia em um grau alto de abstração (estórias).

3.2.3.11 Wideband Delphi Critério Nota Premissas para Nota

1 8 Como a técnica é baseada na opinião de especialistas, o entendimento passa apenas pela aceitação da expertise dos citados especialistas.

2 7

Execução cedo, mas com total dependência de time de especialistas, o que não se dispõe facilmente, ainda mais de forma rápida para, por exemplo, atender propostas. Adicionalmente a técnica embute um custo alto para a produção da estimativa, pois requer uma reunião com especialistas, o que consome horas de trabalho de diversas pessoas (teoricamente “caras”).

3 6

Os resultados do uso desta técnica são tão bons quanto os participantes envolvidos. Estudos realizados [McConnell-06] mostram que o uso desta técnica melhora a acurácia na maioria dos casos, com uma redução média de erro de cerca de 60%. No entanto os mesmos estudos mostram que o erro caiu de 290% para 170%, o que ainda é bastante alto. A acurácia pode também ser comprometida se for um projeto em tecnologia ou área de negócios totalmente novos, para as quais não se disponha de especialistas.

4 4 Baixa adoção pelo mercado. 5 0 A técnica não prevê o acompanhamento de projetos em execução.

6 7 Dados históricos são substituídos por experiências passadas de especialistas, mas passa-se a depender de pessoas que nem sempre estarão disponíveis, podendo até sair da empresa, levando consigo o conhecimento acumulado.


8 9 A técnica é adequada a qualquer processo de desenvolvimento (depende apenas da disponibilidade de especialistas no processo em questão).

9 7 Com base na opinião de especialistas. 10 7 Com base na opinião de especialistas. 11 7 Com base na opinião de especialistas. 12 7 Com base na opinião de especialistas.



3.2.3.12 COCOMO II Application Composition - Pontos de Aplicação


1 6 A classificação das telas e relatórios como simples, média e difícil, é de difícil entendimento para o usuário leigo.

2 6 Exige um detalhamento dos relatórios, telas e componentes que serão desenvolvidos, o que impede o seu uso cedo em projetos.

3 5

Esta técnica foca no esforço associado com a construção de interfaces do usuário (telas e relatórios). Ele assume que o repositório de dados já existe. Isto é verdade para muitos sistemas legados. A técnica foi desenvolvida para tais ambientes e desta forma omite o esforço necessário para projetar e implementar o banco de dados. Stutzke [Stutzke-05] mostra que em um projeto de desenvolvimento específico, um terço do esforço total de desenvolvimento foi gasto implementando o banco de dados. Isto significa que a técnica de Pontos de Aplicação pode subestimar o esforço total por cerca de 50% (= [1 – 0,67] / 0,67).

4 4 Baixa adoção pelo mercado.

5 6 Acompanhamento na execução com granularidade de objeto, ou seja, a evolução é aferida à medida que os 3 diferentes tipos de objetos são construídos, não havendo possibilidade de acompanhamento em granularidades menores.

6 5 A técnica se baseia em dados de projetos estudados pelo grupo que definiu o COCOMO II, mas não permite a calibragem com dados históricos da própria organização.

7 10 A técnica é adequada para projetos de qualquer tamanho. 8 10 A técnica é adequada a qualquer processo de desenvolvimento.

9 5

A técnica não usa nenhum direcionador de custo ou fator de escala que leve em consideração a confiabilidade requerida para o produto. Por outro lado o tipo de aplicação que se presta à aplicação desta técnica não se aplica a projetos que exijam altos graus de confiabilidade. Daí a atribuição do valor 5.

10 6

A técnica não usa nenhum direcionador de custo ou fator de escala que leve em consideração a complexidade do produto. Por outro lado o tipo de aplicação que se presta à aplicação desta técnica não se aplica a projetos de alta complexidade. Um ponto a ser considerado é o fator “Maturidade e Capacidade ICASE“, que pesa não a complexidade do produto, mas a facilidade que a ferramenta ICASE (Ambientes de Software Integrados Suportados por Computador) usada propiciará ao seu desenvolvimento.

11 8 A capacidade e experiência do time do projeto são refletidas pelo fator “Experiência e capacidade dos desenvolvedores”.

12 5 A técnica é adequada à ambientes em que se utilizem ferramentas ICASE.



3.2.4 Técnica de Estimativa Selecionada na Instituição Estudo de Caso

Para análise qualitativa das técnicas candidatas, a abordagem Fatores-Pesados mostrada

na Seção 3.1.1 foi utilizada (ver Tabela 3.3). Este trabalho foi realizado na empresa estudo de

caso em abril de 2005, e considerando os pesos e notas definidos, a técnica melhor pontuada

foi a IFPUG, tendo esta sido escolhida como técnica padrão utilizada na instituição. A

pequena diferença em relação à UCP despertou acaloradas discussões em relação à técnica

a ser escolhida. Por fim um argumento foi decisivo para a escolha final da IFPUG: a adoção

da mesma pelo mercado, critério com peso alto (9), considerado decisivo para o

posicionamento da empresa no mercado, e no qual a IFPUG teve a melhor nota.

Critérios de Seleção - Notas Técnica 1 2 3 4 5 6 7 8 9 10 11 12

Total

IFPUG 7 5 8 9 7 8 10 10 6 8 5 5 639 UCP 7 7 6 7 7 7 10 10 6 6 8 7 626

NESMA Estimada 9 8 6 6 6 8 10 10 5 5 5 5 615 COCOMO II Early Design 4 5 9 4 7 8 10 10 8 8 8 7 608

Comparação - ISBSG 9 8 8 4 0 9 10 10 6 7 5 7 606 COCOMO II

Post-Architecture 4 4 9 4 7 8 10 10 8 8 8 7 597

Analogia - ISBSG 8 8 8 4 0 9 10 10 6 7 5 7 595 NESMA Indicativa 9 9 4 5 6 8 10 10 5 5 5 5 593 NESMA Detalhada 7 5 8 6 7 8 10 10 5 5 5 5 592 Pontos de Estória 7 8 6 4 6 8 10 6 5 5 5 7 553 Wideband Delphi 8 7 6 4 0 7 10 9 7 7 7 7 551

COCOMO II Application Composition

Pontos de Aplicação 6 6 5 4 6 5 10 10 5 6 8 5 526

Tabela 3.3 – Análise Qualitativa das Técnicas de Estimativa Estudadas

Embora a técnica IFPUG tenha sido a escolhida, a mesma não atende bem a um critério

mandatório: execução cedo. É essencial que a técnica escolhida permita estimar os recursos

em tempo de elaboração de proposta. Como a técnica IFPUG não é adequada neste cenário,

e a técnica classificada em segundo lugar, a técnica UCP, também não o é, foi adotada a

técnica classificada em terceiro lugar, a NESMA Estimada para o momento de pré-venda

(elaboração de propostas e negociação com clientes). Todavia, em projetos grandes deve-se

tentar usar a técnica IFPUG mesmo em momento de pré-venda, gastando-se para isto mais

tempo no detalhamento dos requisitos do projeto durante a pré-venda. Se não houver tempo



para este detalhamento, avalia-se o risco de ir em frente usando a NESMA Estimada. Isto é

feito devido ao fato que a técnica IFPUG embute uma margem de erro menor que a técnica

NESMA Estimada. Nestes mesmos projetos grandes, deve ainda ser usada uma segunda

técnica de estimativas e comparados os resultados, visto que cada técnica de estimativa usa

informações diferentes do projeto como entrada para a realização da estimativa, assim se

uma única técnica é usada e estas informações não são acuradas, a estimativa final poderá

ser errada. Em projetos grandes este erro pode representar grandes prejuízos. Se as duas

técnicas usadas previrem esforços muito diferentes, isto indica que não se tem informação

consistente sobre o projeto. Deve-se então detalhar mais as informações sobre o projeto e

repetir as estimativas até que estas convirjam. A técnica usada pela empresa estudo de caso

como técnica alternativa para aferição da medida obtida pela FPA é a técnica UCP (segunda

colocada na seleção – ver Tabela 3.3).

Desta forma foram definidas três técnicas para uso na organização:

1. Momento de Pré-venda (projetos pequenos e médios): NESMA Estimada;

2. Momento de Pré-venda (projetos grandes) e Acompanhamento de Projetos13:

IFPUG;

3. Validação de Estimativa 2: UCP.

O uso das técnicas NESMA e IFPUG mantém a compatibilidade entre as estimativas

realizadas no momento inicial do projeto e após o detalhamento dos requisitos, pois as duas

são técnicas de medição de tamanho funcional (FSM), sendo compatíveis entre si.

É importante citar que o crescimento do uso da técnica UCP no Brasil tem feito surgir

casos em que o cliente demanda que a estimativa seja feita usando a mesma. Neste caso

também é feita a estimativa NESMA ou IFPUG, como forma de validação da estimativa. Deve

ser ressaltado também que a pontuação obtida pela técnica UCP e a aparente tendência de

crescimento de uso desta técnica pelo mercado, indicam que esta pode vir a ser a melhor

opção dentro de alguns anos.

A escolha da FPA é corroborada por alguns fatores:

1. Como mostrado anteriormente, a última pesquisa de Qualidade e Produtividade no

Setor de Software Brasileiro, demonstrou que 16% das organizações do mercado de

software brasileiro, utilizavam FPA (ver Tabela 3.2) [MCT-06]. Outro indicador que

13 Como o software vai ter a sua construção acompanhada e medida



também demonstra o crescente interesse pela FPA é o número de profissionais

certificados pelo IFPUG como Especialistas em Pontos de Função (CFPS). Enquanto,

no período de 1996 - 2001 havia 12 CFPS no Brasil, passamos para 261 em 2007. No

mundo são 1143 certificados (números de fevereiro de 2007) [BFPUG-07], sendo o

Brasil o segundo país do mundo em número de CFPS (ver Tabela 3.4 [BFPUG-07]).

País CFPS País CFPSCoréia 347 Alemanha 4 Brasil 209 Nova Zelândia 4 Índia 195 Espanha 4 EUA 112 Áustria 3 Itália 105 Dinamarca 2 Austrália 22 Costa do Marfim 1 Canadá 11 Holanda 1 Inglaterra 10 Egito 1 México 10 Bélgica 1 Japão 9 Irlanda 1 Total Geral 1052

Tabela 3.4 – Número de CFPS por País (em janeiro de 2007) [BFPUG-07]

2. Pontos de Função são reconhecidos pelo mercado como sendo a melhor abordagem

de estimativa de tamanho [Gartner-02].

3.3 Conclusão

Este capítulo discutiu a seleção da técnica de estimativas da empresa estudo de caso,

considerando as necessidades específicas desta organização, mostrando as técnicas

candidatas, avaliando como estas se adequavam aos critérios de seleção definidos, e

escolhendo a técnica mais apropriada de acordo com a avaliação realizada. Ao final

identificamos as técnicas escolhidas para a estimativa em momento de pré-venda e durante a

execução dos projetos.

Como visto neste capítulo, as técnicas escolhidas são as melhores para aquele momento

de avaliação (abril de 2005), devendo ser reavaliadas periodicamente (sugerimos a cada

triênio), permitindo que sempre se esteja utilizando a técnica mais adequada para a

organização, de acordo com o momento da organização e o estado da arte das técnicas de

estimativas.

A aplicação das técnicas escolhidas neste capítulo, e os métodos e ferramentas usados

para suportar esta aplicação serão apresentados no próximo capítulo.



Capítulo 4 4. Aplicação de Técnica de Estimativas na PITANG

"Olhar é uma coisa. Ver o que você olha é outra. Entender o que você vê é uma terceira coisa. Aprender do que você entendeu é bom.

Mas agir sobre o que você aprendeu é o que realmente importa.” – Anônimo

O capítulo anterior mostra que as técnicas escolhidas para estimativas, a serem utilizadas

na PITANG, foram NESMA Estimada, IFPUG e UCP, sendo as mesmas usadas em pré-vendas

e acompanhamento de projetos. Este capítulo mostra como usando as mesmas chegamos à

estimativa de tamanho do software a ser desenvolvido, e transformamos esta estimativa em

esforço e custos. Além disso, descreve o processo de pré-vendas e de acompanhamento de

projetos da PITANG, no que diz respeito ao uso das técnicas de estimativa escolhidas.

4.1 Identificando Métricas com Base em Projetos Reais

Para transformar o tamanho calculado do projeto (em pontos de função e pontos de casos

de uso) em esforço, é usada a base histórica de projetos da organização, aferindo a

produtividade por pontos de função. Como a técnica UCP é usada para validação das

estimativas feitas em pontos de função (casos específicos), optamos por não acompanhar a

produtividade realizada nesta técnica nos projetos executados, assumindo o valor padrão

sugerido pela técnica UCP de 20 horas por ponto de caso de uso.

A PITANG vem desenvolvendo sistemas em regime de fábrica de software com modelo de

contratação em pontos de função desde setembro de 2005. Neste período foram desenvolvidos

36 projetos de fábrica, com cerca de 16.000 pontos de função no total. Uma característica

comum a todos os projetos é o fato de serem baseados na WEB, quer sejam projetos de

Intranet ou Internet. Estes projetos foram desenvolvidos para diversos clientes privados e

públicos no Brasil e no exterior, todas corporações de porte médio a grande. O

acompanhamento de métricas nestes projetos gerou uma base histórica razoável, permitindo a

aferição de indicadores de produtividade para as tecnologias envolvidas (ver Tabela 4.1).

Tecnologia Qtde. Projetos

Número de FP

Tamanho Médio Projeto (FP)

Produtividade Média

(Horas/FP) .NET C# 3 350 117 9

Java (Struts) 27 12300 456 16

Java (JSF) 6 3350 558 13

Tabela 4.1 – Base Histórica de Projetos PITANG



Um ponto importante acompanhado nestes projetos é o índice de acerto das estimativas

realizadas em relação ao tamanho real final dos projetos e ao esforço final dos mesmos. Dois

índices de acerto são acompanhados:

1. Índice de Acerto de Tamanho: IT = Tamanho Real / Tamanho Estimado;

2. Índice de Acerto de Esforço: IE = Esforço Real / Esforço Estimado.

O IT demonstrou um comportamento de acordo com o esperado, com raras exceções. O IT

médio teve valor de 0,88, dentro do desvio esperado pelo uso da técnica NESMA Estimada

(mais utilizada para estimativas iniciais pela instituição estudo de caso), que indica variação de

10% a 15% (neste caso foi de 12%). A variação do IT foi pequena ao longo do tempo, não

variando muito em relação às primeiras e às últimas contagens. Já o IE demonstrou variação

maior, demonstrando maior nível de acerto à medida que a empresa ganhava maturidade no

uso da técnica de estimativa e passava a retroalimentar suas estimativas de esforço com os

dados históricos de projetos executados. O IE mostrou ser muito sensível às tecnologias

envolvidas, à complexidade da arquitetura e até mesmo à maturidade e expertise do time de

projeto. Para suportar melhor estas variáveis, decidiu-se adotar valores de produtividade média

por tecnologia, assumindo em cada uma destas tecnologias uma arquitetura e um time padrão.

O valor atual do IE médio é de 0,83 para .NET C#, 0,94 para Java-Struts e 0,87 para Java-JSF.

Como visto os valores dos índices de esforço não são exatamente 1 como poder-se-ia esperar.

O fato é que os valores atualmente usados de Produtividade Média (Tabela 4.1) são os valores

para os quais as aferições de projetos estão convergindo.

4.2 Derivando Esforço e Custos

De posse dos números mostrados na Tabela 4.1, alimentamos a planilha usada na PITANG

para estimativa de esforço em pontos de função [SGQP-07], convertendo o número de pontos

de função obtido em horas. Para isto a planilha multiplica o número de pontos de função

calculado (com base nos EIs, EOs, EQs, ILFs e EIFs informados na planilha) pelo número de

horas de produtividade média na tecnologia gerando o número de horas de esforço estimado

para o projeto como um todo.



A tela mostrada na Figura 4.1, é o relatório final obtido pelo uso da planilha de estimativa em

pontos de função da PITANG [SGQP-07].

Figura 4.1 – Estimativa de Esforço em Pontos de Função [SGQP-07]

A partir da estimativa de horas obtida, a planilha deriva a distribuição de esforço, conforme a

distribuição de esforço médio por fases do projeto, usando a base histórica da PITANG (Figura

4.2 [SGQP-07]). Este esforço por fase é distribuído por perfil profissional, conforme o

envolvimento de cada um destes profissionais nas citadas fases. Para calcular a duração de

cada fase (em dias) o estimador atribui a quantidade de profissionais esperados para atuar em

cada uma das fases do projeto, por perfil profissional. Ao final desta etapa, teremos a estimativa

de esforço por perfil profissional e a estimativa de duração do projeto por fase em dias, além da

estimativa de duração total do projeto em meses (estes cálculos de conversão de dias em

meses e de número de horas por mês são realizados conforme premissas detalhadas no

Apêndice F).

Figura 4.2 – Distribuição de Esforço [SGQP-07]



Para facilitar o entendimento vamos examinar com mais cuidado a Figura 4.2:

• A primeira tabela listada ilustra a distribuição de esforço por perfil profissional para um

ponto de função (no exemplo 13 horas). Com base nos dados históricos de projetos

da PITANG, foi identificado que em média a fase de requisitos consome 20% do

esforço de um projeto, a fase de análise e projetos consome 20%, a fase de

construção consome 45% e a fase de testes consome 15% do esforço de um projeto.

• Em cada fase destas a distribuição do esforço de cada profissional difere de acordo

com o papel de cada um. A título de exemplo, com base nos dados históricos de

projetos da PITANG, foi identificada a seguinte distribuição de esforço para a fase de

requisitos: 68% do Analista de Requisitos, 12% do Gerente de Projetos, 6% Arquiteto

de SW, 8% Designer, 3% Engenheiro de Qualidade, e 3% Engenheiro de

Configuração.

• O numero de horas por ponto de função na tecnologia escolhida (13 no exemplo) é

dividido pelo esforço médio de cada fase (20% = 2,6 para fase de requisitos no

exemplo), e dividido por perfil profissional em cada fase (na fase de requisitos – 68%

= 1,77 horas para o Analista de Requisitos, 12% = 0,31 para o Gerente de Projetos,

6% = 0,16 para o Arquiteto de SW, 8% = 0,21 para o Designer, 3% = 0,08 para o

Engenheiro de Qualidade e 3% = 0,08 para o Engenheiro de Configuração).

• A segunda tabela listada na Figura 4.2 mostra a distribuição da estimativa realizada

em horas (2948,92 no exemplo) segundo a distribuição de esforço por

fase/profissional.

• Por fim, a terceira tabela calcula a duração em dias de cada fase, considerando o

número de horas previsto para cada uma, e a quantidade de profissionais

disponibilizados em cada fase. A quantidade de profissionais em cada fase é

informada pelo estimador que utiliza a planilha, sendo o único dado informado. A

soma das durações em dias de cada fase leva a duração total do projeto.

Para fins de estimativa, a planilha trata os projetos como seqüenciais. No caso do

planejamento do projeto na pré-venda prever iterações, serão feitas estimativas separadas para

cada iteração, e posteriormente somadas.



Para transformar a estimativa de esforço por fase do projeto em uma estimativa por mês, a

planilha sugere uma distribuição aproximada de recursos por mês (ver Figura 4.3 [SGQP-07]),

com base no esforço e duração previstos por fase (ver terceira tabela da Figura 4.2).

Figura 4.3 – Distribuição Sugerida de Esforço Mês a Mês – SGC – PITANG [SGQP-07]

Por fim, estimamos outros custos e esforços associados ao projeto: custos de viagem,

custos de despesas em projeto não associadas à pessoal ou viagens, tais como: custos de

terceiros (outras empresas ou consultores) no projeto, fundo de contingência de riscos,

treinamentos, material específico para o projeto (HW, SW, livros, etc.).



4.3 Definição de Processo de Pré-Venda

O processo tem por objetivo orientar o trabalho de estimativas no momento de pré-venda,

definindo ferramentas e templates a serem utilizados. A Figura 4.4 exibe o fluxograma deste

processo [SGQP-07].

Figura 4.4 – Visão Macro do Processo de Estimativas PITANG [SGQP-07]



Se os requisitos não estão suficientemente detalhados, tentar vender ao cliente a idéia de

dividir o projeto em duas fases: uma primeira de levantamento de requisitos, cobrada em regime

de Time & Material e uma segunda de Análise & Projeto, Construção, Testes e Implantação,

cobrada a Preço Fixo. Isto diminui os riscos e incertezas de parte a parte, fazendo com que o

fornecedor possa precificar com mais exatidão, o que traz benefícios para ambas as partes,

pois tanto o fornecedor pode errar para mais como errar para menos. Caso não seja possível

este modelo, prever uma revisão das estimativas (pontos de função) ao final da fase de

requisitos, podendo o projeto ser renegociado neste momento. Isto deve ser deixado claro na

proposta técnica.

Os templates, guias e ferramentas definidos, listados abaixo, suportam tanto o processo de

pré-venda quanto o de acompanhamento de projetos da PITANG:

1. Guia Processo de Estimativas – Pré-Venda*

2. Template de Documento de Requisitos**

3. Planilha de Pontos de Função**

4. Templates de Cronogramas**

5. Check-list de Estimativas de Pré-Venda*

6. Sistema de Gestão Comercial – PITANG*

7. Templates de Propostas Técnicas*

8. Templates de Atas de Reunião**

* Pré-venda ** Pré-venda e Acompanhamento de Projetos



4.3.1 Processo de Pré-Vendas – Passo a Passo Para facilitar a aplicação do processo pelo estimador foi criado o Guia Processo de

Estimativas – Pré-Venda. Este guia tem por objetivo descrever o processo de estimativas da

empresa, detalhando o seu passo a passo, servindo assim de roteiro para os estimadores na

etapa de pré-venda. Detalharemos a seguir cada passo do processo.

4.3.1.1 Detalhar Requisitos (Funcionais e Não-funcionais) O detalhamento de requisitos é feito de acordo com os seguintes passos:

1. Recepção de documentação (RFPs, Editais, Documentação de sistemas pré-

existentes, atas de reuniões, etc.)

2. Reunião de levantamento de requisitos – reuniões podem ser presenciais ou por

telefone/vídeo

3. Escrita de Documento de Requisitos descrevendo a forma de mapeamento dos

requisitos funcionais e não funcionais, além de explicitar o escopo não

contemplado. É fundamental deixar claro o entendimento que se tem de cada

requisito neste momento, para facilitar negociações futuras com o cliente em caso

de estimativa incorreta de esforço.

a. Devem ser listados os requisitos funcionais do sistema, especificando seus

objetivos e prioridades. Estes descrevem ações que o sistema deve estar apto

a executar, ou seja, o que o sistema deve fazer. Compreende os requisitos

preliminares identificados pelo gerente do projeto e analistas de negócio,

quando apropriado, para elaboração desta proposta. Tais requisitos vão

delimitar o escopo do projeto e do produto. Estes requisitos serão mapeados

em transações funcionais na técnica de pontos de função, sendo distribuídos

nas iterações planejadas para o projeto.

b. Cada requisito identificado deve ser listado no documento de requisitos no

formato listado no exemplo da Figura 4.5 [SGQP-07]. A descrição do

comportamento da funcionalidade deve ser feito em duas a seis sentenças,

mencionando as atividades mais importantes.

Figura 4.5 – Exemplo de Detalhamento de Requisito Funcional [SGQP-07]



c. Devem ser listados também os requisitos não funcionais do sistema

Descrevem atributos que o sistema deve possuir ou restrições sob as quais ele

deve operar, e compreendem os requisitos não funcionais preliminares,

identificados pelo gerente do projeto e equipe de apoio, quando apropriado,

para elaboração desta proposta. Tais requisitos vão influenciar nas estimativas

de esforço do projeto. Devem ser listados todos os requisitos não funcionais do

sistema, divididos em requisitos de: Usabilidade, Confiabilidade, Desempenho,

Segurança, Distribuição, Portabilidade, Adequação a Padrões, Integração,

Acessibilidade, Implantação, e Requisitos de Hardware e Software.

d. Devem ser especificadas as funcionalidades que estão relacionadas com o

sistema, mas que não fazem parte do escopo do projeto e, portanto, não serão

implementadas. Este é o escopo negativo do projeto - Escopo Não

Contemplado. Podem estar descritos requisitos funcionais e/ou não funcionais

não contemplados. Esta seção é obrigatória.

e. Para estabelecer a prioridade dos requisitos foram adotadas as denominações

“essencial”, “importante” e “desejável”. A prioridade dos requisitos é utilizada

no gerenciamento do escopo das iterações do projeto e na definição das

prioridades durante o desenvolvimento do sistema.

i. Essencial: requisito sem o qual o sistema não entra em funcionamento.

Requisitos essenciais são requisitos imprescindíveis, devem ser

implementados desde as primeiras implantações do sistema.

ii. Importante: requisito sem o qual o sistema entra em funcionamento,

mas de forma não satisfatória. Requisitos importantes devem ser

implantados o mais rápido possível, mas, se não forem, parte do

sistema poderá ser implantada mesmo assim.

iii. Desejável: requisito que não compromete as funcionalidades básicas

do sistema, isto é, o sistema pode funcionar de forma satisfatória sem

ele. São requisitos que podem ser implantados por último, sem

comprometer o funcionamento do sistema.

4. Validação de requisitos com cliente (aprovação de Documento de Requisitos)



4.3.1.2 Realizar Estimativa A realização de estimativas é feita de acordo com os seguintes passos:

1. Se o projeto é de desenvolvimento, usar Planilha de Pontos de Função [SGQP-07]

a. De acordo com detalhamento disponível dos requisitos escolher tipo de

estimativa: NESMA Estimada ou IFPUG (ver Seção 3.2.4);

b. Escolher linguagem a ser utilizada;

c. Definir quais as fases do projeto que serão alvo de esforço (Requisitos, Análise

e Projeto, Construção e Testes)

d. Preencher abas da planilha com os ALIs, EIFs, EOs, EIs, e EQs.

e. Definir as Características Gerais do Sistema (se estimativa não é NESMA

Estimada)

f. Obter a estimativa final ajustada em pontos de função e o número de horas

total da demanda (ver Figura 4.1)

g. Preencher quantitativos de pessoal a serem utilizados no projeto (ver Figura

4.2)

h. Calcular sugestão de alocação no SGC usando a aba SGC (Figura 4.3)

2. Se o projeto não é de desenvolvimento, estimar considerando a opinião de

especialistas.

3. Para projetos grandes ou nos quais não se tem muito detalhamento, deve ser

usada uma segunda técnica de estimativas (UCP) e comparados os resultados.

Se estes previrem esforços totalmente diferentes, é provável que não se tenha

informação suficiente sobre o projeto. Deve-se detalhar mais as informações sobre

o projeto e repetir as estimativas até que estas convirjam.



4.3.1.3 Construir Cronograma A construção do cronograma é feita de acordo com os seguintes passos:

1. Se o projeto é de desenvolvimento

a. Considerar a duração das etapas conforme sugerido pela planilha de pontos

de função (ver Figura 4.2).

b. Dividir o projeto em um plano de releases (com cada release tendo o tamanho

máximo de três meses). A divisão em releases tem por objetivos:

1. Diminuir a ansiedade natural do cliente, permitindo que o mesmo receba

parcialmente o software que está sendo construído;

2. Reduzir os riscos de mudanças constantes em requisitos, permitindo

que o escopo do projeto vá sendo desdobrado gradativamente

(atendendo as boas práticas dos modelos iterativos e incrementais);

3. Facilitar a interação com o cliente, no sentido de obter o software que

melhor se ajuste às suas necessidades. Isto é alcançado pelo fato dos

releases materializarem o conceito abstrato que estava restrito aos

requisitos, permitindo que se trabalhe de forma equivalente a uma

construção de software baseada em prototipagem.

c. Cada release deve ser estimado usando a planilha de pontos de função, sendo

anexadas ao SGC a planilha geral do projeto e as planilhas de cada release;

d. Em cada release devem ser lançadas as transações funcionais e de dados que

forem ser criadas naquele release. As transações já contabilizadas em um

determinado release não devem ser contabilizadas em releases posteriores;

e. Se for necessário reduzir a duração do cronograma, deve ser avaliado quão

flexível é o conjunto de requisitos e priorizada a redução da duração das

atividades do caminho crítico. O caminho crítico é o formado pelas atividades

que são críticas ao cronograma do projeto, correspondendo ao caminho mais

longo (que leva mais tempo) para a realização do projeto. Atividades críticas

não podem atrasar, pois acarretam em atrasos globais ao projeto. Desta forma,

o gerente de projeto deve desprender uma atenção particular para cada uma

dessas atividades do caminho crítico de modo a minimizar o atraso no projeto.

Se os requisitos podem ser cortados, o cronograma pode ser encurtado tanto

quanto se queira, proporcionalmente à disposição que se tenha de cortar

requisitos. Isto leva a fazer menos trabalho em menos tempo, o que é



razoável. No entanto, se o conjunto de requisitos não é flexível, encurtar o

cronograma depende de adicionar pessoas para fazer mais trabalho em menos

tempo (paralelamente), o que só é razoável até um determinado ponto. Nas

últimas décadas, vários pesquisadores investigaram os efeitos de compressão

de um cronograma. A Figura 4.6 [McConnell-06] sumariza os resultados destas

investigações.

Figura 4.6 – Efeitos de Comprimir ou Expandir um Cronograma Nominal [McConnell-06]

O eixo horizontal no gráfico representa a relação entre o cronograma nominal e

o comprimido. Um valor de 0,9 no eixo indica um cronograma comprimido que

levará 0,9 vezes o tempo que o cronograma nominal (isto é, 90% do nominal).

O eixo vertical representa o esforço total requerido quando o cronograma é

comprimido ou expandido comparado ao esforço requerido quando o

cronograma nominal é usado. Um valor de 1,3 no eixo vertical indica que o

cronograma comprimido requer 1,3 vezes o esforço que o cronograma nominal

requereria. Concluímos assim que a compressão do cronograma nominal

aumenta o esforço total. Se o cronograma nominal era de 10 meses com 5

desenvolvedores, você não pode simplesmente assumir que é possível fazer

em 5 meses com 10 desenvolvedores (como diz um velho adágio, “nove

mulheres não fazem um filho em um mês”).



Cronogramas comprimidos requerem mais esforço por diversas razões:

1. Times maiores requerem mais coordenação e gerenciamento.

2. Times maiores introduzem mais vias de comunicação, o que introduz

mais chances de falhas de comunicação, o que introduz mais erros, que

por sua vez têm que ser corrigidos. O aumento de vias de comunicação

pode ser visualizado na Figura 4.7.

Figura 4.7 – Vias de Comunicação de Acordo com Tamanho de Time de Projeto

3. Cronogramas reduzidos requerem que mais trabalho seja feito em

paralelo. Quanto mais trabalho se sobrepõe, mais alta a chance que

uma parte do trabalho se baseie em outra incompleta ou defeituosa, e

que mudanças tardias venham a aumentar o total de retrabalho.

A conclusão que Barry Boehm [BOEHM-00] e Steve McConnel [McConnell-06]

chegam é que existe uma zona do impossível, um ponto além do qual o

cronograma de desenvolvimento simplesmente não pode ser encurtado.

Mesmo que se trabalhe mais duro, mesmo que se trabalhe de forma mais

inteligente, mesmo usando soluções criativas, ou aumentando o time.

Simplesmente não pode ser feito. O consenso destes pesquisadores é que a

compressão de um cronograma em mais de 25% do nominal não é possível.

1

Vias de comunicação com 2 pessoas

3


6


10




2. Montar cronograma de acordo com templates. Estão definidos templates de

acordo com o tipo de negócio, detalhando as atividades e entregáveis previstos

(ver exemplo na Figura 4.8 [SGQP-07]):

1. Consultoria

i. Processo de Desenvolvimento

ii. Gestão de TI

iii. Segurança, Performance e Redes

2. Desenvolvimento de SW – Projeto Fechado (ver Figura 4.8 [SGQP-07])

3. Levantamento de Requisitos

4. Fábrica de Construção

5. Fábrica de Testes

6. Integração de Software

7. Implantação de Produtos Id Nome da tarefa Duração Predecessoras

1 Template - Projeto Nome 49 dias2 Planejamento 3 dias3 Elaboração do Plano de Projeto 3 dias4 Iteração 1 - Nome Iteração 1 23 dias5 Requisitos 3 dias6 Levantamento e detalhamento de Requisitos 3 dias 37 Análise e Projeto 3 dias8 Elaboração do modelo de análise e projeto 3 dias 69 Implementação e Testes Unitários 15 dias10 Implementação e Testes 15 dias 8TI-3 dias11 Documentação 4 dias 10II12 Testes de Integração 14 dias13 Elaboração do Projeto de Testes 4 dias 8;1114 Execução dos Testes Integrados 3 dias 13;1015 Release da Iteração 1 2 dias16 Liberação da Release 1 2 dias 1417 Iteração 2 - Nome Iteração 2 23 dias18 Requisitos 3 dias 14II19 Levantamento e detalhamento de Requisitos 3 dias20 Análise e Projeto 3 dias21 Elaboração do modelo de análise e projeto 3 dias 1922 Implementação e Testes Unitários 15 dias23 Implementação e Testes 15 dias 21TI-3 dias24 Documentação 4 dias 23II25 Testes de Integração 14 dias26 Elaboração do Projeto de Testes 4 dias 21;2427 Execução dos Testes Integrados 3 dias 23;2628 Release da Iteração 2 2 dias29 Liberação da Release 2 2 dias 2730 Fechamento do Projeto 5 dias 1731 Transferência de Tecnologia 5 dias32 Homologação da Versão Final 5 dias 31TT

S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11Mês 2 Mês 3

Figura 4.8 – Template de Cronograma para Projetos de Desenvolvimento [SGQP-07]



4.3.1.4 Preencher Check-list de Estimativas Check-lists de informações relevantes podem ser altamente efetivos na redução de

inconsistências. Isto é mais útil quando muitas variáveis precisam ser avaliadas. Check-lists

ajudam porque as pessoas raramente conseguem lembrar todas as informações relevantes

para a execução de uma tarefa quando elas precisam fazê-lo. Mesmo especialistas

ocasionalmente esquecem de considerar tudo que eles deveriam. Memória de longo prazo é

inerentemente imperfeita, e mesmo a memória recente está sujeita a falhas. Adicionalmente,

informações irrelevantes podem confundir o julgamento. Estudos de previsão em uma

variedade de disciplinas identificaram que simples check-lists ajudam a melhorar a acurácia

assegurando a avaliação de possibilidades que poderiam de outra forma passar despercebidas,

e lembrando às pessoas de considerações que eles poderiam de outra forma esquecer

[Jørgensen-021] [Armstrong-01] [Park-95]. Check-lists podem ser compilados à medida que a

experiência é acumulada. Na PITANG, é utilizado o check-list de estimativas mostrado no

Apêndice G.



4.3.1.5 Preencher Planilha de Riscos O tratamento de riscos é necessário para reduzir os impactos financeiros que podem ser

gerados por eventuais problemas que venham a ocorrer no projeto. O tratamento de riscos é

feito usando a planilha de suporte à estimativa [SGQP-07], de acordo com os seguintes passos:

1. Devem ser identificados os riscos do projeto, com o apoio do Guia de Identificação

de Riscos (ver Figura 4.9 [SGQP-07]);

Figura 4.9 – PITANG – Guia de Identificação de Riscos (Adaptado de J. Hallows [Hallows-01]) [SGQP-07]



2. Na planilha de riscos devem ser informados o ID Risco (número seqüencial), a

Descrição do Risco, a Probabilidade de Ocorrência (15% - Pequena, 50% - Média,

90% - Alta), a Descrição do Impacto, a Estimativa do Impacto (em horas), e o

Valor da Hora Média do Projeto (calculado no SGC). Com estas informações a

planilha calcula a Estimativa de Impacto, e a Exposição ao Risco (em reais e em

horas) - ver Figura 4.10 [SGQP-07].

3. Atentar que os riscos que devem ter seu impacto contabilizado no SGC (onerando

a proposta) são os que dependem de terceiros, externos à empresa executante do

projeto. Os riscos internos são de responsabilidade da empresa, devendo seu

custo ser assumido dentro da margem do projeto (situações em que o risco seja

de alto impacto financeiro devem ser discutidas à parte).

a. A descrição dos riscos visa comprometer o cliente com o projeto, pois muitos

deles poderão estar relacionados ao posicionamento/comportamento do cliente

ao longo do andamento do projeto. É importante atentar que alguns riscos não

podem ser expostos para conhecimento do cliente, embora devam ser

considerados na estimativa.

4. O fundo de contingência calculado deve ser lançado como custo no SGC, e será

controlado pelo Gerente de Projetos durante a execução do projeto;

a. Normalmente o impacto dos riscos calculados será lançado como impacto

financeiro, não sendo considerado o impacto em cronograma. Situações de

alto risco ou de alto impacto, devem ser discutidas caso a caso.

Figura 4.10 – PITANG – Cálculo do Fundo de Contingência de Riscos [SGQP-07]



4.3.1.6 Lançar Custos no SGC O SGC (Sistema de Gestão Comercial PITANG) é a ferramenta que suporta todo o ciclo de

vendas da empresa, cobrindo o ciclo de vida da venda, seu fluxo de trabalho e as diferentes

instâncias de aprovação necessárias para a formatação de uma proposta e sua entrega a um

cliente. O ciclo de vida de uma proposta é o exibido na Figura 4.11 [SGQP-07]. O SGC é usado

para o lançamento dos custos e esforços de pessoal (o SGC transforma em custo) calculados

em tempo de pré-venda e em função destes calcular o preço final de venda do sistema que foi

estimado.

Figura 4.11 – Fluxo de Tramitação – SGC – PITANG [SGQP-07]



O uso do SGC em momento de pré-venda abrange as etapas de Designação de

Responsável Técnico, de Estimativa de Custos e de Parecer da Gerência de Pré-Venda do

fluxo da Figura 4.11 [SGQP-07].

1. Designação do Gerente de Projeto: Nesta etapa o Gerente de Pré-Vendas faz a

escolha e designação do responsável técnico pela proposta. O responsável

designado será o responsável pela execução das atividades previstas na

Estimativa de Custos. A escolha deste profissional se baseia em critérios de

qualificação, senioridade, expertise no negócio e na tecnologia, e conhecimento

do processo, técnicas e ferramentas usadas para estimativas pela empresa.

2. Estimativa de Custos: Detalhada na Seção 4.2.

3. Parecer da Gerência de Pré-vendas: Nesta etapa o Gerente de Pré-Vendas faz

a análise da proposta escrita pelo responsável técnico designado, avaliando o

atendimento do processo de pré-vendas, a clareza da proposta técnica, no que diz

respeito a escopo, prazos, esforço, premissas de estimativa, entregáveis, e

critérios de aceitação e finalização.

O lançamento de custos no SGC segue os seguintes passos (ver Figura 4.12 [SGQP-07]):

1. Na aba Geral de Estimativas, devem ser informados:

a. Duração do projeto em meses;

b. Duração da garantia em meses;

c. Unidade de alocação de pessoal (hora ou mês) – a alocação em horas é

adequada para projetos pequenos, de poucos dias.

d. Observação – campo de texto livre que deve ser usado para detalhar

considerações e premissas que foram assumidas nas estimativas lançadas.

Figura 4.12 – Definindo Duração de Projeto no SGC [SGQP-07]



2. Lançar os esforços estimados de pessoal, informando a alocação de cada perfil

mês a mês, em horas ou em meses dependendo da unidade de alocação

informada na aba geral, se hora ou mês (ver Figura 4.13 [SGQP-07]). Em função

da alocação lançada o SGC calcula o custo correspondente.

Figura 4.13 – Lançamento de Esforço de Pessoal no SGC [SGQP-07]

3. Lançar os custos de viagens na aba Viagens do SGC.

4. Lançar os outros custos e esforços associados ao projeto na aba Outros do SGC.

4.3.1.7 Escrever Proposta Técnica

A escrita da proposta técnica segue os seguintes passos:

1. Adotar template adequado ao tipo de negócio:

a. Consultoria

i. Processo de Desenvolvimento

ii. Gestão de TI

iii. Segurança, Performance e Redes

b. Desenvolvimento de SW – Projeto Fechado

c. Levantamento de Requisitos

d. Fábrica de Construção

e. Fábrica de Testes

f. Integração de Software

g. Implantação de Produtos

h. Alocação de Mão de Obra

i. Edital (responder conforme Edital)



2. Atentar para a definição de um cronograma de entregas, o qual será usado pela

área de negócios para vincular o fluxo de pagamentos. Idealmente deve-se ter

entregas mensais, ou pelo menos uma entrega a cada release, sendo o fluxo de

pagamentos ajustado para que o caixa do projeto permaneça positivo durante

toda a sua execução (prevendo sinal e pagamentos intermediários que cubram os

períodos sem pagamento).

3. A listagem da memória de cálculo de pontos de função na proposta técnica é

essencial para viabilizar o entendimento entre as partes envolvidas na negociação

(cliente e fornecedor) no caso de necessidade de negociações futuras (ao longo

do projeto) de extensão de escopo. A memória de cálculo deve listar todas as

transações de dados e funcionais consideradas na estimativa, bem como a

classificação de complexidade das mesmas (quando contagem detalhada),

culminando com a contagem não ajustada de pontos de função.

4. Vincular proposta no SGC.

4.3.1.8 Tramitar proposta no SGC O trâmite da proposta no SGC é feito quando cada fase do ciclo de vida de proposta é

encerrada (ver Figura 4.11). A fase alvo desta dissertação é a fase de Estimativa de Custos,

que se encerra quando o estimador considera que encerrou a pré-venda, ou seja já definiu o

escopo do projeto, identificou riscos, montou cronograma, identificou outros custos associados,

e escreveu a proposta técnica propriamente dita. Antes da tramitação, devem ser vinculados no

SGC todos os documentos gerados no processo de estimativa e escrita da proposta, tais como

planilhas, documentos (recebidos do cliente e gerados para este), e-mails associados à

proposta, apresentações utilizadas, etc. Minimamente devem estar vinculados:

1. Proposta Técnica; 2. Planilha de Pontos de Função 3. Check-list de Estimativa de Esforços; 4. E-mails trocados com cliente, área de negócios e área técnica que contém

informações acerca de aceites, dados de entrada para estimativas, etc. 5. Documento de requisitos enviado para validação do cliente (e sua resposta); 6. Documentos recebidos do cliente (RFPs, Editais, documentos de requisitos,

descrição de projetos, etc.) 7. Cronogramas 8. Atas de Reunião



4.4 Definição de Processo de Acompanhamento de Projetos

O acompanhamento dos projetos em execução na instituição estudo de caso é feito pela

coleta de métricas destes projetos, sendo as métricas coletadas usadas para retroalimentar o

processo de estimativas durante a pré-venda. As métricas coletadas são:

• Tamanho: tamanho do software em pontos de função, calculadas segundo o IFPUG,

e com o apoio de planilha de Pontos de Função [SGQP-07];

• Esforço em horas: esforço dispendido no projeto em horas, obtido através de

ferramenta de reportagem de tempo (Timesheet PITANG) usada por todas as equipes

de projetos;

• Custo: custo do projeto obtido através de relatórios financeiros do sistema financeiro

da empresa estudo de caso. Este custo envolve todos os custos ocorridos no projeto,

como custo de pessoal, viagens, parceiros, compra de equipamentos, indiretos, entre

outros.

Estas métricas são coletadas pelas equipes de projetos, com o apoio da área de qualidade,

através do Engenheiro de Qualidade responsável pela garantia de qualidade de cada projeto.

As métricas são registradas em um repositório comum de métricas, que é utilizado pelas

equipes de projetos e de pré-vendas como fonte de lições aprendidas e para refinar seus

processos de estimativas.



4.5 Conclusão

Pode-se verificar que a simples escolha de uma técnica de estimativas, é apenas a ponta do

iceberg de estimativas, pois a partir desta escolha vêm todas as demais etapas da implantação

da técnica, com a definição de templates, ferramentas e processos que apóiem o uso da técnica

escolhida, além da capacitação de estimadores na técnica e nas ferramentas e processos

adotados. Neste capítulo detalhamos o processo definido para a empresa estudo de caso com

seus respectivos templates e ferramentas. Este processo é utilizado em pré-vendas e no

acompanhamento dos projetos em execução, para a realização de estimativas. Vimos também

como derivar as estimativas de tamanho realizadas em esforço e custos.

Outro ponto importante a ser depreendido é a adoção de processos e ferramentas

construídas internamente, adequadas à cultura da organização.

No próximo capítulo concluiremos esta dissertação, apontando suas contribuições e as

necessidades de trabalhos futuros.



Capítulo 5 5. Conclusão

"Não é preciso ter olhos abertos para ver o sol, nem é preciso ter ouvidos afiados para ouvir o trovão. Para ser vitorioso você precisa ver o que não está visível." - Sun Tzu – 496 A.C.

Este trabalho foi motivado pela dificuldade atual de se praticar a estimativa de esforço de

desenvolvimento de software. Embora o assunto de estimativas seja discutido há décadas, e a

Engenharia de Software disponha de diversas técnicas de estimativa em utilização pelo

mercado, não existe uma técnica que seja universal, adequada a qualquer realidade e contexto

de utilização. Cada empresa deve definir a técnica que irá utilizar entre as diversas oferecidas,

incluindo os métodos ad hoc. Como vimos anteriormente, a estimativa de tamanho de projeto

de software ainda está em evolução nas empresas brasileiras. Pesquisa de qualidade e

produtividade no setor de software brasileiro, realizada anualmente pela Secretaria de Política

de Informática do Ministério da Ciência e Tecnologia (MCT) vem demonstrando a gradual

adoção de técnicas de estimativa (ver Tabela 3.2 [MCT-06]). A última pesquisa divulgada (6ª

edição) demonstrou que em uma amostra de 701 organizações do mercado de software

brasileiro, apenas 35% utilizavam algum tipo de métrica para medir a produtividade e a

qualidade dos processos de software. Dentre essas, 16% utilizavam a FPA e 19% utilizavam a

UCP [MCT-06]. Isto reforça a constatação que ainda não existe uma prática consolidada. Sendo

assim, para adotar uma prática de estimativas foi 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.

Vimos neste trabalho, como se deu o processo de seleção e implantação da abordagem de

pontos de função (técnicas IFPUG e Nesma Estimada), escolhida pela organização estudo de

caso. Adicionalmente também é usada a técnica UCP em situações em que seja necessário

validar a estimativa realizada com pontos de função (ver Seção 3.2.4). Mostramos também

como foi a definição e implantação de um processo de suporte à estimativa em momento de

pré-venda e durante a execução do projeto.

O trabalho apresentado nesta dissertação também suporta o 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.



Outro aspecto, que foi um grande de motivador para esse trabalho, foi a experiência prática

do autor durante oito anos, como responsável pelas atividades de pré-vendas de uma

organização de desenvolvimento de software. No início desse período, atividades de

estimativas foram realizadas de forma ad-hoc, sem a existência de um processo definido. Desta

forma, nem sempre os resultados finais das atividades eram satisfatórios, implicando em

estimativas que não correspondiam à realidade dos projetos executados. Esses problemas,

além de motivadores para a realização deste trabalho, serviram como orientadores da definição

do processo proposto. Questões a respeito de como resolver os problemas passados foram

incorporadas no processo final.

Por fim, a aplicação prática deste processo demonstrou que o uso contínuo do mesmo,

sendo refinado com as métricas coletadas pelos projetos em execução leva a um aumento da

precisão do mesmo, conforme demonstrado pela Figura 5.1, que mostra a evolução do Índice

de Acerto de Esforço para Java-Struts, no período que se inicia em setembro de 2005 até

agosto de 2007 (ver mais detalhes na Seção 4.1).

Evolução do Índice de Acerto de Esforço para Java-Struts

0,5

0,55

0,6

0,65

0,7

0,75

0,8

0,85

0,9

0,95

1

nov/05 mar/06 jul/06 nov/06 mar/07 jul/07

IE

Figura 5.1 – Evolução do Índice de Acerto de Esforço para Java-Struts [SGQP-07]

As conclusões deste trabalho estão descritas neste capítulo, que está organizado da

seguinte forma:

• Seção 5.1 - Principais Contribuições: relaciona as principais contribuições resultantes

deste trabalho;

• Seção 5.2 - Trabalhos Relacionados: descreve trabalhos relacionados a este;

• Seção 5.3 - Trabalhos Futuros: descreve trabalhos que podem ser realizados tendo como

base o presente trabalho;

• Seção 5.4 - Considerações Finais: descreve um resumo geral do capítulo de conclusão.



5.1 Principais Contribuições

Esta seção apresenta as principais contribuições do trabalho desenvolvido nesta

dissertação, são elas:

• Definição de um modelo de seleção de técnicas, utilizada para selecionar a técnica de

estimativa adotada pela empresa estudo de caso;

• Apresentação detalhada de um processo de estimativa de esforço de

desenvolvimento de software, listando as ferramentas e templates utilizados,

discorrendo sobre o aprendizado obtido a partir dos problemas enfrentados em

projetos de desenvolvimento de software comerciais;

• Proposta de um modelo de pré-vendas objetivo, que visa contribuir com empresas

que possuem a preocupação de disciplinar e melhorar a qualidade de seus processos

de software, conforme recomendado por modelos de qualidade tradicionais.



5.2 Trabalhos Relacionados

Esta seção apresenta alguns trabalhos relacionados com a área de estimativa de esforço de

desenvolvimento de software que tem paralelos com o trabalho apresentado neste documento.

Edméia Andrade [Andrade-04] em sua dissertação de mestrado do programa de pós-

graduação em Gestão do Conhecimento e Tecnologia da Informação da Universidade Católica

de Brasília avalia o uso das técnicas de pontos de função e pontos de casos de uso, estudando

a relação entre as mesmas. Este trabalho propôs uma melhor forma de estimar, revisar e

recalcular o tamanho do projeto à medida que novos artefatos são disponibilizados durante o

processo de desenvolvimento do projeto de software orientado a objetos. Foi definida uma

equação que descreve a relação entre FP e UCP e que pode ser usada para projetar FP a partir

de UCP e foi proposto um procedimento de contagem de FP e UCP para projetos de software

OO, sendo estes procedimentos aplicados em 19 projetos desenvolvidos pela academia e

indústria. Este trabalho relaciona-se a esta dissertação na medida em que estuda a relação

entre as técnicas de pontos de função e pontos de casos de uso, avaliando pontos positivos e

negativos das mesmas.

Tatiana Monteiro [Monteiro-05] em sua dissertação apresentada ao curso de mestrado em

Informática Aplicada da Universidade de Fortaleza propõe uma extensão da técnica de Pontos

de Casos de Uso, batizada de Technical Use Case Points (TUCP). A técnica proposta foi

aplicada em cinco projetos de uma organização privada, apresentando um cálculo mais acurado

para o esforço de projetos. Este trabalho relaciona-se a esta dissertação na medida em que

analisa as deficiências da técnica original de pontos de casos de uso, pontos estes que também

foram alvo de análise desta dissertação.

Kirsten Ribu [Ribu-01] em sua dissertação apresentada ao curso de mestrado do

Departamento de Informática da Universidade de Oslo fez o estudo de implantação de uma

técnica de estimativas (UCP) em organizações privadas e públicas, tendo acompanhado o uso

da técnica em 12 projetos. Concluiu que a técnica é útil para projetos diversos, com uma

acurácia adequada. Este trabalho relaciona-se a esta dissertação na medida em que

acompanha a implantação de uma técnica de estimativas, e a conversão da estimativa de

tamanho obtida, em esforço.

Mehwish Nasir e H. Farooq Ahmad [Nasir-06] discutem em artigo as práticas de estimativa

de software existentes na indústria e literatura, analisando suas forças e fraquezas. O foco



principal é a análise de lacunas da organização com respeito ao CMMI nível 3 para Engenharia

de Sistemas (SE)/Engenharia de Software (SW)/Desenvolvimento Integrado de Produto e

Processo (IPPD)/ Gerenciamento de Fornecedores (SS). A coleta de dados dos mesmos revela

que a companhia faz uso de abordagens heurísticas nas quais julgamentos de especialistas

suplementados com wideband Delphi, são os principais métodos usados para estimativa de

software. À luz do CMMI Nível 3 para SE/SW, sugerem que métodos formais para estimar

tamanho, esforço e custos para um projeto deveriam ser implementados separadamente das

heurísticas usadas para estimativa. Concluem que metodologias diferentes de estimativa são

aplicáveis em diferentes categorias de projetos. Nenhuma delas é 100% acurada, mas o uso

próprio delas faz o processo de estimativa ser mais suave. O estudo conduzido e as conclusões

a que os autores chegam são bastante similares às obtidas nesta dissertação.

M. A. Parthasarathy [Parthasarathy-07] usa a imensa experiência de campo da Infosys14, um

dos maiores e mais respeitados provedores de soluções de TI do mundo, para gerar um guia

detalhado para a estimativa de projetos de software. Ele demonstra como usar com sucesso a

técnica de pontos de função (FP) em estudos de caso reais. No seu trabalho, ele

sistematicamente identifica armadilhas que podem levar a estimativas não acuradas, e

apresenta soluções usadas na Infosys para superar tais armadilhas. Este trabalho tem grande

correlação com esta dissertação, pois cobre basicamente os mesmos aspectos: de estudo e

seleção de uma técnica de estimativas, de definição e implantação de um processo de

estimativas em uma empresa de desenvolvimento de software, de acompanhamento do

resultado do uso deste processo nos projetos da empresa.

14 Infosys Technologies Ltd. - http://www.infosys.com/ - +75.000 empregados – +3 bilhões Vendas - +25 anos fundação



5.3 Trabalhos Futuros

Esta seção apresenta alguns trabalhos futuros que podem complementar o processo de

estimativa de software proposto nesta dissertação, de modo a possibilitar uma estimativa mais

precisa em tempo de pré-venda e acompanhamento mais efetivo de projetos de software.

A relação abaixo detalha os trabalhos de extensão previstos:

• Calibrar os direcionadores de custo do COCOMO II conforme a base histórica da

empresa estudo de caso, passando a utilizar os direcionadores de custo do

COCOMO II em substituição aos fatores de ajuste do IFPUG.

• Estender a base de dados históricos da organização e o processo associado à sua

alimentação. A organização deve manter uma base de dados que retêm e organiza

historicamente as informações relativas a todos os projetos completados, que permita

a recuperação de informações usando diferentes critérios de pesquisa. Este banco de

dados histórico deve ser tratado como parte integral do processo de estimativa, e a

equipe responsável pelas estimativas deve ter participação ativa na especificação e

na sustentabilidade das informações armazenadas. As informações sobre custos e

esforços devem indicar claramente quais partes do ciclo de vida e quais atividades

foram cobertas pelas diferentes categorias de esforços e custos registrados. Uma vez

criado o banco de dados histórico, a informação de cada projeto completado é

inserida na base. Estimativas originais para tamanho, custo e prazos são retidas, e

relatórios "postmortems" são realizados ao final de cada projeto, de forma a:

o Garantir que a informação registrada é válida;

o Garantir que os eventos que afetaram os custos/prazos sejam descritos e

devidamente registrados enquanto ainda estão "claros" na mente das pessoas

envolvidas no projeto.

• A métrica de pontos de função não considera em sua forma “pura” o reuso de

software. Pretendemos estender o processo proposto neste trabalho, para considerar

o reuso nas estimativas;

• O acompanhamento do desenvolvimento de software em execução pelas equipes de

projetos ressente-se de uma métrica mais acurada que permita a aferição do trabalho

realmente realizado. Existe uma dificuldade natural de dividir o trabalho realizado

conforme se avança no desenvolvimento do software, pelo fato das transações de



dados serem contabilizadas à parte na técnica de pontos de função. Como

contabilizar o desenvolvimento destas funções? Quando elas são contabilizadas?

Pretendemos responder a estas questões com o aprofundamento do uso da técnica

de pontos de função para o acompanhamento de projetos na organização;

• Aprofundar estudos para definir como a contagem de pontos de função interpreta

entidades criadas por herança e agregação, e como estas devem ser contabilizadas.

5.4 Considerações Finais As práticas de estimativa de software aplicadas na empresa estudo de caso vêm

demonstrando uma boa acurácia (ver Figura 5.1), permitindo uma menor exposição ao risco por

parte da organização e dos clientes. Com base nas experiências obtidas a partir dos projetos

acompanhados, utilizados como estudo de caso deste trabalho, podemos concluir que a

utilização de práticas de estimativa é de grande relevância para a obtenção de sucesso em

projetos de software.

Porém, a adoção de práticas de estimativas de software não é suficiente, sendo necessário

o apoio das gerências sênior e de garantia da qualidade, as quais devem estar comprometidas

com a viabilização dos recursos necessários para a realização das atividades e revisões dos

artefatos produzidos no decorrer do projeto. Além disso, a alta gerência deve respaldar a

obrigatoriedade da produção dos artefatos descritos nas metodologias adotadas, bem como a

conformidade destes com os padrões adotados.

O processo detalhado nesta dissertação apresenta algumas restrições, devido ao fato de se

basear em uma técnica que demanda a existência de funções de dados no software a ser

desenvolvido. Algumas linhas de software não possuem funções de dados, ou tem formas muito

particulares de tratá-las, tais como aplicações embarcadas em celular, TV digital, etc. Isto não

chega a ser um problema para a instituição estudo de caso, pois praticamente todos os seus

projetos de desenvolvimento são de aplicações baseadas na Web. No entanto a possibilidade

de crescimento futuro da demanda por aplicações embarcadas como as citadas deverá fazer

com que venha a ser necessário o uso de outras técnicas de estimativas, tais como UCP.

Consideramos por fim, que o processo detalhado neste trabalho vem ganhando maturidade

de forma rápida na organização estudo de caso. A evolução natural do mesmo, com base nos

trabalhos futuros sugeridos como próximos passos o consolidará ainda mais, contribuindo para

empresas que possuam a preocupação de disciplinar e melhorar a qualidade de seus

processos de software, conforme recomendado por modelos de qualidade tradicionais.



Referências Anda-01 Anda B., Dreiem D., Sjoberg D. and Jorgesen M., “Estimating Software Development Effort

Based on Use Cases – Experiences from Industry”, UML 2001 The Unified Modeling Language 4th International Conference, Toronto, Canadá, Outubro 2001

Andrade-04 Andrade E., “Pontos de Casos de Uso e Pontos de Função na Gestão de Estimativa de Tamanho de Projetos de Software Orientados a Objetos”, Dissertação de Mestrado em Gestão do Conhecimento e Tecnologia da Informação da Universidade Católica de Brasília, 2004

Armstrong-01 Armstrong J.S., “Principles of Forecasting: A Handbook for Researchers and Practitioners", The Wharton School, Univ. of Pennsylvania, 2001

Arnold-98 Arnold P. and Pedross P., “Software Size Measurement and Productivity Rating in a Large Scale Software Development Department”, Forging New Links, IEEE Computer Society, 1998

Beck-01 Beck K. e Fowler M.; “Planning Extreme Programming”; Addison-Wesley; 2001 Beck-04 Beck K., “Extreme Programming Explained: Embrace Change 2ª Edição”, Addison-Wesley,

2004 BFPUG-07 Brazilian Function Point Users Group (BFPUG) Web Site; http://www.bfpug.com.br/, Último

acesso em 20/04/2007 Boehm-00 Boehm B., Abts C., Brown A.W., Chulani S., Clark B.K., Horowitz E., Madachy R., Reifer D. e

Steece B.; “Software Cost Estimation With COCOMO II”; Prentice Hall; 2000 Boehm-81 Boehm B., “Software Engineering Economics”, Prentice Hall, 1981 Braungarten-05 Braungarten R., Kunz M., Dumke R.; “An Approach to Classify Software Measurement

Storage Facilities”; Otto-von-Guericke University Magdeburg, Institute for Distributed Systems, Faculty of Computer Science, Magdeburg – Alemanha; 2005

Clark-99 Clark B.K.; “Effects of Process Maturity on Development Effort”; Center for Software Engineering - University of Southern California; 1999

Cockburn-00 Cockburn A.; “Writing Effective Use Cases”; Addison-Wesley; 2000 COCOMO-07 COCOMO Web site; http://sunset.usc.edu/research/COCOMOII/index.html, Último acesso em

20/04/2007 Coggins-93 Coggins G.A. e Russell R.C.; “Software Cost Estimating Models: A Comparative Study of

What the Models Estimate (AFIT Thesis GCA/LAS/93S-4)”; Dayton, OH, Air Force Institute of Technology; 1993

DeMarco-82 DeMarco T., “Controlling Software Projects”, Yourdon Press, 1982 DOD-99 Department of Defense; “Parametric Estimating Handbook Second Edition”; Primavera 1999 Ferens-86 Ferens D.V.; "A Common Sense Approach to Software Cost Estimation"; ISPA Journal of

Parametrics, Volume VI, Number 2; June 1986 FISMA-07 Finnish Software Measurement Association (FISMA) Web Site; http://www.FISMA.fi/in-

english/, Último acesso em 20/04/2007 Fowler-00 Fowler M.; “Planning Agile Projects”; ThoughtWorks; 2000 Garmus-01 Garmus D., Herron D.; “Function Point Analysis – Measurement Practices for Successful

Software Projects”; Addison-Wesley; 2001 Gartner-02 Gartner Research; “Function Points Can Help Measure Application Size”; Research Note

SPA-18-0878; 19-Novembro-2002 Hallows-01 Hallows J.E.; “The Project Management Office Toolkit”; Project Management Institute; 2001 Highsmith-02 Highsmith J.; "Project Estimating"; Cutter Consortium Agile Project Management E-Mail

Advisor; 2-Maio-2002 Hill-06 Hill P.; “Software Early Lifecycle – Functional Sizing”; The DoD Software Tech News, Vol. 9,

Number 2; Junho 2006 IFPUG-02 International Function Point Users Group; “IT Measurement – Practical Advice from the

Experts”; Addison-Wesley; 2002



IFPUG-07 The International Function Point User’s Group (IFPUG) Web Site; http://www.IFPUG.org/, Último acesso em 20/04/2007

ISBSG-07 The International Software Benchmarking Standards (ISBSG) Web Site; http://www.isbsg.org; Último acesso em 20/04/2007

ISO-07 International Organization for Standardization; http://www.iso.org/iso/en/iso9000-14000/index.html; Último acesso em 20/04/2007

ISO/IEC 15939-07 ISO/IEC 15939, Software Engineering - Software Measurement Process; http://www.psmsc.com/ISO.asp; Último acesso em 20/04/2007

Jacobson-99 Jacobson I., Booch G. e Rumbaugh J.; “The Unified Software Development Process”; Addison-Wesley; 1999

Johnson-98 Johnson K.; “Software Cost Estimation: Metrics and Models”; Department of Computer Science, University of Calgary; Fevereiro 1998

Jones-07 Jones C.; “Software Estimating Rules of Thumb - Version 3”; Software Productivity Research, Inc.; 20-Março-2007

Jørgensen-02 Jørgensen M., Indahl U., Sjøberg D.; “Software Effort Estimation by Analogy and “Regression Toward the Mean””; Simula Research Laboratory, Oslo, Noruega; 2002

Jørgensen-021 Jørgensen M.; “A Review of Studies on Expert Estimation of Software Development Effort”; Simula Research Laboratory, Oslo, Noruega; 2002

Kan-03 Kan S.H.; “Metrics and Models in Software Quality Engineering 2nd Edition”; Addison-Wesley; 2003

Karner-93 Karner G.; “Resource Estimation for Objectory Projects”; Objective Systems; 17-Setembro-1993

Kemerer-92 Kemerer C. e Porter B.; “Improving the Reliability of Function Point Measurement: An Empirical Study”; IEEE Transactions on Software Engineering, Vol. 18, No. 11, Página 1011; Novembro 1992

Kival-99 Kival C.W., Rocha A.R.C.; “Qualidade e Produtividade em Software. 3ª Edição”; Makron Books; 1999.

Laurie-00 Laurie R. e Radford P.; “Using Functional Sizing In Software Project Estimating”; Charismatek; Junho 2000

Lederer-92 Lederer A.L. e Prasad J.; “Nine Management Guidelines for Better Cost Estimating”; Communications of the ACM, Pág. 51-59; Fevereiro 1992

Lewis-01 Lewis J.P.; “Large Limits to Software Estimation”; ACM Software Engineering Notes; Vol 26, No. 4 p. 54-59; Julho 2001

Libby-78 Libby R. e Blashfield R.K.; “Performance of a Composite as a Function of the Number of Judges”; Organizational Behaviour and Human Performance 21(2): 121-129; 1978

Longstreet-04 Longstreet D.; “Function Points Analysis Training Course”; Longstreet Consulting Inc.; 2004 López-05 López P.A.P.; “COCOMO II Um modelo para estimativa de custos de Projetos de Software”;

UNISINOS; 2005 McConnell-96 McConnell S.; “Rapid Development”; Microsoft Press; 1996 McConnell-98 McConnell S.; “Software Project Survival Guide”; Microsoft Press; 1998 McConnell-06 McConnell S.; “Software Estimation – Demystifying the Black Art”; Microsoft Press; 2006 McGarry-01 McGarry J., Card D., Jones C., Layman B., Clark E., Dean J., Hall F.; “Practical Software

Measurement: Objective Information for Decision Makers”; Addison-Wesley; 2001 MCT-06 Ministério da Ciência e Tecnologia; “Programa Brasileiro da Qualidade e Produtividade em

Software - Indicadores da Qualidade e Produtividade”; http://www.mct.gov.br/index.php/content/view/47817.html, Último acesso em 23/2/2006

Monteiro-05 Monteiro T.C.; “Pontos de Caso de Uso Técnicos (TUCP): Uma Extensão da UCP”; Dissertação de Mestrado; Curso de Informática Aplicada da Universidade de Fortaleza – UNIFOR; 2005

MPS.BR-07 Melhoria do Processo de Software Brasileiro; http://www.softex.br/mpsbr/_home/default.asp; Último acesso em 20/04/2007



MPMM-07 MPMM – Method123 Project Management Methodology Web Site; http://www.mpmm.com/project-sizes.php, Último acesso em 20/04/2007

Mylius-04 Mylius S. e Marodin H.; “O Estabelecimento de Estimativas em Projetos”; Mylius & Marodin – Gestão de Projetos; 2004

Nasir-06 Nasir M., Ahmad H. F., "An Empirical Study to Investigate Software Estimation Trend in Organizations Targeting CMMISM," ICIS-COMSAR, pp. 38-43, 1st IEEE/ACIS International Workshop on Component-Based Software Engineering,Software Architecture and Reuse (ICIS-COMSAR'06), 2006

NESMA-07 The Netherlands Software Metrics Users Association (NESMA) Web Site; http://www.NESMA.nl/english/index.htm, Último acesso em 20/04/2007

Park-95 Park R.; “A Manager's Checklist for Validating Software Cost and Schedule Estimates”; Special Report CMU/SEI-95-SR-004; Janeiro 1995

Parthasarathy-07 Parthasarathy M.A.; “Practical Software Estimation: Function Point Methods for Insourced and Outsourced Projects”; Addison Wesley; 2007

PMI-00 Project Management Institute (PMI); “PMBOK, Project Management Body of Knowledge”; 2000

Rankin-05 Rankin M.; ” Mike Rankin's MX Blog”, http://mrmx.blogspot.com/search/label/Project%20Mgmt; 8-06-2005

Ribu-01 Ribu K.; “Estimating Object-Oriented Software Projects with Use Cases”; Master of Science Thesis, University of Oslo, Department of Informatics; Novembro 2001

Schneider-98 Schneider G. e Winters J.; “Applying Use Cases”; Addison-Wesley; 1998 Schwaber-96 Schwaber K., “Controlled Chaos : Living on the Edge”, Advanced Development Methods, Inc.,

11th Annual Conference on Object-Oriented Programming Systems, Languages, and Applications, OOPSLA'96 Workshop on Business Object Design and Implementation II, 1996

SEI-07 CMMI Web Site - Carnegie Mellon University – Software Engineering Institute (SEI); http://www.sei.cmu.edu/cmmi/; Último acesso em 20/04/2007

SEL-90 NASA - National Aeronautics and Space Administration – Software Engineering Laboratory Series; “Manager's Handbook for Software Development Revision 1”; Novembro 1990

SGQP-07 SGQP – Sistema de Gestão da Qualidade PITANG, Último acesso em 20/04/2007 Shazan-03 Shazan C.; “Estimando Esforço de Projetos de Software utilizando Análise de Pontos de

Função”; CIn – UFPE; 2003 Smith-99 Smith J.; “The Estimation of Effort Based on Use Cases”; Rational Software; Outubro 1999 Softwaremag-04 Softwaremag.com; “Standish: Project Success Rates Improved Over 10 Years”;

http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish; 15-01-2004 Sommerville-04 Sommerville I.; “Software Engineering (7th Edition)”; Addison-Wesley; 2004 SOX-02 Sarbanes-Oxley Act of 2002; Public Law 107–204—July 30, 2002 116 Stat. 745;

http://www.sec.gov/about/laws/soa2002.pdf; Último acesso em 20/04/2007 Stutzke-05 Stutzke R.D.; “Estimating Software-Intensive Systems”; Addison-Wesley; 2005 Symons-01 Symons C.; “Come back function point analysis (modernized) – all is forgiven!”; Software

Measurement Services Ltd; 2001 Taber-01 Taber C., Fowler M.; “Planning and Running an XP Iteration”; Cutter IT Journal; Janeiro 2001 Trindade-99 Trindade A.L.P., Pessoa M.S.P., Spinola M.M.; “COCOMO II – Uma Compilação de

Informações Sobre a Nova Métrica”; 1999 VanDoren-97 VanDoren E.; “Function Point Analysis”; SEI – Carnegie-Mellon; January 1997 Version One-06 Version One website; “Customer & Mgmt. Practices - Velocity”,

http://www.versionone.net/Resources/Velocity.asp, Último acesso em 23/2/2006 Wu-97 Wu L.; “The Comparison of the Software Cost Estimating Methods”; University of Calgary,

1997 Zuse-95 Zuse H.; “History of Software Measurement”; http://irb.cs.tu-

berlin.de/~zuse/metrics/History_00.html; 1995



Apêndice A – Guia para Definição das GSCs Para facilitar a atribuição do valor do DI para cada GSC, O IFPUG propõe um conjunto de

regras gerais, que serão reproduzidas neste apêndice. Adicionalmente foram acrescentadas as

observações de David Longstreet [Longstreet-04] e David Herron & David Garmus [Garmus-01]

para facilitar a atribuição do DI em aplicações atuais, tais como PC, cliente-servidor, e Web (já

que as GSCs se relacionam melhor com o ambiente mainframe).

O valor varia entre:

• 0 se o fator não está presente ou não tem influência; • 1 se o fator tem influência insignificante; • 2 se o fator tem influência moderada; • 3 se o fator tem influência média; • 4 se o fator tem influência significativa; • 5 se o fator tem forte influência,

A escala de 0 a 5 é uma escala ordinal, desta forma é necessário definir o significado dos

diferentes valores. Nesta situação é normal que as pessoas atribuam diferentes valores para os

mesmos fatores nas mesmas circunstâncias. Para evitar este problema é essencial a existência

de guias. O significado dos GSCs e seus escores são os seguintes:

GSC1: Comunicação de Dados Os dados e informações de controle usados na aplicação são enviados ou recebidos usando

instrumentos de comunicação. Terminais conectados localmente a uma unidade de controle são

considerados como usando instrumentos de comunicação. Protocolo é um conjunto de

convenções, que permitem a transferência, ou troca de informações entre dois sistemas ou

dispositivos. Todos os enlaces de comunicação de dados requerem algum tipo de protocolo.

0 Aplicação é puramente batch ou um PC standalone; 1 Aplicação é batch mas tem entrada de dados remota ou impressão remota; 2 Aplicação é batch mas tem entrada de dados remota e impressão remota; 3 Aplicação inclui entrada de dados online ou um front-end de teleprocessamento para um

processo batch ou um sistema de consulta; 4 Aplicação é mais que um front-end, mas suporta apenas um tipo de protocolo de

teleprocessamento; 5 Aplicação é mais que um front-end, e suporta mais que um tipo de protocolo de

teleprocessamento;



Uma aplicação que permite consulta de aplicações via uma solução Web e acesso local

deve receber um valor 3. Uma aplicação que permite a atualização de ILFs via Internet e

atualização local deve receber um valor 5.

GSC2: Processamento de Dados Distribuídos Processamento de dados distribuídos descreve o nível em que a aplicação transfere dados

entre componentes da mesma. Dados distribuídos ou funções de processamento é uma

característica da aplicação dentro de sua fronteira.

0 Aplicação não ajuda a transferência de dados ou funções de processamento entre componentes do sistema;

1 Aplicação prepara dados para processamento do usuário em outro componente do sistema, tais como planilhas em PC ou banco de dados em PC;

2 Dados são preparados para transferência , transferidos e processados em outro componente do sistema (não para processamento pelo usuário final);

3 Processamento distribuído e transferência de dados são on-line e em uma direção apenas;

4 Processamento distribuído e transferência de dados são on-line e em ambas as direções; 5 Funções de processamento são dinamicamente realizadas nos componentes mais

apropriados do sistema.

Copiar arquivos de um mainframe para um PC local ou copiar arquivos da Internet ou

Intranet deve receber um valor 2. Lendo via um cliente ou via Internet ou Intranet deve receber

um valor 3. Lendo e atualizando via Internet ou Intranet deve receber um valor 4. Dependendo

dos recursos disponíveis, a aplicação processa localmente, no servidor, na Intranet ou Internet

deve receber um valor 5.



GSC3: Performance

Objetivos de performance da aplicação, definidos ou aprovados pelo usuário, tanto em

tempo de resposta quanto throughput, influenciam (ou irão influenciar) o projeto,

desenvolvimento, instalação, e suporte da aplicação.

0 Nenhum requisito especial de performance foi definido pelo usuário; 1 Requisitos de performance e projeto foram definidos e revisados, mas nenhuma ação

especial foi requerida; 2 Tempo de resposta ou throughput é crítico durante horários de pico. Nenhum projeto

especial para utilização de CPU foi requerido. Prazo final de processamento é o próximo dia útil;

3 Tempo de resposta ou throughput é crítico durante todos os horários comerciais. Nenhum projeto especial para utilização de CPU foi requerido. Existem restrições de prazo final de processamento para integração com outros sistemas;

4 Adicionalmente, requisitos de performance definidos pelo usuário são restritivos o suficiente para requerer atividades de análise de performance na fase de projeto ;

5 Adicionalmente, ferramentas de análise de performance foram usadas nas fases de projeto, desenvolvimento, e/ou implementação para atender os requisitos de performance definidos pelo usuário.

GSC4: Configuração do Equipamento

Uma configuração operacional usada fortemente, que requeira considerações especiais de

projeto, é uma característica da aplicação. Por exemplo, o usuário quer executar a aplicação em

um equipamento existente ou comprometido, que irá ser fortemente utilizado.

0 Nenhuma restrição operacional implícita ou explícita foi incluída; 1 Existem restrições operacionais, mas são menos restritivas que uma aplicação típica.

Nenhum esforço especial é necessário para atender as restrições; 2 Algumas considerações de segurança ou temporização estão definidas; 3 Requisitos de processamento específicos para uma parte específica da aplicação estão

definidos; 4 Restrições de operação definidas requerem cuidados especiais no processador central

ou um processador dedicado para executar a aplicação; 5 Adicionalmente, há considerações especiais para a distribuição do sistema e seus

componentes, nas unidades processadoras.



Devemos esperar que a maioria das aplicações receba o valor 2. Para valorar 3 a 5, a

aplicação deve necessitar de um processador dedicado ou múltiplos processadores

processando as mesmas transações e procurando pela forma mais otimizada de

processamento.

GSC5: Taxa de Transações

A taxa de transações é alta e influencia o projeto, desenvolvimento, instalação e suporte da

aplicação

0 Não estão previstos períodos de picos de transação; 1 Estão previstos picos de transações mensal, trimestral, anual ou em certo período do

ano; 2 São previstos picos semanais; 3 São previstos picos diários; 4 Alta taxa de transações definida pelo usuário nos requisitos da aplicação ou acordos de

nível de serviço são altos o suficiente para requerer atividades de análise de performance na fase de projeto;

5 Adicionalmente, é necessário utilizar ferramentas de análise de performance nas fases de projeto, desenvolvimento e/ou implantação.

GSC6: Entrada de Dados On-line

Entrada de dados on-line descreve o nível no qual os dados são entrados através de

transações interativas.

0 Todas as transações são processadas em modo batch; 1 1% a 7% das transações são entradas de dados on-line; 2 8% a 15% das transações são entradas de dados on-line; 3 16% a 23% das transações são entradas de dados on-line; 4 24% a 30% das transações são entradas de dados on-line; 5 Mais de 30% das transações são entradas de dados on-line.

Transações referem-se à EIs, EOs, e EQs, cada uma delas sendo um processo elementar.



GSC7: Interface Com o Usuário

Eficiência do usuário final descreve o nível de consideração da aplicação para fatores

humanos e facilidade de uso para o usuário da aplicação medida. As funções on-line enfatizam

o projeto de interface para a eficiência do usuário final. O projeto de interface inclui:

• Auxílio à Navegação (teclas de função, acesso direto e menus dinâmicos). • Menus. • Documentação e ajuda on-line • Movimentação automática do cursor • Movimentação horizontal e vertical de tela. • Impressão remota (via transações on-line). • Teclas de função preestabelecidas. • Processos batch submetidos a partir de transações on-line. • Seleção de dados na tela por cursor. • Utilização intensa de campos com vídeo reverso, intensificados, sublinhados, coloridos e

outros indicadores. • Impressão da documentação das transações on-line através de hard copy • Utilização de mouse. • Menus Pop-Up. • Menor número possível de telas para executar as funções de negócio. • Suporte Bilíngüe (Contar como 4 itens). • Suporte multilíngüe (contar como 6 itens).

0 Nenhum dos itens citados; 1 De um a três dos itens citados; 2 De quatro a cinco dos itens citados; 3 Mais de cinco dos itens citados, mas não há requerimento específico do usuário quanto

ao sistema ter interface amigável; 4 Mais de cinco dos itens citados, e foram estabelecidos requerimentos quanto à eficiência

do usuário final, fortes o suficiente para requererem a inclusão de atividades específicas de projeto envolvendo fatores humanos, tais como minimização da digitação, para mostrar inicialmente os valores utilizados com mais freqüência;

5 Mais de cinco dos itens citados, e foram estabelecidos requerimentos quanto à eficiência do usuário final, fortes o suficiente para requererem o uso de processos e ferramentas especiais de forma a demonstrar que estes objetivos foram atingidos;



Devemos esperar que aplicações batch com nenhuma interatividade sejam valoradas como

0. Maioria das aplicações interativas tem um front-end com telas de entrada de dados, mas a

menos que elas tenham templates e/ou padrões construídos na aplicação, elas devem ser

valoradas como 3. Se padrões, templates, e/ou ferramentas navegacionais significativas

estiverem presentes, valore 4. Para valorar 5, precisa haver laboratórios de usuários para testar

a usabilidade da aplicação ao invés da funcionalidade. Sistemas em tempo-real, de

telecomunicações, ou controle de processo podem não valorar nada para este GSC.

GSC8: Atualização On-line

Descreve o nível em que ILFS são atualizados on-line.

0 Nenhum; 1 Atualização on-line de um a três arquivos lógicos internos. O volume de atualização é

baixo e a recuperação de dados é simples; 2 Atualização on-line de mais de três arquivos lógicos internos. O volume de atualização é

baixo e a recuperação dos dados é simples 3 Atualização on-line da maioria dos arquivos lógicos internos; 4 Em adição ao item anterior, proteção contra perdas de dados é essencial e foi

especialmente projetada e programada no sistema; 5 Além do item anterior, altos volumes trazem considerações de custo ao processo de

recuperação. Processos de recuperação altamente automatizados foram incluídos, minimizando a intervenção do operador.



GSC9: Processamento Complexo

Processamento complexo descreve o nível em que a lógica de processamento influencia o

desenvolvimento da aplicação. Os seguintes cinco estão presentes.

1. Processamento especial de auditoria e/ou processamento específico de segurança foram considerados na aplicação.

2. Processamento lógico extensivo. 3. Processamento matemático extensivo. 4. Processamento gerando muitas exceções, resultando em transações incompletas que

devem ser processadas novamente. Exemplo: transações de auto-atendimento bancário interrompidas por problemas de comunicação ou com dados incompletos.

5. Processamento complexo para manusear múltiplas possibilidades de entrada/saída. Ex.: multimídia.

0 Nenhum dos itens descritos; 1 Apenas um dos itens descritos; 2 Dois dos itens descritos; 3 Três dos itens descritos; 4 Quatro dos itens descritos; 5 Todos os cinco itens descritos.

GSC10: Reusabilidade

Descreve o nível no qual a aplicação e o código na aplicação foram especificamente

projetados, desenvolvidos, e suportados para serem usados em outras aplicações.

0 Nenhuma preocupação com reutilização de código; 1 Código reutilizado foi usado somente dentro da aplicação; 2 Menos de 10% da aplicação foi projetada prevendo utilização posterior de código por

outra aplicação; 3 10% ou mais da aplicação foi projetada prevendo utilização posterior do código por outra

aplicação; 4 A aplicação foi especificamente projetada e/ou documentada para ter seu código

facilmente reutilizado por outra aplicação e a aplicação é customizada pelo usuário em nível de código fonte;

5 A aplicação foi especificamente projetada e/ou documentada para ter seu código facilmente reutilizado por outra aplicação e a aplicação é customizada para uso através de parâmetros que podem ser alterados pelo usuário.



GSC11: Facilidade de Implantação

Descreve o nível em que a conversão de ambientes prévios influenciou o desenvolvimento

da aplicação. Um plano de conversão e instalação e/ou ferramentas de conversão foram

providas e testadas durante a fase de testes do sistema.

0 Nenhuma consideração especial foi estabelecida pelo usuário, nem procedimento especial de configuração é requerido na instalação;

1 Nenhuma consideração especial foi estabelecida pelo usuário, mas procedimento especial de configuração é requerido na instalação;

2 Requerimentos de conversão e implantação foram estabelecidos pelo usuário e roteiros de conversão e instalação foram providos e testados. O impacto da conversão no projeto não é considerado importante;

3 Requerimentos de conversão e implantação foram estabelecidos pelo usuário e roteiros de conversão e instalação foram providos e testados. O impacto da conversão no projeto é considerado importante;

4 Além do item 2, conversão automática e ferramentas de instalação foram providas e testadas;

5 Além do item 3, conversão automática e ferramentas de instalação foram providas e testadas.



GSC12: Facilidade Operacional

Descreve o nível em que a aplicação atende os aspectos operacionais, tais como

inicialização, backup, e processo de recuperação. Considera o nível em que estes aspectos

foram providos e testados durante a fase de testes do sistema. A aplicação minimiza a

necessidade de atividades manuais, tais como montagem de fitas, manuseio de papel, e

intervenção manual direta no local.

0 Nenhuma consideração especial de operação, além do processo normal de backup foi estabelecida pelo usuário;

1-4 Verifique quais das seguintes afirmativas podem ser identificadas na aplicação. Selecione as que forem aplicadas. Cada item vale um ponto, exceto se definido explicitamente:

• Foram estabelecidos processos de inicialização, backup, e recuperação, mas a intervenção do operador é necessária;

• Foram estabelecidos processos de inicialização, backup, e recuperação, mas nenhuma intervenção do operador é necessária (conte como dois itens);

• A aplicação minimiza a necessidade de montar fitas magnéticas; • A aplicação minimiza a necessidade de manuseio de papel;

5 A aplicação foi projetada para trabalhar sem operador, nenhuma intervenção do operador é necessária para operar o sistema além de inicializar e encerrar a aplicação. A aplicação possui rotinas automáticas para recuperação em caso de erro;

A menos que estejamos contando um sistema legado, nós devemos valorar 1 para a

ausência de necessidade de montagem de fitas e a ausência de papel. Nós devemos valorar 3

se intervenção do operador é requerida para backup, inicialização, e recuperação. Um valor de

4 é atribuído se nenhuma intervenção do operador é requerida; e 5 é atribuído para uma

aplicação que executa, e se recupera automaticamente de erros. Nós normalmente esperamos

ver um valor de 3 para aplicações on-line; e um valor mais alto para sistemas de

telecomunicações, processamento industrial, ou em tempo real, que operam sem a sobrecarga

de interfaces humanas.



GSC13: Múltiplos Locais A aplicação foi especificamente projetada, desenvolvida, e suportada para ser instalada em

múltiplos locais, para múltiplas organizações.

0 Os requerimentos do usuário não consideram a necessidade de instalação em mais de um local;

1 A necessidade de múltiplos locais foi considerada no projeto, e a aplicação está preparada para trabalhar apenas em ambientes idênticos de software e hardware;

2 A necessidade de múltiplos locais foi considerada no projeto, e a aplicação está preparada para trabalhar apenas em ambientes similares de software e/ou hardware;

3 A necessidade de múltiplos locais foi considerada no projeto, e a aplicação está preparada para trabalhar em ambientes diferentes de software e/ou hardware;

4 Planos de documentação e suporte foram providos e testados para suportar a aplicação em múltiplos locais, além disso, os itens 1 e 2 caracterizam a aplicação;

5 Planos de documentação e suporte foram providos e testados para suportar a aplicação em múltiplos locais, além disso, o item 3 caracteriza a aplicação.

GSC14: Facilidade de Manutenção (Flexibilidade)

Descreve o nível em que a aplicação foi desenvolvida para minimizar ou facilitar a

modificação da lógica de processamento ou da estrutura de dados. Suas características são:

0 Não há requisito especial de usuário para projetar a aplicação para minimizar ou facilitar mudanças.

1-5 Selecione quais dos seguintes itens se aplicam: • Estão disponíveis facilidades como consultas e relatórios flexíveis para atender

necessidades simples – por exemplo, lógica e/ou aplicada para um ILF (conte um item).

• Estão disponíveis facilidades como consultas e relatórios flexíveis para atender necessidades de complexidade média – por exemplo, lógica e/ou aplicada para mais de um ILF (conte como 2 itens).

• Estão disponíveis facilidades como consultas e relatórios flexíveis para atender necessidades complexas – por exemplo, lógica e/ou aplicada de forma combinada entre ILFs (conte como 3 itens).

• Dados de controle de negócios são armazenados em tabelas que são mantidas pelo usuário através de processos on-line, mas mudanças têm efeito somente no dia seguinte (conte como um item).

• Dados de controle são armazenados em tabelas que são mantidas pelo usuário através de processo on-line. As mudanças têm efeito imediatamente (conte como 2 itens).



Devem ser endereçadas duas categorias separadas para este GSC. A primeira área lida

com a capacidade de consulta e/ou escrita de relatórios frequentemente provida pelas

linguagens tais como SQL ou FOCUS ou por algumas das mais dinâmicas ferramentas de

relatórios (ex.: Crystal Reports); valores de 0 a 3 são atribuídos para esta característica

particular, a qual está se tornando mais popular entre usuários letrados em computação. A

segunda área e as últimas duas questões relacionam-se com a interatividade na qual dados

e/ou informações de controle são mantidos dentro e/ou pela aplicação; sistemas interativos, de

tempo real, de telecomunicações, e de controle de processo serão tipicamente contados com os

últimos dois pontos.



Apêndice B – Detalhamento de Direcionadores de Custo COCOMO II

PERS - Confiabilidade e Complexidade do Produto

A seguinte abordagem é usada para mapear o conjunto total de direcionadores de custo do

modelo Post-Architecture e suas escalas de valores em suas contrapartidas do modelo Early

Design. Isto envolve o uso e combinação de equivalentes numéricos dos níveis de

classificação. Especificamente, um direcionador de custo de Post-Architecture Muito Baixo

corresponde a um valor numérico de 1, Baixo é 2, Nominal é 3, Alto é 4, Muito Alto é 5, e Extra

Alto é 6. Para os direcionadores de custo combinados Early Design, os valores numéricos dos

direcionadores de custo Post-Architecture correspondentes, são somados, e os totais

resultantes são alocados para um modelo Early Design expandido, indo de Extra Baixo a Extra

Alto. A escala de valores do modelo Early Design sempre tem um total Nominal igual a soma

dos valores Nominais dos seus elementos Post-Architecture correspondentes.

Um exemplo irá ilustrar esta abordagem. O direcionador de custo PERS do modelo Early

Design combina os seguintes direcionadores de custo do modelo Post-Architecture: Capacidade

do Analista (ACAP), Capacidade do Programador (PCAP), e Continuidade do Pessoal (PCON).

Cada um destes tem uma escala de classificação de Muito Baixo (=1) a Extra Alto (=6).

Somando os valores numéricos dos mesmos, obteremos valores variando de 3 a 15.

Estes são dispostos em uma escala, e os níveis de classificação do Early Design PERS são

associados a eles, como mostrado na Tabela B.1 – Níveis de Classificação PERS [Boehm-00].

Extra Baixo

Muito Baixo

Baixo Nominal Alto Muito Alto Extra Alto

Soma de ACAP, PCAP, PCON 3, 4 5, 6 7, 8 9 10, 11 12, 13 14, 15 Percentuais combinados de ACAP e PCAP 20% 39% 45% 55% 65% 75% 85% Turnover Annual de Pessoal 45% 30% 20% 12% 9% 5% 4%

Tabela B.1 – Níveis de Classificação PERS [Boehm-00]



O valor Nominal PERS 9 corresponde a soma (3 + 3 + 3) dos valores Nominais para ACAP,

PCAP, e PCON, e seu multiplicador de esforço correspondente é 1. Note, contudo que o valor

Nominal PERS 9 pode resultar de um número de outras combinações, ex. 1 + 3 + 5 = 9 para

ACAP = Muito Baixo, PCAP = Nominal, e PCON = Muito Alto.

Os valores de escala e multiplicadores de esforço para PCAP e os outros direcionadores de

custo mantêm relacionamentos consistentes com seus pares Post-Architecture. Por exemplo, o

valor PERS Extra Baixo (percentual combinado ACAP e PCAP de 20%; 45% de turnover de

pessoal) representa as médias dos níveis ACAP, PCAP, e PCON que somam 3 ou 4.

A manutenção destes relacionamentos consistentes entre os níveis Early Design e Post-

Architecture assegura consistência das estimativas de custo Early Design e Post-Architecture.

RCPX - Disponibilidade de Produto e Complexidade Este direcionador de custo Early Design combina quatro direcionadores de custo Post-

Architecture: Confiabilidade Requerida pelo Software (RELY), Tamanho do Banco de Dados

(DATA), Complexidade do Produto (CPLX), e Documentação (DOCU). Ao contrário dos

componentes PERS, os componentes RCPX têm escalas com diferentes variações. RELY e

DOCU variam de Muito Baixo a Muito Alto; DATA varia de Baixo a Muito Alto, e CPLX varia de

Muito Baixo a Extra Alto. A soma numérica de seus valores irá variar de 5 (MB, B, MB, MB) a 21

(MA, MA, EA, MA). A Tabela B.2 – Níveis de Classificação RCPX [Boehm-00] associa valores

RCPX ao longo deste intervalo, e associa valores de escala apropriados para cada nível RCPX

de Extra Baixo a Extra Alto.

Extra Baixo

Muito Baixo

Baixo Nominal Alto Muito Alto

Extra Alto

Soma de RELY, DATA, CPLX e DOCU

5, 6 7, 8 9 - 11 12 13 -15 16 - 18 19 - 21

Ênfase em disponibilidade, documentação

Muito Pequena

Pequena Alguma Básica Forte Muito Forte

Extrema

Complexidade do produto Muito Simples

Simples Alguma Moderada Complexa Muito Complexa

Extremamente Complexa

Tamanho do banco de dados Pequeno Pequeno Pequeno Moderado Grande Muito Grande

Muito Grande

Tabela B.2 – Níveis de Classificação RCPX [Boehm-00]



RUSE - Reutilização Requerida

Este direcionador de custo Early Design é o mesmo que o seu par Post-Architecture. Um

sumário dos seus níveis de valoração pode ser visto na Tabela B.3 [Boehm-00].

Muito Baixo

Baixo Nominal Alto Muito Alto Extra Alto

RUSE Pequeno Aproveitamento entre projetos de mesma espécie

Aproveitamento entre programas

Aproveitamento entre linhas de produtos

Aproveitamento entre múltiplas

linhas de produtos

Tabela B.3 – Níveis de Classificação RUSE [Boehm-00]

PDIF - Dificuldade da Plataforma

Este direcionador de custo Early Design combina três direcionadores de custo Post-

Architecture: Restrição de Tempo de Execução (TIME), Restrição de Memória Principal (STOR),

e Volatilidade da Plataforma (PVOL). TIME e STOR variam de Nominal a Extra Alto; e PVOL

varia de Baixo a Muito Alto. A soma numérica de seus valores irá variar de 8 (N, N, B) a 17(EA,

EA, MA). A Tabela B.4 [Boehm-00] associa valores PDIF ao longo deste intervalo, e associa

valores de escala apropriados para cada nível PDIF de Baixo a Extra Alto.

Baixo Nominal Alto Muito Alto Extra Alto Soma de TIME, STOR, e PVOL 8 9 10 - 12 13 - 15 16, 17

Restrições de tempo e armazenamento 50% 50% 65% 80% 90% Volatilidade da plataforma Muito estável Estável Volátil em

alguns pontos Volátil Altamente

volátil

Tabela B.4 – Níveis de Classificação PDIF [Boehm-00]



PREX - Experiência do Pessoal Este direcionador de custo Early Design combina três direcionadores de custo Post-

Architecture: Experiência na Aplicação (AEXP), Experiência na Plataforma (PEXP), e

Experiência com Linguagem e Ferramental (LTEX). Cada um destes varia de Muito Baixo a

Muito Alto. Como em PERS, a soma numérica de seus valores irá variar de 3 a 15. A Tabela

B.5 [Boehm-00] associa valores PREX ao longo deste intervalo, e associa valores de escala

apropriados para cada nível PREX de Extra Baixo a Extra Alto.

Extra Baixo

Muito Baixo Baixo Nominal Alto Muito

Alto Extra Alto

Soma de AEXP, PEXP, e LTEX 3, 4 5, 6 7, 8 9 10, 11 12, 13 14, 15

Experiência em aplicações, plataforma e ferramentas

<= 3 meses 5 meses 9 meses 1 ano 2 anos 4 anos 6 anos

Tabela B.5 – Níveis de Classificação PREX [Boehm-00]

FCIL - Facilidades Este direcionador de custo Early Design combina dois direcionadores de custo Post-

Architecture: Ferramentas de Software (TOOL) e Desenvolvimento Multi-local (SITE). TOOL

varia de Muito Baixo a Muito Alto; e SITE varia de Muito Baixo a Extra Alto. A soma numérica de

seus valores irá variar de 2 (MB, MB) a 11 (MA, EA). A Tabela B.6 [Boehm-00] associa valores

FCIL ao longo deste intervalo, e associa valores de escala apropriados para cada nível FCIL de

Extra Baixo a Extra Alto.

Extra Baixo Muito Baixo Baixo Nominal Alto Muito Alto Extra Alto

Soma de TOOL e SITE 2 3 4, 5 6 7, 8 9, 10 11

Suporte de ferramentas Mínimo

Edição, codificação, depuração

CASE com frontend e backend simples, pequena

integração

Ferramentas básicas de ciclo

de vida, integração moderada

Ferramentas de ciclo de vida

fortes e maduras,

moderadamente integradas


fortes, maduras e pró-ativas,

bem integradas com processos,

métodos e reuso

n/a

Condições de desenvolvimento

multi-local n/a

Internacional, alguns

telefonemas e correio

Múltiplas cidades e empresas,

telefone individual e FAX

Múltiplas cidades ou múltiplas

empresas, correio

eletrônico por banda estreita

Mesma cidade ou área

metropolitana, comunicação eletrônica por banda larga

Mesmo prédio ou complexo, comunicação eletrônica por banda larga e

vídeo-conferência ocasional

rede local, multimídia interativa

Tabela B.6 – Níveis de Classificação FCIL [Boehm-00]



SCED - Cronograma Este direcionador de custo Early Design é o mesmo que o seu par Post-Architecture. Um

sumário dos seus níveis de valoração pode ser visto na Tabela B.7 [Boehm-00].

Muito Baixo Baixo Nominal Alto Muito Alto Extra Alto

SCED 75% do nominal 85% 100% 130% 160%

Tabela B.7 – Níveis de Classificação SCED [Boehm-00]

Multiplicadores de Esforço Post-Architecture

Existem 17 multiplicadores de esforço usados no modelo COCOMO II Post-Architecture para

ajustar o esforço nominal no produto de software em desenvolvimento. Eles são agrupados em

quatro categorias: Produto, Plataforma, Pessoal, e Projeto. A Tabela B.8 e a Tabela B.9

[Boehm-00] listam estes diferentes direcionadores de custo com seus critérios de valoração.

Direcionador de custo Muito Baixo Baixo Nominal Alto Muito Alto Extra Alto

RELY Confiabilidade requerida pelo software

Irrelevante, leve

inconveniência permitida

0,82

Perdas facilmente

recuperadas 0,92

Perdas moderadas

1,00

Altas perdas financeiras

1,10

Risco à vida humana

1,26

n/a

DATA Tamanho da base de dados n/a

DB bytes / SLOC < 10

0,90

10 <= DB bytes / SLOC < 100

1,00

100 <= DB bytes / SLOC <

1K 1,14

DB bytes / SLOC >= 1K

1,28 n/a

DOCU Documentação bate com necessidades

do ciclo de vida

Muitas necessidades

do ciclo de vida não são cobertas

0,81

Algumas necessidades

do ciclo de vida não são

cobertas 0,91

Adequada às necessidades

do ciclo de vida1,00

Excessiva para as

necessidades do ciclo de vida

1,11

Muito excessiva para as

necessidades do ciclo de vida

1,23

n/a

CPLX Complexidade do software

controle de operações, operações

computacionais, operações dependentes de máquinas, operações

de administração de dados, operações de

administração de interfaces com usuários

Código simples,

programação não estruturada

e sem aninhamentos

0,73

Programação estruturada,

pouco aninhamento

0,87

Uso de tabelas de decisão,

algum controle entre módulos, aninhamento baixo, algum

suporte à processamento

distribuído 1,00

Considerável controle entre

módulos, controle de

pilhas e filas, aninhamento

alto, processamento

distribuído, controles

simples de tempo real

1,17

Código reentrante e recursivo,

manuseio de interrupções, sincronização

de tarefas, controles de

processamento em tempo real

1,34

Controle de microcódigo, programação dinâmica de

recursos, controle de

processos em tempo real distribuídos

1,74

Fato

res

de p

rodu

to

RUSE Desenvolvido para reuso n/a Nenhum

0,95

Aproveitamento entre projetos

de mesma espécie

1,00

Aproveitamento entre

programas 1,07

Aproveitamento entre linhas de

produtos 1,15

Aproveitamento entre múltiplas

linhas de produtos

1,24

Tabela B.8 – Sumário de Níveis de Direcionadores de Custo Post-Architecture [Boehm-00]



Direcionador de custo Muito Baixo Baixo Nominal Alto Muito Alto Extra Alto

TIME Restrições relativas ao tempo de execução n/a n/a

Uso <= 50% do tempo de

execução disponível

1,00

70% 1,11

85% 1,29

95% 1,63

STOR Restrições quanto ao uso de memória n/a n/a

Uso <= 50% da memória disponível

1,00

70% 1,05

85% 1,17

95% 1,46

Fato

res

de p

lata

form

a

PVOL Volatilidade de plataforma n/a

Período médio de grandes

mudanças = 12 meses; Pequenas

mudanças = 1 mês 0,87

Grandes = 6 meses;

pequenas = 2 semanas

1,00

Grandes = 2 meses;

pequenas = 1 semana

1,15

Grandes = 2 semanas;

pequenas = 2 dias 1,30

n/a

ACAP Capacidade dos analistas (Habilidade de

Análise e Projeto, eficiência e domínio, e a habilidade para

comunicar-se e cooperar)

15o percentil 1,42

35o percentil 1,19

55o percentil 1,00

75o percentil 0,85

90o percentil 0,71 n/a

PCAP Capacidade dos programadores (como um

time - habilidade, eficiência e domínio, e a habilidade para

comunicar-se e cooperar)

15o percentil 1,34

35o percentil 1,15

55o percentil 1,00

75o percentil 0,88

90o percentil 0,76 n/a

PCON Continuidade do pessoal

Turnover de 48% ao ano

1,29

24% ao ano 1,12

12% ao ano 1,00

6% ao ano 0,90

3% ao ano 0,81 n/a

AEXP Experiência na aplicação (time)

<= 2 meses 1,22

6 meses 1,10

1 ano 1,00

3 anos 0,88

6 anos 0,81 n/a

PEXP Experiência com a plataforma (time)

<= 2 meses 1,19

6 meses 1,09

1 ano 1,00

3 anos 0,91

6 anos 0,85 n/a

Fato

res

de p

esso

al

LTEX Experiência com a linguagem e ferramentas

(time)

<= 2 meses 1,20

6 meses 1,09

1 ano 1,00

3 anos 0,91

6 anos 0,84 n/a

TOOL Uso de ferramentas de software

Edição, codificação, depuração

1,17

CASE com frontend e backend simples, pequena

integração 1,09

Ferramentas básicas de

ciclo de vida, integração moderada

1,00


fortes e maduras,

moderadamente integradas

0,90


fortes, maduras e pró-ativas,

bem integradas com processos,

métodos e reuso 0,78

n/a

SITE Desenvolvimento multisite

localização e comunicação

Internacional, alguns

telefonemas e correio

1,22

Múltiplas cidades e empresas,

telefone individual e

FAX 1,09

Múltiplas cidades ou múltiplas

empresas, correio

eletrônico por banda

estreita 1,00

Mesma cidade ou área

metropolitana, comunicação eletrônica por banda larga

0,93

Mesmo prédio ou complexo, comunicação eletrônica por banda larga e

vídeo-conferência ocasional

0,86

rede local, multimídia interativa

0,80

Fato

res

de p

roje

to

SCED Duração requerida para o projeto de desenvolvimento

75% da nominal

1,43

85% 1,14

100% 1,00

130% 1,00

160% 1,00 n/a

Tabela B.9 – Sumário de Níveis de Direcionadores de Custo Post-Architecture [Boehm-00]



Apêndice C – UCP - Cálculo do Valor dos Fatores Técnicos Para facilitar a atribuição do valor do fator, Symons [Symons-01] propôs um conjunto de

regras gerais, que nós adotaremos. O valor deve ser:

• 0 se o fator não está presente ou não tem influência se presente; • 1 se o fator tem influência insignificante; • 2 se o fator tem influência moderada; • 3 se o fator tem influência média; • 4 se o fator tem influência significativa; • 5 se o fator tem forte influência,


diferentes valores. Nesta situação é normal que as pessoas atribuam diferentes escores para os


de guias. Consideraremos para este fim o trabalho de Mike Rankin [Rankin-05], no qual nos

baseamos para escrever este apêndice. O significado dos fatores técnicos que são comuns aos

da técnica de Pontos de Função, já estão descritos no Apêndice A, conforme associações

mostradas na Tabela C.1.

UCP FPA

F1 - Sistemas distribuídos GSC2

F2 - Objetivos de performance, tanto em tempo de resposta quanto em throughput GSC3

F3 - Eficiência do usuário final (on-line) GSC7

F4 - Complexidade do processamento interno GSC9

F5 - Reusabilidade, o código precisa poder ser usado por outras aplicações GSC10

F6 - Facilidade de instalação GSC11

F7 - Facilidade de operação, Usabilidade GSC12

F8 - Portabilidade GSC13

F9 - Facilidade de manutenção GSC14

F10 - Concorrência GSC5

F11 - Características especiais de segurança Karner

F12 - Necessidade de prover acesso direto a terceiros Karner

F13 - Facilidades Especiais para Treinamento de Usuários são Requeridas Karner

Tabela C.1 – Fatores Técnicos Comuns – UCP e FPA



O significado dos fatores técnicos adicionais propostos por Karner [Karner-93] e seus

escores são os seguintes:

F11: Características Especiais de Segurança

Incluem todas as tecnologias que a aplicação requer para proteger a informação que ele

trata. Podem incluir as seguintes:

1. Autenticação do usuário requerida para acessar todas as partes da aplicação 2. Autenticação por multi-fatores (ex.: senha, impressão digital, íris, reconhecimento de voz,

etc.) é requerida para acessar o todo ou partes da aplicação (conte como 2 itens) 3. Aplicação usa canais criptografados para transferir informações entre componentes

(SSL, SSH, etc.) 4. Aplicação gerencia suas próprias chaves 5. Dados sensíveis são armazenados apenas em formulários criptografados

0 Nenhum dos itens descritos; 1 Apenas um dos itens descritos; 2 Dois dos itens descritos; 3 Três dos itens descritos; 4 Quatro dos itens descritos; 5 Cinco ou mais dos itens descritos.



F12: Necessidade de prover acesso direto a terceiros

A aplicação pode ser usada por pessoas ou organizações além da organização

desenvolvedora e do proprietário da aplicação. Podem incluir as seguintes:

1. A aplicação está disponível para o público em geral na Internet 2. A aplicação mantém e gerencia integrações com terceiros 3. A aplicação é consumidora de serviços de terceiros (conte um para cada API de terceiros

consumida) 4. A aplicação publica e documenta uma API pública 5. A aplicação deve manipular diretamente software de terceiros sem utilizar uma API

publicada (conte como dois itens)


F13: Facilidades Especiais para Treinamento de Usuários são Requeridas

Facilidades para treinamentos de usuários foram adicionadas ao projeto ou requeridas

durante a entrega. Podem incluir as seguintes:

1. Ajuda sensitiva ao contexto 2. Documentação impressa do usuário 3. Tutoriais de software automatizados 4. Certificação do usuário é requerida (conte como 2 itens) 5. Cursos conduzidos por instrutor




Apêndice D – UCP - Cálculo do Valor dos Fatores Ambientais Para facilitar a atribuição do valor do fator, Symons [Symons-01] propôs um conjunto de

regras gerais, que nós adotaremos. O valor deve ser:

• 0 se o fator não está presente ou não tem influência se presente;

• 1 se o fator tem influência insignificante;

• 2 se o fator tem influência moderada;

• 3 se o fator tem influência média;

• 4 se o fator tem influência significativa;

• 5 se o fator tem forte influência,


diferentes valores. Nesta situação é normal que as pessoas atribuam diferentes escores para os


de guias. Consideraremos para este fim os trabalhos de Kirsten Ribu [Ribu-01] e Mike Rankin

[Rankin-05], no qual nos baseamos para escrever este apêndice. O significado dos fatores

ambientais e seus escores são os seguintes:

F1: Familiar com o Processo de Desenvolvimento de Software

Na lista de fatores originais proposta por Karner, este fator é chamado de “Familiar com o

RUP (Rational Unified Process)”. Contudo, experiência da indústria mostra que nem sempre os

projetos usam o RUP. Este inclusive é o caso da empresa estudo de caso, que usa um projeto

baseado no RUP, mas adaptado às necessidades da empresa e adequado ao PMBOK [PMI-00]

e ao CMMI [SEI-07].

0 Time não é familiarizado com o processo; 1 Time tem conhecimento teórico do processo de desenvolvimento; 2 Até 30% dos membros do time usaram o método uma ou mais vezes; 3 Entre 30% e 70% dos membros do time usaram o método uma ou mais vezes; 4 Mais de 70% dos membros do time têm experiência usando o método em projetos

diferentes; 5 Todo o time tem experiência usando o método em diversos projetos diferentes.



F2: Experiência com a Aplicação

Este fator indica experiência com o domínio de projeto da aplicação sendo construída.

Considere a experiência do time em projetos construídos para a indústria em particular ou para

a disciplina que o projeto atende.

0 Todos os membros do time desconhecem o domínio da aplicação; 1 Até 50% dos membros do time têm alguma experiência de no máximo 1 ano e meio, os

demais são novatos no domínio da aplicação; 2 Até 80% dos membros do time têm alguma experiência de no máximo 1 ano e meio, os

demais são novatos no domínio da aplicação; 3 Todos os membros do time têm mais que um ano e meio de experiência no domínio da

aplicação; 4 Maioria do time tem no mínimo dois anos de experiência no domínio da aplicação; 5 Todos os membros do time são experientes (mais que 2 anos) no domínio da aplicação.

F3: Experiência com Orientação a Objetos

Este fator indica a experiência do time com análise e projeto orientados a objeto (OOAD).

Embora ele contenha alguns dos aspectos dos dois primeiros fatores, ele é ainda

significantemente diferente no fato que ele também mede a experiência em modelagem, tais

como modelagem de casos de uso na fase de análise, e modelagem de classes e componentes

na fase de projeto.

0 Time é totalmente não familiarizado com OOAD; 1 Todos os membros do time têm menos que um ano de experiência; 2 Todos os membros do time têm cerca de um ano de experiência; 3 Todos os membros do time têm cerca de um ano e meio de experiência; 4 Maioria do time tem no mínimo dois anos de experiência; 5 Todos os membros do time são experientes (mais que 2 anos).



F4: Capacidade do Analista Líder

Este fator mede a experiência com liderança de projetos.

0 Analista líder é novato; 1 Até 2 anos de experiência em apenas 1 projeto; 2 Até 2 anos de experiência em poucos projetos; 3 No mínimo 3 anos de experiência em poucos projetos; 4 No mínimo 4 anos de experiência em diversos projetos; 5 No mínimo 5 anos de experiência com uma variedade de projetos.

F5: Motivação

Este fator descreve a motivação total do time.

0 Desmotivado; 1 Pelo menos 75% do time desmotivado; 2 Pelo menos 50% do time desmotivado; 3 Pelo menos 25% do time desmotivado; 4 Time está motivado para fazer um bom trabalho; 5 Time está muito motivado e inspirado.

F6: Requisitos Estáveis

Este fator indica o grau de mudança de requisitos que pode ser inserido durante o processo

de desenvolvimento. Controle do processo de requisitos inclui os seguintes itens:

1. Existe documento de requisitos formal e este foi assinado pelos membros do time e o usuário final.

2. Sistema de controle de mudanças formalizado está em uso. 3. Revisões de progresso semanais são conduzidas com o usuário 4. A aplicação já existe e o projeto está portando a mesma para uma plataforma diferente

ou para uma versão subseqüente. 5. Existe um protótipo não funcional.

0 Não existe documento de requisitos; 1 Apenas um dos itens descritos; 2 Dois dos itens descritos; 3 Três dos itens descritos; 4 Quatro dos itens descritos; 5 Cinco dos itens descritos.



F7: Trabalhadores em Tempo Parcial

O fator ambiental “Trabalhadores em Tempo Parcial” mede o percentual do time que não se

dedica em tempo integral ao projeto.

0 Não existem trabalhadores em tempo parcial; 1 Poucos trabalhadores (em torno de 20%) em tempo parcial; 2 Poucos trabalhadores (em torno de 40%) em tempo parcial; 3 Parcela razoável dos trabalhadores (em torno de 60%) em tempo parcial; 4 Grande maioria dos trabalhadores (em torno de 80%) em tempo parcial; 5 Todo o time é composto de trabalhadores em tempo parcial.

F8: Dificuldade da Linguagem de Programação

Este fator deve indicar o nível de dificuldade de implementação com a linguagem escolhida,

nível de abstração que a mesma proporciona ao desenvolvedor, usabilidade da IDE e número

de wizards e geração automática de código oferecida pela IDE.

0 Linguagem de programação extremamente fácil de utilizar e com alto grau de abstração, geração automática de 80% do código e alto nível de reutilização;

1 Linguagem de programação extremamente fácil de utilizar e com alto grau de abstração, IDE utilizada proporciona uma vasta gama de wizards e geradores automáticos de código;

2 Linguagem de programação fácil de utilizar e com bom grau de abstração, IDE utilizada proporciona uma grande gama de wizards;

3 Linguagem de programação razoavelmente fácil de utilizar, IDE utilizada tem grau de dificuldade relativamente baixo (linguagens orientadas a objeto - .NET, Java);

4 Linguagem de programação razoavelmente difícil de utilizar, IDE utilizada tem grau de dificuldade grande (linguagens de 3ª geração – C, Pascal);

5 Linguagem de programação bastante difícil de utilizar, IDE utilizada tem grau de dificuldade muito grande (sistemas embarcados, linguagem assembler).



Apêndice E – Exemplo de Caso de Uso O exemplo abaixo é de Alistair Cockburn [Cockburn-00]. Todos os pontos listados no caso

de uso não são obrigatórios, mas um caso de uso deve no mínimo conter um ator primário, o

objetivo a ser alcançado, as pré e pós condições, um cenário principal de sucesso e extensões.

Caso de Uso: 5 Comprar Bens

Informação Característica Objetivo em contexto: Comprador faz requisição diretamente para nossa companhia, espera que os bens sejam despachados e ser faturado. Escopo: Companhia Nível: Sumário Pré-condições: Nós conhecemos o comprador, seu endereço, etc. Condição de fim com sucesso: Comprador recebe os bens, nós recebemos dinheiro pelos bens. Condição de fim com insucesso: Nós não enviamos os bens, Comprador não gastou o dinheiro. Ator Primário: Comprador, qualquer agente (ou computador) agindo pelo cliente Gatilho: Chegada da solicitação de compra. ---------------------------------------- CENÁRIO DE SUCESSO PRINCIPAL 1. Comprador entra com um requerimento de compra. 2. Companhia recupera o nome do comprador, endereço, bens solicitados, etc. 3. Companhia dá ao comprador informações sobre bens, preços, datas de entrega, etc. 4. Comprador assina a ordem de compra. 5. Companhia cria ordem, envia ordem para comprador. 6. Companhia envia fatura para comprador. 7. Comprador paga fatura. ---------------------- EXTENSÕES 3a. Companhia está sem estoque de algum dos itens solicitados: 3a1. Renegociar ordem. 4a. Comprador paga diretamente com cartão de crédito: 4a1. Obter pagamento pelo cartão de crédito (caso de uso 44) 7a. Comprador devolve bens: 7a. Tratar bens retornados (caso de uso 105) --------------------



VARIAÇÕES 1. Comprador pode usar telefone, fax, usar formulário de ordem na web, troca eletrônica (EDI) 7. Comprador pode pagar com dinheiro ou vale cheque cartão de crédito ---------------------- INFORMAÇÃO RELACIONADA Prioridade: top Objetivo de Performance: 5 minutos por ordem, 45 dias até pagar Freqüência: 200/dia Caso de Uso Superior: Gerenciar relação com cliente (caso de uso 2) Casos de Uso Subordinados: Criar Ordem (caso de uso 15) Obter pagamento por cartão de crédito (caso de uso 44) Tratar bens retornados (caso de uso 105) Canal com ator primário: pode ser por fone, arquivo ou interativo Atores Secundários: companhia de cartão de crédito, banco, serviço de entrega Canais para Atores Secundários: ---------------------------- QUESTÕES EM ABERTO O que acontece se só temos parte da ordem? O que acontece se o cartão de crédito é roubado? --------------------------- CRONOGRAMA Data de Conclusão: release 1.0



Apêndice F – Cálculo de Horas por Mês Para calcular o número de horas de trabalho que estão disponíveis em um mês, foram

consideradas as seguintes premissas:

• Ano tem 52 semanas;

• Semana tem 5 dias úteis

• Ano tem 13,5 feriados (contagem em Recife em 2007)

Consideradas estas premissas, procedemos o cálculo:

• 52 (semanas) x 5 (dias úteis) = 260 dias

• 260 – 13,5 (feriados 2007) = 246,5 (dias úteis)

• 246,5 / 12 (meses do ano) = 20,54 dias / mês

• 20,54 x 8 hs = 165 horas / mês

• 1 mês tem 4,3 semanas (52 / 12)

• Neste cenário, 1 semana = 38,4 hs (165 / 4,3)

Na empresa estudo de caso, utilizamos o check-list de estimativas mostrado na Tabela G.1

e na Tabela G.2 [SGQP-07], que reflete a experiência acumulada em inúmeros projetos (mais

de 400).



Apêndice G – Check-list de Estimativas PITANG O check-list de estimativas usado pela PITANG (mostrado na Tabela G.1 [SGQP-07]) reflete

a experiência acumulada em inúmeros projetos da PITANG e do próprio C.E.S.A.R (mais de

400). O check-list é usado pelos estimadores em tempo de pré-venda para assegurar a

avaliação de possibilidades que poderiam de outra forma passar despercebidas, levando em

conta as considerações que eles poderiam de outra forma esquecer. O check-list preenchido é

posteriormente verificado pelo revisor de estimativas (Gerente de Pré-Vendas) para garantir que

o estimador levou em conta todas as possibilidades que cercam a estimativa de pré-venda de

um projeto. O preenchimento do check-list de estimativas é feito respondendo SIM ou NÃO para

cada item, e nos casos em que a resposta for negativa ou houver necessidade de explicação,

sendo explicados os porquês na coluna Justificativa. O objetivo do SIM/NÃO é garantir para o

revisor que o estimador tratou aquele item. Cada item listado é numerado e tem um hiperlink

para uma orientação detalhada do que deve ser avaliado com o uso do mesmo (ver Tabela G.2

[SGQP-07]).

FASE ÍTEM SIM/ NÃO

JUSTIFICATIVA

[47] Projeto de desenvolvimento estimado usando planilha de Pontos de Função

[01] Estimativa realizada com apoio de pessoal do time de engenharia

[02] Possibilidade de envolvimento de parceiros

[03] Proposta tem gerente de projetos

[04] Proposta prevê alocação parcial de engenheiro de configuração

[05] Proposta prevê alocação parcial de engenheiro de qualidade

[06] Proposta prevê alocação parcial de arquiteto

[07] Proposta prevê alocação parcial de analista de negócios

[08] Proposta prevê alocação parcial de engenheiro de software

[09] Considerada a alocação dos designers na etapa de definição de interface do projeto

[10] Considerada a alocação de profissionais de suporte (administrador de rede local, administrador de sistemas, administrador de banco de dados) na proposta

[11] Pessoal alocado já é conhecido

[12] Período de garantia foi previsto

[43] Considerado na estimativa o tempo para a confecção de helps / realização de treinamentos / documentação do sistema

[42] Considerado na estimativa o tempo necessário para os testes integrados, testes de performance, testes de interface (com outros sistemas) e testes de segurança

[44] Há necessidade de especialistas (consultores) no trabalho a ser realizado

[30] Equipe técnica do cliente participará do projeto

Estimativa de pessoal

[13] Proposta prevê transferência de conhecimento



[14] Viagens e diárias estimadas

[15] Passagens pagas pelo cliente Estimativa de Viagens

[16] Avaliada hospedagem em flat

[18] Licenças de software necessárias lançadas

[19] Avaliada a utilização de componentes

[20] Haverá contratação de terceiros

[21] Avaliada a necessidade de aquisição de hardware

[22] Haverá necessidade de treinamentos específicos para a equipe do projeto ou de suporte

[46] Haverá necessidade de contratação de tradutor

Estimativa de Outros

[23] Haverá necessidade de aquisição de livros específicos

[25] Arquitetura e nível de qualidade de acordo com expectativas do cliente

[26] Ambiente de execução suporta os requisitos funcionais e não funcionais

[27] Fatores ambientais e técnicos foram considerados

[28] Foram considerados os riscos associados à proposta

[50] Documento preliminar de requisitos foi produzido e validado pelo cliente

[29]: Escopo positivo e negativo definidos

[49] Os fatores que afetam a estimativa foram identificados e explicados

[31] Definidas validações em marcos do projeto, estando claros os critérios de aceitação de cada marco/etapa/artefato

[32] Analisada a configuração do SGQP para a proposta

[33] Proposta prevê treinamentos

[34] Ambiente de desenvolvimento e de testes da PITANG suporta o projeto

[35] Critérios de finalização da proposta bem definidos

[45] Responsabilidades de cada parte bem definidas

[36] Ambiente de desenvolvimento distribuído

[37] Prazo máximo de início de projeto definido

[38] Sistema com suporte multilíngüe

[39] Ambiente de homologação compatível com ambiente de produção

[40] Previstas iterações curtas

[17] O trabalho será realizado em dependências do cliente [41] Previstas entregas mensais

[48] Proposta de alocação de mão de obra

Escrita Proposta Técnica

[24] Projeto atende restrições de duração e valor estimado lançados pelo GN no SGC

Tabela G.1 – Check-list de Estimativas de Pré-Vendas PITANG [SGQP-07]



CHECKLIST DE ESTIMATIVAS (ORIENTAÇÕES DE PREENCHIMENTO)

[1] É fortemente recomendado o envolvimento de arquitetos, analistas e engenheiros na elaboração das estimativas. A estimativa deve ser validada com a fábrica interna de SW.

[2]

Sempre que necessário deve-se envolver parceiros nas propostas. Isto pode ocorrer por não termos a expertise dentro de casa, ou por não termos o pessoal disponível. Toda proposta que envolva tecnologias não dominadas pela PITANG ou que algum parceiro domina bem, deve ser negociada com as áreas competentes (fábrica, qualidade, suporte) quanto à possibilidade de formação de expertise interno ou quanto à conveniência do envolvimento de parceiros.

[3]

A alocação do gerente de projetos deve ser de 100% apenas nos projetos que realmente demandem isto, quer pelo tamanho da equipe, quer pela demanda de interação com o cliente. Na maioria dos nossos projetos a alocação pode e deve ser parcial (de 10% em projetos de consultoria a 50% em projetos de desenvolvimento de médio porte). Toda proposta deve ter gerente de projetos orçado. Em projetos de consultoria deve-se colocar mais GP no mês 1 e no último mês (reuniões de abertura e fechamento). Em projetos de desenvolvimento a alocação usada deve ser a proposta pela planilha de pontos de função

[4] Em projetos de consultoria a participação do engenheiro de configuração deve se resumir a uma reunião de apresentação no mês 1 (3% no primeiro mês). Em projetos de desenvolvimento deve ser usada a distribuição de esforço sugerida pela planilha de pontos de função;

[5]

O padrão é a alocação de 10% (0,10) de um engenheiro de qualidade durante todos os meses de duração do projeto. Este percentual pode ser maior se o projeto tiver demandas especificas de qualidade, devendo neste caso a negociação ser feita com a área de qualidade (incluir este caso na justificativa). Em projetos de desenvolvimento deve-se usar a alocação proposta pela planilha de pontos de função.

[6]

Arquitetos devem ter alocação conforme a proposta pela planilha de pontos de função. Esta alocação pode ser maior se o projeto tiver demandas especificas, devendo neste caso a negociação ser feita com a área de engenharia (incluir este caso na justificativa). Arquitetos não são responsáveis por gerência de configuração. É necessário fazer a alocação do engenheiro de configuração para este fim.

[7]

Analistas são responsáveis por levantamento de requisitos, modelos de análise e projeto (junto com os arquitetos) e plano de testes. Deve ser criteriosamente avaliada a necessidade de alocação do analista em tempo integral após a etapa de projeto. Avaliar criteriosamente também a necessidade de presença do analista junto ao cliente nas fases iniciais do projeto. Para isto pode ser considerado uma contratação no local de execução ou viagens. A alocação usada deve ser a sugerida pela planilha de pontos de função;

[8] Os engenheiros de SW só devem entrar na etapa de projeto (em caráter parcial) e nas etapas de implementação, testes e implantação (nesta com participação reduzida). A alocação deve ser a sugerida pela planilha de pontos de função;

[9]

A alocação de designers normalmente ocorre durante a fase de projeto, ou no início da fase de implementação. Normalmente esta alocação será a sugerida pela planilha de pontos de função. Projetos que tenham características que impliquem em maior alocação de designer devem ter a estimativa negociada com a área de design (confirmar esta negociação na justificativa).



[10]

A alocação destes profissionais só deve ser feita se as atividades a serem realizadas pelos mesmos extrapolarem as atividades "normais" já previstas no overhead. Estas atividades são: criar bancos de dados de desenvolvimento e homologação do projeto, suportar à modelagem de dados do projeto, suportar à definição de queries ao banco, disponibilizar o ambiente de desenvolvimento e homologação para o projeto (considerando que todos os desenvolvedores estão fisicamente na PITANG). Quaisquer outras atividades, ou se as atividades citadas usarem tecnologias não dominadas pela área de Suporte, deverão ter orçamento de pessoal em separado. Este orçamento em separado deverá ser realizado com o apoio da área de suporte (confirmar esta negociação na justificativa). As atividades listadas abaixo fazem parte da lista de atividades que deverão ter orçamento em separado: Para o cliente: 1.Instalação e tunning de servidores de aplicação e web containers 2.Instalação e tunning de banco de dados 3.Definição de procedimentos operacionais e de backup do sistema 4.Montagem de arquitetura de alta disponibilidade (redundância e balanceamento de carga, tolerância a falhas) 5.Configuração dos demais elementos da rede, como switchs, hubs e roteadores 6.Gerência do ambiente montado. Ambiente de homologação ou desenvolvimento conjunto (PITANG e Cliente): 1.Montagem de ambiente exclusivo para o projeto 2.Acesso a configuração dos servidores de aplicação e web container instalados na PITANG 3.Acesso direto e a configuração dos servidores de banco de dados 4.Acesso ao repositório de código fonte e artefatos do projeto que estejam na PITANG 5.Acesso a qualquer servidor que não tenha sido colocado na DMZ da PITANG Nos casos em que a tecnologia demandada não for dominada pela PITANG, a área de Suporte terá a responsabilidade de buscar os profissionais competentes no mercado (e assumir um compromisso de prazo para isto ocorrer).

[11]

Quando não for conhecido exatamente quem será alocado no projeto que está sendo estimado (quase sempre), deve-se usar o nível médio de cada cargo / nível como padrão (cargos sem nível no SGC - ex: "Gerente de Projetos"). Além disso devem ser previstas em projetos de mais de 6 meses as promoções de pessoal, devendo para isto ser estimada uma faixa a mais para cada profissional em cada ano de projeto. Adicionalmente deve-se considerar que a capacidade de ramp-up da PITANG é de cerca de 10 novos profissionais por mês (negociar sempre este ramp-up com o Resource Manager). Nos casos em que o profissional for conhecido, lançar o enquadramento atual deste profissional (prevendo futuras promoções para projetos longos). Em casos onde se queira especificar um profissional mais júnior ou mais sênior (e não o enquadramento médio), deve-se negociar com o Resource Manager a disponibilidade deste profissional desejado. Por fim, nos casos onde o profissional precise atuar fora de Recife (headquarter PITANG), deve ser sempre negociada com o Resource Manager esta disponibilidade, devido à disponibilidade menor de pessoal fora da sede. Em alguns casos será necessário fazer contratação, devendo-se para isso considerar um prazo mínimo de 1 mês para o processo de contratação;

[12]

Se o projeto for de desenvolvimento ou integração, o esforço / custo necessário para o período de garantia dos projetos deve ser estimado em todos os itens que forem necessários (pessoal, viagens e outras despesas). Lembrar que a garantia deve ter a alocação mínima necessária de recursos, visto que o cliente já pagou pelos serviços de desenvolvimento. Esta alocação pode e deve variar de acordo com os riscos e características de cada projeto, mas sugere-se um valor base mínimo de 10% do que foi estimado no último mês de projeto para os engenheiros de SW, gerente de projetos, analista de negócios. Normalmente consideramos 3 meses de garantia, mas esta duração pode ser menor se o projeto for de curto/médio prazo (até 6 meses);

[13] Os treinamentos previstos e os profissionais necessários para isto estão orçados?

[14]

As viagens e diárias estimadas nas propostas devem ser detalhadas em documento anexo à proposta ou na aba geral do sistema. É importante poder resgatar o porquê das estimativas colocadas. No caso de viagens e diárias, por exemplo, é essencial saber para que e para quem são as viagens (mês a mês). Lembrar que todos os profissionais envolvidos no projeto podem necessitar viajar, incluindo pessoal de suporte e de qualidade. Lembrar também que o número de viagens pode ser aumentado quando o projeto envolver muitos parceiros, ou ainda de acordo com o perfil do cliente (ou mesmo do histórico conhecido dele);

[15]

Informar no sistema que as passagens serão pagas pelo cliente. Este é o caso padrão, para evitar a bitributação. Deixar claro isto na proposta técnica e para o gerente de negócios. Normalmente este pagamento se dará por nota de débito. Em projetos com clientes governamentais, isto não é possível. Uma alternativa é a viagem ser paga diretamente pelo cliente, mas neste caso deve-se atentar para eventuais diferenças nas políticas de viagens dos clientes, que impliquem em valores mais baixos para hospedagem e diárias. Nestes casos podem permanecer as viagens sendo pagas pela PITANG, ou esta pagar apenas as diárias.



[16]

Em casos onde o volume de hospedagens por mês é muito grande, e quando o projeto dura mais de um mês, deve ser avaliada a possibilidade de uso de um flat ao invés de um hotel. Isto pode implicar em uma redução forte de custos. Obviamente deve-se ter o bom senso de considerar que podem compartilhar um mesmo quarto de flat os colaboradores de mesmo sexo;

[17] Deixar claro na proposta que o cliente deverá disponibilizar instalações e todo o material necessário para a realização do trabalho;

[18]

Lembrar de colocar as licenças de softwares necessários para o desenvolvimento do projeto, que não façam parte do pacote padrão de desenvolvimento da PITANG tais como JBuilder, .NET, Together, softwares básicos, etc. Deve-se pedir a cotação à área de compras. Caso este software esteja sendo adquirido apenas para o projeto em questão e não tenha previsão de utilização futura, deve ser integralmente cobrado aqui. Caso contrário deve-se assumir que o SW deprecia em 2 anos e dividir o valor dele por 24 meses, lançando as partes que digam respeito à duração do projeto como custos do projeto;

[19] Deve ser avaliada a possibilidade de utilização de componentes da PITANG ou de terceiros para agilizar e reduzir os custos de desenvolvimento. Estes custos devem ser lançados na aba Outros;

[20]

Os terceiros devem formalizar a sua participação na proposta com uma proposta técnica e comercial deles para a PITANG A diluição do pagamento dos mesmos ao longo do projeto deve ser negociada em conjunto com o gerente de negócios responsável pela proposta. Atentar que caso esta contratação seja via RPA (pessoa física) deverá ser acrescido 20% de custo de INSS a serem pagos pela PITANG nesta contratação.

[21]

Deve-se avaliar a eventual necessidade de aquisição de hardware específico para os servidores ou estações de trabalho do projeto. Se estes servidores serão de uso exclusivo do projeto, esta particularidade deve ser previamente acertada com a área de suporte. Deve-se assumir que o HW deprecia em 2 anos e calcular o valor do leasing dele por 24 meses (ver pasta Leasing). Caso este hardware esteja sendo adquirido apenas para o projeto em questão e não tenha previsão de utilização futura, deve ser integralmente cobrado aqui (leasing de 24 meses ou na duração do projeto, o que for menor). Caso contrário lançar as prestações que digam respeito à duração do projeto. Deve-se assumir que o HW deprecia em 2 anos, e caso o projeto dure mais que 2 anos, prever a renovação do HW ao final de cada 2 anos;

[22] Estimar quando necessário os treinamentos a serem ministrados para a equipe do projeto (ou pessoal de apoio) para a realização das atividades específicas do projeto;

[23] Prever livros para tecnologias não dominadas pela PITANG e/ou equipe do projeto;

[24]

O projeto atende à restrição de duração e ao valor estimado lançado pelo Gerente de Negócios? Se não atende temos como criar alternativas que facilitem a negociação, como por exemplo criar iterações que consigam colocar um escopo mínimo (acertado com o cliente) no ar dentro do prazo inicialmente pensado, ou diminuir o escopo para o que for essencial (acertado com o cliente)

[25]

Perguntar-se qual qualidade e arquitetura que o cliente está desejando ter, e qual está disposto a pagar? Que argumentos temos para uma arquitetura / qualidade mais refinadas do que ele espera (se for o caso)? O cliente deve participar da divisão de iterações e opinar em quais artefatos considera obrigatórios (propor a entrega da menor quantidade possível de artefatos).

[26]

Avaliar o ambiente onde o sistema vai executar e como o mesmo vai executar (não funcional), avaliar as necessidades do cliente e como ele as atende hoje; Quais as necessidades de distribuição, disponibilidade, performance, independência de plataforma, independência de interface? Revisar parágrafos onde requisitos não funcionais estejam descritos para evitar armadilhas de interpretação (ex.: ambientes, versões, integrações, licenças de software e de maneira geral responsabilidades nossas e do cliente);

[27] Considerar os ganhos / perdas que serão obtidas de acordo com o conhecimento do negócio, a maturidade dos profissionais e o uso de ferramentas / recursos de componentes, geradores de código, arquitetura escolhida e artefatos estritamente necessários no processo de desenvolvimento.

[28]

Lembrar de todos os riscos inerentes à solução: - Não fazer estimativas se não estiver seguro da completude e clareza das informações; - Exigir a avaliação dos sistemas existentes no caso de manutenção / reutilização / substituição / integração (observá-los sobre o prisma dos requisitos funcionais e não funcionais). Solicitar os técnicos que forem necessários para esta avaliação; - Lembrar que muitas vezes o cliente (quem nos contrata) não é o usuário (quem vai usar); - Considerar os riscos e incluir as possibilidades de ocorrência dos mesmos nas estimativas de esforço realizadas (usar aba Riscos). Atentar que os riscos que devem ter seu impacto contabilizado no SGC (onerando a proposta) são os que dependem de terceiros, externos à PITANG. Os riscos internos são de nossa responsabilidade (da empresa) devendo seu custo ser assumido dentro da margem do projeto (situações em que o risco seja de alto impacto financeiro devem ser discutidas à parte) - A descrição dos riscos visa comprometer o cliente com o projeto, pois muitos deles poderão estar relacionados ao posicionamento/comportamento do cliente ao longo do andamento do projeto. É importante atentar que alguns riscos não podem ser expostos para conhecimento do cliente, embora devam ser considerados na estimativa.



[29]

Os requisitos devem ser amarrados via detalhamento do escopo negativo e positivo em Documento Preliminar de Requisitos validado junto ao cliente, e posteriormente listados na proposta. Tem que ficar muito claro o que estamos nos comprometendo a fazer e a não fazer. Além disso, deve ser usada a seção de riscos deixando claro que caso os mesmos ocorram, podem vir a ser necessários reajustes de preço e prazo.

[30]

Avaliar, quando requerido pelo cliente, a possibilidade de composição de equipe híbrida (PITANG + profissionais do cliente), especificando o perfil e nível de maturidade dos participantes do cliente para o desenvolvimento da solução. Para efeitos de estimativa a produtividade destes terceiros (se forem pessoas aprendendo a tecnologia) deve ser considerada como sendo de 50% de um profissional da PITANG

[31]

Definir o processo de validações das etapas do projeto e negociá-las junto ao cliente. Muitas validações podem ser realizadas remotamente, reduzindo custos relativos a viagens. Os critérios de aceitação de cada etapa/artefato devem ser claros e explícitos na proposta. Deve ser definido um tempo máximo de espera pelo aceite do cliente. Após este tempo a etapa/artefato será considerado(a) aceito(a).

[32] Deve-se ter uma visão crítica de qual configuração do SGQP se adequa às necessidades do projeto. Esta configuração (tailoring) deve ser feita com o apoio da área de qualidade;

[33]

Os treinamentos devem ser orçados considerando o material necessário (cópias e encadernação), além do tempo necessário para a elaboração e execução dos mesmos. Além disso deve ficar claro de quem é a responsabilidade sobre disponibilidade da infra-estrutura necessária para o treinamento (salas, computadores, projetores, etc.);

[34]

Nos casos em que ambiente disponível na PITANG não suporte o ambiente de desenvolvimento e testes (incluindo testes de stress e integração) do projeto, deve-se prever a disponibilidade deste ambiente (software e hardware) pelo cliente, ou a aquisição do mesmo dentro do projeto. Estes casos devem considerar a estimativa de esforço de administração destes hardware ou da montagem de outro ambiente (ex. banco de dados em versão do cliente). Consultar a área de suporte para a estimativa;

[35] Os critérios de finalização do projeto devem ser explícitos e claros, prevendo inclusive um tempo máximo que se aguardará pela resposta do cliente em relação ao aceite do projeto e artefatos gerados no mesmo;

[36]

Caso o ambiente de desenvolvimento seja distribuído, será necessário o acesso do cliente a ambiente de desenvolvimento e testes da PITANG ou vice-versa. Para estes casos devem ser considerados os pontos observados na nota 10 deste documento. Além disso deve-se atentar ao software de controle de versão que será utilizado, pois o CVS não é muito apropriado para este tipo de demanda;

[37]

O prazo default previsto no texto da proposta técnica é de até 15 dias para iniciar o projeto, uma vez que o cliente dê o de acordo. Este prazo vale para equipes de até 5 pessoas e para projetos nas condições normais de temperatura e pressão. Equipes maiores que 5 pessoas ou projetos que envolvam software/hardware novos a serem implementados devem ter o prazo de início ampliado para 30 dias. Além disso deve ser sempre usado 30 dias quando houver necessidade de pessoal com enquadramento ou conhecimento específico (ex.: fulano de tal, ou alguém com conhecimento na tecnologia X ou no negócio Y). Estes casos devem ser sempre negociados com o responsável por alocação de pessoal em projetos (o Resource Manager ou o Gerente de Suporte/Qualidade, dependendo do perfil profissional)

[38] Deixar claro que o sistema terá suporte a várias línguas (ou não) e em que línguas ele será entregue. Ou seja, suporta diversas línguas, mas a primeira versão só tem os arquivos de configuração para português e inglês (por exemplo)

[39] Deixar claro se o ambiente de homologação é compatível com o ambiente de produção, e em caso contrário, justificar porque não é, e que impactos (riscos) isto traz para a homologação

[40] Deve-se trabalhar com iterações curtas (idealmente de 1 mês). Esta divisão do trabalho permitirá o tratamento antecipado de riscos e a entrega mais rápida de funcionalidades ao cliente, diminuindo a ansiedade natural da espera pelo produto.

[41]

Deve-se sempre prever entregas mensais no projeto, para viabilizar o fluxo de recebimentos (caixa) do projeto de acordo com o envio de entregáveis para o cliente. Planejar o projeto de tal forma a garantir que todo mês se tenha uma entrega (de um ou mais artefatos), para viabilizar a negociação do fluxo de recebimentos por parte do gerente de negócios;

[42] Considerar o uso da fábrica de testes interna para o projeto, negociando com o gestor desta área os custos de contratação e o esforço esperado pela mesma;

[46] Se houver a necessidade de contratação de tradutor, o custo associado a esta contratação deve ser lançado na aba Outros. Estes custos devem ser levantados com a área de marketing ou administrativa.

[47] A planilha de pontos de função deve ser utilizada para todos os projetos de desenvolvimento. As exceções devem ser explicitamente justificadas. Atentar que em contagens de pontos de função, não é considerado o esforço de implementação, devendo este ser estimado e lançado à parte no SGC.

[48] Devem ser definidos os critérios de ramp-up de equipe, troca de profissionais, pagamento de horas extras, horário de trabalho, local de alocação, e recursos necessários à execução do trabalho.



[49]

- Um sumário escrito com os valores de parâmetros assumidos e seus arrazoados devem acompanhar a estimativa. - Premissas devem ser identificadas e explicadas (tudo que for assumido como verdade ou mentira e que influencie a estimativa) - Incertezas em valores de parâmetros devem ser identificadas e quantificadas.

[50] Um documento preliminar de requisitos deve ser escrito e validado com cliente (submissão de Documento de Requisitos para aprovação).

Tabela G.2 – Check-list de Estimativas PITANG - Orientações de Preenchimento [SGQP-07]



Apêndice H – Glossário de Termos Este apêndice explica o conceito de alguns termos importantes que são mencionados no

decorrer deste trabalho, os quais estão diretamente relacionados ao processo de estimativa de

esforço de desenvolvimento de software. Estes termos são descritos abaixo, estando

apresentados por ordem alfabética.

Acessibilidade Ferramentas ou conjuntos de ferramentas que permitem que portadores de deficiências (as mais variadas) se utilizem dos recursos que o computador oferece.

API Application Program Interface. Uma API é um conjunto de comandos, funções, e protocolos que programadores usam quando estão construindo software para um sistema operacional ou ambiente de software específico.

Ator Alguém ou alguma coisa fora do sistema que interage com ele. Por exemplo, usuários do sistema, outro sistema, etc.

Artefato Um pedaço de informação que é produzida, modificada ou utilizada no decorrer do processo. Tudo que é produzido e documentado durante o projeto, podendo ser submetido ao controle de versão. Pode ser um documento, um modelo, código, etc. Por exemplo: plano do projeto, documento de requisitos, defeitos reportados durante a execução de testes, código fonte, código executável, etc.

Baseline Uma baseline é um conjunto de produtos aceitos e controlados, e que serão utilizados em atividades posteriores à sua aceitação

Brainstorming Técnica de dinâmica de grupo para geração e discussão de idéias, enquanto se estimulam os participantes a raciocinar e interagir.

Caso de Uso Uma seqüência de ações que incorpora uma funcionalidade específica ao sistema, fornecendo um resultado de valor para o ator que iniciou sua execução. A especificação de um caso de uso contém todos os fluxos (principal, alternativos e de exceção) das ações relacionadas para produzir os resultados. Em outras palavras, um caso de uso é um conjunto de cenários que capturam os requisitos funcionais.

Commodity Um bem ou serviço cuja disponibilidade massiva tipicamente leva a menores margens e diminui a importância de fatores (como marca) outros que não preço.

Confiabilidade Probabilidade de um item desempenhar uma função, sob condições específicas, de forma adequada, como previsto no projeto, durante um período de tempo pré-determinado.

COTS Comercial-off-the-shelf (COTS) são componentes de software prontos para utilização, de terceiros, comercialmente disponíveis, e que se tornam importantes durante a criação do novo software, devendo ser utilizados preferencialmente durante a fase de pré-desenvolvimento do (software) [Boehm-00].

Desempenho Capacidade do sistema de executar transações dentro de uma unidade de tempo.



DMZ Zona Desmilitarizada - corresponde ao segmento ou segmentos de rede, parcialmente protegido, que se localiza entre redes protegidas e redes desprotegidas e que contém todos os serviços e informações para clientes ou públicos.

Escopo do projeto As características e funcionalidades de um projeto específico. Entregável Um produto entregável é um documento, um programa ou outro produto

de software. Ele é o (um dos) resultado(s) de uma atividade. FSM Functional Size Measurement – Medida funcional de tamanho de

software, conceito definido pelo padrão ISO/IEC 14143-1:1998 Integração Capacidade do software de se integrar a softwares desenvolvidos em

outra tecnologia ou a sistemas pré-existentes. Iteração Uma seqüência de atividades com um plano estabelecido que resulta

em uma versão do produto (interna ou externa). Uma iteração não requer necessariamente uma passagem completa por todos os fluxos de processo do RUP, porém requer no mínimo uma passagem pelos seguintes fluxos: requisitos, análise e projeto, implementação e teste.

Logging Registrar dados de execução de transações em arquivos apropriados para este fim (arquivos de log).

Modelo de ciclo de vida

Estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do sistema desde a definição de seus requisitos até a descontinuação de seu uso.

Patrocinador Pessoas/áreas da empresa cliente que solicitaram o projeto e que estão comprometidas com o sucesso do mesmo.

Pervasivo O termo “pervasivo” não existe no idioma português. Entretanto, para evitar confusão com outros termos também emergentes na área, “pervasivo” será usado neste texto como a tradução do termo em inglês “pervasive”. Pervasive significa estar difundido através de cada parte de um todo, normalmente de forma imperceptível.

Portabilidade Característica das aplicações serem executáveis (ou facilmente recompiladas) noutras plataformas além daquela de origem.

Pré-venda Etapa inicial do processo de venda, que envolve a elaboração de propostas técnicas, com definição de escopo, custos e cronograma

Queries Plural do inglês Query, traduzido como consulta Ramp-up Aumento, Acréscimo Release Um release de software se referencia à distribuição, pública ou privada,

de uma versão inicial ou nova e atualizada de um produto de software. Requisito A descrição de uma condição ou capacidade do sistema. Um requisito

pode ser dividido em funcional e não funcional, estando os funcionais relacionados aos processos de negócios que o sistema deve implementar, e os requisitos não funcionais associados às necessidades de segurança, performance, usabilidade e demais características não relacionadas à implementação de regras de negócios.

Risco Preocupação constante com probabilidade significativa de afetar o sucesso do projeto.



Rule of Thumb Um procedimento ou regra geral ou aproximada baseada na experiência ou prática, ao contrário de cálculos científicos ou de estimativas específicas.

SGC Sistema de Gestão Comercial PITANG SGQP Sistema de Gestão de Qualidade PITANG SLOC Linhas de código fonte do software, desconsiderando linhas de

comentário e em branco. Sistema da Qualidade

Estrutura organizacional, procedimentos, processos e recursos necessários para implementar a gestão da qualidade.

Tailoring Adequação do processo de software da empresa às necessidades específicas do projeto em questão.

Template Documento padrão de um processo, indicando a forma de preenchimento e geração de um documento.

Tunning Sintonia ou ajuste de algum sistema para que funcione melhor. Turnover Rotatividade de pessoal na organização (entrada e saída). Throughput Quantidade de dados que é possível transferir no barramento de dados

ou através de um dispositivo por segundo. Usabilidade Termo usado para definir a facilidade com que as pessoas podem

empregar uma ferramenta ou objeto a fim de realizar uma tarefa específica.

Usuário Uma pessoa que interage com o sistema. WBS Work Breakdown Structure ou Estrutura Analítica de Trabalho é um

agrupamento dos elementos de um projeto, que organiza e define o escopo total do trabalho.

Wizard Um utilitário dentro de uma aplicação que ajuda a usar a aplicação para realizar uma tarefa em particular.

Implantação de Processo de Estimativa de Esforço de … › bitstream › 123456789 › 2685 ›...

Documents

Transcript of Implantação de Processo de Estimativa de Esforço de … › bitstream › 123456789 › 2685 ›...