Post on 30-Jun-2020
Pós-Graduação em Ciência da Computação
“Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso
Real”
Por
Antônio do Rêgo Valença
Dissertação de Mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE, AGOSTO/2007
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 2
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 3
• 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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 4
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 5
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 6
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 7
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 8
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 9
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 10
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 11
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 12
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 13
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 14
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 15
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].
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 16
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:
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 17
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 18
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.).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 19
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/.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 20
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 21
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 22
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 23
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 24
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 25
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]).).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 26
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 27
Tipos de Elementos de Dados 1 - 4 5 - 15 >= 16
< 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 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 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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 28
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
Referenciados > 3 Médio Alto Alto
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 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 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;
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 29
• 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;
Tipos de Elementos de Dados 1 - 5 6 - 19 >= 20
1 Baixo Baixo Médio 2 - 3 Baixo Médio Alto
Tipos de Arquivos
Referenciados > 3 Médio Alto Alto
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 30
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 31
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 32
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:
1. Contagem de pontos de função não ajustados da aplicação, consistindo de EIs,
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;
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 33
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):
1. Contagem de pontos de função não ajustados da aplicação, consistindo de EIs,
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;
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 34
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 35
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 36
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 37
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 38
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 39
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 40
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 41
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 42
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].
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 43
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 44
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 45
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 46
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 47
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 48
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 49
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 50
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].
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 51
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 52
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 53
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 54
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 55
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 56
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 57
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 58
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,
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 59
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 60
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 61
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 62
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 63
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 64
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 65
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 66
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].
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 67
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 68
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 69
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 70
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 71
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;
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Real
Centro de Informática – UFPE Página 72
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
Centro de Informática – UFPE Página 73
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 é
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 74
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 75
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 76
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:
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 77
• 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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 78
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 79
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;
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 80
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 81
É 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].
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 82
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 83
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).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 84
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].
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 85
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 86
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 87
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).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 88
3.2.3.2 UCP
Critério Nota Premissas para Nota
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;
7 10 A técnica é adequada para projetos de qualquer tamanho.
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).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 89
3.2.3.3 NESMA Estimada
Critério Nota Premissas para Nota
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.
7 10 A técnica é adequada para projetos de qualquer tamanho.
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.
10 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.
11 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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 90
3.2.3.4 COCOMO II Early Design
Critério Nota Premissas para Nota
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.
7 10 Mesmo do IFPUG. 8 10 Mesmo do IFPUG.
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
Critério Nota Premissas para Nota
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 91
3.2.3.6 COCOMO II Post-Architecture
Critério Nota Premissas para Nota
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.
7 10 Mesmo do IFPUG. 8 10 Mesmo do IFPUG.
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
Critério Nota Premissas para Nota
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 92
3.2.3.8 NESMA Indicativa
Critério Nota Premissas para Nota
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.
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 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.
10 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.
11 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.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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 93
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.
7 10 A técnica é adequada para projetos de qualquer tamanho.
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 94
3.2.3.12 COCOMO II Application Composition - Pontos de Aplicação
Critério Nota Premissas para Nota
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 95
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 96
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 97
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 98
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 99
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 100
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 101
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 102
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.).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 103
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 104
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 105
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 106
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)
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 107
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 108
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 é
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 109
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”).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 110
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
Vias de comunicação com 3 pessoas
6
Vias de comunicação com 4 pessoas
10
Vias de comunicação com 5 pessoas
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 111
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 112
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 113
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 114
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 115
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 116
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 117
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)
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 118
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 119
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 120
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 121
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 122
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 123
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 124
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 125
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 126
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 127
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 128
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 129
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 130
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 131
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;
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 132
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 133
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 134
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 135
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;
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 136
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 137
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 138
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 139
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 140
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).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 141
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 142
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 143
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 144
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 145
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
Ferramentas de ciclo de vida
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 146
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 147
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
Ferramentas de ciclo de vida
fortes e maduras,
moderadamente integradas
0,90
Ferramentas de ciclo de vida
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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 148
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,
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 escores para os
mesmos fatores nas mesmas circunstâncias. Para evitar este problema é essencial a existência
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 149
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 150
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)
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.
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
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 151
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,
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 escores para os
mesmos fatores nas mesmas circunstâncias. Para evitar este problema é essencial a existência
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 152
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).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 153
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 154
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).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 155
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) --------------------
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 156
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 157
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).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 158
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
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 159
[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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 160
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).
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 161
[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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 162
[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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 163
[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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 164
[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]
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 165
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 166
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.
Implantação de Processo de Estimativa de Esforço de Desenvolvimento de Software - Caso Prático
Centro de Informática – UFPE Página 167
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.