Escolar Documentos
Profissional Documentos
Cultura Documentos
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
321726'(&$626'(862(321726'()81d21$*(672'(
(67,0$7,9$'(7$0$1+2'(352-(726'(62)7:$5(
25,(17$'26$2%-(726
Brasília
2004
7(502'($3529$d2
('0e,$/(21253(5(,5$'($1'5$'(
321726'(&$626'(862(321726'()81d21$*(672'(
(67,0$7,9$'(7$0$1+2'(352-(726'(62)7:$5(
25,(17$'26$2%-(726
Brasília
UCB
i
'HGLFDWyULD
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'8d2
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*(672'(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*(672'((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&/862(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
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
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
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:
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
(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
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
$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
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
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
4XDGUR&RPSOH[LGDGHIXQFLRQDO,)38*
"! #%$&'$ &(
)+*-,.'/ 0
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
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
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
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
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)
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)
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
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
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
4XDGUR3ULQFLSDLVFDUDFWHUtVWLFDVHGLIHUHQoDVHQWUH$3)H3&8
=> =?8
Métrica mais antiga e mais utilizada no mundo Métrica relativamente nova e pouca utilizada
Padrão internacional desde 2002 Ainda não alcançou o nível de padronização e nem foi
incorporada em ferramentas populares;
Não requer o uso de notação padrão, mas é baseada no Baseada no modelo de casos de uso
modelo funcional e independente de tecnologia
Largamente discutida na literatura Tem aumentado o uso e a publicação de estudos na
literatura
É suportada pelo IFPUG e diversos grupos nacionais O Modelo de casos de uso ainda não possui bons
de usuários e bases históricas de contagens realizadas históricos de produtividade
Possui regras de contagem padronizadas 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
È mais utilizada no final das fases de análise e projeto Utilizado na fase inicial do projeto
Visão do usuário Visão do usuário
Alto nível de maturidade Em fase de amadurecimento
É subjetiva e possui diferença entre contadores É subjetiva e possui diferença entre contadores
Oferece treinamento e certificação Ainda não oferece treinamentos e certificação
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
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
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
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
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
@A
BCDE(E(BE-FHG
I
J
KL5DI
MKNE @A
BCDE(E(BEJDOK
@?BNB
Aquisição Documentação
Garantia da Qualidade
Verificação
Operação
Validação
Auditoria
Manutenção
Resolução de Problemas
@A
BCDE(E(BE.B
A
P
K
INQK
CNB
I
KNE
)LJXUD(VWUXWXUDGD1%5,62,(&(ABNT, 1998)
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 ; ;
6HTHQFLDPHQWRGHDWLYLGDGHV ;
*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)
48
4XDGUR0DSHDPHQWRGD1%5,62,(&SDUDD,62H30%2.
(ISO, 1999)
Gestão de aquisição
Revisão e avaliaçã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
Encerramento 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
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
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).
4XDGUR3DVVRVGRSURFHVVRGHFRQWDJHPGH3)
LL ,GHQWLILFDURHVFRSRGHFRQWDJHPHDIURQWHLUDGDDSOLFDomR
LLL &RQWDUDV)XQo}HVGHGDGRV
LY &RQWDUDV)XQo}HVWUDQVDFLRQDLV
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
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
$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$
LLL (PSUHVD&
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
$&$'(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 ^
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
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
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
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
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 : b1pDFHLWDHFRQFOXL-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.
7DEHOD9DORUHVGRVQtYHLVGHVLJQLILFkQFLDSREWLGRVSHOR³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
7DEHOD9DORUHVGRVQtYHLVGHVLJQLILFkQFLDSREWLGRVSHOR³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
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
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
(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
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
,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
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
)RUPDomRSURILVVLRQDO ÈUHDGHFHUWLILFDomR
Doutorado 1 IFPUG
8 3 18
Mestrado PMI
Especialização Outro
4
37 Graduação
23 3
Certificação
)LJXUD)RUPDomRSURILVVLRQDOGRVUHVSRQGHQWHV
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
([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
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.
21mRUHVSRQGHX1mRUHFRPHQGDGD3RXFR5HFRPHQGDGD5HFRPHQGDGD0XLWRUHFRPHQGDGD
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
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.
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
± ² ³ ´ µ ¶ · ¸ ¹ ±"º ±+±
)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
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
$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
3URFHVVRGHJHVWmRGHHVWLPDWLYDGHWDPDQKRGHSURMHWRGHVRIWZDUH
$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
22
* - Estas atividades podem ser realizadas diversas vezes, de acordo com a necessidade do projeto.
96
5HODFLRQDPHQWRGRSURFHVVRGHJHVWmRGHHVWLPDWLYDGHWDPDQKRFRPRVSURFHVVRVGH
GHVHQYROYLPHQWRHGHJHVWmRGHSURMHWRVGHVRIWZDUH
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
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
&RQVLGHUDo}HVILQDLVGRFDStWXOR
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
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
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
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
$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,=$d2'2*(5(17('2352-(72280(0%52'$(48,3(
,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
• 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
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
&$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)
$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,=$d2'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,621HRVIDWRVTXHSURYRFDPDWUDVRQRFURQRJUDPDIRUDP
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 3RXFR5HFRPHQGDGD5HFRPHQGDGD0XLWRUHFRPHQGDGD
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'$d2
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.
,,$&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:
1RLQtFLRGRGHVHQYROYLPHQWR6HPDQDO0HQVDO$SyVRWpUPLQRGHFDGDIDVHGHGHVHQYROYLPHQWR
6HPSHULRGLFLGDGHGHILQLGD1mRSUDWLFDHVWDVDo}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.
,,$&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
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
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
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 'LDJUDPDVGHVHTrQFLD
É 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
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
Manual do usuário
Manual do sistema
Material de treinamento
3URGXWRILQDOGRVRIWZDUHSDUDXVR
Rational.... (2001a)