UNIVERSIDADE

CATÓLICA DE
BRASÍLIA
PROGRAMA DE PÓS-GRADUAÇÃO EM
GESTÃO DO CONHECIMENTO
E TECNOLOGIA DA INFORMAÇÃO

0HVWUDGR

3RQWRVGH&DVRVGH8VRH3RQWRVGH)XQomRQDJHVWmR
GHHVWLPDWLYDGHWDPDQKRGHSURMHWRVGHVRIWZDUH
RULHQWDGRVDREMHWRV

Autora: Edméia Leonor Pereira de Andrade

Orientadora: Profa. Dra. Káthia Marçal de Oliveira

BRASÍLIA 2004 

('0e,$/(21253(5(,5$'($1'5$'(




321726'(&$626'(862(321726'()81d­21$*(67­2'(
(67,0$7,9$'(7$0$1+2'(352-(726'(62)7:$5(
25,(17$'26$2%-(726


Dissertação submetida ao Programa de Pós Graduação

6WULFWR 6HQVX em Gestão do Conhecimento e
Tecnologia da Informação da Universidade Católica de
Brasília para obtenção do Grau de Mestre.

Orientadora: Profa. Dra. Káthia Marçal de Oliveira.

Brasília
2004
7(502'($3529$d­2



('0e,$/(21253(5(,5$'($1'5$'(

321726'(&$626'(862(321726'()81d­21$*(67­2'(
(67,0$7,9$'(7$0$1+2'(352-(726'(62)7:$5(
25,(17$'26$2%-(726




Dissertação defendida e aprovada como requisito parcial para obtenção do grau de

Mestre no Programa de Pós-Graduação VWULFWRVHQVX em Gestão do Conhecimento e Tecnologia
da Informação, em 20 de fevereiro de 2004, pela banca examinadora constituída por:

Profa. Dra. Káthia Marçal de Oliveira

Orientadora - UCB

Prof. Dr. Arnaldo Dias Belchior

UNIFOR

Prof. Dr. Nicolas Anquetil

UCB

Brasília
UCB

i
 'HGLFDWyULD 

























Ao meu esposo Ronaldo e queridos filhos Loriza, Priscila e Leandro

pelo apoio, carinho e incentivo em todos os momentos.


ii
 $JUDGHFLPHQWRV

A Deus por me proporcionar à vida, a sabedoria e a coragem para realizar esta pesquisa.
Aos meus pais, irmãos e sogra, pelo apoio e incentivo.
Ao meu esposo Ronaldo pelo apoio, incentivo, carinho, paciência, colaboração nas revisões
e realização das análises estatística.
Aos meus queridos filhos Loriza, Priscila e Leandro pelo incentivo, carinho e compreensão
nos momentos difíceis.
Aos diretores, gerentes e membros de projetos de software das empresas, aos professores e
alunos da UCB que me forneceram as informações fundamentais para a realização desta
pesquisa.
Aos outros participantes da pesquisa que contribuíram com relevantes informações.
A minha orientadora, Dra. Káthia, pelos ensinamentos, orientações e principalmente pela
paciência durante a realização deste trabalho.
Aos outros professores do curso pelos conhecimentos transmitidos.
Aos colegas de curso, especialmente Angélica, Paulo Leão e Fabiano pela troca de
conhecimento, apoio e companheirismo.
Aos meus chefes e colegas da Embrapa pelo apoio e incentivo.
À Embrapa pelo suporte financeiro.
Aos amigos pela amizade, carinho e incentivo.
Aos professores membros da banca examinadora, por prestigiarem este trabalho com sua
presença, críticas e sugestões de melhoria.
E a todos que colaboraram de forma direta ou indireta na realização desta pesquisa.

iii
 5HVXPR

As organizações têm-se preocupado cada vez mais com a qualidade de seus produtos de
software com os custos efetivos e com o cumprimento de cronogramas especificados nos
projetos de desenvolvimento. Estas características do processo de desenvolvimento de software
dependem de um gerenciamento efetivo, baseado em um plano de projeto definido com base em
estimativas mais precisas. A estimativa de tamanho, por exemplo, é uma das métricas mais
utilizadas na gestão de projetos de desenvolvimento de software, porque a partir desta dimensão é
possível definir o esforço, o prazo e os custos necessários para o desenvolvimento do software.
Devido a isso, a estimativa de tamanho deve ser realizada no início do projeto e refinada durante
todo o seu ciclo de desenvolvimento. Em relação ao desenvolvimento Orientado a Objetos (OO),
abordagem bastante utilizada no mercado atual, a estimativa de tamanho é geralmente realizada
através de duas métricas: Análise de Pontos de Função (APF), que já é utilizada em sistemas
tradicionais desde 1979, e Pontos de Casos de Uso (PCU), proposta em 1993. Na primeira, a
precisão da estimativa melhora à medida que se obtém mais informações da análise e do projeto
de sistemas. A segunda foi proposta para ser utilizada no início do ciclo de desenvolvimento, na
fase de requisitos. Considerando-se o fato de que durante todo o processo de desenvolvimento
deve-se gerenciar adequadamente os prazos, recursos e custos; de que essas estimativas
dependem do tamanho do projeto e de que as duas métricas de medição são adequadas em
momentos diferentes do desenvolvimento, esta pesquisa se propõe a utilizar a APF e o PCU de
forma combinada, para apoiar o gerente em relação à gestão de estimativa de tamanho do projeto
de software. Este apoio consiste da definição de um processo de gestão de estimativa de tamanho,
que deverá ser utilizado em paralelo aos processos de desenvolvimento e gestão de projetos de
software. Este processo propõe: i) utilizar o PCU e a APF quando são melhores aplicadas,
tentando explorar a relação existente entre elas; ii) estimar o tamanho do software continuamente
ao longo do processo de desenvolvimento do projeto; e, iii) sugerir ações gerenciais a serem
tomadas pelo gerente durante o planejamento e controle do projeto.



iv
 $EVWUDFW

The software enterprises have a growing concern about product quality and with the
accomplishment of development projects schedule while being cost effective. These software
development characteristics depend on an effective management based on a project plan. The
project plan, in turn, is based on more precise software size estimates. The size estimation is one
of the most used metrics in the management of software development projects because from this
estimation it is possible to define effort, resources and costs needed for software development.
Because of this, the size estimate should be accomplished in the beginning of the project and
refined during the whole cycle of the project development. In relation to the Object Oriented
(OO) development approach, quite used in today’s market, the size estimate is usually obtained
through two counting metrics: Function Points Analysis (FPA), which is already used in
traditional systems since 1979, and Use Cases Points (UCP), proposed in 1993. In the first one,
the precision of the estimate improves as more information from the analysis and system projects
is available. The second one, the UCP, was proposed for use in the beginning of the development
cycle, in the phase of requirement definition. Considering that these two metrics are useful in
different phases of the software development process, this research intends to indicate a
combined use of APF and PCU to support the manager in the size estimate management of the
software project. This support consists in the definition of a size estimate management process
that should be used along the development and management processes of software projects. This
process includes: i) to use UCP and FPA when they are better applied trying to exploit their
relationship; ii) to use size estimates continually throughout the software development project;
and iii) to suggest managerial actions that should be taken by the manager during the project’s
planning and control.

v
 6XPiULR
&$3Ë78/2,1752'8d­2 
1.1. MOTIVAÇÃO E RELEVÂNCIA DO PROBLEMA ........................................................................................................ 1
1.2. OBJETIVOS E SUPOSIÇÕES ................................................................................................................................... 4
2EMHWLYRJHUDO 
2EMHWLYRVHVSHFtILFRV  
6XSRVLo}HV  
1.3. METODOLOGIA ................................................................................................................................................... 5
1.4. ESTRUTURA ........................................................................................................................................................ 6
&$3Ë78/20e75,&$6'((67,0$7,9$'(7$0$1+2'(62)7:$5(  
2.1. INTRODUÇÃO ...................................................................................................................................................... 7
2.2. MEDIÇÃO DE SOFTWARE ..................................................................................................................................... 7
2.3. MÉTRICAS DE ESTIMATIVAS DE TAMANHO DE SOFTWARE ................................................................................. 10
$QiOLVHGH3RQWRVGH)XQomR$3)  
3RQWRVGH&DVRGH8VR3&8  
2XVRGRWDPDQKRGRSURMHWRQDHVWLPDWLYDGHHVIRUoRRXSURGXWLYLGDGH  
2.4. CONSIDERAÇÕES FINAIS DO CAPÍTULO .............................................................................................................. 28
&$3Ë78/2*(67­2'(352-(72'(62)7:$5(  
3.1 INTRODUÇÃO ..................................................................................................................................................... 31
3.2. DEFINIÇÃO ........................................................................................................................................................ 31
3.3. PROCESSOS DE GESTÃO DE PROJETOS ................................................................................................................ 32
3ODQHMDPHQWRGHSURMHWRGHVRIWZDUH  
&RQWUROHGHSURMHWRGHVRIWZDUH  
*HVWmRGHSURMHWRVGHVRIWZDUHGHDFRUGRFRPDVQRUPDVH 
3.4. CONSIDERAÇÕES FINAIS DO CAPÍTULO .............................................................................................................. 49
&$3Ë78/2*(67­2'((67,0$7,9$'(7$0$1+2'(352-(72'(  
62)7:$5(25,(17$'2$2%-(726 
4.1. INTRODUÇÃO .................................................................................................................................................... 50
4.2. OBJETIVO .......................................................................................................................................................... 51
4.3. PADRONIZAÇÃO DOS PROCEDIMENTOS DE CONTAGEM DA APF E PCU PARA PROJETOS OO............................. 52
3URFHGLPHQWRVGHFRQWDJHPGD$3)  
3URFHGLPHQWRVGHFRQWDJHPGH3&8  
4.4. RELAÇÃO ENTRE A APF E PCU ........................................................................................................................ 59
$SOLFDomRGDVPpWULFDVQDDFDGHPLD  
$SOLFDomRGDVPpWULFDVQDLQG~VWULD  
$QiOLVHGRVUHVXOWDGRV 
(TXDomRGHUHODomRHQWUH3)H3&8  
4.5.IDENTIFICAÇÃO DAS AÇÕES GERENCIAIS A SEREM TOMADAS PELOS GERENTES ................................................. 79
4.6. PROCESSO DE GESTÃO DE ESTIMATIVA DE TAMANHO DE PROJETO DE SOFTWARE ............................................. 92
5HODFLRQDPHQWRGRSURFHVVRGHJHVWmRGHHVWLPDWLYDGHWDPDQKRFRPRVSURFHVVRVGHGHVHQYROYLPHQWR
HGHJHVWmRGHSURMHWRVGHVRIWZDUH 
4.7. CONSIDERAÇÕES FINAIS DO CAPÍTULO ............................................................................................................ 102
&$3Ë78/2&21&/86­2(3(563(&7,9$6)8785$6  
5()(5Ç1&,$6%,%/,2*5È),&$6  
$3Ç1',&(6  
APÊNDICE A - CARACTERÍSTICAS GERAIS E AMBIENTAIS QUE INFLUENCIAM NO SISTEMA..................................... 114
APÊNDICE B - GESTÃO DE ESTIMATIVAS EM PROJETOS DE SOFTWARE ................................................................... 121
APÊNDICE C - PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ORIENTADO A OBJETOS ...................................... 125

vi
 /LVWDGH)LJXUDV

FIGURA 1 - ESTRUTURA DA NBR ISO/IEC 12.207 (ABNT, 1998) .............................................................................. 44

FIGURA 2 - RELAÇÃO ENTRE PCU E APF EM PROJETOS DA ACADEMIA E DA INDÚSTRIA.............................................. 78
FIGURA 3 - ÁREA DE ATUAÇÃO DOS RESPONDENTES .................................................................................................... 82
FIGURA 4 - FORMAÇÃO PROFISSIONAL DOS RESPONDENTES ......................................................................................... 82
FIGURA 5 - EXPERIÊNCIA EM GESTÃO DE PROJETOS ..................................................................................................... 83
FIGURA 6 - EXPERIÊNCIA EM GESTÃO DE TEMPO DE EXECUÇÃO DE PROJETOS .............................................................. 83
FIGURA 7 - RELACIONAMENTO DO PROCESSO DE GESTÃO DE ESTIMATIVA DE TAMANHO COM OS PROCESSOS DE
DESENVOLVIMENTO E GESTÃO DE PROJETOS DE SOFTWARE .............................................................................. 100

vii
 /LVWDGH4XDGURV

QUADRO 1 - COMPLEXIDADE FUNCIONAL (IFPUG, 2000) .......................................................................................... 15
QUADRO 2 - COMPLEXIDADE DE ENTRADA EXTERNA (IFPUG, 2000) ......................................................................... 16
QUADRO 3 - COMPLEXIDADE DE SAÍDA EXTERNA (IFPUG, 2000) .............................................................................. 17
QUADRO 4 - COMPLEXIDADE DE CONSULTA EXTERNA (IFPUG, 2000) ....................................................................... 18
QUADRO 5 - CARACTERÍSTICAS GERAIS DO SISTEMA (IFPUG, 2000)........................................................................... 18
QUADRO 6 - PESO DOS ATORES (KARNER, 1993) ......................................................................................................... 22
QUADRO 7 - PESO DOS CASOS DE USO (KARNER, 1993) .............................................................................................. 23
QUADRO 8 - FATORES DE COMPLEXIDADE TÉCNICA (KARNER, 1993) .......................................................................... 24
QUADRO 9 - FATORES DE COMPLEXIDADE AMBIENTAL (FA) (KARNER, 1993) ............................................................ 25
QUADRO 10 - PRINCIPAIS CARACTERÍSTICAS E DIFERENÇAS ENTRE APF E PCU.......................................................... 29
QUADRO 11 - ÁREAS DE CONHECIMENTO DA GESTÃO DE PROJETOS DO PMBOK X ATIVIDADES DO PROCESSO DE
GESTÃO DA NBR ISO/IEC 12.207 (ISO, 1999) .................................................................................................. 46
QUADRO 12 MAPEAMENTO DOS PROCESSOS DE GESTÃO DE PROJETOS DA ISO 10.006 PARA AS ATIVIDADES DE GESTÃO
DE PROCESSOS DA NBR ISO/IEC 12.207(ISO, 1999)........................................................................................ 47
QUADRO 13 - MAPEAMENTO DA NBR ISO/IEC 12.207 PARA A ISO 10006 E PMBOK ............................................. 48
QUADRO 14 - PASSOS DO PROCESSO DE CONTAGEM DE PF........................................................................................... 53
QUADRO 15 - PASSOS DO PROCESSO DE CONTAGEM DE PCU ....................................................................................... 57
QUADRO 16 - OBJETIVO DE ESTUDO ............................................................................................................................ 79
QUADRO 17 - AÇÕES A SEREM TOMADAS QUANDO O CRONOGRAMA É IMPRATICÁVEL ................................................ 85
QUADRO 18 - AÇÕES A SEREM TOMADAS QUANDO O CRONOGRAMA ESTÁ DENTRO DO PRAZO ..................................... 87
QUADRO 19 - AÇÕES MAIS INDICADAS PARA CADA FATO ............................................................................................. 89
QUADRO 20 - AÇÕES A SEREM TOMADAS PELOS GERENTES QUANDO O CRONOGRAMA ESTÁ ATRASADO ..................... 92
QUADRO 21 - ATIVIDADES DO PROCESSO DE GESTÃO DE ESTIMATIVA DE TAMANHO ................................................... 94
QUADRO 22 - ARTEFATOS GERADOS DURANTE O PROCESSO DE DESENVOLVIMENTO DE PROJETO DE SOFTWARE
ORIENTADO A OBJETOS ...................................................................................................................................... 131

viii
 /LVWDGH7DEHODV

TABELA 1 - RESULTADO DA CONTAGEM DE PCU E PF NOS PROJETOS DA ACADEMIA .................................................. 67

TABELA 2 - RESULTADO DA CONTAGEM DE PCU E PF NOS PROJETOS DA INDÚSTRIA .................................................. 68
TABELA 3 - VALORES DOS NÍVEIS DE SIGNIFICÂNCIA (P) OBTIDOS PELO “TESTE T” NAS EQUAÇÕES DE REGRESSÃO
QUADRÁTICA E LINEAR. ...................................................................................................................................... 73
TABELA 4- VALORES DOS NÍVEIS DE SIGNIFICÂNCIA (P) OBTIDOS PELO “TESTE T” NAS EQUAÇÕES DE REGRESSÃO
LINEAR SEM INTERCEPTO. ................................................................................................................................... 74
TABELA 5 - AÇÕES RECOMENDADAS QUANDO O CRONOGRAMA É IMPRATICÁVEL ....................................................... 84
TABELA 6 - AÇÕES A SEREM TOMADAS PARA CONTROLAR OU MANTER O CRONOGRAMA NO PRAZO ............................ 86
TABELA 7 - AÇÕES A SEREM TOMADAS QUANDO O CRONOGRAMA ESTIVER ATRASADO ............................................... 88

ix
 1

&DStWXOR,QWURGXomR


0RWLYDomRHUHOHYkQFLDGRSUREOHPD
A competição entre organizações de desenvolvimento de software vem aumentando com
o crescimento do mercado de Tecnologia da Informação (TI). Conforme notícia disponibilizada
na página do Ministério da Ciência e Tecnologia (MCT), o mercado nacional de software deve
crescer 5,3% em 2004, movimentando US$ 1,76 bilhões (MCT, 2003a).
De acordo com o estudo denominado “A indústria de Software no Brasil”, elaborado pela
Softex em parceria com o 0DVVDFKXVHWWV,QVWLWXWHRI7HFKQRORJ\ (MIT), em 2002, comparando-se
o mercado do Brasil, da China e da Índia, “a indústria brasileira de TI está pronta para competir
com seus grandes concorrentes internacionais. Entre os três países estudados, o Brasil tem o
maior mercado interno de software, da ordem de US$ 7,7 bilhões, mas exporta apenas 1,5% desse
total, em produtos e serviços, o que contrasta profundamente com a Índia, cujas exportações
superam 70% de seu mercado total, de US$ 8,2 bilhões, basicamente sob a forma de serviços”
(MCT, 2003b).
Em conseqüência desta realidade, as organizações têm-se preocupado cada vez mais com
a melhoria da qualidade de seus produtos de software com os custos efetivos e com o
cumprimento de cronogramas em seus projetos de desenvolvimento. Todas estas características
dependem de um gerenciamento do processo de desenvolvimento de software eficiente e eficaz.
Nesse gerenciamento, é essencial a adoção de normas, modelos de maturidade de
processos de software, guias como NBR ISO/IEC 12.207 (ASSOCIAÇÃO BRASILEIRA DE
NORMAS TÉCNICAS (ABNT), 1998); NBR ISO/IEC 10.006 (ABNT, 2000); ISO/IEC TR
15.504 (,17(51$7,21$/67$1'$5'25*$1,=$7,21 (ISO), 1998); CMM (PAULK, 2000)
e PMBOK (2000) e de um plano de projeto efetivo, que englobe os requisitos de qualidade do
produto, exigidos pelo cliente e seja baseado em estimativas precisas de tamanho, esforço, prazos
e custos.
O tamanho de um projeto de software é uma das primeiras estimativas a ser realizada,
pois dessa dimensão depende a definição de esforço, custos e prazos necessários para a
definição do plano de desenvolvimento do software(CALDIERA et al., 1998).Além de subsidiar
o planejamento do projeto, a estimativa de tamanho facilita o relacionamento entre cliente e
 2

fornecedor; permite o gerenciamento de riscos; o controle do cronograma e possibilita o

conhecimento da produtividade da equipe, o que também beneficia a gerência e a qualidade dos
contratos de terceirização de projetos de software (HAZAN, 1999; GARMUS; HERRON, 2000 e
LONGSTREET, 2002).
A precisão de estimativas de tamanho é dependente de informações que nem sempre estão
disponíveis no início dos projetos. No entanto, essas estimativas são necessárias no início do
projeto para discussão de contratos ou determinação da viabilidade do projeto em termos da
análise de custos e benefícios. Sendo assim, é necessário à obtenção de estimativas mais precisas
no início do projeto, bem como o seu gerenciamento durante todo o ciclo de desenvolvimento do
mesmo. Dessa forma, espera-se reduzir os problemas de gestão tais como: alto custos, atrasos no
cronograma, insatisfação do usuário e dificuldades de medição do progresso do projeto
(MURTHI, 2002).
Várias métricas de tamanho de software têm sido desenvolvidas e melhoradas desde o
final da década de 1960, entre elas: Linhas de código (LOC) )XQFWLRQ 3RLQW $QDO\VLV %DQJ,
)HDWXUH 3RLQWV DQG %RHLQJ¶V ' )XQFWLRQ 3RLQW, 0DUN ,, )XQFWLRQ 3RLQW $QDO\VLV, 8VH &DVH
3RLQW &260,&)XOO)XQFWLRQV3RLQWV (McPHEE, 1999; GARMUS; HERRON, 2000).
A estimativa de tamanho de projeto de software ainda está em evolução nas empresas
brasileiras. Pesquisa de qualidade e produtividade no setor de software brasileiro, realizada pela
Secretaria de Política de Informática do Ministério da Ciência e Tecnologia (MCT) em 2001,
demonstraram que em uma amostra de 446 organizações do mercado de software brasileiro
(91,5% delas são empresas privadas), apenas 30% utilizavam algum tipo de métrica para medir a
produtividade e a qualidade dos processos de software. Dentre essas, 10,3% utilizam LOC,
18,2% utilizavam a APF e 6,7% utilizam outras métricas (MCT, 2002).
Embora o índice de uso de métricas no Brasil seja baixo, Aguiar (2003) ressalta que o
interesse pela APF tem crescido bastante. Sua afirmação tem como base o aumento de
profissionais brasileiros certificados pelo IFPUG como Especialistas em Pontos de Função
(CFPS) nos últimos três anos. Enquanto, no período de 1996-2001 havia 16 CFPS, somente em
2002 e 2003 tiveram 80 certificações. De acordo com a lista de profissionais certificados,
disponibilizada na página do %UD]LOLDQ )XQFWLRQ 3RLQW 8VHUV *URXS (BFPUG), existem até
janeiro de 2004, 139 (cento e trinta e nove) especialistas certificados pelo IFPUG no Brasil.
 3

A )XQFWLRQ 3RLQW $QDO\VLV ou Análise de Pontos de Função (APF) é uma das métricas
mais utilizadas em sistemas tradicionais desde 1979 e mede o tamanho das funções do software
sob o ponto de vista do usuário, utilizando a documentação gerada durante todo o processo de
desenvolvimento do produto, principalmente as da fase de projeto.
Apesar da APF ser a métrica de tamanho mais utilizada no mercado, muitos autores
criticam a sua adequação à estimativa de tamanho de projetos atuais, como os projetos Orientados
a Objetos (OO), pois a APF foi criada em 1979, com base nos conceitos das técnicas de análise e
projeto estruturados, diferentes dos conceitos baseados na tecnologia OO, abordagem bastante
utilizada no mercado atual (SYMONS, 1988; FENTON; PFLEEGER, 1997; GUPTA R; GUPTA
S., 1996). Apesar desta crítica, diversos estudos têm sido realizados propondo o mapeamento da
APF para OO ou desenvolvendo novas métricas com base na APF como o 8VH &DVH 3RLQW ou
Pontos de Casos de Uso (PCU) (KARNER, 1993; FETCKE, ABRAN, NGUYEN, 1997;
CALDIERA et al., 1998; KUSUMOTO, INOUE, KASIMOTO, 2000; TICHENOR, 1997;
RAM, RAJU, 2000; CARBONE, SANTUCCI, s.d. ; ARNOLD, PEDROSS, 1998).
Com o aumento do uso da tecnologia Orientada a Objetos (OO) para o desenvolvimento
de projetos de software, a estimativa de tamanho passou a ser realizada também através de Pontos
de Casos de Uso (PCU), uma métrica mais recente, proposta em 1993 para a estimativa de
projetos de software orientado a objetos.
A principal diferença entre APF e PCU está relacionada ao momento da coleta de
informações para a estimativa de tamanho inicial do projeto. A APF possui resultados melhores,
à medida, em que se tem mais informação da análise e do projeto de sistemas (tabelas, campos,
associações, etc). O PCU tem como proposta ser utilizado logo no início do ciclo de
desenvolvimento, na fase de definição dos requisitos, com base no modelo de casos de uso. O
modelo de casos de uso é uma técnica largamente utilizada na indústria para capturar e descrever
os requisitos funcionais de um software. Esse modelo consiste de diagramas e descrições de casos
de uso (ANDA, 2002).
Considerando que os casos de uso são desenvolvidos durante a fase de levantamento de
requisitos e análise e que eles capturam representações precisas das necessidades do usuário, faz
sentido basear-se no modelo de casos de uso para fazer a estimativa de tamanho do software.
Uma outra vantagem da estimativa baseada em casos de uso é que os casos de uso são mantidos
por outros artefatos como projeto, código, documento de testes, gestão de configuração,
 4

arquitetura etc. Além disso, os casos de uso são centrados nos usuários e não no projeto do
sistema (DAMODARAN; WASHINGTON, s.d).
Se estas métricas possuem pontos positivos e têm sido utilizadas em projetos de software
orientado a objetos, conforme demonstrado na literatura, porque não utilizá-las de forma
combinada para obter estimativas mais precisas no início do projeto e permitir ao gerente o
refinamento das mesmas durante todo o processo de desenvolvimento do projeto?
Através do uso combinado da APF e PCU e de uma abordagem de gestão adequada de
estimativa de tamanho durante todo o processo de desenvolvimento, espera-se que o gerente
possa fazer a estimativa do tamanho do software e conhecer a dimensão do que está sendo
gerenciado no início do projeto. Isto permite subsidiar o planejamento, comparar as estimativas,
controlar o projeto com mais segurança e providenciar ações de ajustes no plano e no
cronograma, para minimizar problemas existentes em relação ao custo e prazo dos projetos de
software e, conseqüentemente, aumentar a satisfação do cliente. Para isto, é necessário padronizar
os procedimentos de contagem definidos originalmente para a APF e PCU para projetos OO, de
acordo com os resultados e as experiências dos autores que aplicaram estas métricas nesse tipo de
projetos, investigar a existência de relação entre a APF e PCU, visando utilizar essas métricas de
forma combinada para estimar o tamanho de projetos de software OO com maior precisão desde
o início do projeto e identificar ações a serem tomadas pelos gerentes durante a execução e o
controle do projeto de software.

2EMHWLYRVH6XSRVLo}HV
2EMHWLYRJHUDO

Este trabalho visa indicar aos gerentes uma melhor forma de estimar, revisar e recalcular o
tamanho do projeto a partir da APF e PCU à medida que novos artefatos estejam disponíveis
durante o processo de desenvolvimento do projeto de software orientado a objetos, provendo
subsídios para melhorar as decisões gerenciais.
2EMHWLYRVHVSHFtILFRV
Para atender ao objetivo geral é necessário:

ƒestudar as principais características da APF e PCU e aplicá-las em projetos de

software orientados a objetos;
 5

ƒinvestigar a existência de relação entre as métricas APF e PCU;

ƒidentificar as ações gerenciais a serem tomadas pelo gerente durante o controle e
acompanhamento do projeto.
6XSRVLo}HV
Desta forma, as suposições a serem investigadas nesta pesquisa são:

ƒexiste relação entre APF e PCU que pode ser descrita por uma equação matemática;
ƒa APF e PCU podem ser usadas de forma combinada.

0HWRGRORJLD
A presente pesquisa caracteriza-se quanto à forma de abordagem do problema como uma
pesquisa qualitativa e aplicada com a finalidade prática de usar as métricas de estimativa de
tamanho de software APF e PCU de forma combinada, em projetos de software orientado a
objetos do mundo real.
Quanto aos fins, esta pesquisa é descritiva porque visa conhecer, analisar e interpretar as
informações dos projetos de software para encontrar a relação entre a aplicação das duas
métricas. E quanto aos meios, caracteriza-se como investigação documental, bibliográfica e de
campo. A pesquisa de campo envolveu a aplicação de um questionário para a identificação das
ações gerenciais entre os profissionais que exercem o papel de gerente de projetos de software em
empresas públicas e privadas.
Para a realização deste trabalho, foi feito um estudo bibliográfico na literatura para obter
entendimento teórico necessário sobre medição de software, métricas de estimativa de tamanho
de software, APF, PCU e respectivos processos de contagem, gestão de projetos de software e
ações gerenciais relacionadas à gestão de estimativas de tamanho durante a execução e o controle
de projeto de software.
A partir deste estudo, foi definido um processo de gestão de estimativas de tamanho. Este
processo consiste do uso combinado da APF e PCU durante todo o ciclo de desenvolvimento do
projeto. Para subsidiar este processo foram padronizados os procedimentos de contagem da APF
e PCU para projetos OO, investigada a relação existente entre a APF e PCU e identificadas ações
gerenciais a serem tomadas pelos gerentes. As atividades deste processo foram definidas com
base nas NBR ISO/IEC 12.207 (ABNT, 1998); NBR ISO/IEC 10.006 (ABNT, 2000) no guia do
 6

PMBOK (PMBOK, 2000) e em um processo de desenvolvimento de software OO

(RATIONAL..., 2001b).

(VWUXWXUD
Este trabalho consiste de cinco capítulos, incluindo este que é a introdução.
No capítulo 2, são apresentados os conceitos relacionados à medição, às métricas de
estimativa de tamanho de softwareàs principais características e aos procedimentos de contagem
das métricas da APF e PCU, aos trabalhos relacionados à aplicação dessas métricas em projetos
de softwareorientados a objetos, disponíveis na literatura e às principais diferenças entre APF e
PCU.
No capítulo 3, são apresentados os conceitos de gestão de projetos, os principais
processos, principalmente os de planejamento e controle e a gestão de projetos de acordo com a
NBR ISO/IEC 10.006 (ABNT, 2000) e a NBR ISO/IEC 12.207 (ABNT 1998).
O capítulo 4 descreve o objetivo e as atividades relevantes para a gestão de estimativa de
tamanho, que engloba: padronização dos procedimentos de contagem de PF e PCU em projetos
de software OO; investigação da relação entre PF e PCU; identificação das ações gerenciais a
serem tomadas pelos gerentes durante a execução do projeto; a definição do processo de gestão
de estimativa e o seu relacionamento com os processos de desenvolvimento e a gestão de projetos
de software.
No capítulo 5, são apresentadas as principais contribuições deste trabalho para a melhoria
do processo de gestão de estimativa de tamanho e as perspectivas de trabalhos futuros.
Finalmente, é apresentado o questionário explicativo para identificar o nível de influência
das características gerais do sistema (IFPUG, 2000) e dos fatores técnicos e ambientais propostos
por Karner (1993) (APÊNDICE A), o questionário para identificar as ações gerenciais a serem
tomadas pelos gerentes durante a gestão de estimativas (APÊNDICE B) e o modelo do processo
de desenvolvimento de projeto de software OO (APÊNDICE C).
 7

&DStWXOR0pWULFDVGHHVWLPDWLYDGHWDPDQKRGHVRIWZDUH

,QWURGXomR
Eficiência, entrega do produto no prazo, dentro do orçamento e com um nível de
qualidade desejado pelo cliente são características que influenciam no sucesso de organizações de
desenvolvimento de software no mercado atual, globalizado e competitivo de TI. Neste sentido,
ressaltam-se a importância de mecanismos de acompanhamento e a avaliação do progresso do
processo, projeto e produto.
Estes mecanismos, normalmente baseados em informações qualitativas e quantitativas
coletadas através de medições realizadas durante o projeto, são recursos essenciais na gestão de
desenvolvimento de software. Para o gerente do projeto, essas medidas, também conhecidas
como métricas, permitem melhor entendimento do processo de produção e do controle do projeto
de software. Desta maneira, as medições fornecem informações que permitem a determinação de
pontos fortes e fracos dos processos e produto, indicam ações corretivas e propiciam avaliações
de impactos de tais ações. Enfim, garantem a qualidade do processo e dos produtos obtidos
(FENTON; PFLEEGER, 1997; BASILI; CALDIERA; ROMBACH, 1994).
A necessidade de medidas que informem a eficiência do desenvolvimento e minimizem os
fracassos de projetos, principalmente em relação às falhas no cronograma e nas estimativas
realizadas, demandaram a realização de estudos na área de estimativa de tamanho de software,
que resultaram na proposição de diversas métricas ou métodos de medição de processo, projeto e
produtos de software.
Este capítulo apresenta alguns conceitos relacionados à medição e às métricas de
estimativa de tamanho de software APF e PCU e as principais pesquisas realizadas sobre a
aplicação das mesmas em projetos de software orientados a objetos.

0HGLomRGHVRIWZDUH
Medição “ é um processo pelo qual números ou símbolos são atribuídos a propriedades de
entidades do mundo real de modo a descrevê-las de acordo com regras claramente definidas”
(FENTON; PFLEEGER, 1997). Basili; Caldiera; Rombach (1994) definem medição como um
mecanismo para criar memória corporativa e auxiliar nas buscas de respostas para diversas
 8

questões associadas ao processo de software. Estes autores ressaltam que para ser efetiva, a
medição tem que focar em objetivos específicos, ser aplicada durante todo o processo de
desenvolvimento do produto, processo e projeto e ser interpretada com base na caracterização e
no entendimento do contexto organizacional.
Por outro lado, McGarry et al., (2001) ressaltam que o sucesso do programa de medição
depende de um processo estruturado e repetitivo que define as atividades de medidas (coleta,
análise e apresentação dos dados) diretamente relacionadas às necessidades de informação dos
gerentes de projetos. Estes autores destacam também, que a medição é mais efetiva quando
implementada de forma integrada com as atividades técnicas e de gestão que definem os projetos
de software, porque a medição fornece informações objetivas relacionadas aos riscos e problemas
que podem ter impacto nos objetivos dos projetos definidos.
Pressman (2002), com base no ,(((6WDQGDUG*ORVVDU\RI6RIWZDUH(QJLQHHULQJ7HUPV
define medida como “ uma indicação quantitativa da extensão, dimensão, capacidade ou tamanho
de algum atributo de um produto ou de um processo” e métrica como “ uma medida quantitativa
do grau em que um sistema, componente ou processo possui determinado atributo” . Com base
nas medidas, são obtidos os indicadores que são uma métrica, ou combinação de métricas que
fornecem compreensão de um processo, recursos e projeto ou produto de software (PRESSMAN,
2002).
As métricas podem ser classificadas em várias categorias: métricas de processo, produto
e recursos (FENTON; PFLEEGER, 1997), objetivas e subjetivas (MÖLLER; PAULISH, 1993) e
diretas e indiretas (FENTON; PFLEEGER, 1991; PRESSMAN, 2002).
As métricas de processo medem as atividades realizadas durante todo o desenvolvimento
de software; as métricas de produto medem os artefatos, produtos e documentos gerados pelo
processo; e as métricas de recursos medem as entidades requeridas para a execução do processo
(FENTON; PFLEEGER, 1997).
As métricas objetivas podem ser quantificadas e medidas através de expressões numéricas
ou representações gráficas de expressões numéricas contadas a partir do código fonte, projeto,
dados de teste, e outras informações do software. As métricas subjetivas são medidas baseadas
em estimativas pessoais ou de grupo, geralmente obtidas através de conceitos como excelente,
regular, bom e ruim (MÖLLER; PAULISH 1993).
 9

Para Fenton e Pfleeger (1997), métricas subjetivas dependem da pessoa que está
mensurando, do seu julgamento e do grau de imprecisão, o que dificulta o consenso entre
atributos que envolvem processos, produtos ou qualidade.
As métricas diretas são aquelas que não dependem da medida de outro atributo, mas da
quantificação de um fator observado no produto. Já as métricas indiretas envolvem as medidas de
um ou mais atributos relacionados a este (FENTON; PFLEEGER, 1991).
Dentro da categoria de métricas direta, McGarry et al. (2001) destacam algumas
abordagens de métricas de estimativas de projeto de software como: i) modelos paramétricos; ii)
analogia; iii) julgamento de especialistas; iv) atividades baseadas em modelos; e v)
relacionamentos de estimativas. As abordagens mais comuns são os modelos paramétricos,
analogia e julgamento de especialistas.
Os modelos paramétricos assumem que existe um relacionamento matemático entre o
tamanho, esforço, cronograma e qualidade e que o relacionamento é afetado por fatores
mensuráveis de desempenho também chamados parâmetros. A entrada mais importante nesse
modelo é o tamanho, o qual representa a quantidade de funções do software. Para obter melhores
resultados, os modelos paramétricos têm que ser calibrados com dados do ambiente local de
desenvolvimento (McGARRY et al., 2001).
A analogia é geralmente realizada por especialista em estimativa (com base na
experiência de projetos anteriores) e por algoritmos de busca de projetos similares (disponíveis
em base de dados) (JORGENSEN; INDAHL; SJOBERG, 2003). Esta abordagem requer um
conhecimento detalhado do projeto para identificar as diferenças específicas entre o projeto
proposto e os projetos realizados anteriormente, que foram usados como base para fazer a
estimativa. O relatório do estudo realizado por Heemstra (1992), citado por Jorgensen; Indahl;
Sjoberg (2003) em 600 organizações destaca que a estimativa por analogia é o método mais
comum de estimativa na indústria de software.
O julgamento de especialistasé realizado com base nas experiências de profissionais em
projetos semelhantes. As técnicas baseadas na experiência de especialistas são úteis na ausência
de dados quantitativos. Longstreet (2002) sugere que ao “ avaliar projetos semelhantes, deve-se
considerar o tipo de plataforma de hardware, o tipo de linguagem, o tipo de projeto, o tipo de
sistema operacional e identificar os dados históricos de taxa de entrega, de cronogramas e de
custo do projeto” . 
 10

Para obter resultados significativos, todas as abordagens de métricas de estimativas

requerem alguns dados históricos similares ao projeto proposto incluindo, o domínio da
aplicação, o nível de maturidade do processo de desenvolvimento, a experiência da equipe, taxas
de produtividade, tipos de tecnologia e de ferramentas utilizadas e o grau de reuso (McGARRY
et al., 2001; FENTON; PFLEEGER, 1997).
A seguir, serão apresentadas as métricas de estimativa de tamanho de software que, em
geral, são baseadas em modelos paramétricos.

0pWULFDVGHHVWLPDWLYDVGHWDPDQKRGHVRIWZDUH
“ Estimativa de tamanho de software é um processo pelo qual uma pessoa ou um grupo de
pessoas estima o tamanho de um produto de software” (McPHEE, 1999). O tamanho, geralmente,
tem impacto na solução técnica e na gestão do projeto já que, estimativas imprecisas podem levar
ao fracasso do projeto (ROSS, s.d).
O tamanho do software significa a quantidade de trabalho a ser executado no
desenvolvimento de um projeto. Cada projeto pode ser estimado de acordo com o tamanho físico
(que são medidos através da especificação de requisitos, análise, projeto e código); com base nas
funções que o usuário obtém, na complexidade do problema que o software irá resolver e no
reuso do projeto, que mede o quanto o produto será copiado ou modificado a partir de um outro
produto existente (FENTON; PFLEEGER, 1997; McPHEE, 1999).
As primeiras métricas de estimativa de tamanho de software surgiram em 1950/1960 e se
basearam no tamanho físico de linhas de código como o /LQHVRI&RGH(LOC) (FENTON; NEIL,
2000). Esta métrica considera o software sob a perspectiva da estrutura interna e é aplicada nas
fases finais do projeto (MISIC; TESIC, s.d.).
Ross (s.d.) destaca duas vantagens no uso de LOC: i) a possibilidade de fazer a estimativa
automaticamente; e ii) a facilidade de uso de dados históricos pois, grande parte dos dados de
estimativas existentes, foram medidos através de LOC. Já, as desvantagens estão relacionadas à
ambigüidade, pois a métrica trata de abstrações não textuais, e a falta de significado da medida
para o usuário final. Além destas desvantagens, Jones (1986), citado por Fenton e Pfleeger
(1997), ressalta que uma contagem em LOC depende do grau de reuso e da linguagem de
programação e pode ser cinco vezes superior a uma outra estimativa, devido às diferenças das
técnicas de medição de linhas em branco, linhas de comentário, declaração de dados e linhas de
 11

instruções. Fenton e Pfleeger (1997) destacam ainda, que a LOC penaliza programas pequenos e
bem projetados, não se adapta às linguagens não procedimentais e é de difícil obtenção na fase
inicial de planejamento.
LOC foi uma métrica bastante utilizada até meados de 1970. A partir daí surgiram
diversas linguagens de programação e conseqüentemente a necessidade de outras formas de
estimar o tamanho de software.
Atualmente, são várias as métricas de estimativa de tamanho existentes e grandes as
dificuldades para selecionar a mais apropriada para o tamanho de um projeto de software de uma
organização. As principais métricas foram desenvolvidas com base nas funções de software tais
como: )XQFWLRQ3RLQW$QDO\VLV ou Análise de Pontos de Função; %DQJ; )HDWXUH3RLQWV%RHLQJ¶V
(')XQFWLRQ3RLQW; 0DUN,,; 8VH&DVH3RLQWou Pontos de Casos de Uso, &260,& )XOO)XQFWLRQ
3RLQW (McPHEE, 1999; GARMUS; HERRON, 2000).
A Análise de Pontos de Função (APF) é uma das primeiras métricas a medir o tamanho do
software com alguma precisão, é a mais utilizada no mercado, tornando-se padrão internacional
em 2002 através da norma ISO/IEC 20.926 (DEKKERS, 2003; AGUIAR, 2003). Atualmente, o
mapeamento da APF para estimativa de projetos de software OO tem sido largamente discutido
na literatura.
O Ponto de Casos de Uso (PCU) foi definido para estimar projetos Orientados a Objetos
(OO), com base na mesma filosofia da APF e 0DUN,, (a estimativa de tamanho é baseada nas
funções do software de acordo com a visão do usuário) e no processo “ 2EMHFWRU\” , onde foi
desenvolvida a técnica de diagramação para o conceito de casos de uso. Posteriormente, Ivar
Jacobson desenvolveu a “ 2EMHFW2ULHQWHG6RIWZDUH(QJLQHHULQJ (OOSE)” , metodologia centrada
em casos de uso1, técnica largamente utilizada na indústria para descrever e capturar os requisitos
funcionais de software (RIBU, 2001). Considerando-se que o modelo de casos de uso foi
desenvolvido para capturar os requisitos baseados no uso e na visão dos usuários, faz sentido

1
Caso de uso representa as funções do sistema. É uma coleção de interações seqüenciais entre o software em desenvolvimento e
seus atores externos relacionados a um objetivo específico. Os casos de uso possuem relacionamentos do tipo incluídos e
estendidos (COCKBURN, A., 2000, citado por RIBU, 2001). O comportamento comum é executado através de casos de usos
incluídos e os opcionais, através dos casos de uso estendidos. O relacionamento tipo ‘incluído’ é usado para evitar a cópia do
mesmo texto em fluxos alternativos de diversos casos de uso. Esses tipos de casos de uso são sempre chamados quando o caso
de uso é nomeado num passo de um outro caso de uso. O caso de uso ‘estendido’ indica que uma instância do caso de uso
pode ou não incluir o comportamento especificado no outro caso de uso. Este tipo de relacionamento descreve alternativas ou
adições ao cenário principal e são escritas separadamente (Ribu, 2001). Não há regras precisas para a contagem dos casos de
uso incluídos e estendidos.
 12

basear a estimativa de tamanho e recursos de projetos de software nos casos de usos

(DAMODARAN; WASHINGTON, s.d).
Como a APF é a métrica mais usada no mercado e provê estimativas mais precisas à
medida que se obtém mais informações do projeto e o PCU foi criado para estimar projetos OO
com base no modelo de casos de uso gerado no início do projeto, essas métricas foram
selecionadas como objeto de estudo deste trabalho. Dessa forma, as características relevantes, o
processo de contagem e os principais estudos sobre o uso dessas métricas em projetos OO, serão
apresentadas a seguir.

$QiOLVHGH3RQWRVGH)XQomR$3)
A APF foi desenvolvida em meados da década de 70 e publicada em 1979 por Allan
Albrecht na tentativa de minimizar as dificuldades associadas às linhas de código como medida
de tamanho de software, e de ajudar na geração de um mecanismo que pudesse prever o esforço
associado ao desenvolvimento de software (LONGSTREET, 2002).
A primeira versão da APF visava tratar dos fatores externos, das características
importantes para o usuário, ser aplicada no início do processo de desenvolvimento do produto,
ser ligada à produtividade econômica e ser independente do código fonte ou linguagem de
programação do software (McPHEE, 1999).
Em 1984, Allan Albrecht refinou esta versão e, posteriormente, com o aumento do uso da
APF, tornou-se necessário definir um guia que interpretasse as regras originais para os novos
ambientes. Devido à essa necessidade, em 1986 foi criado o ,QWHUQDWLRQDO)XQFWLRQ3RLQW8VHUV
*URXS (IFPUG). A partir desta data, o IFPUG passou a ser o responsável pela definição das
regras de contagem, pelo treinamento e pela certificação dos profissionais interessados na
aplicação dessa métrica e divulgação de diversas bases de dados históricas de produtividade da
indústria de desenvolvimento de software, disponibilizadas por vários órgãos, entre eles o
,QWHUQDWLRQDO 6RIWZDUH %HQFKPDUNLQJ 6WDQGDUGV *URXS (INTERNATIONAL SOFTWARE
BENCHMARKING STANDARDS GROUP (ISBSG), 2002). Essas informações possibilitam a
estimativa de tempo de desenvolvimento de novos projetos de software e produtividade da equipe
com base em estimativas anteriores realizadas através da APF (GARMUS; HERRON, 2000;
IFPUG, 2000; LONGSTREET, 2002).
 13

A APF tornou-se a métrica mais usada e estudada na história da engenharia de software e

no final de 1993 já havia grupos de usuários em 18 países (JONES, 1994).
A APF visa estabelecer uma medida de “ tamanho” do software, em Pontos de Função
(PF) (unidade de medida para software assim como a hora é unidade de medida para tempo),
através da quantificação das funções implementadas sob o ponto de vista do usuário, num
enfoque empresarial e não técnico (LONGSTREET, 2002).
Essa métrica tem como princípio básico focar na especificação de requisitos para obter
estimativas de tempo, custo, esforço e recursos na fase inicial do projeto ou na manutenção de
software independente da tecnologia utilizada para implementação (FUREY, 1997; RIBU, 2001).
A APF permite uma contagem indicativa no início do desenvolvimento sem conhecer
detalhes do modelo de dados. Posteriormente, na fase de projeto, essa contagem passa a ser uma
estimativa com maior precisão da complexidade das funções e, ao término do desenvolvimento
do software, na implantação, é realizada uma contagem detalhada, obtida a partir do grau de
complexidade das funções levantadas no processo funcional, modelo de dados, descrição das
telas e relatórios (IFPUG, 2000; LONGSTREET, 2002).
Em geral, as organizações aplicam a APF como: “ um método para determinar o tamanho
do pacote de software adquirido; para apoiar a análise da produtividade e qualidade; para estimar
os custos, recursos e esforços de projetos de desenvolvimento e manutenção de software´
(HAZAN, 1999; GARMUS; HERRON, 2000)
Além destas finalidades, Longstreet (2002) destaca outras utilidades da APF tais como:
“ definir quando e onde fazer reengenharia; estimar casos de testes; entender o aumento do
escopo; ajudar em negociações contratuais; desenvolver um conjunto padrão de métricas; e fazer
comparação de software´.
Para estimar o tamanho do software de acordo com a AFP, o IFPUG definiu os
procedimentos de contagem conforme descritos a seguir.

3URFHVVRGHFRQWDJHPGH$QiOLVHGH3RQWRVGH)XQomR
O processo de contagem da APF compõe-se de sete etapas (IFPUG, 2000):
i) 'HWHUPLQDU R WLSR GH FRQWDJHP - A APF se propõe a estimar o tamanho de
projetos de desenvolvimento; aplicações em uso ou projetos de manutenção.
 14

ii) ,GHQWLILFDURHVFRSRGDFRQWDJHPHDIURQWHLUDGDDSOLFDomR– O escopo define

as funções que serão contadas de acordo com a visão do usuário, e a fronteira da
aplicação separa o projeto a ser contado dos usuários e das aplicações externas ao
domínio do projeto.
iii) &RQWDU DV IXQo}HV GH GDGRV ± As funções de dados consistem de: Arquivos


Lógicos Internos (ALIs) e Arquivos de Interface Externa (AIEs). Um AIE de
uma aplicação sempre será contado como um ALI na aplicação de origem. Para
identificar um ALI, observar as seguintes regras:
a. se o grupo de dados ou informações de controle é lógico e identificável pelo
usuário;
b. se o grupo de dados é mantido através de um processo elementar dentro da
fronteira da aplicação a ser contada.
A complexidade dos ALIs é identificada através do número de itens de dados4 e de
registros lógicos5. Para identificar os itens de dados, seguir as seguintes regras:
a. contar um item de dados para cada campo reconhecido pelo usuário como
único, não repetido, mantido por um ALI ou recuperado de um AIE ou de um
ALI;
b. quando duas aplicações mantêm e ou referenciam o mesmo ALI ou AIE, mas
cada uma mantém ou referencia itens de dados separados, conte apenas os
itens de dados utilizados em cada aplicação para avaliar a complexidade dos
ALI e AIE;
c. contar um item de dado para cada campo requerido pelo usuário para
estabelecer um relacionamento com outro ALI ou AIE que, no caso, é
considerada chave estrangeira.
Para identificar um AIE, verificar grupos de dados ou informação de controle que
satisfaçam a definição de um AIE. As seguintes regras devem ser verificadas:

2
Arquivo Lógico Interno é um grupo lógico de dados ou informações de controle sob o ponto de vista do usuário, cuja
manutenção é feita internamente pela aplicação.
3
Arquivo de Interface Externa é um grupo lógico de dados referenciado na aplicação cuja responsabilidade pela manutenção é de
outra aplicação, ou seja, não é mantido pela aplicação que está sendo contada. São armazenados fora da fronteira da aplicação.
4
Item de dados representa um segmento de um registro do ALI que tem significado único e é identificado pelo usuário. São os
campos da tabela e deve-se contabilizar um item de dado para cada campo.
5
Registros lógicos são subgrupos de dados reconhecidos pelo usuário dentro de um Arquivo Lógico Interno.
 15

a. o grupo de dados ou informação de controle é lógico e identificável pelo

usuário;
b. o grupo de dados é referenciado pela aplicação a ser contada mas pertence à
outra aplicação fora da fronteira da aplicação;
c. o grupo de dados não mantido pela aplicação a ser contada;
d. o grupo de dados é mantido em um Arquivo Lógico Interno de outra aplicação.
De acordo com o número de itens de dados e de registros lógicos identificados, classifica-
se o ALI e AIE conforme a Quadro 1 e atribui os pesos de 7, 10 ou 15 PFs para os ALIs e 5, 7
ou 10 PFs para os AIE respectivamente à complexidade baixa, média ou alta.

4XDGUR&RPSOH[LGDGHIXQFLRQDO,)38*

   
 



 
    "! #%$&'$ &( )+*-,.'/ 0

 12 12 354

#& 12 354 
6 )+*.,.'/ 0 354  

iv) &RQWDU DV IXQo}HV WUDQVDFLRQDLV ± Estas funções representam as funções de

processamento dos dados fornecidos pela aplicação ao usuário. As funções
transacionais podem ser Entradas Externas (EE)6, Saídas Externas (SE)7 e
Consultas Externas (CE)8. Compõem-se de itens referenciados (parâmetros que
estão sendo representados pelos seus tipos) e de arquivos referenciados.
Para identificar as EEs, devem ser analisados todos os processos elementares que recebem
dados de fora da aplicação e que atualizam um ou mais ALIs de acordo com as seguintes regras:
a. os dados ou informação de controle devem ser recebidos de fora da fronteira da
aplicação;

6
Entradas Externas são transações recebidas de fora da fronteira da aplicação que têm como objetivo manter os ALI e ou alterar o
comportamento do sistema. Os dados podem ser recebidos de telas de entrada de dados ou diretamente de outros aplicativos.
Estes dados podem ser informações de negócios ou informação de controle.
7
Saídas Externas são as transações que geram dados e os enviam para fora da fronteira da aplicação. Têm que apresentar
informação para o usuário através de processamento lógico diferente ou adicional à recuperação de dados ou informação de
controle. Ex: dados transferidos para outra aplicação (dados contidos em um ALI e ou AIE, que são formatados e processados
para uso em uma outra aplicação); relatórios (se suas saídas usam processamento ou cálculos distintos); dados derivados (dados
que resultam de cálculos, fórmulas, ou outras operações sobre dados originais); formatos gráficos; gerador de relatórios (saídas
que são desenvolvidas para o usuário por meio de um gerador de relatórios).
8
Consultas Externas são combinações entre atividades de entrada e saída de dados, ou seja, é uma solicitação enviada para a
aplicação, a qual gera uma recuperação correspondente e exibe os dados.
 16

b. no mínimo, um AIE é mantido, se a entrada de dados pela fronteira não for

informação de controle que altera o comportamento do sistema.
Para contabilizar o item de dado referenciado na transação de EE, considerar as seguintes
regras:
a. os itens de dados de acordo com a visão do usuário;
b. contar os itens de dados, que aparecem mais de uma vez em um arquivo por causa da
tecnologia ou técnica de implementação apenas uma vez;
c. considerar um item de dado adicional para as teclas de função ou linha(s) de comando
que especificam a ação a ser tomada pela EE;
d. contabilizar os campos não informados pelo usuário, mas que são atualizados em um
ALI por uma EE;
e. as mensagens de erros, confirmação ou itens de dados adicionais, devem ser
consideradas, caso sejam requeridas pelo usuário.
De acordo com o número de itens de dados, ALI e AIE referenciados, classifica-se a EE
em baixa, média ou alta, conforme o Quadro 2 abaixo e os respectivos pesos (3, 4 ou 6 PF).
Para identificar as SEverificar o processamento lógico do processo elementar de acordo
com as seguintes regras:
Quadro 2 - Complexidade de Entrada Externa (IFPUG, 2000)

   
 


 
7
89

 : &"&  6 )+*-,.'/ 0
 
 

$ 12 12 354
# 12 354 
; )+*.,.'/ 0 354  

a. se contém no mínimo, uma fórmula matemática ou cálculo;

b. se cria dados derivados;
c. se mantém no mínimo, um ALI;
d. se altera o comportamento do sistema.
Já a complexidade da SE é verificada através donúmero de arquivos e elementos de dados
referenciados. Deve-se contar um arquivo referenciado para cada ALI mantido ou lido ou um AIE
lido durante o processamento da SE.
Para identificar os itens de dados, observar as regras:
 17

a. contar um item de dado para cada campo reconhecido pelo usuário, não repetido, que
entre pela fronteira da aplicação e seja requerido para especificar quando, qual e/ou
como o dado será recuperado ou gerado pelo processo elementar ou que saia da
fronteira da aplicação. Se um item de dado entra e sai pela fronteira da aplicação,
contá-lo apenas uma vez;
b. contar um item de dado quando a aplicação enviar mensagens de resposta para fora da
fronteira, indicar um erro ocorrido durante o processamento, confirmar o
processamento completo ou verificar se o processamento deva continuar;
c. Contar um item de dado para a habilidade de especificar uma ação a ser tomada,
quando existem múltiplos métodos para chamar o mesmo processo lógico;
d. não contar os campos que são recuperados ou derivados pelo sistema e armazenados
em um ALI durante o processo elementar se esses campos não cruzam a fronteira da
aplicação;
e. não contar variáveis, números de páginas, data/hora ou selos gerados pelo sistema.
Após identificar os arquivos e os itens de dados referenciados, classificar a SE conforme o
Quadro 3 abaixo e atribuir o peso 4, 5 ou 7 PF respectivo à complexidade baixa, média ou alta.
4XDGUR&RPSOH[LGDGHGH6DtGD([WHUQD(IFPUG, 2000)


   
 


 
7
89


 
 
  & 6 "! #%$)+*-,.'/ 0
$ 12 12 354
# ; 12 354 
:)+*.,.'/ 0 354  

A CE visa apresentar informação para o usuário através da recuperação de dados ou

informação de controle. Verificar se o processamento lógico é elementar, segundo as regras
abaixo:
a. recupera dados ou informação de controle de um ALI ou AIE;
b. não contém fórmulas matemáticas ou cálculos;
c. não cria dados derivados;
d. não mantém ALI;
e. não altera o comportamento do sistema.
 18

De acordo com o número de itens de dados e arquivos referenciados, classificam-se as CEs

conforme o Quadro 4 e atribui-se o peso 3, 4 ou 6 PF conforme a complexidade baixa, média ou
alta.
v) 'HWHUPLQDU R 3) QmR DMXVWDGR ± Após identificar as funções de dados e
transacionais, multiplicar o total de ALI, AIE, EE, SE e CE pela respectiva
complexidade para determinar o valor de PF não ajustado. De acordo com a
complexidade, cada uma das funções de dados e transacionais contribui com um
determinado número de PF. O total desses pontos de função computados é
chamado de pontos de função não-ajustados.

4XDGUR&RPSOH[LGDGHGH&RQVXOWD([WHUQDIFPUG, 2000)


   
 


 
7
89


 
 
  & 6 "! #%$)+*-,.'/ 0
$ 12 12 354
# ; 12 354 
:)+*.,.'/ 0 354  


vi) 'HWHUPLQDU R )DWRU GH $MXVWH  O nível de influência dos fatores de ajustes
técnicos é determinado com base nas 14 características gerais de sistemas,
conforme mostra o Quadro 5 e o Apêndice A (questão 1 a 14). Após atribuir e
somar os valores dos fatores de ajustes para obter o nível de influência da
aplicação, deve-se aplicar a seguinte fórmula:
)$725'($-867( 1tYHOGH,QIOXrQFLD 

4XDGUR&DUDFWHUtVWLFDVJHUDLVGRVLVWHPD(IFPUG, 2000)

&DUDFWHUtVWLFDVJHUDLVGRVLVWHPD
Comunicação de dados Atualização on-line
Processamento distribuído Processamento complexo
Desempenho Reutilização de código
Utilização de equipamentos Facilidade de implantação
Volume de transações Facilidade operacional
Entrada de dados on-line Múltiplos locais
Eficiência do usuário final Facilidade de mudanças
 19

Estas características influenciarão a complexidade do software e conseqüentemente seu

tamanho. As características gerais do software podem variar o tamanho do software em 35% mais
ou menos.
vii) &DOFXODU RV 3RQWRV GH )XQomR DMXVWDGRV  Os PFs ajustados são calculados a
partir dos PFs não ajustados determinados no ítem ‘v’ e do fator de ajuste
determinado no ítem ‘vi’ de acordo com a seguinte fórmula:
3)B'(6(192/9,0(172 3)B1­2$-867$'2 )$725B$-867(
Apesar da APF ser a métrica mais utilizada para estimativa de tamanho de software, essa
métrica tem apresentado limitações por ter sido desenvolvida com base nas técnicas estruturadas.
Uma limitação da APF refere-se à tentativa de seu uso na medição do tamanho funcional de
outros tipos de software como o de tempo real, científicos e orientados a objetos (JONES, 1996;
WHITMIRE, 1992; REIFER, 1990; MUKHOPADHYAY; KEKRE, 1992, citados por ABRAN
et al. (2000); RIBU, 2001).
Em relação a software OO, vários estudos tem sido realizados sobre o uso e mapeamento
dos conceitos da APF para conceitos OO, conforme apresentado a seguir.

7UDEDOKRVUHODFLRQDGRVDRXVRGD$3)HPSURMHWRVGHVRIWZDUH22
Alguns pesquisadores propuseram o mapeamento da APF para OO com base no modelo
de casos de uso da 2EMHFW 2ULHQWHG 6RIWZDUH (QJLQHHULQJ (OOSE) (FETCKE; ABRAN;
NGUYEN, 1997). Outros autores basearam-se no diagrama de classes (consideram classes como
arquivo lógico e as mensagens como transações) (WHITMIRE e ASMA, ambos citados por
FETCKE; ABRAN; NGUYEN (1997); CALDIERA et al. (1998)). Uemura; Kusumoto; Inoue
(1999) detalharam as regras de medição da APF para a especificação de requisitos e projetos
usando os diagramas de seqüência e de classes com base na 8QLILHG0RGHOOLQJ/DQJXDJH (UML)
(KUSUMOTO; INOUE; KASIMOTO, 2000). Por outro lado, Gupta R. e Gupta S. (1996)
acreditam que não existe um simples relacionamento entre os conceitos originais da APF e os
conceitos de objetos e serviços.
Outros autores, além de fazer o mapeamento da APF para OO propuseram novos
métodos, tais como: )DVW &RXQW 2EMHFW 2ULHQWHG )XQFWLRQ 3RLQW 22)3 3UHGLFWLYH 2EMHFW
 20

3RLQW323V2EMHFW2ULHQWHG'HVLJQ)XQFWLRQ3RLQWV22')3)DVW 6HULRXVH8VH&DVH

3RLQW8&3< 
O )DVW&RXQW foi desenvolvido em 1993 para estimar PF, com base no método científico.
Este método permite que a equipe de projetos faça a estimativa de tamanho em menos tempo
(conta quatro vezes mais rápido) que a APF porque a contagem de PF se baseia no Modelo
central de dados e no 6WDIILQJ(VWLPDWRU, que é uma equação derivada da análise da relação entre
os pontos de função e o número de dias/desenvolvedor necessários para o desenvolvimento do
projeto (TICHENOR,1997).
O 2EMHFW 2ULHQWHG )XQFWLRQ 3RLQW (OOFP) criado por Caldiera et al (1998), faz o
mapeamento dos conceitos da APF para os conceitos OO (de acordo com a notação da 2EMHFW
0RGHOLQJ7HFKQLTXHV (OMT)). Estes autores definem os procedimentos de contagem de herança,
agregação e polimorfismo com base no modelo de objetos produzido na fase de projeto e
propõem realizar a estimativa de tamanho em diferentes pontos do desenvolvimento do software
à medida que novos artefatos são disponibilizados. O OOFP foi aplicado em oito subsistemas,
desenvolvidos no mesmo ambiente de uma empresa de software da área de telecomunicação.
Esses subsistemas foram também contados em LOC para que os autores pudessem aplicar as
técnicas de regressão e encontrar a associação entre OOFP e LOC.
O 3UHGLFWLYH2EMHFW3RLQW (POPs) proposto por Minkiewicz (1997) e citado por Caldiera,
et al. (1998), é baseado na contagem de classes e nos pesos dos métodos de cada classe. Os
métodos das classes são medidos com base no tipo do método e na complexidade. Os ajustes são
realizados pela média da profundidade da herança de acordo com o número de filhos da classe.
O2EMHFW2ULHQWHG'HVLJQ)XQFWLRQ3RLQWV (OODFP) foi adaptado por Ram e Raju (2000)
a partir dos procedimentos de contagem definidos pelo IFPUG. Esse método estima o tamanho
de software OO na fase de projetos, com base nas funções do software e na complexidade das
classes. A complexidade da classe pode ser baixa, média ou alta de acordo com um valor
numérico definido pelos autores com base em observações de diferentes projetos. Para estes
autores “ um arquivo lógico é uma coleção de elementos de dados, os quais são visíveis a todos os
métodos da classe” e as “ funções transacionais são os métodos das classes” .

9
Este método possui o mesmo nome do método de Karner (1993), é baseado em Casos de uso, mas foi definido por Arnold e
Pedross (1998)
 21

O )DVW 6HULRXV combina várias medidas extraídas dos diagramas da UML (através do
5DWLRQDO5RVH 2000) e, de acordo com o nível de detalhe do diagrama de classes, associa cada
classe à estimativa de tamanho em linhas de código. O tamanho estimado em LOC é convertido
em PF (CARBONE; SANTUCCI, s.d.).
O Use Case Point (UCP), desenvolvido por Arnold e Pedross, (1998) e também
denominado UCP como o método proposto pelo Karner (1993), é baseado em cenários e casos de
uso. Os autores utilizaram a APF para calibrar seu método e avaliaram os fatores técnicos
significantes para a funcionalidade requerida pelo sistema. De acordo com a comparação dos
resultados da contagem dos PCU (proposto pelo método de Arnold e Pedross, 1998) e dos FP,
eles detectaram uma variação na estimativa entre 90% a 110% e ressaltaram que “ esta precisão é
suficiente porque a avaliação da métrica de APF pode ter uma imprecisão de até 30%, quando a
estimativa do tamanho é realizada por diferentes líderes de projetos” .
Além dos diversos estudos apresentados sobre a aplicação da APF em projetos OO, um
outro estudo relevante foi realizado em 1994 pelo 4XDOLW\ $VVXUDQFH ,QVWLWXWH e IFPUG. Este
estudo indica que a variação da contagem entre contadores treinados e certificados tem diminuído
para aproximadamente 11%. No entanto, outras pesquisas realizadas por Uemura; Kusumoto;
Inoue (1999), Arnold e Pedross (1998) e Kemerer; Low; Jeffery estes últimos citados por
Kitchenham (1997), ressaltam que há diferença de 10% a 12% entre os contadores de uma
mesma organização e de 30% entre contadores de organizações diferentes.
A seguir serão apresentadas as principais características do PCU, a outra métrica a ser
utilizada neste trabalho.

3RQWRVGH&DVRGH8VR3&8
O PCU é um método de estimativa de tamanho de projeto de software orientado a objetos
criado por Karner (1993), com base na APF, 0DUN,, e no Modelo de casos de uso. O Modelo de
casos de uso foi posteriormente incorporado na 8QLILHG0RGHOOLQJ/DQJXDJH (UML) e tem sido
muito utilizado no mercado atualmente. O PCU também estima o tamanho da função do
software de acordo com a visão do usuário final e com base em uma unidade de medida o PCU.
Neste método, Karner (1993) explora o modelo e a descrição de casos de uso, substitui
algumas características técnicas propostas pela APF, cria os fatores ambientais e propõe uma
estimativa de produtividade.
 22

Os fatores ambientais e técnicos de ajustes propostos por Karner (1993) foram criados e
alterados de acordo com a experiência dos projetos desenvolvidos através do processo
“ 2EMHFWRU\” . A descrição destes fatores encontra-se no Apêndice A.
Karner (1993) propôs a produtividade de 20 homens/hora por PCU. Com base nos
recursos utilizados pelos projetos de seu estudo, tentou ainda encontrar a correlação entre PCU e
os recursos necessários para desenvolver o projeto através da adoção da regressão linear, mas
seus dados não foram suficientes para encontrar a relação proposta.
O método PCU contribui para a diminuição de algumas dificuldades impostas pelo
mercado em relação à resistência de adoção de métodos de estimativas, porque é um método
simples, fácil de usar e rápido de se aplicar, quando possui as informações necessárias para
realizar as estimativas (DAMODARAN; WASHINGTON s.d).
O PCU também possui um processo de contagem conforme descrito a seguir.

3URFHVVRGHFRQWDJHPGH3RQWRVGH&DVRVGH8VR
O processo de contagem de PCU compõe-se de seis etapas (Karner, 1993):
L &RQWDURVDWRUHVHDWULEXLURJUDXGHFRPSOH[LGDGH±Identificar e multiplicar o
total de atores de acordo com o tipo de complexidade (simples, médio ou
complexo) pelo respectivo peso (1, 2 ou 3), conforme Quadro 6 e somar os
produtos para obter o total de atores não ajustados.

4XDGUR3HVRGRVDWRUHV(Karner, 1993)

&RPSOH[LGDGHGRDWRU 'HVFULomR 3HVR

6LPSOHV Representa um outro sistema com Interface definida
 de Programas 1

Representa um outro sistema que interage através de

0pGLR protocolos ou quando há interação humana através 2
 de terminal

&RPSOH[R É uma pessoa que interage através de Interface 3
 Gráfica ou página Web

 23

LL &RQWDURVFDVRVGHXVRHDWULEXLURJUDXGHFRPSOH[LGDGHA complexidade é
baseada no número de transações10. De acordo com o número de transações,
multiplicar cada caso de uso pelo respectivo peso conforme Quadro7.

4XDGUR3HVRGRVFDVRVGHXVR(Karner, 1993)

&RPSOH[LGDGH&DVRGH8VR 'HVFULomR 3HVR

6LPSOHV Tem até 3 transações incluindo os passos alternativos
 e deve ser realizado com menos de 5 classes de
 análise 5

0pGLR Tem de 4 a 7 transações incluindo os passos
 alternativos e deve ser realizado com 5 a 10 classes 10
 de análise

&RPSOH[R Tem acima de 7 transações incluindo os passos
 alternativos e deve ser realizado com pelo menos de 15
 10 classes de análise

LLL &DOFXODURV3&8VQmRDMXVWDGRV±De acordo com aseguinte formula: 

  3&8QmRDMXVWDGRV  3HVRGH$WRUHV 3HVRVGH&DVRVGHXVR

LY 'HWHUPLQDU R IDWRU GH FRPSOH[LGDGH WpFQLFD 48$'52    Os fatores de

complexidade técnica variam numa escala de 0 a 5, de acordo com o grau de
dificuldade do sistema a ser construído. O valor 0 indica pouca criticidade e baixa
complexidade (irrelevante para o projeto) e o valor 5 indica alta criticidade e
complexidade (essencial). Após determinar o valor dos fatores, multiplicar pelo
respectivo peso, somar o total e aplicar a seguinte fórmula:
)DWRUGHFRPSOH[LGDGHWpFQLFD  6RPDWyULRGR)DWRUWpFQLFR









10
De acordo com Schneider e Winters (2001), transação é definida como um conjunto de atividades atômicas, as quais são
executadas completamente ou não. Quando tiver a mesma transação em todos os diagramas de seqüência como ex: ORJLQJ ou
procedimentos de segurança, a transação deve ser contada apenas uma vez porque a funcionalidade é implementada apenas uma
vez e reutilizada em outros casos de uso (RIBU, 2001).
 24

4XDGUR)DWRUHVGHFRPSOH[LGDGHWpFQLFD(Karner, 1993)

'HVFULomR 3HVR
Sistemas Distribuídos 2.0
Desempenho da aplicação 1.0
Eficiência do usuário final (on-line) 1.0
Processamento interno complexo 1.0
Reusabilidade do código em outras aplicações 1.0
Facilidade de instalação 0.5
Usabilidade (facilidade operacional) 0.5
Portabilidade 2.0
Facilidade de manutenção 1.0
Concorrência 1.0
Características especiais de segurança 1.0
Acesso direto para terceiros 1.0
Facilidades especiais de treinamento 1.0

Y 'HWHUPLQDU D HILFLrQFLD GR IDWRU DPELHQWDO  Os fatores ambientais indicam a

eficiência do projeto e estão relacionados ao nível de experiência dos
profissionais. Esses fatores (Quadro 9) são determinados através da escala de 0 a
5, onde 0 indica baixa habilidade (pouca experiência no domínio da aplicação), 3
indica média experiência e 5 indica alta experiência. Por exemplo, para o fator
“ motivação” , 0 significa sem motivação para o projeto; 3, média motivação e 5,
alta motivação. Para o fator “ requisitos estáveis” , 0 significa extremamente
instável; 3, médio e 5, estável. Para o fator “ trabalhadores com dedicação parcial” ,
0 indica poucos ou nenhum profissional de período não integral; 3, médio e 5
todos profissionais de período não integral. Para o fator “ dificuldade da
linguagem de programação” , 0 indica que a linguagem é de pouca complexidade e
ou que a equipe de projeto tem domínio completo sobre a mesma; 3, médio e 5,
muita dificuldade com a linguagem de programação. Após determinar o valor de
cada fator, multiplicar pelo peso e somar o total dos valores. Em seguida, aplicar a
seguinte fórmula:
)DWRU GH FRPSOH[LGDGH DPELHQWDO       6RPDWyULR GR )DWRU
DPELHQWDO

 25


4XDGUR)DWRUHVGHFRPSOH[LGDGHDPELHQWDO)$(Karner, 1993)

'HVFULomR 3HVR
Familiaridade com o Processo de Desenvolvimento de Software 1.5
Experiência na Aplicação 0.5
Experiência com OO, na Linguagem e na Técnica de Desenvolvimento 1.0
Capacidade do Líder de Projeto 0.5
Motivação 1.0
Requisitos estáveis 2.0
Trabalhadores com dedicação parcial -1.0
Dificuldade da Linguagem de Programação -1.0

YL &DOFXODU RV 3&8V DMXVWDGRV ± Esse cálculo é realizado com base na

multiplicação dos PCU não ajustados, na complexidade técnica e na complexidade
DPELHQWDODWUDYpVGDVHJXLQWHIyUPXOD
3&8  3&8 QmR DMXVWDGRV  )DWRU GH FRPSOH[LGDGH WpFQLFD  )DWRU GH
FRPSOH[LGDGHDPELHQWDO

7UDEDOKRVUHODFLRQDGRVDRXVRGH3&8HPSURMHWRVGHVRIWZDUH22
O PCU ainda é pouco utilizado na indústria. Agarwal (2001) citado por Damodaran e
Washington (2003) apresenta um exemplo de uso deste método para estimar um projeto de
Internet realizado na ,QIRV\V (Índia). Outras experiências de uso do PCU na indústria foram
realizadas por Anda et al (2001), por Ribu (2001) e por algumas empresas como a 5DWLRQDO, SUN
e IBM (PROBASCO, 2002).
No Brasil, algumas empresas privadas de desenvolvimento de software têm adotado o
PCU para estimativa de tamanho de projetos de software ou para estudos experimentais. Algumas
dessas experiências já foram publicadas por Valença (2003), Cunha e Almeida (2003) e Feitosa e
Jansen (2003).
Algumas razões para o baixo uso do PCU na indústria foram indicadas por Damodaran e
Washington (2003) tais como: i) o PCU é um método relativamente novo; ii) ainda não foi
incorporado em ferramentas populares de estimativa de software; e iii) o modelo de caso de uso,
apesar de ser um método padrão para descrição de requisitos, ainda não possui bons históricos de
 26

produtividade. Em função disso, e da necessidade dos gerentes dos projetos da indústria em obter
estimativas de tamanho no início do projeto para subsidiar o planejamento, outros métodos de
estimativa de tamanho têm sido utilizados e, à medida que se obtém mais informações sobre o
projeto através das iterações, novas estimativas são realizadas (SMITH, 1999).
Apesar do PCU ainda ser pouco utilizado na indústria, diversos autores já experimentaram
esta métrica com e sem o uso dos fatores técnicos de ajuste, computaram a estimativa de esforço,
propuseram um formulário padrão para descrição de casos de uso e definiram regras para atribuir
valores aos fatores ambientais (LONGSTREET, 2000; SCHNEIDER; WINTERS, 2001; ANDA
et al., 2001; ANDA, 2002 e RIBU, 2001).
Anda et al. (2001) aplicaram o método de Karner (1993) em três projetos de uma
companhia de desenvolvimento de software da Noruega, Suécia e Finlândia para comparar as
estimativas realizadas através do PCU com as estimativas realizadas pelos membros sêniorsdos
projetos. Os resultados mostraram que a estimativa realizada através de PCU foi próxima à
estimativa real realizada pelos desenvolvedores experientes. Estes autores observaram que alguns
aspectos da estrutura dos modelos de casos de uso tiveram impacto nas estimativas tais como: i) o
uso de generalização entre os atores; ii) a contagem dos casos de uso estendidos e incluídos; iii) o
nível de detalhe da descrição dos casos de uso; iv) as dificuldades para atribuição de valores aos
fatores técnicos e ambientais e; v) a escolha da taxa de produtividade por PCU. Anda et al. (2001)
definiram um formulário padrão para facilitar a descrição de casos de uso.
Os resultados dos estudos realizados por Anda et al. (2001) suportam reivindicações já
existentes, em que o modelo de casos de uso tem um impacto forte na estimativa; pode ser
utilizado com sucesso para estimar esforço em desenvolvimento de software e que o método de
Karner (1993) pode apoiar os especialistas no processo de estimativa baseado na APF.
Apesar de Karner (1993) não recomendar a contagem dos casos de uso estendidos e
incluídos, Anda et al. (2001) acham que os mesmos devem ser incluídos na contagem para evitar
estimativa abaixo da realidade, principalmente se as funções descritas nesses casos de uso são
essenciais e implementadas.
Em um outro trabalho, Anda (2002), investigou o PCU mediante a realização de cursos de
modelagem de caso de uso para 37 profissionais experientes em desenvolvimento de software.
Ele fez uma comparação entre a medição dos especialistas em desenvolvimento e em estimativa
de software, com a medição realizada por técnicos inexperientes com o domínio da aplicação e da
 27

tecnologia adotada para desenvolvimento. Neste estudo, foi utilizado o formulário padrão
definido no seu trabalho anterior para descrever os casos de uso.
Ribu, (2001) também utilizou o método de Karner (1993) para estimar o tamanho de
projetos de estudantes e da indústria. Este autor testou o PCU com e sem o uso dos fatores
técnicos de ajuste, computou a estimativa de esforço, propôs um formulário padrão para
descrição de casos de uso e definiu regras para atribuir valores aos fatores ambientais. Além
disso, propôs a analise da complexidade do caso de uso através do diagrama de seqüência e das
classes que implementam os casos de uso quando não houver a descrição dos mesmos. Mas, esse
autor ressaltou que esta alternativa pode levar a contagem de classes de projeto e comprometer o
resultado da estimativa. As conclusões desse estudo foram as seguintes: i) o método de PCU teve
baixa variação entre o valor estimado e o real; ii) sugeriu descartar os fatores de ajustes técnicos e
manter os fatores ambientais; iii) contar os casos de uso incluídos e estendidos; e iv) utilizar um
formulário padrão para descrição de casos de uso.

2XVRGRWDPDQKRGRSURMHWRQDHVWLPDWLYDGHHVIRUoRRXSURGXWLYLGDGH
A estimativa de tamanho é essencial no início do projeto, para ajudar o gerente a planejar
o desenvolvimento do produto e estimar esforço, cronograma, recursos, custo e outros fatores
como a qualidade exigida pelo usuário final. (PUTNAM citado por ROSS, s.d; McGARRY et al.,
2001; FENTON; PFLEEGER, 1997; McPHEE, 1999).
O &DSDELOLW\ 0DWXULW\ 0RGHO (CMM), nível 2, área chave “ Planejamento de projeto de
software” , estabelece também que as estimativas de esforço, custo, recursos, cronograma e
qualidade sejam relacionadas às estimativas de tamanho do projeto. O CMM requer ainda que as
estimativas geradas sejam documentadas e usadas no planejamento e controle do projeto
(JOHNSON; BRODMAN, 2000; PAULK, et al., 2000).
Com base na estimativa de tamanho, Karner (1993) propôs uma produtividade de 20
homens/hora por PCU. Mas este fator ainda é um ponto que não existe concordância entre
diversos pesquisadores. Por exemplo, Schneider e Winters (2001) analisando a proposta de
Karner, propuseram verificar novamente os fatores ambientais para contar quantos dos fatores
estão abaixo da escala 3 e quantos estão acima desta escala. Se o total for 2 ou menos, eles
recomendam usar 20 homens/hora por PCU, se o total for 3 ou 4 deve usar 28 homens/ hora por
 28

PCU e se e o total for 5 ou mais, o gerente deve mudar o projeto para que os números possam ser
ajustados, caso contrário, o projeto terá grandes riscos de falhas.
Em uma outra análise, Spaks, citado por Anda et al. (2001), mostrou que o esforço pode
variar entre 15 e 30 homens/hora por PCU.
Em relação ao esforço ou produtividade estimada em APF, o ISBSG possui bases de
dados históricas que indicam a produtividade de horas por PF de acordo com o tipo de linguagem
adotada no desenvolvimento do projeto de software (ISBSG, 2002).
Além das estimativas iniciais de prazo, custos e esforço, Pressman (2002) ressalta que no
decorrer do desenvolvimento do projeto, os PFs estimados, são utilizados para estimar a
produtividade, a qualidade e outros atributos de software como erros por PF; defeitos por PF;
custo por PF e páginas de documentação por PF e PF por homens/mês.
Por outro lado, há autores que destacam que a estimativa de tamanho é uma das atividades
mais difíceis de se realizar em uma organização de desenvolvimento de software, principalmente
quando é realizada no início do projeto (BUTLER; ROSS, 1997, citado por ROSS, s.d ).

&RQVLGHUDo}HVILQDLVGRFDStWXOR
Apesar do PCU ter sido definido com base na APF, estas métricas diferem em vários
aspectos conforme mostra o Quadro10 (FENTON; PFLEEGER, 1997; GARMUS; HERRON,
2000; ANDA et al., 2001; DAMODARAN; WASHINGTON, 2002).
Damodaran e Washington (2002) acreditam que não é difícil para uma organização
desenvolver seus próprios padrões de granularidade dos casos de uso de análise e classificá-los de
acordo com a complexidade. Se a organização tiver padrões para definir casos de uso, é possível
ter uma boa base de dados histórica de estimativas para ser utilizada como fonte de consulta para
estimar novos projetos. Estes autores acreditam que o PCU tem potencial para se tornar um
método maduro e largamente aceito como um método de estimativa.
Embora existam críticas e diferenças em relação ao uso da APF e PCU em projetos de
software OO, estas métricas continuam sendo utilizadas para estimar software OO, mas de forma
independente. A APF além de ser padrão mundial é reconhecida internacionalmente.
Caldiera, et al. (1998) ressaltaram que os conceitos da APF podem ser aplicados como
uma métrica que permite estimar o tamanho com mais precisão a partir da fase final de análise e
projeto de desenvolvimento de software OO, e consideraram que a integração da APF com as
 29

ferramentas de modelagem OO e a automação do processo de contagem podem ajudar a expandir

o uso da APF na indústria de software.

4XDGUR3ULQFLSDLVFDUDFWHUtVWLFDVHGLIHUHQoDVHQWUH$3)H3&8
 => =?8

Métrica mais antiga e mais utilizada no mundo
Padrão internacional desde 2002
Não requer o uso de notação padrão, mas é baseada no
modelo funcional e independente de tecnologia
Largamente discutida na literatura
É suportada pelo IFPUG e diversos grupos nacionais
de usuários e bases históricas de contagens realizadas
Possui regras de contagem padronizadas
È mais utilizada no final das fases de análise e projeto
Visão do usuário
Alto nível de maturidade
É subjetiva e possui diferença entre contadores
Oferece treinamento e certificação
Métrica relativamente nova e pouca utilizada
Ainda não alcançou o nível de padronização e nem foi
incorporada em ferramentas populares;
Baseada no modelo de casos de uso
Tem aumentado o uso e a publicação de estudos na
literatura
O Modelo de casos de uso ainda não possui bons
históricos de produtividade
Não há padrões para descrever casos de uso, há
dúvidas na contagem de casos de uso incluídos e
estendidos e para determinar o nível apropriado de
detalhe para cada transação do caso de uso
Utilizado na fase inicial do projeto
Visão do usuário
Em fase de amadurecimento
É subjetiva e possui diferença entre contadores
Ainda não oferece treinamentos e certificação

O PCU é baseado no Modelo de Casos de Uso, muito utilizado atualmente no mercado

para identificar e documentar os requisitos do software nos termos dos usuários e de maneira
mais completa e articulada que outros métodos (DEKKERS, 1999). Além disso, o PCU
possibilita a estimativa de tamanho na fase inicial do projeto e é fácil de usar.
Alguns autores sugeriram o uso combinado dessas métricas, como Arnold e Pedross
(1998), Longstreet (2000), Schneider e Winters (2001), Anda et al. (2001) e Ribu, (2001). Estes
autores propuseram utilizar o PCU juntamente com a APF ou realizar a contagem em grupo para
evitar desvios e obter um resultado mais próximo da realidade. No entanto, a sugestão foi para
trabalhos futuros, já que estes autores não realizaram esta pesquisa.
 30

McGarry et al. (2001) também destacam que a confiança nas estimativas aumenta quando
mais de uma forma de estimar é utilizada e, à medida que se obtém mais informações do domínio
do software durante o processo de desenvolvimento do projeto, as estimativas serão melhores.
Devido a isto, estes autores recomendam realizar novas estimativas através de modelos
paramétricos ou prever a estimativa necessária, para completar o projeto com base no
cronograma e no orçamento utilizado no projeto até o momento da contagem.
Este trabalho se propõe, portanto, usar as duas métricas de forma combinada para permitir
o planejamento e acompanhamento da estimativa de tamanho ao longo do desenvolvimento, ou
seja, a gestão da estimativa de tamanho apoiando assim a gestão de projetos. Dessa forma, no
próximo capítulo serão apresentadas as principais características de gestão de projeto de software.
 31

&DStWXOR*HVWmRGHSURMHWRGHVRIWZDUH

,QWURGXomR
O desenvolvimento de projeto de software tem-se tornado mais complexo e tem sido
realizado em ambientes dinâmicos, onde as condições de negócio, as tecnologias e as
necessidades ou requisitos dos usuários mudam constantemente durante o projeto. Como
resultado, a indústria de software tem enfrentado problemas de subestimativas de orçamento,
atrasos no cronograma, dificuldade na medição do progresso do projeto, baixa qualidade do
produto, falta de credibilidade no desempenho de TI e insatisfação do usuário (ABEL-HAMID;
MADNICK (1991), citados por JURISON, 1999).
Alguns destes problemas podem ser confirmados com base no relatório do 6WDQGLVK
*URXS³&KDRV$UHFLSHIRUVXFFHVV´ citado por Murthi (2002), o qual indica que somente 28%
de todos os projetos de software de 2000 estavam dentro do cronograma e orçamento estimados e
apresentaram todas as características planejadas.
Diante desse contexto, torna-se necessário melhorar a gestão de projetos e providenciar
ações gerenciais que possam contribuir para uma gestão mais efetiva e, conseqüentemente
melhorar os índices acima.
Neste capítulo, serão apresentados os principais conceitos e as características relevantes
da gestão de projetos de software, destacando, principalmente, os processos de planejamento e
controle de projeto.

'HILQLomR
Projetos são empreendimentos temporários, com começo e fim bem definidos, e têm
como objetivo criar um produto ou serviço único distinto dos existentes. São planejados,
executados e controlados por pessoas e restringidos por recursos limitados, podendo envolver
uma unidade isolada da organização ou várias organizações através de consórcios e parcerias
(PMBOK, 2000; JOHNSON; BRODMAN, 2000).
O objetivo da gestão de projetos é o atendimento das demandas de clientes internos e
externos, garantindo a satisfação de suas necessidades, mantendo um bom relacionamento e
 32

controlando os recursos, esforços e desempenho do projeto (JURISON, 1999; REEL, 1999;

PMBOK, 2000).
De acordo com Pressman (2002), a gestão de projetos envolve planejamento,
acompanhamento e controle de processos, planos de projetos, pessoas e produtos, requerendo,
segundo o PMBOK (2000), a aplicação de conhecimentos, habilidades, ferramentas e técnicas
para planejar e controlar atividades que visam atender as necessidades dos interessados.
O aumento da complexidade do software tem dificultado o processo de gestão de projetos
e contribuído para a alta taxa de falhas em projetos de desenvolvimento de software (JURISON,
1999; REEL, 1999).
Na tentativa de diminuir as falhas de projetos de software, Reel (1999) destaca alguns
fatores fundamentais para o sucesso da gestão de projetos: i) começar o projeto adequadamente;
ii) manter uma equipe motivada e um ambiente de desenvolvimento pro-ativo; iii) rastrear o
progresso do projeto; iv) tomar decisões inteligentes; e v) institucionalizar a revisão de projetos
para identificar os pontos fortes e fracos após a realização do mesmo.
A seguir serão apresentados os principais processos de gestão de projetos.

3URFHVVRVGHJHVWmRGHSURMHWRV

O PMBOK (2000) recomenda o uso dos seguintes processos para garantir a gestão eficaz
de projetos:
i) LQLFLDomR - obtenção do comportamento da organização para o início do projeto;
ii) SODQHMDPHQWR – definição, refinamento dos objetivos e seleção das alternativas de
ação para alcançar as metas do projeto;
iii) H[HFXomR - coordenação de pessoas e recursos para realizar o plano do projeto;
iv) FRQWUROH- assegura que os objetivos do projeto estão sendo atendidos por meio de
monitoração;
v) HQFHUUDPHQWR - formalização da aceitação do projeto ou do encerramento de
forma organizada.
Os processos acima são denominados de atividades pela NBR ISO/IEC 12.207 (ABNT,
1998) e de fases do processo de desenvolvimento por Jurison (1999). Estes processos são
interligados pelos produtos gerados em cada um deles. Cada processo ou fase do projeto, é
 33

marcado pela conclusão de um ou mais produtos, pela revisão dos principais subprodutos e pela
avaliação de desempenho visando à continuação adequada do projeto.
Os processos de planejamento e de controle de projeto devem ser vistos como essenciais
na gestão de projetos de software e, por esta razão, as principais características desses processos
serão apresentadas a seguir. 

3ODQHMDPHQWRGHSURMHWRGHVRIWZDUH
O objetivo do planejamento de projeto de software é “ estabelecer planos razoáveis para
desenvolver e gerenciar o projeto” (PAULK et al, 2000).
O planejamento envolve o desenvolvimento de estimativas do projeto a ser executado; o
estabelecimento de compromissos necessários; a definição do plano; a especificação de metas e
objetivos, a elaboração de estratégias, políticas, procedimentos e regras a serem adotadas pelo
projeto. O planejamento, geralmente, é realizado com base nas informações dos clientes, da
equipe técnica, nas métricas coletadas em projetos anteriores e nas estimativas iniciais do projeto
(THAYER, 1997; WEIHRICH, 1997 citados por FARIAS, 2002; PAULK et al, 2000).
Alguns autores defendem a idéia da elaboração do plano do projeto de maneira aberta e
colaborativa por ser mais precisa e permitir a análise dos níveis de complexidade e dos riscos do
projeto, principalmente os riscos relacionados aos requisitos, à tecnologia, aos recursos, às
habilidades técnicas, à integração, ao cronograma, à manutenção e à melhoria do projeto.
(PRESSMAN, 2002; MURTHI, 2002; PITTMAN, 1993).
Para fazer um bom planejamento, o PMBOK (2000) recomenda a execução de alguns
processos essenciais e facilitadores.
Os processos essenciais são:
i) planejamento e detalhamento do escopo;
ii) seqüenciamento das atividades;
iii) estimativa de duração das atividades;
iv) desenvolvimento do cronograma;
v) planejamento dos recursos;
vi) estimativa dos custos;
vii) desenvolvimento do plano do projeto.
Os processos facilitadores são:
 34

i) planejamento da qualidade;
ii) planejamento organizacional;
iii) montagem da equipe;
iv) planejamento das comunicações;
v) identificação, quantificação e desenvolvimento de respostas aos riscos;
vi) planejamento e preparação das aquisições.
Pressman, (2002) e Jurison (1999) reforçam a utilização desses processos ao destacarem
as características mais importantes do planejamento: i) definição dos objetivos e requisitos; ii)
realização das estimativas de tamanho; iii) definição do cronograma, custo e orçamento; iv) o
impacto do negócio, o perfil do cliente, a definição do processo de desenvolvimento e do
ambiente tecnológico; v) a experiência da equipe; e vi) a identificação dos riscos. Estes autores
ressaltam ainda que, se estas características não forem executadas adequadamente podem
ameaçar o plano do projeto
O CMM – nível 2 também propõe atividades para a realização do planejamento do projeto
tais como (PAULK et al, 2000):
i) elaborar a proposta do projeto com a participação do grupo de engenheiros de
software;
ii) começar o planejamento do projeto no estágio inicial do projeto;
iii) revisar os planos do projeto com a participação do grupo de engenheiros de
software e outros grupos envolvidos durante todo o planejamento;
iv) rever os compromissos do projeto realizados por grupos externos de acordo com
os procedimentos documentados;
v) identificar ou definir o processo de desenvolvimento do software a ser utilizado no
projeto;
vi) desenvolver o plano do projeto de software de acordo com os procedimentos
documentados;
vii) documentar o plano do projeto;
viii) identificar os produtos de trabalho do software necessários para manter o controle
do projeto;
ix) realizar ou atualizar as estimativas de tamanho do software;
x) estimar o esforço e os custos do projeto de software;
 35

xi) estimar os recursos computacionais críticos;

xii) derivar o cronograma do projeto;
xiii) identificar os riscos associados ao custo, aos recursos, ao cronograma e aos
aspectos técnicos do projeto;
xiv) preparar ferramentas de suporte e outras facilidades para a construção do software;
xv) registrar os dados do planejamento do software.
Algumas destas atividades são semelhantes aos processos de planejamento propostos
pelo PMBOK (2000) como a realização de estimativas de tamanho, custos e recursos.
O principal produto do processo de planejamento é o plano do projeto. Esse plano deve
ser formal e composto de outros planos tais como: o plano de iterações; plano de testes; plano de
gestão de configuração; plano de riscos; plano de documentação, cronograma e o processo de
desenvolvimento específico a ser usado no desenvolvimento do software. O plano de
desenvolvimento deve ser refinado, corrigido e melhorado durante todo o processo de
desenvolvimento para manter o projeto alinhado a esse processo. Com base no plano do projeto,
o gerente inicia a execução e o controle do projeto até a geração do produto final e o
encerramento do mesmo (JURISON, 1999).

&RQWUROHGHSURMHWRGHVRIWZDUH
O objetivo do controle e rastreamento do projeto é “ prover visibilidade adequada do
progresso atual do projeto, para que os gerentes possam providenciar ações corretivas quando o
desempenho do mesmo se desvia significativamente do plano elaborado” (PAULK, et al., 2000).
Segundo o CMM – nível 2, a gestão e o controle do projeto implicam em conhecer a
versão do produto do trabalho em uso num determinado tempo (passado ou presente) e controlar
as mudanças realizadas (PAULK, et al., 2000).
O controle do plano do projeto gera informações e mecanismos necessários para os
gerentes e a equipe do projeto para avaliação e monitoramento do progresso do desenvolvimento
do projeto (MURTHI, 2002; ABDEL-HAMID; MADNICK, 1993, citados por JURISON, 1999).
As informações de interesse dos gerentes geralmente estão relacionadas a custo, a produtividade
da equipe, a qualidade do código e do processo e a satisfação do cliente em relação ao produto. Já
a equipe de desenvolvimento está preocupada com informações relacionadas aos requisitos, às
 36

falhas encontradas, ao atendimento dos objetivos do produto e do processo e aos fatos que
poderão ocorrer no futuro (McGARRY et al., 2001).
McGarry et al.(2001) ressalta ainda, que as decisões do gerente do projeto durante a fase
de controle se baseiam em três tipos de análise, que provêem informação de suporte a decisão:
estimativas de tamanho, custos e prazos; análise de viabilidade; e análise de desempenho. Estas
atividades são usualmente executadas iterativamente durante todo o processo de desenvolvimento
do projeto.
As estimativas, que são afetadas por variáveis humanas, técnicas, ambientais e políticas,
devem ser ajustadas com base em informações e artefatos gerados ao longo do desenvolvimento
do projeto e de acordo com a capacidade, experiência e nível de habilidades da equipe
(McGARRY et al., 2001; JURISON, 1999).
A análise de viabilidade determina se o plano do projeto é possível de se realizar através
da análise de dados históricos, experiência da equipe e consistência do plano. A omissão de
detalhes do projeto pode ter impacto no sucesso do mesmo. Portanto, a primeira atividade para
checar a viabilidade do plano é verificar se ele está completo, suficientemente detalhado e se há
consistência entre a estimativa de tamanho com o esforço planejado e as atividades definidas no
cronograma. As seguintes questões devem ser consideradas ao se fazer a análise de viabilidade
dos planos: i) se as atividades importantes, os feriados e férias dos membros da equipe foram
considerados nos planos; ii) se as atividades sobrepostas são possíveis de serem executadas; e iii)
se os objetivos de complexidade e densidade de defeitos estão dentro do contexto do projeto
(McGARRY et al. 2001).
Caso as atividades planejadas no cronograma sejam difíceis de cumprir devido às datas
impostas pelo cliente ou falhas no planejamento, o gerente deve tomar algumas decisões tais
como (PRESSMAN, 2002; PMBOK, 2000; JURISON, 1999; McGARRY et al., 2001):
i) reunir-se com o cliente, apresentar a estimativa detalhada em relação ao esforço e
à duração estimada para o projeto e tentar negociar novos prazos;
ii) definir uma estratégia de desenvolvimento incremental que entregue a
funcionalidade crítica na data prevista e adie as funções restantes;
iii) negociar o aumento do orçamento e contratar técnicos mais experientes;
iv) utilizar componentes adquiridos ou reusar componentes já existentes.
 37

A análise de desempenho do projeto deve ser realizada regularmente para identificar as

variações do plano e implementar ações corretivas antecipando os futuros problemas
(McGARRY et al., 2001). A identificação do aumento do tamanho não planejado pode ser usada
para subsidiar à tomada de decisão, fazer ajustes nos recursos e melhorar o desempenho do
projeto. Outras ações de ajustes como estender o cronograma para manter a qualidade do projeto,
adicionar mais pessoas na equipe do projeto para manter o cronograma, excluir funções para
controlar custos, mudar o processo de desenvolvimento e re-alocar recursos e orçamento para
suportar as atividades chave, podem envolver os gerentes superiores e clientes interessados.
O cronograma aprovado no processo de planejamento deve ser controlado durante todo o
processo de desenvolvimento para evitar atrasos na execução das atividades planejadas. No
entanto, em caso de atraso, Pressman, (2002); PMBOK, (2000); Jurison, (1999) recomendam as
seguintes ações:
i) revisão do planejamento do projeto e identificação dos desvios no cronograma;
ii) inclusão de técnicos ou redistribuição da equipe do projeto;
iii) revisão e priorização das funções do software, deixando as menos importantes
para futuras versões;
iv) revisão do cronograma buscando alcançar o próximo marco do projeto na data
prevista;
v) controle da comunicação entre os membros do projeto;
vi) realização de ajustes no plano e documentação das ações corretivas para
contemplar as alterações de tempo e custo;
vii) modificação da seqüência das atividades e analise das alternativas de respostas aos
riscos;
viii) verificação se as atualizações do cronograma requerem ajustes em outros aspectos
do plano geral do projeto;
ix) registro dos desvios do cronograma.
Caso não haja possibilidade de recuperação do atraso, o gerente deve rever o cronograma
como um todo e renegociar com as partes envolvidas.
Se o cronograma tiver dentro do prazo, o gerente tem que continuar controlando o projeto
para evitar possíveis desvios ou atraso na entrega do produto final. Neste caso, o gerente deve
realizar as seguintes ações (PRESSMAN, 2002; PMBOK, 2000; JURISON, 1999):
 38

i) continuar as análises de desempenho dos relatórios do projeto para identificação

de riscos e antecipação de problemas futuros;
ii) controlar a produtividade da equipe e da rotatividade de pessoal;
iii) identificar possíveis mudanças de legislação, substituição de tecnologia e erro ou
omissão no detalhamento do escopo.
Para facilitar o controle e a análise de desempenho do projeto durante o seu
desenvolvimento, o PMBOK (2000) propõe o uso dos seguintes processos:
i) controle geral de mudanças;
ii) controle de mudanças de escopo;
iii) controle de cronograma;
iv) controle de custos;
v) controle de qualidade;
vi) relato de desempenho;
vii) controle de respostas aos riscos.
Estes processos gerenciam as principais dimensões do projeto citadas por Murthi (2002)
como escopo (requisitos); recursos (pessoas, equipamentos e dinheiro); tempo e riscos, através
das diversas áreas de conhecimento propostas também pelo PMBOK (2000):
i) *HUrQFLDGD,QWHJUDomR - descreve os processos necessários para assegurar que
os diversos elementos do projeto sejam adequadamente coordenados. Essa
gerência compõe-se do desenvolvimento e execução do plano do projeto e controle
geral de mudanças.
ii) *HUrQFLD GR (VFRSR  descreve os processos necessários para assegurar que o
projeto contempla todo, e nada mais que, o trabalho requerido, para completar o
projeto com sucesso. Essa gerência é composta pela iniciação do projeto e pelo
planejamento, detalhamento, verificação e controle de mudanças do escopo.
iii) *HUrQFLD GR 7HPSR - descreve os processos necessários para assegurar que o
projeto termine dentro do prazo previsto. É composta pela definição,
seqüenciamento e estimativa da duração das atividades, desenvolvimento e
controle do cronograma.
 39

iv) *HUrQFLD GR &XVWR  descreve os processos necessários para assegurar que o
projeto seja completado dentro do orçamento previsto. É composta pelo
planejamento dos recursos e pela estimativa, pelo orçamento e controle dos custos.
v) *HUrQFLDGD4XDOLGDGH- descreve os processos necessários para assegurar que as
necessidades que originaram o desenvolvimento do projeto serão satisfeitas. É
composta pelo planejamento, garantia e controle da qualidade.
vi) *HUrQFLDGRV5HFXUVRV+XPDQRVGR3URMHWR - descreve os processos necessários
para proporcionar a melhor utilização das pessoas envolvidas no projeto. É
composta pelo planejamento organizacional, montagem e desenvolvimento da
equipe.
vii) *HUrQFLDGDV&RPXQLFDo}HVGR3URMHWR - descreve os processos necessários para
assegurar que a geração, captura, distribuição, armazenamento e apresentação das
informações do projeto sejam feitas de forma adequada e no tempo certo. É
composta pelo planejamento, distribuição, relato de desempenho e encerramento
administrativo.
viii) *HUrQFLD GRV 5LVFRV GR 3URMHWR - descreve os processos que dizem respeito à
identificação, análise e resposta a riscos do projeto. Ela é composta pela
identificação, quantificação, qualificação, desenvolvimento e controle das
respostas aos riscos.
ix) *HUrQFLD GDV $TXLVLo}HV GR 3URMHWR - descreve os processos necessários para a
aquisição de recursos e serviços fora da organização que desenvolve o projeto.
Esta gerência é composta pelo planejamento e pela preparação das aquisições,
obtenção de propostas, seleção de fornecedores, administração e encerramento de
contratos.
Todas as áreas de conhecimento citadas acima devem ser seguidas para garantir uma
gestão adequada de projetos. No entanto, as gerências de tempo e custo dependem de estimativas
iniciais para assegurar que o projeto termine dentro do prazo e do orçamento previstos. As
estimativas de tempo definidas no início do projeto são determinantes para planejar os recursos,
prever o custo e elaborar o orçamento do projeto.
Sendo assim, no contexto deste trabalho, a gerência de tempo tem fundamental
importância, porque o prazo ou tempo de desenvolvimento do projeto definido através do
 40

cronograma, com base nas estimativas iniciais, deverá ser gerenciado e ajustado à medida que
novas estimativas de tamanho forem realizadas durante o processo de desenvolvimento do
projeto. E, sempre que as estimativas de tamanho forem revistas, outras estimativas como as de
tempo ou prazo, esforço e custos dos recursos necessários à implementação das atividades
definidas no cronograma do projeto também devem ser revistas.
O controle do cronograma e da duração das atividades propostas pela área de
conhecimento “ gerência de tempo” (PMBOK, 2000) e pela NBR ISO/IEC 10.006 (ABNT, 2000),
deve ser realizado durante as atividades de planejamento; execução e controle e revisão e
avaliação do projeto conforme proposto pela NBR ISO/IEC 12.207 (ABNT, 1998) e apresentado
na ISO/IEC DTR 16326 (ISO, 1999).
Além dos processos de controle e das áreas de conhecimento indicadas pelo PMBOK
(2000), o CMM também cita algumas atividades que devem ser executadas pelo gerente para
rastrear e controlar o projeto (PAULK, 2000):
i) rastrear as atividades do projeto de software e o status da comunicação com base
no plano de desenvolvimento do projeto;
ii) revisar o plano de desenvolvimento do projeto de acordo com os procedimentos
documentados;
iii) revisar os compromissos e mudanças realizadas por grupos externos de acordo
com os procedimentos documentados;
iv) comunicar as mudanças aprovadas nos compromissos que afetam o projeto aos
membros da equipe e outros grupos relacionados;
v) rastrear as estimativas de tamanho, esforço, custo e de recursos computacionais
críticos do projeto e tomar ações corretivas caso necessário;
vi) rastrear o cronograma do projeto e tomar ações corretivas caso necessário;
vii) rastrear as atividades técnicas de construção do software e tomar ações corretivas
caso necessário;
viii) rastrear os riscos do software associados ao custo, recursos, cronograma e aspectos
técnicos e tomar ações corretivas caso necessário;
ix) documentar os dados atuais de estimativas e re-planejamento do projeto;
x) realizar entrevistas de revisões periódicas com a equipe do projeto para rastrear o
plano, o progresso técnico e o desempenho do projeto;
 41

xi) realizar revisões formais para verificar se os compromissos e resultados do projeto

estão sendo conduzidos conforme os procedimentos documentados.
O desempenho do projeto pode ser afetado como já destacados anteriormente por riscos,
eventos e novas situações que surgem durante a execução do mesmo (MURTHI, 2002). Segundo
o PMBOK (2000) e Pressman (2002), os principais riscos estão relacionados aos problemas
técnicos e de negócio que, geralmente, ameaçam a qualidade e a pontualidade do software.
Os riscos técnicos, citados pelo PMBOK (2000) e Jurison, (1999) são: falhas de projeto,
omissões e interpretações errôneas de requisitos; problemas de implementação; de interface; de
verificação; de manutenção; de ambigüidade nas especificações e incerteza técnica;
obsolescência técnica; entrega atrasada de componente chave e uso de tecnologia de “ ponta” .
Os riscos de negócio podem estar relacionados à construção de um produto inadequado
por exemplo: produto excelente mas sem demanda (risco de mercado); produto que não se
encaixa na estratégia de negócio da empresa (risco estratégico) e que a equipe de vendas não sabe
como vender e mudanças no mercado ou nas ações governamentais. Outros riscos de negócio
podem ser gerenciais como a perda de apoio da gerência superior devido à mudança de enfoque,
de pessoal (pessoas com habilidades únicas, difíceis de serem substituídas) ou de orçamento. Para
atenuar os riscos, torna-se necessário à elaboração de um plano de contingência com a respectiva
documentação dos procedimentos (PRESSMAN, 2002; PMBOK, 2000 JURISON, 1999 e
MURTHI, 2002).
Ainda em relação a riscos de projetos, foi realizado um estudo por Farias (2002) para
identificar os fatos causadores de riscos encontrados em projetos de software. Os fatos que
causam atrasos no cronograma identificados nesse estudo foram: i) equipe de desenvolvimento
indisponível; ii) projeto com alto grau de inovação; iii) prazos e custos estabelecidos
arbitrariamente; iv) método de estimativa de tamanho inadequado; v) gerência inexperiente; vi)
equipe de desenvolvimento inexperiente em engenharia de software, nos métodos e ferramentas
utilizadas e no domínio da aplicação; vii) processo de desenvolvimento inadequado; viii)
levantamento ou acompanhamento de requisitos com pessoas inexperientes; ix) alto grau de
competição na empresa do cliente; x) falta de comprometimento do usuário/cliente; xi)
orçamento insuficiente; xii) requisitos complexos; xiii) hardware e/ou software necessários não
disponíveis no momento definido; xiv) dependência de produtos ou serviços externos que afetam
o produto, o orçamento, o cronograma ou a continuidade do projeto; xv) mudanças de requisitos
 42

que não foram refletidas em mudanças de cronograma; xvi) falta de identificação dos riscos
previsíveis e imprevisíveis no início do projeto; xvii) falta de identificação das dificuldades
técnicas e humanas no início do projeto e xviii) falta de comunicação entre os membros da equipe
de projetos.
Um outro ponto relevante em relação à gestão de projetos de software está relacionado à
capacidade e as habilidades do gerente. Para gerenciar adequadamente um projeto conforme os
processos e as atividades apresentadas nesta seção, é necessário que o gerente de projeto tenha
habilidades e conhecimentos específicos como liderança, influência na organização, capacidade
de negociação, de solucionar problemas e de comunicação (PMBOK, 2000; THOMSETT, 2002 e
A ROLE-BASED..., 2003).

*HVWmRGHSURMHWRVGHVRIWZDUHGHDFRUGRFRPDVQRUPDVH
A NBR ISO/IEC 10006 (ABNT, 2000) fornece diretrizes para a obtenção da qualidade na
gestão de projetos. Essas diretrizes utilizam processos de gestão de projetos que são semelhantes
às áreas de conhecimento proposta pelo PMBOK (2000). Esses processos são agrupados em:
i) HVWUDWpJLFR – é um processo que organiza e gerencia a realização dos outros
processos do projeto;
ii) JHVWmR GH LQWHUGHSHQGrQFLDV HQWUH RV SURFHVVRV – envolve o gerenciamento
global da interdependência entre os processos do projeto. Os processos de
gerenciamento são os de iniciação do projeto e desenvolvimento do plano do
projeto, gerenciamento das interações, gerenciamento de alterações e configuração
e encerramento;
iii) HVFRSR – inclui uma descrição do produto do projeto, suas características e como
elas serão medidas ou avaliadas. Os processos relacionados ao escopo são os de
desenvolvimento conceitual, desenvolvimento e controle do escopo e definição e
controle de atividades;
iv) WHPSR – visa determinar as dependências e a duração das atividades, garantindo a
conclusão do projeto no prazo previsto. Consistem dos processos de planejamento
de dependência das atividades, estimativa de duração e desenvolvimento e
controle do cronograma.
 43

v) FXVWR – visa prover e gerenciar os custos do projeto garantindo sua conclusão

dentro do orçamento. Os processos relacionados ao custo são estimativa,
orçamento e controle de custos;
vi) UHFXUVRV - consistem dos processos de planejamento e controle de recursos
vii) SHVVRDO – visa criar um ambiente no qual o pessoal possa contribuir efetiva e
eficientemente para o projeto. Consistem dos processos de definição da estrutura
organizacional do projeto, alocação e desenvolvimento da equipe;
viii) FRPXQLFDomR – visa facilitar o intercâmbio de informações necessárias ao projeto.
Possui os processos de planejamento da comunicação, gerenciamento da
informação e controle da comunicação;
ix) ULVFR – lida com incertezas do projeto e requer uma abordagem estruturada para
minimizar o impacto de eventos negativos e obter vantagem das oportunidades
para melhoria. Os processos relacionados aos riscos são os de identificação e
avaliação de riscos, desenvolvimento de reação aos riscos e controle de riscos;
x) sXSULPHQWRV – tratam do suprimento, aquisição ou fornecimento de produtos
necessários aos projetos. São os seguintes: planejamento e controle de
suprimentos, documentação dos requisitos técnicos, avaliação de fornecedores,
sub contratação e controle de contrato.
Essa norma destaca dois aspectos importantes para alcançar a qualidade na gestão de
projetos: a qualidade do processo de desenvolvimento do projeto e a qualidade do produto. O
alcance da qualidade do processo e do produto em um projeto requer um enfoque sistemático
para assegurar que as necessidades implícitas e explícitas do cliente sejam entendidas e
satisfeitas, que as necessidades de outras partes interessadas sejam avaliadas e que a política de
qualidade da organização seja considerada (ABNT, 2000).
Por outro lado, a NBR ISO/IEC 12.207 (ABNT, 1998) estabelece uma estrutura comum
para os processos de desenvolvimento de software desde a sua concepção até a descontinuidade
do software. Essa estrutura contém processos, atividades e tarefas que podem ser aplicadas
durante a aquisição e o fornecimento, o desenvolvimento, a operação e a manutenção de
software. A Figura 1 mostra os cinco processos fundamentais, os oito processos de apoio e quatro
processos organizacionais.
 44

No escopo deste trabalho, são considerados os processos de desenvolvimento e de

gerência. O processo de desenvolvimento contém as principais atividades e tarefas do
desenvolvedor tais como: implementação do processo, análise de requisitos; projeto da
arquitetura do sistema, projeto do software, codificação e testes, integração, teste de qualificação
do software, instalação, apoio e aceitação do software. O Apêndice C mostra os principais
artefatos gerados em cada atividade ou disciplina de um processo de desenvolvimento OO.

@A
BCDE(E(BE-FHG I J KL5DI MKNE @A
BCDE(E(BEJDOK @?BNB

Aquisição Documentação

Fornecimento Gerência de Configuração

Garantia da Qualidade

Verificação
Operação
Validação

'HVHQYROYLPHQWR Revisão Conjunta

Auditoria
Manutenção

Resolução de Problemas

@A
BCDE(E(BE.B
A
P
K INQK
CNB
I KNE

*HUrQFLD Infra-estrutura Melhoria Treinamento

)LJXUD(VWUXWXUDGD1%5,62,(&(ABNT, 1998)

As atividades do processo de gestão de projetos proposta pela norma 12.207 (ABNT,

1998) estão inseridas dentro do processo de gerência e são as seguintes:
i) LQLFLDomRHGHILQLomRGHHVFRSR – consiste do estabelecimento dos requisitos, e da
viabilidade do processo;
ii) SODQHMDPHQWR– consiste dos planos para a execução do processo;
iii) H[HFXomR H FRQWUROH – consistem da implementação do plano. O gerente deve
monitorar a execução do processo, investigar, analisar e resolver os problemas e
reportar aos interessados o progresso do processo através de relatórios;
 45

iv) UHYLVmR H DYDOLDomR – o gerente deve garantir que o software e os planos sejam
avaliados e verificados para satisfazer os requisitos e atingir os objetivos dos
planos;
v) HQFHUUDPHQWR– determina se o processo está completo, levando em consideração
os critérios especificados no contrato e nos procedimentos da organização. Os
resultados e registros devem ser arquivados.

0DSHDPHQWRGR30%2.H1%5,62,(&SDUDD1%5,62,(&
Os processos de gestão de projetos propostos pelo PMBOK (2000) são implementados
através das áreas de conhecimento de gestão que, por sua vez, constituem-se de outros processos
conforme citado anteriormente e apresentado no Quadro 11, colunas 1 e 2. As próximas cinco
colunas deste Quadro 11 mostram as atividades do processo de gestão proposto pela NBR
ISO/IEC 12.207 (ABNT, 1998) e o cruzamento das mesmas com as áreas de conhecimento e
respectivos processos do PMBOK (2000). Por exemplo, para a área de conhecimento “ gestão de
tempo” , os processos de definição, seqüenciamento das atividades e o de desenvolvimento do
cronograma são desenvolvidos durante a atividade de planejamento e os processos de estimativa
de duração das atividades e controle do cronograma, diretamente relacionados com o escopo
deste trabalho, são realizados durante as atividades de planejamento, execução e controle e
revisão e avaliação da NBR ISO/IEC 12.207 (ABNT, 1998).
O mapeamento da NBR ISO/IEC 10.006 para a NBR ISO/IEC 12.207 é apresentado
através do Quadro 12, no qual, a primeira e segunda colunas mostram os grupos de processos de
gestão de projetos e seus respectivos processos propostos pela NBR ISO/IEC 10.006 e nas
próximas cinco, as atividades da NBR ISO/IEC 12.207 e os cruzamentos com os processos da
NBR ISO/IEC 10006. Os processos relacionados ao tempo como a estimativa de duração das
atividades e o desenvolvimento do cronograma, em destaque na tabela são realizados durante as
atividades de planejamento, enquanto que, o controle do cronograma é feito durante a execução e
o controle e a revisão e avaliação, conforme mostra o Quadro 12.
O Quadro 13 mostra, na primeira coluna, os processos de gestão de projetos mapeados
para os processos da NBR ISO/IEC 10.006 (ABNT, 2000) (coluna dois) e para as áreas de
conhecimento da gestão de projetos do PMBOK (coluna três). Nesse quadro, o processo
relacionado ao tempo da NBR ISO/IEC 10.006 (ABNT, 2000), e a área de gestão de tempo,
 46

(PMBOK, 2000) são realizados durante os seguintes processos de gestão da NBR ISO/IEC
12.207(ABNT, 1998): planejamento; execução e controle; e revisão e avaliação conforme já
apresentados nos quadros anteriores.
4XDGURÈUHDVGHFRQKHFLPHQWRGDJHVWmRGHSURMHWRVGR30%2.;DWLYLGDGHV
GRSURFHVVRGHJHVWmRGD1%5,62,(& (ISO, 1999)

30%2. $WLYLGDGHVGRSURFHVVRGHJHVWmRGD,62,(&
ÈUHDVGH 3URFHVVRVGDViUHDVGH ,QLFLDomRH 3ODQHMDPHQ ([HFXomR 5HYLVmRH (QFHUUD
FRQKHFLPHQWRGD FRQKHFLPHQWRGDJHVWmRGHSURMHWR GHILQLomR WR HFRQWUROH DYDOLDomR PHQWR
JHVWmRGHSURMHWR GRHVFRSR

Gestão da integração Desenvolvimento do plano X X
Execução do plano X X
Controle de mudanças geral X X
Gestão do escopo Iniciação X X
Planejamento do escopo X X
Definição do escopo X X
Verificação do escopo X X X
Controle de mudança do escopo X X X X
 'HILQLomRGHDWLYLGDGHV ; ;   
 6HTHQFLDPHQWRGHDWLYLGDGHV  ;   
*HVWmRGRWHPSR (VWLPDWLYDGHGXUDomRDWLYLGDGHV  ; ; ; 
 'HVHQYROYLPHQWRGRFURQRJUDPD  ;   
 &RQWUROHGRFURQRJUDPD   ; ; 
Gestão de custos Planejamento de recursos X X
Estimativa de custos X X X
Orçamento do custo X
Controle de custos X X
Gestão de qualidade Planejamento da qualidade X X
Garantia da qualidade X X
Controle da qualidade X X
Gestão de recursos Planejamento organizacional X X X
humanos Aquisição de pessoas X X
Desenvolvimento da equipe X X
Gestão de Planejamento da comunicação X X
comunicação Distribuição da informação X
Relatório de desempenho X X
Encerramento administrativo X X
Gestão de riscos Identificação dos riscos X X
Quantificação dos riscos X X
Desenvolvimento de respostas riscos X X X
Controle de respostas aos riscos X X X X
Gestão de Planejamento da aquisição X X
suprimentos Solicitação da aquisição X X
Solicitação X X
Seleção da fonte X X X
Administração de contratos X X
Encerramento de contrato X X
 47

4XDGUR0DSHDPHQWRGRVSURFHVVRVGHJHVWmRGHSURMHWRVGD,62SDUDDV
DWLYLGDGHVGHJHVWmRGHSURFHVVRVGD1%5,62,(&(ISO, 1999)
,62 $WLYLGDGHVGRSURFHVVRGHJHVWmRGD,62,(&
*UXSRVGHSURFHVVRV 3URFHVVRVGHJHVWmRGHSURMHWRV ,QLFLDomRH 3ODQHMD ([HFXomRH 5HYLVmRH (QFHUUD
GHJHVWmRGHSURMHWRV GHILQLomRGR PHQWR FRQWUROH DYDOLDomR PHQWR
 HVFRSR
Processos Iniciação do projeto e plano de X X X
interdependentes desenvolvimento
Gestão da interação X X X
Gestão de mudanças X X X
Encerramento X X
Processos Desenvolvimento conceitual X
relacionados Controle e desenvolvimento do escopo X X X
ao escopo Definição de atividades X
Controle de atividades X X
3URFHVVRV 3ODQHMDPHQWRGHGHSHQGrQFLD  ;  ; 
UHODFLRQDGRV (VWLPDWLYDGXUDomRDWLYLGDGHV  ;   
DRWHPSR 'HVHQYROYLPHQWRGHFURQRJUDPD  ;   
 &RQWUROHGHFURQRJUDPD  ; ; ; 

Processos Estimativa de custos X
relacionados ao Orçamento X
custo Controle de custos X X X
Processos Planejamento de recursos X
relacionados a Controle de recursos X X X
recursos
Processos Definição da estrutura organizacional X
relacionados do projeto
a pessoal
Alocação de pessoal X O
Desenvolvimento da equipe O
Processos Planejamento da comunicação O O
relacionados a Gestão da Informação X X
comunicação Controle da comunicação O O
Processos Identificação dos riscos O X
relacionados Avaliação dos riscos X
Aos riscos Desenvolvimento respostas aos riscos X
Controle dos riscos O O
Processos Controle e planejamento da aquisição O X
relacionados a Documentação de requisitos O X
suprimentos Avaliação de subcontratos O O X
Subcontratação O X X X
Controle de contrato X X
Legenda: X = mapeamento objetivo e O = mapeamento subjetivo (pode haver alguma discordância)



4XDGUR0DSHDPHQWRGD1%5,62,(&SDUDD,62H30%2.
(ISO, 1999)
,62,(&$WLYLGDGHVGR
SURFHVVR
3URFHVVRGH*HVWmR
Iniciação e definição do escopo
Iniciação e definição do escopo
Planejamento
Execução e controle
Revisão e avaliação
Encerramento
48
,621tYHLVGRVSURFHVVRV 30%2.ÈUHDVGH
FRQKHFLPHQWRGDJHVWmRGH
SURMHWRV
Processos de gestão de interdependência Gestão de integração
Processos relacionados ao escopo Gestão de escopo
Processos relacionados a pessoal *HVWmRGHWHPSR
Processos relacionados à comunicação Gestão de custos
Processos relacionados aos riscos Gestão de qualidade
Processos relacionados a suprimentos Gestão de recursos humanos
Gestão de comunicação
Gestão de riscos
Gestão de aquisição
Processos de gestão de interdependência Gestão de integração
Processos relacionados ao escopo Gestão de escopo
3URFHVVRVUHODFLRQDGRVDRWHPSR *HVWmRGHWHPSR
Processos relacionados ao custo Gestão de custos
Processos relacionados aos recursos Gestão de qualidade
Processos relacionados a pessoal Gestão de recursos humanos
Processos de gestão de interdependência Gestão de integração
Processos relacionados a escopo Gestão de escopo
3URFHVVRVUHODFLRQDGRVDWHPSR *HVWmRGHWHPSR
Processos relacionados a custos Gestão de custos
Processos relacionados a recursos Gestão de qualidade
Processos relacionados a comunicação Gestão de recursos humanos
Processos relacionados a riscos Gestão de comunicação
Processos relacionados a suprimento Gestão de riscos
Gestão de aquisição
Processos de gestão de interdependência Gestão de integração
Processos relacionados a escopo Gestão de escopo
3URFHVVRVUHODFLRQDGRVDWHPSR *HVWmRGHWHPSR
Processos relacionados a custos Gestão de custos
Processos relacionados a recursos Gestão de qualidade
Processos relacionados à comunicação Gestão de comunicação
Processos relacionados a riscos Gestão de riscos
Processos relacionados a suprimentos Gestão de aquisição
Processos de gestão de interdependência Gestão de escopo
Gestão de comunicação
Gestão de aquisição
 49


&RQVLGHUDo}HVILQDLVGRFDStWXOR
Este capítulo apresentou os principais conceitos e as características da gestão de projetos
de software, ressaltando os aspectos importantes do planejamento e do controle de projetos de
software de acordo com o PMBOK, CMM - nível 2, as NBR ISO/IEC 10.006 (ABNT, 2000) e
NBR ISO/IEC 12.207 (ABNT, 1998); as principais ações de controle do cronograma; as
habilidades do gerente de projeto e o mapeamento da NBR ISO/IEC 12.207 para a NBR ISO/IEC
10.006 e PMBOK (ISO, 1999).
No próximo capítulo, será apresentada uma proposta de gestão de estimativa de tamanho
de projetos de software orientado a objetos com base nas métricas, modelos, normas e trabalhos
relevantes referenciados neste capítulo e nos anteriores.
 50

&DStWXOR*HVWmRGHHVWLPDWLYDGHWDPDQKRGHSURMHWRGH
VRIWZDUHRULHQWDGRDREMHWRV

,QWURGXomR

Para subsidiar o planejamento e a negociação de prazos, esforço, recursos e custos com o

cliente, as empresas de software normalmente requerem estimativas de tamanho do software a ser
desenvolvido na fase inicial do projeto. Em geral, no entanto, a precisão de estimativas realizadas
no início do projeto não é grande, necessitando ser refinada com base em informações
disponibilizadas durante a implementação do projeto. Assim, existe uma demanda por métricas
que proporcionem maior precisão nas estimativas iniciais de tamanho de software a ser
desenvolvido.
Conforme citado no Capítulo 2, a estimativa de tamanho é importante, porque subsidia o
gerente no planejamento e na previsão de custos, prazos e esforços associados ao
desenvolvimento do projeto, permite estimativas de casos de testes, facilita as negociações
contratuais, além de ser um mecanismo de controle da qualidade e da produtividade da equipe. O
tamanho tem impacto na solução técnica e na gestão do projeto e estimativas imprecisas podem
resultar em fracassos (ROSS, s.d; LONGSTREET, 2002). Dessa forma, uma gerência eficiente
depende de uma visão sempre atualizada do tamanho do projeto.
A APF é uma das métricas de estimativa de tamanho mais sedimentadas no mercado e
que proporciona resultados cada vez mais precisos à medida que artefatos da fase de análise e
projeto são gerados (CALDIERA et al., 1998). Por outro lado, o PCU permite fazer estimativas
no início do projeto com base no modelo de casos de uso, que tem sido muito utilizado no
mercado, por ser mais completo que outros métodos de especificação de requisitos (DEKKERS,
1999).
Para que a estimativa de tamanho seja realizada com maior precisão desde o início do
projeto, este trabalho propõe-se utilizar estas métricas de forma combinada no momento em que
elas são melhores aplicadas nas diversas fases do processo de desenvolvimento, possibilitando,
assim, apoiar a gerencia de projetos.
 51

Este apoio consiste da definição de um processo de gestão de estimativa que deverá ser
utilizado em paralelo aos processos de gestão e desenvolvimento de projetos de software.
Portanto, neste capítulo, serão apresentados o objetivo da gestão de estimativa proposto
neste trabalho, os elementos necessários para realizar esta gestão e, finalmente, o processo de
gestão de estimativa de tamanho de software, relacionando-o com os processos de
desenvolvimento e gestão de projetos de software.

2EMHWLYR
A gestão de estimativa de tamanho proposta neste trabalho tem como objetivo indicar aos
gerentes uma melhor forma de estimar, revisar e recalcular o tamanho do projeto à medida que
novos artefatos estejam disponíveis durante o processo de desenvolvimento do projeto de
software orientado a objetos, de forma a apoiar as decisões gerenciais ao longo da gestão do
projeto.
Para permitir estimar e recalcular o tamanho do software ao longo do projeto, decidiu-se
usar PCU e APF de forma combinada, já que estas métricas têm sido usadas de forma mais
adequada em momentos diferentes do processo de desenvolvimento de software.
Dessa forma, para alcançar este objetivo é necessário realizar as seguintes etapas:
i) a padronização dos procedimentos de contagem da APF e PCU para projetos OO,
pois conforme apresentado no Capítulo 2, há diferentes propostas para adaptar a
APF para OO e algumas sugestões para melhoria do PCU;
ii) a investigação da relação entre as métricas PF e PCU, de forma a permitir o seu
uso combinado;
iii) a identificação das ações gerenciais, para apoiar o gerente na tomada de decisão,
durante o controle do cronograma;
iv) e, finalmente, a definição do processo de gestão de estimativa de tamanho de
projetos de software, que engloba todas as atividades necessárias a esta gestão e os
elementos definidos nos itens anteriores.
 A seguir, será apresentada cada uma destas etapas.
 52

3DGURQL]DomRGRVSURFHGLPHQWRVGHFRQWDJHPGD$3)H3&8SDUD
SURMHWRV22

A estimativa de tamanho em PCU e APF deve ser realizada continuamente no momento

do ciclo de desenvolvimento do projeto de software em que estas métricas são melhores aplicadas
visando alcançar os seguintes benefícios:
i) permitir a comparação dos resultados das estimativas realizadas em momentos
diferentes do projeto;
ii) refinar a estimativa à medida que novas contagens são realizadas em APF;
iii) facilitar a tomada de decisões e evitar riscos futuros com base em estimativas
reais;
iv) fazer as previsões de custo, prazo e produtividade da equipe com maior segurança
no início do desenvolvimento;
v) possibilitar a identificação de falhas na documentação do projeto e melhorias nos
processos.
Para realizar a estimativa em PCU e PF no momento mais adequado ao longo do processo
de desenvolvimento do projeto, é necessário utilizar os procedimentos de contagem propostos por
estas métricas. A APF possui regras de contagem padronizadas pelo IFPUG (2000) enquanto que,
o PCU ainda não alcançou o nível de padronização e a contagem é realizada com base na
proposta inicial de Karner (1993).
Em relação à estimativa de projetos OO ainda há divergências na forma de contagem,
apesar dos vários estudos realizados em relação ao mapeamento dos conceitos da APF para os
conceitos OO. Sendo assim, torna-se necessário padronizar os procedimentos de contagem da
APF e PCU para projetos OO antes de realizar as estimativas.
Dessa forma, para que fosse atendida a condição de uniformidade das métricas utilizadas,
os procedimentos de contagem da APF e PCU foram descritos com base no manual de contagem
(versão 4.1.1) IFPUG (2000) e na proposta de Karner (1993) apresentados no capítulo 2.
Alguns passos dos procedimentos originais de contagem destas métricas, foram
complementados e apresentados a seguir.
Ainda como parte dos procedimentos de contagem foi elaborado um questionário
explicativo sobre as características gerais do sistema (IFPUG, 2000) e dos fatores técnicos e
 53

ambientais propostos por Karner (1993). Este questionário, apresentado no Apêndice A, deve ser
utilizado para identificar o nível de influência desses fatores nos projetos estimados.

3URFHGLPHQWRVGHFRQWDJHPGD$3)
A contagem de PF é realizada em sete passos conforme apresentado no Quadro 14. Todos
esses passos são utilizados em projetos OO conforme apresentados no capítulo 2, seção 2.3.1.1.
No entanto, os passos 2, 3 e 4 foram complementados com base nas propostas de mapeamento
dos conceitos da APF para conceitos orientados a objetos realizados por diversos autores como
IFPUG (2001), IFPUG (2000), Ram; Raju (2000), Garmus; Herron (2000), Uemura; Kusomoto;
Inoue (1999), Caldiera et al. (1998) e Fetcke; Abran; Nguyen (1997).

Estes procedimentos visam facilitar a contagem de PF em projetos OO que geralmente,

possuem características diferentes de projetos orientados a especificação funcional ou a
documentos de requisitos (GARMUS; HERRON, 2000).

4XDGUR3DVVRVGRSURFHVVRGHFRQWDJHPGH3)

i) Determinar o tipo de contagem

LL ,GHQWLILFDURHVFRSRGHFRQWDJHPHDIURQWHLUDGDDSOLFDomR

LLL &RQWDUDV)XQo}HVGHGDGRV

LY &RQWDUDV)XQo}HVWUDQVDFLRQDLV

v) Determinar os PF não ajustados

vi) Determinar os valores dos Fatores de ajuste

vii) Calcular os PF ajustados

 No passoLL,GHQWLILFDURHVFRSRGDFRQWDJHPHDIURQWHLUDGDDSOLFDomR, devem ser

identificadas através do Modelo de casos de uso e dos Diagramas de seqüência11 . O modelo de
casos de uso representa os atores, que estão fora da aplicação e os casos de uso representam a
interação entre o ator e o sistema (APÊNDICE C).

11
O Modelo de casos de uso e os Diagramas de seqüência descrevem o comportamento dinâmico da aplicação (UEMURA;
KUSOMOTO; INOUE, 1999). O Modelo de casos de uso compõe-se de diagramas e da descrição de casos de uso. A descrição
de casos de uso detalha os requisitos (ANDA, 2002). Ver também Apêndice C.
 54

 No passo LLL &RQWDU DV IXQo}HV GH GDGRV deve ser contadas apenas as funções da
aplicação solicitadas pelo usuário. Essas funções de dados consistem dos Arquivos Lógicos
Internos (ALI) e Arquivos de Interface Externa (AIE). No contexto de projetos de
desenvolvimento OO, classe de objetos é considerada arquivo lógico, e métodos, operações ou
serviços são considerados funções transacionais (IFPUG, 1996; WHITMIRE, 1993 e
CALDIERA et al., 1998, citados por RAM; RAJU, 2000 e FETCKE; ABRAN; NGUYEN,
1997). Os elementos chave para contagem de PF em projetos OO são os nomes das classes, seus
atributos e associações com outras classes. Os métodos da classe ajudam a identificar o que o
caso de uso precisa fazer e quais classes serão envolvidas na realização do caso de uso (IFPUG,
2001).
Os ALIs são as classes de objetos criadas e mantidas pela aplicação e os AIEs são as
classes de objetos externas lidas e não atualizadas pela aplicação a ser contada, mas pela
aplicação que a criou (RAM; RAJU, 2000). Estes arquivos são identificados nos diagramas de
classes de análise e projeto12 com base nas seguintes regras (UEMURA; KUSOMOTO; INOUE,
1999):

a. 'HWHUPLQDU R WLSR GH IXQomR GH GDGRV ± selecionar as classes de objetos cujo
estereótipo é do tipo ‘entidade’ 13 como candidatas a arquivos lógicose verificar se tem
operações que mudam atributos de outros objetos ou enviam dados para outros objetos
e atores (FETCKE; ABRAN; NGUYEN, 1997; CALDIERA et al., 1998).
b. -XOJDUDFRPSOH[LGDGHGDVIXQo}HVGHGDGRV - as complexidades dos AIEs e ALIs
são identificadas através do número de itens de dados e do número de registros
lógicos de cada classe. O número de itens de dados é contado através dos atributos da
classe e dos relacionamentos reconhecidos pelo usuário, identificados no diagrama de
classes. Se a classe é derivada de outra, o número de atributos da classe básica
também é contado (RAM; RAJU, 2000). Em projetos orientados a objetos, os registros

12
O diagrama de classes descreve a estrutura do sistema através das classes que consistem de atributos e operações e das relações
entre elas incluindo a generalização e agregação (UEMURA; KUSOMOTO; INOUE, 1999). Ver também Apêndice C.
13
O objeto tipo ‘entidade’ modela informação que existe no sistema por muito tempo. Este tipo de objeto pode ser estruturado
com relacionamentos de herança e agregação. Além deste tipo há outros objetos do tipo controle e interface. Os objetos de
controle modelam a funcionalidade que não é naturalmente amarrada aos outros tipos de objetos. O objeto de controle pode
operar em vários objetos de entidades, executar um processamento e apresentar o resultado ao objeto de interface que modela o
comportamento e a informação relacionada à apresentação do sistema ao usuário (FETCKE; ABRAN; NGUYEN, 1997)
 55

lógicos são também identificados através dos relacionamentos entre as classes do tipo
agregação e herança (generalização e especialização de classes) (APÊNDICE C).
A agregação ocorre quando um objeto faz parte do outro. O objeto agregado é considerado
um subgrupo e, portanto, é um registro lógico do agregador e o objeto agregador é um ALI.
Considerar as seguintes regras para identificar os registros lógicos (FETCKE; ABRAN;
NGUYEN, 1997 e CALDIERA et al., 1998):
a. um objeto tipo entidade, que é parte de um outro objeto, é um registro lógico do objeto
agregado independente do tipo de cardinalidade;
b. se a agregação ocorrer em vários níveis ou seja, o objeto agregado for um agregador ao
mesmo tempo, seus agregados e ele mesmo serão considerados registros lógicos do
agregador maior, que é o ALI identificado primeiramente.
O relacionamento tipo herança não tem representação direta na APF. A hierarquia
completa é considerada um arquivo e cada subclasse é um registro lógico (IFPUG, 2001). Devem-
se considerar as seguintes regras para identificar os registros lógicos neste tipo de relacionamento
(FETCKE; ABRAN; NGUYEN,1997):
a. quando a superclasse for abstrata, é candidata a um registro lógico de cada classe que
herda suas propriedades. Neste caso, as subclasses serão consideradas ALIs e não
subgrupos da superclasse;
b. se a superclasse não for abstrata, as subclasses serão consideradas como agrupamentos
da superclasse e são identificadas como registros lógicos da superclasse;
c. se um registro lógico for considerado como superclasse, toda a sua descendência será
considerada registro lógico do ALI superior.
Além do relacionamento de herança e agregação, a associação também deve ser analisada
no diagrama de classes de objetos. Em geral, a classe tipo associação é considerada um arquivo
lógico. Neste caso, conta os atributos da classe associação e os atributos que são chaves primárias
nas classes associadas como elementos de dados. Quando a associação possui múltiplos valores
ela é considerada um registro lógico porque um grupo inteiro de objetos referenciados é mantido
em um atributo (CALDIERA et al., 1998).
Outras funções requeridas pelo usuário como mensagens de erro e texto de ajuda, também
devem ser contadas (FETCKE; ABRAN; NGUYEN,1997).
 56

De acordo com o número de itens de dados e de registros lógicos referenciados, classifica-

se o ALI e AIE em baixa, média ou alta complexidade, conforme o Quadro 1, apresentado no
Capítulo 2.
No passo (iv) &RQWDU DV IXQo}HV WUDQVDFLRQDLV deve ser observado que as funções
transacionais (Entrada Externa (EE), Consulta Externa (CE) ou Saída Externa (SE)) são
identificadas a partir dos casos de uso, do diagrama de seqüência ou do diagrama de classes. Os
casos de uso são candidatos a transações, que são identificadas através da seqüência de fluxos de
interações, definidas na descrição dos casos de uso e no diagrama de seqüência. Para identificar
as funções transacionais através da descrição de casos de uso, deve observar as seguintes regras
definidas por Fetcke; Abran; Nguyen (1997):
a. selecionar cada caso de uso que tem relacionamento direto com um ator tipo usuário
ou aplicação externa;
b. selecionar cada caso de uso estendido como candidato à transação;
c. decidir se o caso de uso candidato tem uma ou mais transações com base nos
procedimentos de contagem do IFPUG (2000).
Nos diagramas de seqüência, cada mensagem trocada por objetos especificados como
função de dados é candidata a uma função transacional. As funções transacionais compõem-se de
itens (parâmetros ou argumentos) e de arquivos referenciados (geralmente as classes do tipo
entidade).
No diagrama de classes, as funções transacionais são identificadas através dos métodos
das classes (IFPUG, 1996; WHITMIRE, 1993 e CALDIERA et al. 1998, citados por RAM;
RAJU, 2000).
As seguintes regras devem ser observadas para identificar as funções transacionais
(UEMURA; KUSOMOTO; INOUE, 1999; GARMUS D.; HERRON, D., 2000):
a. se um objeto comunica-se com outros objetos através da interface da aplicação e
algum processamento é requerido no final, pode ser considerado funções transacionais
do tipo entrada externa (EE), saídas externa (SE) ou consulta externa (CE)
b. se a mensagem não tem argumento (elementos de dados identificados pelo usuário),
significa que a mesma não troca dados e, portanto, não é considerada uma função
transacional;
 57

c. se um ator envia mensagem com argumentos para uma classe tipo entidade é
considerada uma EE;
d. quando uma ou mais classes tipo ‘entidade’ envia uma mensagem para um ator e
todos os argumentos da mensagem são os mesmos atributos das classes, a transação é
uma CE;
e. quando uma classe tipo entidade envia uma mensagem para um ator e todos os
argumentos da mensagem são atributos derivados (dados que resultam de cálculos,
fórmulas, ou outras operações sobre os dados originais) da classe é uma SE;
De acordo com o número de itens de dados e classes (tipo ‘entidade’ ) referenciadas,
classifica-se a função transacional em baixa, média ou complexa, conforme os Quadros 2, 3 e 4
apresentados no Capítulo 2.
Após realizar a contagem das funções transacionais são determinados os PF não ajustados,
identificados os valores dos fatores de ajuste de acordo com o nível de influência das
características do sistema (com base o questionário apresentado no Apêndice A - questão de 1 a
14) e calculados os PF ajustados conforme procedimentos definidos no Capítulo 2.

3URFHGLPHQWRVGHFRQWDJHPGH3&8
A contagem de PCU é realizada em seis passos, conforme apresentado no Quadro 15.
Todos esses passos são utilizados em projetos OO, conforme apresentados no capítulo 2, seção
2.3.2.1. No entanto, os passos 1 e 2 serão complementados conforme resultados dos estudos
realizados por Schneider (2001), Ribu (2001), Anda., et al. (2001).

4XDGUR3DVVRVGRSURFHVVRGHFRQWDJHPGH3&8

L &RQWDURVDWRUHVHDWULEXLURJUDXGHFRPSOH[LGDGH
ii) &RQWDURVFDVRVGHXVRHDWULEXLURJUDXGHFRPSOH[LGDGH
iii) Somar o total de atores com o total de casos de uso para obter o PCU não ajustado
iv) Determinar a complexidade do fator técnico
v) Determinar a complexidade do fator ambiental
vi) Calcular o PCU ajustado
 58

No passo L &RQWDU RV DWRUHV H DWULEXLU R JUDX GH FRPSOH[LGDGH, pode-se usar a
generalização dos atores, caso 2 ou mais atores tenham muito em comum. Assim, pode ser
considerado um super ator e contá-lo apenas uma vez (ANDA, et al. 2001; RIBU, 2001). Após a
identificação dos atores, utilizar o Quadro 7 apresentado no capítulo 2 para atribuir os respectivos
pesos.

 No passo LL &RQWDU RV FDVRV GH XVR H DWULEXLU R JUDX GH FRPSOH[LGDGH, deve ser
observadas as regras para identificar as transações, já que a complexidade do caso de uso, é
definida com base no número de transações. Entende-se por transação “ um conjunto de
atividades atômicas, as quais são executadas completamente ou não” (SCHNEIDER; WINTERS,
2001). Ribu (2001) sugere as seguintes regras para identificar os casos de uso e respectivas
transações:
a. quando a mesma transação ocorrer em diversos casos de uso, como ex: ORJLQ ou
procedimentos de segurança, a transação deve ser contada apenas uma vez porque a
função é implementada uma vez e reutilizada em outros casos de uso;
b. contar os casos de uso estendidos e incluídos separadamente apenas uma vez e não
como uma transação de cada caso de uso que o utiliza;
c. identificar as classes de análise (não as de projeto) que implementam as funções do
caso de uso para auxiliar na determinação da complexidade do caso de uso. As
classes podem ser identificadas na descrição dos casos de uso, nos diagramas de
seqüência ou no diagrama de classes de análise;
d. comparar as transações (descritas no caso de uso) com as transações do diagrama de
seqüência e com o número de classes de análise utilizadas para implementar o caso de
uso para verificar se a complexidade do caso de uso foi definida corretamente;
e. Quando a documentação não apresentar a descrição dos casos de uso, deve-se utilizar
o diagrama de seqüência para contar as transações (apenas aquelas que indicam o que
fazer e não as que indicam o como fazer) ou as classes que implementam o caso de
uso.
Após identificar as transações, deve-se atribuir o peso de cada caso de uso de acordo com
o Quadro 8, apresentados no Capítulo 2.
Os passos iv e v (determinar a complexidade do fator técnico e ambiental) devem ser
realizados com base no questionário apresentado no Apêndice A.
 59

A seguir será apresentada a etapa 2, que é a investigação da relação entre a APF e PCU.
 
5HODomRHQWUHD$3)H3&8
Os procedimentos de contagem da APF e PCU definidos no capítulo 2 e complementados
nas seções anteriores devem ser utilizados em diversos projetos de software de uma mesma
organização para criar uma base de dados histórica de estimativas e possibilitar, assim, a
investigação da relação entre estas duas métricas.
Como não existe disponibilidade de uma base de dados histórica de estimativas de
projetos OO realizadas através de PCU e APF, no escopo deste trabalho, essas métricas serão
aplicadas em projetos OO da academia e da indústria, visando obter valores reais de PF e PCU
para subsidiar a investigação da existência de relação entre essas métricas.
Através dessa relação, que pode ser definida através de uma equação, o gerente poderá
projetar o número de PF no início do projeto assim que a primeira estimativa de tamanho for
realizada em PCU. O número de PF projetado será posteriormente aferido com o número real de
PF, determinado através de outras contagens que serão realizadas durante o processo de
desenvolvimento do projeto. Dessa forma, o gerente poderá comparar a estimativa inicial com as
realizadas durante o desenvolvimento do projeto, garantir que a medição seja aprimorada
constantemente, providenciar ações gerenciais para ajustar o plano e cronograma do projeto e
permitir um gerenciamento mais eficiente do projeto. Dessa forma, a equação de relação definida
será utilizada para realizar a gestão da estimativa de tamanho durante todo o desenvolvimento, ou
seja, a cada novo artefato produzido, uma medição do tamanho do projeto em PF pode ser
realizada e esta medição pode ser comparada com um valor projetado no início do projeto
baseado na medição em PCU.
Para investigar a existência de relação entre a APF e o PCU, no escopo deste trabalho, os
procedimentos de contagem foram aplicados em dezenove projetos de software orientado a
objetos desenvolvidos na academia e na indústria.
A coleta dos dados foi realizada através da análise dos manuais de documentação dos
projetos de software, disponibilizados pelos gerentes dos projetos de forma impressa e eletrônica.
As características gerais do sistema foram identificadas através do questionário (APÊNDICE A)
enviado por meio eletrônico ou aplicado em forma de entrevista estruturada com os gerentes de
projeto.
 60

As informações coletadas sobre cada projeto foram armazenadas em planilhas Excel e,

posteriormente, analisadas de forma qualitativa, ressaltando os resultados mais importantes.
Com base nos resultados da aplicação das métricas, foram realizados diferentes testes
estatísticos para investigar a existência de relação entre APF e PCU e encontrar a equação que
melhor representasse a relação entre essas métricas.
Essa investigação deve ser realizada no contexto de cada empresa devido às
particularidades do processo e do ambiente de desenvolvimento de projeto de software existente.
Assim, há mais garantia de precisão na equação encontrada.
As principais características dos projetos da academia e da indústria e os respectivos
resultados da aplicação da APF e PCU nesses projetos, serão apresentadas a seguir.
  
$SOLFDomRGDVPpWULFDVQDDFDGHPLD
Os projetos da academia foram desenvolvidos por alunos do curso de Ciência da
Computação da Universidade Católica de Brasília (UCB). A APF e PCU foram aplicadas em 9
projetos, sendo que, 8 foram desenvolvidos como projeto final de conclusão do curso e 1 foi
desenvolvido como um projeto de pesquisa, mas também por alunos em fase final de curso. Esses
projetos possuem características comuns tais como: seguem o mesmo processo de
desenvolvimento de software; utilizam a UML e um formulário padrão para descrição dos casos
de uso; constituem-se de uma equipe pequena e são de baixa complexidade, devido ao curto
prazo que os alunos têm para definir e implementar o projeto. O formulário padrão utilizado para
descrição dos casos de uso foi definido por um grupo de professores da Engenharia de Software
da UCB e contém as seguintes informações: nome do caso de uso, prioridade, atores que
interagem, associação com outros casos de uso, pré-condições, fluxo principal, fluxo alternativos
e pós-condições.
As informações sobre os projetos foram coletadas a partir da documentação
disponibilizada pelos alunos como o documento de contexto, especificação de requisitos,
diagrama de casos de uso, diagrama de classes de negócio, descrição de casos de uso e protótipo
de telas, diagramas de seqüência, diagramas de classes de análise e diagramas de classes de
projetos e/ou modelo de entidade e relacionamento.
A contagem de PCU foi realizada com base no modelo e descrição de casos de uso. A
contagem de PF foi realizada através dos diagramas de classes de negócio, diagramas de
 61

seqüência, diagramas de classes de análise e de projetos, modelo de entidade e relacionamento e

protótipo de telas.

$SOLFDomRGDVPpWULFDVQDLQG~VWULD
Na indústria, as métricas foram aplicadas em três empresas (duas privadas e uma pública).
As empresas privadas têm como principal negócio o desenvolvimento de software para terceiros.
No contexto deste trabalho, essas empresas foram denominadas como Empresa A, B e C.
Foram realizadas duas contagens para cada projeto uma em PCU e outra em PF, seguindo-se os
mesmos procedimentos utilizados para a contagem dos projetos da academia. Ao todo foram
contados dez projetos (em desenvolvimento) da indústria, sendo cinco da Empresa A, dois da
Empresa B e três da Empresa C.
As três empresas desenvolvem software orientados a objetos com base no 5DWLRQDO
8QLILHG3URFHVV (RUP) e na 8QLILHG0RGHOLQJ/DQJXDJH (UML).
As principais características das empresas e dos projetos analisados serão apresentadas
separadamente para cada empresa conforme descrito a seguir.

L (PSUHVD$

A Empresa A é atuante no mercado do setor financeiro, mais especificamente no mercado

de cartões de créditos e no setor de saúde brasileiro. Esta empresa possui uma equipe altamente
capacitada composta de mais de cem analistas e programadores, todos com formação em nível
superior e certificações nas tecnologias mais atuais disponíveis no momento.
Essa empresa tem uma boa penetração no mercado, preocupa-se com a qualidade de seus
produtos e serviços e, principalmente, com a satisfação do cliente. Essa empresa já utiliza o PCU
para estimar o tamanho, esforço e custo de seus projetos e adota outras métricas para medir a
qualidade do processo de desenvolvimento de software e dos produtos gerados.
Todos os projetos são desenvolvidos com base na tecnologia orientada a objetos, no RUP,
UML e respectivas ferramentas como 5DWLRQDO5RVH6RGD etc. Para implementação dos projetos,
são utilizadas as linguagens C #, C, Java e (QWHUSULVH-DYD%HDQV (EJB).
Todas as equipes de projetos de desenvolvimento de software seguem documentos
padrões para definição e documentação do software tais como: documento de visão do projeto,
 62

especificações suplementares, detalhamento de casos de uso, descrição de entidades persistentes

no banco de dados, etc.
No documento de especificações suplementares, são definidos os requisitos de qualidade:
usabilidade, confiabilidade, desempenho, suportabilidade, portabilidade, funções e restrições da
aplicação.
O documento de detalhamento de casos de uso consiste de histórico de alterações (data,
responsável, motivo), orientações para entendimento, descrição, referências, atores, pré-
condições, pós-condições, fluxo de eventos, fluxo alternativos, requisitos especiais, ponto de
extensão, informações complementares (classe, atributos, formato e domínio utilizados pelo caso
de uso) e observações, aprovação do usuário gestor e do diretor executivo da empresa.
O documento de descrição de entidades persistentes no banco de dados lista todas as
entidades, descrição dos atributos (DOLiV, tipo, tamanho), índices, chaves estrangeiras, tipo de
geração, referências e comentários.
Para a contagem de PCU, foram utilizados os modelos de visão de casos de uso. Na
maioria dos projetos dessa empresa, os casos de uso são agrupados em módulos ou subsistemas
que se compõem da especificação dos atores, casos de uso e do modelo de casos do referido
módulo.
Para a contagem de PF utilizou-se a visão lógica que consiste do modelo de análise, do
modelo do projeto e do esquema do banco de dados.
Todos os projetos são desenvolvidos de forma iterativa. Geralmente são definidos todos
os casos de uso na especificação de requisitos e priorizados os que serão analisados, projetados,
implementados, testados e disponibilizados para os usuários nas iterações. Por exemplo, para o
projeto ‘I1’ (Tabela 2), foi realizado o levantamento de requisitos para todos os casos de uso, mas
realizada a análise e o projeto para apenas cinco casos de uso que serão implementados, testados
e disponibilizados para os usuários na primeira iteração. Posteriormente, outros casos de uso
serão analisados, projetados, implementados e disponibilizados em outras iterações, até que todos
os casos de uso tenham sido desenvolvidos. Sendo assim, para não comprometer a estimativa de
PF em relação à estimativa de PCU ou seja, PCUs obtidos através da contagem de todos os casos
de uso e PF obtidos através da contagem de alguns casos de uso (apenas os que foram priorizados
na iteração), decidiu-se contar PCU e PF apenas para os casos de uso priorizados na iteração,
 63

para se obter uma estimativa real do tamanho em PCU e PF do projeto em desenvolvimento na

iteração.

LL (PSUHVD%

A Empresa B é uma autarquia do setor público e tem como principal negócio à

coordenação e distribuição de recursos financeiros da área de educação. Essa empresa possui um
Setor de TI, constituída de aproximadamente 100 profissionais, responsáveis pelo
desenvolvimento de produtos de software necessários à realização do negócio da organização.
O Setor de TI encontra-se atualmente em fase de migração para as tecnologias orientadas
a objetos; a linguagem Java e um novo processo de desenvolvimento de software “ customizado”
a partir do RUP. A maioria dos projetos de software em desenvolvimento tem como principal
objetivo migrar sistemas legados para a nova tecnologia. Essa empresa ainda não utiliza APF ou
PCU para estimar o tamanho de seus projetos de software.
As equipes de projetos de desenvolvimento de software também seguem documentos
padrões para definição e documentação do sistema como o documento de visão do projeto e
descrição de casos de uso.
O documento de visão consiste da definição do propósito, escopo, referências e descrição
do problema e do produto, descrição dos gestores e das respectivas necessidades ou requisitos,
dependências e determinantes de qualidade do produto.
O documento de descrição de casos de uso contém o controle do histórico das alterações,
descrição do caso de uso, fluxos de eventos básicos e alternativos, solicitações especiais, pré-
condições e pontos de extensão. A Empresa B disponibilizou dois projetos para contagem.

LLL (PSUHVD&

A Empresa C atua na área de planejamento da informação, informática, treinamento e

desenvolvimento de sistemas nas modalidades de fábrica de software e RXWVRXUFLQJ com alto
índice de especialização em fabricação de soluções informatizadas.
Essa empresa possui certificação ISO 9001, uma equipe de mais de 1000 profissionais
distribuídos na matriz e em diversos clientes e geralmente, utiliza metodologias e ferramentas, de
acordo com a necessidade de cada projeto.
 64

Os projetos disponibilizados por essa empresa são desenvolvidos com base no RUP, UML
e no Modelo de Entidade e Relacionamento (MER).
Essa empresa não utiliza diagramas de seqüência. As informações sobre as classes
responsáveis pelos casos de uso e respectivos atributos são apresentadas no formulário de
descrição de casos de uso.
O formulário padrão para descrição de casos de uso contém o histórico do documento
(data, versão, descrição e autor), homologação (nome, cargo, data e assinatura), sumário,
objetivo, tipo, atores, cenários, fluxos principal, alternativo e de exceção, pontos de extensão,
pré-condições, pós-condições, entidades de negócio, requisitos não funcionais (desempenho,
conversão de dados, hardware, segurança, restrições de implementação, interface, cópia de
segurança e recuperação), observação, referências e anexos (“ leiaute” de telas).
Essa empresa utiliza a APF e experiências anteriores para fazer a estimativa de tamanho
de seus projetos.
Para os projetos dessa empresa, a contagem de PF foi realizada com base na descrição de
casos de uso, diagrama de classes e MER.

$QiOLVHGRVUHVXOWDGRV
Os principais resultados da aplicação de PCU e PF na academia e indústria podem ser
verificados nas Tabelas 1 e 2. Os projetos foram representados pelas letras ‘A’ de academia e ‘I’
de indústria, seguidos do número seqüencial do projeto. Para a contagem de PCU foram
apresentados os totais de atores e casos de uso, os valores dos fatores de ajustes técnicos e
ambientais, o PCU não ajustados e ajustados. Para PF mostrou-se o número de AIE, ALI, o total
de funções transacionais, o fator de ajuste técnico e os valores de PF não ajustados e ajustados.
Analisando os resultados apresentados na Tabela 1, observou-se que todos os projetos contados
tiveram o número total de PF superior ao número total de PCU. A contagem de PF além de ser
mais detalhada, envolve a contagem de funções de dados (ALI e AIE), que vale no mínimo 7
pontos. Em relação à complexidade dos ALIs, a tendência é sempre ser baixa mesmo que o ALI
tenha vários tipos de relacionamentos, inclusive herança e agregação. Isto ocorre porque a tabela
usada para determinar a complexidade do ALI definida no manual de contagem do IFPUG (2000)
e apresentada no Capítulo 2 (Quadro 1), exige um grande número de itens de dados e registros
lógicos para alcançar média ou alta complexidade.
 65

O projeto “ A7” por exemplo, apesar de ter apenas 23 transações identificadas na

contagem de PF, possui 24 ALIs o que resultou num número de PF superior em mais de 100% ao
número de PCU.
Observou-se também que não são definidos diagramas de seqüência para todas as
transações dos casos de uso. Por exemplo, para os projetos “ A1” , “ A2” e A9” foram definidos um
diagrama de seqüência para cada caso de uso do projeto. Nestes casos, foram contadas as
transações representadas nestes diagramas e as apresentadas na descrição de casos de uso. Na
impossibilidade de identificar claramente as classes e respectivos elementos de dados
referenciados em cada transação (já que estas informações não foram indicadas na descrição dos
casos de uso), as mesmas foram consideradas de baixa complexidade.
O projeto “ A9” era um projeto de pesquisa, que foi posteriormente implantando na UCB
e, devido a isso, tornou-se maior e mais complexo que os outros projetos da academia. Mas, para
fins do estudo da relação, foi considerado um projeto acadêmico por seguir o mesmo processo de
desenvolvimento, a UML, o mesmo formulário padrão para descrever os casos de uso e por ter
sido desenvolvido por alunos em final de curso. Observou-se, ainda, que este projeto teve 57
casos de uso, o que indica que os casos de uso foram bastante específicos e de baixa
complexidade, com apenas uma a duas transações cada um. Nesse caso, a contagem de Casos de
uso pode superestimar o tamanho do software, já que cada Caso de uso vale no mínimo 5 PCUs
quando se tem até 3 transações. Portanto, é de fundamental importância que os desenvolvedores
tenham claro entendimento de como definir e descrever os casos de uso e suas respectivas
transações.
Os resultados da aplicação das métricas nos projetos desenvolvidos pela indústria são
apresentados na Tabela 2. Através dessa tabela, pode-se observar que os resultados da contagem
de PCU e PF para a indústria seguiram a mesma tendência dos resultados apresentados para a
academia, diferenciando apenas no tamanho e na complexidade dos projetos.
Por exemplo, o total de PF foi superior ao total de PCU em todos os projetos da indústria.
Neste caso, a diferença foi ainda maior porque os projetos da indústria são mais complexos
principalmente em relação às funções de dados, ou seja, são definidos muitos ALIs. Além disso,
os projetos são definidos de forma integrada com outros sistemas de informação existentes.
Nesses casos, são contados também os AIE como nos projetos I1 a I5 e I9. De acordo com os
resultados, observou-se que 1 PCU equivale a aproximadamente 3 PFs.
 66

Os projetos “ I6” e “ I7” da Empresa B e os projetos “ I8” , “ I9” e “ I10” da Empresa C

também tiveram a contagem de PF bem maior que PCU devido ao alto número de ALIs definidos
no projeto, apesar da contagem de PF dos projetos da Empresa B serem baseadas na descrição de
casos de uso e nos diagramas de classes e MER ou seja, as transações não foram contadas
através dos diagramas de seqüência porque esses diagramas não são adotados nessa empresa.
Tentou-se identificar as funções transacionais através do diagrama de classes com base
nos métodos das classes para os projetos, que não foram definidos diagramas de seqüência para
todas as transações dos casos de uso. Observou-se que esta não é uma tarefa simples, pois não há
indicação clara de quais classes são responsáveis por cada caso de uso, se as mesmas não forem
indicadas explicitamente na descrição de casos de uso ou no diagrama de seqüência. Além disso,
não há garantia de que todos os métodos são indicados nesse diagrama e que todos os métodos
indicados estejam relacionados à implementação do negócio. Este tipo de contagem pode levar a
valores sub ou super estimados das funções transacionais. Nesse sentido, deve-se analisar esta
forma de contagem com mais cuidado ou adotá-la apenas, quando os métodos das classes forem
claramente descritos, evitando assim, a contagem de métodos de implementação ou criados para
atender requisitos da linguagem de programação.
 67

$&$'(0,$
 3&8 3)

d
a
UVT

TX

Y
SVT
X

Z
YX
TX

\X
T

Y
Y

V`
X

V`
X

Y
RS

V
[

]
W

R
^\
_

R
^ \

]
\
_

V
[

]
\
_

]
W

^ R]
_

^ R]
Y
TX

Y
_X
Y
b`
T
bXY
[
[

WS

_
bVY

cY

VX

Z
b

V
V

V
2 19 0,835 1,01 - 9 19 0,85
Ye

fg

i'hg
gj

e
gk

ek
i kg
k
2 34 0,845 1,175 - 16 34 0,96
gY

le
f

le
m
m

gn
k

g
gk
i j
k
i l
5 36 1,005 0,89 - 6 48 1,07
n
Y

gk
k

le
j
i j

g
le

gn
i g
e
o
5 21 0,89 0,875 - 16 13 0,95
Y
m

e
g

i on

e
k
f

e
j
i mj
h

l
2 14 0,89 0,86 - 7 15 0,95
Y

j
le

o
f

i eok
g
h

i h
8 21 0,94 0,86 - 8 23 1,02
Y
f

en
o

e
e
i gn

e
o

e
i fg
ej
h
6 19 0,815 0,905 - 24 23 0,9
Y

en
e

i o
f
fg

g
f

g
k
i mn
l

l
2 5 0,89 0,86 - 5 10 0,95
j
Y

n
f

lg

n
j

n
i k
f
e
h
h
i
7 57 0,875 1,025 - 31 57 0,88
Y
o

n
n
e

g
i oj
f
f

m
og

n
m
i g
o
f
7DEHOD5HVXOWDGRGDFRQWDJHPGH3&8H3)QRVSURMHWRVGDDFDGHPLD

/HJHQGD
Z
R
\

]
R
Fator de Ajuste Técnico Arquivo de Interface Externa – Consulta Externa
Y Y

cY VbY

Z
]
^ Y ^ W

V
^ b ^

Fator de Ajuste Ambiental Arquivo Lógico Interno Fator de Ajuste Técnico

Y
]

]
^ W
– Pontos de Caso de Uso não – Entrada Externa – Pontos de Função não
Z

Y
R
^ \
_

V
V

^ R]
_
ajustados ajustados
Pontos de Casos de Uso – Saída Externa Pontos de Função Ajustados
Z

^ Y

VX

^ Y
R
^ \

^ R]
Ajustados
 qp qp qp RS
bek b bj rst lb b rst b b bn bg be rst UVT 
o f h m
uv uv uv W
TX
y x w

Y
n l en j l W
g
f f h f SVT
R R ] ]
Z Z Y Y X
^ \ ^ \ ^ Y ^ W
^ Y _

ajustados

Ajustados
Y
Z
YX

g e g e gj le ej TX
m g e o h V
h m h [
R
Z
\ \X
T

Fator de Ajuste Técnico

k k k k k

Fator de Ajuste Ambiental

'
i ke '
i ke '
i ke i j i l i i i '
i ke '
i ke

Pontos de Casos de Uso

k k k n ]
oe oe o Y
f h o h W

– Pontos de Caso de Uso não

3&8

k k k k k k k k k
i l i l i l i j i l i l i l i'ek i i
V ]
VX g e o f Y
V m m m m h h h h Y
cY bVY h h
^ b ^

n R
e k e g n ek g gn e k Z
n e e f n j j f ^\
f h g h
o f f
_
Y

– Saída Externa
– Entrada Externa
e j e n j le gn e
g g l n k R
i gn i i hk i i n i i'e i hj i m Z
i h f gm f
/HJHQGD

Arquivo Lógico Interno

mn g j ^ \
m e me o o
h f m f h h
Y

Arquivo de Interface Externa

] ^ ^ ^ ^ g g e e
R f h ]
bVY \
R R ] ] _
,1'Ò675,$

Z Z Y Y [
^ \ ^ \ ^ Y ^ W Y V`
n n n [ a
^ Y _ e j e gj e e TX X
Ajustados
Y me e cY V
h o f m m h b [
não ajustados

V WS
V
Y ]
n _X \
k e g n VX _
m o m h e oe f Y
Fator de Ajuste Técnico

f o o o h h b` V`
d
Fator de Ajuste Ambiental

V T
Pontos de Casos de Uso

X
– Pontos de Caso de Uso

Z _
bYX
3)

7DEHOD5HVXOWDGRGDFRQWDJHPGH3&8H3)QRVSURMHWRVGDLQG~VWULD

k
'
i ek '
i ek '
i ek '
i ek i j '
i ek '
i ek i'ek i e
' i e
'
n k e ej ]
g g Y
f f f o m W

n n n
n ek ej en
lm f g m n f ^ R]
m o fg hg f
m h m o h h _
Y

n j n
l l k e l e
nm f hn f me R
i j i gk i m i j i n
oj i o i gj i hgk i i hn ^ ]
mk j lm k fek o k
g h m
m f Y
68
 69

(TXDomRGHUHODomRHQWUH3)H3&8
Com o intuito de se utilizar PCU e APF de forma combinada foi realizada uma
investigação, com base nos dados das contagens de PCU e APF apresentados nas Tabelas 1 e 2
para averiguar a existência de relação entre estas duas métricas e a definição de uma equação que
representasse esta relação através da análise estatística. O desenvolvimento de uma equação que
descreva essa relação permitirá a projeção de PF a partir de valores de PCU obtidos na fase
inicial dos projetos. Para realizar a análise estatística, foram definidas as seguintes etapas: i)
planejamento da análise estatística e ii) realização da análise estatística e interpretação dos
resultados.
L 3ODQHMDPHQWRGDDQiOLVHHVWDWtVWLFD

Como citado anteriormente, foram contados 19 projetos, sendo 9 da academia e 10 da

indústria. O objetivo principal dessa contagem era identificar uma relação entre as medidas que
pudesse ser expressa através de uma equação a ser utilizada para realizar a gestão da estimativa
do projeto durante o processo de desenvolvimento do projeto. Dessa forma, o objetivo principal é
avaliar a seguinte hipótese de estudo:
ƒ+LSyWHVHGH(VWXGRExiste uma relação entre PCU e APF resultantes de contagens
em projetos de desenvolvimento de software desenvolvidos na academia e na indústria
e esta relação pode ser representada por uma equação matemática.
No entanto, como os projetos foram desenvolvidos em ambientes diferentes ou seja, na
academia e em três empresas distintas, levantou-se a questão se os resultados das contagens
poderiam ser agrupados ou não. Diante desta questão, decidiu-se fazer a análise estatística dos
dados das contagens de PCU e APF nos projetos da academia e das empresas separadamente e
testar as seguintes hipóteses de estudo:
ƒ+LSyWHVH GH (VWXGR   Não existe diferença entre as equações que representam a
relação entre PCU e APF em projetos de desenvolvimento de software de diferentes
empresas.
ƒ+LSyWHVH GH (VWXGR   Não existe diferença entre as equações que descrevem a
relação entre PCU e APF dos projetos da academia e da indústria.
Estas hipóteses serão testadas através da análise de regressão, que é uma das modalidades
de análise da relação existente entre duas variáveis. Esta ferramenta estatística utiliza a relação
 70

existente entre variáveis quantitativas de maneira que uma variável possa ser estimada a partir da
outra (NETER; WASSERMAN; KUTNER, 1989). Esta relação é expressa por uma equação
matemática e o problema consiste em estabelecer a função matemática que melhor exprima a
relação existente entre as duas variáveis, no caso deste trabalho, PCU e APF.
Na área de engenharia de software, técnicas de regressão vêm sendo bastante empregadas
no estudo de relações entre variáveis. Por exemplo, Caldiera et al. (1998) considerou várias
equações de regressão para descrever a relação entre o seu método de estimativa de tamanho
(OOFP) e o tamanho final da aplicação estimado em linhas de código (LOC). Karner (1993)
tentou encontrar a relação entre PCU e os recursos necessários para concluir o projeto (em
homens/hora). Tichenor (1997) usou a regressão linear para encontrar a relação entre o resultado
da contagem de seu método ()DVWFRXQW) e APF (IFPUG) e entre APF e dias gastos pela equipe
de desenvolvimento em uma amostra de projetos concluídos.

LL 5HDOL]DomRGDDQiOLVHHVWDWtVWLFDHLQWHUSUHWDomRGRVUHVXOWDGRV

7HVWHGD+LSyWHVHGHHVWXGR
A hipótese de estudo 1 é a principal suposição deste trabalho, pois a existência de uma
relaçãoentre PCU e APF é uma condição essencial para que estas duas métricas sejam utilizadas
de forma combinada no processo de gestão de estimativa, através de modelos matemáticos que
descrevam esta relação. O uso de modelos ou equações matemáticas que descrevam a relação
entre PCU e APF permitirá a projeção de PF a partir de contagens de PCU. No presente caso,
foram testadas equações linear e polinomial de 2º grau ou quadrática como descritoras da relação
entre PCU e APF. Estes modelos são representados pelas seguintes equações:
Linear: \ E z E { [
Quadrático: \ E z E { [E| [ð
O termo ³\´ indica a variável dependente, no caso APF e o termo ³[´ representa a
variável independente, no caso, PCU. Nestas equações, E z E { HE| representam respectivamente, o
intercepto14, o coeficiente de efeito linear e o coeficiente de efeito quadrático.
No caso da equação linear, a relação entre as variáveis é representada por uma linha reta
enquanto que no modelo quadrático, uma linha curva representa esse tipo de relação. A

14
Intercepto é a altura na qual a linha de regressão corta o eixo Y (NETER; WASSERMAN; KUTNER, 1989).
 71

verificação da adequação de uma ou outra equação é desenvolvida através de testes estatísticos

que avaliam, dentro de uma margem de erro, hipóteses de nulidade dos coeficientes das equações.
Assim, o teste sobre a adequação da equação linear é feito estabelecendo-se uma hipótese nula
sobre o coeficiente linear (E { ). A aceitação dessa hipótese indicaria que o valor de E { sendo zero,
a equação linear não é adequada para descrever a relação entre PCU e APF. Com relação à
equação quadrática, a hipótese de nulidade a ser testada refere-se ao coeficiente quadrático (E| ).
Assim, se a hipótese nula, de que b2 é zero, for aceita, o coeficiente quadrático deve ser retirado
da equação.
Para ambas equações, a hipótese alternativa é a de que os coeficientes linear e quadrático
são diferentes de zero. A rejeição da hipótese nula com conseqüente aceitação da hipótese
alternativa indica que as equações são adequadas para descrever a relação entre PCU e APF.
Estas hipóteses são propostas da seguinte maneira:
a. Para teste de adequação da equação linear:
Hipótese nula: H0 : b1= 0
Hipótese alternativa Ha : b1
b. Para teste de adequação da equação quadrática:
Hipótese nula: H0 : b2 = 0
Hipótese alternativa Ha : b2 
Estas hipóteses são testadas através de um teste t15. Nesse teste, um valor de t é calculado
pelas formulas:
a. equação linear:W E { VE {  onde E { é o coeficiente linear e VE {  é o desvio padrão16
para esse coeficiente;
b. equação quadrática: W E| VE|  onde E| é o coeficiente quadrático e VE|  é o desvio
padrão para esse coeficiente.
O valor deW calculado é comparado com o valor de Wexistente em tabelas estatísticas17. Se
o W calculado for igual ou menor ao valor de Wda tabela (para o nível de significância e o grau de
liberdade), a hipótese de nulidade é aceita e se oW calculado é maior que o valor W da tabela, essa
hipótese é rejeitada em favor da hipótese alternativa. Nesses testes, existe sempre a possibilidade
15
O teste de ‘t’ , que é baseado na distribuição de 6WXGHQW, é usado para pequenas amostras e tem aplicações em testes de hipóteses
ou de significância para médias e calculo de intervalos de confiança (MARKUS, 1974).
16
O desvio padrão é a raiz quadrada da variância do coeficiente de regressão
17
Tabelas estatísticas são tabelas com valores críticos que servem de comparação com os valores de t calculado, ao nível de
significância estabelecido e com os mesmos graus de liberdade.
 72

de rejeição da hipótese de nulidade quando na realidade ela é verdadeira. A possibilidade desse

erro, que é conhecido como “ Erro tipo I” , deve ser estabelecido pelo analista estatístico, e é
chamada de nível de confiança. Os valores de tabela de W variam em função desses níveis de
confiança. Atualmente, os pacotes de análise estatística ao realizarem testes de W para os
coeficientes de equação de regressão, produzem um valor S18, que indica, para o Wcalculado, qual
o nível de confiança ou probabilidade de incorrer o Erro tipo I. Como exemplo, se for
estabelecido à priori um nível de confiança de 5%, a hipótese nula será rejeitada sempre que o
valor de S calculado pelo pacote estatístico for igual ou menor que 0,05.
No presente estudo, o software 6WDWLVWLFDO $QDO\VLV 6RIWZDUH (SAS) e os modelos de
programação propostos por Freund e Litteli (1991) e Smith e Cody (1991) foram utilizados para
análise de regressão dos dados coletados nos projetos da academia e indústria.
Para os testes da Hipótese 1, as análises de regressão foram realizadas nos dados de
contagem de PCU e PF nos projetos agrupados da seguinte maneira:
a. nove projetos da academia;
b. cinco projetos da Empresa A;
c. cinco projetos das Empresas B+C.
Os projetos da academia foram analisados separadamente porque haviam sido
desenvolvidos seguindo processos e tecnologias diferentes. Além disso, foram desenvolvidos por
alunos em final de curso, sem experiência em desenvolvimento de software.
Os projetos da indústria apesar de basearem no RUP e UML foram separados em dois
grupos de cinco projetos (Empresa A e Empresas B + C). Os projetos da Empresa A foram
analisados separadamente para identificar se havia diferença nas equações encontradas para uma
única empresa, já que para esta empresa haviam sido contados cinco projetos, amostra mínima
para fazer a análise estatística. As contagens dos projetos das Empresas B e C foram agrupadas
visando à obtenção de uma amostra de tamanho suficiente para permitir o estudo da relação entre
as variáveis PCU e PF, já que haviam sido contados apenas 2 e 3 projetos respectivamente da
Empresa B e C e também por verificar que o ambiente, processos e tecnologias utilizadas por elas
eram bastante semelhantes, apesar da empresa B ser uma autarquia pública com 100 profissionais

18
S ou nível de significância indica a probabilidade de ocorrência de erro tipo I, ou seja de rejeitar-se a hipótese de nulidade
quando ela é verdadeira.
 73

e a empresa B ser uma fábrica de software com mais de 1000 profissionais. A partir desse ponto
estas duas empresas passaram a sere consideradas uma única empresa.
Os resultados dos testes realizados são apresentados na Tabela 3. Nesta Tabela, pode-se
observar que para as três situações analisadas (academia, Empresa A e Empresas B + C) os
valores de “ S” do coeficiente quadrático estão acima do nível de confiança de 5% (S!), o
que nos leva a aceitar a hipótese de nulidade (H0 : b2 = 0 ) de que os coeficientes quadráticos são
zero e que, portanto uma equação quadrática não é adequada para descrever a relação entre PF e
PCU observada nas empresas A, B + C e academia.
A mesma tabela mostra que na equação linear, os valores de p para os coeficientes
lineares são menores que 0,05 o que rejeita a hipótese de nulidade (H0 : b1= 0 ) para todos eles.
Assim, a hipótese alternativa (Ha : b1pDFHLWDHFRQFOXL-se que equações lineares são as mais
adequadas para descrever a relação entre PCU e PF em projetos da academia, Empresa A e
Empresa B + C.
7DEHOD9DORUHVGRVQtYHLVGHVLJQLILFkQFLDSREWLGRVSHOR³WHVWHW´QDVHTXDo}HV
GHUHJUHVVmRTXDGUiWLFDHOLQHDU

7HVWHW±QtYHLVGHVLJQLILFkQFLDS
&RHILFLHQWH &RHILFLHQWH
,QWHUFHSWR
OLQHDU TXDGUiWLFR
0RGHORV E}
E~  E ~€
4XDGUiWLFD
Empresa A 0,324 0,954 0,2964
Empresas B e C 0,348 0,036 0,1358
academia 0,514 0,139 0,8600
/LQHDU
Empresa A 0,861  -
Empresas B e C 0,461  -
academia 0,340  -

Nesta Tabela 3, observa-se também que para os interceptos os valores de “ p” são maiores
que 0,05, indicando uma aceitação da hipótese de nulidade (H0 : b0= 0), ou seja de que os
interceptos das equações lineares descrevendo a relação entre PCU e PF em projetos da academia
e industrias é zero.
De fato, ao considerar que PCU e PF são variáveis quantitativas de medida de tamanho de
software, zero é um valor possível para o intercepto de uma equação linear descrevendo à relação
entre as duas variáveis, pois quando PCU for zero, obrigatoriamente, PF também será zero.
 74

Assim, foi considerada que a melhor descrição da relação entre PCU e APF e as
estimativas mais precisas de PF a partir de contagens de PCU são obtidas com uma equação
linear sem interceptos, ou que passe pela origem. Utilizando-se o pacote SAS, foi investigada a
possibilidade de equações lineares sem interceptos para descrever a relação entre PCU e APF.
Na Tabela 4, os baixos valores de S calculados para o coeficiente linear indicam a rejeição da
hipótese de nulidade, o que mostra a adequação das equações lineares sem intercepto para
descrever a relação entre PF e PCU. Comparando com os valores de S para o coeficiente linear
da equação com intercepto que aparecem na Tabela 3, observa-se que os valores de S para esse
mesmo coeficiente das equações sem intercepto são bem menores. Isto indica um melhor ajuste
da equação linear sem intercepto para os dados de contagens de PCU e PF.
Assim, as equações lineares sem intercepto obtidas com a aplicação do SAS e que
descrevem a relação entre PCU e PF nos projetos avaliados são as seguintes:
a. Projetos da academia PF = 1,461 PCU
b. Projetos da Empresa A PF = 2,581 PCU
c. Projetos da Empresas B+C PF = 3,263 PCU

7DEHOD9DORUHVGRVQtYHLVGHVLJQLILFkQFLDSREWLGRVSHOR³WHVWHW´QDVHTXDo}HV
GHUHJUHVVmROLQHDUVHPLQWHUFHSWR
7HVWHW±QtYHLVGHVLJQLILFkQFLDS
&RHILFLHQWH &RHILFLHQWH
,QWHUFHSWR
OLQHDU TXDGUiWLFR
0RGHOR E}
E~  E ~€
/LQHDUVHPLQWHUFHSWR
Empresa A -  -
Empresas B e C -  -
academia - < -

7HVWHGD+LSyWHVHGHHVWXGR
Neste teste, a hipótese verificada é a de que não existe diferença entre as equações que
representam a relação entre PCU e APF em projetos de desenvolvimento de diferentes industrias.
A eventualidade de não existirem diferenças entre essas equações permitirá que as contagens de
PCU e PF realizadas nas três empresas sejam agrupadas. Com isso, um número maior de casos
analisados resultará numa equação que permitirá maior precisão nas estimativas. Neste estudo,
como foram realizadas contagens em cinco projetos da Empresa A, em três projetos da Empresa
 75

B e em dois da Empresa C, na comparação entre as equações das industrias, as contagens dos

projetos avaliados nas Empresas B e C foram agrupadas conforme relatado anteriormente. Assim,
a comparação foi realizada entre a equação que descreve a relação PCU e APF dos projetos das
Empresas B e C (que passaram a serem consideradas uma única empresa) e aquela que descreve a
mesma relação para os projetos da Empresa A.
A comparação entre as equações foi realizada conforme indicado por Neter e Wasserman
(1974) e compõe-se dos seguintes passos:
i) Ajuste do modelo completo ou sem restrições para obtenção da Soma de Quadrado
do Erro do modelo completo – SQE(C)19. O modelo completo consiste no ajuste
de equações separadamente para a relação entre PCU e APF dos projetos da
Empresa A e das Empresas B + C. Como este passo já foi completado
anteriormente no teste da hipótese 1, o SQE do modelo completo será a soma do
valor de SQE obtido na regressão da Empresa A com o valor de SQE obtido na
regressão das Empresas B + C. Esses valores foram fornecidos pelo pacote SAS.
ii) Ajuste do modelo restrito para obtenção da Soma de Quadrado do Erro do modelo
restrito – SQE(R). Neste caso, uma única equação linear foi definida para
representar a relação entre PCU e PF para o agrupamento dos dados de contagem
das Empresas A, B e C, ou seja 10 projetos. Esse ajuste foi realizado pelo pacote
SAS, que forneceu o valor de SQE.
Uma das hipóteses a serem testadas indica que os interceptos e coeficientes lineares das
equações definidas para a empresa A e empresas B + C são iguais. A hipótese alternativa é a de
que interceptos e coeficientes lineares são diferentes. Estas hipóteses podem ser descritas da
seguinte maneira:
a. C1: b0 Empresa A = b0 Empresas B + C e b1 Empresa A = b1 Empresas B + C
b. C2: b0 Empresa A E0 Empresas B + C ou b1 Empresa A E1 Empresas B + C ou
ambos são diferentes.
O teste estatístico para verificar qual das hipóteses acima irá prevalecer é um teste )20.
Nesse teste, um valor de )é calculado pela formula:

19
SQE é o somatório dos desvios entre o valor observado e o valor estimado pelo modelo de regressão elevado ao quadrado
20
O teste ) éutilizado para comparação de variâncias.
 76

 )  64( 5 ± 64( &  64( & Q {  Q|  ±  RQGH Q { é o numero de projetos

contados na Empresa A e Q| é o número de projetos contados nas Empresas B + C.
A aceitação de uma ou outra hipótese é realizada pela comparação do valor de )calculado
pela formula acima com o valor de )encontrado em tabelas estatísticas. O valor de) da tabela é
encontrado, considerando-se um nível de significância e os graus de liberdade do numerador (2) e
do denominador (Q { Q| ±) da formula acima. Se o valor do )calculado for menor ou igual ao
do ) da tabela, concluímos & { ou que não existe diferença entre as equações. Se o valor de )
calculado for maior que F da tabela optamos por &| ou que as equações são diferentes.
A comparação entre as equações definidas para Empresa A e Empresas B + C utilizou
valores gerados pelo pacote estatístico SAS. Os valores foram:
SQE (Empresa A) = 14402 n = 5 (nº de casos estudados)
SQE (Empresas B+C) = 12587 n = 5 (nº de casos estudados)
SQE (Empresas A+B+C) = 51518 n = 10 (nº de casos estudados)
SQE(C) = 14402 + 12587 = 26629
SQE(R) = 51518
Aplicando a formula acima temos um ) calculado com valor de 2,80. O valor de ) da
tabela é de 6,94. Assim, como o valor de ) calculado é menor que o valor de ) da tabela foi
adotado & {  ou seja, não existe diferença entre as equações definidas para representar a relação
entre PCU e PF nas Empresas A e B + C. Considerando que as equações são iguais, é
aconselhável o agrupamento das contagens de PF e PCU, para estabelecimento de uma única
equação para descrição da relação entre as duas variáveis em projetos da indústria (Empresas A +
B + C). A equação estabelecida foi a seguinte: 3) 3&8

7HVWHGD+LSyWHVH
Não existe diferença entre as equações que descrevem a relação entre PCU e PF dos
projetos da academia e da indústria. Seguindo a mesma lógica relatada na hipótese anterior, a
inexistência de diferenças entre as equações geradas para academia e indústria permitirá o
agrupamento de todos os dados de contagens realizados para ajuste de uma só equação que
descreveria a relação entre PCU e PF para projetos da indústria e da Academia.
Nesta comparação as hipóteses são:
a. C1: b0 industria = b0 academia e b1 industria = b1 academia
 77

b. C2: b0 industria  E0 academia ou b1 industria  E1 academia ou ambos são

diferentes.
Seguindo os passos utilizados anteriormente a comparação entre a equações lineares da
industria e academia seria:
SQE (industria) = 51518 n = 10 (nº de casos estudados)
SQE (academia) = 12628 n = 9 (nº de casos estudados)
SQE (indústria + academia) = 270012 n = 19 (nº de casos estudados)
SQE(C) = 51518 + 12628 = 64146
SQE(R) = 270012
Aplicando a formula acima temos um ) calculado com valor de 24,07. O valor de )da
tabela é de 4,54. Assim, como o valor de ) calculado é maior que o valor de F da tabela foi
adotado &| ou seja, existe diferença entre as equações definidas para representar a relação entre
PCU e PF na indústria e na academia.
A Figura 2 mostra a representação gráfica das equações desenvolvidas para academia e
indústria. A reta indica os valores estimados a partir da equação encontrada para a academia
(PF=1,4615 PCU) e para a indústria (PF=2,8905 PCU). O nível de significância S indica a
possibilidade de erro ao aceitar-se que existe uma relação entre as variáveis PCU e PF e que essa
relação é descrita por uma equação linear. No caso, o valor de S é menor que 0,0001. Outra
estatística apresentada nesta Figura é o coeficiente de determinação R². Esse coeficiente indica
quanto da variabilidade existente em PF é explicado com a utilização da variável PCU. Um valor
alto como o encontrado (R² = 0,97) e o baixo nível de significância S indicam o excelente ajuste
das equações definidas.
Os valores de R² inicialmente encontrados para a academia (R² = 0,9697) e para a
indústria (R² = 0,9723) foram arredondados para 0,97. Devido a isso, os valores de R² foram
iguais para as duas equações.
As diferenças entre as equações da academia e indústria podem ser atribuídas ao nível de
complexidade dos projetos desenvolvidos e ao número de casos de uso definidos. Os projetos de
conclusão de curso desenvolvidos na academia não utilizam, na maioria das vezes, AIEs e
possuem um número relativamente baixo de ALIs, o que implica em uma pontuação menor de PF
para estes projetos. Por outro lado, são definidos muitos casos de uso de baixa complexidade
 78

(com apenas 1 ou 2 transações). Isto também contribui para que a contagem de PCU fique
superior e conseqüentemente diminui a diferença entre o total de PCU e PF.
Já os projetos da indústria, além de serem mais complexos em relação ao número de
funções de dados e de funções transacionais, são melhores definidos, ou seja, os números de
casos de uso representam as funções do software de forma mais adequada, o que pode torná-los
menores em número de casos de uso descritos e mais complexos em relação ao número de
transações realizadas.

DFDGHPLD LQG~VWULD
800 800

700 3) 3&8 700 3) 3&8

600 600

500 500
„… 400 „… 400

300 300

200 200
R² = 0,97 R² = 0,97
100 100
p < 0,0001 p < 0,0001
0 0
0 100 200 300 400 0 100 200 300 400
‚ƒ
‚ƒ

)LJXUD5HODomRHQWUH3&8H$3)HPSURMHWRVGDDFDGHPLDHGDLQG~VWULD

É importante ressaltar ainda, que estas equações serviram para mostrar que existe uma
relação entre APF e PCU e que essas métricas podem ser utilizadas de forma combinada. Para
que as equações sejam utilizadas na prática pelas empresas que fizeram parte desta pesquisa e
pela academia recomendamos o refinamento das mesmas através da contagem final dos projetos
utilizados no escopo deste trabalho e a geração de novas equações a serem utilizadas para
projeção de PF de futuros projetos desenvolvidos em ambientes semelhantes.
Para obter maior precisão na equação a ser utilizada para projetar PF, é importante que
cada empresa da indústria encontre a equação de relação entre a APF e PCU através das
contagens de seus próprios projetos, desenvolvidos com base em processos, padrões e tecnologias
específicas ao ambiente de desenvolvimento de software da empresa.
 79

A seguir será apresentado o estudo realizado na terceira etapa da pesquisa ou seja, a

identificação das ações gerenciais a serem utilizadas pelo gerente do projeto durante o processo
de gestão de estimativa de tamanho.

,GHQWLILFDomRGDVDo}HVJHUHQFLDLVDVHUHPWRPDGDVSHORVJHUHQWHV
A partir da gestão de estimativas associada à gerência de projetos, o gerente terá
informações mais precisas sobre o projeto e isso possibilitará o rastreamento do cronograma e o
controle das atividades planejadas e realizadas. Conhecendo o VWDWXV do projeto, o gerente poderá
tomar decisões de ajustes no plano e no cronograma com base em ações gerenciais sendo, dessa
forma, fornecido o apoio definido no objetivo do processo de gestão de estimativa de tamanho
descrito na seção 4.2.
No entanto, para facilitar a tomada de decisão nesse momento, é necessário identificar
quais ações são mais relevantes e poderão subsidiar os gerentes de projeto na execução do
processo de gestão de estimativa.
Para identificar estas ações, foi realizada uma pesquisa de campo, com gerentes de
projetos de software, baseada em ações gerenciais, disponíveis na literatura e apresentadas no
capítulo 3.
Para realizar esta pesquisaforam definidas três etapas:definição, a qual foi formalizado o
objetivo do estudo, e coleta e análise de dados, na qual foi feita a pesquisa de campo
propriamente dita e a análise dos resultados. Estas etapas serão descritas a seguir.
L 'HILQLomR

O objetivo do estudo foi definido com base na estrutura da técnica *RDO 4XHVWLRQ
0HFWULFV (GQM), conforme proposto por Wohlin et al.(2000) e Solingen e Berghout, (1999)
(QUADRO 16).
4XDGUR2EMHWLYRGH(VWXGR

3URSyVLWR: Identificar
2EMHWRum conjunto de ações gerenciais
3RQWRGHYLVWD: gerentes de projeto de software
1RFRQWH[WRGHgestão de estimativa de tamanho de projetos de software
 80

Considerando este objetivo e o contexto da gestão de estimativa que é permitir ao gerente

de projeto uma forma de estimar, revisar e recalcular o tamanho do projeto para que possa
realizar uma melhor gestão do tempo ou prazo de desenvolvimento do projeto (considerando a
medida de tamanho), foi analisado então quais os momentos em que o gerente de projeto precisa
tomar ações gerenciais relacionadas ao tempo ou prazo do mesmo.
Um primeiro momento é logo no início do projeto quando o gerente faz uma primeira
estimativa para definir prazos para o cliente. Com a estimativa de tamanho inicial, o gerente pode
perceber que o prazo que o cliente deseja receber o produto é impraticável diante do tamanho do
projeto a ser desenvolvido. Dessa forma, para alcançar o objetivo definido no Quadro 16, é
necessário identificar TXDLVDo}HVGHYHPVHUWRPDGDVTXDQGRRFURQRJUDPDGRSURMHWRp
LPSUDWLFiYHO. Foram, então, listadas diferentes ações baseadas nas recomendações de Jurison
(1999); Pressman (2002), PMBOK (2000), CMM, nível 2 (PAULK, 2000) e McGARRY et al.
(2001) apresentadas no capítulo 3. Assim, através da pesquisa de campo, foi solicitado aos
gerentes de projeto a indicação das ações “ mais recomendadas” , “ recomendadas” , “ pouco
recomendadas” ou “ não recomendadas” .
Uma vez definido um prazo com o cliente, é necessário que o gerente acompanhe o
cronograma durante todo o processo de desenvolvimento do software, buscando mantê-lo dentro
do prazo estabelecido. Dessa forma, para alcançar o objetivo definido no Quadro 16, é necessário
identificar TXDLVDo}HVGHYHPVHUWRPDGDVSDUDPDQWHURFURQRJUDPDGRSURMHWRGHQWUR
GRSUD]R Uma lista de ações foi definida com base nos mesmos autores anteriores. Na pesquisa
de campo, foi solicitado que os gerentes de projeto identificassem a periodicidade em que essas
ações devem ser tomadas na prática, ou seja, no “ início do desenvolvimento do projeto” ,
“ semanalmente” , “ mensalmente” , “ após o final de cada fase de desenvolvimento” , as que são
tomadas “ esporadicamente” , “ sem periodicidade definida” e as “ não praticadas pelos gerentes” .
No entanto, à medida que o gerente de projeto acompanha continuamente a execução do
projeto, mesmo tomando ações para mantê-lo no prazo, pode acontecer do cronograma atrasar
por diferentes fatores. Como citado no capítulo 3, Farias (2002) realizou uma pesquisa em que
identificou diferentes fatos que levam um cronograma a atrasar (como por exemplo, equipe de
desenvolvimento indisponível, projeto com alto grau de inovação, entre outros). Dessa forma,
apesar de todo o controle, o cronograma pode sofrer algum atraso devido a algum desses fatos.
Assim, foi decidido identificar TXDLVDo}HVGHYHPVHUWRPDGDVSDUDFDGDIDWRLGHQWLILFDGR
 81

FRPRFDXVDGRU GR DWUDVR QRFURQRJUDPD GRSURMHWR, de forma a melhor alcançar o objetivo

definido no Quadro 16. Os fatos que provocam atraso no cronograma foram identificados no
estudo realizado por Farias (2002). Esses fatos foram listados juntamente com as possíveis ações
a serem tomadas pelo gerente, para evitá-los ou minimizar a ocorrência dos mesmos. Essas ações
também foram definidas baseadas nos autores citados acima.
Esse conjunto de questões, contendo as ações e fatos, foi organizado em um questionário
apresentado no Apêndice B.

ii) &ROHWDHDQiOLVHGHGDGRV
A coleta de dados foi realizada através da aplicação do questionário apresentado no
Apêndice B. Os participantes do estudo foram os gerentes de projetos de software da indústria
(empresas públicas e privadas) e alunos do curso de Pós-graduação em Gestão do Conhecimento
e Tecnologia da Informação (GCTI) da UCB, cujo perfil são de profissionais que trabalham na
indústria na área de TI. Esses participantes são representativos para os profissionais que
desempenham a função de gerente de projeto. Desta forma, as ações gerenciais indicadas pelos
participantes serão baseadas na experiência pessoal de cada respondente do questionário.
Foram enviados 23 questionários via e-mail para profissionais de empresas públicas e
privadas e distribuídos 25 pessoalmente, para os alunos do curso de Pós-Graduação em GCTI da
UCB. Do total de 48 questionários distribuídos, obteve-se 37 respostas.
A primeira parte do questionário identificou as características dos profissionais que
participaram da pesquisa como: a formação profissional, área de atuação e experiência na gestão
de projetos conforme mostram as Figuras 3 e 4.
Dentre os respondentes, 36 atuam na indústria e alguns desses atuam também na academia
como aluno de pós-graduação, professor e ou pesquisador conforme mostra a Figura 3. Apenas 1
respondente atua apenas na academia.
 82

$WXDomRQD,QG~VWULD $WXDomRQD$FDGHPLD
Gerente de TI Professor

Gerente de projeto 1
Pesquisador
6
2 3 1 3 Membro de projeto
0
Aluno pós-
9 Gerente de 2 graduação
19 Gerente de
estimativa de projeto 19
Consultor externo estimativa
Consultor externo
Não respondeu

)LJXUDÈUHDGHDWXDomRGRVUHVSRQGHQWHV

Em relação à formação profissional, identificou-se que além do curso de graduação, 23

dos respondentes possuem especialização, 18 possuem mestrado, 3 possuem doutorado e 8
possuem certificações. Dentre os profissionais certificados, 3 são certificados pelo PMI, 1 pelo
IFPUG e 4 em outras áreas (Figura 4).

)RUPDomRSURILVVLRQDO ÈUHDGHFHUWLILFDomR

Doutorado 1 IFPUG
8 3 18
Mestrado PMI

Especialização Outro
4
37 Graduação
23 3
Certificação

)LJXUD)RUPDomRSURILVVLRQDOGRVUHVSRQGHQWHV

Identificou-se também a experiência dos respondentes em relação ao tempo de atuação em

gestão de projetos e o número de projetos gerenciados. A Figura 5 mostra que 13 possuem de 5 a
10 anos e 12 de a 1 a três anos de experiência. Apenas 3 possuem mais de 10 anos de experiência,
sendo que a maioria dos respondentes gerenciou de 1 a 5 projetos de software.
 83

7HPSRGHDWXDomRHPJHVWmRGH
Ÿ ?¡“¢£¥¤5¦?¢˜§£¥¤(¨¢>©¤>ª˜«>¢£¬¢­>®›¯ °›¦?¤>ª

SURMHWRV †ˆ‡?‰-Šˆ‹>Œ

‰Ž‡?-Šˆ‹>Œ
2 1 - 3 proj
3 7 11 3 - 5 proj
3 Ž‡†%-Šˆ‹>Œ>
12
5 - 10 proj
‘“’” –•?—˜† 7 mais de 10 proj
13 ’ ‹>Œ> 10 não respondeu
8 ™Hš›Œ
œ —?>Œ‹>•>—ž

)LJXUD([SHULrQFLDHPJHVWmRGHSURMHWRV

Quanto à gestão de tempo de execução de projetos, verificou-se que a experiência dos

respondentes varia entre média a baixa conforme mostra a Figura 6.
Após identificar as características dos respondentes, os resultados da pesquisa foram
analisados em conjunto (já que 36 dos respondentes são da indústria e apenas 1 da academia) de
acordo com as questões definidas na etapa LGHILQLomR conforme apresentado a seguir.

([SHULrQFLDHPJHVWmRGHWHPSRGH
H[HFXomRGHSURMHWRV

5 3 Alta
2 Média
Baixa
11 19 Nenhuma
Não respondeu

)LJXUD([SHULrQFLDHPJHVWmRGHWHPSRGHH[HFXomRGHSURMHWRV

4XHVWmR4XDLVDo}HVGHYHPVHUWRPDGDVTXDQGRRFURQRJUDPDGRSURMHWRpLPSUDWLFiYHO"
Para responder esta questão, foram identificadas na literatura as ações a serem tomadas
pelo gerente ainda na fase de planejamento, ou mais especificamente, após a definição do
cronograma do projeto, caso o cronograma seja irreal ou impraticável de se executar.
Para cada ação, foi solicitada a indicação do nível de recomendação representado pela
escala de 1 a 4 ou seja, 4- muito recomendada, 3- recomendada, 2- pouco recomendada e 1 - não
recomendada de acordo com a experiência do respondente (APÊNDICE B, I – Planejamento).
 84

A Tabela 5 apresenta o resultado para a questão 1 de acordo com a freqüência da

indicação das ações (listadas na coluna 1) por nível de recomendação (apresentado em negrito
nas colunas de 2 a 6). Por exemplo, a ação 1 teve 26 indicações para o nível 4. Isto mostra que
esta ação é muito recomendada. Por outro lado, os resultados mostram que a ação 6 não é
recomendada por 100% dos respondentes do questionário.
Além das ações apresentadas inicialmente no questionário, três outras ações foram
sugeridas por um dos respondentes: medir a satisfação do cliente, motivar a equipe e oferecer
treinamento.

7DEHOD$o}HVUHFRPHQGDGDVTXDQGRRFURQRJUDPDpLPSUDWLFiYHO
$o}HV 1tYHOGHUHFRPHQGDomR
    
1. Reunir-se com o cliente, apresentar a estimativa 4 0 0 7 
detalhada em relação ao esforço e a duração
estimada para o projeto e negociar novo prazo.
2. Definir uma estratégia de desenvolvimento 0 0 5  14
incremental que entregue a funcionalidade crítica
na data prevista e adie as funções restantes.
3. Negociar o aumento do orçamento e contratar 0 10  6 2
mais recursos humanos apesar de que esta solução
pode comprometer a qualidade do produto.
4. Contratar consultoria especializada para resolver 1 3 10  2
problemas técnicos.
5. Substituir os técnicos que não tem apresentado 0 3 14  5
resultados satisfatórios.
6. Ignorar a realidade e esperar completar o prazo 0  0 0 0
determinado no cronograma.
21mRUHVSRQGHX1mRUHFRPHQGDGD3RXFR5HFRPHQGDGD5HFRPHQGDGD0XLWRUHFRPHQGDGD

O Quadro 17 sintetiza as respostas para a questão (1), por ordem decrescente de indicação
das ações pelos respondentes do questionário.
 85

4XDGUR$o}HVDVHUHPWRPDGDVTXDQGRRFURQRJUDPDpLPSUDWLFiYHO

4XHVWmR4XDLVDo}HVGHYHPVHUWRPDGDVTXDQGRRFURQRJUDPDGRSURMHWRpLPSUDWLFiYHO"
$o}HVPDLV ƒ$omR  Reunir com o cliente, apresentar a estimativa detalhada em relação ao esforço e a
UHFRPHQGDGDV duração estimada para o projeto e negociar novo prazo.
$o}HV ƒ$omR Definir uma estratégia de desenvolvimento incremental que entregue a funcionalidade
UHFRPHQGDGDV crítica na data prevista e adie as funções restantes.
ƒ$omR Contratar consultoria especializada para resolver problemas técnicos.
ƒ$omR Substituir os técnicos que não tem apresentado resultados satisfatórios.
$o}HVSRXFR ƒ$omR Negociar o aumento do orçamento e contratar mais recursos humanos.
UHFRPHQGDGDV
$o}HVQmR ƒ$omR Ignorar a realidade e esperar completar o prazo determinado no cronograma – 100%
UHFRPHQGDGDV respondentes.
2XWUDV Do}HV ƒMedir a satisfação do cliente, motivar a equipe e oferecer treinamento.
LQGLFDGDV 

A próxima questão do questionário (APÊNDICE B, II – Acompanhamento), visa

identificar as ações que permitem controlar ou manter o cronograma dentro do prazo em resposta
à questão (2) apresentada na etapa LGHILQLomR (Tabela 6).

4XHVWmR³4XDLVDo}HVGHYHPVHUWRPDGDVSDUDPDQWHURFURQRJUDPDGRSURMHWRGHQWURGR
SUD]R´
Foi solicitada aos respondentes, a indicação das ações de acordo com a escala de
periodicidade em que elas são realizadas na prática: 1- no início do desenvolvimento, 2 –
semanal, 3 – mensal, 4 – após o término de cada fase de desenvolvimento, 5 – sem periodicidade
definida e 6 - não pratica estas ações. A Tabela 6 mostra os resultados de acordo com a
freqüência das respostas.
De acordo com esta tabela, pode-se verificar que nove (2 a 8, 10 e 18) das vinte e duas
ações propostas para a questão devem ser adotadas no início do desenvolvimento, sete (9, 12 –
14, 16, 17 e 19) semanalmente e seis sem periodicidade definida (1,11, 16, 17, 21 e 22). A Tabela
6 mostrou também que a ação 10 foi a mais indicada, seguida da ação 21 e posteriormente das
ações 3, 5, 12, 18 e 19.
Os resultados apresentados na Tabela 6 indicam que a maioria das ações recomendadas
para manter o cronograma no prazo (16 das 22) deve ser tomadas no início do desenvolvimento,
semanalmente ou sem periodicidade definida conforme mostra o Quadro 18.
 86



7DEHOD$o}HVDVHUHPWRPDGDVSDUDFRQWURODURXPDQWHURFURQRJUDPDQRSUD]R

$o}HV 3HULRGLFLGDGH
     
1. Avaliar o plano de projeto, o ambiente de desenvolvimento previsto, as 5 11 3 2  2
datas impostas pelo patrocinador do projeto ou cliente e os fatores externos
que podem interferir no cronograma do projeto.
2. Avaliar o tempo necessário para implementar cada atividade.  12 3 4 4 0
3.Incluir reservas orçamentárias para resolver problemas ou executar o plano  1 2 4 8 4
de contingência.
4. Identificar e documentar as restrições no plano do projeto que limitarão a  6 5 4 7 3
realização das atividades e elaborar um plano de contingência.
5. Verificar se todas as atividades e tarefas que visam alcançar o objetivo do  10 6 4 4 0
projeto constam no cronograma e foram entendidas pela equipe.
6. Identificar se os marcos de referência do projeto foram estabelecidos de  6 6 5 4 1
modo que o progresso possa ser acompanhado.
7. Verificar se todo o esforço e duração do projeto foram atribuídos  5 8 9 5 1
corretamente a cada atividade do cronograma.
8. Verificar se as interdependências entre as atividades foram adequadamente  5 6 9 4 1
indicadas.
9. Identificar questões que podem causar problemas futuros, providenciar 7  7 6 9 0
ações corretivas e alertar a equipe do projeto.
10. Identificar as atividades que não são do projeto ou que dependem de  2 3 6 3 1
fornecedores para serem executadas.
11. Identificar possíveis mudanças que influenciam no cronograma (ex: na 8 9 5 5  1
legislação, no escopo ou tecnologia).
12. Identificar e coordenar as atividades e tarefas realizadas em paralelo. 10  6 3 3 0
13. Identificar quais datas do cronograma foram alcançadas e quais não foram. 0  7 10 3 1
14. Conduzir reuniões periódicas para que cada membro do projeto possa 0  8 1 4 1
relatar o progresso e os problemas atuais.
15. Analisar os relatórios de desempenho do projeto e avaliar os resultados 0 10  8 7 3
das revisões conduzidas ao longo do processo de desenvolvimento.
16. Atualizar o plano, os documentos técnicos e informar a equipe e clientes. 0  6 9  1
17. Ter membros representativos nas reuniões de revisões técnicas para 3  7 6  4
garantir o entendimento comum das necessidades do cliente e evitar futuras
surpresas.
18. Identificar se há algum membro da equipe que possui habilidades únicas,  1 6 3 8 2
difíceis de serem substituídas ou está comprometido com outros projetos.
19. Controlar a produtividade da equipe. 0  11 2 5 2

20. Refinar as estimativas realizadas no início do projeto durante todo o ciclo 1 6 11  5 2
de desenvolvimento do projeto.
21. Contratar consultoria externa para auxiliar no uso da tecnologia. 8 1 1 3  5
22. Facilitar a comunicação entre os membros da equipe. 5 11 3 2  2
(1) No início do desenvolvimento (2) Semanal (3) Mensal (4) Após o término de cada fase de desenvolvimento
(5) Sem periodicidade definida (6) Não pratica estas ações.
 87

4XDGUR$o}HVDVHUHPWRPDGDVTXDQGRRFURQRJUDPDHVWiGHQWURGRSUD]R

4XHVWmR4XDLVDo}HVGHYHPVHUWRPDGDVSDUDPDQWHURFURQRJUDPDGRSURMHWRGHQWURGRSUD]R"
1RLQtFLRGR ƒ$omR  Identificar as atividades que não são do projeto ou que dependem de
GHVHQYROYLPHQWRGR fornecedores para serem executadas.
SURMHWR ƒ$omR Incluir reservas orçamentárias para resolver problemas ou executar o plano de
contingência.
ƒ$omR  Verificar se todas as atividades e tarefas que visam alcançar o objetivo do
projeto constam no cronograma e foram entendidas pela equipe.
ƒ$omR  Identificar se há algum membro da equipe que possui habilidades únicas,
difíceis de serem substituídas ou está comprometido com outros projetos.
ƒ$omR Avaliar o tempo necessário para implementar cada atividade.
ƒ$omR Identificar se os marcos de referência do projeto foram estabelecidos de modo
que o progresso possa ser acompanhado.
ƒ$omR  Verificar se as interdependências entre as atividades foram adequadamente
indicadas.
ƒ$omR  Identificar e documentar as restrições no plano do projeto que limitarão a
realização das atividades e elaborar um plano de contingência.
ƒ$omR Verificar se todo o esforço e duração do projeto foram atribuídos corretamente
a cada atividade do cronograma.
6HPDQDOPHQWH ƒ$omR Conduzir reuniões periódicas para que cada membro do projeto possa relatar o
progresso e os problemas atuais.
ƒ$omR Identificar e coordenar as atividades e tarefas realizadas em paralelo.
ƒ$omR Controlar a produtividade da equipe.
ƒ$omR Identificar quais datas do cronograma foram alcançadas e quais não foram.
ƒ$omR  Identificar questões que podem causar problemas futuros, providenciar ações
corretivas e alertar a equipe do projeto.
ƒ$omR Atualizar o plano, os documentos técnicos e informar a equipe e clientes.
ƒ$omR Ter membros representativos nas reuniões de revisões técnicas para garantir o
entendimento comum das necessidades do cliente e evitar futuras surpresas.
0HQVDOPHQWH ƒ$omR  Analisar os relatórios de desempenho do projeto e avaliar os resultados das
revisões conduzidas ao longo do processo de desenvolvimento. 
$SyVRILQDOGH ƒ$omR Refinar as estimativas realizadas no início do projeto durante todo o ciclo de
FDGDIDVHGH desenvolvimento do projeto. Esta indicação coincide com a proposta do processo de
GHVHQYROYLPHQWR gestão de estimativa, definido neste trabalho (ver Figura 7).
6HPSHULRGLFLGDGH ƒ $omR. Contratar consultoria externa para auxiliar no uso da tecnologia.
GHILQLGD ƒ $omR Avaliar o plano de projeto, o ambiente de desenvolvimento previsto, as datas
impostas pelo patrocinador do projeto ou cliente e os fatores externos que podem
interferir no cronograma do projeto.
ƒ $omR Facilitar a comunicação entre os membros da equipe.
ƒ $omR  Identificar possíveis mudanças que influenciam no cronograma (ex: na
legislação, no escopo ou tecnologia).
ƒ $omR Atualizar o plano, os documentos técnicos e informar a equipe e clientes.
ƒ $omR Ter membros representativos nas reuniões de revisões técnicas para garantir
o entendimento comum das necessidades do cliente e evitar futuras surpresas.
1mRSUDWLFDGDV ƒ$omR Ignorar a realidade e esperar completar o prazo determinado no cronograma.
2XWUDVDo}HV ƒMedir a satisfação do cliente, motivar a equipe e oferecer treinamento.

A última questão do questionário (APÊNDICE B – II Acompanhamento) identificou as

ações a serem tomadas pelo gerente quando o cronograma está atrasado em resposta a questão (3)
apresentada na etapa L GHILQLomR. As ações foram indicadas de acordo com os fatos que
provocam atraso no cronograma. Os números indicados nas colunas representam as ações listadas
 88

no topo da tabela e as linhas representam os fatos que provocam o atraso no cronograma. Foi
solicitada a indicação das ações a serem tomadas para cada fato.

4XHVWmR  4XDLV Do}HV GHYHP VHU WRPDGDV SDUD FDGD IDWR LGHQWLILFDGR FRPR FDXVDGRU GR
DWUDVRQRFURQRJUDPDGRSURMHWR"
A seguir serão apresentadas as ações indicadas para cada fato. Os números destacados
representam a freqüência de respostas mais significantes conforme mostra a Tabela 7.

7DEHOD$o}HVDVHUHPWRPDGDVTXDQGRRFURQRJUDPDHVWLYHUDWUDVDGR
$o}HVDVHUHPWRPDGDVTXDQGRRFURQRJUDPDHVWLYHUDWUDVDGR
1. Rever o planejamento do projeto e identificar desvios no
7. Controlar a comunicação entre os membros do projeto.
cronograma.
8. Fazer ajustes no plano e documentar as ações para contemplar as
2. Agregar novas pessoas na equipe do projeto.
revisões de tempo, custo, seqüência de atividades e análise de
3. Redistribuir as pessoas na equipe.
alternativas de respostas a riscos.
4. Rever as funções do software, priorizá-las e deixar as menos
9. Verificar se as atualizações do cronograma requerem ajustes em
importantes para futuras versões.
outros aspectos do plano geral do projeto.
5. Rever o cronograma e buscar alcançar o próximo marco do projeto
10. Registrar os desvios do cronograma, identificar quais atividades
na data prevista para garantir o término do projeto na data
ocorreram e o motivo de sua ocorrência.
esperada.
11. Contratar consultoria especializada.
6. Caso não haja possibilidade de recuperação do atraso, o gerente
deve rever o cronograma e negociar com as partes envolvidas.
)DWRVTXHSURYRFDPDWUDVRQRFURQRJUDPD $o}HVUHFRPHQGDGDV
± ² ³ ´ µ ¶ · ¸ ¹ ±"º ±+±

1. Equipe de desenvolvimento indisponível. ±"µ

12 5 7 6 9 2 4 4 6 3
2. Projeto com alto grau de inovação. ±"·
8 10 0 6 1 8 8 6 4 4
3. Prazos e custos estabelecidos arbitrariamente. ±"¸
1 2 3 9 12 1 14 9 6 3
4. Método de estimativa de tamanho inadequado. ±»³ ±»² ±»²
3 1 7 7 11 1 9 4
5. Gerência inexperiente. ±"µ
9 9 2 3 5 5 1 7 9 8
6. Equipe de desenvolvimento inexperiente em Engenharia de Software. ²%º
7 10 2 4 6 6 5 4 18 0

7. Equipe de desenvolvimento inexperiente no domínio da aplicação. ±»³ ±»³

11 6 6 3 5 6 3 5 4

8. Equipe de desenvolvimento inexperiente nos métodos e ferramentas ±"¸

utilizadas. 8 17 7 3 5 4 6 5 5 4

9. Processo de desenvolvimento inadequado. ±"µ

9 2 4 5 4 7 4 7 6 6
10. Levantamento ou acompanhamento de requisitos com pessoas ±+± ±+±
inexperientes. 5 6 4 6 5 6 4 6 7

11. Alto grau de competição na empresa do cliente. ±»²

9 1 3 3 4 6 7 5 6 4
12.Falta de comprometimento do usuário/cliente. 9 3 0 5 4 9 9 9 5
±"º
1
13. Orçamento insuficiente. ±"´ ±»³ ±+±
0 2 3 10 3 7 4 1
14. Requisitos complexos. ±+±
9 6 0 7 6 5 11 5 7 9
15. Hardware e/ou software necessários não disponíveis no momento ±»³ ±»³
definido. 0 2 5 8 2 11 7 8 1
 89

)DWRVTXHSURYRFDPDWUDVRQRFURQRJUDPD $o}HVUHFRPHQGDGDV
16. Dependência de produtos ou serviços externos que afetam o produto, ±"µ
o orçamento, o cronograma ou a continuidade do projeto. 12 0 0 5 6 12 4 4 7 1

17. Mudanças de requisito que não foram refletidas em mudanças do ±»²

cronograma. 3 0 6 11 11 4 10 11 9 2

18. Falta de identificação dos riscos previsíveis e imprevisíveis no início ±"¸

do projeto. 0 0 4 6 11 2 13 10 7 2

19. Falta de identificação das dificuldades técnicas e humanas no início ±"µ

do projeto. 5 7 6 8 8 6 10 6 6 4

20. Falta de comunicação entre os membros do projeto. ³+²

8 3 6 3 5 3 3 4 3 2

Com base na Tabela 7, foram destacadas as ações mais indicadas para cada fato causador
do atraso no cronograma e apresentado no Quadro 19 abaixo.

4XDGUR$o}HVPDLVLQGLFDGDVSDUDFDGDIDWR

)DWRVTXHSURYRFDPDWUDVRQR
$o}HVPDLVLQGLFDGDV
FURQRJUDPD
 (TXLSHGHGHVHQYROYLPHQWR ƒ $omRRever o planejamento do projeto e identificar desvios no cronograma
LQGLVSRQtYHO ƒ $omRAgregar novas pessoas na equipe do projeto.
3URMHWRFRPDOWRJUDXGH
ƒ $omRContratar consultoria especializada.
LQRYDomR
ƒ $omR Rever o planejamento do projeto e identificar desvios no cronograma.
3UD]RVHFXVWRVHVWDEHOHFLGRV
DUELWUDULDPHQWH ƒ $omR  Fazer ajustes no plano e documentar as ações para contemplar as
revisões de tempo, custo, seqüência de atividades e análise de respostas a riscos
ƒ $omR  Rever o cronograma e negociar com as partes envolvidas, caso não
haja possibilidade de recuperação do atraso
0pWRGRGHHVWLPDWLYDGH ƒ $omR Rever o planejamento do projeto e identificar desvios no cronograma.
WDPDQKRLQDGHTXDGR ƒ $omR  Fazer ajustes no plano e documentar as ações para contemplar as
revisões de tempo, custo, seqüência de atividades e análise de alternativas de
respostas a riscos.
ƒ $omR Verificar se as atualizações do cronograma requerem ajustes em outros
aspectos do plano geral do projeto.
ƒ $omR  Rever o cronograma e negociar com as partes envolvidas, caso não
haja possibilidade de recuperação do atraso.
*HUrQFLDLQH[SHULHQWH ƒ $omR Contratar consultoria especializada.
ƒ $omR Agregar novas pessoas na equipe do projeto.
(TXLSHGHGHVHQYROYLPHQWR ƒ $omR Agregar novas pessoas na equipe do projeto.
LQH[SHULHQWHHP(QJHQKDULDGH ƒ $omR  Registrar os desvios do cronograma, identificar quais atividades
6RIWZDUH ocorreram e o motivo de sua ocorrência.
ƒ $omR Redistribuir as pessoas na equipe.







 90

4XDGURFRQW$o}HVPDLVLQGLFDGDVSDUDFDGDIDWR
)DWRVTXHSURYRFDPDWUDVRQR
FURQRJUDPD
(TXLSHGHGHVHQYROYLPHQWR
LQH[SHULHQWHQRGRPtQLRGD
DSOLFDomR

(TXLSHGHGHVHQYROYLPHQWR
LQH[SHULHQWHQRVPpWRGRVH
IHUUDPHQWDVXWLOL]DGDV
3URFHVVRGHGHVHQYROYLPHQWR
LQDGHTXDGR
/HYDQWDPHQWRRX
DFRPSDQKDPHQWRGHUHTXLVLWRV
FRPSHVVRDVLQH[SHULHQWHV
$OWRJUDXGHFRPSHWLomRQD
HPSUHVDGRFOLHQWH
)DOWDGHFRPSURPHWLPHQWR
GRXVXiULRFOLHQWH
2UoDPHQWRLQVXILFLHQWH
5HTXLVLWRVFRPSOH[RV
+DUGZDUHHRXVRIWZDUH
QHFHVViULRVQmRGLVSRQtYHLVQR ƒ $omR. Rever o cronograma e negociar com as partes envolvidas, caso não haja
PRPHQWRGHILQLGR
'HSHQGrQFLDGHSURGXWRVRX ƒ $omR  Fazer ajustes no plano e documentar as ações para contemplar as
VHUYLoRVH[WHUQRVTXHDIHWDPR
SURGXWRRRUoDPHQWRR
FURQRJUDPDRXDFRQWLQXLGDGH ƒ $omR Rever o cronograma e negociar com as partes envolvidas, caso não
GRSURMHWR





$o}HVPDLVLQGLFDGDV
ƒ $omR Agregar novas pessoas na equipe do projeto.
ƒ $omR Contratar consultoria especializada.
ƒ $omR Rever o planejamento do projeto e identificar desvios no cronograma.
ƒ $omR Contratação de consultoria especializada.
ƒ $omR Rever o planejamento do projeto e identificar desvios no cronograma;
ƒ $omR Agregar novas pessoas na equipe do projeto.
ƒ $omRControlar a comunicação entre os membros do projeto.
ƒ $omR  Registrar os desvios do cronograma, identificar quais atividades
ocorreram e o motivo da sua ocorrência.
ƒ $omR Rever o planejamento do projeto e identificar desvios no cronograma;
$omR  Rever o cronograma e negociar com as partes envolvidas, caso não
haja possibilidade de recuperação do atraso.
ƒ $omR Controlar a comunicação entre os membros do projeto.
ƒ $omR  Fazer ajustes no plano e documentar as ações para contemplar as
revisões de tempo, custo, seqüência de atividades e análise de alternativas de
respostas a riscos.
ƒ $omR Rever o planejamento do projeto e identificar desvios no cronograma;
ƒ $omR  Rever as funções do software, priorizá-las e deixar as menos
importantes para futuras versões.
ƒ $omR  Fazer ajustes no plano e documentar as ações para contemplar as
revisões de tempo, custo, seqüência de atividades e análise de alternativas de
respostas a riscos.
ƒ $omR  Rever as funções do software, priorizá-las e deixar as menos
importantes para futuras versões.
ƒ $omR  Fazer ajustes no plano e documentar as ações para contemplar as
revisões de tempo, custo, seqüência de atividades e análise de alternativas de
respostas a riscos.
ƒ $omR. Rever o planejamento do projeto e identificar desvios no cronograma.
possibilidade de recuperação do atraso.
ƒ $omR. Fazer ajustes no plano e documentar as ações para contemplar as
revisões de tempo, custo, seqüência de atividades e análise de alternativas de
respostas a riscos.
revisões de tempo, custo, seqüência de atividades e análise de alternativas de
respostas a riscos.
haja possibilidade de recuperação do atraso.
ƒ $omR Rever o planejamento do projeto e identificar desvios no cronograma
 91


4XDGURFRQW$o}HVPDLVLQGLFDGDVSDUDFDGDIDWR

)DWRVTXHSURYRFDPDWUDVRQR
$o}HVPDLVLQGLFDGDV
FURQRJUDPD
0XGDQoDVGHUHTXLVLWRTXH ƒ $omR Rever o planejamento do projeto e identificar desvios no cronograma.
QmRIRUDPUHIOHWLGDVHP ƒ $omR Rever o cronograma e buscar alcançar o próximo marco do projeto na
PXGDQoDVGRFURQRJUDPD data prevista para garantir o término do projeto na data esperada.
ƒ $omR  Rever o cronograma e negociar com as partes envolvidas, caso não
haja possibilidade de recuperação do atraso.
ƒ $omR Verificar se as atualizações do cronograma requerem ajustes em outros
aspectos do plano geral do projeto.
ƒ $omR . Fazer ajustes no plano e documentar as ações para contemplar as
revisões de tempo, custo, seqüência de atividades e análise de alternativas de
respostas a riscos.
)DOWDGHLGHQWLILFDomRGRV ƒ $omR Rever o planejamento do projeto e identificar desvios no cronograma.
ULVFRVSUHYLVtYHLVHLPSUHYLVtYHLV ƒ $omR . Fazer ajustes no plano e documentar as ações para contemplar as
QRLQtFLRGRSURMHWR revisões de tempo, custo, seqüência de atividades e análise de alternativas de
 respostas a riscos.
)DOWDGHLGHQWLILFDomRGDV ƒ $omR  Rever o cronograma e negociar com as partes envolvidas, caso não
GLILFXOGDGHVWpFQLFDVHKXPDQDV haja possibilidade de recuperação do atraso.
QRLQtFLRGRSURMHWR
)DOWDGHFRPXQLFDomRHQWUH
ƒ $omR Controlar a comunicação entre os membros do projeto
RVPHPEURVGRSURMHWR

A ação 2. “ Agregar novas pessoas na equipe do projeto” , apesar de ter sido indicada pelos
gerentes para alguns dos fatos do Quadro 19, deve ser analisada com cuidado, já que agregar
pessoas nas últimas fases do projeto pode ter um efeito danoso (PRESSMAN, 2002).
Analisando os resultados apresentados acima para a questão 3, pode-se concluir que as
ações mais indicadas pelos respondentes, (independente do fato causador do atraso), quando o
cronograma está atrasado, são as apresentadas no Quadro 20 em ordem de decrescente de
indicação.
Além das ações apresentadas no questionário (APÊNDICE B), alguns respondentes
indicaram outras ações relevantes a serem tomadas, quando o cronograma está atrasado e as
associaram aos fatos conforme mostra também o Quadro 20. O número apresentado entre
parêntesis indica a quantidade de respondentes que indicaram a ação.
 92

4XDGUR   $o}HV D VHUHP WRPDGDV SHORV JHUHQWHV TXDQGR R FURQRJUDPD HVWi
DWUDVDGR

$o}HVDVHUHP $omR Rever o planejamento do projeto e identificar desvios no cronograma.

ƒ
WRPDGDVSHORV $omR Fazer ajustes no plano e documentar as ações para contemplar as revisões de tempo,
ƒ
JHUHQWHV custo, seqüência de atividades e análise de alternativas de respostas a riscos.
TXDQGRR $omR  Rever o cronograma e negociar com as partes envolvidas, caso não haja
ƒ
FURQRJUDPD possibilidade de recuperação do atraso.
HVWiDWUDVDGR $omR  Registrar os desvios do cronograma, identificar quais atividades ocorreram e o
ƒ
 motivo de sua ocorrência.
$omR Verificar se as atualizações do cronograma requerem ajustes em outros aspectos do
ƒ
plano geral do projeto.
$omR Agregar novas pessoas na equipe do projeto.
ƒ
$omR Contratar consultoria especializada.
ƒ
$omR Controlar a comunicação entre os membros do projeto.
ƒ
$omR Rever o cronograma e buscar alcançar o próximo marco do projeto na data prevista
ƒ
para garantir o término do projeto.
$omR  Rever as funções do software, priorizá-las e deixar as menos importantes para
ƒ
futuras revisões.
$omR Redistribuir as pessoas na equipe.
ƒ
2XWUDV Do}HV )DWRH- Ação 12. Oferecer treinamento (5).
ƒ
LQGLFDGDV GH )DWRAção 13. Capacitar a equipe (1).
ƒ
DFRUGR FRP R )DWRAção 14. Substituir a gerência (1).
ƒ
IDWR SHORV )DWR- Ação 15. Fazer revisões periódicas e constantes com o usuário (1).
ƒ
UHVSRQGHQWHV )DWRAção 16. Rever o processo para adequá-lo à necessidade da empresa (1).
ƒ

Finalmente, após estudar e complementar os procedimentos de contagem da APF e PCU

para projetos OO de acordo com a literatura, aplicar estes procedimentos na contagem de projetos
reais (academia e indústria), encontrar a relação entre estas métricas e identificar as ações a serem
tomadas pelo gerente do projeto, foi definido um processo de gestão de estimativa de tamanho,
incorporando todas as etapas acima para apoiar o gerente do projeto durante todo o processo de
desenvolvimento do projeto. Este processo será descrito a seguir.

3URFHVVRGHJHVWmRGHHVWLPDWLYDGHWDPDQKRGHSURMHWRGHVRIWZDUH

O processo de gestão de estimativa de tamanho de projeto de software visa apresentar

atividades a serem realizadas durante a gestão de estimativa de tamanho de forma integrada com
os processos de desenvolvimento e gestão de projetos de software.
Para executar as atividades do processo de gestão de estimativas são utilizadas
informações, procedimentos e recursos que são considerados entradas importantes para este
processo tais como:
i) documentação do projeto de software;
 93

ii) procedimentos de contagem de PCU e PF;

iii) equação de relação entre PF e PCU;
iv) hardware e software necessários à realização das estimativas;
v) histórico de estimativas de tamanho de projeto de software desenvolvidos na
empresa;
vi) plano e cronograma do projeto de software;
vii) ações a serem tomadas durante o acompanhamento do projeto de desenvolvimento
de software.
Os itens (ii), (iii) e (vii) foram definidos nas seções 4.3, 4.4.4 e 4.5 deste capítulo.
Os principais produtos de saída ou resultados do processo de gestão de estimativas de
tamanho são:
i) número de PCU contados para o projeto;
ii) número de PF projetados e contados (em diferentes fases do processo de
desenvolvimento);
iii) planilhas com os resultados das contagens;
iv) diferença entre o número de PF projetado e o número de PF contado;
v) relatório de controle atual do projeto de desenvolvimento;
vi) lista de ações gerenciais a serem executadas para corrigir os desvios do projeto;
vii) base de dados de histórico de estimativas atualizada.
Este processo tem como principais clientes o gerente comercial da empresa; o gerente de
projeto de software, os membros de projeto de software e o usuário gestor do produto de
software.
O processo de gestão de estimativas compõe-se das seguintes atividades:
atividade 1: Realizar a contagem de tamanho inicial em PCU;
atividade 2: Projetar a estimativa em PF;
atividade 3: Realizar a contagem de tamanho em PF;
atividade 4: Comparar o número de PF projetado com o número de PF contado;
atividade 5: Obter informações gerenciais do projeto;
atividade 6: Comparar as estimativas com o cronograma planejado;
atividade 7: Providenciar ações de ajuste no projeto;
atividade 8: Realizar estimativa de tamanho final em PF (PF entregue).
 94

Para cada atividade do processo serão descritos a seguir os objetivos, o responsável, os

pré-requisitos necessários para sua realização, as tarefas que a compõe, os produtos de entrada e
saída e as diretrizes21 a serem utilizadas para a sua realização conforme apresentado no Quadro
21.
4XDGUR$WLYLGDGHVGRSURFHVVRGHJHVWmRGHHVWLPDWLYDGHWDPDQKR

$WLYLGDGH5HDOL]DUDFRQWDJHPGHWDPDQKRLQLFLDOHP3&8
2EMHWLYR Identificar a primeira estimativa de tamanho do projeto em PCU
5HVSRQViYHOGerente de projeto de software
3UpUHTXLVLWR Existência do modelo e descrição de casos de uso gerados no processo de
desenvolvimento de software
7DUHIDV Realizar a contagem de PCU
Documentar o resultado da contagem realizada
3URGXWRVGHHQWUDGD Solicitação de estimativa de tamanho do projeto
Artefatos gerados no processo de desenvolvimento de software
(Modelo e descrição de casos de uso)
3URGXWRVGHVDtGD Número de PCU contados e planilhas geradas na contagem
'LUHWUL]HV Procedimentos de contagem de PCU descritos no Capítulo 2 e na seção 4.3 deste
capítulo.
$WLYLGDGH3URMHWDUDHVWLPDWLYDHP3)
2EMHWLYR Estimar o número de PF no início do projeto, usando a equação que descreve a
relação entre PCU e PF
5HVSRQViYHO Gerente de projeto de software
3UpUHTXLVLWR Ter encontrado uma equação de relação entre PF e PCU para a organização e
ter realizado a estimativa do projeto em PCU
7DUHIDV Aplicar a equação de relação
3URGXWRVGHHQWUDGD Número de PCU contados
Equação de relação entre PF e PCU
3URGXWRVGHVDtGD Número de PF projetados

21
Diretrizes são normas, regras, procedimentos e ou documentos utilizados durante a execução de uma atividade do processo.
 95

'LUHWUL]HV Não tem

¼¼ $WLYLGDGH5HDOL]DUDFRQWDJHPGHWDPDQKRHP3)
2EMHWLYR Identificar a primeira estimativa de tamanho do projeto em PF
5HVSRQViYHO Gerente de projeto de software
3UpUHTXLVLWR Existência do Modelo de casos de uso, Diagramas de seqüência dos casos de
uso e do Modelo de classes de análise
7DUHIDV Realizar a contagem de PF
Documentar a contagem realizada
3URGXWRVGHHQWUDGD Artefatos gerados no processo de desenvolvimento de software
(Modelo de casos de uso Diagramas de seqüência e Modelo de classes de análise)
3URGXWRVGHVDtGD Número de PF contados e planilhas geradas na contagem
'LUHWUL]HV Procedimentos de contagem de PF descritos no Capítulo 2 e na seção 4.3 deste
capítulo.
$WLYLGDGH&RPSDUDUDFRQWDJHPUHDOL]DGDHP3)FRPRQ~PHURGH3)SURMHWDGR
2EMHWLYR Analisar os resultados das estimativas de tamanho projetadas para PF (através da
equação), com a estimativa de tamanho realizada em PF para o projeto
5HVSRQViYHO Gerente de projeto de software
3UpUHTXLVLWR Existência do número de PF projetado e do número de PF contado
7DUHIDV Analisar e comparar os resultados de PF
3URGXWRVGHHQWUDGD Número de PF projetado e o número de PF contado
3URGXWRVGHVDtGD Diferença entre o número de PF projetado e o número de PF contado
'LUHWUL]HV Não tem
$WLYLGDGH2EWHULQIRUPDo}HVJHUHQFLDLVGRSURMHWR
2EMHWLYR Levantar as informações relevantes sobre o desenvolvimento do projeto
5HVSRQViYHO Gerente de projeto de software
3UpUHTXLVLWR Existência de estimativas realizadas em PCU e PF (projetado e contado),
cronograma do projeto e relatórios de acompanhamento do projeto
7DUHIDV Identificar as informações e a situação atual do desenvolvimento do projeto
3URGXWRVGHHQWUDGDNúmero de PCU e PF projetado e contado, planejamento do projeto

22
* - Estas atividades podem ser realizadas diversas vezes, de acordo com a necessidade do projeto.
 96

cronograma do projeto, estimativas de esforço e custo do projeto e relatórios de

acompanhamento ou controle do projeto,
3URGXWRVGHVDtGD Relatório com a situação atual do desenvolvimento do projeto
'LUHWUL]HV Não tem
$WLYLGDGH&RPSDUDUDVHVWLPDWLYDVFRPRFURQRJUDPDSODQHMDGR
2EMHWLYR Identificar a situação atual do cronograma
5HVSRQViYHO Gerente do projeto de software
3UpUHTXLVLWR Existência de estimativas em PCU e em PF (projetada e contada) e relatório
da situação atual do projeto fornecido pelo processo de gestão de projetos.
7DUHIDV Comparar as atividades planejadas no cronograma com as atividades realizadas
pela equipe do projeto
Comparar o esforço e os custos estimados com a última contagem realizada em
PF
Analisar os problemas e os riscos identificados no projeto
Identificar os fatos que causaram os problemas
Identificar as ações gerenciais mais adequadas para solucionar o problema
3URGXWRVGHHQWUDGD Número de PCU e PF (projetado e realizado) e relatório com a
situação atual do projeto
3URGXWRVGHVDtGD Relatório da situação atual do cronograma e Lista de ações gerenciais
selecionadas pelo gerente do processo de gestão de estimativas com base no resultado do
estudo realizado na seção 4.5)
'LUHWUL]HV Ações gerenciais proposta neste trabalho
$WLYLGDGH3URYLGHQFLDUDo}HVGHDMXVWHQRSURMHWR
2EMHWLYR Corrigir os desvios do cronograma do projeto e evitar novos problemas
5HVSRQViYHO Gerente do projeto de software
3UpUHTXLVLWR Existência do número de PCU e de PF (projetado e realizado), situação atual
cronograma e ações a serem tomadas pelos gerentes
7DUHIDV Verificar a lista de ações recomendadas
Executar as ações recomendadas para ajustar o projeto caso o cronograma seja
impraticável, esteja atrasado ou as ações para evitar futuros atrasos
3URGXWRVGHHQWUDGD: Número de PCU e PF (projetado e estimado), situação atual do
 97

cronograma e lista de ações recomendadas

3URGXWRVGHVDtGD Lista de ações de ajustes a serem executadas para corrigir os desvios ou
problemas identificados
'LUHWUL]HV: Não tem
$WLYLGDGH5HDOL]DUDFRQWDJHPILQDOGH3)
2EMHWLYR Identificar o tamanho real do produto de software
5HVSRQViYHO Gerente de estimativa de tamanho de projetos
3UpUHTXLVLWR Artefatos gerados durante o processo de desenvolvimento de software,
produto de software desenvolvido e base de dados com o histórico das estimativas realizadas.
7DUHIDV Atualizar a contagem anterior com base na documentação atual e no produto de
software concluído
Armazenar os resultados das contagens realizadas durante todo o processo de
desenvolvimento do projeto na Base de dados de histórico de estimativas
3URGXWRVGHHQWUDGD Artefatos gerados durante o processo de desenvolvimento de software
(Modelo de casos de uso, modelo de análise e projeto, Modelo de Entidade e Relacionamento
– MER), planilhas utilizadas nas contagens anteriores e produto de software.
3URGXWRVGHVDtGD Número final de PF e Base de dados de histórico das estimativas
atualizadas
'LUHWUL]HV Procedimentos de contagem de PF definidos no capítulo 3 na sessão 4.3

A seguir, será apresentado o relacionamento deste processo com os processos de

desenvolvimento e de gestão de projeto software.

5HODFLRQDPHQWRGRSURFHVVRGHJHVWmRGHHVWLPDWLYDGHWDPDQKRFRPRVSURFHVVRVGH
GHVHQYROYLPHQWRHGHJHVWmRGHSURMHWRVGHVRIWZDUH

O processo de gestão de estimativa foi definido de forma integrada com os processos de

desenvolvimento e gestão de projetos de software. As atividades desses processos foram
definidas com base na NBR ISO/IEC 12.207 (ANBT, 1998) e NBR ISO/IEC 10.006 (ABNT,
2000) no PMBOK (2000), na prática chave do CMM – nível 2 que aborda as estimativas
(PAULK ET AL., 2000) apresentadas no capítulo 3.
 98

A norma NBR ISO/IEC 10.006 (ABNT, 2000) utiliza os processos de gestão de projetos
relacionados a interdependências entre os processos, ao escopo, tempo, custo, recursos, pessoal,
comunicação, risco e suprimentos como às áreas de conhecimento proposta pelo PMBOK (2000).
Os processos relacionados ao “ tempo” e a área de conhecimento “ gestão de tempo” , são
utilizados durante a execução das atividades dos processos de desenvolvimento e de gestão
propostas pela NBR ISO/IEC 12.207 (ABNT, 1998) conforme mostra o Quadro 11, apresentado
no capítulo 3.
Esses processos geram informações de entrada para o processo de estimativa de tamanho
e utilizam os produtos de saída deste processo de gestão de estimativas e as ações gerenciais
identificadas através do estudo realizado neste trabalho.
O relacionamento do processo de gestão de estimativas com os processos de
desenvolvimento e gestão de software, ocorre conforme mostra a Figura 7.
A Figura 7 é dividida em três partes. A primeira parte apresenta um processo de
desenvolvimento de software, suas principais atividades ou disciplinas (modelagem de negócio,
requisitos, análise e projeto, implementação, testes e implantação) e os principais artefatos
gerados pelas atividades e utilizados no processo de gestão de estimativa de tamanho, conforme
proposto pelo processo OO apresentado no Apêndice C. A segunda parte desta Figura, mostra o
processo de gestão de estimativas de tamanho, suas respectivas atividades descritas na seção
anterior e os elementos utilizados durante a execução deste processo como a equação de relação
entre a APF e PCU, os valores do PF projetados e contados durante o desenvolvimento do projeto
e a lista de ações gerenciais identificadas na seção 4.5 deste capítulo. A terceira parte mostra o
processo de gestão de projetos de software e seus respectivos processos conforme proposto pelo
PMBOK (2000).
O relacionamento entre os três processos apresentados na Figura 7 ocorre através:
i) das principais atividades e artefatos gerados pelo processo de desenvolvimento de
software (definidos com base no Apêndice C) que são pré-requisitos ou
documentos de entrada para o processo de estimativa de tamanho;
ii) dos processos de gestão de projetos propostos pelo PMBOK, que utilizam as
informações geradas pelo processo de gestão de estimativa de tamanho e ao
mesmo tempo subsidiam este processo com informações sobre o plano,
 99

cronograma e relatórios do status do projeto em desenvolvimento (definidos com

base no PMBOK (2000) e nos Quadro 13 e 14 apresentados no capítulo 3);
iii) de informações do histórico das estimativas realizadas durante o processo de
desenvolvimento do projeto e outras informações relevantes sobre o projeto.
Essas informações serão reutilizadas em futuros projetos conforme recomenda a NBR
ISO/IEC 10006 (ABNT, 2000) e o CMM – nível 2 (PAULK et al. 2000).
O processo de gestão de estimativa de tamanho mostra através da Figura 7, que a
estimativa inicial do projeto será realizada através do PCU com base no modelo e descrição de
casos de uso do sistema definidos na disciplina de requisitos do processo de desenvolvimento
(atividade 1). O modelo de casos de uso de negócio, gerado na disciplina de modelagem de
negócio, não é utilizado neste processo porque nesse modelo ainda não foram identificados os
casos de uso que representam as funções do software a ser desenvolvido. Com base no resultado
da contagem de PCU e na equação de relação entre APF e PCU será projetado número de PF
(atividade 2). Através do PCU encontrado e do PF projetado, o gerente do projeto poderá
desempenhar as atividades do processo de SODQHMDPHQWR que faz parte dos processos de gestão
de projetos tais como: i) estimar o esforço e custo do projeto; ii) elaborar o plano e o cronograma
do projeto; e iii) negociar compromissos com o cliente de acordo com os recursos necessários.
Nesse ponto, o gerente do projeto deve identificar e documentar os riscos do software associado
aos custos, recursos, cronograma e aspectos técnicos do projeto e elaborar planos de
contingências como recursos humanos alternativos, hardware, software e ferramentas adicionais.



½ ¾ ¿ À Á Â Â ¿ Ã Á
½ ¾ ¿ À Á Â Â ¿ Ã Á ò Á Â É ó ¿ Ã Á ù ¾ ¿ú Á É ¿ Â ½ ¾ ¿ À Á Â Â ¿ Ã Á ò Á ÂÉ ó ¿ Ã Á Ã Á Â Á Ä Å ¿Æ ÅÇ È Á Ä É ¿ Ã Á
Á Â ÉÇ È Ì ÉÇ Å Ì Ã Á É Ì È Ì Ä ô ¿

Atividade
 ¿ ÊÉ Ë Ì ¾ Á

/HJHQGD


Õ Ø ×


ØÓ Î»Í
Ó Ö×Ø Ð
× Ñ âÐ Ò
ÑÖ Ó Ñ Ñ ÏÐ Ú
çÖÐ Ü Ù 

ç ÞÝ Ò ÔÑÕ ÒÓ ÚÐÛ
Ü ÐÛ
ˆ ÚÐÛ ×Ö Ó
×ç Ñ
Õ âÐ
âÐ
× Ø
õ

Artefatos
Ó
Modelo de casos
de uso de negócio

ÖÐçç Ü
ÑÖ Ó
×
ì Ø
âÐ ö×
Ûá Î Õß
Ø Ý× Õ
Õ Ð ×



× Ð àÜ
×Ù ÑÕ 
ý ûü


ÐÒ âÐ Ù þÿ


×
þÿ ÏÐ



ðç

Ó


 
Üã

Ó
ç Ù×

Dados
 

 



Ö×Ø þ 


 


Ñ Î ä ÿ
 
Ù


ý
ÚÐÛ Ñ ÏÐ

ÔÑÕ ÒÓ
ÐÛ
Ñ

Üã

Ð ç Î å

Processo
Õ Üã Û Ý× Õ Ø

Ö×Ø 


Ñ ×æ ÑÕ æ×




Ù æ
ç ÒÓ

ÑÐ à ÑÕ  
Ðà
 
Õ Ù 

Ð
ç â× 
Ù×

× Õ ç â× ×ç þ Ð


þ



×
ÐççÖ Ü





×ç þ




ÖÐçç Ü
 

 


×ç 

âÐ


 
Ø ØÓ
÷ âÐ ÕÚ
Ð
ÕÕ
ÖÐ Õ Õ ë×
ÑØ Ò ÐØ Û Î è
Ñ ×æ
Û ÑÖ Ó Ñ êé
ÐÑ Ü Ðà çÓ Õ
ÐØ Ûà Ù× ì ÙÐ Ûõ

Informação
ç íÐ
Ù× ÐØ â×
ÐÛæ Ò
Ù×
JHVWmRGHSURMHWRVGHVRIWZDUH

ØÐ
Ñ
Ù
ì
ö×
Ðç
estimativas
Histórico de

×Õ
!
Û ÙÓ Î ý


×ØÖ Ñ
Û Ý× 

ï ÙÓ

Õ×


Ñç

ÑÚ ÑÕæ
ÑÕ
Û
Ñ Ö×Û
þ
 dados
dados
Base de


Ðç

Ñ

ç ÙÐ




Ø þÿ


Õ ì Î Õî 




þ


ç íÐ ï×
Õ×  


× þ

ÜÓ

æ×
Ñ âÐ


ÖÐçç Ü Ø âÐ
Ðà ý


× Ù× ç àð ÑÕÖ Ó

âÐ ÙÐ



÷ø þ
Ð
ðÖ
Ûõ
ì
ö× Ö×Ø
Ñ Î ñ ÑØæ Ò
Ù Ñ ÏÐ
âÐ Ñ
ÚÐÛ Ô ÒÓ Ù
ÑÕ ì
estimativas
Histórico de

Ø ëÓ Ñ ö×
Üã Ñ
Ò
)LJXUD5HODFLRQDPHQWRGRSURFHVVRGHJHVWmRGHHVWLPDWLYDGHWDPDQKRFRPRVSURFHVVRVGHGHVHQYROYLPHQWRH
100
 101

A projeção de PF será gerenciada e re-estimada durante todo o ciclo de desenvolvimento

do projeto de software, à medida que novos artefatos forem desenvolvidos. Assim que os
diagramas de seqüência e os de classes de análise forem gerados, será realizada a primeira
contagem de PF (atividade 3). Posteriormente, na disciplina de projeto será realizada nova
contagem de PF com base no diagrama de classes de projeto.
Em seguida, a estimativa de PF projetada será comparada com a estimativa de PF
encontrada (atividade 4). Nesse ponto do projeto, o gerente poderá comparar os resultados das
estimativas com as informações gerenciais do projeto, obtidas através dos processos de
SODQHMDPHQWR H FRQWUROH GR SURMHWR (processos de gestão de projetos), e verificar se o
cronograma é possível de se realizar ou impraticável, se está dentro do prazo ou se está atrasado
(atividade 5 e 6). Deve ser verificado o grau de completitude das atividades realizadas, o trabalho
já concluído, o esforço e os recursos gastos com o planejamento inicial.
Com base nos resultados dessa comparação, o gerente irá providenciar ações de ajustes no
projeto, de acordo com as ações gerenciais validadas através da pesquisa realizada neste trabalho
(atividade 7). Em geral, as ações incluem revisões no plano de desenvolvimento do projeto, ações
para melhorar o desempenho da equipe e comunicação das decisões para as pessoas envolvidas.
As mudanças no tamanho do projeto estimado podem afetar as negociações realizadas
anteriormente, tornando necessário novas negociações com o cliente.
O cronograma e o plano do projeto é rastreado pelo gerente durante os processos de
planejamento, controle e execução do projeto, conforme proposto pelo PMBOK (2000), CMM –
nível 2, área chave de planejamento de projeto de software (PAULK et al., 2000) e de acordo
com as necessidades do projeto e as diretrizes da organização.
Finalmente, após a implementação e testes do produto e com base nos artefatos principais
(subsistemas e produto final do sistema) será realizada a última contagem de PF (atividade 8)
para subsidiar os acertos finais com o cliente, antes de disponibilizar o produto e encerrar o
processo de gestão do projeto.
A contagem inicial em PCU, a projeção de PF e todas as contagens de PF realizadas
durante o desenvolvimento do projeto, devem ser armazenadas em repositórios de cada
organização. Com base na contagem de diversos projetos é possível refinar a equação de relação
entre PCU e APF e projetar PF com maior precisão para a organização.
 102

&RQVLGHUDo}HVILQDLVGRFDStWXOR

Este capítulo apresentou um processo de gestão de estimativa de tamanho de software,

definido de forma integrada com os processos de desenvolvimento e gestão de projetos de
software.
Para subsidiar este processo, foram realizadas as seguintes atividades: i) padronização dos
procedimentos de contagem da APF e PCU para projetos de software OO conforme a literatura;
ii) aplicação dos procedimentos de contagem da APF e PCU em 19 projetos, sendo nove da
academia e dez da indústria; iii) investigação da relação entre PCU e APF com base nos
resultados da contagem dos projetos da academia e indústria; e iv) identificação das ações
gerenciais a serem tomadas pelos gerentes de projeto quando o cronograma é impraticável de se
realizar, está dentro do prazo ou está atrasado.
Em relação à aplicação dos procedimentos de contagem da APF e PCU nos projetos da
academia e indústria, observou-se que para fazer uma contagem com mais precisão é de
fundamental importância que o projeto seja bem documentado e que haja possibilidade de
realizar entrevistas com o gerente ou membros da equipe envolvida no projeto para
esclarecimento de dúvidas ou complementação das informações necessárias para a realização da
estimativa. Isto é importante porque nem sempre todas informações estão explícitas na
documentação do software.
Em alguns dos projetos contados detectou-se inconsistência em relação aos casos de uso
descritos no modelo de análise e os realizados no modelo de projeto. Este tipo de inconsistência
dificulta a contagem e pode contribuir para uma estimativa imprecisa. Dessa forma, pode-se
destacar que a aplicação da APF e PCU ajuda a determinar o nível de qualidade e adequação da
documentação do projeto. Portanto, é recomendável que a documentação seja mantida atualizada
e consistente durante todo o processo de desenvolvimento do projeto.
Ainda em relação à documentação dos projetos, pode-se destacar que os diagramas e
descrição de casos de uso, o diagrama de seqüência e os diagramas de análise e projeto de classes
são fundamentais para a realização de estimativas com maior precisão porque esses diagramas
fornecem informações relevantes para a realização das estimativas de tamanho.
Quanto à identificação das características técnicas do sistema, observou-se uma certa
dificuldade entre os gerentes com pouca experiência em desenvolvimento de software OO para
 103

indicar os níveis de influência dos fatores de ajustes técnicos e ambientais no projeto conforme
observadas por Anda et al.(2001).
Além dos pontos destacados acima, foram observados outros aspectos específicos à
contagem de PCU realizadas nos projetos da academia e indústria tais como:
i) Os diagramas de caso de uso e respectivas descrições quando elaboradas através
de padrões pré-definidos pela organização e com base em um mesmo processo de
desenvolvimento de software facilitam, o processo de contagem.
ii) A identificação das transações dos casos de uso é complexa devido ao certo grau
de subjetividade existente nesse tipo de contagem. É muito importante o
entendimento claro do significado de uma transação entre diferentes contadores de
uma mesma organização.
iii) A realização da estimativa em PCU é rápida, exige muito pouco esforço e pode
trazer muitos benefícios para a organização já que é realizada no início do projeto.
iv) A precisão da estimativa em PCU vai depender da qualidade da análise de
requisitos, o que poderá influenciar na estimativa realizada por qualquer método
usado na fase inicial do projeto. Devido a isso, é de fundamental importância que
a estimativa inicial seja refinada ao longo do processo de desenvolvimento em
APF como proposto neste trabalho.
Em relação à contagem de PF, as seguintes considerações são relevantes:
i) As classes e respectivos atributos responsáveis pela realização de cada transação
devem ser descritos de forma explícita para facilitar a identificação da
complexidade das funções transacionais, já que a complexidade depende do
número de arquivos e elementos de dados referenciados.
ii) A contagem de PF é mais detalhada e complexa, e torna-se mais precisa à medida
que novos artefatos são gerados durante o desenvolvimento conforme já
comprovado em experiências anteriores disponíveis na literatura.
A investigação da relação entre PCU e APF, foi realizada com base nos resultados da
contagem dos projetos da academia e indústria. Esses resultados foram analisados e utilizados
em testes estatísticos para identificar a equação de relação entre as duas métricas.
De acordo com os resultados obtidos nesses testes, podem-se fazer as seguintes
considerações:
 104

i) Para os projetos estudados foi constatado que a relação entre PF e PCU pode ser
descrita pelas equações 3)   3&8 para projetos da academia e 3) 
 3&8 para projetos da indústria comprovando a primeira suposição deste
trabalho.
ii) As equações acima podem ser usadas para projetar valores para PF a partir de
valores de PCU indicando que a APF e PCU podem ser utilizadas de forma
complementar e o uso combinado destas métricas pode gerar estimativa mais
seguras, pois a estimativa realizada no início pode ser refinada à medida que novas
contagens de PF forem realizadas durante o processo de desenvolvimento do
projeto de software Dessa forma, o gerente tem resultados reais para poder
comparar o plano e o cronograma do projeto e tomar decisões com maior
segurança.
iii) Recomenda-se que todos os resultados das estimativas e o histórico do projeto,
incluindo as ações gerenciais utilizadas para ajustes no projeto, sejam
armazenados em uma base de dados histórica para subsidiar a gestão de novos
projetos e melhorar os processos de gestão de estimativa da empresa, o de gestão e
desenvolvimento de projetos de software.
Neste capítulo, foi realizado ainda, um estudo para identificar as ações gerenciais a serem
tomadas pelo gerente do projeto durante a execução do processo de gestão de estimativas. 
Finalmente, considerando os procedimentos de contagem apresentados no capítulo 2 e na
seção 4. 3 deste capítulo, a equação de relação encontrada entre a APF e PCU e as ações
gerenciais identificadas foi definido o processo de gestão de estimativa de tamanho integrado
com os processos de gestão e desenvolvimento de software conforme mostra a Figura 7.
 105

&DStWXOR&RQFOXVmRHSHUVSHFWLYDVIXWXUDV

No mercado competitivo atual, uma preocupação constante das organizações é o

cumprimento de cronogramas e o custo efetivo de seus projetos de desenvolvimento de software.
Todas estas características dependem de um gerenciamento adequado do projeto. Nesse
gerenciamento é de fundamental importância que o plano efetivo do projeto se baseie em
estimativas mais precisas de tamanho, uma vez que, o tamanho de um projeto de software é uma
das primeiras estimativas a ser realizada, pois dessa dimensão depende a definição do esforço,
custos e prazos necessários para a definição do plano de desenvolvimento do software.
Diante desta necessidade, este trabalho teve como objetivo propor aos gerentes uma
melhor forma de estimar, revisar e recalcular o tamanho do projeto à medida que novos artefatos
estejam disponíveis durante o processo de desenvolvimento do projeto de software orientado a
objetos. Para atender a este objetivo foram definidos os seguintes objetivos específicos:
i) Estudar as principais características da APF e PCU e aplicá-las em projetos de
software orientados a objetos;
ii) Investigar a existência de relação entre as métricas APF e PCU;
iii) Definir uma equação que descreva esta relação e possa ser usada para projetar PF
a partir de PCU;
iv) Identificar as ações gerenciais a serem tomadas pelo gerente durante o controle e
acompanhamento do projeto.
Para atender o objetivo i) foram estudadas as principais características da APF e PCU e
padronizados os procedimentos de contagem da APF e PCU para projetos de software OO.
Posteriormente, estes procedimentos foram aplicados em 19 projetos de software OO
desenvolvidos pela academia e indústria, buscando a relação entre as estimativas de APF e PCU.
De acordo com os resultados obtidos através da aplicação da APF e PCU em projetos OO
da academia e da indústria e com a investigação da relação entre PCU e APF foram atendidos os
objetivos ii) e iii) e aceitas às suposições inicialmente definidas neste trabalho: i) há uma relação
linear entre PF e PCU, e a equação que descreve essa relação pode ser utilizada para projetar PF
a partir de PCU logo no início do projeto; e ii) a APF e PCU podem ser utilizadas de forma
combinada.
 106

Foi constatado também que a equação que descreve a relação entre PF e PCU nos projetos
da academia (3)   3&8) difere daquela que descreve a mesma relação em projetos da
indústria (3) 3&8).
Para atender o objetivo iv) foi realizado um estudo entre 37 gerentes de projeto da
indústria da academia visando identificar as ações gerenciais a serem tomadas pelo gerente,
quando o cronograma for impraticável de se realizar, tiver dentro do prazo mas precisa ser
controlado e quando tiver atrasado. Os resultados deste estudo foram apresentados no capítulo 4,
seção 4.5.
Finalmente, com base nos resultados acima foi proposto um processo de gestão de
estimativa de tamanho de forma integrada com os processos de desenvolvimento e gestão de
projetos de software. Dessa forma, o gerente poderá estimar, revisar e recalcular o tamanho do
projeto à medida que novos artefatos estejam disponíveis durante o processo de desenvolvimento
do projeto de software orientado a objetos.
Portanto, como contribuições deste trabalho, podem ser destacadas:
i) a proposição de um processo de gestão de estimativa de tamanho de projetos de
software relacionado com os processos de desenvolvimento e gestão de projeto de
software e combinando o uso da APF e PCU, nas fases do processo de
desenvolvimento do projeto nas quais estas métricas têm aplicação mais adequada;
ii) a identificação da equação de relação entre PF e PCU para a academia e indústria,
o que indica que cada organização pode encontrar a equação de relação entre estas
métricas com base em dados de projetos reais desenvolvidos internamente e pode
usar a equação e o resultado da contagem de PCU para projetar PF no início do
projeto e assim usar a APF e PCU de forma combinada.
iii) a lista de ações a serem tomadas pelos gerentes durante a execução e controle do
projeto.
Assim, o gerente poderá usar o processo de gestão de estimativa de tamanho conforme
proposto, de forma relacionada com os processos de desenvolvimento e gestão de projetos,
especialmente, a gestão de tempo (cronograma) para garantir maior precisão nas estimativas de
tamanho e, conseqüentemente, nas estimativas de custo, esforço e produtividade da equipe. Dessa
forma, o gerente poderá gerenciar o projeto de forma mais eficiente, tomando decisões com base
 107

nas ações gerenciais identificadas neste estudo e garantindo melhoria dos processos, da qualidade
do produto e da satisfação do cliente.
Os resultados deste trabalho indicam várias perspectivas de pesquisas conforme descrito a
seguir.
i) realizar novas estimativas de PF e PCU nos projetos da Empresa A, B e C
utilizados nesta pesquisa, assim que o desenvolvimento dos mesmos for
concluído. Com base nos resultados dessas estimativas, gerar nova equação de
relação para validar a equação gerada neste trabalho quando os referidos projetos
ainda estavam em desenvolvimento;
ii) implantar o processo de gestão de estimativa de tamanho de projetos em uma das
empresas que participaram desta pesquisa, para verificar a adequação da equação
de relação encontrada entre a APF e CPU na projeção de PF de novos projetos e
das ações gerenciais indicadas neste trabalho;
iii) definir uma ferramenta para apoiar o processo e garantir o reuso do histórico das
estimativas realizadas durante o processo de desenvolvimento do projeto;
iv) definir como o processo de gestão de estimativa de tamanho pode ser realizado
iterativamente considerando o desenvolvimento dirigido por casos de uso;
v) verificar a possibilidade de contar as funções transacionais através dos métodos
das classes definidos no diagrama de classes, conforme proposto por Minkiewicz
(1997) citado por Caldiera, et al. (1998)
 108

5HIHUrQFLDVELEOLRJUiILFDV

ABDEL-HAMID, T. Software project control: an experimental investigation of judgment with

fallible information ,((( 7UDQVDFWLRQV RQ 6RIWZDUH (QJLQHHULQJ. V. 19, n. 6, June,
1993. p. 603 – 612.
ABRAN, A. et al. Functional size measurement methods: COSMIC-FFP: design and field trials.
In: FESMA-AEMES Software Measurements Conference. 2000.
AGUIAR, M. Pontos de função ou pontos de caso de uso? Como estimar projetos orientados a
objetos. 'HYHORSHUV¶0DJD]LQH V. 7, n. 77. Jan., 2003.
ANDA, B. Comparing effort estimates based on Use Case Points with expert Estimates.
(PSLULFDO$VVHVVPHQWLQ6RIWZDUH(QJLQHHULQJ($6( Keele, UK, April, 8 – 10,
2002. 13 p.
________; et al. Estimating software development effort based on use cases: experiences from
industry. In: International Conference on the Unified Modeling Language (UML2001), 4.
3URFHHGLQJV Toronto, Oct. 1 – 5, 2001, p. 487 – 502.
ARNOLD, M.; PEDROSS, P. Software size measurement and productivity rating in a large-scale
software development department. In: International Conference on Software Engineering,
20. 3URFHHGLQJV 1998. p. 490 – 493. Disponível
em:http://dlib2.computer.org/conferen/icse/8368/pdf/83680490.pdf? Acesso em 25/02/03.
A ROLE- BASED guide to the Rational Unified Process. March, 2003. Ch. 14, p. 271.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). 1%5 ,62,(& :
Gestão da qualidade: diretrizes para a qualidade de gerenciamento de projetos. Rio de
Janeiro:ABNT. 2000. 17 p.
________. 1%5 ,62,(& : Tecnologia de Informação: processos do ciclo de vida de
software. Rio de Janeiro:ABNT. 1998. 38 p.
BASILI. V.; CALDIERA, G.; ROMBACH, H. Goal Question Metric paradigm. In:
(QF\FORSpGLDRI6RIWZDUH(QJLQHHULQJ. V. 2, 1994. p. 527 –532.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. 7KH XQLILHG PRGHOLQJ ODQJXDJH XVHU JXLGH
Reading: ADDISON-WESLEY. 1999. 482p.
CALDIERA, G et al. Definition and experimental evaluation of Function Points for object-
oriented systems. In: International Symposium on Software Metrics , 5. 3URFHHGLQJV
 109

IEEE. March 20 – 21, 1998, Bethesda, Maryland. P. 167 – 179. Acesso em 10/02/03
Disponível em: http://dlib2.computer.org/conferen/ metrics/9201/ pdf/92010167.pdf?
CARBONE, M.; SANTUCCI,G. )DVW 6HULRXV UML based metrics for effort estimation.S. d.
CUNHA, G.; ALMEIDA, E. Estimativa de projetos com base em Casos de Uso. In: SIMPÓSIO
INTERNATIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE (SIMPROS), 4,
2003, Recife. $QDLV Recife, CenPRA/SENAC. 2003. p. 53 - 60.
DAMODARAN, M; WASHINGTON, A. Estimation using use case points. &RPSXWHU6FLHQFH
3URJUDP Texas –Victoria: University of Houston. S.d. 4 p. Disponível em:
http://bfpug.com.br/Artigos/UCP/Damodaran-Estimation_Using_Use_Case_Points.pdf
Acesso em 22/09/2003.
DEKKERS, C. Measuring the ‘logical’ or ‘functional’ size of software projects and software
application. ,62%8//(7,1 May, 2003. p. 10 – 13.
________; McQUAID. P. The dangers of using software metrics to (Mis)Manage. ,(((
Mar./Apr.2002. p. 24 – 30.
________. Uses Cases and Function Points – Where´s the Fit? In: 0HWULFV 6WUDWHJLHV.
Jan.1999.6 p.
FARIAS, L. D. 3ODQHMDPHQWR GH ULVFRV HP DPELHQWHV GH GHVHQYROYLPHQWR GH VRIWZDUH
RULHQWDGRVDRUJDQL]DomR. Rio de Janeiro, UFRJ/COPPE. Tese (Mestrado).
FEITOSA, C.; JANSEN, S. Processo de estimativa e acompanhamento de tamanho e esforço para
o ProSCes. In: Encontro da Qualidade e produtividade em software (EQPS), 2003,
Fortaleza. Fortaleza, MCT. 10 slides. Disponível em: http://www.google.com.br. Acesso
em 19/12/2003.
FENTON, N., NEIL, M. Software Metrics: Roadmap. )XWXUH RI 6RIWZDUH (QJLQHHULQJ
/LPHULFN,UHODQG $&0 p. 359-370, 2000.
_______; PFLEEGER, S. 6RIWZDUH PHWULFV a rigorous & practical approach. Boston: PWS
Publishing Company, 1997. 638 p.
_______. 6RIWZDUH0HWULFVa rigorous approach. Chapman & Hall; 1991.
FETCKE, T.; ABRAN, A; NGUYEN, T. 0DSSLQJWKH22-DFREVRQDSSURDFKLQWR)XQFWLRQ
3RLQW$QDO\VLV 1997. 11 p. Acesso em 10/02/2003.Disponível em:
http://dlib2.computer.org/conferen/tools/8383/pdf/83830192.pdf?
 110

FREUND, R. & LITTELL, R. 6$66\VWHPIRUUHJUHVVLRQ: SAS series in statistical applications.

2.ed. Cary: SAS Institute Inc. 1991. 210p.
FUREY, S. Why we should use Function Points. ,((( Mar./April, 1997. 2 p.
GARMUS, D., HERRON, D. )XQFWLRQ 3RLQW $QDO\VLV Measurement Practices for successful
software projects. Addison-Wesley: EUA. 2000. 363 p.
GUPTA R.; GUPTA S. Object Point Analysis. In: IFPUG Conference, 1996. 3URFHHGLQJV
Dallas, 1996.
HAZAN, C. $QiOLVH GH 3RQWRV SRU )XQomR: uma abordagem gerencial. Rio de Janeiro,
SERPRO. 1999. 1 v.
IFPUG. International Function Point Users Group. )XQFWLRQ 3RLQW &RXQWLQJ 3UDFWLFHV Case
Study 3 – Analysis, Construction. Release 2.0. Princeton Junction: IFPUG. 2001. 246 p.
_______. )XQFWLRQ3RLQW&RXQWLQJ3UDFWLFHV0DQXDO Release 4.1. Ohio: IFPUG. 2000. 1 v.
INTERNATIONAL SOFTWARE BENCHMARKING STANDARDS GROUP (ISBSG).
Benchmarking Repository, Release 6. ISBSG. Abr, 2002.
INTERNATIONAL STANDARD ORGANIZATION (ISO).,62,(& '75 :Software
Engineering:Guide for the application of ISO/IEC 12207 to project management.1999.31 p.
________. ,62,(&75 Information technology: Software process assessment – part 1:
concepts and introductory guide. 1998.
JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. 8QLILHG 6RIWZDUH 'HYHORSPHQW 3URFHVV.
Addison-Wesley, 1996.
JOHNSON, D.; BRODMAN, J. Applying CMM project planning practices to diverse
environments. IEEE Software. July/Aug. 2000. p. 40 – 47.
JONES, C. Software Challenges: )XQFWLRQSRLQW a new way of looking at tools. Computer,
August, 1994. p. 66 – 67. Acesso em 24/02/03.Disponível em:
http://dlib2.computer.org/co/books/co1995/pdf/rx102.pdf?
JORGENSEN, M.; INDAHL, U.; SJOBERG, D. (IIRUWHVWLPDWLRQ: software effort estimation
by analogy and regression toward the mean. 18p.
JURISON, J. Software project management: the manager’ s view. &RPPXQLFDWLRQV RI WKH
DVVRFLDWLRQIRU,QIRUPDWLRQ6\VWHPVV. 2, article 17, Sep. 1999. 56 p.
KARNER, G. 8VH &DVH 3RLQWV: resource estimation for Objectory projects. Objective Systems
SF AB (copyright owned by Rational/IBM), 1993.
 111

KITCHENHAM, B. Counterpoint: the problem with Function Point. ,(((6RIWZDUHMarch,

19972 p. Acesso em 10/02/03.Disponível em:
http://dlib2.computer.org/so/books/so1997/pdf/s2029.pdf?
KUSUMOTO, S; INOUE, K.; KASIMOTO, T. Function Point Measurement for Object-Oriented
Requirements Specification. In: Annual International Computer Software and Aplications
Conference, 24. 3URFHHGLQJV IEEE, 2000. 6p.
http://dlib2.computer.org/conferen/COMPSAC/0792/pdf/07920543.pdf? Acesso em:
10/02/03.
LONGSTREET, D. )XQGDPHQWDOV RI )XQFWLRQ 3RLQW $QDO\VLV. Blue Springs: Longstreet
Consulting Inc., 2002. Disponível em: http://www.ifpug.com/Articles/default.htm. Acesso
em 01/04/03.
________. 8VH &DVH DQG )XQFWLRQ 3RLQW Blue Springs: Longstreet Consulting Inc., 2000.
Disponível em: http://www.ifpug.com/fpafund.htm. Acesso em 04/04/03.
MARKUS, R. (OHPHQWRVGHHVWDWtVWLFDDSOLFDGD. Porto Alegre: UFRGS, 1974. 327p.
McGARRY, J. et al. 3UDFWLFDO VRIWZDUH PHDVXUHPHQW objective information for decision
makers. Boston: Addison-Wesley. 2001. 277p.
McPHEE, C. 6(1*: Software process management:software size estimation. University of
Calgary. 1999. 11p. Disponível em:
http://sern.ucalgary.ca/~cmcphee/SENG621/Software_Size_Estimation.html Acesso em
19/09/03
MCT. MINISTÉRIO DE CIÊNCIA E TECNOLOGIA. Notícias de TI: mercado de software
crescerá 5,3% em 2004. Notícia publicada na Computerworld em 12/11/03. 2003a. Acesso
em 06/01/2004. Disponível em:
http://www.mct.gov.br/Temas/info/Imprensa/Noticias_Anteriores/Noticias_2003/Software
_2003.htm
_______. Notícias de TI: uma vitória do software brasileiro. Notícia publicada no Estadão em
29/09/03. 2003b. Acesso em 06/01/2004. Disponível em:
http://www.mct.gov.br/Temas/info/Imprensa/Noticias_Anteriores/Noticias_2003/Software
_2003.htm.
_______. 4XDOLGDGH HSURGXWLYLGDGHQRVHWRUGH VRIWZDUH EUDVLOHLUR Brasília: Ministério de
Ciência e Tecnologia. Secretaria de Política de Informática. 2002. 258p. (n. 4).
 112

MISIC, V.; TESIC, D. Downsizing the estimation of software quality: a small object-oriented
case study. In: Technology of Object-Oriented Languages and Systems. 3URFHHGLQJV S.d.
10 p. Disponível em: http://dlib2.computer.org/conferen/tools/9096/pdf/90960308.pdf?
Acesso em: 25/02/03.
MÖLLER, K.H.; PAULISH, D.J.; 6RIWZDUH0HWULFVa practioner'
s guide to improved product
development. IEEE Computer Society Press, Chapmam & Hall; 1993
MURTHI, Sanjay. Preventive risk management for software projects. ,(((±,73UR Sep./Oct.,
2002. p. 9 – 15.
NETER, J; WASSERMAN, W; KUTNER, M. $SSOLHGOLQHDUUHJUHVVLRQPRGHOV. Homewood:
IRWIN. 1989. 667 p. il.
NETER, J; WASSERMAN, W. $SSOLHGOLQHDUVWDWLVWLFDOPRGHOV Homewood, Illinois: Richard
D. Irvin, 1974.
PAULK, M. et al. 7KH FDSDELOLW\ PDWXULW\ PRGHO: guidelines for improving the software
process. Boston: Addison Wesley. 2000. 441p. Carnegie Mellon University: Software
Engineering Institute.
PITTMAN, Matthew. Lessons learned in managing object-oriented development. ,(((
6RIWZDUH. Jan. 1993, 43 – 53 p.
PMBOK. 3URMHFW 0DQDJHPHQW %RG\ RI .QRZOHGJH Belo Horizonte: PMIMG, 2000 (edição
traduzida pelo PMI/MG).
PRESSMAN, R. (QJHQKDULDGH6RIWZDUH5. ed.Rio de Janeiro: McGraw-Hill, 2002. 843 p.
PROBASCO, L. Dear Dr. Use Case: what about Function Point and Use Cases? 7KH5DWLRQDO
(GJH 2002. Disponível em:
http://www.therationaledge.com/content/au_02/t_drUseCase_lp.jsp Acesso em 30/10/03.
RAM, J.; RAJU, S. Object oriented design function points. In: Asia-Pacific Conference on
Quality Software, 1. 3URFHHGLQJV IEEE, 2000. 6 p. Disponível em: http://dlib2.
computer.org/conferen/apaqs/0825/pdf/08250121.pdf? Acesso em 10/02/03.
RATIONAL UNIFIED PROCESS. 5DWLRQDO 8QLILHG 3URFHVV best practices for software
development teams 2001a Rational. 2001a. Acesso em 25/01/04. Disponível em:
http:///www.rational.com/media/whitepapers/rup_bestpractices.pdf.
 113

BBBBBBBB5DWLRQDO6RIWZDUH&RUSRUDWLRQ 1997-2000, 2001b (www.rational.com)

REEL, J. S. Critical success factors in software projects. ,(((6RIWZDUH May/June, 1999 p. 18
– 23.
RIBU, K. (VWLPDWLQJ REMHFWRULHQWHG VRIWZDUH SURMHFWV ZLWK XVH FDVHV. Oslo: University of
Oslo, 2001.132 p. Tese (Mestrado– Department of Informatics)
ROSS, M. Size does matter: continuous size estimating and tracking. 4XDQWLWDWLYH 6RIWZDUH
0DQDJHPHQW Disponível em: http://www.qsm.com. Acesso em 19/09/03. s.d . 16 p.
SCHNEIDER, G.; WINTERS, J. Use case and project plan. In: ----------. $SS\LQJXVHFDVHV a
practical guide. 2. ed. New York: Addison Weslwy, 2001. capítulo 10, p. 143 – 159.
SMITH, J. 7KH HVWLPDWLRQ RI HIIRUW EDVHG RQ 8VH &DVHV Rational software white paper.
Cupertino: Rational Software. 1999. 15 p.
SMITH & CODY, R. $SSOLHGVWDWLVWLFVDQGWKH6$6SURJUDPPLQJODQJXDJH. 3.ed. New York:
North-Holland. 1991. 443p.
SOLINGEN, R.; BERGHOUT, E. 7KH *RDO4XHVWLRQ0HWULF PHWKRG: a practical guide for
quality improvement of software development. London: McGraw-Hill. 1999. 199p.
SYMONS, C. R. Function Point Analysis: difficulties and improvements. ,((( 7UDQVDFWLRQV
RQ 6RIWZDUH (QJLQHHULQJ V. 14, n. 1, Jan. 1988. 11p. Disponível em:
http://dlib2.computer.org/ts/ books/ts1988/pdf/e0002.pdf Acesso em 10/02/03.
TICHENOR, C. B. The internal revenue service function point analysis program: a brief. In:
Intenational Computer Software and Application Conference, 21. 3URFHHGLQJV 1997. p.
591 – 592. Disponível em: http://dlib2.computer.org/ conferen/
compsac/8105/pdf/81050591.pdf? Acesso em 25/02/03.
THOMSETT, Rob. ([WUHPH SURMHFW PDQDJHPHQW executive report. V. 2, n. 2, 2002. 32 p.
Disponível em: http://www.cutter.com/consortium.
UEMURA, T.; KUSUMOTO, S.; INOUE, K. Function point measurement tool for UML design
specification. In: International Symposium on Software Metrics , 6. $QDLV IEEE, 1999, p.
62 –69. Disponível em: http://dlib2. computer.
Org/conferen/metrics/0403/pdf/04030062.pdf? Acesso em 10/02/03.
VALENÇA, A. (VWLPDWLYDGHHVIRUoRGHVRIWZDUHRULHQWDGRDREMHWRV. Recife. 2003.43 p.
WOHLIN et al. ([SHULPHQWDWLRQ LQ VRIWZDUH HQJLQHHULQJ an introduction. Boston: Kluwer
Academic Publisheres. 2000. 204 p.
 114

$SrQGLFHV

$SrQGLFH$&DUDFWHUtVWLFDVJHUDLVHDPELHQWDLVTXHLQIOXHQFLDPQRVLVWHPD

Este questionário visa identificar o nível de influência das características técnicas, de acordo com a APF-
IFPUG (2001) e PCU- KARNER (1993), e das características ambientais propostas por KARNER (1993) em
projetos de desenvolvimento de software Orientado a Objetos.

&$5$&7(5,=$d­2'2*(5(17('2352-(72280(0%52'$(48,3(

1RPH2SFLRQDO  (PDLO2SFLRQDO 

ÈUHDGH$WXDomR
LQG~VWULD  DFDGHPLD
Gerente de TI Professor
Gerente de projeto Pesquisador
Membro de projeto Aluno de graduação
Consultor/Contador Consultor/Contador
)RUPDomRNível e Área([SHULrQFLD
Doutorado ( ) Eng de Software ( ) Outro Tempo de atuação em gestão de projetos ( ) anos
Mestrado ( ) Gestão de TI e do ( ) Outro
Número de projetos gerenciados ( ) projetos
Conhecimento
Experiência em gestão de estimativas: (tempo, riscos,
Especialização ( ) Análise de Sistemas recursos, custos, etc.)
( ) Outro
( ) Alta ( ) Média ( ) Baixa ( ) Nenhuma

Graduação ( ) Ciência da Computação
( ) Outro
Certificação ( ) IFPUG ( ) PMI 
7tWXORGRSURMHWRVLVWHPD

,16758d®(6
Assinale o grau de influência de cada característica abaixo no projeto ou sistema de acordo com a escala de 0 a 5.
Após responder as questões abaixo encaminhe o arquivo com suas respostas para o seguinte e-mail:
edmeia.andrade@embrapa.br ou edmeiaandrade@brturbo.com .

&$5$&7(5Ë67,&$67e&1,&$63523267$63(/$$3)±,)38*
&RPXQLFDomRGHGDGRV±Os dados e as informações de controle utilizados na aplicação são enviados ou
recebidos através de recursos de comunicação de dados.
0 ( ) O processamento da aplicação é puramente EDWFK ou é executado em um PC isolado.
1 ( ) A aplicação é EDWFK mas tem entrada de dados remota ou impressão remota.
2 ( ) A aplicação é EDWFK mas tem entrada de dados remota e impressão remota.
3 ( ) Captura de dados RQOLQH via terminal de vídeo ou via um processador IURQWHQG, para alimentar processos
EDWFK ou sistemas de consultas (4XHU\6\VWHPV).
4. ( ) Mais que um IURQWHQG, mas a aplicação suporta apenas um tipo de protocolo de comunicação.
5. ( ) Mais que um IURQWHQG e a aplicação suporta mais de um tipo de protocolo de comunicação.
3URFHVVDPHQWRGLVWULEXtGR±Dados ou processamento distribuído entre várias unidades de processamento – CPU
 115

0 ( ) A aplicação não auxilia na transferência de dados ou processamento entre as CPUs da instalação.

1 ( ) A aplicação prepara dados para o usuário final processar em outra CPU da instalação. Por exemplo, planilhas
eletrônicas ou gerenciadores de banco de dados de PC.
2 ( ) Os dados são preparados para transferência, transferidos e processados em uma outra CPU da instalação (mas
NÃO para processamento pelo usuário final como visto no item 1).
3 ( ) Processamento distribuído e transferência de dados RQOLQH apenas em uma direção.
4. ( ) Processamento distribuído e transferência de dados RQOLQH em ambas direções.
5 ( ) As funções de processamento são executadas dinamicamente na CPU mais apropriada.
'HVHPSHQKR± Identifica os objetivos de SHUIRUPDQFH da aplicação estabelecidos e aprovados pelo usuário
0 ( ) Nenhuma exigência especial de SHUIRUPDQFH foi fixada pelo usuário.
1 ( ) Requisitos de SHUIRUPDQFH foram estabelecidos e revisados, mas nenhuma ação especial foi necessária.
2 ( ) O tempo de resposta é crítico durante as horas de pico. O intervalo de tempo limite (GHDGOLQH) do
processamento é sempre para o próximo dia útil. Nenhuma consideração especial para utilização de CPU foi
requerida.
3 ( ) O tempo de resposta é crítico durante todo o horário de utilização. Os requisitos de prazo de processamento
com outros sistemas são limitantes. Não foi necessário nenhum procedimento especial para utilização de CPU.
4. ( ) Os requisitos de SHUIRUPDQFH estabelecidos pelo usuário são rigorosos o bastante para requerer tarefas de
análise de SHUIRUPDQFH na fase de análise e projeto da aplicação.
5 ( ) Além do descrito no item 4, ferramentas de análise de SHUIRUPDQFH foram usadas nas fases de projeto,
desenvolvimento e/ou implementação a fim de proporcionar a SHUIRUPDQFH estabelecida pelo usuário.
8WLOL]DomRGHHTXLSDPHQWR – Há necessidade de se fazer considerações especiais no projeto do sistema para que a
configuração do equipamento não fique sobrecarregada.
0 ( ) Não há restrições operacionais explícitas ou implícitas.
1 ( ) Existem restrições operacionais, mas são menos restritivas do que aplicações típicas. Nenhum esforço extra é
necessário para suplantar as restrições.
2 ( ) Algumas considerações sobre tempo e segurança são necessárias.
3 ( ) Necessidades especiais de processador para uma parte específica da aplicação.
4 ( ) Restrições operacionais estabelecidas requerem atenção especial a nível de processador central ou processador
dedicado para executar a aplicação.
5 ( ) Além do descrito acima, existem sobrecargas a nível das unidades de processamento (CPUs) distribuídas da
instalação.
9ROXPHGHWUDQVDo}HV – É alto e tem influência no projeto, desenvolvimento, implantação e manutenção da
aplicação.
0 ( ) Nenhum período de pico de transações é esperado.
1 ( ) Picos de transações mensais, quadrimestrais, sazonais e anuais são esperados.
2 ( ) Picos semanais de transações são esperados.
3 ( ) Picos diários de transações são esperados.
4 ( ) Altos volumes de transações foram fixados pelo usuário para a aplicação, o que força a execução de tarefas de
análise de performance na fase de projeto da aplicação.
5 ( ) Requer o uso de ferramentas de análise de performance nas fases de projeto, desenvolvimento e/ou
implantação, além das considerações acima.
(QWUDGDGHGDGRV2QOLQH±A aplicação possui funções que fornecem entrada de dados e informação de controle
RQOLQH
0 ( ) Todas as transações são processadas em modo EDWFK
1 ( ) 1% a 7% das transações são entradas de dados interativas.
2 ( ) 8% a 15% das transações são entradas de dados interativas.
3 ( ) 16% a 23% das transações são entradas de dados interativas.
4. ( ) 24% a 30% das transações são entradas de dados interativas.
5. ( ) Mais de 30% das transações são entradas de dados interativas.
(ILFLrQFLDGRXVXiULRILQDO±As funções RQOLQH fornecidas enfatizam um projeto da aplicação voltado para a
eficiência do usuário final.
 116

• Menus
• Documentação/Help 2QOLQH
• Movimento automático do cursor
• Movimento de Tela (VFUROOLQJ) vertical e horizontal
• Impressão remota (via transações RQOLQH)
• Teclas de Função pré-definidas
• Execução de jobs EDWFK a partir de transações RQOLQH
• Seleção de dados da tela via movimentação do cursor
• Uso intenso de vídeo reverso, brilho intensificado, sublinhado, cores e outros recursos de vídeo
• Documentação de transações RQOLQH via KDUGFRS\
• Interface para mouse
• 3RSXS Windows
• O mínimo possível de telas para executar as funções do negócio
• Fácil navegação entre telas (por exemplo, através de teclas de função)
• Suporte bilíngüe (suporta dois idiomas, contar como quatro itens)
• Suporte multilingüe (suporta mais de dois idiomas, contar como seis itens)
0 ( ) A aplicação não apresenta nenhum dos itens acima.
1 ( ) Apresenta de 1 a 3 dos itens acima.
2 ( ) Apresenta de 4 a 5 dos itens acima.
3 ( ) Apresenta 6 ou mais dos itens acima, mas não há nenhum requisito do usuário relacionado à eficiência.
4. ( ) Apresenta 6 ou mais dos itens acima, e os requisitos estabelecidos para eficiência do usuário são rigorosos o
suficiente para que a fase de projeto da aplicação inclua fatores para: minimizar a digitação, maximizar os
GHIDXOWV, utilizar WHPSODWHVetc.
5. ( ) Apresenta 6 ou mais dos itens acima, e os requisitos estabelecidos para eficiência do usuário são rigorosos o
suficiente para que seja necessário o uso de ferramentas e processos especiais para demonstrar que os
objetivos de eficiência foram alcançados.
$WXDOL]DomRRQOLQH±A aplicação possibilita a atualização RQOLQH dos Arquivos Lógicos Internos.
0 ( ) Nenhuma atualização.
1 ( ) Atualização RQOLQH de 1 a 3 arquivos de controle. O volume de atualizações é baixo e a recuperação de dados
é simples.
2 ( ) Atualização RQOLQH de 4 ou mais arquivos de controle. O volume de atualizações é baixo e a recuperação de
dados é simples.
3 ( ) Atualização RQOLQH da maioria dos Arquivos Lógicos Internos.
4. ( ) Além dos itens anteriores, a proteção contra perda de dados é essencial e foi especificamente projetada e
codificada no sistema.
5. ( ) Além dos itens anteriores, altos volumes de dados trazem considerações sobre custo para o processo de
recuperação. Exigem procedimentos de recuperação totalmente automatizados com a mínima intervenção
do operador.
3URFHVVDPHQWRFRPSOH[R±Pode ser dividido nas seguintes categorias:
• Processamento especial de auditoria e/ou processamento especial de segurança.
• Processamento lógico extensivo.
• Processamento matemático extensivo.
• Grande quantidade de processamento de exceções, resultante de transações incompletas que necessitam
de reprocessamento. Por exemplo: transações incompletas de ATMs causadas por interrupções de
comunicação, valores de dados ausentes ou validações de erros.
• Processamento complexo para manipular múltiplas possibilidades de entrada/saída. Por exemplo:
múltiplos meios e independência de equipamentos.
0 ( ) Não apresenta nenhum dos itens acima.
1 ( ) Apresenta um dos itens acima.
2 ( ) Apresenta dois dos itens acima.
3 ( ) Apresenta três dos itens acima.
4 ( ) Apresenta quatro dos itens acima.
5 ( ) Apresenta todos os itens acima.
 117

5HXWLOL]DomRGHFyGLJR±A aplicação e o seu código foram especificamente projetados, desenvolvidos e

suportados para serem reutilizados em outras aplicações.
0 ( ) Não apresenta código reutilizável.
1 ( ) O código reutilizável é usado somente dentro da própria aplicação.
2 ( ) Menos de 10% da aplicação foi feita, levando-se em conta a sua utilização por outras aplicações.
3 ( ) 10% ou mais da aplicação foi feita, levando-se em conta a sua utilização por outras aplicações.
4. ( ) A aplicação foi projetada e documentada para facilitar a reutilização de código e a aplicação é customizada
pelo usuário a nível do código fonte.
5. ( ) A aplicação foi projetada e documentada para facilitar a reutilização de código e a aplicação é customizada
para uso através de parâmetros que podem ser atualizados pelo usuário.
)DFLOLGDGHGHLPSODQWDomR – Um plano de implantação e conversão de dados e/ou ferramentas de conversão de
dados foi preparado e testado durante a fase de testes dos sistemas.
0 ( ) Nenhuma consideração especial foi feita pelo usuário e nenhum procedimento especial foi requerido para a
implantação.
1 ( ) Nenhuma consideração especial foi feita pelo usuário, mas um procedimento especial foi requerido para a
implantação.
2 ( ) Requisitos de implantação e conversão de dados foram fixados pelo usuário, e roteiros de implantação e
conversão de dados foram preparados e testados. O impacto da conversão de dados no projeto não é
considerado importante.
3 ( ) Requisitos de implantação e conversão de dados foram fixados pelo usuário e roteiros de implantação e
conversão de dados foram preparados e testados. O impacto da conversão de dados no projeto é considerado
importante.
4. ( ) Além do descrito no item 2, ferramentas automatizadas de implantação e conversão de dados foram
preparadas e testadas.
5. ( ) Além do descrito no item 3, ferramentas automatizadas de implantação e conversão de dados foram
preparadas e testadas.
)DFLOLGDGHRSHUDFLRQDOProcedimentos efetivos de inicialização, EDFNXS e recuperação foram desenvolvidos e
testados. A aplicação minimiza a necessidade de atividades manuais, tais como montagem de fitas magnéticas,
manuseio de formulários e intervenção manual do operador.
0 ( ) Nenhuma consideração especial sobre facilidade operacional, além dos procedimentos normais de EDFNXS,
foi feita pelo usuário.
1 ( ) Procedimentos eficientes de inicialização, EDFNXS e recuperação foram preparados, mas a intervenção do
operador é necessária.
2 ( ) Procedimentos eficientes de inicialização, EDFNXS e recuperação foram preparados, mas nenhuma intervenção
do operador é necessária (contar como dois itens).
3 ( ) A aplicação minimiza a operação de montagem de fitas magnéticas.
4 ( ) A aplicação minimiza a necessidade de manuseio de formulários.
5. ( ) A aplicação foi projetada para não precisar de intervenção do operador no seu funcionamento normal.
Apenas a inicialização e parada do sistema ficam a cargo do operador. A recuperação automática de erros é
uma característica da aplicação.
0~OWLSORVORFDLVA aplicação foi especificamente projetada, desenvolvida e suportada para ser instalada em
múltiplos locais de uma organização ou para múltiplas organizações.
0 ( ) Nenhuma solicitação do usuário para considerar a necessidade de instalar a aplicação em mais de um local.
1 ( ) Necessidade de instalação em múltiplos locais foi levada em consideração no projeto do sistema e a aplicação
foi projetada para operar somente em ambientes idênticos de hardware e software
2 ( ) Necessidade de instalação em múltiplos locais foi levada em consideração no projeto do sistema e a aplicação
foi projetada para operar somente em ambientes similares de hardware e software
3 ( ) Necessidade de instalação em múltiplos locais foi levada em consideração no projeto do sistema e a aplicação
foi projetada para operar inclusive em ambientes diferentes de hardware e/ou software.
4. ( ) Um plano de documentação e manutenção foi elaborado e testado para suportar a aplicação em múltiplos
locais e a aplicação atende aos itens 1 e 2.
5. ( ) Um plano de documentação e manutenção foi elaborado e testado para suportar a aplicação em múltiplos
locais e a aplicação atende ao item 3.
)DFLOLGDGHGHPXGDQoDVA aplicação foi especificamente projetada, desenvolvida para suportar manutenção,
visando à facilidade de mudanças. Por exemplo:
 118

• capacidade de consultas/relatórios flexíveis está disponível

• dados de controle do negócio são agrupados em tabelas passíveis de manutenção pelo usuário.
0 ( ) Nenhum requisito especial do usuário para projetar a aplicação, visando minimizar ou facilitar mudanças.
1 ( ) É fornecido recurso da consulta/relatórios flexíveis capaz de manipular solicitações simples de consulta (TXHU\
UHTXHVWV). Por exemplo: lógica de DQGRU aplicada a somente um Arquivo Lógico Interno (contar como um
item).
2 ( ) É fornecido recurso de consulta/relatórios flexíveis capaz de manipular solicitações de consulta (TXHU\
UHTXHVWV) de média complexidade. Por exemplo: lógica de DQGRU aplicada a mais de um Arquivo Lógico
Interno (contar como dois itens).
3 ( ) É fornecido recurso de consulta/relatórios flexíveis capaz de manipular solicitações complexas de consulta
(TXHU\UHTXHVWV). Por exemplo: combinações de lógica de DQGRU aplicadas a um ou mais Arquivos Lógicos
Internos (contar como três itens).
4 ( ) Dados de controle são mantidos em tabelas que são atualizadas pelo usuário através de processos RQOLQH e
interativos, mas as alterações só são efetivadas no próximo dia útil.
5 ( ) Dados de controle são mantidos em tabelas que podem ser atualizadas pelo usuário através de processos RQ
OLQH e interativos e as alterações são efetivadas imediatamente (contar como dois itens)
2875$6&$5$&7(5Ë67,&$67e&1,&$63523267$63(/2.$51(5
)DFLOLGDGHGHLQVWDODomR – Indica o nível de preparação de procedimentos e ferramentas para instalação do sistema
0 ( ) Nenhuma consideração especial foi feita pelo usuário e nenhum procedimento especial foi requerido para a
instalação.
1 ( ) Nenhuma consideração especial foi feita pelo usuário, mas um procedimento especial foi requerido para a
instalação.
2 ( ) Requisitos de instalação foram fixados pelo usuário.
3 ( ) Requisitos de instalação foram fixados pelo usuário e roteiros de instalação foram preparados e testados.
4. ( ) Além do descrito no item 2, ferramentas automatizadas de instalação foram preparadas e testadas.
5. ( ) Além do descrito no item 3, ferramentas automatizadas de instalação foram preparadas e testadas.

3RUWDELOLGDGHA aplicação foi especificamente projetada, desenvolvida e suportada para ser instalada em
múltiplas plataformas (Windows, Unix, Linux, etc)

0 ( ) Nenhuma solicitação do usuário para considerar a necessidade de instalar a aplicação em mais de uma
plataforma
1 ( ) Necessidade de instalação em múltiplas plataformas foi levada em consideração no projeto do sistema e a
aplicação foi projetada para operar somente em ambientes idênticos de KDUGZDUH e software
2 ( ) Necessidade de instalação em múltiplas plataformas foi levada em consideração no projeto do sistema e a
aplicação foi projetada para operar somente em ambientes similares de KDUGZDUH e software
3 ( ) Necessidade de instalação em múltiplas plataformas foi levada em consideração no projeto do sistema e a
aplicação foi projetada para operar inclusive em plataformas diferentes.
4. ( ) Um plano de documentação e manutenção foi elaborado e testado para suportar a aplicação em múltiplas
plataformas e a aplicação atende aos itens 1 e 2.
5. ( ) Um plano de documentação e manutenção foi elaborado e testado para suportar a aplicação em múltiplas
plataformase a aplicação atende ao item 3.
$FHVVRVVLPXOWkQHRVFRQFRUUrQFLD±Indica o volume de acesso simultâneo a aplicação
0 ( )
Não é esperado acesso simultâneo
1 ( )
São esperados acessos simultâneos esporadicamente
2 ( )
Acessos simultâneos são esperados.
3 ( )
Acessos simultâneos são esperados diariamente
4 ( )
Muitos acessos simultâneos foram fixados pelo usuário para a aplicação, o que força a execução de tarefas de
análise de performance na fase de projeto da aplicação.
5 ( ) Requer o uso de ferramentas controle de acesso nas fases de projeto desenvolvimento e/ou implantação, além
das considerações acima.
&DUDFWHUtVWLFDVHVSHFLDLVGHVHJXUDQoD±Indica o nível de segurança exigido pela aplicação
 119

0 ( ) Nenhuma solicitação do usuário para considerar a necessidade de controle de segurança da aplicação

1 ( ) Necessidade de controle de segurança foi levada em consideração no projeto do sistema
2 ( ) Necessidade de controle de segurança foi levada em consideração no projeto do sistema e a aplicação foi
projetada para ser acessada somente por usuários autorizados
3 ( ) Necessidade de controle de segurança foi levada em consideração no projeto do sistema e a aplicação foi
projetada para ser acessada somente por usuários autorizados. O acesso será controlado e auditado.
4. ( ) Um plano de segurança foi elaborado e testado para suportar o controle de acesso a aplicação
5. ( ) Um plano de segurança foi elaborado e testado para suportar o controle de acesso a aplicação e a auditoria 
)DFLOLGDGHVHVSHFLDLVGHWUHLQDPHQWR– Indica o nível de facilidade de treinamento de usuários
0 ( ) Nenhuma solicitação do usuário para considerar a necessidade de treinamento especial
1 ( ) Necessidade de treinamento especial foi levada em consideração no projeto do sistema
2 ( ) Necessidade de treinamento foi levada em consideração no projeto do sistema e a aplicação foi projetada
para ser acessada com facilidade pelos usuários
3 ( ) Necessidade de treinamento especial foi levado em consideração no projeto do sistema e a aplicação foi
projetada para ser utilizada por usuários de diversos níveis
4 - 5 ( ) Um plano de treinamento foi elaborado e testado para facilitar o uso da aplicação

&$5$&7(5Ë67,&$6$0%,(17$,63523267$63(/2.$51(5
)DPLOLDULGDGHFRPR3URFHVVRGH'HVHQYROYLPHQWRGH6RIWZDUH– Indica a experiência da equipe com o
processo/método utilizado para desenvolvimento do projeto.
0 ( ) A equipe não é familiar com o processo de desenvolvimento de software
1 ( ) A equipe tem conhecimento teórico do processo de desenvolvimento de software
2 - 3 ( ) Um ou mais membros utilizou o processo uma ou poucas vezes
3 - 4 ( ) Pelo menos a metade dos membros da equipe tem experiência no uso do processo em diferentes projetos
5. ( ) Toda a equipe tem experiência no uso do processo em vários projetos diferentes.
([SHULrQFLDQD$SOLFDomR±Indica a experiência com diferentes tipos de aplicação ou com o tipo de aplicação
que está sendo desenvolvida.
0 ( ) Todos os membros da equipe são novatos
1 - 2 ( ) Poucos membros da equipe possuem alguma experiência (de 1 a 1 ½ ano). Os outros são novatos.
3 ( ) Todos os membros tem mais de 1 ½ ano de experiência
4 ( ) A maioria da equipe tem 2 anos de experiência
5. ( ) Todos os membros são experientes
([SHULrQFLDFRP22QD/LQJXDJHPHQD7pFQLFDGH'HVHQYROYLPHQWR – Mede a experiência da equipe com
análise e projeto OO, modelagem de casos de uso, classes e componentes.
0 ( ) A equipe não é familiar com análise e projeto OO.
1 ( ) Todos os membros tem menos de 1 ano de experiência.
2 – 3 ( ) Todos os membros tem de 1 a 1 ½ ano de experiência
4 ( ) A maioria da equipe tem mais de 2 anos de experiência
5. ( ) Todos os membros são experientes ( mais de 2 anos)

&DSDFLGDGHGR/tGHUGH3URMHWR±Indica a experiência do líder com análise de requisitos e modelagem.

0 ( ) O líder do projeto é novato.
1 - 2 ( ) Possui experiência de poucos projetos
3 - 4 ( ) Pelo menos 2 anos de experiência com vários projetos
5. ( ) Pelo menos 3 anos de experiência com projetos variados
0RWLYDomR±Descreve a motivação total da equipe.
0 ( ) Não motivada
1 - 2 ( ) Pouca motivada
3 - 4 ( ) A equipe está motivada para fazer um bom trabalho
5. ( ) A equipe está muito motivada e inspirada
5HTXLVLWRVHVWiYHLV±Mede o grau de mudança de requisitos e inseguranças sobre o significado dos requerimentos.
 120

0 ( ) Requisitos muito instáveis com mudanças freqüentes

1-2 ( ) Requisitos instáveis. Clientes demandam algumas mudanças realizadas em diversos intervalos
3-4( ) Estabilidade global. Pequenas mudanças são necessárias
5. ( ) Requisitos estáveis ao longo do desenvolvimento
7UDEDOKDGRUHVFRPGHGLFDomRSDUFLDO±Mede a estabilidade da equipe e a influencia do trabalho parcial na
produtividade.
0 ( ) Não tem membro com dedicação parcial
1 -2 ( ) Poucos membros (20%) trabalham em período parcial
3 -4 ( ) A metade dos membros da equipe trabalham em período parcial
5. ( ) Toda os membros da equipe trabalham em período parcial
'LILFXOGDGHGD/LQJXDJHPGH3URJUDPDomR– Indica a experiência com ferramentas primárias de
desenvolvimento e com a linguagem de programação escolhida
0 ( ) Todos os membros da equipe são programadores experientes
1 ( ) A maioria dos membros da equipe possuem mais de 2 anos de experiência
2 ( ) Todos os membros tem mais de 1 ½ ano de experiência
3 ( ) A maioria da equipe tem mais de 1 ano de experiência
4 ( ) poucos membros da equipe tem alguma experiência (1 ano). Os outros são novatos.
5. ( ) Todos os membros da equipe são novatos
 121

$SrQGLFH%*HVWmRGHHVWLPDWLYDVHPSURMHWRVGHVRIWZDUH
Este questionário visa a identificar as ações a serem tomadas pelo gerente de projeto em relação à gestão de
estimativa de projeto durante a sua execução. A estimativa de tamanho realizada no início do projeto através de
Pontos de Caso de Uso (PCU) e Pontos de Função (PF) é refinada ao longo do desenvolvimento do projeto e
comparada com a estimativa de tempo planejada através da definição do cronograma. Portanto, durante a gestão,
torna-se necessário identificar a situação real do projeto em relação ao tempo estimado, ou seja, se o cronograma está
dentro do prazo ou atrasado.

&$5$&7(5,=$d­2'2*(5(17('2352-(72

1RPH2SFLRQDO (PDLO2SFLRQDO
ÈUHDGH$WXDomR
 LQG~VWULD  DFDGHPLD
Gerente de TI Professor
Gerente de projeto Pesquisador
Membro de projeto Aluno de pós-graduação
Gerente de estimativas de projeto Gerente de estimativas de projeto
Consultor externo Consultor externo
([SHULrQFLD )RUPDomR1tYHOHÈUHD
7HPSRGHDWXDomRHPJHVWmRGHSURMHWRVDQRV
( ) Doutorado ( )Eng de Software ( ) Outro
( ) 1 – 3 ( ) 3 – 5 ( ) 5 - 10 ( ) mais de 10

1~PHURGHSURMHWRVJHUHQFLDGRV ( ) Mestrado ( ) Gestão de TI e do ( ) Outro
( ) 1 – 3 ( ) 3 – 5 ( ) 5 - 10 ( ) mais de 10 Conhecimento (em curso)

Gestão de tempo de execução de projetos: ( )Especialização ( ) Análise de Sistemas
( ) Alta ( ) Média ( ) Baixa ( ) Nenhuma ( ) Outro
( )Graduação ( ) Ciência da Computação
( ) Outro
( ) Certificação: ( ) IFPUG
( ) PMI
( ) Outro
&RQWDWR

(GPpLD/HRQRU3HUHLUDGH$QGUDGH
e-mail – HGPHLDDQGUDGH#EUWXUERFRP; HGPHLDDQGUDGH#HPEUDSDEU

$VDo}HVGHJHVWmRGHHVWLPDWLYDUHODFLRQDGDVQHVWHTXHVWLRQiULRHVWmREDVHDGDVHP35(660$1
30%2.H-85,621HRVIDWRVTXHSURYRFDPDWUDVRQRFURQRJUDPDIRUDP
LGHQWLILFDGRVQRWUDEDOKRGH)DULDV

,3/$1(-$0(172±$o}HVUHFRPHQGDGDVHPXPFURQRJUDPDLPSUDWLFiYHO

Com base na lista de ações descritas abaixo, assinale com um X a coluna correspondente ao nível de recomendação que
você considera mais adequado em relação às ações a serem adotadas quando a data de entrega do produto definida no
planejamento é impraticável.
1mRUHFRPHQGDGD 3RXFR5HFRPHQGDGD5HFRPHQGDGD0XLWRUHFRPHQGDGD

Obs: Caso você queira indicar outras ações relevantes, acrescente-a na lista abaixo e indique o nível de recomendação
correspondente.
$o}HVDVHUHPWRPDGDVTXDQGRRFURQRJUDPDpLPSUDWLFiYHO 1Ë9(/'(5(&20(1'$d­2
 122

    
1. Reunir-se com o cliente, apresentar a estimativa detalhada em relação ao
esforço e a duração estimada para o projeto e negociar novo prazo.
2. Definir uma estratégia de desenvolvimento incremental que entregue a
funcionalidade crítica na data prevista e adie as funções restantes.
3. Negociar o aumento do orçamento e contratar mais recursos humanos
apesar de que esta solução pode comprometer a qualidade do produto.
4. Contratar consultoria especializada para resolver problemas técnicos.

5. Substituir os técnicos que não tem apresentado resultados satisfatórios.

6. Ignorar a realidade e esperar completar o prazo determinado no

cronograma.

,,$&203$1+$0(172±2FURQRJUDPDHVWiQRSUD]R
1. Com base na lista de ações descritas abaixo, assinale com um X a coluna correspondente à periodicidade emque você
tem realizado ações de acompanhamento e controle do cronograma:
1RLQtFLRGRGHVHQYROYLPHQWR6HPDQDO0HQVDO$SyVRWpUPLQRGHFDGDIDVHGHGHVHQYROYLPHQWR
6HPSHULRGLFLGDGHGHILQLGD1mRSUDWLFDHVWDVDo}HV

Obs: Caso você queira indicar outras ações relevantes, acrescente-a na lista abaixo e indique a periodicidade que a
mesma é realizada. 
$o}HVDVHUHPWRPDGDVSDUDFRQWURODURFURQRJUDPD      
1. Avaliar o plano de projeto, o ambiente de desenvolvimento previsto, as
datas impostas pelo patrocinador do projeto ou cliente e os fatores externos
que podem interferir no cronograma do projeto.
2. Avaliar o tempo necessário para implementar cada atividade.
3.Incluir reservas orçamentárias para resolver problemas ou executar o plano
de contingência.
4. Identificar e documentar as restrições no plano do projeto que limitarão a
realização das atividades e elaborar um plano de contingência.
5. Verificar se todas as atividades e tarefas que visam alcançar o objetivo do
projeto constam no cronograma e foram entendidas pela equipe.
6. Identificar se os marcos de referência do projeto foram estabelecidos de
modo que o progresso possa ser acompanhado.
7. Verificar se todo esforço e duração do projeto foram atribuídos
corretamente a cada atividade do cronograma.
8. Verificar se as interdependências entre as atividades foram adequadamente
indicadas.
9. Identificar questões que podem causar problemas futuros, providenciar
ações corretivas e alertar a equipe do projeto.
10. Identificar as atividades que não são do projeto ou que dependem de
fornecedores para serem executadas.
11. Identificar possíveis mudanças que influenciam no cronograma (ex: na
legislação, no escopo ou tecnologia).
12. Identificar e coordenar as atividades e tarefas realizadas em paralelo.
13. Identificar quais datas do cronograma foram alcançadas e quais não foram
 123

14. Conduzir reuniões periódicas para que cada membro do projeto possa
relatar o progresso e os problemas atuais.
15. Analisar os relatórios de desempenho do projeto e avaliar os resultados
das revisões conduzidas ao longo do processo de desenvolvimento.
16. Atualizar o plano, os documentos técnicos e informar a equipe e clientes.
17. Ter membros representativos nas reuniões de revisões técnicas para
garantir o entendimento comum das necessidades do cliente e evitar futuras
surpresas.
18. Identificar se há algum membro da equipe que possui habilidades únicas,
difíceis de serem substituídas ou está comprometido com outros projetos.
19. Controlar a produtividade da equipe.

20. Refinar as estimativas realizadas no início do projeto durante todo o ciclo

de desenvolvimento do projeto.
21. Contratar consultoria externa para auxiliar no uso da tecnologia.

22. Facilitar a comunicação entre os membros da equipe.

,,$&203$1+$0(172±2FURQRJUDPDHVWiDWUDVDGR
1. A seguir será apresentada a tabela que relaciona fatos que podem provocar atrasos no cronograma e ações a serem
tomadas quando o cronograma do projeto está atrasado. Os números indicados nas colunas representam as ações
descritas abaixo. Cada linha da tabela representa um fato e o conjunto de ações associadas. 0DUTXHFRPXPµ;¶DV
Do}HVTXHGHYHPVHUWRPDGDVSDUDFDGDIDWROLVWDGRQDWDEHOD

Obs.:
Caso você queira indicar outras ações relevantes, acrescente-a na lista de ações abaixo e relacione-a ao fato
correspondente.
Caso você queira indicar outros fatos relevantes, acrescente-o na lista de fatos da tabela e relacione-a a ação
correspondente.
$o}HVDVHUHPWRPDGDVTXDQGRRFURQRJUDPDWLYHUDWUDVDGR
1. Rever o planejamento do projeto e identificar desvios 7. Controlar a comunicação entre os membros do projeto.
no cronograma. 8. Fazer ajustes no plano e documentar as ações para
2. Agregar novas pessoas na equipe do projeto contemplar as revisões de tempo, custo, seqüência de
3. Redistribuir as pessoas na equipe. atividades e análise de alternativas de respostas a
4. Rever as funções do software, priorizá-las e deixar as riscos.
menos importantes para futuras versões. 9. Verificar se as atualizações do cronograma requerem
5. Rever o cronograma e buscar alcançar o próximo ajustes em outros aspectos do plano geral do projeto.
marco do projeto na data prevista para garantir o 10. Registrar os desvios do cronograma, identificar quais
término do projeto na data esperada. atividades ocorreram e o motivo de sua ocorrência.
6. Caso não haja possibilidade de recuperação do 11. Contratar consultoria especializada.
atraso, o gerente deve rever o cronograma e negociar 12.
com as partes envolvidas.
$o}HVUHFRPHQGDGDV
)DWRVTXHSURYRFDPDWUDVRQRFURQRJUDPD

            
1. Equipe de desenvolvimento indisponível.
           
2. Projeto com alto grau de inovação.
           
3. Prazos e custos estabelecidos arbitrariamente.            
4. Método de estimativa de tamanho inadequado.
           
 124

5. Gerência inexperiente.
           
6. Equipe de desenvolvimento inexperiente em Eng. Soft.            
7. Equipe de desenvolvimento inexperiente na aplicação.            

           
8. Equipe de desenvolvimento inexperiente nos métodos e
ferramentas utilizadas.
9. Processo de desenvolvimento inadequado.            
10. Levantamento de requisitos com pessoas inexperientes.            
11. Alto grau de competição na empresa do cliente.            
12.Falta de comprometimento do usuário/cliente.            
13. Orçamento insuficiente.            
14. Requisitos complexos.            

           
15. Hardware e/ou software necessários não disponíveis no
momento definido.
16. Dependência de produtos ou serviços externos que
afetam o produto, o orçamento, o cronograma ou a            
continuidade do projeto.
           
17. Mudanças de requisito que não foram refletidas em
mudanças do cronograma.

           
18. Falta de identificação dos riscos previsíveis e
imprevisíveis no início do projeto.

           
19. Falta de identificação das dificuldades técnicas e
humanas no início do projeto.

           
20. Falta de comunicação entre os membros da equipe do
projeto.

 125

$SrQGLFH&3URFHVVRGHGHVHQYROYLPHQWRGHVRIWZDUHRULHQWDGRDREMHWRV

O processo de desenvolvimento de software inclui as perspectivas organizacionais,

funcionais e comportamentais e deve refletir os principais objetivos do desenvolvimento como: i)
construir software de alta qualidade, ii) encontrar as falhas no início do desenvolvimento; e iii)
manter as regras do orçamento e cronograma. Nesse sentido, a escolha do processo a ser adotado
no desenvolvimento depende da natureza da aplicação e das características do projeto.
No escopo deste trabalho, o processo de desenvolvimento de software foi baseado no
5DWLRQDO 8QLILHG 3URFHVV (RUP). O RUP tem como principais características: i) a avaliação
contínua dos riscos do projeto no final de cada iteração; ii) a geração de produtos
interdependentes em todas as iterações; iii) é baseado na tecnologia OO, fortemente orientado a
utilização de casos de uso, centrado na arquitetura e na UML; e iv) é iterativo e incremental
(RATIONAL..., 2001b).
A idéia principal do desenvolvimento iterativo e incremental é a entrega do produto em
partes (PITTMAN, 1993). No modelo de desenvolvimento incremental, cada componente é
projetado em detalhes, implementado, testado e disponibilizado. Os resultados de cada
incremento são apenas parte de uma solução que tem como objetivo, oferecer uma versão
operacional do software possibilitando ao usuário, ter alguma função em uso na medida em que
as outras partes do projeto estão em desenvolvimento. A cada nova versão, a função
disponibilizada é refinada e novas funções são adicionadas. (MURTHI, 2002; PFLEEGER,
2001).
No RUP, o software é construído em várias iterações (é uma seqüência distinta de
atividades que resultam em uma versão do produto) durante as seguintes fases de
desenvolvimento: i) concepção (estabelece os casos de uso de negócio do sistema e delimita o
escopo do projeto); ii) elaboração (analisa o domínio do problema, estabelece a arquitetura do
sistema, desenvolve o plano do projeto e elimina os elementos de riscos do projeto); iii)
construção (são desenvolvidos, testados e integrados os componentes do sistema baseando-se na
arquitetura definida); e iv) transição (são realizados os testes do produto e executados os ajustes,
de acordo com a validação do usuário para assegurar uma disponibilização adequada do software
para os usuários). (JACOBSON; BOOCH; RUMBAUGH, 1996; RATIONAL..., 2001a e
RATIONAL, 2001b). As fases variam de acordo com o tempo. Cada fase percorre um intervalo
 126

de tempo entre dois pontos de verificações principais, definidas como marcos no projeto. No final
de cada fase uma avaliação é executada para determinar se os objetivos foram atingidos. Se a
avaliação for satisfatória o projeto poderá passar para a próxima fase.
A passagem pelas quatro fases e respectivas disciplinas23 do processo determina uma
iteração e produz uma versão do software. As disciplinas ou atividades deste processo são:
modelagem de negócio, requisitos, análise e projeto, implementação, teste e implantação. Além
destas, o RUP dispõe de algumas disciplinas de suporte ao processo como o gerenciamento de
mudanças e configuração, o gerenciamento de projetos e ambiente.
A GLVFLSOLQD GH PRGHODJHP GH QHJyFLR modela visualmente o processo de negócio
usando os casos de uso de negócio. Esta disciplina garante um entendimento comum entre os
interessados sobre o quê o processo precisa para apoiar a organização. Os casos de uso de
negócio são analisados e documentados através do modelo de casos de uso de negócios e do
modelo de classes de negócio. Nem todos os projetos fazem a modelagem de negócios
( RATIONAL..., 2001a).
A GLVFLSOLQD GH UHTXLVLWRV é considerada uma das mais importantes do processo de
desenvolvimento de software, pois será nesse momento que haverá um entendimento sobre o
problema que o cliente apresentou e que deverá ser resolvido através do software a ser
desenvolvido. Nessa disciplina são identificados, organizados e documentados os requisitos do
sistema. Os principais artefatos gerados nessa disciplina são: glossário do software, memórias de
reuniões de levantamento de requisitos, lista de necessidades, relatório de viabilidade técnica,
documento de visão do software (cenários), modelo de casos de uso, definição da arquitetura
candidata e protótipo de interface com usuário. O modelo de caso de uso é um dos principais
artefatos resultantes dessa disciplina.
A DQiOLVHHSURMHWR tem como finalidade transformar os requisitos em um modelo com
suficientes detalhes para mostrar como os casos de uso do sistema serão realizados na
implementação. Na análise, é gerado o modelo de análise que constitui-se dos seguintes
diagramas: de classes de análise, de interação (colaboração ou seqüência), de estados ou de
atividades. O projeto visa refinar o modelo de análise e desenvolver uma arquitetura robusta para
o software compatível com o ambiente de implementação e com o desempenho desejado para o
software. Os principais artefatos gerados nessa disciplina são: modelo de projeto (diagrama de

23
Disciplinas são as macro-atividades desenvolvidas durante as fases do RUP.
 127

classes de projeto, componentes e modelo de dados), diagramas de interação de projeto,

definição da arquitetura (configuração da plataforma tecnológica, diagrama de implantação e
diagrama de subsistemas) e versão preliminar do plano de teste
A LPSOHPHQWDomR visa desenvolver as classes, objetos e componentes, testar os
componentes e integrá-los em subsistemas, conforme definido na arquitetura do software. Nessa
disciplina, são gerados os códigos fonte dos componentes, os resultados dos testes dos
componentes, o plano de integração de componentes, os subsistemas integrados e o produto de
software.
A GLVFLSOLQDGHWHVWHV visa identificar e garantir que defeitos sejam identificados antes de
disponibilizar o software. Deve ser verificada a interação entre objetos, a adequação da
integração de todos os componentes do software e se todos os requisitos foram corretamente
implementados. Os casos de uso fornecem os cenários necessários para identificação funcional de
cenários de teste. Esses cenários de teste são usados para originar casos de teste e scripts de teste.
Dessa forma, a funcionalidade do sistema é verificada executando-se cenários de teste que
experimentam cada caso de uso. Os principais produtos são o plano de teste, os casos de teste
definidos, os resultados dos testes realizados, o documento de solicitação de mudanças no
software aprovado pelos usuários.
A LPSODQWDomR visa personalizar a instalação, empacotar o produto oferecido e permitir o
acesso ao software. Para isso, é necessário definir o plano de implantação do projeto e iterações,
manuais do usuário, do sistema e de treinamento antes da implantação do software.
Em cada disciplina são gerados um ou mais artefatos. Alguns deles estão listados na
coluna 2 do Quadro 22. Os artefatos destacados em negrito são geralmente utilizados para
realizar a estimativa de tamanho durante o processo de desenvolvimento de um projeto de
software OO, porque fornecem informações relevantes sobre as funções do software, necessárias
para fazer a estimativa de tamanho tanto através da APF como do PCU. 
Os artefatos gerados nas disciplinas acima representam os aspectos estáticos e dinâmicos
de um sistema. Os artefatos estáticos são aqueles que não mudam em uma versão do sistema,
como classes, pacotes, componentes e os artefatos dinâmicos descrevem informações sobre
objetos e como essas informações são transmitidas em um serviço ou função. Geralmente, a
parte estática do sistema é representada pelos diagramas de classes, de objetos, de componentes e
de implantação e a parte dinâmica através do diagrama de casos de uso, de seqüência, de
 128

colaboração, de estado e de atividades. Esses diagramas são alguns dos artefatos mais
importantes gerados durantes o processo de desenvolvimento de software OO. A seguir, é
apresentada uma breve descrição de cada um desses diagramas de acordo com Booch;
Rumbaugh; Jacobson (1999):
i) 'LDJUDPDGHFDVRVGHXVR
Este diagrama é o centro da modelagem do comportamento de um sistema, subsistema ou
de uma classe. Este diagrama é importante para visualizar, especificar, documentar e testar o
comportamento do sistema. Ele mostra um conjunto de casos de uso, atores, dependências,
generalização e relacionamentos de associação. Geralmente, é utilizado para modelar o contexto
e os requisitos de sistemas.
Casos de uso representam as funções de um sistema e o relacionamento entre elas. Um
caso de uso pode também incluir um comportamento de um outro caso de uso através de um
relacionamento do tipo incluído ou estendido. O comportamento comum é representado em um
caso de uso do tipo incluído para evitar a cópia das mesmas funções em diversos casos de uso. O
caso de uso estendido representa um comportamento opcional ou alternativo ao cenário principal,
o qual indica que uma instância do caso de uso pode ou não incluir o comportamento
especificado (COCKBURN, 2000, citado por RIBU, 2001).
Os atores podem estar associados através da generalização, a qual é utilizada para agrupar
o comportamento comum entre os atores (RIBU, 2001).
A UML não descreve como o modelo de casos de uso deve ser estruturado nem como
cada caso de uso deve ser documentado. Há apenas uma sugestão de Ivar Jacobson para usar um
formulário para a descrição estruturada dos casos de uso (RIBU, 2001)
ii) 'LDJUDPDGHFODVVHV
Este diagrama mostra a visão estática do projeto do sistema através de um conjunto de
classes, interfaces e a colaboração entre seus relacionamentos.
Uma classe de objetos descreve um grupo de objetos com propriedades similares
(atributos), comportamento comum (métodos ou operações), relacionamentos comuns com outros
objetos e semânticas idênticas. Uma classe pode ser abstrata, ou seja, aquela que permite que um
conjunto de subclasses tenha o mesmo comportamento, mas que não foi projetada para ter
instâncias. Uma classe abstrata representa um conceito e as classes dela derivadas representam
implementações desse conceito.
 129

Cada classe é classificada de acordo com seu estereótipo. Os estereótipos pré-definidos na

UML são: classes de fronteira, de entidade, de controle, de exceção, parametrizada, utilitária e
meta classe. Os três primeiros estereótipos (fronteira, controle e entidade) são os mais comuns.
Uma classe de fronteira modela a comunicação entre os atores e o sistema, uma classe de
entidade modela informação e comportamento persistentes e uma classe de controle modela o
comportamento de controle específico a um ou mais casos de uso.
Os objetos (instância de uma classe) atuam no comportamento de um sistema
colaborando entre si para produzir as funções necessárias. A colaboração é realizada através de
relacionamentos entre as classes. Na modelagem orientada a objetos, os relacionamentos mais
importantes são dependências, generalização e associação.
A dependência é um relacionamento entre dois elementos de modelagem, no qual uma
mudança em um elemento de modelagem (o elemento independente) afetará o outro elemento de
modelagem (o elemento dependente).
A generalização é um relacionamento taxonômico entre um elemento mais geral
(superclasse) e um elemento mais específico (subclasse). A subclasse é totalmente consistente em
relação à superclasse e contém informações adicionais. Uma instância da subclasse pode ser
usada onde à superclasse permitir. O mecanismo que torna possível a generalização é a herança,
que pode ser simples ou múltipla. Na herança simples, a subclasse herda as características de
apenas uma superclasse e na herança múltipla a subclasse herda as características de mais de uma
superclasse.
Uma associação implica na existência de uma ligação entre os objetos das classes
associadas. Podem ser binárias, ternárias ou de ordem mais elevada.
Uma agregação (tipo especial de associação) estabelece o relacionamento entre o todo e
suas partes, no qual os objetos que representam os componentes de das partes são associados a
um objeto que representa a estrutura inteira.
O diagrama de classes contém também pacotes, subsistemas ou instâncias como os
objetos. Este diagrama é também a base para outros diagramas como os diagramas de
componente e de implantação.
iii) 'LDJUDPDGHREMHWRV
Este diagrama mostra um conjunto de objetos e seus relacionamentos. Os objetos são
instância da classe, mas pode também representar instâncias de colaboração, componentes e nós.
 130

Este diagrama pode ser considerado como um caso especial de um diagrama de classes ou de um
diagrama de colaboração. Este diagrama contém objetos e ligações e é utilizado sob a perspectiva
real ou para protótipos da visão dos requisitos funcionais do sistema.
iv) 'LDJUDPDGHFRPSRQHQWHV
Este diagrama mostra a organização e as dependências entre um conjunto de
componentes. Estes diagramas estão relacionados ao diagrama de classes, no qual um
componente pode mapear uma ou mais classes, interface ou colaboração.
v) 'LDJUDPDGHLPSODQWDomR
Este diagrama mostra a configuração de nós de processamento em tempo de execução e
os componentes, os processos e os objetos que dependem deles. Os componentes representam
manifestações de unidades de código em tempo de execução.
YL 'LDJUDPDVGHVHTrQFLD
 É um diagrama de interação que enfatiza o tempo de ordenação da mensagem, ou seja
mostra o comportamento de um caso de uso do sistema de forma cronológica. Com base no
comportamento, são atualizados os modelos estáticos. Os diagramas de seqüência são definidos
com base na descrição dos casos de uso e mostram um conjunto de objetos que participam da
interação no topo do diagrama (nome e classe a qual pertence), as mensagens enviadas e
recebidas de outros objetos, os métodos ou operações e os respectivos parâmetros. Geralmente,
coloca-se o objeto que inicia a interação à esquerda e outros objetos subordinados a direita. As
mensagens enviadas e recebidas são colocadas nas linhas verticais (que representam a existência
de um objeto num período de tempo. Muitos dos objetos que aparecem no diagrama de interação
existem enquanto durar a interação).
vii) 'LDJUDPDGHFRODERUDomR
É um diagrama de interação que enfatiza a estrutura organizacional dos objetos que
enviam e recebem mensagens. Este diagrama mostra um conjunto de objetos, as ligações entre
eles e as mensagens enviadas e recebidas.
viii) 'LDJUDPDGHHVWDGR
Este diagrama consiste dos estados, transições, eventos e atividades. É usado para mostrar
como um elemento, usualmente uma classe, muda de estado no tempo de acordo com o
ordenamento do evento ou condições de transição que provocam mudança de comportamento do
objeto (RIBU, 2001).
 131

ix) 'LDJUDPDGHDWLYLGDGHV
É um tipo especial de diagrama de estado que mostra o fluxo de atividades dentro do
sistema
A arquitetura do sistema em geral é representada através das seguintes visões: i) de casos
de uso (consiste dos diagramas e descrição de casos de uso e dos diagramas de atividades); ii) de
projeto (constitui-se dos diagramas de classes, de interação e de estado); iii) de processo,
(compõe-se dos diagramas de classes e de interação); iv) implementação (diagramas de
componentes); e v) de implantação (diagramas de implantação).
Os artefatos mais importantes para o processo de estimativa de tamanho de um projeto de
software são os destacados em negrito no Quadro 22: documento de visão do sistema, modelo de
casos de uso (diagrama e descrições de casos de uso); modelo de análise (diagramas de classes de
objetos e de seqüência) modelo de projeto (diagramas de classes de objetos, de seqüência e de
entidade e relacionamentos); subsistemas e o produto final do software ou sistema.
O documento de visão captura os requisitos de nível alto e as restrições de projeto, para
fornecer ao leitor uma compreensão do sistema a ser desenvolvido. Ele fornece informações
necessárias, do ponto de vista de um negócio, para determinar se vale ou não a pena investir no
projeto e está, portanto, diretamente relacionado ao caso de negócio. Comunica os principais
questionamentos relacionados ao projeto e funciona como um regulador com base no qual todas
as decisões futuras deverão ser validadas.
4XDGUR$UWHIDWRVJHUDGRVGXUDQWHRSURFHVVRGHGHVHQYROYLPHQWRGHSURMHWRGH
VRIWZDUHRULHQWDGRDREMHWRV

'LVFLSOLQD $UWHIDWRV
Modelo de casos de uso de negócio
0RGHODJHPGH

Modelo de classes de negócio

QHJyFLR

Atas de reuniões de levantamento de necessidades

Glossário do sistema de informação
5HTXLVLWRV

Lista de necessidades.
Relatório de viabilidade técnica
'RFXPHQWRGHYLVmRGRVLVWHPD


0RGHORGHFDVRVGHXVR
Definição da arquitetura candidata
Protótipo de interface com usuário
 132

4XDGUR   FRQW  $UWHIDWRV JHUDGRV GXUDQWH R SURFHVVR GH GHVHQYROYLPHQWR GH
SURMHWRGHVRIWZDUHRULHQWDGRDREMHWRV

'LVFLSOLQD $UWHIDWRV
0RGHORGH$QiOLVH (Diagramas de classes de análise, de interação (colaboração e seqüência),
de estados e de atividades
0RGHORGH3URMHWR (Diagrama de Classes de projeto, Componentes e Modelo de Dados)
$QiOLVHH
3URMHWR

Diagramas de Interação de Projeto

Definição da arquitetura (Configuração da plataforma, Diagrama de implantação e de
subsistemas)
Versão preliminar do Plano de Teste
Modelo de implementação
Código fonte do componente.
,PSOHPHQWD

Resultados dos testes de componentes

omR

Código fonte do componente corrigido

Plano de integração de componentes
6XEVLVWHPDVLQWHJUDGRV
3URGXWRGHVRIWZDUH
Plano de teste atualizado com Procedimentos de teste e Casos de teste definidos
7HVWHV

Resultados dos testes

Documento de solicitação de mudanças
6LVWHPDDSURYDGRSHORVXVXiULRV
Plano de implantação do projeto e iterações
,PSODQWDomR

Manual do usuário
Manual do sistema
Material de treinamento
3URGXWRILQDOGRVRIWZDUHSDUDXVR
Rational.... (2001a)