Estimativas

UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO
CENTRO DE CINCIAS EXATAS E TECNOLOGIA
Relatrios Tcnicos
do Departamento de Informtica Aplicada
da UNIRIO
n 0025/2009
PESQUISA EM ESTIMATIVAS
EM PROJETOS DE
MODELAGEM DE PROCESSOS
Claudia Cappelli
Flavia Santoro
Jos Roberto Dutra
Mrcio Barros
Vanessa Nunes
Departamento de Informtica Aplicada

UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO
Av. Pasteur, 458, Urca - CEP 22290-240
RIO DE JANEIRO BRASIL
Projeto de Pesquisa
Grupo de Pesquisa Participante
Patrocnio
ii
Relatrios Tcnicos do DIA/UNIRIO, No. 0025/2009

Editor: Prof. Sean W . M. Siqueira
Dezembro, 2009
PESQUISA EM ESTIMATIVAS EM PROJETOS DE

MODELAGEM DE PROCESSOS *
Claudia Cappelli1, Flvia Santoro1,2, Jos Roberto Dutra1,
1,2
Mrcio Barros , Vanessa Nunes1
1
Ncleo de Pesquisa e Prtica em Tecnologia (NP2Tec)

Departamento de Informtica Aplicada (DIA) Universidade Federal do Estado do Rio de
Janeiro (UNIRIO)
claudia.cappelli@uniriotec.br, flavia.santoro@uniriotec.br, jrcdutra@gmail.com,

marcio.barros@uniriotec.br, vanunes@gmail.com
Abstract. One of the first questions in the initial phase of a process modeling project is
how to estimate the effort to be spent for its implementation. A modeling project is
very similar to a project of software development. This paper surveys the literature on
estimates of effort to carry out projects of modeling business processes and software
development seeking techniques and methods applicable to business processes
modeling projects. The proposal will be applied on a real scenario, on a large brazilian
oil and gas company.
Keywords: Estimate of effort, Metric, Business Process Modeling
Resumo. Uma das primeiras questes na fase inicial de um projeto de modelagem de
processos como estimar o esforo a ser gasto para sua execuo. Um projeto de
modelagem em muito se assemelha a um projeto de desenvolvimento de software. Este
trabalho realizou um levantamento bibliogrfico sobre estimativas de esforo para a
realizao de projetos de modelagem de processos de negcio e desenvolvimento de
software buscando trabalhos contendo tcnicas e mtodos aplicveis aos projetos de
modelagem de processos de negcio na Petrobras.
Palavras-chave: Estimativa de esforo, Mtrica, Modelagem de Processos de Negcio
___________________
Trabalho patrocinado pela Petrobras.
iii
Sumrio
1
Introduo
1.1. Motivao
1.2. Objetivos
1.3. Detalhamento do Problema
1.4. Mtodo de pesquisa
1.5. Estrutura do Relatrio
2 Principais abordagens relacionadas
8
8
8
9
9
10
2.1
A model for Software Development Effort and Cost Estimation
2.1.1
Descrio
2.1.2
Pontos positivos e pontos negativos
2.1.3
Contribuies para o projeto
2.2
A Weighted Coupling Metric for Business Process Models
2.2.1
Descrio
2.2.2
2.2.3
2.3
Comparison of Artificial Neural Network and Regression Models in Software Effort
Estimation
2.3.1
Descrio
2.3.2
2.3.3
2.4
Early estimating using COSMIC-FFP
2.4.1
Descrio
2.4.2
2.4.3
2.5
Complexity Metrics for Business Process Models
2.5.1
Descrio
2.5.2
2.6
Effort estimation of use cases for incremental large-scale software development
2.6.1
Descrio
2.6.2
2.6.3
2.7
Effort Estimation using analogy
2.7.1
Descrio
2.7.2
2.7.3
2.8
Estimation support by lexical analysis of requirements documents
2.8.1
Descrio
2.8.2
2.8.3
2.9
Estimeetings: Development Estimates and a Front-End Process for a Large Project
2.9.1
Descrio
2.9.2
2.9.3
2.10 Expert Judgement as an Estimating Method
2.10.1 Descrio
2.10.2 Pontos positivos e pontos negativos
10
10
11
11
11
11
11
11
12
12
13
14
14
14
16
16
17
17
18
19
19
19
19
19
19
20
20
20
20
20
21
21
21
21
21
22
22
22
2.10.3 Contribuies para o projeto

2.11 Function Points
2.11.1 Descrio
2.12 Functional Size Measurement Revisited
2.12.1 Descrio
2.13 Improving Size Estimates Using Historical Data
2.13.1 Descrio
2.14 Learning how to improve effort estimation in small software companies
2.14.1 Descrio
2.15 The application of case-based reasoning to the software development process
2.15.1 Descrio
2.16 Use Case Estimation The Devil is in the Detail
2.16.1 Descrio
3 Concluses
22
22
22
24
24
25
25
25
25
25
25
26
26
26
26
29
29
29
29
30
30
30
30
31
31
32
33
Requisitos para a proposta de como estimar projetos de modelagem de processos
4.1
Recuperar informaes de projetos similares e suas estimativas, nas bases
histricas.
33
4.2
Possibilidade de elaborao de estimativas ainda em fases iniciais do projeto
33
5 Glossrio
34
Referncias Bibliogrficas
36
Anexo A Planejamento e execuo da reviso sistemtica
38
A.1
Introduo
38
A.2
Planejamento da reviso
39
vi
A.2.1 Objetivo
A.2.2 Formulao da Pergunta (Question Formularization)
A.2.2.1 Pergunta (Question Focus)
A.2.2.2 Abrangncia e qualidade da pesquisa (Question Quality and Amplitude)
A.2.3 Seleo de fontes (Sources Selection)
A.2.3.1 Definio de critrios para seleo de fontes (Sources Selection Criteria Definition)
A.2.3.2 Idiomas (Studies Languages)
A.2.3.3 Fontes de estudo (Sources Identification)
A.2.3.3.1 Mtodo de busca (Sources search methods)
A.2.3.3.2 Expresso de busca (Search string)
A.2.3.3.3 Relao inicial das fontes de estudo (Source list)
A.2.3.4 Seleo de fontes aps validao (Sources Selection after Evaluation)
A.2.3.5 Checagem de referncias (References Checking)
A.2.4 Seleo de estudos (Studies Selection)
A.2.4.1 Definio dos tipos de estudos (Studies types definition)
A.2.4.2 Procedimentos para seleo de estudos (Procedures for studies selection)
A.2.4.3 Critrios de incluso e excluso (Studies inclusion and exclusion criteria definition)
A.3
Execuo da reviso
39
39
39
39
40
40
40
41
41
41
42
42
42
42
42
43
43
44
A.3.1 Lista de Publicaes de Controle

A.3.2 Histrico das Buscas
Anexo B Relatrio de estatsticas de projetos de modelagem de processos
44
44
48
B.1
Introduo
48
B.2
Estudo realizado
49
B.2.1 Conduo do estudo prvio

B.3
Proposta de estimativa
49
50
vi
i
1 Introduo
1.1. Motivao
Atualmente diversas iniciativas em modelagem de processos de negcio so
conduzidas nas organizaes. Projetos so realizados para que estas iniciativas possam
ser implantadas. Para conduo destes projetos so utilizadas em geral prticas de
gerncia de projetos j bastante conhecidas tanto na academia como no mercado.
Uma das primeiras atividades a ser realizada num projeto de modelagem um
levantamento inicial de modo a se identificar o escopo do projeto e ter um prazo para
seu desenvolvimento. Este prazo ser validado a partir de uma estimativa de esforo
necessrio para a concluso do projeto de modelagem e de um volume estimado de
alocao de profissionais para este projeto ao longo do tempo. Porm, uma das
questes inerentes a este contexto, e foco deste documento, como estimar o esforo a
ser gasto para execuo de um projeto de modelagem de processos.
Um projeto de modelagem em muito se assemelha a um projeto de
desenvolvimento de software. Em geral parte-se sempre de um novo escopo e contexto
e deseja-se uma soluo nica, ou seja, construda naquele projeto e
que no ser
repetida em geral. Esta similaridade nos traz tambm a mesma dificuldade que temos
hoje nos projetos de desenvolvimento. A maioria das tcnicas existentes (pontos por
funo, pontos por caso de uso, complexidade de mdulos, linhas de cdigo) no
atende na plenitude as medies de tamanho e derivaes de esforo.
De forma a contribuir nesta linha de pesquisa, estabeleceu-se um projeto para
investigar abordagens e metodologias que tenham como foco a estimativa de projetos
de modelagem de processos.
1.2. Objetivos
Realizar uma busca sistemtica na literatura de Cincia da Computao, em particular
na rea de Engenharia de Software, por trabalhos sobre estimativas de esforo para a
realizao de projetos de modelagem de processos de negcio e desenvolvimento de
software que possam elucidar mecanismos aplicveis aos projetos de modelagem de
processos de negcio na Petrobras. No caso de desenvolvimento de software, o
interesse da pesquisa est voltado para estimativas baseadas em requisitos de negcio
obtidos nas fases iniciais de projetos de sistemas de informao.
1.3. Detalhamento do Problema

Em geral, so realizadas mais de uma estimativa ao longo do ciclo de vida de um
projeto, na medida em que o conhecimento sobre os seus requisitos vai sendo
aprofundado. Portanto, a estimativa mais crtica e difcil de ser elaborada aquela que
acontece na fase inicial do projeto, quando poucos detalhes so conhecidos e no se
tem uma viso clara dos requisitos. Neste momento, a estimativa torna-se um
instrumento para tomada de deciso quanto viabilidade dos projetos.
_____________________________________________________________________________________________
RelaTe-DIA: Pesquisa em Estimativas em Projetos de Modelagem de Processos
8
Apesar da existncia de diversas tcnicas para estimar projetos de desenvolvimento

de software, as estimativas ainda so muito dependentes da experincia dos
estimadores e do conhecimento sobre projetos passados.
Neste sentido, a experincia na elaborao de estimativas de projetos de modelagem
de processos, em diversos Escritrios de Processos da TIC/E&P, levou a equipe da
UNIRIO/NP2TEC a prover um mecanismo de estimao do esforo mdio necessrio
para a realizao de um projeto desta natureza, de acordo com o tipo de projeto e o
nmero de processos modelados. Trata-se de um estudo inicial, realizado com
restries de tempo para levantamento dos dados, organizao dos mesmos e
realizao de anlises alternativas, visando apresentar resultados iniciais que possam
apoiar decises de investimento em projetos de modelagem. Este estudo encontra-se
no ANEXO B.
1.4. Mtodo de pesquisa

O mtodo de pesquisa seguiu as linhas gerais de uma reviso sistemtica. O
planejamento e execuo da reviso so apresentados no ANEXO A.
O desenvolvimento de uma abordagem sistemtica de reviso visa estabelecer um
processo formal para conduzir este tipo de investigao, evitando a introduo de
eventuais vieses da reviso de literatura informal. A reviso sistemtica um tipo de
estudo secundrio (KITCHENHAM, 2004), cujo processo de pesquisa segue um
conjunto de passos metodologicamente bem definidos de acordo com um protocolo
prvio (BIOLCHINI et al., 2005) e cuja adoo procura reduzir o vis inerente a uma
reviso informal (SILVA FILHO, 2006).
1.5. Estrutura do Relatrio

Este relatrio est organizado em seis sees, incluindo a Introduo. Na Seo 2, so
apresentados os trabalhos relacionados, provenientes das leituras e anlises dos artigos
listados na Introduo. Na Seo 3, so discutidas as concluses gerais sobre os
trabalhos relacionados. Na Seo 4, com base nos resultados obtidos, so descritos os
requisitos da proposta deste projeto. As Sees 5 e 6 apresentam respectivamente o
Glossrio e Referncias Bibliogrficas. H ainda o Anexo A que contm o planejamento
e execuo da reviso bibliogrfica realizada e o Anexo B que contm o relatrio de
estatsticas de projetos de modelagem de processos.
_____________________________________________________________________________________________
RelaTe-DIA: Pesquisa em Estimativas em Projetos de Modelagem de Processos
9
2 Principais abordagens relacionadas

2.1
2.1.1
A model for Software Development Effort and Cost Estimation

Descrio
Boehms [1] classifica modelos algortmicos usados para estimativa de esforo da

seguinte forma:
- Modelos lineares (linear models): tambm chamados de modelos matemticos que
traam uma linha simples para os dados observados;
- Modelos multiplicativos (multiplicative models): expressam o esforo como um
produto de constantes com vrios fatores de custo;
- Modelos analticos (analytic models): expressam o esforo atravs de uma funo
que no nem linear nem multiplicativa;
- Modelos tabulados (tabular models): representam o relacionamento entre os
fatores de custo e o esforo de desenvolvimento em forma de matriz;
- Modelos de composio (composite models): usam uma combinao de todos os
modelos acima ou alguns deles. Exemplo: RCA PRICE S, Putnams SLIM Software
lifecycle management, COCOMO.
O modelo de Putnam, objeto de estudo dos autores do artigo, pode ser utilizado na
anlise de processos para avaliar o impacto de um cronograma apertado e prever custo
em termos longos a partir da evoluo do projeto. Dada a mo-de-obra (quantidade e
relao homem-hora) disponvel para o projeto, o modelo de Putnam estima tempos de
completude atravs de tcnicas simples de curve-fitting.
O modelo de Putnam, segundo os autores prev de forma simples um estimativa de
custos para o desenvolvimento de um software. No entanto, sua capacidade em prever
tempo de desenvolvimento e requisitos para quantidade de mo-de-obra em um
estado inicial do desenvolvimento no so satisfatrios. Trata-se de uma inabilidade
inerente de modelos que usam a equao de Norden/Raylegh para representar mode-obra em homem/ano por unidade de tempo (normalmente representado em
Homem-Ano/Ano).
Os autores apresentam o modelo de Putnam atravs das explicaes da curva de
Nordem/Rayleigh, equaes associadas e suas limitaes. O problema principal reside
no fato de que uma previso inicial (early prediction) falha, pois modelos lineares
simplificados falham em capturar a variao inicial das observaes.
Os autores apontam duas formas de tentar resolver essa questo: ajustar a curva
com um grau mais elevado para o conjunto de dados e/ou encontrar uma alternativa
de transformao para os eixos. Essas opes, no entanto, se aplicadas ao modelo de
Putnam, criariam uma complexidade enorme ao modelo e o tornariam muito mais
dependente dos dados e no genrico. Os autores ento propuseram um modelo
chamado GAMMA para compensar essas limitaes usando a segunda forma
proposta.
RelaTe-DIA: Levantamento de Informaes para Modelagem de Processos
10
Eles propem novas equaes para construo de uma nova curva, diferente da de
Norden/Rayleigh e que levam em considerao o grau de transformao baseado em
resduos do conjunto de dados que criam desvios nas curvas. Alm disso, eles levam
tambm em considerao um fator de erro baseado no real e no estimado. Foram
criadas equaes para clculo de cada umas dessas variveis. E para cada explicao,
foi provado matematicamente, a superioridade deste modelo em relao ao de Putnam.
2.1.2
Como ponto positivo, o modelo leva em considerao desvios que podem acontecer
nos projetos e taxa de erro na estimativa.
Como ponto negativo, o artigo no descreve quais dados so importantes para a
construo das variveis utilizadas nas equaes, bem como no apresenta um
exemplo de uso dos modelos e equaes propostas.
2.1.3
Pode ser interessante olhar os aspectos apontados pelo modelo que levam em
considerao desvios, taxas de erros e a taxa de manpower buildup (que relaciona a
quantidade de pessoas e o tipo de projeto que realizado para identificar o quo
realista o cronograma do projeto ).
2.2
2.2.1
A Weighted Coupling Metric for Business Process Models

Descrio
Em um artigo de apenas quatro pginas, os autores ressaltam a similaridade entre

projetos de desenvolvimento de software e projetos de modelagem de processos de
negcio. Baseados nestas similaridades, os autores sugerem a importncia de se definir
e utilizar mtricas nos projetos de modelagem de processos. Com base nesta
afirmativa, apresentam uma mtrica de coeso aplicvel a processos desta natureza.
2.2.2
Como ponto positivo, o artigo serve como referncia para nossa premissa bsica no
projeto: projetos de modelagem possuem similaridades com projetos de software.
Como ponto negativo, a apresentao de uma soluo a procura de um problema.
2.2.3
Como colocado acima, o artigo d substncia a uma premissa que usamos desde o
incio do projeto e que justifica a anlise que estamos realizando sobre tcnicas de
estimao em projetos de software. Isto particularmente importante quando
redigirmos o resumo de tudo que foi lido.
11
2.3
2.3.1
Comparison of Artificial Neural Network and Regression Models in

Software Effort Estimation
Descrio
Os autores comentam sobre a importncia de gesto de projetos de desenvolvimento

de software, em especial do processo de estimativas e em linhas gerais destacam as
variveis que devem ser estimadas em funo da dependncia entre elas como segue
na figura abaixo.
Destacam ainda que as organizaes normalmente querem escolher modelos de

estimativas com maior grau de acurcia no resultado, porm modelos robustos demais
pedem dados mais robustos, concretos e confiveis, e muitas vezes estas organizaes
no possuem essas informaes de antemo.
Os autores citam algumas iniciativas de modelos e mtodos de estimativas.
Inicialmente as propostas tendiam a retirar a subjetividade no processo de estimativas
como o caso de Anlise de pontos por funo, COCOMO e Ordinal Regression
Models (todos possuem referncias).
Eles citam que as tcnicas de anlise e explorao de dados como clustering, casebased reasoning (ex.: ESTOR) e ANN tem surtido efeito na estimativa de esforo do
projeto de desenvolvimento de software.
Os autores citam ainda outras abordagens e combinaes entre elas, mas sempre
com taxas mediana a baixa de performance dos resultados.
Foi realizado um estudo de caso baseado nos dados de um estudo prvio
implementado por Boehm [7] para testar o mtodo COCOMO e o objetivo dos autores
era gerar uma estimativa de esforo para cada fase do projeto de desenvolvimento de
sistemas (O mtodo COCOMO no entanto s apresentava o esforo total).
12
Eles utilizaram o software STATISTICA para encontrar o melhor modelo dentre os

possveis 10 modelos existentes no software, baseado em um nmero de variveis
independentes disponibilizadas no appendix do artigo. Algumas delas so: linhas de
cdigo, tamanhos do banco de dados, tempo de desenvolvimento, volatilidade do
hardware, experincia dos profisionais, etc...
Os autores fizeram um passo de regresso construindo um modelo de regresso
onde era adicionado em cada fase do projeto a varivel com a maior correlao parcial
levando em considerao todas as variveis do modelo. O objetivo era maximizar um
valor F dado. Este valor F servia para verificar, na regresso, se uma determinada
varivel tinha impacto no esforo do projeto. Quando a varivel era acrescentada e o
valor diminua, esta varivel era descartada. O estudo mostrou que apenas a varivel
TOTKDSI (software size in source lines of code) apresentou resultado significativo.
Aps esse estudo eles quiseram refinar retirando o sexto projeto, de seis em seis, dos
63 projetos (criando uma forma quase randmica). Eles queriam diminuir ou verificar
o otimismo que os mtodos acabam por embutir.
O resultado pode ser visto nas tabelas 1 e 2
2.3.2
Pontos positivos: Segundo os autores, tcnicas baseadas em ANN tm sido aplicadas

com sucesso em vrios domnios no sentido de desenvolver solues para estimativas
de problemas, classificao, controle, etc. Estas tcnicas podem ser usadas como
modelos preditivos, pois so capazes de modelar funes complexas. Os autores
13
apontam a questo da dependncia entre parmetros e variveis quaisquer do projeto

que pode causar erros de estimativas.
Pontos negativos: Os autores no explicam como chegaram aos clculos realizados,
o que dificulta o entendimento das tabelas de resultado.
2.3.3
Os autores apostam em tcnicas onde j se possui o valor da varivel tamanho do

projeto. No caso de projetos de desenvolvimento de software, eles tratam de linhas de
cdigo, o que perigoso. Transpondo esta questo para modelagem de processos, o
perigo, ainda que menor, ainda existe, pois no se sabe ao certo o tamanho exato do
projeto. O que facilita que a tcnica de modelagem nica e, portanto o tamanho
mdio levantado de um projeto tende a ser prximo da realidade (levando-se em
considerao um bom levantamento e a no ocorrncia de mudanas de escopo
durante a execuo). Portanto modelos de regresso podem ser interessantes de
investigar.
2.4
2.4.1
Early estimating using COSMIC-FFP

Descrio
Nas fases iniciais de um projeto poucos detalhes so conhecidos mas o impacto de uma
deciso em relao ao desenvolvimento de um sistema de informao grande. Uma
estimativa do tamanho do software a ser desenvolvido tem de ser feita com to pouco
informao quanto possvel e tanta exatido quanto possvel. Neste sentido, vrias
tcnicas so derivadas da experincia sobre quais aspectos de um sistema de
informao podem contribuir na estimativa de tamanho em um estgio inicial de
desenvolvimento como, por exemplo:
Fuzzy logic uma forma de sistematizar as comparaes com os ltimos

trabalhos.
Standard-component sizing identifica uma srie de componentes-chaves que

podem ser comparados com os dados histricos sobre tais componentes.
Proxy-based Estimating atribui um intervalo de tamanho para cada mtodo

conceitual dentro do software a ser estimado usando dados histricos de tais
mtodos.
Wideband-Delphi, onde um nmero de especialistas estima o tamanho de um

sistema de informao com base nos seus requisitos. Um moderador calcula o
tamanho mdio estimado e devolve aos especialistas, juntamente com todas as
outras estimativas, para uma nova rodada. Este processo continua at que o
desvio entre as estimativas seja aceitvel.
FPA i, nesta abordagem um nmero de estimadores estabelece o peso de uma

srie de requisitos. Para cada peso atribudo um valor mnimo, um mais
provvel e um mximo estimado.
Early and Quick Function Point Analysis, mtodo baseado em software para
identificar objetos em diferentes nveis de detalhe. Para cada tipo de objeto h
uma estimativa do valor mnimo, do mais provvel e do mximo.
14
Dependendo do tipo de software que tem de ser produzido e do ambiente de

desenvolvimento, todos estes mtodos podem ser teis, mas quase todos dependem da
experincia dos especialistas e conhecimento sobre projetos anteriores, tornando-os de
certa forma subjetivos. Outra maneira de fazer estimativas iniciais de tamanho por
simplificao da tcnica detalhada de estimao.
Estimativas iniciais utilizando Pontos por Funo:
A primeira simplificao usada quando os elementos so conhecidos mas no

se sabe exatamente os seus respectivos tamanhos: tomar o valor mdio para a EI
(External Inputs), EO (External Outputs) e EQ (External Enquiries) porque
geralmente existe um numero equivalente de funes com complexidade baixa e
alta. Atribuir baixa complexidade para ILF (Internal Logical File) e FEI
(External Interface file) porque mais de 90% dos arquivos so de baixa
complexidade. Esta simplificao, tambm conhecida como FPS (Function
Points Simplified), pode ter uma preciso no intervalo de 5%.
Outra simplificao o fato de que geralmente h uma relao linear entre o

nmero de arquivos lgicos e o nmero de funes transacionais sobre estes
arquivos. Portanto, se houver um modelo de dados j disponvel na terceira
forma normal, possvel estimar a nmero de pontos por funo com base neste
modelo de dados. Para cada tipo de entidade ILF so contados 25 pontos por
funo e para cada tipo de entidade FEI so contados 10 pontos por funo.
Se apenas um modelo conceitual de dados conhecido, uma aproximao

semelhante pode ser usada para estimativa do tamanho. Para cada tipo de
entidade ILF conceitual so contados 35 pontos por funo pontos e, para cada
tipo de entidade FEI conceitual so contados 15 pontos por funo. Desvios de
at 50% tm sido registrados, de modo que este tipo de avaliao s deve ser
utilizado como uma primeira estimativa.
As estimativas por pontos por funo so independentes do ambiente de

desenvolvimento, isto , em todos os ambientes em que a anlise de pontos de funo
pode ser aplicada, estas tcnicas de estimativas iniciais funcionam da mesma maneira.
Em ambientes onde a anlise de pontos de funo no se aplica, estimar o tamanho
usando COSMIC-FFP pode ser uma alternativa. O manual de medio deste mtodo
apresenta duas tcnicas para a estimativa do tamanho inicial: a aproximada e a
aproximada refinada. At o momento em que o artigo foi escrito, havia pouco relato de
experincia prtica usando essas tcnicas.
COSMIC-FFP Aproximada: Nas fases iniciais do desenvolvimento de software apenas
o nmero de processos funcionais conhecido. Para estimar o tamanho de uma
aplicao, o nmero de processos funcionais pode ser multiplicado pelo tamanho
mdio de processos funcionais de um software com caractersticas similares. O manual
de medio do COSMIC-FFP fornece um exemplo de software para aviao militar
onde o tamanho mdio dos processos funcionais 8 cfsu. A experincia no grupo
financeiro Dutch Rabobank aponta um tamanho mdio de 7,2 cfsu, o que sugere que
esta tcnica dependente do ambiente.
COSMIC-FFP Refinada: Esta tcnica um refinamento da anterior, onde os processos
funcionais so divididos em categorias com igual contribuio para o tamanho
funcional da aplicao. O manual de medio do COSMIC-FFP fornece um exemplo
em que classifica os processos funcionais em quatro categorias: pequeno, mdio,
grande e muito grande. Para cada uma destas categorias, so calculados os tamanhos
15
mdios dos processos funcionais de um software local com caractersticas similares

aplicao em questo. Para estimar o tamanho da aplicao multiplica-se, para cada
categoria, a quantidade de processos funcionais pelos respectivos tamanhos mdios
dos processos funcionais do software local. Durante a pesquisa foi encontrada uma
discrepncia entre a forma que o manual do COSMIC-FFP descreve o calculo dos
quartis (categorias) e como eles so efetivamente calculados nos exemplos do manual.
Mtodo 1 (descrito no manual): divide o tamanho total do software por quatro e

encontra o tamanho mdio dos quartis, contendo os processos funcionais
ordenados por tamanho.
Mtodo 2 (usado nos exemplos): divide o numero de processos funcionais por

quatro e encontra o tamanho mdio dos quartis, contendo os processos
funcionais ordenados por tamanho.
Levantamento de estimativas iniciais de tamanho em diferentes ambientes

O final do artigo apresenta nmeros levantados de diversos projetos que utilizaram
COSMIC-FFP para estimativas de tamanho em estgios iniciais do ciclo de
desenvolvimento. A inteno foi avaliar o quanto esta tcnica dependente do
ambiente. Foram selecionados 47 projetos, divididos em quatro setores: bancrio,
governo, seguro e logstico.
Para o mtodo aproximado, embora o tamanho mdio dos projetos de cada setor
fosse da mesma ordem de grandeza, o tamanho mdio dos processos funcionais de
cada setor mostrou-se bastante diferente. Para explicar estas diferenas os autores
apontam a necessidade de futuras investigaes sobre os detalhes dos projetos. Os
nmeros suportam a idia de que existe uma relao entre setor e tamanho mdio dos
processos funcionais.
Para o mtodo refinado utilizando o Mtodo 2, foi observado que os intervalos de
tamanho para as categorias pequeno, mdio e grande ficam muito prximos, no
sendo de utilidade para estimativas em fases iniciais de projeto.
Preciso do mtodo
Os autores recalcularam o tamanho dos processos funcionais com base nos nmeros
encontrados nas estimativas e compararam com os valores reais fornecendo
percentuais de desvio por setor. Os nmeros variaram de 26% a 53% para o mtodo
aproximado, enquanto para o mtodo refinado a variao foi de 7% a 19%.
2.4.2
Como ponto positivo: o fato de ser possvel realizar estimativas de tamanho, em fases
iniciais de projeto utilizando as tcnicas COSMIC-FFP.
Como ponto negativo: pouco relato de experincia prtica usando essas tcnicas.
2.4.3
Os mtodos baseados em COSMIC-FFP podem servir de base para definio de um

mtodo para estimar esforo em projetos de modelagem de processos, principalmente
em relao questo de estimativas em fases iniciais de projeto.
16
2.5
2.5.1
Complexity Metrics for Business Process Models

Descrio
Diversas pesquisas neste sentido tm sido realizadas sobre complexidade de software

com objetivo de estimar taxa de erro, custo de manuteno e partes de software que
devem ser reestruturadas. Neste artigo as idias a respeito da complexidade de
software so discutidas com vistas aplicao nos modelos de processos de negcio.
fornecida uma viso geral dos fatores que podem influenciar a complexidade dos
modelos e mtricas que podem ser usadas para medir estes fatores. A discusso aqui
restrita ao fluxo de controle no envolvendo aspectos como, fluxo de dados e uso de
recursos.
Tamanho do modelo: linhas de cdigo
O dicionrio de padres do IEEE define complexidade de sistema ou componente
como sendo o grau de dificuldade de entendimento e verificao de seu desenho ou
implementao. A medida de complexidade de software mais simples e conhecida a
de linhas de cdigo (LOC) que representa o tamanho de um programa.
Normalmente refere-se ao numero de expresses executveis, desconsiderando-se
comentrios, quebras de linhas etc.
O nmero de atividades pode ser visto como o equivalente ao numero de linhas de
cdigo em um software, sendo a forma mais simples e fcil para medir o tamanho de
um modelo de processo de negcio (BPM). No entanto, o numero de atividades no
leva em conta a estrutura do modelo. Um modelo com 50 atividades pode ser
desenhado de forma bem estruturada e de fcil de entendimento ou, de forma oposta,
ser desestruturado e difcil de entender. Por este motivo, o artigo apresenta a seguir
outras mtricas com objetivo de medir a complexidade do fluxo de atividades.
Complexidade do Fluxo de Controle do Modelo: McCabe-Metric
O nmero ciclomtico, introduzido por McCabe, uma das mtricas de software mais
difundidas e usadas. Corresponde ao numero de decises binrias mais 1. Decises no
binrias com N resultados possveis so contadas como N-1 decises binrias. A
Complexidade do Fluxo de Controle de processos (CFC), generalizao do numero
ciclomtico, definida por Cardoso como sendo o numero de estados mentais que tem
que ser considerados quando um projetista desenvolve um processo.
De forma anloga ao numero ciclomatico, que igual ao numero de decises
binrias mais 1, a mtrica CFC para aplicao em BPMs conta o numero de decises no
fluxo de controle. Cada split no modelo incrementa o numero de decises possveis da
seguinte forma: AND-split soma 1, XOR-split soma N e OR-split soma 2N 1.
Estrutura do modelo: Aninhamento e sadas da estrutura de controle
Apesar de dois modelos possurem o mesmo CFC, eles podem ter complexidades
diferentes. Um fluxo linear tende a ser menos complexo que um com muitas decises.
Os autores consideram as mtricas de aninhamento adequadas para medir este
influncia na complexidade global do modelo. Quanto mais profundo o aninhamento,
maior a complexidade do modelo. A definio desta mtrica simples e direta: igual
ao numero necessrio de decises no fluxo de controle para execuo de um processo.
sugerido o uso desta mtrica de forma complementar ao CFC. No entanto,
17
importante perceber que esta mtrica pode levar a resultados falsos. As ferramentas
grficas de modelagem de processos de negocio no obrigam separaes e junes de
fluxo sejam formadas em pares casados, permitindo assim a criao de modelos com
problemas semelhantes ao da programao no estruturada, com desvios (GOTO)
indesejveis no cdigo.
Na programao de software, foi introduzida a mtrica knot count para medir
estes desvios indesejveis do fluxo de controle.
Um modelo de processo de negcio considerado bem estruturado se possui
separaes e junes apropriadamente aninhadas em pares casados. Esta afirmativa
formalmente definida por meio da terminologia das redes de Petri, onde um workflow
bem estruturado aquele que no possui handles. Esta mtrica aplicvel em
modelos do tipo workflow, tais como EPCs (Event driven Process Chains) que o
padro adotado pela ferramenta ARIS. Algumas ferramentas de workflow possuem
restries semnticas que foram o modelador a construir modelos bem estruturados,
ou seja, com numero de handles igual a zero.
Grau de Compreenso do modelo: Mtricas de Complexidade Cognitiva
Para suprir algumas deficincias da mtrica CFC, outras propostas foram elaboradas.
Por exemplo, dois modelos mostram estruturas de controle com mais de um caminho
sendo executado em paralelo. Neste caso, se a necessidade fosse desenvolver casos de
teste, a mtrica CFC seria extremamente apropriada, porque os casos de teste devem
contemplar todos os caminhos possveis de serem percorridos. No entanto, para
expressar a dificuldade de entendimento do modelo esta mtrica pode no ser
aplicvel. Em alguns casos, o entendimento do modelo independe da quantidade de
caminhos existentes. O artigo cita o peso cognitivo como sendo a mtrica para medir o
esforo requerido para compreenso de um pedao de software. Pesquisadores, com
base em estudos empricos, definiram pesos cognitivos para estruturas de controle
bsicas.
Utilizando-se a esta mesma linha de raciocnio, parece possvel a definio de pesos
cognitivos para BPMs. Neste caso, deve-se considerar que BPMs podem ser modelados
de forma no estruturada, ou seja, levar em conta workflow patterns e antipatterns.
Modularizao do modelo
Para analise da modularizao de um BPM possvel adotar as mtricas fan-in e
fan-out para sistemas de software modularizados, onde: Fan-in refere-se ao nmero de
vezes que um mdulo chamado. Fan-out refere-se ao nmero de mdulos que so
chamados pelo mdulo que est sendo investigado.
2.5.2
Como ponto positivo, algumas das mtricas apresentadas no artigo podem ser
aplicadas diretamente sobre os modelos (no. de atividades, CFC, aninhamento
Max./mdio, no. de "handles" e fan-in/fan-out).
Como ponto negativo, pesos cognitivos, patterns e anti-patterns so mtricas de
software que requerem customizao para aplicao em modelos de processo de
negcio.
18
2.6
2.6.1
Effort estimation of use cases for incremental large-scale software

development
Descrio
A tcnica de Pontos por Caso de Uso (UCP) se baseia na identificao e classificao de

atores e casos de uso de um projeto de software para estimar o esforo necessrio para
o desenvolvimento deste projeto. Os autores propem algumas simplificaes para
aplicar a tcnica e apresentam uma situao onde estas simplicaes foram aplicadas.
2.6.2
Como ponto positivo, os autores documentaram uma forma de calcular o esforo de

manuteno que j aplicada na prtica, tanto em UCP quanto em FP. O estudo de
caso apresentado muito interessante, em especial no que diz respeito distribuio
do esforo ao longo das atividades de desenvolvimento (que poderiam ser ainda mais
detalhadas).
Por outro lado, como aspectos negativos destacam-se o problema da variao de
complexidade das transaes no ter sido resolvido e ainda requerer a anlise manual
por um especialista para identificar se as transaes esto no mesmo nvel de
granularidade e compatveis com o esperado pela tcnica UCP (mesmo este, no bem
definido).
2.6.3
A grande contribuio seria para a primeira fase do nosso projeto, onde foi construda
uma maneira rpida de estimar o esforo para a modelagem de processos. Nesta etapa
o objetivo exatamente o inverso: adicionar detalhes que possam ser obtidos a partir
de uma anlise mais profunda do processo (o que chamaramos de uma estimativa
ps-arquitetural em software) para chegar a uma estimativa mais precisa do esforo.
2.7
2.7.1
Effort Estimation using analogy

Descrio
Os autores fazem uma comparao entre as tcnicas de julgamento por especialistas

atravs da tcnica de DELPHI, as tcnicas de clculo por algoritmos (COCOMO e
Pontos por Funo) e a tcnica de analogia. Chegam concluso de que esta terceira
seria a mais apropriada e constroem uma ferramenta para aplic-la. Acreditam que
esta terceira combina pontos positivos das outras duas tcnicas. Esta tcnica consiste
basicamente na escolha de caractersticas de projetos (escolha feita por especialistas)
que devem ser registradas ao longo do seu desenvolvimento para depois serem
escolhidas e comparadas com os novos projetos (aqui usam-se alguns algoritmos para
seleo e combinao).
19
2.7.2
Como ponto positivo, podemos citar o prprio uso da tcnica de analogias. Ela se
apresenta como mais uma opo para o processo de estimativas e aparentemente tem
vantagens sobre as demais.
Como ponto negativo, podemos citar que o artigo no explicita como so feitos os
clculos para se chegar a que critrios usar e tambm no coloca como feita a escolha
pelos especialistas dos itens que sero pontuados nos projetos. Alm disso, o artigo se
preocupa muito com a ferramenta e pouco fala da tcnica.
2.7.3
Esta tcnica pode ser bastante til neste projeto, pois no caso de projetos de
modelagem de processos na Petrobras j temos vrios realizados que poderiam ser
usados como base histrica. O que teria que ser feito a escolha dos dados a serem
comparados entre os projetos. Um ponto negativo neste caso se para os projetos j
realizados no existirem os dados a serem coletados registrados.
Vale ressaltar que numa primeira fase deste projeto na Petrobras fizemos algo
similar ao que proposto neste artigo. Escolhemos algumas varveis e comparamos
entre vrios projetos para obter uma estimativa a ser usada para comparar com novos
projetos.
2.8
2.8.1
Estimation support by lexical analysis of requirements documents

Descrio
Embora o resumo e a introduo levem a crer que trata-se de um artigo sobre

estimativa de esforo para o desenvolvimento de um sistema, os autores focalizam a
identificao das classes centrais para o projeto e implementao deste software. Os
autores argumentam que o nmero de classes est diretamente relacionado com o
esforo, apresentam e comparam duas tcnicas baseadas na anlise lxica de
documentos de requisitos para identificar as classes. O artigo apresenta uma validao
da proposta, onde os resultados das tcnicas baseadas na anlise lxica so
comparados com os resultados obtidos por um especialista e um conjunto de alunos.
2.8.2
Como ponto positivo, uma anlise lxica mais estruturada pode ajudar a encontrar as
principais classes de um projeto orientado a objetos. No entanto, h de se questionar
at onde esta questo realmente relevante. Ela foi extensamente abordada no incio
dos anos 90, quando do incio da aplicao de tcnicas orientadas a objetos na anlise e
projeto de sistemas, sendo praticamente esquecida desde ento.
Como ponto negativo, verifica-se que no trivial estimar o esforo para a
realizao de um projeto baseado apenas no nmero de classes chave deste.
20
2.8.3
O artigo cumpre um papel importante no projeto de pesquisa por chamar a ateno

sobre a possibilidade de extrairmos informaes de uma descrio sucinta do processo.
Com base em uma anlise lxica, pode ser vivel identificar o nmero de atividades, de
riscos e de outros elementos que no temos quando comeamos a fazer as estimativas.
Algo para ser pensado medida que a proposta do mtodo for evoluindo.
2.9
2.9.1
Estimeetings: Development Estimates and a Front-End Process for a

Large Project
Descrio
Os autores abordam as principais dificuldades relacionadas com as estimativas de

projetos de desenvolvimento de software, quebrando o processo de estimao em duas
fases essenciais: a estimativa do tamanho e a estimativa do esforo (a partir do
tamanho). Os autores observam que a principal dificuldade envolvida nas estimativas
est em identificar o trabalho que deve ser realizado para implementar uma
determinada funcionalidade. Assim, ressaltam a importncia de tomar as decises
sobre estimativas em grupos, onde estejam representados os principais envolvidos na
arquitetura do projeto (representantes de subsistemas) e tcnicos especialistas em
estimao de projetos de software.
2.9.2
Como pontos positivos, os autores destacam que a discusso sobre as estimativas

distribui um comprometimento sobre sua execuo, permite que os melhores
profissionais participem das decises sobre as estimativas e exige que as equipes
funcionais preparem um material de qualidade para ser entregue e digerido antes da
reunio.
Como ponto negativo, destaca-se que os autores no apresentam evidncias claras
sobre a melhoria do processo de estimao (apenas informaes subjetivas sobre suas
percepes sobre o mtodo).
2.9.3
O artigo segue uma linha diferente do que estamos abordando. Ao invs de destacar
informaes relevantes para as estimativas e buscar uma frmula ou derivao baseada
nestas informaes, o artigo destaca a tomada de deciso em grupo a partir da juno e
discusso de diferentes vises construdas de forma subjetiva. Considerando as
divergncias existentes nos dados que utilizamos na estimativa inicial que geramos
para o projeto, talvez seja possvel pensar em uma tcnica que envolva grupos de
discusso sobre o tema para gerar a estimativa de um novo projeto. uma linha
distinta das propostas at ento revistas, mas talvez seja complementar de acordo com
a preciso que conseguimos obter dos dados atuais que vm sendo analisados.
21
2.10 Expert Judgement as an Estimating Method

2.10.1 Descrio
Os autores apresentam uma avaliao crtica dos diferentes mtodos de estimativa
utilizados para avaliao do esforo necessrio para a realizao de tarefas ligadas ao
desenvolvimento e manuteno de software. Em particular, os autores criticam a
classificao de Barry Boehm sobre o tema, reorganizando as classes de mtodos
sugeridas por Boehm em um modelo matricial (ao invs de uma lista de alternativas).
De posse desta matriz, os autores identificam a necessidade de opinio subjetiva e
interveno manual em todos os mtodos. Assim, eles destacam a importncia de se
entender a forma com que os especialistas conduzem o processo de estimao, como
forma de se aprimorar os demais mtodos.
Como ponto positivo, o artigo apresenta diversas consideraes interessantes sobre o
uso de especialistas nos processos de estimao.
Como ponto negativo, os resultados do estudo realizado no so exatamente
surpreendentes e o objetivo principal, conforme expressado na introduo do artigo,
acaba se perdendo devido a caractersticas prprias da empresa onde o estudo de caso
foi conduzido.
No aparecem muitas contribuies para o projeto. Na concluso, os autores deixam
um tema para reflexo, sugerindo que mtodos de estimativa deveriam se integrar s
opinies de especialistas ao invs de tentar substitu-las, fornecendo meios para que os
especialistas tenham mais informao para tomar suas decises e no incorram em
esquecimento de partes importantes do projeto. Alguns mtodos baseados em IA e na
representao e gerenciamento de conhecimento propem algo nesta linha, mas nunca
vi um estudo prtico sobre sua aplicao.
2.11 Function Points

2.11.1 Descrio
Alguns mtodos para realizar medio da funcionalidade de software vm sendo
propostos, e estes variam de acordo com o que medir e como so feitas estas medies,
alm de sua utilidade, aplicabilidade e aceitao na indstria. Medidas de tamanho
podem focar ou no problema que o software pretende tratar ou pelo programa em si,
ou seja, a soluo.
O problema expresso na especificao funcional, atravs dos requisitos, e a
soluo possui um tamanho fsico (comprimento ou extenso). Assim, funcionalidade e
comprimento so dois aspectos diferentes do tamanho de um software. Medir
comprimento fcil, a medida mais comum o nmero de linhas de cdigo (LOC).
Porm medir funcionalidade mais complicado, diversos mtodos j foram propostos:
Pontos por funo do IFPUG; Pontos por funo Mark II; Cosmic,entre outros.
22
O mtodo pontos por funo foi proposto por Albrecht em 1979. Basicamente
consiste em contar certos componentes que representam manifestaes visveis do
software com pesos que devem refletir seu valor para o cliente, e depois ajustar o
resultado para incorporar fatores inerentes complexidade tcnica da aplicao. Uma
reviso na proposta inicial foi feita em 1984.
A primeira fase do mtodo pontos por funo consiste em identificar certos
componentes do sistema que provm funcionalidade ao usurio: entradas externas,
sadas externas, consultas externas, arquivos lgicos internos e arquivos externos de
interface. O nmero de pontos associado a cada componente depende de sua
complexidade funcional.
A segunda fase do mtodo consiste em realizar um ajuste no resultado obtido com a
contagem. Para isso definido um Fator de Ajuste com base em 14 caractersticas
gerais de sistema: comunicao de dados, processamento distribudo de dados,
performance, configurao, taxa de transao, entrada de dados em tempo real,
eficincia do usurio final, atualizaes em tempo real, processamento complexo,
reusabilidade, facilidade de instalao, facilidade de operao, mltiplos sites,
facilidade de mudanas.
Vrias experincias com o uso deste mtodo e sua boa aceitao no mercado
comprovam seu valor. No entanto, existem crticas quanto aos problemas tericos na
construo do mtodo: a primeira fase envolve medidas em escala absoluta, mas
depois passa a ser escala ordinal; na funo de ajuste tambm existem inconsistncias
nas operaes aplicadas; a origem e objetividade dos pesos tambm so questionadas.
Isso resulta que a medida invlida em vrias situaes. Questiona-se ento o que
realmente medido (funcionalidade, tamanho), e qual deve ser sua utilizao (estimar,
determinar produtividade).
O fato que a proposta adequada para sistemas fortemente baseados em
manipulao de dados, onde o processamento relativamente simples. Em outros
tipos de sistema (engenharia, cientficos, tempo real), no se aplica com a mesma
eficincia. Desta forma, algumas abordagens alternativas vm sendo propostas.
Mark II Functions Points foi proposto como uma evoluo da abordagem original
de Pontos por Funo (IFPUG). Nesta proposta, um sistema considerado como uma
coleo de transaes lgicas consistentes. Com entrada, processamento e sada. O
tamanho de uma transao a soma do tamanho de suas entradas, sadas e
processamento. O tamanho de um sistema a soma dos tamanhos de suas transaes.
Uma medida baseada em Mark II FP pode ser convertida para IFPUG atravs de
uma frmula que foi derivada empiricamente.
Alm de Mark II, outras alternativas foram propostas na tentativa de resolver
problemas apontados nesta abordagem: DeMarcos Function Weight (System Bang);
3D Function Points; Feature Points.
System Bang considera sistemas fortemente baseados em funes (conta o nmero
de funes no DFD), dados (conta o nmero de elementos no modelo de dados), ou
hbridos. 3D Function Points mede sistemas com processamento em tempo real e
cientficos. Feature Points mede sistemas com alta complexidade algortmica.
Nenhuma destas abordagens conseguiu alcanar o xito pretendido, segundo os
autores.
COSMIC (Common Software Measurement International Consortium) um
consrcio formado por vrios pesquisadores com objetivo de prover uma nova
23
abordagem para medio e estimativa de software independente do tipo,

prioritariamente software para apoio a negcios e tempo real (Full Function Points). Os
princpios em que se baseia esta abordagem so: requisitos funcionais do software so
definidos como conjunto de processos funcionais; software manipula pedaos de
informao (Figura 1) chamados grupos de dados; processos funcionais envolvem subprocessos funcionais de acordo com movimento dos dados e transformaes nos
grupos de dados; o tamanho funcional diretamente proporcional ao seu nmero de
movimento de dados; o tamanho de uma aplicao a soma dos tamanhos de seus
processos funcionais.
Figura 1 Movimentos dos dados em Full Function Points.
COSMIC-FFP apresenta duas inovaes importantes: camadas e pontos de vista de

medidas (measurement viewpoints).
Especificamente para software orientado a objetos, vrias abordagens foram
propostas para adaptar os conceitos de FP para os elementos e modelos OO. Use Case
Points calculam o tamanho do software com base no modelo de casos de uso, ao invs
de contar transaes e dados, conta-se atores e casos de uso. Alm disso, o resultado
obtido um valor de esforo e no de tamanho como em IFPUG. O mtodo prope 3
estgios: identificao e classificao dos atores; identificao e classificao dos casos
de uso e aplicao de um fator de ajuste.
Os autores fazem uma descrio de cada mtodo, comparam e apresentam um
histrico de pesquisas na rea.
No h pontos negativos.
Pode ser interessante olhar outros aspectos que no somente a quantidade de funes
(ou atividades) para estimar projetos de modelagem de processos, tais como os
24
diversos mtodos de FP fazem (por exemplos, quantidade de informao manipulada

pode ser um bom indicativo de esforo para modelagem do processo).
2.12 Functional Size Measurement Revisited

2.12.1 Descrio
Os autores relacionam uma srie de mtodos para medir tamanho e estimar software
baseados em pontos por funo e afirmam que na medida em que vinham sendo
apresentados, inconsistncias entre eles eram detectadas. Desta forma, a International
Organizacional of Standard (ISO) passou a definir padres e atualmente 4 mtodos so
certificados: IFPUG, Mark II FP, COSMIC-FFP e NESMA FSM. Eles se diferenciam
entre si pelo que contam e como contam, mas todos so baseados em funcionalidades
disponibilizadas para usurios. Os autores realizaram dois estudos de caso para
avaliar os mtodos baseados em FP.
O primeiro estudo de caso teve como objetivo avaliar a aplicabilidade dos mtodos
na medio de projetos em diferentes domnios funcionais e por isso envolveu 3 casos.
O segundo estudo teve carter exploratrio e o objetivo foi avaliar a aplicao de
vrios mtodos em diferentes fases de um projeto de software.
Os autores descrevem em detalhes as questes que no funcionam nos mtodos em
seus estudos.
As questes descritas so basicamente conceituais. Ao tomar estes mtodos como base,
ser importante verific-las tambm.
2.13 Improving Size Estimates Using Historical Data

2.13.1 Descrio
Os autores comentam sobre a necessidade de se ter um processo ou mtodo de
estimativas de tamanho para desenvolvimento de sistemas. Porm mesmo sem um
processo de estimativas definido, as equipes de desenvolvimento de software, no geral,
j desenvolveram diversos softwares e portanto possuem uma grande quantidade de
informaes acerca do tempo para realizar cada desenvolvimento que pode ser
utilizado para estimar desenvolvimento futuros.
Os autores ento realizaram um estudo em cima de um grande projeto de um
sistema desenvolvido em C++ voltado para geocincia, o qual continha todos os dados
de tamanho e tempo de desenvolvimento de cada fase e parte do software.
Eles estudaram se existia algum elemento especfico que impactava no tempo de
desenvolvimento de software como, por exemplo, os seguintes elementos mais
25
utilizados no projeto: Elementos GUI em um componente, mudanas de evento e

estado tratados, nmero de funes por componente, nmero de componentes
reutilizados.
Concluram que sim e que ainda estes elementos impactam uns nos outros.
Foram construdos grficos mostrando a correlao entre os elementos elencados e
os estudos mostram que o tamanho do software est relacionado a diversos nveis de
abstrao do sistema e de quais elementos se adota em sua construo.
Como ponto positivo, prope a identificao da relao entre diferentes elementos do
sistema.
Como ponto negativo, realiza a pesquisa baseado em um nico projeto e nos
elementos usualmente utilizados por uma equipe especfica restringindo o estudo.
Uma pequena equipe bastante uniforme.
No h contribuies expressivas para o projeto. A no ser por reforar o fato de que
existem variveis que ao serem adicionadas em um projeto impactam em outras j
existentes.
2.14 Learning how to improve effort estimation in small software

companies
2.14.1 Descrio
As estimativas de esforo para desenvolvimento de software requerem o entendimento
e conhecimento de fatores peculiares organizao e ao seu processo de
desenvolvimento. Por exemplo, os mtodos utilizados e a equipe de desenvolvimento
influenciam no calculo do esforo. considerado pouco realista a existncia de um
modelo matemtico ou sistema estatstico que determine com exatido o esforo
requerido.
Na prtica, o uso da memria das pessoas (conhecimento), a avaliao e suposio
dos estimadores continuam sendo a abordagem mais comumente utilizada para
estimar esforo. Desta forma as estimativas so subjetivas. Mesmo usando alguma
tcnica conhecida, as estimativas de esforo produzidas so inerentemente subjetivas.
Neste sentido, proposto que a melhoria na exatido das estimativas seja alcanada
atravs da abordagem Bayesiana.
A inferncia Bayesiana pode fornecer uma estatstica da tendncia de subjetividade
do estimador durante a estimativa de atributos que so medidos em uma escala
ordinal. Esta abordagem pode habilitar a produo uma distribuio de erros
individual, para cada estimador, sobre uma escala ordinal de medida de esforo. Esta
distribuio de erros pode ser usada pelos estimadores para que eles verifiquem o
quanto suas estimativas diferem de uma estimativa de consenso de um grupo ou do
esforo real de desenvolvimento dos sistemas. Este processo de aprendizado pode ser
usado para melhoria da exatido das estimativas. Entretanto, para determinar a
26
distribuio de erros necessrio coletar dados das estimativas, dos fatores

relacionados e dos esforos reais.
O principio bsico deste artigo que as caractersticas de uma pequena empresa de
desenvolvimento de software requerem uma abordagem de suporte s estimativas de
esforo que seja compatvel com suas prticas de trabalho. O segundo princpio que o
suporte deve ser dado considerando a abordagem atual da organizao para
elaborao das estimativas, mesmo que no seja a mais apropriada. Mesmo existindo
um bom mtodo de estimativas apoiado por sistema provvel que haja restries de
recursos e tempo em pequenas organizaes que impeam a sua plena utilizao. Ou
seja, qualquer tipo de suporte deve permitir que as pequenas organizaes utilizem
seus prprios mtodos de estimativas.
Pequenas empresas utilizam estimativas que incluem tendncias subjetivas, a
experincia e o conhecimento de seus desenvolvedores. Alm disso, com freqncia
esto envolvidas com solues e domnios de problemas completamente novos.
O suporte s estimativas de esforo em pequenas empresas necessrio em duas
reas: Primeiro para melhorar a exatido das estimativas quando o domnio do
problema e soluo conhecido. Segundo, para quando o domnio desconhecido e
neste caso, o conhecimento das tendncias de subjetividade do estimador e sua
classificao de valores de fatores do diferente domnio do problema e soluo podem
ajudar a melhorar futuras estimativas para domnios novos e desconhecidos. Coleta de
dados e anlise estatstica podem reduzir o nmero de domnios desconhecidos.
Outro ponto de destaque que as estimativas devem ser consistentes. Tendo em
vista que elas so medidas subjetivas e no muito acuradas, sugere a utilizao de uma
escala de medida ordinal como base para os estimadores realizarem suas estimativas
de comum acordo. A escolha de fronteiras/patamares apropriados para os intervalos
da escala ordinal pode fornecer medidas consistentes.
O artigo faz referncia a um manual (Gibbs Sampling) que pode ser usado para
definir os parmetros de distribuio de probabilidade que represente a distribuio
dos erros dos estimadores quando o esforo real e os dados da estimativa so
fornecidos para um modelo estatstico apropriado. Desta forma, julgamentos baseados
na intuio e experincia so incorporados sistematicamente ao modelo em conjunto
com as observaes dos dados obtidos, a fim de obter estimativas mais confiveis.
A abordagem Bayesiana para inferncia da distribuio de erros pode ajudar os
estimadores no aprendizado e melhoria de suas habilidades em domnios conhecidos.
Isto pode ser alcanado atravs da leitura de suas prprias tendncias subjetivas,
medidas sobre uma gama de estimativas de esforo. Com base nas suas provveis
tendncias de erro, os estimadores podem ajustar suas estimativas, conforme
representado no desenho abaixo:
27
A prtica corrente nas empresas que participaram do levantamento envolvia de

uma a duas estimativas distintas: a primeira no estudo de viabilidade e a segunda aps
o levantamento de requisitos.
Nesta empresas, os fatores e atributos utilizados pelos estimadores para elaborarem
suas estimativas so:
Domnio do problema
Setor de negcio
Tipo de sistema
Domnio da soluo
Hardware
Software (linguagens de programao)

Ferramentas
Mtodos de desenvolvimento
Nvel de conhecimento do cliente/usurio sobre a aplicao/domnio do

problema, medido numa escala ordinal.
Conhecimento da equipe/estimador sobre:

Aplicao/domnio do problema
28
Domnio da soluo: linguagem, hardware e outras restries tcnicas, como

por exemplo, velocidade de execuo.
ID do estimador.
Numero de mdulos que provavelmente sero necessrios.
Complexidade de cada mdulo avaliados em uma escala ordinal (simples,

mdio, complexo, muito complexo, extremamente complexo: 1, 2, 3, 4, 5).
Dados adicionais podem ser coletados:

Esforo da fase de design
Esforo da fase de implementao
Esforo da fase de testes
Overheads
Cada estimador interpreta estes fatores usando sua experincia e ponto de vista
pessoal. As estimativas de um projeto so frequentemente elaboradas por mais de um
estimador.
No caso de domnios de problemas e solues desconhecidos, a distribuio de
erros existente pode mostrar como um estimador adapta suas estimativas como
contingncia em novos domnios. Os estimadores podem isolar esta informao
usando a distribuio de erros do domnio antigo e voltar para reavaliar os fatores de
ajuste e contingncias usadas na estimativa para novos domnios quando os valores
reais estiverem disponveis.
Os autores fazem uma proposta para melhoria das estimativas de forma independente
do mtodo ou tcnica utiliza para estimar o esforo. A idia que os estimadores
tenham um instrumento para entender o seu comportamento e ajustar as prximas
estimativas.
A abordagem apresentada permite que o conhecimento prvio (histrico) seja
considerado na realizao/ajuste das estimativas, o que pode ser de interesse para o
projeto.
2.15 The application of case-based reasoning to the software

development process
2.15.1 Descrio
O artigo, apoiado em uma ferramenta comercial, demonstra um mtodo em que o
raciocnio baseado em casos (CBR) pode ser aplicado ao processo de desenvolvimento
de software. Definio de requisitos, estimativa de esforo, desenho de software,
localizao de defeitos e manuteno so discutidos como candidatos tecnologia
29
CBR, que explorada como um mecanismo para melhoria da produtividade e

qualidade do desenvolvimento de software.
O artigo descreve os passos do processo de raciocnio baseado em casos: avaliao
da situao, pesquisa do caso, recuperao do caso, avaliao do caso e manuteno da
base de casos. O prottipo apresentado consiste de casos que descrevem projetos de
software. Cada projeto identificado por um nmero nico, nome, descrio, ambiente
de hardware, linguagem ou pacote usado no desenvolvimento, nmero de pontos de
funo e cinco caractersticas (semelhantes aos fatores de ajuste da anlise de pontos
por funo). O nmero de pontos de funo til para limitar a pesquisa a projetos
que provavelmente tenham esforos de desenvolvimento semelhantes.
Em relao a mtodos ou tcnicas de estimativas em projetos de software, o assunto
praticamente no explorado. So feitos apenas alguns comentrios, tais como:
CBR tem o potencial de reduzir o esforo, e conseqentemente o custo, para

produzir pontos por funo atravs da facilidade de reutilizao de mdulos,
objetos, desenhos etc.
Com a reteno das informaes das estimativas nos casos, a tecnologia CBR
pode afetar de maneira positiva o processo de estimativas de esforo e custo,
oferecendo uma forma de estimar baseada em um gama de experincia bem mais
abrangente.

Como ponto positivo, a proposta de uso de CBR para recuperao de histricos de
estimativas.
Como ponto negativo o fato do artigo no ter foco em algum mtodo ou tcnica de
estimativas que o assunto de interesse do projeto.
A sugesto de uso da tecnologia CBR pode ser interessante caso o projeto caminhe para
uma soluo baseada em estimativas por analogia com consultas intensivas em
histricos de estimativas.
2.16 Use Case Estimation The Devil is in the Detail

2.16.1 Descrio
Os autores fazem um resumo breve sobre as tcnicas de Pontos de Funo, Pontos por
Caso de Uso e Estrutura Analtica do Projeto (EAP). E indicam que estas tcnicas que
hoje s so utilizadas, em geral, em estgios mais avanados do projeto deveriam ser
usadas em conjunto deste o incio do projeto, sempre mantendo a rastreabilidade entre
estes artefatos. medida que o projeto v evoluindo cada um dos artefatos tambm
vai. Com isso, poderia ser obtido um nvel de detalhe de custo maior desde o incio do
projeto.
30

Como ponto positivo, a construo da EAP pode dar uma viso melhor principalmente
de relacionamentos e agrupamentos entre os requisitos. Tambm definir os casos de
uso sem um nvel de detalhe ainda maior pode ajudar na elaborao das estimativas
iniciais, pois amplia a viso do engenheiro de software.
Como ponto negativo, podemos citar que numa fase ainda muito inicial os casos de
uso podem tender a ficar muito superficiais e pouco detalhados no agregando muito
valor ou fazendo muita diferena dos prprios requisitos funcionais e de infraestrutura
em si. Outro ponto negativo a falta de exemplos.
O artigo cumpre um papel importante no projeto de pesquisa, pois chama a ateno
sobre a possibilidade de elaborarmos estimativas ainda em fases iniciais do projeto. O
que teria que ser feito algum tipo de relao entre requisitos, casos de uso e EAP e
artefatos produzidos em projetos de modelagem de processos.
31
3 Concluses
Apesar da existncia de artigos sobre mtricas de qualidade para modelos de processos
de negcio, no foi encontrada nenhuma publicao que abordasse ou fizesse
referncia a algum mtodo ou tcnica para realizar estimavas em projetos de
modelagem de processos. Alguns autores [Gruhn, V. and Laue, R.,2006] ressaltam a
similaridade entre projetos de desenvolvimento de software e projetos de modelagem
de processos de negcio e, baseados nesta similaridade, prope uma customizao das
mtricas de software para rea de modelagem de processos de negcio.
Esta constatao vem confirmar a expectativa do grupo, comprovando que a deciso
de incluir na busca tcnicas de estimao em projetos de software foi acertada.
32
4 Requisitos para a proposta de como estimar projetos de

modelagem de processos
Conforme demonstrado na concluso do relatrio e nas anlises dos artigos da reviso
bibliogrfica, os seguintes requisitos so relevantes para uma proposta de como
elaborar estimativas em projetos de modelagem de processos:
4.1
Recuperar informaes de projetos similares e suas estimativas, nas bases

histricas.
Para viabilizar esta recuperao necessrio classificar os projetos de acordo com um

conjunto de caractersticas que permita isolar uma classe com caractersticas e objetivos
similares ao projeto que ser desenvolvido. Existe um grande nmero de fatores de
projeto que afetam o seu desenvolvimento, entre elas:
Fatores relacionados pessoal, tais como: experincia dos usurios, experincia

da equipe de desenvolvimento na ferramenta, metodologia e diretrizes de
modelagem de processos, bem como no domnio do negcio;
Fatores relacionados ao problema, tais como: complexidade e frequncia de

alterao de requisitos;
Fatores relacionados ao produto, tais como: tamanho e complexidade do modelo,

quantidade de processos e/ou atividades envolvidas, nvel de detalhamento das
atividades;
Fatores relacionados a recursos, tais como: disponibilidade de pessoas e

facilidade de acesso aos usurios;
Fatores relacionados ao desenvolvimento, tais como: objetivo do modelo

(mapeamento do processo as-ise/ou to-be, derivao de requisitos,
simulao etc.), a possibilidade de entregar o produto em partes, o paradigma
adotado e o nvel de riscos tcnicos.
4.2
Possibilidade de elaborao de estimativas ainda em fases iniciais do

projeto
33
5 Glossrio
3D Function Points: Mtrica para sistemas com processamento em tempo real e
cientficos.
Artificial Neural Network (ANN): Redes neurais artificiais representam um conceito
da computao que visa trabalhar no processamento de dados de maneira semelhante
ao crebro humano.
Case-Based Reasoning (CBR): Raciocnio Baseado em Casos uma tecnologia
emergente em representao e processamento de conhecimento que utiliza a
experincia passada para resolver problemas.
Common Software Measurement International Consortium (COSMIC): Consrcio
formado por vrios pesquisadores com objetivo de prover uma nova abordagem para
medio e estimativa de software independente do tipo, prioritariamente software
para apoio a negcios e tempo real (Full Function Points).
Control-flow Complexity (CFC): Mtrica para analise da complexidade do fluxo de
processos.
COSMIC-FFP Size Unit (CFSU): Unidade de tamanho para COSMIC-FFP.
COSMIC-FFP: Mtodo proposto em 2000, na prtica foi um refinamento do mtodo
FFP. Ainda no uma tcnica to disseminada no mundo quanto do IFPUG, porm
observa-se que muita pesquisa est sendo realizada sobre este mtodo.
Cost Constructive Model (COCOMO): mtodo que busca estimar esforo, prazo,
custo e tamanho de equipe, necessrios ao desenvolvimento do software, desde que se
tenha como premissa a sua dimenso.
Diagrama de Fluxo de Dados (DFD): representa o fluxo de dados num sistema de
informao, assim como as sucessivas transformaes que estes sofrem. O DFD uma
ferramenta grfica que transcreve, de forma no tcnica, a lgica do procedimento do
sistema em estudo, sendo usada por diferentes mtodos e principalmente pelos
classificados como orientados a processos.
Estimeeting: termo definido pelos autores para denominar uma reunio estruturada
onde tcnicos com grande experincia se renem para estimar o esforo necessrio
para implementar e testar uma funcionalidade em um projeto de software. Estas
decises so tomadas com base em um documento funcional e um documento tcnico,
gerados para cada funcionalidade por uma equipe destacada para demonstrar a
importncia e viabilidade desta funcionalidade.
Estrutura Analtica do Projeto (EAP): Uma decomposio hierrquica orientada
entrega do trabalho a ser executado pela equipe do projeto para atingir os objetivos do
projeto e criar as entregas necessrias. Ela organiza e define o escopo total do projeto.
(PMBOK)
Feature Points: Mtrica para sistemas com alta complexidade algortmica.
Function Points (FP): Mtodo de anlise de pontos por funo.
34
Functional Size Measure (FSM): Medida do tamanho funcional.

Grafical User Interface (GUI): Interface grfica com o usrio que permite a interao
homem-computador.
Handle: O nmero de handles um termo das redes de Petri utilizado para medir a
quantidade de pares de ns mal estruturados. Esta mtrica aplicada em modelos de
workflow mede o nmero de construes split/join mal-estruturadas.
International Function Point Users Group (IFPUG): uma organizao sem fins
lucrativos, cuja misso promover e incentivar a gesto eficaz das atividades de
desenvolvimento e manuteno de software atravs da utilizao da Analise de Pontos
por Funo Anlise e outras tcnicas de medio de software.
Inferncia Bayesiana: um tipo de inferncia estatstica que descreve as incertezas
sobre quantidades invisveis de forma probabilstica. Incertezas so modificadas
periodicamente aps observaes de novos dados ou resultados. A operao que
calibra a medida das incertezas conhecida como operao bayesiana e baseada na
frmula de Bayes. A frmula de Bayes muitas vezes denominada Teorema de Bayes.
Lines of Code (LOC): Nmero de linhas de cdigo.
Mark II FP: Variao mais antiga do mtodo de pontos de funo padro do IFPUG,
foi apresentada em Londres por Charles Symons em 1983. Atualmente um mtodo de
domnio pblico mantido pela associao de mtricas do Reino Unido - UKSMA.
NESMA FSM: Mtodo para medida do tamanho funcional que utiliza a mesma
filosofia, conceitos, termos e regras do IFPUG, com algumas diretrizes diferentes.
Netherlands Software Metrics Association (NESMA): Associao de mtricas da
Holanda mantm seu prprio manual de contagem, cuja primeira verso em 1990 foi
baseada no manual do IFPUG.
Ordinal Regression Model: Modelo de regresso ordinal. uma abordagem
probabilstica para realizao de estimativas.
Workflow pattern / anti-pattern: Coleo de padres de workflow, referentes a
problemas recorrentes e solues demonstradas, que fornecem um exame completo
das vrias perspectivas (fluxo de controle, dados, recursos e manipulao de excees)
que precisam ser suportadas por linguagens de workflow ou de modelagem de
processos de negcio.
35
Referncias Bibliogrficas
BIELAK J. Improving size estimates using historical data In: IEEE Software, Vol.17,
Issue 6, p. 27-35, Nov/Dec 2000.
BIOLCHINI, J.; MIAN, P. G.; NATALI, A. C. C.; TRAVASSOS, G. H. Systematic
Review in Software Engineering. In: Technical report RT-ES 679/05. PESC COPPE/UFRJ, 2005
BOWDEN P., HARGREAVES M., LANGENSIEPEN C.S. Estimation support by
lexical analysis of requirements documents In: The Journal of Systems and Software
51, Elsevier, p. 8798, 2000.
CARDOSO J. , VANDERFEESTEN I., REIJERS H.A. A weighted coupling metric for
business process models In: Proceedings of CAiSE, 2007
GENCEL C., DEMIRORS O. Functional size measurement revisited In: ACM
Transactions on Software Engineering and Methodology, Vol. 17, No. 3, Article 15, Jun.
2008.
GRUHN, V. AND LAUE R. Complexity Metrics for Business Process Models In: 9th
International Conference on Business Information Systems, Klagenfurt, Austria, 2006
GRUPE F.H., URWILER R., RAMARAPU N.K., OWRANG M. The application of
case-based reasoning to the software development process In: Information and
Software Technology 40, Elsevier, p. 493499, May 1998
HUGHES R.T. Expert judgement as an estimating method In: Information and
Software Technology 38, Elsevier, p.67-75, 1996
KITCHENHAM, B. A. "Procedures for Performing Systematic Reviews", Software
Engineering Group - Keele University - United Kingdom and Empirical Software
Engineering, National ICT Australia Ltd., 2004
LOKAN, C.J. Function Points In: Advances in Computers, Vol. 65, Chapter 7,
Academic Press, p. 298-349.
MOHAGHEGHI P., ANDA B., CONRADI R. Effort estimation of use cases for
incremental large-scale software development In: 27th International Conference on
Software Engineering, St Louis, MO, p.303-311, May 2005.
MOSES, J.
CLIFFORD, J. Learning how to improve effort estimation in small
software development companies In: Computer Software and Applications
Conference (COMPSAC), The 24th Annual International, Taipei, Taiwan, p. 522-527,
Oct. 2000
PILLAI K., SUKUMARAN NAIR V.S. A model for software development effort and
cost estimation In: IEEE Transactions on Software Engineering, vol. 23, n.8, Aug. 1997
SHEPPERD M.,
SCHOFIELD C.,
KITCHENHAM B. Effort estimation using
analogy In: Proceedings of the 18th International Conference on Software
Engineering, Berlin, Germany, p. 170-178, Mar. 1996
36
TAFF L.M., BORCHERING J.W., AND JR., HUDGINS W.R. "Estimeetings:

Development Estimates and a Front-End Process For a Large Project" In: IEEE
Transactions on Software Engineering, vol. 17, no. 8, august 1991
TRONTO I., SILVA J., SANT'ANNA N., "Comparison of Artificial Neural Network and
Regression Models in Software Effort Estimation" In: Proceedings of International Joint
Conference on Neural Networks, Orlando, Florida, USA, August 12-17, 2007
VINSEN, K., JAMIESON, D. & CALLENDER, G. "Use case estimation - the devil is in
the detail" In: IEEE Joint International Requirements Engineering Conference RE'04,
IEEE Computer Society, Kyoto, Japan, 2004.
VOGELEZANG F.W., Early estimating using COSMIC-FFP In: Proceedings of the
2nd Software Metrics European Forum (SMEF), Roma, 2005
37
Anexo A Planejamento e execuo da reviso sistemtica

A.1 Introduo
O objetivo deste documento apresentar o planejamento da reviso sistemtica que
ser realizada no contexto do projeto de Governana.
Motivao: Necessidade de validar os prazos estabelecidos em propostas de

fornecedores para projetos em modelagem de processos de negcio. As propostas so
elaboradas aps reunies de levantamento com o cliente para definio do tipo e
quantidade de processos que fazem parte do escopo do projeto.
Fora do escopo de estudo: a) Levantamento de dados para clculo de produtividade

da equipe de modelagem. Estes dados sero extrados do histrico de projetos de
modelagem desenvolvidos pela UNIRIO/NP2Tec dentro da rea de Explorao e
Produo da Petrobras; b) Estimativas de custo.
Este trabalho faz parte das iniciativas de pesquisa do Termo de Cooperao para
modelagem de processos entre a NP2Tec/UNIRIO e a Petrobras/TIC-E&P/GDIEP.
38
A.2 Planejamento da reviso

A.2.1 Objetivo
Procurar trabalhos sobre estimativas de esforo para a realizao de projetos de
modelagem de processos de negcio e desenvolvimento de software que possam ser
aplicados aos projetos de modelagem de processos de negcio na Petrobras. No caso
de desenvolvimento de software, o interesse da pesquisa est voltado para estimativas
baseadas em requisitos de negcio obtidos nas fases iniciais de projetos de sistemas de
informao.
A.2.2 Formulao da Pergunta (Question Formularization)
A.2.2.1 Pergunta (Question Focus)

Como estimar o tamanho, estimar ou derivar o esforo e prazo de projetos de
modelagem de processos de negcio?
A.2.2.2 Abrangncia e qualidade da pesquisa (Question Quality and

Amplitude)
Problema/Questo (Problem/Question)
Pesquisar e elaborar um mtodo especfico de estimativas para projetos de
modelagem de processos de negcio.
Palavras chave e sinnimos (Keywords and synonyms)

Portugus: Estimar, estimativa, estimao, medir, medio, mtrica, tamanho,
esforo, prazo, tempo, modelo, modelagem de processo, BPM, business process
management, processo de negcio, desenho de processo, pontos por funo,
pontos por caso de uso.
Ingls: Estimate, estimation, calculate, calculation, measure, measurement,
metric, size, sizing, effort, deadline, term, time, model, business modeling
(modelling), BPM, process management, business process, process design,
function points, use case points.
Interveno (Intervention)
Metodologias de estimativas orientadas modelagem de processos e fases de
desenho e anlise de solues.
Controle
Volker Gruhn and Ralf Laue: Complexity Metrics for Business Process Models.
Chair of Applied Telematics / e-Business, Computer Science Faculty, University
of Leipzig, Germany.
39
Resultados esperados (Effect)

Lista de metodologias para estimativas de projetos de modelagem de processos
Lista de metodologias para estimativa de projetos de desenvolvimento de
sistemas com nfase na fase de desenho.
Lista de ferramentas para realizao de estimativas de projetos.
Comparao (Outcome measure)

No se aplica.
Populao (Population)
Trabalhos publicados em conferncias e peridicos relatando estudos e propostas
de metodologias para estimativa de projetos de modelagem de processos e
desenvolvimento de software e/ou exemplos de suas aplicaes e ferramentas
que implementam as propostas.
Forma de conduo da experimentao

No se aplica.
A.2.3 Seleo de fontes (Sources Selection)
A.2.3.1 Definio de critrios para seleo de fontes (Sources Selection

Criteria Definition)
Disponibilidade das referncias, no necessariamente em sua ntegra, na Internet

ou em formato impresso.
Utilizao de portais considerados relevantes para os pesquisadores da rea

estudada.
Existncia de mecanismos de pesquisa para levantamento de referncias

Desejvel: Possuir mecanismo de busca que permita o uso de expresses
lgicas;
Os mecanismos de busca devero permitir a busca no resumo (abstract) e/ou
texto completo da publicao.
A.2.3.2 Idiomas (Studies Languages)

Portugus e ingls.
40
A.2.3.3 Fontes de estudo (Sources Identification)
A.2.3.3.1 Mtodo de busca (Sources search methods)

Via Web, atravs de expresses de busca pr-estabelecidas.
As publicaes oriundas de fontes que no possuam mecanismos de busca sero
analisadas manualmente, quando disponveis, considerando as expresses de busca
definidas.
As publicaes no-digitais sero analisadas manualmente considerando as expresses
de busca pr-estabelecidas.
A.2.3.3.2 Expresso de busca (Search string)

Para publicaes em portugus deve-se utilizar a expresso abaixo:
(tcnica OR mtodo OR metodologia OR mecanismo OR modelo)

AND
(estimar OR estimativa OR estimativas OR estimao OR medir OR medio OR
medies OR mtrica OR mtricas)
AND
(tamanho OR esforo OR prazo OR tempo OR pontos por funo OR pontos por
caso de uso)
AND
(modelagem de processo OR modelagem de processos OR BPM OR processo
de negcio OR processos de negcio OR desenho de processo OR desenho de
processos OR modelagem de negcio)
Para publicaes em ingls deve-se utilizar a expresso abaixo:
(technic OR technique OR method OR methodology OR mechanism OR model OR

models)
AND
(estimate OR estimation OR measure OR measurement OR metric OR metrics)
AND
(size OR sizing OR effort OR deadline OR term OR time OR function point OR use
case point OR UCP OR AFP OR NAFP)
41
AND
(process modeling OR BPM OR business process OR process design OR
business modeling)
A.2.3.3.3 Relao inicial das fontes de estudo (Source list)
Fonte
Compendex http://www.engeneeringvillage.com/
Citeseer - http://citeseer.ist.psu.edu/
Editora Springer - http://www.springer.com/
Google Scholar
Portal da Association for Computing Machinery - http://portal.acm.org/dl.cfm
Portal da IEEE - http://www.ieee.org/portal/site
Scopus http://www.scopus.com/
A.2.3.4 Seleo de fontes aps validao (Sources Selection after

Evaluation)
princpio, todas as referncias com texto completo obtidas sero analisadas pela
equipe.
A.2.3.5 Checagem de referncias (References Checking)

No se aplica
A.2.4 Seleo de estudos (Studies Selection)
A.2.4.1 Definio dos tipos de estudos (Studies types definition)

No se aplica
42
A.2.4.2 Procedimentos para seleo de estudos (Procedures for studies

selection)
O analista aplicar a estratgia de busca para a identificao de potenciais publicaes.
As publicaes identificadas sero selecionadas (1 filtro) atravs da leitura das sees
de abstract e concluso e verificao dos critrios de incluso e excluso estabelecidos.
Posteriormente a lista de publicaes excludas ser avaliada pelo grupo. Em caso
de conflito, a publicao ser includa. Aps a identificao das publicaes, atravs do
critrio dos mecanismos de busca, os documentos selecionados sero lidos e resumidos
(2 filtro) para extrao de informaes sobre metodologias para estimativas de
projetos de modelagem de processos de negcio. Nesta etapa, algumas publicaes
podem ser excludas considerados os critrios estabelecidos. Para esta etapa, vale a
mesma regra anterior, ou seja, caso haja impasse entre os pesquisadores, a publicao
deve ser mantida na lista.
A.2.4.3 Critrios de incluso e excluso (Studies inclusion and exclusion

criteria definition)
Critrios de excluso:
CE1: No sero selecionadas as publicaes sem referncia a um mtodo para

estimar tamanho, esforo e/ou prazo de projetos de modelagem de processos ou
desenvolvimento de software.
CE2: No sero selecionadas as publicaes cuja abordagem das estimativas no

mencione projetos de modelagem de processos de negcio ou desenvolvimento
de software.
CE3: No sero selecionadas as publicaes em que a palavra BPM no significar

Business Process Management.
Critrios de incluso:
CI1: Podem ser selecionadas publicaes que apresentem um mtodo para

estimativa ou medio de tamanho, esforo e prazo, qualquer que seja a fase do
projeto de modelagem de processos.
CI2: Podem ser selecionadas publicaes que descrevam prottipos de mtodos

ou ferramentas relacionados estimativa de projetos.
CI3: Devem ser consideradas as referncias bibliogrficas que apaream nas

referncias das publicaes e sejam consideradas relevantes apesar de no terem
sido identificadas pelas palavras chave do estudo.
43
A.3 Execuo da reviso

A.3.1 Lista de Publicaes de Controle
Na fase de planejamento, o artigo abaixo [Gruhn, V. and Laue R.] foi citado como
controle, mas na verdade era uma referncia a ser utilizada no projeto independente
dela aparecer ou no na reviso. A inteno no era utiliz-lo apenas para refinamento
da expresso de busca. No momento em que os testes preliminares foram iniciados, a
segunda publicao foi incorporada ao grupo de controle:
i.
GRUHN, V. AND LAUE R. Complexity Metrics for Business Process Models

In: 9th International Conference on Business Information Systems, Klagenfurt,
Austria, 2006
ii.
VOGELEZANG, F.W., "Early estimating using COSMIC-FFP", In: Proceedings

of the 2nd Software Metrics European Forum (SMEF 2005), Roma, Mar. 2005
A.3.2 Histrico das Buscas

Os primeiros testes das mquinas de busca foram realizados com a expresso
planejada (item A2.3.3.2). Em relao s fontes de estudo foram verificados os
seguintes problemas:
Compendex: No foi possvel acessar o sistema, uma vez que era necessrio
informar conta de usurio e senha.
Google Scholar e CiteSeer: No foi possvel executar a pesquisa, provavelmente

devido a restries em relao ao tamanho da expresso de busca.
Portal da ACM: No obteve resultados. Como conhecida por ter problemas no

seu mecanismo de busca, esta base foi descartada.
Optou-se ento pela Scopus, que apresentou boas condies para realizao das
buscas, oferecendo a facilidade de exportao dos resultados da pesquisa para uma
planilha no formato CSV e retornando artigos de outras bases inclusive da IEEE e
Springer.
Com a expresso planejada (item A2.3.3.2), a base da Scopus retornou 181
resultados, com vrios artigos fora do escopo da pesquisa. A partir da foram
realizadas diversas rodadas com variaes da expresso de busca obtendo-se os
seguintes resultados:
TITLE-ABS-KEY((technic OR technique OR method OR
methodology OR
mechanism OR model OR models OR metric OR metrics) AND ({estimate size} OR
{size estimation} OR {estimate effort} OR {effort estimation} OR {function point} OR
44
{use case point} OR UCP OR AFP OR NAFP) AND ({process modeling} OR BPM OR
{business process} OR {process design} OR {business modeling} OR {information
system} OR {information systems})) AND SUBJAREA(comp)
Resultado: 26 artigos.
TITLE-ABS-KEY((technic OR technique OR method OR
methodology OR
mechanism OR model OR models OR metric OR metrics) AND ({estimate size} OR
{size estimation} OR {estimate effort} OR {effort estimation} OR {function point} OR
{function points} OR {use case point} OR {use case points} OR UCP OR AFP OR NAFP)
AND ({process modeling} OR BPM OR {business process} OR {process design} OR
{business modeling} OR {information system} OR {information systems})) AND
SUBJAREA(comp)
TITLE-ABS-KEY(early AND estimation AND size AND (requirement OR

requirements)) AND SUBJAREA(comp)
TITLE-ABS-KEY((earl* OR initial) AND estimat* AND (size OR cost OR effort)

AND (project OR requirement OR business OR process)) AND SUBJAREA(comp)
Expresso de busca final

TITLE-ABS-KEY((requirement OR functionality) AND estimat* AND (size OR
effort) AND (project OR business OR process)) AND SUBJAREA(comp)
O executor da pesquisa analisou individualmente os campos de titulo e abstract
dos 249 artigos, considerando os critrios de incluso e excluso, at chegar a um
resultado de 79 artigos. Em seguida, os abstracts destes 79 artigos foram lidos por 3
dos integrantes do grupo. Cada integrante fez sua avaliao individual indicando se
deveria ser lido integralmente o artigo ou no. Numa reunio da equipe estas
avaliaes foram discutidas e os conflitos existentes foram resolvidos atravs de
consenso e votao, tendo como resultado os 28 artigos listados a seguir:
How to use COSMIC functional size in
effort estimation models?
Gencel C.
2008
Improving quality of functional

requirements by measuring their functional
size
Trudel S., Abran A.
2008
45
Project sizing and estimating: A case study

using PSU, IFPUG and COSMIC
Buglione L., CuadradoGallego J.J., De Mesa J.A.G.
2008
Uncertainty in ERP effort estimation: A

challenge or an asset?
Daneva M., Wettflower S.,

De Boer S.
2008
A metamodeling approach to estimate

software size from requirements
specifications
Abrahao S., Insfran E.
2008
Impact of base functional component types

on software functional size based effort
estimation
Buglione L., Gencel C.
2008
Integrating portfolio management and

simulation concepts in the ERP project
estimation practice
Daneva M.
2008
Functional size measurement revisited
Gencel C., Demirors O.
2008
Comparison of artificial neural network

and regression models in software effort
estimation
De Barcelos Tronto I.F.,

Simoes Da Silva J.D.,
Sant'Anna N.
2007
A flexible method for software effort

estimation by analogy
Li J., Ruhe G., Al-Emran A.,

Richter M.M.
2007
A functional size measurement method for

object-oriented conceptual schemas: Design
and evaluation issues
Abrahao S., Poels G., Pastor

O.
2006
A requirement-based project estimation

approach
Chang C.-P., Wu C.-S., Chu

C.-P., Lv J.-L.
2005
Effort estimation of use cases for

incremental large-scale software
development
Mohagheghi P., Anda B.,

Conradi R.
2005
Function Points
Lokan C.J.
2005
Use case estimation - The devil is in the

detail
Vinsen K., Jamieson D.,

Callender G.
2004
Fuzzy modeling for function points

analysis
De Souza Lima Jr. O., Farias

P.P.M., Belchior A.D.
2003
Measuring Effort Estimation Uncertainty to

Improve Client Confidence
Moses J.
2002
Learning how to improve effort

estimation in small software development
companies
Moses John
2000
Improving size estimates using historical

data
Bielak J.
2000
Estimation support by lexical analysis of

requirements documents
Bowden P., Hargreaves M.,

Langensiepen C.S.
2000
A Rule-Based Approach to Developing

Software Development Prediction Models
Chatzoglou P.D., Macaulay

L.A.
1998
The application of case-based reasoning

to the software development process
Grupe F.H., Urwiler R.,

Ramarapu N.K., Owrang M.
1998
Estimating software project effort using
Shepperd M., Schofield C.
1997
46
analogies
A model for software development effort
and cost estimation
Pillai K., Sukumaran Nair

V.S.
1997
Expert judgement as an estimating

method
Hughes R.T.
1996
A structured methodology for software

development effort prediction using the
analytic hierarchy process
Lee H.
1993
Estimeetings: Development estimates and

a front-end process for a large project
Taff Louis M., Borchering

James W., Hudgins Jr.
W.Richard
Wrigley C.D., Dexter A.S.
1991
A model for measuring information system

size
1991
Iniciou-se ento o trabalho de recuperao dos artigos para que fossem lidos e
resumidos. Neste momento, foi observado que atravs da rede da UNIRIO, alguns
downloads no traziam o contedo dos artigos, baixando apenas o respectivo
abstract. Sendo assim, no final desta etapa foram obtidos os 14 artigos que aparecem
em destaque na relao acima.
Um dos artigos obtidos (Abrahao S., Insfran E., 2008, A metamodeling approach to
estimate software size from requirements specifications) foi considerado como falso
positivo aps sua leitura, descartando-se a necessidade de elaborao de seu resumo.
Neste momento, o artigo de Irene Vanderfeesten, Jorge Cardoso, Hajo A. Reijers, A
weighted coupling metric for business process models foi includo na relao para
leitura, por indicao de um dos integrantes do grupo. Este artigo no foi encontrado
pelo processo de reviso sistemtica, mas se mostrou de interesse para a pesquisa.
Os 14 artigos resultantes foram ento lidos integralmente e resumidos, permitindo a
identificao dos pontos fortes e fracos de cada um e suas contribuies para o projeto
em questo.
47
Anexo B Relatrio de estatsticas de projetos de modelagem

de processos
B.1 Introduo
O objetivo deste documento apresentar o estudo realizado com base nos projetos de
modelagem de processos j realizados pela UNIRIO/NP2Tec em diversos Escritrios
de Processos da TIC/E&P para prover um mecanismo de estimao do esforo mdio
necessrio para a realizao de um projeto desta natureza, de acordo com o tipo de
projeto e o nmero de processos modelados. Trata-se de um estudo inicial, realizado
com restries de tempo para levantamento dos dados, organizao dos mesmos e
realizao de anlises alternativas, visando apresentar resultados iniciais que possam
apoiar decises de investimento em projetos de modelagem. Esto sendo organizados
estudos mais profundos no sentido de prover uma estimativa mais confivel, ainda
que dependente de dados mais especficos sobre o projeto em anlise.
48
B.2 Estudo realizado

B.2.1 Conduo do estudo prvio
Durante o estudo foram levantadas informaes sobre os projetos de modelagem de
processos realizados pela UNIRIO/NP2TEc dentro do E&P. Estas informaes
incluram, para cada projeto, o tempo total gasto no projeto (em dias teis de trabalho),
o nmero de processos modelados e o nmero de participantes, bem como seus perfis.
Para realizar este estudo inicialmente coletamos os dados supracitados dos projetos
que foram realizados junto ao E&P. Selecionamos 40 (quarenta) projetos de
modelagem de processos, dentre os quais dois foram excludos por conta dos dados
existentes estarem muito fora da curva padro o processo de coleta. Os dados dos 38
(trinta e oito) projetos restantes foram tabulados, calculando-se o esforo ponderado
exigido por cada projeto, de acordo com o nmero de participantes envolvidos.
Em seguida, os projetos selecionados foram classificados em trs categorias, de
acordo com informaes fornecidas por pessoas do NP2Tec que participaram dos
projetos. Os tipos de projetos definidos foram: ADM (processos administrativos), TGE
(processos tcnicos com foco em gesto) e TOP (processos tcnicos operacionais).
Analisando-se graficamente os dados destes projetos, eliminamos mais um projeto, que
se tratava de um caso extremo (outlier) em relao a seus pares.
Depois, os projetos de cada grupo foram classificados como pequenos, mdios ou
grandes, utilizando-se um critrio que visava reduzir o desvio padro intra-grupo.
Devido ao nmero relativamente reduzido de projetos (em relao aos nove subgrupos
pretendidos) e concentrao destes projetos em determinados tamanhos, optamos
por uma diviso de cada grupo em dois subgrupos: pequeno/mdio e grande.
Finalmente, calculamos a mdia e o desvio padro de cada grupo, estabelecendo
intervalos de confiana para os subgrupos. Em casos onde tivemos subgrupos com
apenas um projeto, sendo impossvel calcular o desvio padro, fizemos uma estimativa
baseada em experincia e no desvio padro de outros subgrupos.
Foram realizadas anlises rpidas levando em considerao outros aspectos dos
projetos. No entanto, estas anlises apontaram falta de correlao entre os fatores
escolhidos, de modo que nada se pode concluir a respeito at o presente momento.
Novas anlises esto sendo planejadas, junto a uma reviso sistemtica de mecanismos
de estimativa similares ao que propomos, no sentido de refinar as estimativas em um
horizonte de mdio prazo.
49
B.3 Proposta de estimativa

Baseado nos estudos realizados foram consideradas para a proposta inicial de
estimativas as informaes que certamente so levantados durante o levantamento
inicial do projeto: Domnio e processos (em nmeros) a serem modelados. Qualquer
outra informao adicional pode no estar disponvel e varia bastante dependendo de
cada projeto e por este motivo, alm dos j citados na seo anterior, no foram
consideradas neste estudo.
Tipos de processos:
TOP Tcnico
operacional
Processos do E&P caractersticos de prticas

operacionais de explorao e produo onde h
necessidade de descrio e modelagem detalhada dos
procedimentos de execuo das atividades.
TGE Tcnico de
gesto
Processos de acompanhamento, anlise e gesto das

operaes de explorao e produo onde a descrio e
modelagem dos procedimentos de execuo das
atividades so detalhadas em um nvel mais alto, pelas
caractersticas destes tipos de processos onde ocorrem
anlises e negociaes.
ADM - Administrativo
Processos executados por reas administrativas e de

apoio explorao e produo onde a descrio e
modelagem dos procedimentos de execuo das
atividades possuem detalhamento que varia de acordo
com a necessidade do Gestor de processos.
Caractersticas dos projetos:

A classificao de um projeto leva em considerao os tipos e a quantidade de
processos modelados.
Os projetos podem ser classificados em:
PP Pequeno/Mdio Projeto
GP Grande Projeto
Classificao proposta:
50
N Processos
Tipo do processo
Classificao
At 5
Tcnico operacional
PP
6 em diante
Tcnico operacional
GP
At 6
Administrativo
PP
7 em diante
Administrativo
GP
At 4
Tcnico de gesto
PP
5 em diante
Tcnico de gesto
GP
Esforo mdio de realizao dos projetos:
Classificao
Tipo de
processo
Nmero de
Processos
Analisados
Mdia do
esforo total
(em
homens/dia)
Desvio
padro (em
homens/dia)
PP
TGE
14
56
31
PP
ADM
13
84
20
PP
TOP
160
60
GP
TGE
100
40
GP
ADM
162
30
GP
TOP
230
80
A mdia do esforo leva em considerao a atuao de 1 analista/hora (8hrs/dia)

dedicado a esta atividade.
Para todos os projetos levou-se em considerao a participao (no contabilizados
na tabela acima) de:
- 1 lder de projetos em tempo parcial (4hrs/dia) 0,5 lder de projeto
- 1 gerente de projetos dedicado em tempo parcial (3,2hrs/dia) 0,4 gerente
Perfis:
Analista
modelador
Responsvel pelo levantamento e modelagem de processos de

negcio. Este trabalho inclui promover a discusso e servir como
facilitador da mesma junto aos stakeholders coletando as
informaes necessrias e representando em modelos de processo
de acordo com padres internos de modelagem.
51
Deve possuir as seguintes habilidades:

- Capacidade de pensamento estruturado/algortmico;
- Capacidade de abstrao e classificao em grupos;
- Facilidade de comunicao;
- Bons conhecimentos do pacote Microsoft Office;
- Bons conhecimentos na ferramenta de modelagem de processos a
ser utilizada no projeto;
- Boa capacidade de redao;
- Boa capacidade de relao interpessoal e negociao;
As formaes preferenciais incluem: engenharia de produo e
reas correlatas a TI ou administrao.
Lder de projeto
Responsvel por coordenar o levantamento e modelagem de

processos com relao a estratgia de conduo das entrevistas
junto aos stakeholders e a estratgia de modelagem de processos
escolhida, garantir a aderncia dos modelos de processos aos
padres internos de modelagem, gerenciar o plano de projeto
controlando o cronograma do projeto.
- Bons conhecimentos do pacote Microsoft Office;
- Conhecimento na ferramenta de modelagem de processos a ser
utilizada no projeto;
- Conhecimentos em gesto de projetos;
- Aptido para gesto de pessoas e conflitos;
Gerente
Responsvel por gerenciar o projeto junto ao contratante com

relao gesto de tempo, esforo, custo e escopo do projeto de
modelagem, bem como gerir a expectativas dos gestores do
projeto e servir como ponte de comunicao do gerente
contratante com a equipe de modelagem de processos.
- Conhecimento de ferramentas de modelagem de processos;
52
- Conhecimentos em gesto de projetos;
- Aptido para gesto de pessoas e conflitos;
A incorporao de mais analistas modeladores na equipe de modelagem de

processos pode reduzir o esforo mdio total do projeto da seguinte forma:
Incluso de analista
modelador
Total de analistas
modeladores
Porcentagem mdia de
diminuio do esforo
mdio
80% do esforo mdio

total
75% do esforo mdio

total
3 em diante
4 em diante
70% do esforo mdio

total
Essa relao explicada pela:

- Grande integrao existente entre os processos modelados o que requer um tempo
de dedicao dos analistas em realizar anlises em conjunto;
- A baixa disponibilidade dos stakeholders (participantes e interessados nos
processos) para realizar reunies de levantamento de processos;
- A necessidade de aumentar o esforo do Lder de projeto e do Gerente em funo
do aumento na demanda por mentoring e auditoria interna de processos bem como do
aumento da prpria gesto do mesmo.
No entanto esse porcentual mdio de diminuio do esforo tende a diminuir em
maior grau considerando o paralelismo de modelagens que requerem entrevistas com
stakeholders distintos.
53

Estimativas

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Estimativas

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO

CENTRO DE CINCIAS EXATAS E TECNOLOGIA

Departamento de Informtica Aplicada

Relatrios Tcnicos do DIA/UNIRIO, No. 0025/2009

PESQUISA EM ESTIMATIVAS EM PROJETOS DE

Ncleo de Pesquisa e Prtica em Tecnologia (NP2Tec)

claudia.cappelli@uniriotec.br, flavia.santoro@uniriotec.br, jrcdutra@gmail.com,

Trabalho patrocinado pela Petrobras.

2.10.3 Contribuies para o projeto

Requisitos para a proposta de como estimar projetos de modelagem de processos

Anexo A Planejamento e execuo da reviso sistemtica

A.3.1 Lista de Publicaes de Controle

B.2.1 Conduo do estudo prvio

1.3. Detalhamento do Problema

Apesar da existncia de diversas tcnicas para estimar projetos de desenvolvimento

1.4. Mtodo de pesquisa

1.5. Estrutura do Relatrio

2 Principais abordagens relacionadas

A model for Software Development Effort and Cost Estimation

Boehms [1] classifica modelos algortmicos usados para estimativa de esforo da

RelaTe-DIA: Levantamento de Informaes para Modelagem de Processos

Pontos positivos e pontos negativos

Contribuies para o projeto

A Weighted Coupling Metric for Business Process Models

Em um artigo de apenas quatro pginas, os autores ressaltam a similaridade entre

Pontos positivos e pontos negativos

Contribuies para o projeto

RelaTe-DIA: Levantamento de Informaes para Modelagem de Processos

Comparison of Artificial Neural Network and Regression Models in

Os autores comentam sobre a importncia de gesto de projetos de desenvolvimento

Destacam ainda que as organizaes normalmente querem escolher modelos de

RelaTe-DIA: Levantamento de Informaes para Modelagem de Processos

Eles utilizaram o software STATISTICA para encontrar o melhor modelo dentre os

Pontos positivos e pontos negativos

Pontos positivos: Segundo os autores, tcnicas baseadas em ANN tm sido aplicadas

RelaTe-DIA: Levantamento de Informaes para Modelagem de Processos

apontam a questo da dependncia entre parmetros e variveis quaisquer do projeto

Contribuies para o projeto

Os autores apostam em tcnicas onde j se possui o valor da varivel tamanho do

Early estimating using COSMIC-FFP

Fuzzy logic uma forma de sistematizar as comparaes com os ltimos

Standard-component sizing identifica uma srie de componentes-chaves que

Proxy-based Estimating atribui um intervalo de tamanho para cada mtodo

Wideband-Delphi, onde um nmero de especialistas estima o tamanho de um

FPA i, nesta abordagem um nmero de estimadores estabelece o peso de uma

RelaTe-DIA: Levantamento de Informaes para Modelagem de Processos

Dependendo do tipo de software que tem de ser produzido e do ambiente de

A primeira simplificao usada quando os elementos so conhecidos mas no

Outra simplificao o fato de que geralmente h uma relao linear entre o

Se apenas um modelo conceitual de dados conhecido, uma aproximao

As estimativas por pontos por funo so independentes do ambiente de

RelaTe-DIA: Levantamento de Informaes para Modelagem de Processos

mdios dos processos funcionais de um software local com caractersticas similares

Mtodo 1 (descrito no manual): divide o tamanho total do software por quatro e

Mtodo 2 (usado nos exemplos): divide o numero de processos funcionais por

Levantamento de estimativas iniciais de tamanho em diferentes ambientes

Pontos positivos e pontos negativos

Contribuies para o projeto

Os mtodos baseados em COSMIC-FFP podem servir de base para definio de um

RelaTe-DIA: Levantamento de Informaes para Modelagem de Processos

Complexity Metrics for Business Process Models

Diversas pesquisas neste sentido tm sido realizadas sobre complexidade de software

RelaTe-DIA: Levantamento de Informaes para Modelagem de Processos

Pontos positivos e pontos negativos