Você está na página 1de 143

UNIVERSIDADE CATLICA DE BRASLIA

PROGRAMA DE PS-GRADUAO EM GESTO DO CONHECIMENTO E TECNOLOGIA DA INFORMAO

0HVWUDGR
3RQWRV GH &DVRV GH 8VR H 3RQWRV GH )XQomR QD JHVWmR GH HVWLPDWLYD GH WDPDQKR GH SURMHWRV GH VRIWZDUH RULHQWDGRV D REMHWRV Autora: Edmia Leonor Pereira de Andrade Orientadora: Profa. Dra. Kthia Maral de Oliveira

BRASLIA

2004

('0e,$ /(2125 3(5(,5$ '( $1'5$'(

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

Dissertao submetida ao Programa de Ps Graduao 6WULFWR 6HQVX em Gesto do Conhecimento e Tecnologia da Informao da Universidade Catlica de Braslia para obteno do Grau de Mestre. Orientadora: Profa. Dra. Kthia Maral de Oliveira.

Braslia 2004

7(502 '( $3529$d2

('0e,$ /(2125 3(5(,5$ '( $1'5$'(

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

Dissertao defendida e aprovada como requisito parcial para obteno do grau de Mestre no Programa de Ps-Graduao VWULFWR VHQVX em Gesto do Conhecimento e Tecnologia da Informao, em 20 de fevereiro de 2004, pela banca examinadora constituda por:

Profa. Dra. Kthia Maral de Oliveira Orientadora - UCB

Prof. Dr. Arnaldo Dias Belchior UNIFOR

Prof. Dr. Nicolas Anquetil UCB

Braslia UCB

'HGLFDWyULD

Ao meu esposo Ronaldo e queridos filhos Loriza, Priscila e Leandro pelo apoio, carinho e incentivo em todos os momentos.

ii

$JUDGHFLPHQWRV
A Deus por me proporcionar vida, a sabedoria e a coragem para realizar esta pesquisa. Aos meus pais, irmos e sogra, pelo apoio e incentivo. Ao meu esposo Ronaldo pelo apoio, incentivo, carinho, pacincia, colaborao nas revises e realizao das anlises estatstica. Aos meus queridos filhos Loriza, Priscila e Leandro pelo incentivo, carinho e compreenso nos momentos difceis. Aos diretores, gerentes e membros de projetos de software das empresas, aos professores e alunos da UCB que me forneceram as informaes fundamentais para a realizao desta pesquisa. Aos outros participantes da pesquisa que contriburam com relevantes informaes. A minha orientadora, Dra. Kthia, pelos ensinamentos, orientaes e principalmente pela pacincia durante a realizao deste trabalho. Aos outros professores do curso pelos conhecimentos transmitidos. Aos colegas de curso, especialmente Anglica, Paulo Leo 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 presena, crticas e sugestes de melhoria. E a todos que colaboraram de forma direta ou indireta na realizao desta pesquisa.

iii

5HVXPR
As organizaes tm-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 caractersticas 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 mtricas mais utilizadas na gesto de projetos de desenvolvimento de software, porque a partir desta dimenso possvel definir o esforo, o prazo e os custos necessrios para o desenvolvimento do software. Devido a isso, a estimativa de tamanho deve ser realizada no incio do projeto e refinada durante todo o seu ciclo de desenvolvimento. Em relao ao desenvolvimento Orientado a Objetos (OO), abordagem bastante utilizada no mercado atual, a estimativa de tamanho geralmente realizada atravs de duas mtricas: Anlise de Pontos de Funo (APF), que j utilizada em sistemas tradicionais desde 1979, e Pontos de Casos de Uso (PCU), proposta em 1993. Na primeira, a preciso da estimativa melhora medida que se obtm mais informaes da anlise e do projeto de sistemas. A segunda foi proposta para ser utilizada no incio 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 mtricas de medio so adequadas em momentos diferentes do desenvolvimento, esta pesquisa se prope a utilizar a APF e o PCU de forma combinada, para apoiar o gerente em relao gesto de estimativa de tamanho do projeto de software. Este apoio consiste da definio de um processo de gesto de estimativa de tamanho, que dever ser utilizado em paralelo aos processos de desenvolvimento e gesto de projetos de software. Este processo prope: i) utilizar o PCU e a APF quando so melhores aplicadas, tentando explorar a relao existente entre elas; ii) estimar o tamanho do software continuamente ao longo do processo de desenvolvimento do projeto; e, iii) sugerir aes 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 todays 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 projects planning and control.

6XPiULR
&$378/2  ,1752'8d2  1.1. MOTIVAO E RELEVNCIA DO PROBLEMA ........................................................................................................ 1 1.2. OBJETIVOS E SUPOSIES ................................................................................................................................... 4  2EMHWLYR JHUDO   2EMHWLYRV HVSHFtILFRV    6XSRVLo}HV   1.3. METODOLOGIA ................................................................................................................................................... 5 1.4. ESTRUTURA ........................................................................................................................................................ 6

&$378/2  0e75,&$6 '( (67,0$7,9$ '( 7$0$1+2 '( 62)7:$5(   2.1. INTRODUO ...................................................................................................................................................... 7 2.2. MEDIO DE SOFTWARE ..................................................................................................................................... 7 2.3. MTRICAS DE ESTIMATIVAS DE TAMANHO DE SOFTWARE ................................................................................. 10  $QiOLVH GH 3RQWRV GH )XQomR $3)    3RQWRV GH &DVR GH 8VR 3&8    2 XVR GR WDPDQKR GR SURMHWR QD HVWLPDWLYD GH HVIRUoR RX SURGXWLYLGDGH   2.4. CONSIDERAES FINAIS DO CAPTULO .............................................................................................................. 28

&$378/2  *(672 '( 352-(72 '( 62)7:$5(   3.1 INTRODUO ..................................................................................................................................................... 31 3.2. DEFINIO ........................................................................................................................................................ 31 3.3. PROCESSOS DE GESTO DE PROJETOS ................................................................................................................ 32  3ODQHMDPHQWR GH SURMHWR GH VRIWZDUH    &RQWUROH GH SURMHWR GH VRIWZDUH    *HVWmR GH SURMHWRV GH VRIWZDUH GH DFRUGR FRP DV QRUPDV  H   3.4. CONSIDERAES FINAIS DO CAPTULO .............................................................................................................. 49

62)7:$5( 25,(17$'2 $ 2%-(726  4.1. INTRODUO .................................................................................................................................................... 50 4.2. OBJETIVO .......................................................................................................................................................... 51 4.3. PADRONIZAO DOS PROCEDIMENTOS DE CONTAGEM DA APF E PCU PARA PROJETOS OO............................. 52  3URFHGLPHQWRV GH FRQWDJHP GD $3)    3URFHGLPHQWRV GH FRQWDJHP GH 3&8   4.4. RELAO ENTRE A APF E PCU ........................................................................................................................ 59  $SOLFDomR GDV PpWULFDV QD DFDGHPLD    $SOLFDomR GDV PpWULFDV QD LQG~VWULD    $QiOLVH GRV UHVXOWDGRV   (TXDomR GH UHODomR HQWUH 3) H 3&8   4.5.IDENTIFICAO DAS AES GERENCIAIS A SEREM TOMADAS PELOS GERENTES ................................................. 79 4.6. PROCESSO DE GESTO DE ESTIMATIVA DE TAMANHO DE PROJETO DE SOFTWARE ............................................. 92  5HODFLRQDPHQWR GR SURFHVVR GH JHVWmR GH HVWLPDWLYD GH WDPDQKR FRP RV SURFHVVRV GH GHVHQYROYLPHQWR H GH JHVWmR GH SURMHWRV GH VRIWZDUH  4.7. CONSIDERAES FINAIS DO CAPTULO ............................................................................................................ 102

&$378/2  *(672 '( (67,0$7,9$ '( 7$0$1+2 '( 352-(72 '(  

$31',&(6   APNDICE A - CARACTERSTICAS GERAIS E AMBIENTAIS QUE INFLUENCIAM NO SISTEMA..................................... 114 APNDICE B - GESTO DE ESTIMATIVAS EM PROJETOS DE SOFTWARE ................................................................... 121 APNDICE C - PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ORIENTADO A OBJETOS ...................................... 125

5()(51&,$6 %,%/,2*5),&$6  

&$378/2  &21&/862 ( 3(563(&7,9$6 )8785$6  

vi

/LVWD GH )LJXUDV
FIGURA 1 - ESTRUTURA DA NBR ISO/IEC 12.207 (ABNT, 1998) .............................................................................. 44 FIGURA 2 - RELAO ENTRE PCU E APF EM PROJETOS DA ACADEMIA E DA INDSTRIA.............................................. 78 FIGURA 3 - REA DE ATUAO DOS RESPONDENTES .................................................................................................... 82 FIGURA 4 - FORMAO PROFISSIONAL DOS RESPONDENTES ......................................................................................... 82 FIGURA 5 - EXPERINCIA EM GESTO DE PROJETOS ..................................................................................................... 83 FIGURA 6 - EXPERINCIA EM GESTO DE TEMPO DE EXECUO DE PROJETOS .............................................................. 83 FIGURA 7 - RELACIONAMENTO DO PROCESSO DE GESTO DE ESTIMATIVA DE TAMANHO COM OS PROCESSOS DE DESENVOLVIMENTO E GESTO DE PROJETOS DE SOFTWARE .............................................................................. 100

vii

/LVWD GH 4XDGURV
QUADRO 1 - COMPLEXIDADE FUNCIONAL (IFPUG, 2000) .......................................................................................... 15 QUADRO 2 - COMPLEXIDADE DE ENTRADA EXTERNA (IFPUG, 2000) ......................................................................... 16 QUADRO 3 - COMPLEXIDADE DE SADA EXTERNA (IFPUG, 2000) .............................................................................. 17 QUADRO 4 - COMPLEXIDADE DE CONSULTA EXTERNA (IFPUG, 2000) ....................................................................... 18 QUADRO 5 - CARACTERSTICAS 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 TCNICA (KARNER, 1993) .......................................................................... 24 QUADRO 9 - FATORES DE COMPLEXIDADE AMBIENTAL (FA) (KARNER, 1993) ............................................................ 25 QUADRO 10 - PRINCIPAIS CARACTERSTICAS E DIFERENAS ENTRE APF E PCU.......................................................... 29 QUADRO 11 - REAS DE CONHECIMENTO DA GESTO DE PROJETOS DO PMBOK X ATIVIDADES DO PROCESSO DE GESTO DA NBR ISO/IEC 12.207 (ISO, 1999) .................................................................................................. 46 QUADRO 12 MAPEAMENTO DOS PROCESSOS DE GESTO DE PROJETOS DA ISO 10.006 PARA AS ATIVIDADES DE GESTO 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 - AES A SEREM TOMADAS QUANDO O CRONOGRAMA IMPRATICVEL ................................................ 85 QUADRO 18 - AES A SEREM TOMADAS QUANDO O CRONOGRAMA EST DENTRO DO PRAZO ..................................... 87 QUADRO 19 - AES MAIS INDICADAS PARA CADA FATO ............................................................................................. 89 QUADRO 20 - AES A SEREM TOMADAS PELOS GERENTES QUANDO O CRONOGRAMA EST ATRASADO ..................... 92 QUADRO 21 - ATIVIDADES DO PROCESSO DE GESTO DE ESTIMATIVA DE TAMANHO ................................................... 94 QUADRO 22 - ARTEFATOS GERADOS DURANTE O PROCESSO DE DESENVOLVIMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETOS ...................................................................................................................................... 131

viii

/LVWD GH 7DEHODV
TABELA 1 - RESULTADO DA CONTAGEM DE PCU E PF NOS PROJETOS DA ACADEMIA .................................................. 67 TABELA 2 - RESULTADO DA CONTAGEM DE PCU E PF NOS PROJETOS DA INDSTRIA .................................................. 68 TABELA 3 - VALORES DOS NVEIS DE SIGNIFICNCIA (P) OBTIDOS PELO TESTE T NAS EQUAES DE REGRESSO QUADRTICA E LINEAR. ...................................................................................................................................... 73 TABELA 4- VALORES DOS NVEIS DE SIGNIFICNCIA (P) OBTIDOS PELO TESTE T NAS EQUAES DE REGRESSO LINEAR SEM INTERCEPTO. ................................................................................................................................... 74 TABELA 5 - AES RECOMENDADAS QUANDO O CRONOGRAMA IMPRATICVEL ....................................................... 84 TABELA 6 - AES A SEREM TOMADAS PARA CONTROLAR OU MANTER O CRONOGRAMA NO PRAZO ............................ 86 TABELA 7 - AES A SEREM TOMADAS QUANDO O CRONOGRAMA ESTIVER ATRASADO ............................................... 88

ix

&DStWXOR  ,QWURGXomR  0RWLYDomR H UHOHYkQFLD GR SUREOHPD


A competio entre organizaes de desenvolvimento de software vem aumentando com o crescimento do mercado de Tecnologia da Informao (TI). Conforme notcia disponibilizada na pgina do Ministrio da Cincia e Tecnologia (MCT), o mercado nacional de software deve crescer 5,3% em 2004, movimentando US$ 1,76 bilhes (MCT, 2003a). De acordo com o estudo denominado A indstria de Software no Brasil, elaborado pela Softex em parceria com o 0DVVDFKXVHWWV ,QVWLWXWH RI 7HFKQRORJ\ (MIT), em 2002, comparando-se o mercado do Brasil, da China e da ndia, a indstria brasileira de TI est pronta para competir com seus grandes concorrentes internacionais. Entre os trs pases estudados, o Brasil tem o maior mercado interno de software, da ordem de US$ 7,7 bilhes, mas exporta apenas 1,5% desse total, em produtos e servios, o que contrasta profundamente com a ndia, cujas exportaes superam 70% de seu mercado total, de US$ 8,2 bilhes, basicamente sob a forma de servios (MCT, 2003b). Em conseqncia desta realidade, as organizaes tm-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 caractersticas dependem de um gerenciamento do processo de desenvolvimento de software eficiente e eficaz. Nesse gerenciamento, essencial a adoo de normas, modelos de maturidade de processos de software, guias como NBR ISO/IEC 12.207 (ASSOCIAO BRASILEIRA DE NORMAS TCNICAS (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, esforo, prazos e custos. O tamanho de um projeto de software uma das primeiras estimativas a ser realizada, pois dessa dimenso depende a definio de esforo, custos e prazos necessrios para a definio do plano de desenvolvimento do software (CALDIERA et al., 1998). Alm de subsidiar o planejamento do projeto, a estimativa de tamanho facilita o relacionamento entre cliente e

fornecedor; permite o gerenciamento de riscos; o controle do cronograma e possibilita o conhecimento da produtividade da equipe, o que tambm beneficia a gerncia e a qualidade dos contratos de terceirizao de projetos de software (HAZAN, 1999; GARMUS; HERRON, 2000 e LONGSTREET, 2002). A preciso de estimativas de tamanho dependente de informaes que nem sempre esto disponveis no incio dos projetos. No entanto, essas estimativas so necessrias no incio do projeto para discusso de contratos ou determinao da viabilidade do projeto em termos da anlise de custos e benefcios. Sendo assim, necessrio obteno de estimativas mais precisas no incio do projeto, bem como o seu gerenciamento durante todo o ciclo de desenvolvimento do mesmo. Dessa forma, espera-se reduzir os problemas de gesto tais como: alto custos, atrasos no cronograma, insatisfao do usurio e dificuldades de medio do progresso do projeto (MURTHI, 2002). Vrias mtricas de tamanho de software tm sido desenvolvidas e melhoradas desde o final da dcada de 1960, entre elas: Linhas de cdigo (LOC) )XQFWLRQ 3RLQW $QDO\VLV %DQJ, 3RLQW &260,& )XOO )XQFWLRQV 3RLQWV (McPHEE, 1999; GARMUS; HERRON, 2000). )HDWXUH 3RLQWV DQG %RHLQJV ' )XQFWLRQ 3RLQW, 0DUN ,, )XQFWLRQ 3RLQW $QDO\VLV, 8VH &DVH

A estimativa de tamanho de projeto de software ainda est em evoluo nas empresas brasileiras. Pesquisa de qualidade e produtividade no setor de software brasileiro, realizada pela Secretaria de Poltica de Informtica do Ministrio da Cincia e Tecnologia (MCT) em 2001, demonstraram que em uma amostra de 446 organizaes do mercado de software brasileiro (91,5% delas so empresas privadas), apenas 30% utilizavam algum tipo de mtrica para medir a produtividade e a qualidade dos processos de software. Dentre essas, 10,3% utilizam LOC, 18,2% utilizavam a APF e 6,7% utilizam outras mtricas (MCT, 2002). Embora o ndice de uso de mtricas no Brasil seja baixo, Aguiar (2003) ressalta que o interesse pela APF tem crescido bastante. Sua afirmao tem como base o aumento de profissionais brasileiros certificados pelo IFPUG como Especialistas em Pontos de Funo (CFPS) nos ltimos trs anos. Enquanto, no perodo de 1996-2001 havia 16 CFPS, somente em 2002 e 2003 tiveram 80 certificaes. De acordo com a lista de profissionais certificados, disponibilizada na pgina do %UD]LOLDQ )XQFWLRQ 3RLQW 8VHUV *URXS (BFPUG), existem at janeiro de 2004, 139 (cento e trinta e nove) especialistas certificados pelo IFPUG no Brasil.

3 A )XQFWLRQ 3RLQW $QDO\VLV ou Anlise de Pontos de Funo (APF) uma das mtricas mais utilizadas em sistemas tradicionais desde 1979 e mede o tamanho das funes do software sob o ponto de vista do usurio, utilizando a documentao gerada durante todo o processo de desenvolvimento do produto, principalmente as da fase de projeto. Apesar da APF ser a mtrica de tamanho mais utilizada no mercado, muitos autores criticam a sua adequao 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 tcnicas de anlise 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 crtica, diversos estudos tm sido realizados propondo o mapeamento da APF para OO ou desenvolvendo novas mtricas 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 tambm atravs de Pontos de Casos de Uso (PCU), uma mtrica mais recente, proposta em 1993 para a estimativa de projetos de software orientado a objetos. A principal diferena entre APF e PCU est relacionada ao momento da coleta de informaes para a estimativa de tamanho inicial do projeto. A APF possui resultados melhores, medida, em que se tem mais informao da anlise e do projeto de sistemas (tabelas, campos, associaes, etc). O PCU tem como proposta ser utilizado logo no incio do ciclo de desenvolvimento, na fase de definio dos requisitos, com base no modelo de casos de uso. O modelo de casos de uso uma tcnica largamente utilizada na indstria para capturar e descrever os requisitos funcionais de um software. Esse modelo consiste de diagramas e descries de casos de uso (ANDA, 2002). Considerando que os casos de uso so desenvolvidos durante a fase de levantamento de requisitos e anlise e que eles capturam representaes precisas das necessidades do usurio, 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 so mantidos por outros artefatos como projeto, cdigo, documento de testes, gesto de configurao,

arquitetura etc. Alm disso, os casos de uso so centrados nos usurios e no no projeto do sistema (DAMODARAN; WASHINGTON, s.d). Se estas mtricas possuem pontos positivos e tm sido utilizadas em projetos de software orientado a objetos, conforme demonstrado na literatura, porque no utiliz-las de forma combinada para obter estimativas mais precisas no incio do projeto e permitir ao gerente o refinamento das mesmas durante todo o processo de desenvolvimento do projeto? Atravs do uso combinado da APF e PCU e de uma abordagem de gesto 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 dimenso do que est sendo gerenciado no incio do projeto. Isto permite subsidiar o planejamento, comparar as estimativas, controlar o projeto com mais segurana e providenciar aes de ajustes no plano e no cronograma, para minimizar problemas existentes em relao ao custo e prazo dos projetos de software e, conseqentemente, aumentar a satisfao do cliente. Para isto, necessrio padronizar os procedimentos de contagem definidos originalmente para a APF e PCU para projetos OO, de acordo com os resultados e as experincias dos autores que aplicaram estas mtricas nesse tipo de projetos, investigar a existncia de relao entre a APF e PCU, visando utilizar essas mtricas de forma combinada para estimar o tamanho de projetos de software OO com maior preciso desde o incio do projeto e identificar aes a serem tomadas pelos gerentes durante a execuo e o controle do projeto de software.

 2EMHWLYRV H 6XSRVLo}HV


 2EMHWLYR JHUDO

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 disponveis durante o processo de desenvolvimento do projeto de software orientado a objetos, provendo subsdios para melhorar as decises gerenciais.  2EMHWLYRV HVSHFtILFRV Para atender ao objetivo geral necessrio: estudar as principais caractersticas da APF e PCU e aplic-las em projetos de software orientados a objetos;

investigar a existncia de relao entre as mtricas APF e PCU; identificar as aes gerenciais a serem tomadas pelo gerente durante o controle e acompanhamento do projeto.

 6XSRVLo}HV Desta forma, as suposies a serem investigadas nesta pesquisa so: existe relao entre APF e PCU que pode ser descrita por uma equao matemtica; 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 prtica de usar as mtricas 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 informaes dos projetos de software para encontrar a relao entre a aplicao das duas mtricas. E quanto aos meios, caracteriza-se como investigao documental, bibliogrfica e de campo. A pesquisa de campo envolveu a aplicao de um questionrio para a identificao das aes gerenciais entre os profissionais que exercem o papel de gerente de projetos de software em empresas pblicas e privadas. Para a realizao deste trabalho, foi feito um estudo bibliogrfico na literatura para obter entendimento terico necessrio sobre medio de software, mtricas de estimativa de tamanho de software, APF, PCU e respectivos processos de contagem, gesto de projetos de software e aes gerenciais relacionadas gesto de estimativas de tamanho durante a execuo e o controle de projeto de software. A partir deste estudo, foi definido um processo de gesto 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 relao existente entre a APF e PCU e identificadas aes 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

PMBOK (PMBOK, 2000) e em um processo de desenvolvimento de software OO (RATIONAL..., 2001b).

 (VWUXWXUD
Este trabalho consiste de cinco captulos, incluindo este que a introduo. No captulo 2, so apresentados os conceitos relacionados medio, s mtricas de estimativa de tamanho de software s principais caractersticas e aos procedimentos de contagem das mtricas da APF e PCU, aos trabalhos relacionados aplicao dessas mtricas em projetos de software orientados a objetos, disponveis na literatura e s principais diferenas entre APF e PCU. No captulo 3, so apresentados os conceitos de gesto de projetos, os principais processos, principalmente os de planejamento e controle e a gesto de projetos de acordo com a NBR ISO/IEC 10.006 (ABNT, 2000) e a NBR ISO/IEC 12.207 (ABNT 1998). O captulo 4 descreve o objetivo e as atividades relevantes para a gesto de estimativa de tamanho, que engloba: padronizao dos procedimentos de contagem de PF e PCU em projetos de software OO; investigao da relao entre PF e PCU; identificao das aes gerenciais a serem tomadas pelos gerentes durante a execuo do projeto; a definio do processo de gesto de estimativa e o seu relacionamento com os processos de desenvolvimento e a gesto de projetos de software. No captulo 5, so apresentadas as principais contribuies deste trabalho para a melhoria do processo de gesto de estimativa de tamanho e as perspectivas de trabalhos futuros. Finalmente, apresentado o questionrio explicativo para identificar o nvel de influncia das caractersticas gerais do sistema (IFPUG, 2000) e dos fatores tcnicos e ambientais propostos por Karner (1993) (APNDICE A), o questionrio para identificar as aes gerenciais a serem tomadas pelos gerentes durante a gesto de estimativas (APNDICE B) e o modelo do processo de desenvolvimento de projeto de software OO (APNDICE C).

 ,QWURGXomR

&DStWXOR  0pWULFDV GH HVWLPDWLYD GH WDPDQKR GH VRIWZDUH

Eficincia, entrega do produto no prazo, dentro do oramento e com um nvel de qualidade desejado pelo cliente so caractersticas que influenciam no sucesso de organizaes de desenvolvimento de software no mercado atual, globalizado e competitivo de TI. Neste sentido, ressaltam-se a importncia de mecanismos de acompanhamento e a avaliao do progresso do processo, projeto e produto. Estes mecanismos, normalmente baseados em informaes qualitativas e quantitativas coletadas atravs de medies realizadas durante o projeto, so recursos essenciais na gesto de desenvolvimento de software. Para o gerente do projeto, essas medidas, tambm conhecidas como mtricas, permitem melhor entendimento do processo de produo e do controle do projeto de software. Desta maneira, as medies fornecem informaes que permitem a determinao de pontos fortes e fracos dos processos e produto, indicam aes corretivas e propiciam avaliaes de impactos de tais aes. Enfim, garantem a qualidade do processo e dos produtos obtidos (FENTON; PFLEEGER, 1997; BASILI; CALDIERA; ROMBACH, 1994). A necessidade de medidas que informem a eficincia do desenvolvimento e minimizem os fracassos de projetos, principalmente em relao s falhas no cronograma e nas estimativas realizadas, demandaram a realizao de estudos na rea de estimativa de tamanho de software, que resultaram na proposio de diversas mtricas ou mtodos de medio de processo, projeto e produtos de software. Este captulo apresenta alguns conceitos relacionados medio e s mtricas de estimativa de tamanho de software APF e PCU e as principais pesquisas realizadas sobre a aplicao das mesmas em projetos de software orientados a objetos.

 0HGLomR GH VRIWZDUH


Medio um processo pelo qual nmeros ou smbolos so atribudos 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 medio como um mecanismo para criar memria corporativa e auxiliar nas buscas de respostas para diversas

questes associadas ao processo de software. Estes autores ressaltam que para ser efetiva, a medio tem que focar em objetivos especficos, ser aplicada durante todo o processo de desenvolvimento do produto, processo e projeto e ser interpretada com base na caracterizao e no entendimento do contexto organizacional. Por outro lado, McGarry et al., (2001) ressaltam que o sucesso do programa de medio depende de um processo estruturado e repetitivo que define as atividades de medidas (coleta, anlise e apresentao dos dados) diretamente relacionadas s necessidades de informao dos gerentes de projetos. Estes autores destacam tambm, que a medio mais efetiva quando implementada de forma integrada com as atividades tcnicas e de gesto que definem os projetos de software, porque a medio fornece informaes objetivas relacionadas aos riscos e problemas que podem ter impacto nos objetivos dos projetos definidos. Pressman (2002), com base no ,((( 6WDQGDUG *ORVVDU\ RI 6RIWZDUH (QJLQHHULQJ 7HUPV define medida como uma indicao quantitativa da extenso, dimenso, capacidade ou tamanho de algum atributo de um produto ou de um processo e mtrica como uma medida quantitativa do grau em que um sistema, componente ou processo possui determinado atributo . Com base nas medidas, so obtidos os indicadores que so uma mtrica, ou combinao de mtricas que fornecem compreenso de um processo, recursos e projeto ou produto de software (PRESSMAN, 2002). As mtricas podem ser classificadas em vrias categorias: mtricas de processo, produto e recursos (FENTON; PFLEEGER, 1997), objetivas e subjetivas (MLLER; PAULISH, 1993) e diretas e indiretas (FENTON; PFLEEGER, 1991; PRESSMAN, 2002). As mtricas de processo medem as atividades realizadas durante todo o desenvolvimento de software; as mtricas de produto medem os artefatos, produtos e documentos gerados pelo processo; e as mtricas de recursos medem as entidades requeridas para a execuo do processo (FENTON; PFLEEGER, 1997). As mtricas objetivas podem ser quantificadas e medidas atravs de expresses numricas ou representaes grficas de expresses numricas contadas a partir do cdigo fonte, projeto, dados de teste, e outras informaes do software. As mtricas subjetivas so medidas baseadas em estimativas pessoais ou de grupo, geralmente obtidas atravs de conceitos como excelente, regular, bom e ruim (MLLER; PAULISH 1993).

Para Fenton e Pfleeger (1997), mtricas subjetivas dependem da pessoa que est mensurando, do seu julgamento e do grau de impreciso, o que dificulta o consenso entre atributos que envolvem processos, produtos ou qualidade. As mtricas diretas so aquelas que no dependem da medida de outro atributo, mas da quantificao de um fator observado no produto. J as mtricas indiretas envolvem as medidas de um ou mais atributos relacionados a este (FENTON; PFLEEGER, 1991). Dentro da categoria de mtricas direta, McGarry et al. (2001) destacam algumas abordagens de mtricas de estimativas de projeto de software como: i) modelos paramtricos; ii) analogia; iii) julgamento de especialistas; iv) atividades baseadas em modelos; e v) relacionamentos de estimativas. As abordagens mais comuns so os modelos paramtricos, analogia e julgamento de especialistas. Os modelos paramtricos assumem que existe um relacionamento matemtico entre o tamanho, esforo, cronograma e qualidade e que o relacionamento afetado por fatores mensurveis de desempenho tambm chamados parmetros. A entrada mais importante nesse modelo o tamanho, o qual representa a quantidade de funes do software. Para obter melhores resultados, os modelos paramtricos tm 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 experincia de projetos anteriores) e por algoritmos de busca de projetos similares (disponveis em base de dados) (JORGENSEN; INDAHL; SJOBERG, 2003). Esta abordagem requer um conhecimento detalhado do projeto para identificar as diferenas especficas entre o projeto proposto e os projetos realizados anteriormente, que foram usados como base para fazer a estimativa. O relatrio do estudo realizado por Heemstra (1992), citado por Jorgensen; Indahl; Sjoberg (2003) em 600 organizaes destaca que a estimativa por analogia o mtodo mais comum de estimativa na indstria de software. O julgamento de especialistas realizado com base nas experincias de profissionais em projetos semelhantes. As tcnicas baseadas na experincia de especialistas so teis na ausncia 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 histricos de taxa de entrega, de cronogramas e de custo do projeto .

10

Para obter resultados significativos, todas as abordagens de mtricas de estimativas requerem alguns dados histricos similares ao projeto proposto incluindo, o domnio da aplicao, o nvel de maturidade do processo de desenvolvimento, a experincia da equipe, taxas de produtividade, tipos de tecnologia e de ferramentas utilizadas e o grau de reuso (McGARRY et al., 2001; FENTON; PFLEEGER, 1997). A seguir, sero apresentadas as mtricas de estimativa de tamanho de software que, em geral, so baseadas em modelos paramtricos.

 0pWULFDV GH HVWLPDWLYDV GH WDPDQKR GH VRIWZDUH


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 soluo tcnica e na gesto 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 fsico (que so medidos atravs da especificao de requisitos, anlise, projeto e cdigo); com base nas funes que o usurio obtm, 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 mtricas de estimativa de tamanho de software surgiram em 1950/1960 e se basearam no tamanho fsico de linhas de cdigo como o /LQHV RI &RGH (LOC) (FENTON; NEIL, 2000). Esta mtrica 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 histricos pois, grande parte dos dados de estimativas existentes, foram medidos atravs de LOC. J, as desvantagens esto relacionadas ambigidade, pois a mtrica trata de abstraes no textuais, e a falta de significado da medida para o usurio final. Alm 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 programao e pode ser cinco vezes superior a uma outra estimativa, devido s diferenas das tcnicas de medio de linhas em branco, linhas de comentrio, declarao de dados e linhas de

11

instrues. Fenton e Pfleeger (1997) destacam ainda, que a LOC penaliza programas pequenos e bem projetados, no se adapta s linguagens no procedimentais e de difcil obteno na fase inicial de planejamento. LOC foi uma mtrica bastante utilizada at meados de 1970. A partir da surgiram diversas linguagens de programao e conseqentemente a necessidade de outras formas de estimar o tamanho de software. Atualmente, so vrias as mtricas de estimativa de tamanho existentes e grandes as dificuldades para selecionar a mais apropriada para o tamanho de um projeto de software de uma organizao. As principais mtricas foram desenvolvidas com base nas funes de software tais como: )XQFWLRQ 3RLQW $QDO\VLV ou Anlise de Pontos de Funo; %DQJ; )HDWXUH 3RLQWV %RHLQJV 3RLQW (McPHEE, 1999; GARMUS; HERRON, 2000). (' )XQFWLRQ 3RLQW; 0DUN ,,; 8VH &DVH 3RLQW ou Pontos de Casos de Uso, &260,& )XOO )XQFWLRQ A Anlise de Pontos de Funo (APF) uma das primeiras mtricas a medir o tamanho do software com alguma preciso, a mais utilizada no mercado, tornando-se padro internacional em 2002 atravs 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 funes do software de acordo com a viso do usurio) e no processo 2EMHFWRU\ , onde foi (OO), com base na mesma filosofia da APF e 0DUN ,, (a estimativa de tamanho baseada nas

desenvolvida a tcnica de diagramao para o conceito de casos de uso. Posteriormente, Ivar Jacobson desenvolveu a 2EMHFW2ULHQWHG 6RIWZDUH (QJLQHHULQJ (OOSE) , metodologia centrada em casos de uso1, tcnica largamente utilizada na indstria 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 viso dos usurios, faz sentido
1

Caso de uso representa as funes do sistema. uma coleo de interaes seqenciais entre o software em desenvolvimento e seus atores externos relacionados a um objetivo especfico. Os casos de uso possuem relacionamentos do tipo includos e estendidos (COCKBURN, A., 2000, citado por RIBU, 2001). O comportamento comum executado atravs de casos de usos includos e os opcionais, atravs dos casos de uso estendidos. O relacionamento tipo includo usado para evitar a cpia do mesmo texto em fluxos alternativos de diversos casos de uso. Esses tipos de casos de uso so sempre chamados quando o caso de uso nomeado num passo de um outro caso de uso. O caso de uso estendido indica que uma instncia do caso de uso pode ou no incluir o comportamento especificado no outro caso de uso. Este tipo de relacionamento descreve alternativas ou adies ao cenrio principal e so escritas separadamente (Ribu, 2001). No h regras precisas para a contagem dos casos de uso includos e estendidos.

12

basear a estimativa de tamanho e recursos de projetos de software nos casos de usos (DAMODARAN; WASHINGTON, s.d). Como a APF a mtrica mais usada no mercado e prov estimativas mais precisas medida que se obtm mais informaes do projeto e o PCU foi criado para estimar projetos OO com base no modelo de casos de uso gerado no incio do projeto, essas mtricas foram selecionadas como objeto de estudo deste trabalho. Dessa forma, as caractersticas relevantes, o processo de contagem e os principais estudos sobre o uso dessas mtricas em projetos OO, sero apresentadas a seguir.  $QiOLVH GH 3RQWRV GH )XQomR $3) A APF foi desenvolvida em meados da dcada de 70 e publicada em 1979 por Allan Albrecht na tentativa de minimizar as dificuldades associadas s linhas de cdigo como medida de tamanho de software, e de ajudar na gerao de um mecanismo que pudesse prever o esforo associado ao desenvolvimento de software (LONGSTREET, 2002). A primeira verso da APF visava tratar dos fatores externos, das caractersticas importantes para o usurio, ser aplicada no incio do processo de desenvolvimento do produto, ser ligada produtividade econmica e ser independente do cdigo fonte ou linguagem de programao do software (McPHEE, 1999). Em 1984, Allan Albrecht refinou esta verso e, posteriormente, com o aumento do uso da APF, tornou-se necessrio definir um guia que interpretasse as regras originais para os novos ambientes. Devido essa necessidade, em 1986 foi criado o ,QWHUQDWLRQDO )XQFWLRQ 3RLQW 8VHUV *URXS (IFPUG). A partir desta data, o IFPUG passou a ser o responsvel pela definio das regras de contagem, pelo treinamento e pela certificao dos profissionais interessados na aplicao dessa mtrica e divulgao de diversas bases de dados histricas de produtividade da indstria de desenvolvimento de software, disponibilizadas por vrios rgos, entre eles o ,QWHUQDWLRQDO 6RIWZDUH %HQFKPDUNLQJ 6WDQGDUGV *URXS (INTERNATIONAL SOFTWARE BENCHMARKING STANDARDS GROUP (ISBSG), 2002). Essas informaes possibilitam a estimativa de tempo de desenvolvimento de novos projetos de software e produtividade da equipe com base em estimativas anteriores realizadas atravs da APF (GARMUS; HERRON, 2000; IFPUG, 2000; LONGSTREET, 2002).

13

A APF tornou-se a mtrica mais usada e estudada na histria da engenharia de software e no final de 1993 j havia grupos de usurios em 18 pases (JONES, 1994). A APF visa estabelecer uma medida de tamanho do software, em Pontos de Funo (PF) (unidade de medida para software assim como a hora unidade de medida para tempo), atravs da quantificao das funes implementadas sob o ponto de vista do usurio, num enfoque empresarial e no tcnico (LONGSTREET, 2002). Essa mtrica tem como princpio bsico focar na especificao de requisitos para obter estimativas de tempo, custo, esforo e recursos na fase inicial do projeto ou na manuteno de software independente da tecnologia utilizada para implementao (FUREY, 1997; RIBU, 2001). A APF permite uma contagem indicativa no incio do desenvolvimento sem conhecer detalhes do modelo de dados. Posteriormente, na fase de projeto, essa contagem passa a ser uma estimativa com maior preciso da complexidade das funes e, ao trmino do desenvolvimento do software, na implantao, realizada uma contagem detalhada, obtida a partir do grau de complexidade das funes levantadas no processo funcional, modelo de dados, descrio das telas e relatrios (IFPUG, 2000; LONGSTREET, 2002). Em geral, as organizaes aplicam a APF como: um mtodo para determinar o tamanho do pacote de software adquirido; para apoiar a anlise da produtividade e qualidade; para estimar os custos, recursos e esforos de projetos de desenvolvimento e manuteno de software (HAZAN, 1999; GARMUS; HERRON, 2000) Alm destas finalidades, Longstreet (2002) destaca outras utilidades da APF tais como: definir quando e onde fazer reengenharia; estimar casos de testes; entender o aumento do escopo; ajudar em negociaes contratuais; desenvolver um conjunto padro de mtricas; e fazer comparao de software. Para estimar o tamanho do software de acordo com a AFP, o IFPUG definiu os procedimentos de contagem conforme descritos a seguir.  3URFHVVR GH FRQWDJHP GH $QiOLVH GH 3RQWRV GH )XQomR O processo de contagem da APF compe-se de sete etapas (IFPUG, 2000): i) 'HWHUPLQDU R WLSR GH FRQWDJHP - A APF se prope a estimar o tamanho de

projetos de desenvolvimento; aplicaes em uso ou projetos de manuteno.

14 ,GHQWLILFDU R HVFRSR GD FRQWDJHP H D IURQWHLUD GD DSOLFDomR O escopo define as funes que sero contadas de acordo com a viso do usurio, e a fronteira da aplicao separa o projeto a ser contado dos usurios e das aplicaes externas ao domnio do projeto. iii)

ii)

&RQWDU DV IXQo}HV GH GDGRV As funes de dados consistem de: Arquivos Lgicos Internos (ALIs) e Arquivos de Interface Externa (AIEs). Um AIE de uma aplicao sempre ser contado como um ALI na aplicao de origem. Para identificar um ALI, observar as seguintes regras: a. se o grupo de dados ou informaes de controle lgico e identificvel pelo usurio; b. se o grupo de dados mantido atravs de um processo elementar dentro da fronteira da aplicao a ser contada.

A complexidade dos ALIs identificada atravs do nmero de itens de dados4 e de registros lgicos5. Para identificar os itens de dados, seguir as seguintes regras: a. contar um item de dados para cada campo reconhecido pelo usurio como nico, no repetido, mantido por um ALI ou recuperado de um AIE ou de um ALI; b. quando duas aplicaes mantm e ou referenciam o mesmo ALI ou AIE, mas cada uma mantm ou referencia itens de dados separados, conte apenas os itens de dados utilizados em cada aplicao para avaliar a complexidade dos ALI e AIE; c. contar um item de dado para cada campo requerido pelo usurio para estabelecer um relacionamento com outro ALI ou AIE que, no caso, considerada chave estrangeira. Para identificar um AIE, verificar grupos de dados ou informao de controle que satisfaam a definio de um AIE. As seguintes regras devem ser verificadas:
2

Arquivo Lgico Interno um grupo lgico de dados ou informaes de controle sob o ponto de vista do usurio, cuja manuteno feita internamente pela aplicao. Arquivo de Interface Externa um grupo lgico de dados referenciado na aplicao cuja responsabilidade pela manuteno de outra aplicao, ou seja, no mantido pela aplicao que est sendo contada. So armazenados fora da fronteira da aplicao. Item de dados representa um segmento de um registro do ALI que tem significado nico e identificado pelo usurio. So os campos da tabela e deve-se contabilizar um item de dado para cada campo. Registros lgicos so subgrupos de dados reconhecidos pelo usurio dentro de um Arquivo Lgico Interno.

15

a. o grupo de dados ou informao de controle lgico e identificvel pelo usurio; b. o grupo de dados referenciado pela aplicao a ser contada mas pertence outra aplicao fora da fronteira da aplicao; c. o grupo de dados no mantido pela aplicao a ser contada; d. o grupo de dados mantido em um Arquivo Lgico Interno de outra aplicao. De acordo com o nmero de itens de dados e de registros lgicos identificados, classificase o ALI e AIE conforme a Quadro 1 e atribui os pesos de 7, 10 ou 15 PFs para os ALIs e 5, 7 ou 10 PFs para os AIE respectivamente complexidade baixa, mdia ou alta. 4XDGUR   &RPSOH[LGDGH IXQFLRQDO ,)38* 
   !  "#"      

iv)

&RQWDU DV IXQo}HV WUDQVDFLRQDLV Estas funes representam as funes de processamento dos dados fornecidos pela aplicao ao usurio. As funes transacionais podem ser Entradas Externas (EE)6, Sadas Externas (SE)7 e Consultas Externas (CE)8. Compem-se de itens referenciados (parmetros que esto sendo representados pelos seus tipos) e de arquivos referenciados.

Para identificar as EEs, devem ser analisados todos os processos elementares que recebem dados de fora da aplicao e que atualizam um ou mais ALIs de acordo com as seguintes regras: a. os dados ou informao de controle devem ser recebidos de fora da fronteira da aplicao;
6

Entradas Externas so transaes recebidas de fora da fronteira da aplicao que tm 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 informaes de negcios ou informao de controle. Sadas Externas so as transaes que geram dados e os enviam para fora da fronteira da aplicao. Tm que apresentar informao para o usurio atravs de processamento lgico diferente ou adicional recuperao de dados ou informao de controle. Ex: dados transferidos para outra aplicao (dados contidos em um ALI e ou AIE, que so formatados e processados para uso em uma outra aplicao); relatrios (se suas sadas usam processamento ou clculos distintos); dados derivados (dados que resultam de clculos, frmulas, ou outras operaes sobre dados originais); formatos grficos; gerador de relatrios (sadas que so desenvolvidas para o usurio por meio de um gerador de relatrios). Consultas Externas so combinaes entre atividades de entrada e sada de dados, ou seja, uma solicitao enviada para a aplicao, a qual gera uma recuperao correspondente e exibe os dados.

H 92FEC@8 G D B A 1   R #SQ   )   )

92&75 6 8 6 #SQ   R "#I  P    )

  R #SQ

"#I  P  "#I  P 

341 1 2

 $ !'&0%('&% )  $ H 9FFBCA T G 2 D 25 8 1

16

b. no mnimo, um AIE mantido, se a entrada de dados pela fronteira no for informao de controle que altera o comportamento do sistema. Para contabilizar o item de dado referenciado na transao de EE, considerar as seguintes regras: a. os itens de dados de acordo com a viso do usurio; b. contar os itens de dados, que aparecem mais de uma vez em um arquivo por causa da tecnologia ou tcnica de implementao apenas uma vez; c. considerar um item de dado adicional para as teclas de funo ou linha(s) de comando que especificam a ao a ser tomada pela EE; d. contabilizar os campos no informados pelo usurio, mas que so atualizados em um ALI por uma EE; e. as mensagens de erros, confirmao ou itens de dados adicionais, devem ser consideradas, caso sejam requeridas pelo usurio. De acordo com o nmero de itens de dados, ALI e AIE referenciados, classifica-se a EE em baixa, mdia ou alta, conforme o Quadro 2 abaixo e os respectivos pesos (3, 4 ou 6 PF). Para identificar as SE verificar o processamento lgico do processo elementar de acordo com as seguintes regras: Quadro 2 - Complexidade de Entrada Externa (IFPUG, 2000)
H 92FECA T 1 G D B   R #SQ   )   )    !  "#"       8 41&8 2 #SQ   R "#I  P    ) 1 X 2   R #SQ "#I  P  "#I  P     ! #"   W V U  # H 9FFBCA G 2 D 1 2&6 5 Y

a. se contm no mnimo, uma frmula matemtica ou clculo; b. se cria dados derivados; c. se mantm no mnimo, um ALI; d. se altera o comportamento do sistema. J a complexidade da SE verificada atravs do nmero de arquivos e elementos de dados referenciados. Deve-se contar um arquivo referenciado para cada ALI mantido ou lido ou um AIE lido durante o processamento da SE. Para identificar os itens de dados, observar as regras:

17

a. contar um item de dado para cada campo reconhecido pelo usurio, no repetido, que entre pela fronteira da aplicao 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 aplicao. Se um item de dado entra e sai pela fronteira da aplicao, cont-lo apenas uma vez; b. contar um item de dado quando a aplicao 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 ao a ser tomada, quando existem mltiplos mtodos para chamar o mesmo processo lgico; d. no contar os campos que so recuperados ou derivados pelo sistema e armazenados em um ALI durante o processo elementar se esses campos no cruzam a fronteira da aplicao; e. no contar variveis, nmeros de pginas, data/hora ou selos gerados pelo sistema. Aps 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, mdia ou alta. 4XDGUR   &RPSOH[LGDGH GH 6DtGD ([WHUQD (IFPUG, 2000)
   !  "#"      

A CE visa apresentar informao para o usurio atravs da recuperao de dados ou informao de controle. Verificar se o processamento lgico elementar, segundo as regras abaixo: a. recupera dados ou informao de controle de um ALI ou AIE; b. no contm frmulas matemticas ou clculos; c. no cria dados derivados; d. no mantm ALI; e. no altera o comportamento do sistema.

H 92FEC&75 G D B A 6   R #SQ   )   )

#SQ   R   )

"#I  P 

3 412 T

  R #SQ

"#I  P  "#I  P 

1 8 2

   ! #"   W V U  # H 9FFBC&X G 2 D A 1 2&6 Y 25

18

De acordo com o nmero de itens de dados e arquivos referenciados, classificam-se as CEs conforme o Quadro 4 e atribui-se o peso 3, 4 ou 6 PF conforme a complexidade baixa, mdia ou alta. v) 'HWHUPLQDU R 3) QmR DMXVWDGR Aps identificar as funes de dados e transacionais, multiplicar o total de ALI, AIE, EE, SE e CE pela respectiva complexidade para determinar o valor de PF no ajustado. De acordo com a complexidade, cada uma das funes de dados e transacionais contribui com um determinado nmero de PF. O total desses pontos de funo computados chamado de pontos de funo no-ajustados. 4XDGUR   &RPSOH[LGDGH GH &RQVXOWD ([WHUQD IFPUG, 2000)
   !  "#"      

vi)

'HWHUPLQDU R )DWRU GH $MXVWH  O nvel de influncia dos fatores de ajustes tcnicos determinado com base nas 14 caractersticas gerais de sistemas, conforme mostra o Quadro 5 e o Apndice A (questo 1 a 14). Aps atribuir e somar os valores dos fatores de ajustes para obter o nvel de influncia da )$725 '( $-867( aplicao, deve-se aplicar a seguinte frmula: 1tYHO GH ,QIOXrQFLD   

4XDGUR   &DUDFWHUtVWLFDV JHUDLV GR VLVWHPD (IFPUG, 2000) &DUDFWHUtVWLFDV JHUDLV GR VLVWHPD


Comunicao de dados Processamento distribudo Desempenho Utilizao de equipamentos Volume de transaes Entrada de dados on-line Eficincia do usurio final Atualizao on-line Processamento complexo Reutilizao de cdigo Facilidade de implantao Facilidade operacional Mltiplos locais Facilidade de mudanas

H 92FEC&75 G D B A 6   R #SQ   )   )

#SQ   R   )

"#I  P 

3 412 T

  R #SQ

"#I  P  "#I  P 

1 8 2

   ! #"   W V U  # H 9FFBC&X G 2 D A 1 2&6 Y 25

19

Estas caractersticas influenciaro a complexidade do software e conseqentemente seu tamanho. As caractersticas gerais do software podem variar o tamanho do software em 35% mais ou menos. vii) &DOFXODU RV 3RQWRV GH )XQomR DMXVWDGRV  Os PFs ajustados so calculados a partir dos PFs no ajustados determinados no tem v e do fator de ajuste 3)B'(6(192/9,0(172 3)B12 $-867$'2 )$725B$-867( determinado no tem vi de acordo com a seguinte frmula:

Apesar da APF ser a mtrica mais utilizada para estimativa de tamanho de software, essa mtrica tem apresentado limitaes por ter sido desenvolvida com base nas tcnicas estruturadas. Uma limitao da APF refere-se tentativa de seu uso na medio do tamanho funcional de outros tipos de software como o de tempo real, cientficos e orientados a objetos (JONES, 1996; WHITMIRE, 1992; REIFER, 1990; MUKHOPADHYAY; KEKRE, 1992, citados por ABRAN et al. (2000); RIBU, 2001). Em relao a software OO, vrios estudos tem sido realizados sobre o uso e mapeamento dos conceitos da APF para conceitos OO, conforme apresentado a seguir.  7UDEDOKRV UHODFLRQDGRV DR XVR GD $3) HP SURMHWRV GH VRIWZDUH 22 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 lgico e as mensagens como transaes) (WHITMIRE e ASMA, ambos citados por FETCKE; ABRAN; NGUYEN (1997); CALDIERA et al. (1998)). Uemura; Kusumoto; Inoue (1999) detalharam as regras de medio da APF para a especificao de requisitos e projetos usando os diagramas de seqncia e de classes com base na 8QLILHG 0RGHOOLQJ /DQJXDJH (UML) (KUSUMOTO; INOUE; KASIMOTO, 2000). Por outro lado, Gupta R. e Gupta S. (1996) acreditam que no existe um simples relacionamento entre os conceitos originais da APF e os conceitos de objetos e servios. Outros autores, alm de fazer o mapeamento da APF para OO propuseram novos mtodos, tais como: )DVW &RXQW 2EMHFW 2ULHQWHG )XQFWLRQ 3RLQW 22)3  3UHGLFWLYH 2EMHFW

20 3RLQW 323V  2EMHFW 2ULHQWHG 'HVLJQ )XQFWLRQ 3RLQWV 22')3  )DVW


`

3RLQW 8&3 

6HULRXV H 8VH &DVH

O )DVW &RXQW foi desenvolvido em 1993 para estimar PF, com base no mtodo cientfico.

Este mtodo permite que a equipe de projetos faa a estimativa de tamanho em menos tempo (conta quatro vezes mais rpido) que a APF porque a contagem de PF se baseia no Modelo central de dados e no 6WDIILQJ (VWLPDWRU, que uma equao derivada da anlise da relao entre os pontos de funo e o nmero de dias/desenvolvedor necessrios para o desenvolvimento do projeto (TICHENOR,1997). mapeamento dos conceitos da APF para os conceitos OO (de acordo com a notao da 2EMHFW O 2EMHFW 2ULHQWHG )XQFWLRQ 3RLQW (OOFP) criado por Caldiera et al (1998), faz o

0RGHOLQJ 7HFKQLTXHV (OMT)). Estes autores definem os procedimentos de contagem de herana, agregao e polimorfismo com base no modelo de objetos produzido na fase de projeto e propem realizar a estimativa de tamanho em diferentes pontos do desenvolvimento do software medida que novos artefatos so disponibilizados. O OOFP foi aplicado em oito subsistemas, desenvolvidos no mesmo ambiente de uma empresa de software da rea de telecomunicao. Esses subsistemas foram tambm contados em LOC para que os autores pudessem aplicar as tcnicas de regresso e encontrar a associao entre OOFP e LOC. O 3UHGLFWLYH 2EMHFW 3RLQW (POPs) proposto por Minkiewicz (1997) e citado por Caldiera, et al. (1998), baseado na contagem de classes e nos pesos dos mtodos de cada classe. Os mtodos das classes so medidos com base no tipo do mtodo e na complexidade. Os ajustes so realizados pela mdia da profundidade da herana de acordo com o nmero de filhos da classe. O 2EMHFW 2ULHQWHG 'HVLJQ )XQFWLRQ 3RLQWV (OODFP) foi adaptado por Ram e Raju (2000) a partir dos procedimentos de contagem definidos pelo IFPUG. Esse mtodo estima o tamanho de software OO na fase de projetos, com base nas funes do software e na complexidade das classes. A complexidade da classe pode ser baixa, mdia ou alta de acordo com um valor numrico definido pelos autores com base em observaes de diferentes projetos. Para estes autores um arquivo lgico uma coleo de elementos de dados, os quais so visveis a todos os mtodos da classe e as funes transacionais so os mtodos das classes .

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

21 O )DVW 6HULRXV combina vrias medidas extradas dos diagramas da UML (atravs do

5DWLRQDO 5RVH 2000) e, de acordo com o nvel de detalhe do diagrama de classes, associa cada em PF (CARBONE; SANTUCCI, s.d.).

classe estimativa de tamanho em linhas de cdigo. O tamanho estimado em LOC convertido O Use Case Point (UCP), desenvolvido por Arnold e Pedross, (1998) e tambm denominado UCP como o mtodo proposto pelo Karner (1993), baseado em cenrios e casos de uso. Os autores utilizaram a APF para calibrar seu mtodo e avaliaram os fatores tcnicos significantes para a funcionalidade requerida pelo sistema. De acordo com a comparao dos resultados da contagem dos PCU (proposto pelo mtodo de Arnold e Pedross, 1998) e dos FP, eles detectaram uma variao na estimativa entre 90% a 110% e ressaltaram que esta preciso suficiente porque a avaliao da mtrica de APF pode ter uma impreciso de at 30%, quando a estimativa do tamanho realizada por diferentes lderes de projetos . Alm dos diversos estudos apresentados sobre a aplicao da APF em projetos OO, um outro estudo relevante foi realizado em 1994 pelo 4XDOLW\ $VVXUDQFH ,QVWLWXWH e IFPUG. Este estudo indica que a variao da contagem entre contadores treinados e certificados tem diminudo 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 diferena de 10% a 12% entre os contadores de uma mesma organizao e de 30% entre contadores de organizaes diferentes. A seguir sero apresentadas as principais caractersticas do PCU, a outra mtrica a ser utilizada neste trabalho.  3RQWRV GH &DVR GH 8VR 3&8 O PCU um mtodo de estimativa de tamanho de projeto de software orientado a objetos casos de uso foi posteriormente incorporado na 8QLILHG 0RGHOOLQJ /DQJXDJH (UML) e tem sido muito utilizado no mercado atualmente. O PCU tambm estima o tamanho da funo do software de acordo com a viso do usurio final e com base em uma unidade de medida o PCU. Neste mtodo, Karner (1993) explora o modelo e a descrio de casos de uso, substitui algumas caractersticas tcnicas propostas pela APF, cria os fatores ambientais e prope uma estimativa de produtividade. criado por Karner (1993), com base na APF, 0DUN ,, e no Modelo de casos de uso. O Modelo de

22

Os fatores ambientais e tcnicos de ajustes propostos por Karner (1993) foram criados e alterados de acordo com a experincia dos projetos desenvolvidos atravs do processo 2EMHFWRU\ . A descrio destes fatores encontra-se no Apndice A. Karner (1993) props a produtividade de 20 homens/hora por PCU. Com base nos recursos utilizados pelos projetos de seu estudo, tentou ainda encontrar a correlao entre PCU e os recursos necessrios para desenvolver o projeto atravs da adoo da regresso linear, mas seus dados no foram suficientes para encontrar a relao proposta. O mtodo PCU contribui para a diminuio de algumas dificuldades impostas pelo mercado em relao resistncia de adoo de mtodos de estimativas, porque um mtodo simples, fcil de usar e rpido de se aplicar, quando possui as informaes necessrias para realizar as estimativas (DAMODARAN; WASHINGTON s.d). O PCU tambm possui um processo de contagem conforme descrito a seguir.  3URFHVVR GH FRQWDJHP GH 3RQWRV GH &DVRV GH 8VR L O processo de contagem de PCU compe-se de seis etapas (Karner, 1993): &RQWDU RV DWRUHV H DWULEXLU R JUDX GH FRPSOH[LGDGH Identificar e multiplicar o

total de atores de acordo com o tipo de complexidade (simples, mdio ou complexo) pelo respectivo peso (1, 2 ou 3), conforme Quadro 6 e somar os produtos para obter o total de atores no ajustados. 4XDGUR   3HVR GRV DWRUHV (Karner, 1993)
&RPSOH[LGDGH GR DWRU 6LPSOHV 0pGLR &RPSOH[R 'HVFULomR Representa um outro sistema com Interface definida de Programas Representa um outro sistema que interage atravs de protocolos ou quando h interao humana atravs de terminal uma pessoa que interage atravs de Interface Grfica ou pgina Web 3HVR 1 2 3

23 LL &RQWDU RV FDVRV GH XVR H DWULEXLU R JUDX GH FRPSOH[LGDGH  A complexidade baseada no nmero de transaes10. De acordo com o nmero de transaes, multiplicar cada caso de uso pelo respectivo peso conforme Quadro 7. 4XDGUR   3HVR GRV FDVRV GH XVR (Karner, 1993)
&RPSOH[LGDGH &DVR GH 8VR 6LPSOHV 0pGLR &RPSOH[R 'HVFULomR Tem at 3 transaes incluindo os passos alternativos e deve ser realizado com menos de 5 classes de anlise Tem de 4 a 7 transaes incluindo os passos alternativos e deve ser realizado com 5 a 10 classes de anlise Tem acima de 7 transaes incluindo os passos alternativos e deve ser realizado com pelo menos de 10 classes de anlise 3HVR

5 10

15

LLL LY

3&8 QmR DMXVWDGRV

&DOFXODU RV 3&8V QmR DMXVWDGRV De acordo com a seguinte formula: 'HWHUPLQDU R IDWRU GH FRPSOH[LGDGH WpFQLFD 48$'52   Os fatores de de acordo com o grau de 3HVR GH $WRUHV  3HVRV GH &DVRV GH XVR

complexidade tcnica variam numa escala de 0 a 5,

dificuldade do sistema a ser construdo. O valor 0 indica pouca criticidade e baixa complexidade (irrelevante para o projeto) e o valor 5 indica alta criticidade e complexidade (essencial). Aps determinar o valor dos fatores, multiplicar pelo )DWRU GH FRPSOH[LGDGH WpFQLFD respectivo peso, somar o total e aplicar a seguinte frmula:    6RPDWyULR GR )DWRU WpFQLFR 

10

De acordo com Schneider e Winters (2001), transao definida como um conjunto de atividades atmicas, as quais so executadas completamente ou no. Quando tiver a mesma transao em todos os diagramas de seqncia como ex: ORJLQJ ou procedimentos de segurana, a transao deve ser contada apenas uma vez porque a funcionalidade implementada apenas uma vez e reutilizada em outros casos de uso (RIBU, 2001).

24 4XDGUR   )DWRUHV GH FRPSOH[LGDGH WpFQLFD (Karner, 1993)


'HVFULomR Sistemas Distribudos Desempenho da aplicao Eficincia do usurio final (on-line) Processamento interno complexo Reusabilidade do cdigo em outras aplicaes Facilidade de instalao Usabilidade (facilidade operacional) Portabilidade Facilidade de manuteno Concorrncia Caractersticas especiais de segurana Acesso direto para terceiros Facilidades especiais de treinamento 3HVR 2.0 1.0 1.0 1.0 1.0 0.5 0.5 2.0 1.0 1.0 1.0 1.0 1.0

'HWHUPLQDU D HILFLrQFLD GR IDWRU DPELHQWDO  Os fatores ambientais indicam a eficincia do projeto e esto relacionados ao nvel de experincia dos profissionais. Esses fatores (Quadro 9) so determinados atravs da escala de 0 a 5, onde 0 indica baixa habilidade (pouca experincia no domnio da aplicao), 3 indica mdia experincia e 5 indica alta experincia. Por exemplo, para o fator motivao , 0 significa sem motivao para o projeto; 3, mdia motivao e 5, alta motivao. Para o fator requisitos estveis , 0 significa extremamente instvel; 3, mdio e 5, estvel. Para o fator trabalhadores com dedicao parcial , 0 indica poucos ou nenhum profissional de perodo no integral; 3, mdio e 5 todos profissionais de perodo no integral. Para o fator dificuldade da linguagem de programao , 0 indica que a linguagem de pouca complexidade e ou que a equipe de projeto tem domnio completo sobre a mesma; 3, mdio e 5, muita dificuldade com a linguagem de programao. Aps determinar o valor de cada fator, multiplicar pelo peso e somar o total dos valores. Em seguida, aplicar a )DWRU GH FRPSOH[LGDGH DPELHQWDO seguinte frmula:     6RPDWyULR GR )DWRU

DPELHQWDO 

25

4XDGUR   )DWRUHV GH FRPSOH[LGDGH DPELHQWDO )$ (Karner, 1993)


'HVFULomR Familiaridade com o Processo de Desenvolvimento de Software Experincia na Aplicao Experincia com OO, na Linguagem e na Tcnica de Desenvolvimento Capacidade do Lder de Projeto Motivao Requisitos estveis Trabalhadores com dedicao parcial Dificuldade da Linguagem de Programao 3HVR 1.5 0.5 1.0 0.5 1.0 2.0 -1.0 -1.0

YL

&DOFXODU RV 3&8V DMXVWDGRV Esse clculo realizado com base na DPELHQWDO DWUDYpV GD VHJXLQWH IyUPXOD multiplicao dos PCU no ajustados, na complexidade tcnica e na complexidade 3&8 QmR DMXVWDGRV )DWRU GH FRPSOH[LGDGH WpFQLFD )DWRU GH

FRPSOH[LGDGH DPELHQWDO

3&8

 7UDEDOKRV UHODFLRQDGRV DR XVR GH 3&8 HP SURMHWRV GH VRIWZDUH 22 O PCU ainda pouco utilizado na indstria. Agarwal (2001) citado por Damodaran e Washington (2003) apresenta um exemplo de uso deste mtodo para estimar um projeto de Internet realizado na ,QIRV\V (ndia). Outras experincias de uso do PCU na indstria foram e IBM (PROBASCO, 2002). No Brasil, algumas empresas privadas de desenvolvimento de software tm adotado o PCU para estimativa de tamanho de projetos de software ou para estudos experimentais. Algumas dessas experincias j foram publicadas por Valena (2003), Cunha e Almeida (2003) e Feitosa e Jansen (2003). Algumas razes para o baixo uso do PCU na indstria foram indicadas por Damodaran e Washington (2003) tais como: i) o PCU um mtodo relativamente novo; ii) ainda no foi incorporado em ferramentas populares de estimativa de software; e iii) o modelo de caso de uso, apesar de ser um mtodo padro para descrio de requisitos, ainda no possui bons histricos de realizadas por Anda et al (2001), por Ribu (2001) e por algumas empresas como a 5DWLRQDO, SUN

26

produtividade. Em funo disso, e da necessidade dos gerentes dos projetos da indstria em obter estimativas de tamanho no incio do projeto para subsidiar o planejamento, outros mtodos de estimativa de tamanho tm sido utilizados e, medida que se obtm mais informaes sobre o projeto atravs das iteraes, novas estimativas so realizadas (SMITH, 1999). Apesar do PCU ainda ser pouco utilizado na indstria, diversos autores j experimentaram esta mtrica com e sem o uso dos fatores tcnicos de ajuste, computaram a estimativa de esforo, propuseram um formulrio padro para descrio 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 mtodo de Karner (1993) em trs projetos de uma companhia de desenvolvimento de software da Noruega, Sucia e Finlndia para comparar as estimativas realizadas atravs do PCU com as estimativas realizadas pelos membros sniors dos projetos. Os resultados mostraram que a estimativa realizada atravs de PCU foi prxima 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 generalizao entre os atores; ii) a contagem dos casos de uso estendidos e includos; iii) o nvel de detalhe da descrio dos casos de uso; iv) as dificuldades para atribuio de valores aos fatores tcnicos e ambientais e; v) a escolha da taxa de produtividade por PCU. Anda et al. (2001) definiram um formulrio padro para facilitar a descrio de casos de uso. Os resultados dos estudos realizados por Anda et al. (2001) suportam reivindicaes j existentes, em que o modelo de casos de uso tem um impacto forte na estimativa; pode ser utilizado com sucesso para estimar esforo em desenvolvimento de software e que o mtodo de Karner (1993) pode apoiar os especialistas no processo de estimativa baseado na APF. Apesar de Karner (1993) no recomendar a contagem dos casos de uso estendidos e includos, Anda et al. (2001) acham que os mesmos devem ser includos na contagem para evitar estimativa abaixo da realidade, principalmente se as funes descritas nesses casos de uso so essenciais e implementadas. Em um outro trabalho, Anda (2002), investigou o PCU mediante a realizao de cursos de modelagem de caso de uso para 37 profissionais experientes em desenvolvimento de software. Ele fez uma comparao entre a medio dos especialistas em desenvolvimento e em estimativa de software, com a medio realizada por tcnicos inexperientes com o domnio da aplicao e da

27

tecnologia adotada para desenvolvimento. Neste estudo, foi utilizado o formulrio padro definido no seu trabalho anterior para descrever os casos de uso. Ribu, (2001) tambm utilizou o mtodo de Karner (1993) para estimar o tamanho de projetos de estudantes e da indstria. Este autor testou o PCU com e sem o uso dos fatores tcnicos de ajuste, computou a estimativa de esforo, props um formulrio padro para descrio de casos de uso e definiu regras para atribuir valores aos fatores ambientais. Alm disso, props a analise da complexidade do caso de uso atravs do diagrama de seqncia e das classes que implementam os casos de uso quando no houver a descrio dos mesmos. Mas, esse autor ressaltou que esta alternativa pode levar a contagem de classes de projeto e comprometer o resultado da estimativa. As concluses desse estudo foram as seguintes: i) o mtodo de PCU teve baixa variao entre o valor estimado e o real; ii) sugeriu descartar os fatores de ajustes tcnicos e manter os fatores ambientais; iii) contar os casos de uso includos e estendidos; e iv) utilizar um formulrio padro para descrio de casos de uso.  2 XVR GR WDPDQKR GR SURMHWR QD HVWLPDWLYD GH HVIRUoR RX SURGXWLYLGDGH A estimativa de tamanho essencial no incio do projeto, para ajudar o gerente a planejar o desenvolvimento do produto e estimar esforo, cronograma, recursos, custo e outros fatores como a qualidade exigida pelo usurio final. (PUTNAM citado por ROSS, s.d; McGARRY et al., 2001; FENTON; PFLEEGER, 1997; McPHEE, 1999). O &DSDELOLW\ 0DWXULW\ 0RGHO (CMM), nvel 2, rea chave Planejamento de projeto de software , estabelece tambm que as estimativas de esforo, 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) props uma produtividade de 20 homens/hora por PCU. Mas este fator ainda um ponto que no existe concordncia 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 esto abaixo da escala 3 e quantos esto 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 nmeros possam ser ajustados, caso contrrio, o projeto ter grandes riscos de falhas. Em uma outra anlise, Spaks, citado por Anda et al. (2001), mostrou que o esforo pode variar entre 15 e 30 homens/hora por PCU. Em relao ao esforo ou produtividade estimada em APF, o ISBSG possui bases de dados histricas que indicam a produtividade de horas por PF de acordo com o tipo de linguagem adotada no desenvolvimento do projeto de software (ISBSG, 2002). Alm das estimativas iniciais de prazo, custos e esforo, Pressman (2002) ressalta que no decorrer do desenvolvimento do projeto, os PFs estimados, so utilizados para estimar a produtividade, a qualidade e outros atributos de software como erros por PF; defeitos por PF; custo por PF e pginas de documentao por PF e PF por homens/ms. Por outro lado, h autores que destacam que a estimativa de tamanho uma das atividades mais difceis de se realizar em uma organizao de desenvolvimento de software, principalmente quando realizada no incio do projeto (BUTLER; ROSS, 1997, citado por ROSS, s.d ).

 &RQVLGHUDo}HV ILQDLV GR FDStWXOR


Apesar do PCU ter sido definido com base na APF, estas mtricas diferem em vrios aspectos conforme mostra o Quadro10 (FENTON; PFLEEGER, 1997; GARMUS; HERRON, 2000; ANDA et al., 2001; DAMODARAN; WASHINGTON, 2002). Damodaran e Washington (2002) acreditam que no difcil para uma organizao desenvolver seus prprios padres de granularidade dos casos de uso de anlise e classific-los de acordo com a complexidade. Se a organizao tiver padres para definir casos de uso, possvel ter uma boa base de dados histrica 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 mtodo maduro e largamente aceito como um mtodo de estimativa. Embora existam crticas e diferenas em relao ao uso da APF e PCU em projetos de software OO, estas mtricas continuam sendo utilizadas para estimar software OO, mas de forma independente. A APF alm de ser padro mundial reconhecida internacionalmente. Caldiera, et al. (1998) ressaltaram que os conceitos da APF podem ser aplicados como uma mtrica que permite estimar o tamanho com mais preciso a partir da fase final de anlise e projeto de desenvolvimento de software OO, e consideraram que a integrao da APF com as

29

ferramentas de modelagem OO e a automao do processo de contagem podem ajudar a expandir o uso da APF na indstria de software. 4XDGUR   3ULQFLSDLV FDUDFWHUtVWLFDV H GLIHUHQoDV HQWUH $3) H 3&8
Mtrica mais antiga e mais utilizada no mundo Padro internacional desde 2002 No requer o uso de notao padro, mas baseada no modelo funcional e independente de tecnologia Largamente discutida na literatura suportada pelo IFPUG e diversos grupos nacionais de usurios e bases histricas de contagens realizadas Possui regras de contagem padronizadas Tem aumentado o uso e a publicao de estudos na literatura O Modelo de casos de uso ainda no possui bons histricos de produtividade No h padres para descrever casos de uso, h dvidas na contagem de casos de uso includos e estendidos e para determinar o nvel apropriado de detalhe para cada transao do caso de uso mais utilizada no final das fases de anlise e projeto Viso do usurio Alto nvel de maturidade subjetiva e possui diferena entre contadores Oferece treinamento e certificao Utilizado na fase inicial do projeto Viso do usurio Em fase de amadurecimento subjetiva e possui diferena entre contadores Ainda no oferece treinamentos e certificao Mtrica relativamente nova e pouca utilizada Ainda no alcanou o nvel de padronizao e nem foi incorporada em ferramentas populares; Baseada no modelo de casos de uso
V ! %ca  a b

O PCU baseado no Modelo de Casos de Uso, muito utilizado atualmente no mercado para identificar e documentar os requisitos do software nos termos dos usurios e de maneira mais completa e articulada que outros mtodos (DEKKERS, 1999). Alm disso, o PCU possibilita a estimativa de tamanho na fase inicial do projeto e fcil de usar. Alguns autores sugeriram o uso combinado dessas mtricas, como Arnold e Pedross (1998), Longstreet (2000), Schneider e Winters (2001), Anda et al. (2001) e Ribu, (2001). Estes autores propuseram utilizar o PCU juntamente com a APF ou realizar a contagem em grupo para evitar desvios e obter um resultado mais prximo da realidade. No entanto, a sugesto foi para trabalhos futuros, j que estes autores no realizaram esta pesquisa.

30

McGarry et al. (2001) tambm destacam que a confiana nas estimativas aumenta quando mais de uma forma de estimar utilizada e, medida que se obtm mais informaes do domnio do software durante o processo de desenvolvimento do projeto, as estimativas sero melhores. Devido a isto, estes autores recomendam realizar novas estimativas atravs de modelos paramtricos ou prever a estimativa necessria, para completar o projeto com base no cronograma e no oramento utilizado no projeto at o momento da contagem. Este trabalho se prope, portanto, usar as duas mtricas de forma combinada para permitir o planejamento e acompanhamento da estimativa de tamanho ao longo do desenvolvimento, ou seja, a gesto da estimativa de tamanho apoiando assim a gesto de projetos. Dessa forma, no prximo captulo sero apresentadas as principais caractersticas de gesto de projeto de software.

31

&DStWXOR  *HVWmR GH SURMHWR GH VRIWZDUH  ,QWURGXomR


O desenvolvimento de projeto de software tem-se tornado mais complexo e tem sido realizado em ambientes dinmicos, onde as condies de negcio, as tecnologias e as necessidades ou requisitos dos usurios mudam constantemente durante o projeto. Como resultado, a indstria de software tem enfrentado problemas de subestimativas de oramento, atrasos no cronograma, dificuldade na medio do progresso do projeto, baixa qualidade do produto, falta de credibilidade no desempenho de TI e insatisfao do usurio (ABEL-HAMID; MADNICK (1991), citados por JURISON, 1999). *URXS &KDRV $ UHFLSH IRU VXFFHVV citado por Murthi (2002), o qual indica que somente 28% de todos os projetos de software de 2000 estavam dentro do cronograma e oramento estimados e apresentaram todas as caractersticas planejadas. Diante desse contexto, torna-se necessrio melhorar a gesto de projetos e providenciar aes gerenciais que possam contribuir para uma gesto mais efetiva e, conseqentemente melhorar os ndices acima. Neste captulo, sero apresentados os principais conceitos e as caractersticas relevantes da gesto de projetos de software, destacando, principalmente, os processos de planejamento e controle de projeto. Alguns destes problemas podem ser confirmados com base no relatrio do 6WDQGLVK

 'HILQLomR
Projetos so empreendimentos temporrios, com comeo e fim bem definidos, e tm como objetivo criar um produto ou servio nico distinto dos existentes. So planejados, executados e controlados por pessoas e restringidos por recursos limitados, podendo envolver uma unidade isolada da organizao ou vrias organizaes atravs de consrcios e parcerias (PMBOK, 2000; JOHNSON; BRODMAN, 2000). O objetivo da gesto de projetos o atendimento das demandas de clientes internos e externos, garantindo a satisfao de suas necessidades, mantendo um bom relacionamento e

32

controlando os recursos, esforos e desempenho do projeto (JURISON, 1999; REEL, 1999; PMBOK, 2000). De acordo com Pressman (2002), a gesto de projetos envolve planejamento, acompanhamento e controle de processos, planos de projetos, pessoas e produtos, requerendo, segundo o PMBOK (2000), a aplicao de conhecimentos, habilidades, ferramentas e tcnicas para planejar e controlar atividades que visam atender as necessidades dos interessados. O aumento da complexidade do software tem dificultado o processo de gesto de projetos e contribudo para a alta taxa de falhas em projetos de desenvolvimento de software (JURISON, 1999; REEL, 1999). Na tentativa de diminuir as falhas de projetos de software, Reel (1999) destaca alguns fatores fundamentais para o sucesso da gesto de projetos: i) comear o projeto adequadamente; ii) manter uma equipe motivada e um ambiente de desenvolvimento pro-ativo; iii) rastrear o progresso do projeto; iv) tomar decises inteligentes; e v) institucionalizar a reviso de projetos para identificar os pontos fortes e fracos aps a realizao do mesmo. A seguir sero apresentados os principais processos de gesto de projetos.

 3URFHVVRV GH JHVWmR GH SURMHWRV


O PMBOK (2000) recomenda o uso dos seguintes processos para garantir a gesto eficaz de projetos: i) ii) iii) iv) v) LQLFLDomR - obteno do comportamento da organizao para o incio do projeto;

SODQHMDPHQWR definio, refinamento dos objetivos e seleo das alternativas de ao para alcanar as metas do projeto; H[HFXomR - coordenao de pessoas e recursos para realizar o plano do projeto;

FRQWUROH - assegura que os objetivos do projeto esto sendo atendidos por meio de monitorao; HQFHUUDPHQWR - formalizao da aceitao do projeto ou do encerramento de forma organizada.

Os processos acima so denominados de atividades pela NBR ISO/IEC 12.207 (ABNT, 1998) e de fases do processo de desenvolvimento por Jurison (1999). Estes processos so interligados pelos produtos gerados em cada um deles. Cada processo ou fase do projeto,

33

marcado pela concluso de um ou mais produtos, pela reviso dos principais subprodutos e pela avaliao de desempenho visando continuao adequada do projeto. Os processos de planejamento e de controle de projeto devem ser vistos como essenciais na gesto de projetos de software e, por esta razo, as principais caractersticas desses processos sero apresentadas a seguir.  3ODQHMDPHQWR GH SURMHWR GH VRIWZDUH O objetivo do planejamento de projeto de software estabelecer planos razoveis 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 necessrios; a definio do plano; a especificao de metas e objetivos, a elaborao de estratgias, polticas, procedimentos e regras a serem adotadas pelo projeto. O planejamento, geralmente, realizado com base nas informaes dos clientes, da equipe tcnica, nas mtricas 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 idia da elaborao do plano do projeto de maneira aberta e colaborativa por ser mais precisa e permitir a anlise dos nveis de complexidade e dos riscos do projeto, principalmente os riscos relacionados aos requisitos, tecnologia, aos recursos, s habilidades tcnicas, integrao, ao cronograma, manuteno e melhoria do projeto. (PRESSMAN, 2002; MURTHI, 2002; PITTMAN, 1993). Para fazer um bom planejamento, o PMBOK (2000) recomenda a execuo de alguns processos essenciais e facilitadores. Os processos essenciais so: i) ii) iii) iv) v) vi) vii) planejamento e detalhamento do escopo; seqenciamento das atividades; estimativa de durao das atividades; desenvolvimento do cronograma; planejamento dos recursos; estimativa dos custos; desenvolvimento do plano do projeto.

Os processos facilitadores so:

34

i) ii) iii) iv) v) vi)

planejamento da qualidade; planejamento organizacional; montagem da equipe; planejamento das comunicaes; identificao, quantificao e desenvolvimento de respostas aos riscos; planejamento e preparao das aquisies.

Pressman, (2002) e Jurison (1999) reforam a utilizao desses processos ao destacarem as caractersticas mais importantes do planejamento: i) definio dos objetivos e requisitos; ii) realizao das estimativas de tamanho; iii) definio do cronograma, custo e oramento; iv) o impacto do negcio, o perfil do cliente, a definio do processo de desenvolvimento e do ambiente tecnolgico; v) a experincia da equipe; e vi) a identificao dos riscos. Estes autores ressaltam ainda que, se estas caractersticas no forem executadas adequadamente podem ameaar o plano do projeto O CMM nvel 2 tambm prope atividades para a realizao do planejamento do projeto tais como (PAULK et al, 2000): i) ii) iii) iv) v) vi) vii) viii) ix) x) elaborar a proposta do projeto com a participao do grupo de engenheiros de software; comear o planejamento do projeto no estgio inicial do projeto; revisar os planos do projeto com a participao do grupo de engenheiros de software e outros grupos envolvidos durante todo o planejamento; rever os compromissos do projeto realizados por grupos externos de acordo com os procedimentos documentados; identificar ou definir o processo de desenvolvimento do software a ser utilizado no projeto; desenvolver o plano do projeto de software de acordo com os procedimentos documentados; documentar o plano do projeto; identificar os produtos de trabalho do software necessrios para manter o controle do projeto; realizar ou atualizar as estimativas de tamanho do software; estimar o esforo e os custos do projeto de software;

35

xi) xii) xiii) xiv) xv)

estimar os recursos computacionais crticos; derivar o cronograma do projeto; identificar os riscos associados ao custo, aos recursos, ao cronograma e aos aspectos tcnicos do projeto; preparar ferramentas de suporte e outras facilidades para a construo do software; registrar os dados do planejamento do software.

Algumas destas atividades so semelhantes aos processos de planejamento propostos pelo PMBOK (2000) como a realizao de estimativas de tamanho, custos e recursos. O principal produto do processo de planejamento o plano do projeto. Esse plano deve ser formal e composto de outros planos tais como: o plano de iteraes; plano de testes; plano de gesto de configurao; plano de riscos; plano de documentao, cronograma e o processo de desenvolvimento especfico a ser usado no desenvolvimento do software. O plano de desenvolvimento deve ser refinado, corrigido e melhorado durante todo o processo de desenvolvimento para manter o projeto alinhado a esse processo. Com base no plano do projeto, o gerente inicia a execuo e o controle do projeto at a gerao do produto final e o encerramento do mesmo (JURISON, 1999).  &RQWUROH GH SURMHWR GH VRIWZDUH O objetivo do controle e rastreamento do projeto prover visibilidade adequada do progresso atual do projeto, para que os gerentes possam providenciar aes corretivas quando o desempenho do mesmo se desvia significativamente do plano elaborado (PAULK, et al., 2000). Segundo o CMM nvel 2, a gesto e o controle do projeto implicam em conhecer a verso do produto do trabalho em uso num determinado tempo (passado ou presente) e controlar as mudanas realizadas (PAULK, et al., 2000). O controle do plano do projeto gera informaes e mecanismos necessrios para os gerentes e a equipe do projeto para avaliao e monitoramento do progresso do desenvolvimento do projeto (MURTHI, 2002; ABDEL-HAMID; MADNICK, 1993, citados por JURISON, 1999). As informaes de interesse dos gerentes geralmente esto relacionadas a custo, a produtividade da equipe, a qualidade do cdigo e do processo e a satisfao do cliente em relao ao produto. J a equipe de desenvolvimento est preocupada com informaes relacionadas aos requisitos, s

36

falhas encontradas, ao atendimento dos objetivos do produto e do processo e aos fatos que podero ocorrer no futuro (McGARRY et al., 2001). McGarry et al.(2001) ressalta ainda, que as decises do gerente do projeto durante a fase de controle se baseiam em trs tipos de anlise, que provem informao de suporte a deciso: estimativas de tamanho, custos e prazos; anlise de viabilidade; e anlise de desempenho. Estas atividades so usualmente executadas iterativamente durante todo o processo de desenvolvimento do projeto. As estimativas, que so afetadas por variveis humanas, tcnicas, ambientais e polticas, devem ser ajustadas com base em informaes e artefatos gerados ao longo do desenvolvimento do projeto e de acordo com a capacidade, experincia e nvel de habilidades da equipe (McGARRY et al., 2001; JURISON, 1999). A anlise de viabilidade determina se o plano do projeto possvel de se realizar atravs da anlise de dados histricos, experincia da equipe e consistncia do plano. A omisso 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 consistncia entre a estimativa de tamanho com o esforo planejado e as atividades definidas no cronograma. As seguintes questes devem ser consideradas ao se fazer a anlise de viabilidade dos planos: i) se as atividades importantes, os feriados e frias dos membros da equipe foram considerados nos planos; ii) se as atividades sobrepostas so possveis de serem executadas; e iii) se os objetivos de complexidade e densidade de defeitos esto dentro do contexto do projeto (McGARRY et al. 2001). Caso as atividades planejadas no cronograma sejam difceis de cumprir devido s datas impostas pelo cliente ou falhas no planejamento, o gerente deve tomar algumas decises tais como (PRESSMAN, 2002; PMBOK, 2000; JURISON, 1999; McGARRY et al., 2001): i) ii) iii) iv) reunir-se com o cliente, apresentar a estimativa detalhada em relao ao esforo e durao estimada para o projeto e tentar negociar novos prazos; definir uma estratgia de desenvolvimento incremental que entregue a funcionalidade crtica na data prevista e adie as funes restantes; negociar o aumento do oramento e contratar tcnicos mais experientes; utilizar componentes adquiridos ou reusar componentes j existentes.

37

A anlise de desempenho do projeto deve ser realizada regularmente para identificar as variaes do plano e implementar aes corretivas antecipando os futuros problemas (McGARRY et al., 2001). A identificao do aumento do tamanho no planejado pode ser usada para subsidiar tomada de deciso, fazer ajustes nos recursos e melhorar o desempenho do projeto. Outras aes de ajustes como estender o cronograma para manter a qualidade do projeto, adicionar mais pessoas na equipe do projeto para manter o cronograma, excluir funes para controlar custos, mudar o processo de desenvolvimento e re-alocar recursos e oramento para suportar as atividades chave, podem envolver os gerentes superiores e clientes interessados. O cronograma aprovado no processo de planejamento deve ser controlado durante todo o processo de desenvolvimento para evitar atrasos na execuo das atividades planejadas. No entanto, em caso de atraso, Pressman, (2002); PMBOK, (2000); Jurison, (1999) recomendam as seguintes aes: i) ii) iii) iv) v) vi) vii) viii) ix) reviso do planejamento do projeto e identificao dos desvios no cronograma; incluso de tcnicos ou redistribuio da equipe do projeto; reviso e priorizao das funes do software, deixando as menos importantes para futuras verses; reviso do cronograma buscando alcanar o prximo marco do projeto na data prevista; controle da comunicao entre os membros do projeto; realizao de ajustes no plano e documentao das aes corretivas para contemplar as alteraes de tempo e custo; modificao da seqncia das atividades e analise das alternativas de respostas aos riscos; verificao se as atualizaes do cronograma requerem ajustes em outros aspectos do plano geral do projeto; registro dos desvios do cronograma. Caso no haja possibilidade de recuperao do atraso, o gerente deve rever o cronograma como um todo e renegociar com as partes envolvidas. Se o cronograma tiver dentro do prazo, o gerente tem que continuar controlando o projeto para evitar possveis desvios ou atraso na entrega do produto final. Neste caso, o gerente deve realizar as seguintes aes (PRESSMAN, 2002; PMBOK, 2000; JURISON, 1999):

38

i) ii) iii)

continuar as anlises de desempenho dos relatrios do projeto para identificao de riscos e antecipao de problemas futuros; controlar a produtividade da equipe e da rotatividade de pessoal; identificar possveis mudanas de legislao, substituio de tecnologia e erro ou omisso no detalhamento do escopo.

Para facilitar o controle e a anlise de desempenho do projeto durante o seu desenvolvimento, o PMBOK (2000) prope o uso dos seguintes processos: i) ii) iii) iv) v) vi) vii) controle geral de mudanas; controle de mudanas de escopo; controle de cronograma; controle de custos; controle de qualidade; relato de desempenho; controle de respostas aos riscos.

Estes processos gerenciam as principais dimenses do projeto citadas por Murthi (2002) como escopo (requisitos); recursos (pessoas, equipamentos e dinheiro); tempo e riscos, atravs das diversas reas de conhecimento propostas tambm pelo PMBOK (2000): i) *HUrQFLD GD ,QWHJUDomR - descreve os processos necessrios para assegurar que

os diversos elementos do projeto sejam adequadamente coordenados. Essa gerncia compe-se do desenvolvimento e execuo do plano do projeto e controle geral de mudanas. ii) *HUrQFLD GR (VFRSR  descreve os processos necessrios para assegurar que o projeto contempla todo, e nada mais que, o trabalho requerido, para completar o projeto com sucesso. Essa gerncia composta pela iniciao do projeto e pelo iii) *HUrQFLD GR 7HPSR - descreve os processos necessrios para assegurar que o projeto termine dentro do prazo previsto. composta pela definio, seqenciamento e estimativa da durao das atividades, desenvolvimento e controle do cronograma. planejamento, detalhamento, verificao e controle de mudanas do escopo.

39 *HUrQFLD GR &XVWR  descreve os processos necessrios para assegurar que o projeto seja completado dentro do oramento previsto. composta pelo v) *HUrQFLD GD 4XDOLGDGH - descreve os processos necessrios para assegurar que as necessidades que originaram o desenvolvimento do projeto sero satisfeitas. vi) *HUrQFLD GRV 5HFXUVRV +XPDQRV GR 3URMHWR - descreve os processos necessrios para proporcionar a melhor utilizao das pessoas envolvidas no projeto. composta pelo planejamento organizacional, montagem e desenvolvimento da vii) *HUrQFLD GDV &RPXQLFDo}HV GR 3URMHWR - descreve os processos necessrios para assegurar que a gerao, captura, distribuio, armazenamento e apresentao das informaes do projeto sejam feitas de forma adequada e no tempo certo. composta pelo planejamento, distribuio, relato de desempenho e encerramento viii) *HUrQFLD GRV 5LVFRV GR 3URMHWR - descreve os processos que dizem respeito identificao, anlise e resposta a riscos do projeto. Ela composta pela identificao, quantificao, qualificao, desenvolvimento e controle das ix) *HUrQFLD GDV $TXLVLo}HV GR 3URMHWR - descreve os processos necessrios para a aquisio de recursos e servios fora da organizao que desenvolve o projeto. Esta gerncia composta pelo planejamento e pela preparao das aquisies, obteno de propostas, seleo de fornecedores, administrao e encerramento de contratos. Todas as reas de conhecimento citadas acima devem ser seguidas para garantir uma gesto adequada de projetos. No entanto, as gerncias de tempo e custo dependem de estimativas iniciais para assegurar que o projeto termine dentro do prazo e do oramento previstos. As estimativas de tempo definidas no incio do projeto so determinantes para planejar os recursos, prever o custo e elaborar o oramento do projeto. Sendo assim, no contexto deste trabalho, a gerncia de tempo tem fundamental importncia, porque o prazo ou tempo de desenvolvimento do projeto definido atravs do respostas aos riscos. administrativo. equipe. composta pelo planejamento, garantia e controle da qualidade. planejamento dos recursos e pela estimativa, pelo oramento e controle dos custos.

iv)

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, esforo e custos dos recursos necessrios implementao das atividades definidas no cronograma do projeto tambm devem ser revistas. O controle do cronograma e da durao das atividades propostas pela rea de conhecimento gerncia de tempo (PMBOK, 2000) e pela NBR ISO/IEC 10.006 (ABNT, 2000), deve ser realizado durante as atividades de planejamento; execuo e controle e reviso e avaliao do projeto conforme proposto pela NBR ISO/IEC 12.207 (ABNT, 1998) e apresentado na ISO/IEC DTR 16326 (ISO, 1999). Alm dos processos de controle e das reas de conhecimento indicadas pelo PMBOK (2000), o CMM tambm cita algumas atividades que devem ser executadas pelo gerente para rastrear e controlar o projeto (PAULK, 2000): i) ii) iii) iv) v) vi) vii) viii) ix) x) rastrear as atividades do projeto de software e o status da comunicao com base no plano de desenvolvimento do projeto; revisar o plano de desenvolvimento do projeto de acordo com os procedimentos documentados; revisar os compromissos e mudanas realizadas por grupos externos de acordo com os procedimentos documentados; comunicar as mudanas aprovadas nos compromissos que afetam o projeto aos membros da equipe e outros grupos relacionados; rastrear as estimativas de tamanho, esforo, custo e de recursos computacionais crticos do projeto e tomar aes corretivas caso necessrio; rastrear o cronograma do projeto e tomar aes corretivas caso necessrio; rastrear as atividades tcnicas de construo do software e tomar aes corretivas caso necessrio; rastrear os riscos do software associados ao custo, recursos, cronograma e aspectos tcnicos e tomar aes corretivas caso necessrio; documentar os dados atuais de estimativas e re-planejamento do projeto; realizar entrevistas de revises peridicas com a equipe do projeto para rastrear o plano, o progresso tcnico e o desempenho do projeto;

41

xi)

realizar revises formais para verificar se os compromissos e resultados do projeto esto sendo conduzidos conforme os procedimentos documentados.

O desempenho do projeto pode ser afetado como j destacados anteriormente por riscos, eventos e novas situaes que surgem durante a execuo do mesmo (MURTHI, 2002). Segundo o PMBOK (2000) e Pressman (2002), os principais riscos esto relacionados aos problemas tcnicos e de negcio que, geralmente, ameaam a qualidade e a pontualidade do software. Os riscos tcnicos, citados pelo PMBOK (2000) e Jurison, (1999) so: falhas de projeto, omisses e interpretaes errneas de requisitos; problemas de implementao; de interface; de verificao; de manuteno; de ambigidade nas especificaes e incerteza tcnica; obsolescncia tcnica; entrega atrasada de componente chave e uso de tecnologia de ponta . Os riscos de negcio podem estar relacionados construo de um produto inadequado por exemplo: produto excelente mas sem demanda (risco de mercado); produto que no se encaixa na estratgia de negcio da empresa (risco estratgico) e que a equipe de vendas no sabe como vender e mudanas no mercado ou nas aes governamentais. Outros riscos de negcio podem ser gerenciais como a perda de apoio da gerncia superior devido mudana de enfoque, de pessoal (pessoas com habilidades nicas, difceis de serem substitudas) ou de oramento. Para atenuar os riscos, torna-se necessrio elaborao de um plano de contingncia com a respectiva documentao dos procedimentos (PRESSMAN, 2002; PMBOK, 2000 JURISON, 1999 e MURTHI, 2002). Ainda em relao a riscos de projetos, foi realizado um estudo por Farias (2002) para identificar os fatos causadores de riscos encontrados em projetos de software. Os fatos que causam atrasos no cronograma identificados nesse estudo foram: i) equipe de desenvolvimento indisponvel; ii) projeto com alto grau de inovao; iii) prazos e custos estabelecidos arbitrariamente; iv) mtodo de estimativa de tamanho inadequado; v) gerncia inexperiente; vi) equipe de desenvolvimento inexperiente em engenharia de software, nos mtodos e ferramentas utilizadas e no domnio da aplicao; vii) processo de desenvolvimento inadequado; viii) levantamento ou acompanhamento de requisitos com pessoas inexperientes; ix) alto grau de competio na empresa do cliente; x) falta de comprometimento do usurio/cliente; xi) oramento insuficiente; xii) requisitos complexos; xiii) hardware e/ou software necessrios no disponveis no momento definido; xiv) dependncia de produtos ou servios externos que afetam o produto, o oramento, o cronograma ou a continuidade do projeto; xv) mudanas de requisitos

42

que no foram refletidas em mudanas de cronograma; xvi) falta de identificao dos riscos previsveis e imprevisveis no incio do projeto; xvii) falta de identificao das dificuldades tcnicas e humanas no incio do projeto e xviii) falta de comunicao entre os membros da equipe de projetos. Um outro ponto relevante em relao gesto 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 seo, necessrio que o gerente de projeto tenha habilidades e conhecimentos especficos como liderana, influncia na organizao, capacidade de negociao, de solucionar problemas e de comunicao (PMBOK, 2000; THOMSETT, 2002 e A ROLE-BASED..., 2003).  *HVWmR GH SURMHWRV GH VRIWZDUH GH DFRUGR FRP DV QRUPDV  H  A NBR ISO/IEC 10006 (ABNT, 2000) fornece diretrizes para a obteno da qualidade na gesto de projetos. Essas diretrizes utilizam processos de gesto de projetos que so semelhantes s reas de conhecimento proposta pelo PMBOK (2000). Esses processos so agrupados em: i) ii) processos do projeto; HVWUDWpJLFR um processo que organiza e gerencia a realizao dos outros

JHVWmR GH LQWHUGHSHQGrQFLDV HQWUH RV SURFHVVRV envolve o gerenciamento

global da interdependncia entre os processos do projeto. Os processos de gerenciamento so os de iniciao do projeto e desenvolvimento do plano do projeto, gerenciamento das interaes, gerenciamento de alteraes e configurao e encerramento; iii) HVFRSR inclui uma descrio do produto do projeto, suas caractersticas e como

elas sero medidas ou avaliadas. Os processos relacionados ao escopo so os de desenvolvimento conceitual, desenvolvimento e controle do escopo e definio e controle de atividades; iv) WHPSR visa determinar as dependncias e a durao das atividades, garantindo a

concluso do projeto no prazo previsto. Consistem dos processos de planejamento de dependncia das atividades, estimativa de durao e desenvolvimento e controle do cronograma.

43 FXVWR visa prover e gerenciar os custos do projeto garantindo sua concluso dentro do oramento. Os processos relacionados ao custo so estimativa, oramento e controle de custos; vi) vii) UHFXUVRV - consistem dos processos de planejamento e controle de recursos

v)

SHVVRDO visa criar um ambiente no qual o pessoal possa contribuir efetiva e eficientemente para o projeto. Consistem dos processos de definio da estrutura organizacional do projeto, alocao e desenvolvimento da equipe;

viii)

FRPXQLFDomR visa facilitar o intercmbio de informaes necessrias ao projeto.

Possui os processos de planejamento da comunicao, gerenciamento da informao e controle da comunicao; ix) ULVFR lida com incertezas do projeto e requer uma abordagem estruturada para

minimizar o impacto de eventos negativos e obter vantagem das oportunidades para melhoria. Os processos relacionados aos riscos so os de identificao e avaliao de riscos, desenvolvimento de reao aos riscos e controle de riscos; x) sXSULPHQWRV tratam do suprimento, aquisio ou fornecimento de produtos necessrios aos projetos. So os seguintes: planejamento e controle de suprimentos, documentao dos requisitos tcnicos, avaliao de fornecedores, sub contratao e controle de contrato. Essa norma destaca dois aspectos importantes para alcanar a qualidade na gesto de projetos: a qualidade do processo de desenvolvimento do projeto e a qualidade do produto. O alcance da qualidade do processo e do produto em um projeto requer um enfoque sistemtico para assegurar que as necessidades implcitas e explcitas do cliente sejam entendidas e satisfeitas, que as necessidades de outras partes interessadas sejam avaliadas e que a poltica de qualidade da organizao seja considerada (ABNT, 2000). Por outro lado, a NBR ISO/IEC 12.207 (ABNT, 1998) estabelece uma estrutura comum para os processos de desenvolvimento de software desde a sua concepo at a descontinuidade do software. Essa estrutura contm processos, atividades e tarefas que podem ser aplicadas durante a aquisio e o fornecimento, o desenvolvimento, a operao e a manuteno de software. A Figura 1 mostra os cinco processos fundamentais, os oito processos de apoio e quatro processos organizacionais.

44

No escopo deste trabalho, so considerados os processos de desenvolvimento e de gerncia. O processo de desenvolvimento contm as principais atividades e tarefas do desenvolvedor tais como: implementao do processo, anlise de requisitos; projeto da arquitetura do sistema, projeto do software, codificao e testes, integrao, teste de qualificao do software, instalao, apoio e aceitao do software. O Apndice C mostra os principais artefatos gerados em cada atividade ou disciplina de um processo de desenvolvimento OO.

Aquisio Fornecimento

Operao

'HVHQYROYLPHQWR
Manuteno

*HUrQFLD

Infra-estrutura

Melhoria

)LJXUD   (VWUXWXUD GD 1%5 ,62,(&  (ABNT, 1998) As atividades do processo de gesto de projetos proposta pela norma 12.207 (ABNT, 1998) esto inseridas dentro do processo de gerncia e so as seguintes: i) ii) iii) viabilidade do processo; LQLFLDomR H GHILQLomR GH HVFRSR consiste do estabelecimento dos requisitos, e da SODQHMDPHQWR consiste dos planos para a execuo do processo;

H[HFXomR H FRQWUROH consistem da implementao do plano. O gerente deve monitorar a execuo do processo, investigar, analisar e resolver os problemas e

reportar aos interessados o progresso do processo atravs de relatrios;

f x f d '&cuyt@@%"ge d h i f i i h f

''"#Fi@@%"e d i x u s f x g u x s u e f f i i h g f

i'uSqrEi@@%"e d x w s h v u t s p f i i h g f

Documentao Gerncia de Configurao Garantia da Qualidade Verificao Validao Reviso Conjunta Auditoria

Resoluo de Problemas

Treinamento

45 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 considerao os critrios especificados no contrato e nos procedimentos da organizao. Os resultados e registros devem ser arquivados.  0DSHDPHQWR GR 30%2. H 1%5 ,62,(&  SDUD D 1%5 ,62,(&  Os processos de gesto de projetos propostos pelo PMBOK (2000) so implementados atravs das reas de conhecimento de gesto que, por sua vez, constituem-se de outros processos conforme citado anteriormente e apresentado no Quadro 11, colunas 1 e 2. As prximas cinco colunas deste Quadro 11 mostram as atividades do processo de gesto 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 gesto de tempo , os processos de definio, seqenciamento das atividades e o de desenvolvimento do cronograma so desenvolvidos durante a atividade de planejamento e os processos de estimativa de durao das atividades e controle do cronograma, diretamente relacionados com o escopo deste trabalho, so realizados durante as atividades de planejamento, execuo e controle e reviso e avaliao da NBR ISO/IEC 12.207 (ABNT, 1998). O mapeamento da NBR ISO/IEC 10.006 para a NBR ISO/IEC 12.207 apresentado atravs do Quadro 12, no qual, a primeira e segunda colunas mostram os grupos de processos de gesto de projetos e seus respectivos processos propostos pela NBR ISO/IEC 10.006 e nas prximas 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 durao das atividades e o desenvolvimento do cronograma, em destaque na tabela so realizados durante as atividades de planejamento, enquanto que, o controle do cronograma feito durante a execuo e o controle e a reviso e avaliao, conforme mostra o Quadro 12. O Quadro 13 mostra, na primeira coluna, os processos de gesto de projetos mapeados para os processos da NBR ISO/IEC 10.006 (ABNT, 2000) (coluna dois) e para as reas de conhecimento da gesto de projetos do PMBOK (coluna trs). Nesse quadro, o processo relacionado ao tempo da NBR ISO/IEC 10.006 (ABNT, 2000), e a rea de gesto de tempo,

iv)

46

(PMBOK, 2000) so realizados durante os seguintes processos de gesto da NBR ISO/IEC 12.207(ABNT, 1998): planejamento; execuo e controle; e reviso e avaliao conforme j apresentados nos quadros anteriores. 4XDGUR   UHDV GH FRQKHFLPHQWR GD JHVWmR GH SURMHWRV GR 30%2. ; DWLYLGDGHV GR SURFHVVR GH JHVWmR GD 1%5 ,62,(&  (ISO, 1999)

UHDV GH FRQKHFLPHQWR GD JHVWmR GH SURMHWR

30%2. $WLYLGDGHV GR SURFHVVR GH JHVWmR GD ,62,(&  3URFHVVRV GDV iUHDV GH ,QLFLDomR H 3ODQHMDPHQ ([HFXomR 5HYLVmR H (QFHUUD FRQKHFLPHQWR GD JHVWmR GH SURMHWR GHILQLomR WR H FRQWUROH DYDOLDomR PHQWR GR HVFRSR X X X X X X ; X X X X X X

Gesto da integrao Desenvolvimento do plano Execuo do plano Controle de mudanas geral Gesto do escopo Iniciao Planejamento do escopo Definio do escopo Verificao do escopo Controle de mudana do escopo 'HILQLomR GH DWLYLGDGHV 6HTHQFLDPHQWR GH DWLYLGDGHV *HVWmR GR WHPSR (VWLPDWLYD GH GXUDomR DWLYLGDGHV 'HVHQYROYLPHQWR GR FURQRJUDPD &RQWUROH GR FURQRJUDPD Gesto de custos Planejamento de recursos Estimativa de custos Oramento do custo Controle de custos Gesto de qualidade Planejamento da qualidade Garantia da qualidade Controle da qualidade Gesto de recursos Planejamento organizacional humanos Aquisio de pessoas Desenvolvimento da equipe Gesto de Planejamento da comunicao comunicao Distribuio da informao Relatrio de desempenho Encerramento administrativo Gesto de riscos Identificao dos riscos Quantificao dos riscos Desenvolvimento de respostas riscos Controle de respostas aos riscos Gesto de Planejamento da aquisio suprimentos Solicitao da aquisio Solicitao Seleo da fonte Administrao de contratos Encerramento de contrato

X X X ; ; ; ; X X X X X X

X ; ; X X X X X X X X X X X X X X X X

X X ; ;

X X X X X X X

X X X X

X X X X X X X

X X X X

X X

X X

47 4XDGUR  0DSHDPHQWR GRV SURFHVVRV GH JHVWmR GH SURMHWRV GD ,62  SDUD DV DWLYLGDGHV GH JHVWmR GH SURFHVVRV GD 1%5 ,62,(& (ISO, 1999)
,62  3URFHVVRV GH JHVWmR GH SURMHWRV $WLYLGDGHV GR SURFHVVR GH JHVWmR GD ,62,(&  ,QLFLDomR H 3ODQHMD ([HFXomR H 5HYLVmR H (QFHUUD GHILQLomR GR PHQWR FRQWUROH DYDOLDomR PHQWR HVFRSR X X X X X X X X X X X X X X X ; ; X X

*UXSRV GH SURFHVVRV GH JHVWmR GH SURMHWRV Processos interdependentes

Processos relacionados ao escopo 3URFHVVRV UHODFLRQDGRV DR WHPSR Processos relacionados ao custo Processos relacionados a recursos Processos relacionados a pessoal

Iniciao do projeto e plano de desenvolvimento Gesto da interao Gesto de mudanas Encerramento Desenvolvimento conceitual Controle e desenvolvimento do escopo Definio de atividades Controle de atividades 3ODQHMDPHQWR GH GHSHQGrQFLD (VWLPDWLYD GXUDomR DWLYLGDGHV 'HVHQYROYLPHQWR GH FURQRJUDPD &RQWUROH GH FURQRJUDPD Estimativa de custos Oramento Controle de custos Planejamento de recursos Controle de recursos Definio da estrutura organizacional do projeto Alocao de pessoal Desenvolvimento da equipe Planejamento da comunicao Gesto da Informao Controle da comunicao Identificao dos riscos Avaliao dos riscos Desenvolvimento respostas aos riscos Controle dos riscos Controle e planejamento da aquisio Documentao de requisitos Avaliao de subcontratos Subcontratao Controle de contrato

X X ; ; ; ; X X X X X X X O X X X X X O X

; X X

Processos relacionados a comunicao Processos relacionados Aos riscos Processos relacionados a suprimentos

O O

X O

O X X X X

O O O

O X X

Legenda: X = mapeamento objetivo e O = mapeamento subjetivo (pode haver alguma discordncia)

48 4XDGUR   0DSHDPHQWR GD 1%5 ,62,(&  SDUD D ,62  H 30%2. (ISO, 1999)
,62,(&  $WLYLGDGHV GR SURFHVVR ,62  1tYHLV GRV SURFHVVRV 30%2. UHDV GH FRQKHFLPHQWR GD JHVWmR GH SURMHWRV Gesto de integrao Gesto de escopo *HVWmR GH WHPSR Gesto de custos Gesto de qualidade Gesto de recursos humanos Gesto de comunicao Gesto de riscos Gesto de aquisio Gesto de integrao Gesto de escopo *HVWmR GH WHPSR Gesto de custos Gesto de qualidade Gesto de recursos humanos Gesto de integrao Gesto de escopo *HVWmR GH WHPSR Gesto de custos Gesto de qualidade Gesto de recursos humanos Gesto de comunicao Gesto de riscos Gesto de aquisio Reviso e avaliao Processos de gesto de interdependncia Processos relacionados a escopo 3URFHVVRV UHODFLRQDGRV D WHPSR Processos relacionados a custos Processos relacionados a recursos Processos relacionados comunicao Processos relacionados a riscos Processos relacionados a suprimentos Processos de gesto de interdependncia Gesto de integrao Gesto de escopo *HVWmR GH WHPSR Gesto de custos Gesto de qualidade Gesto de comunicao Gesto de riscos Gesto de aquisio Gesto de escopo Gesto de comunicao Gesto de aquisio

3URFHVVR GH *HVWmR

Iniciao e definio do escopo

Iniciao e definio do escopo

Processos de gesto de interdependncia Processos relacionados ao escopo Processos relacionados a pessoal Processos relacionados comunicao Processos relacionados aos riscos Processos relacionados a suprimentos

Planejamento

Processos de gesto de interdependncia Processos relacionados ao escopo 3URFHVVRV UHODFLRQDGRV DR WHPSR Processos relacionados ao custo Processos relacionados aos recursos Processos relacionados a pessoal Processos de gesto de interdependncia Processos relacionados a escopo 3URFHVVRV UHODFLRQDGRV D WHPSR Processos relacionados a custos Processos relacionados a recursos Processos relacionados a comunicao Processos relacionados a riscos Processos relacionados a suprimento

Execuo e controle

Encerramento

49

 &RQVLGHUDo}HV ILQDLV GR FDStWXOR


Este captulo apresentou os principais conceitos e as caractersticas da gesto de projetos de software, ressaltando os aspectos importantes do planejamento e do controle de projetos de software de acordo com o PMBOK, CMM - nvel 2, as NBR ISO/IEC 10.006 (ABNT, 2000) e NBR ISO/IEC 12.207 (ABNT, 1998); as principais aes 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 prximo captulo, ser apresentada uma proposta de gesto de estimativa de tamanho de projetos de software orientado a objetos com base nas mtricas, modelos, normas e trabalhos relevantes referenciados neste captulo e nos anteriores.

50

&DStWXOR  *HVWmR GH HVWLPDWLYD GH WDPDQKR GH SURMHWR GH VRIWZDUH RULHQWDGR D REMHWRV  ,QWURGXomR
Para subsidiar o planejamento e a negociao de prazos, esforo, recursos e custos com o cliente, as empresas de software normalmente requerem estimativas de tamanho do software a ser desenvolvido na fase inicial do projeto. Em geral, no entanto, a preciso de estimativas realizadas no incio do projeto no grande, necessitando ser refinada com base em informaes disponibilizadas durante a implementao do projeto. Assim, existe uma demanda por mtricas que proporcionem maior preciso nas estimativas iniciais de tamanho de software a ser desenvolvido. Conforme citado no Captulo 2, a estimativa de tamanho importante, porque subsidia o gerente no planejamento e na previso de custos, prazos e esforos associados ao desenvolvimento do projeto, permite estimativas de casos de testes, facilita as negociaes contratuais, alm de ser um mecanismo de controle da qualidade e da produtividade da equipe. O tamanho tem impacto na soluo tcnica e na gesto do projeto e estimativas imprecisas podem resultar em fracassos (ROSS, s.d; LONGSTREET, 2002). Dessa forma, uma gerncia eficiente depende de uma viso sempre atualizada do tamanho do projeto. A APF uma das mtricas de estimativa de tamanho mais sedimentadas no mercado e que proporciona resultados cada vez mais precisos medida que artefatos da fase de anlise e projeto so gerados (CALDIERA et al., 1998). Por outro lado, o PCU permite fazer estimativas no incio do projeto com base no modelo de casos de uso, que tem sido muito utilizado no mercado, por ser mais completo que outros mtodos de especificao de requisitos (DEKKERS, 1999). Para que a estimativa de tamanho seja realizada com maior preciso desde o incio do projeto, este trabalho prope-se utilizar estas mtricas de forma combinada no momento em que elas so melhores aplicadas nas diversas fases do processo de desenvolvimento, possibilitando, assim, apoiar a gerencia de projetos.

51

Este apoio consiste da definio de um processo de gesto de estimativa que dever ser utilizado em paralelo aos processos de gesto e desenvolvimento de projetos de software. Portanto, neste captulo, sero apresentados o objetivo da gesto de estimativa proposto neste trabalho, os elementos necessrios para realizar esta gesto e, finalmente, o processo de gesto de estimativa de tamanho de software, relacionando-o com os processos de desenvolvimento e gesto de projetos de software.

 2EMHWLYR
A gesto 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 disponveis durante o processo de desenvolvimento do projeto de software orientado a objetos, de forma a apoiar as decises gerenciais ao longo da gesto 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 mtricas tm sido usadas de forma mais adequada em momentos diferentes do processo de desenvolvimento de software. Dessa forma, para alcanar este objetivo necessrio realizar as seguintes etapas: i) a padronizao dos procedimentos de contagem da APF e PCU para projetos OO, pois conforme apresentado no Captulo 2, h diferentes propostas para adaptar a APF para OO e algumas sugestes para melhoria do PCU; ii) iii) iv) a investigao da relao entre as mtricas PF e PCU, de forma a permitir o seu uso combinado; a identificao das aes gerenciais, para apoiar o gerente na tomada de deciso, durante o controle do cronograma; e, finalmente, a definio do processo de gesto de estimativa de tamanho de projetos de software, que engloba todas as atividades necessrias a esta gesto e os elementos definidos nos itens anteriores. A seguir, ser apresentada cada uma destas etapas.

52

SURMHWRV 22

 3DGURQL]DomR GRV SURFHGLPHQWRV GH FRQWDJHP GD $3) H 3&8 SDUD

A estimativa de tamanho em PCU e APF deve ser realizada continuamente no momento do ciclo de desenvolvimento do projeto de software em que estas mtricas so melhores aplicadas visando alcanar os seguintes benefcios: i) ii) iii) iv) v) permitir a comparao dos resultados das estimativas realizadas em momentos diferentes do projeto; refinar a estimativa medida que novas contagens so realizadas em APF; facilitar a tomada de decises e evitar riscos futuros com base em estimativas reais; fazer as previses de custo, prazo e produtividade da equipe com maior segurana no incio do desenvolvimento; possibilitar a identificao de falhas na documentao do projeto e melhorias nos processos. Para realizar a estimativa em PCU e PF no momento mais adequado ao longo do processo de desenvolvimento do projeto, necessrio utilizar os procedimentos de contagem propostos por estas mtricas. A APF possui regras de contagem padronizadas pelo IFPUG (2000) enquanto que, o PCU ainda no alcanou o nvel de padronizao e a contagem realizada com base na proposta inicial de Karner (1993). Em relao estimativa de projetos OO ainda h divergncias na forma de contagem, apesar dos vrios estudos realizados em relao ao mapeamento dos conceitos da APF para os conceitos OO. Sendo assim, torna-se necessrio padronizar os procedimentos de contagem da APF e PCU para projetos OO antes de realizar as estimativas. Dessa forma, para que fosse atendida a condio de uniformidade das mtricas utilizadas, os procedimentos de contagem da APF e PCU foram descritos com base no manual de contagem (verso 4.1.1) IFPUG (2000) e na proposta de Karner (1993) apresentados no captulo 2. Alguns passos dos procedimentos originais de contagem destas mtricas, foram complementados e apresentados a seguir. Ainda como parte dos procedimentos de contagem foi elaborado um questionrio explicativo sobre as caractersticas gerais do sistema (IFPUG, 2000) e dos fatores tcnicos e

53

ambientais propostos por Karner (1993). Este questionrio, apresentado no Apndice A, deve ser utilizado para identificar o nvel de influncia desses fatores nos projetos estimados.  3URFHGLPHQWRV GH FRQWDJHP GD $3) A contagem de PF realizada em sete passos conforme apresentado no Quadro 14. Todos esses passos so utilizados em projetos OO conforme apresentados no captulo 2, seo 2.3.1.1. No entanto, os passos 2, 3 e 4 foram complementados com base nas propostas de mapeamento dos conceitos da APF para conceitos orientados a objetos realizados por diversos autores como IFPUG (2001), IFPUG (2000), Ram; Raju (2000), Garmus; Herron (2000), Uemura; Kusomoto; Inoue (1999), Caldiera et al. (1998) e Fetcke; Abran; Nguyen (1997). Estes procedimentos visam facilitar a contagem de PF em projetos OO que geralmente, possuem caractersticas diferentes de projetos orientados a especificao funcional ou a documentos de requisitos (GARMUS; HERRON, 2000). 4XDGUR   3DVVRV GR SURFHVVR GH FRQWDJHP GH 3) i) LL LLL LY v) vi) vii) Determinar o tipo de contagem ,GHQWLILFDU R HVFRSR GH FRQWDJHP H D IURQWHLUD GD DSOLFDomR &RQWDU DV )XQo}HV GH GDGRV &RQWDU DV )XQo}HV WUDQVDFLRQDLV Determinar os PF no ajustados Determinar os valores dos Fatores de ajuste Calcular os PF ajustados

No passo LL ,GHQWLILFDU R HVFRSR GD FRQWDJHP H D IURQWHLUD GD DSOLFDomR, devem ser identificadas atravs do Modelo de casos de uso e dos Diagramas de seqncia11 . O modelo de casos de uso representa os atores, que esto fora da aplicao e os casos de uso representam a interao entre o ator e o sistema (APNDICE C).
11

O Modelo de casos de uso e os Diagramas de seqncia descrevem o comportamento dinmico da aplicao (UEMURA; KUSOMOTO; INOUE, 1999). O Modelo de casos de uso compe-se de diagramas e da descrio de casos de uso. A descrio de casos de uso detalha os requisitos (ANDA, 2002). Ver tambm Apndice C.

54 No passo LLL  &RQWDU DV IXQo}HV GH GDGRV deve ser contadas apenas as funes da aplicao solicitadas pelo usurio. Essas funes de dados consistem dos Arquivos Lgicos Internos (ALI) e Arquivos de Interface Externa (AIE). No contexto de projetos de desenvolvimento OO, classe de objetos considerada arquivo lgico, e mtodos, operaes ou servios so considerados funes 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 so os nomes das classes, seus atributos e associaes com outras classes. Os mtodos da classe ajudam a identificar o que o caso de uso precisa fazer e quais classes sero envolvidas na realizao do caso de uso (IFPUG, 2001). Os ALIs so as classes de objetos criadas e mantidas pela aplicao e os AIEs so as classes de objetos externas lidas e no atualizadas pela aplicao a ser contada, mas pela aplicao que a criou (RAM; RAJU, 2000). Estes arquivos so identificados nos diagramas de classes de anlise 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 esteretipo do tipo entidade 13 como candidatas a arquivos lgicos e verificar se tem operaes que mudam atributos de outros objetos ou enviam dados para outros objetos b. -XOJDU D FRPSOH[LGDGH GDV IXQo}HV GH GDGRV - as complexidades dos AIEs e ALIs so identificadas atravs do nmero de itens de dados e do nmero de registros lgicos de cada classe. O nmero de itens de dados contado atravs dos atributos da classe e dos relacionamentos reconhecidos pelo usurio, identificados no diagrama de classes. Se a classe derivada de outra, o nmero de atributos da classe bsica tambm contado (RAM; RAJU, 2000). Em projetos orientados a objetos, os registros e atores (FETCKE; ABRAN; NGUYEN, 1997; CALDIERA et al., 1998).

12

O diagrama de classes descreve a estrutura do sistema atravs das classes que consistem de atributos e operaes e das relaes entre elas incluindo a generalizao e agregao (UEMURA; KUSOMOTO; INOUE, 1999). Ver tambm Apndice C. O objeto tipo entidade modela informao que existe no sistema por muito tempo. Este tipo de objeto pode ser estruturado com relacionamentos de herana e agregao. Alm deste tipo h outros objetos do tipo controle e interface. Os objetos de controle modelam a funcionalidade que no naturalmente amarrada aos outros tipos de objetos. O objeto de controle pode operar em vrios objetos de entidades, executar um processamento e apresentar o resultado ao objeto de interface que modela o comportamento e a informao relacionada apresentao do sistema ao usurio (FETCKE; ABRAN; NGUYEN, 1997)

13

55

lgicos so tambm identificados atravs dos relacionamentos entre as classes do tipo agregao e herana (generalizao e especializao de classes) (APNDICE C). A agregao ocorre quando um objeto faz parte do outro. O objeto agregado considerado um subgrupo e, portanto, um registro lgico do agregador e o objeto agregador um ALI. Considerar as seguintes regras para identificar os registros lgicos (FETCKE; ABRAN; NGUYEN, 1997 e CALDIERA et al., 1998): a. um objeto tipo entidade, que parte de um outro objeto, um registro lgico do objeto agregado independente do tipo de cardinalidade; b. se a agregao ocorrer em vrios nveis ou seja, o objeto agregado for um agregador ao mesmo tempo, seus agregados e ele mesmo sero considerados registros lgicos do agregador maior, que o ALI identificado primeiramente. O relacionamento tipo herana no tem representao direta na APF. A hierarquia completa considerada um arquivo e cada subclasse um registro lgico (IFPUG, 2001). Devemse considerar as seguintes regras para identificar os registros lgicos neste tipo de relacionamento (FETCKE; ABRAN; NGUYEN,1997): a. quando a superclasse for abstrata, candidata a um registro lgico de cada classe que herda suas propriedades. Neste caso, as subclasses sero consideradas ALIs e no subgrupos da superclasse; b. se a superclasse no for abstrata, as subclasses sero consideradas como agrupamentos da superclasse e so identificadas como registros lgicos da superclasse; c. se um registro lgico for considerado como superclasse, toda a sua descendncia ser considerada registro lgico do ALI superior. Alm do relacionamento de herana e agregao, a associao tambm deve ser analisada no diagrama de classes de objetos. Em geral, a classe tipo associao considerada um arquivo lgico. Neste caso, conta os atributos da classe associao e os atributos que so chaves primrias nas classes associadas como elementos de dados. Quando a associao possui mltiplos valores ela considerada um registro lgico porque um grupo inteiro de objetos referenciados mantido em um atributo (CALDIERA et al., 1998). Outras funes requeridas pelo usurio como mensagens de erro e texto de ajuda, tambm devem ser contadas (FETCKE; ABRAN; NGUYEN,1997).

56

De acordo com o nmero de itens de dados e de registros lgicos referenciados, classificase o ALI e AIE em baixa, mdia ou alta complexidade, conforme o Quadro 1, apresentado no Captulo 2. No passo (iv) &RQWDU DV IXQo}HV WUDQVDFLRQDLV deve ser observado que as funes

transacionais (Entrada Externa (EE), Consulta Externa (CE) ou Sada Externa (SE)) so identificadas a partir dos casos de uso, do diagrama de seqncia ou do diagrama de classes. Os casos de uso so candidatos a transaes, que so identificadas atravs da seqncia de fluxos de interaes, definidas na descrio dos casos de uso e no diagrama de seqncia. Para identificar as funes transacionais atravs da descrio de casos de uso, deve observar as seguintes regras definidas por Fetcke; Abran; Nguyen (1997): a. selecionar cada caso de uso que tem relacionamento direto com um ator tipo usurio ou aplicao externa; b. selecionar cada caso de uso estendido como candidato transao; c. decidir se o caso de uso candidato tem uma ou mais transaes com base nos procedimentos de contagem do IFPUG (2000). Nos diagramas de seqncia, cada mensagem trocada por objetos especificados como funo de dados candidata a uma funo transacional. As funes transacionais compem-se de itens (parmetros ou argumentos) e de arquivos referenciados (geralmente as classes do tipo entidade). No diagrama de classes, as funes transacionais so identificadas atravs dos mtodos das classes (IFPUG, 1996; WHITMIRE, 1993 e CALDIERA et al. 1998, citados por RAM; RAJU, 2000). As seguintes regras devem ser observadas para identificar as funes transacionais (UEMURA; KUSOMOTO; INOUE, 1999; GARMUS D.; HERRON, D., 2000): a. se um objeto comunica-se com outros objetos atravs da interface da aplicao e algum processamento requerido no final, pode ser considerado funes transacionais do tipo entrada externa (EE), sadas externa (SE) ou consulta externa (CE) b. se a mensagem no tem argumento (elementos de dados identificados pelo usurio), significa que a mesma no troca dados e, portanto, no considerada uma funo transacional;

57

c. se um ator envia mensagem com argumentos para uma classe tipo entidade considerada uma EE; d. quando uma ou mais classes tipo entidade envia uma mensagem para um ator e todos os argumentos da mensagem so os mesmos atributos das classes, a transao uma CE; e. quando uma classe tipo entidade envia uma mensagem para um ator e todos os argumentos da mensagem so atributos derivados (dados que resultam de clculos, frmulas, ou outras operaes sobre os dados originais) da classe uma SE; De acordo com o nmero de itens de dados e classes (tipo entidade ) referenciadas, classifica-se a funo transacional em baixa, mdia ou complexa, conforme os Quadros 2, 3 e 4 apresentados no Captulo 2. Aps realizar a contagem das funes transacionais so determinados os PF no ajustados, identificados os valores dos fatores de ajuste de acordo com o nvel de influncia das caractersticas do sistema (com base o questionrio apresentado no Apndice A - questo de 1 a 14) e calculados os PF ajustados conforme procedimentos definidos no Captulo 2.  3URFHGLPHQWRV GH FRQWDJHP GH 3&8 A contagem de PCU realizada em seis passos, conforme apresentado no Quadro 15. Todos esses passos so utilizados em projetos OO, conforme apresentados no captulo 2, seo 2.3.2.1. No entanto, os passos 1 e 2 sero complementados conforme resultados dos estudos realizados por Schneider (2001), Ribu (2001), Anda., et al. (2001). 4XDGUR   3DVVRV GR SURFHVVR GH FRQWDJHP GH 3&8 L ii) iii) iv) v) vi) &RQWDU RV DWRUHV H DWULEXLU R JUDX GH FRPSOH[LGDGH &RQWDU RV FDVRV GH XVR H DWULEXLU R JUDX GH FRPSOH[LGDGH Somar o total de atores com o total de casos de uso para obter o PCU no ajustado Determinar a complexidade do fator tcnico Determinar a complexidade do fator ambiental Calcular o PCU ajustado

58 No passo L  &RQWDU RV DWRUHV H DWULEXLU R JUDX GH FRPSOH[LGDGH, pode-se usar a generalizao 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). Aps a identificao dos atores, utilizar o Quadro 7 apresentado no captulo 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 transaes, j que a complexidade do caso de uso, definida com base no nmero de transaes. Entende-se por transao um conjunto de atividades atmicas, as quais so executadas completamente ou no (SCHNEIDER; WINTERS, 2001). Ribu (2001) sugere as seguintes regras para identificar os casos de uso e respectivas transaes: a. quando a mesma transao ocorrer em diversos casos de uso, como ex: ORJLQ ou procedimentos de segurana, a transao deve ser contada apenas uma vez porque a funo implementada uma vez e reutilizada em outros casos de uso; b. contar os casos de uso estendidos e includos separadamente apenas uma vez e no como uma transao de cada caso de uso que o utiliza; c. identificar as classes de anlise (no as de projeto) que implementam as funes do caso de uso para auxiliar na determinao da complexidade do caso de uso. As classes podem ser identificadas na descrio dos casos de uso, nos diagramas de seqncia ou no diagrama de classes de anlise; d. comparar as transaes (descritas no caso de uso) com as transaes do diagrama de seqncia e com o nmero de classes de anlise utilizadas para implementar o caso de uso para verificar se a complexidade do caso de uso foi definida corretamente; e. Quando a documentao no apresentar a descrio dos casos de uso, deve-se utilizar o diagrama de seqncia para contar as transaes (apenas aquelas que indicam o que fazer e no as que indicam o como fazer) ou as classes que implementam o caso de uso. Aps identificar as transaes, deve-se atribuir o peso de cada caso de uso de acordo com o Quadro 8, apresentados no Captulo 2. Os passos iv e v (determinar a complexidade do fator tcnico e ambiental) devem ser realizados com base no questionrio apresentado no Apndice A.

59

A seguir ser apresentada a etapa 2, que a investigao da relao entre a APF e PCU.

 5HODomR HQWUH D $3) H 3&8


Os procedimentos de contagem da APF e PCU definidos no captulo 2 e complementados nas sees anteriores devem ser utilizados em diversos projetos de software de uma mesma organizao para criar uma base de dados histrica de estimativas e possibilitar, assim, a investigao da relao entre estas duas mtricas. Como no existe disponibilidade de uma base de dados histrica de estimativas de projetos OO realizadas atravs de PCU e APF, no escopo deste trabalho, essas mtricas sero aplicadas em projetos OO da academia e da indstria, visando obter valores reais de PF e PCU para subsidiar a investigao da existncia de relao entre essas mtricas. Atravs dessa relao, que pode ser definida atravs de uma equao, o gerente poder projetar o nmero de PF no incio do projeto assim que a primeira estimativa de tamanho for realizada em PCU. O nmero de PF projetado ser posteriormente aferido com o nmero real de PF, determinado atravs de outras contagens que sero 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 medio seja aprimorada constantemente, providenciar aes gerenciais para ajustar o plano e cronograma do projeto e permitir um gerenciamento mais eficiente do projeto. Dessa forma, a equao de relao definida ser utilizada para realizar a gesto da estimativa de tamanho durante todo o desenvolvimento, ou seja, a cada novo artefato produzido, uma medio do tamanho do projeto em PF pode ser realizada e esta medio pode ser comparada com um valor projetado no incio do projeto baseado na medio em PCU. Para investigar a existncia de relao 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 indstria. A coleta dos dados foi realizada atravs da anlise dos manuais de documentao dos projetos de software, disponibilizados pelos gerentes dos projetos de forma impressa e eletrnica. As caractersticas gerais do sistema foram identificadas atravs do questionrio (APNDICE A) enviado por meio eletrnico ou aplicado em forma de entrevista estruturada com os gerentes de projeto.

60

As informaes coletadas sobre cada projeto foram armazenadas em planilhas Excel e, posteriormente, analisadas de forma qualitativa, ressaltando os resultados mais importantes. Com base nos resultados da aplicao das mtricas, foram realizados diferentes testes estatsticos para investigar a existncia de relao entre APF e PCU e encontrar a equao que melhor representasse a relao entre essas mtricas. Essa investigao deve ser realizada no contexto de cada empresa devido s particularidades do processo e do ambiente de desenvolvimento de projeto de software existente. Assim, h mais garantia de preciso na equao encontrada. As principais caractersticas dos projetos da academia e da indstria e os respectivos resultados da aplicao da APF e PCU nesses projetos, sero apresentadas a seguir.  $SOLFDomR GDV PpWULFDV QD DFDGHPLD Os projetos da academia foram desenvolvidos por alunos do curso de Cincia da Computao da Universidade Catlica de Braslia (UCB). A APF e PCU foram aplicadas em 9 projetos, sendo que, 8 foram desenvolvidos como projeto final de concluso do curso e 1 foi desenvolvido como um projeto de pesquisa, mas tambm por alunos em fase final de curso. Esses projetos possuem caractersticas comuns tais como: seguem o mesmo processo de desenvolvimento de software; utilizam a UML e um formulrio padro para descrio dos casos de uso; constituem-se de uma equipe pequena e so de baixa complexidade, devido ao curto prazo que os alunos tm para definir e implementar o projeto. O formulrio padro utilizado para descrio dos casos de uso foi definido por um grupo de professores da Engenharia de Software da UCB e contm as seguintes informaes: nome do caso de uso, prioridade, atores que interagem, associao com outros casos de uso, pr-condies, fluxo principal, fluxo alternativos e ps-condies. As informaes sobre os projetos foram coletadas a partir da documentao disponibilizada pelos alunos como o documento de contexto, especificao de requisitos, diagrama de casos de uso, diagrama de classes de negcio, descrio de casos de uso e prottipo de telas, diagramas de seqncia, diagramas de classes de anlise e diagramas de classes de projetos e/ou modelo de entidade e relacionamento. A contagem de PCU foi realizada com base no modelo e descrio de casos de uso. A contagem de PF foi realizada atravs dos diagramas de classes de negcio, diagramas de

61

seqncia, diagramas de classes de anlise e de projetos, modelo de entidade e relacionamento e prottipo de telas.  $SOLFDomR GDV PpWULFDV QD LQG~VWULD Na indstria, as mtricas foram aplicadas em trs empresas (duas privadas e uma pblica). As empresas privadas tm como principal negcio 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 indstria, sendo cinco da Empresa A, dois da Empresa B e trs da Empresa C. 8QLILHG 3URFHVV (RUP) e na 8QLILHG 0RGHOLQJ /DQJXDJH (UML). separadamente para cada empresa conforme descrito a seguir. L (PSUHVD $ As trs empresas desenvolvem software orientados a objetos com base no 5DWLRQDO

As principais caractersticas das empresas e dos projetos analisados sero apresentadas

A Empresa A atuante no mercado do setor financeiro, mais especificamente no mercado de cartes de crditos e no setor de sade brasileiro. Esta empresa possui uma equipe altamente capacitada composta de mais de cem analistas e programadores, todos com formao em nvel superior e certificaes nas tecnologias mais atuais disponveis no momento. Essa empresa tem uma boa penetrao no mercado, preocupa-se com a qualidade de seus produtos e servios e, principalmente, com a satisfao do cliente. Essa empresa j utiliza o PCU para estimar o tamanho, esforo e custo de seus projetos e adota outras mtricas para medir a qualidade do processo de desenvolvimento de software e dos produtos gerados. Todos os projetos so desenvolvidos com base na tecnologia orientada a objetos, no RUP, so utilizadas as linguagens C #, C, Java e (QWHUSULVH -DYD %HDQV (EJB). UML e respectivas ferramentas como 5DWLRQDO 5RVH 6RGD etc. Para implementao dos projetos, Todas as equipes de projetos de desenvolvimento de software seguem documentos padres para definio e documentao do software tais como: documento de viso do projeto,

62

especificaes suplementares, detalhamento de casos de uso, descrio de entidades persistentes no banco de dados, etc. No documento de especificaes suplementares, so definidos os requisitos de qualidade: usabilidade, confiabilidade, desempenho, suportabilidade, portabilidade, funes e restries da aplicao. O documento de detalhamento de casos de uso consiste de histrico de alteraes (data, responsvel, motivo), orientaes para entendimento, descrio, referncias, atores, prcondies, ps-condies, fluxo de eventos, fluxo alternativos, requisitos especiais, ponto de extenso, informaes complementares (classe, atributos, formato e domnio utilizados pelo caso de uso) e observaes, aprovao do usurio gestor e do diretor executivo da empresa. O documento de descrio de entidades persistentes no banco de dados lista todas as entidades, descrio dos atributos (DOLiV, tipo, tamanho), ndices, chaves estrangeiras, tipo de gerao, referncias e comentrios. Para a contagem de PCU, foram utilizados os modelos de viso de casos de uso. Na maioria dos projetos dessa empresa, os casos de uso so agrupados em mdulos ou subsistemas que se compem da especificao dos atores, casos de uso e do modelo de casos do referido mdulo. Para a contagem de PF utilizou-se a viso lgica que consiste do modelo de anlise, do modelo do projeto e do esquema do banco de dados. Todos os projetos so desenvolvidos de forma iterativa. Geralmente so definidos todos os casos de uso na especificao de requisitos e priorizados os que sero analisados, projetados, implementados, testados e disponibilizados para os usurios nas iteraes. Por exemplo, para o projeto I1 (Tabela 2), foi realizado o levantamento de requisitos para todos os casos de uso, mas realizada a anlise e o projeto para apenas cinco casos de uso que sero implementados, testados e disponibilizados para os usurios na primeira iterao. Posteriormente, outros casos de uso sero analisados, projetados, implementados e disponibilizados em outras iteraes, at que todos os casos de uso tenham sido desenvolvidos. Sendo assim, para no comprometer a estimativa de PF em relao estimativa de PCU ou seja, PCUs obtidos atravs da contagem de todos os casos de uso e PF obtidos atravs da contagem de alguns casos de uso (apenas os que foram priorizados na iterao), decidiu-se contar PCU e PF apenas para os casos de uso priorizados na iterao,

63

para se obter uma estimativa real do tamanho em PCU e PF do projeto em desenvolvimento na iterao. LL (PSUHVD %

A Empresa B uma autarquia do setor pblico e tem como principal negcio coordenao e distribuio de recursos financeiros da rea de educao. Essa empresa possui um Setor de TI, constituda de aproximadamente 100 profissionais, responsveis pelo desenvolvimento de produtos de software necessrios realizao do negcio da organizao. O Setor de TI encontra-se atualmente em fase de migrao para as tecnologias orientadas a objetos; a linguagem Java e um novo processo de desenvolvimento de software customizado a partir do RUP. A maioria dos projetos de software em desenvolvimento tem como principal objetivo migrar sistemas legados para a nova tecnologia. Essa empresa ainda no utiliza APF ou PCU para estimar o tamanho de seus projetos de software. As equipes de projetos de desenvolvimento de software tambm seguem documentos padres para definio e documentao do sistema como o documento de viso do projeto e descrio de casos de uso. O documento de viso consiste da definio do propsito, escopo, referncias e descrio do problema e do produto, descrio dos gestores e das respectivas necessidades ou requisitos, dependncias e determinantes de qualidade do produto. O documento de descrio de casos de uso contm o controle do histrico das alteraes, descrio do caso de uso, fluxos de eventos bsicos e alternativos, solicitaes especiais, prcondies e pontos de extenso. A Empresa B disponibilizou dois projetos para contagem. LLL (PSUHVD &

A Empresa C atua na rea de planejamento da informao, informtica, treinamento e desenvolvimento de sistemas nas modalidades de fbrica de software e RXWVRXUFLQJ com alto ndice de especializao em fabricao de solues informatizadas. Essa empresa possui certificao ISO 9001, uma equipe de mais de 1000 profissionais distribudos na matriz e em diversos clientes e geralmente, utiliza metodologias e ferramentas, de acordo com a necessidade de cada projeto.

64

Os projetos disponibilizados por essa empresa so desenvolvidos com base no RUP, UML e no Modelo de Entidade e Relacionamento (MER). Essa empresa no utiliza diagramas de seqncia. As informaes sobre as classes responsveis pelos casos de uso e respectivos atributos so apresentadas no formulrio de descrio de casos de uso. O formulrio padro para descrio de casos de uso contm o histrico do documento (data, verso, descrio e autor), homologao (nome, cargo, data e assinatura), sumrio, objetivo, tipo, atores, cenrios, fluxos principal, alternativo e de exceo, pontos de extenso, pr-condies, ps-condies, entidades de negcio, requisitos no funcionais (desempenho, converso de dados, hardware, segurana, restries de implementao, interface, cpia de segurana e recuperao), observao, referncias e anexos ( leiaute de telas). Essa empresa utiliza a APF e experincias anteriores para fazer a estimativa de tamanho de seus projetos. Para os projetos dessa empresa, a contagem de PF foi realizada com base na descrio de casos de uso, diagrama de classes e MER.  $QiOLVH GRV UHVXOWDGRV Os principais resultados da aplicao de PCU e PF na academia e indstria podem ser verificados nas Tabelas 1 e 2. Os projetos foram representados pelas letras A de academia e I de indstria, seguidos do nmero seqencial do projeto. Para a contagem de PCU foram apresentados os totais de atores e casos de uso, os valores dos fatores de ajustes tcnicos e ambientais, o PCU no ajustados e ajustados. Para PF mostrou-se o nmero de AIE, ALI, o total de funes transacionais, o fator de ajuste tcnico e os valores de PF no ajustados e ajustados. Analisando os resultados apresentados na Tabela 1, observou-se que todos os projetos contados tiveram o nmero total de PF superior ao nmero total de PCU. A contagem de PF alm de ser mais detalhada, envolve a contagem de funes de dados (ALI e AIE), que vale no mnimo 7 pontos. Em relao complexidade dos ALIs, a tendncia sempre ser baixa mesmo que o ALI tenha vrios tipos de relacionamentos, inclusive herana e agregao. Isto ocorre porque a tabela usada para determinar a complexidade do ALI definida no manual de contagem do IFPUG (2000) e apresentada no Captulo 2 (Quadro 1), exige um grande nmero de itens de dados e registros lgicos para alcanar mdia ou alta complexidade.

65

O projeto A7 por exemplo, apesar de ter apenas 23 transaes identificadas na contagem de PF, possui 24 ALIs o que resultou num nmero de PF superior em mais de 100% ao nmero de PCU. Observou-se tambm que no so definidos diagramas de seqncia para todas as transaes dos casos de uso. Por exemplo, para os projetos A1 , A2 e A9 foram definidos um diagrama de seqncia para cada caso de uso do projeto. Nestes casos, foram contadas as transaes representadas nestes diagramas e as apresentadas na descrio de casos de uso. Na impossibilidade de identificar claramente as classes e respectivos elementos de dados referenciados em cada transao (j que estas informaes no foram indicadas na descrio dos casos de uso), as mesmas foram consideradas de baixa complexidade. O projeto A9 era um projeto de pesquisa, que foi posteriormente implantando na UCB e, devido a isso, tornou-se maior e mais complexo que os outros projetos da academia. Mas, para fins do estudo da relao, foi considerado um projeto acadmico por seguir o mesmo processo de desenvolvimento, a UML, o mesmo formulrio padro para descrever os casos de uso e por ter sido desenvolvido por alunos em final de curso. Observou-se, ainda, que este projeto teve 57 casos de uso, o que indica que os casos de uso foram bastante especficos e de baixa complexidade, com apenas uma a duas transaes cada um. Nesse caso, a contagem de Casos de uso pode superestimar o tamanho do software, j que cada Caso de uso vale no mnimo 5 PCUs quando se tem at 3 transaes. Portanto, de fundamental importncia que os desenvolvedores tenham claro entendimento de como definir e descrever os casos de uso e suas respectivas transaes. Os resultados da aplicao das mtricas nos projetos desenvolvidos pela indstria so apresentados na Tabela 2. Atravs dessa tabela, pode-se observar que os resultados da contagem de PCU e PF para a indstria seguiram a mesma tendncia dos resultados apresentados para a academia, diferenciando apenas no tamanho e na complexidade dos projetos. Por exemplo, o total de PF foi superior ao total de PCU em todos os projetos da indstria. Neste caso, a diferena foi ainda maior porque os projetos da indstria so mais complexos principalmente em relao s funes de dados, ou seja, so definidos muitos ALIs. Alm disso, os projetos so definidos de forma integrada com outros sistemas de informao existentes. Nesses casos, so contados tambm os AIE como nos projetos I1 a I5 e I9. De acordo com os resultados, observou-se que 1 PCU equivale a aproximadamente 3 PFs.

66

Os projetos I6 e I7 da Empresa B e os projetos I8 , I9 e I10 da Empresa C tambm tiveram a contagem de PF bem maior que PCU devido ao alto nmero de ALIs definidos no projeto, apesar da contagem de PF dos projetos da Empresa B serem baseadas na descrio de casos de uso e nos diagramas de classes e MER ou seja, as transaes no foram contadas atravs dos diagramas de seqncia porque esses diagramas no so adotados nessa empresa. Tentou-se identificar as funes transacionais atravs do diagrama de classes com base nos mtodos das classes para os projetos, que no foram definidos diagramas de seqncia para todas as transaes dos casos de uso. Observou-se que esta no uma tarefa simples, pois no h indicao clara de quais classes so responsveis por cada caso de uso, se as mesmas no forem indicadas explicitamente na descrio de casos de uso ou no diagrama de seqncia. Alm disso, no h garantia de que todos os mtodos so indicados nesse diagrama e que todos os mtodos indicados estejam relacionados implementao do negcio. Este tipo de contagem pode levar a valores sub ou super estimados das funes transacionais. Nesse sentido, deve-se analisar esta forma de contagem com mais cuidado ou adot-la apenas, quando os mtodos das classes forem claramente descritos, evitando assim, a contagem de mtodos de implementao ou criados para atender requisitos da linguagem de programao.

67

3&8
#

$&$'(0,$
d

3)
i g i g n m o i k f m og f n e i mn g n j l k i fg e g f h ej i oek e o g i mj o f e j gn e k f e i j le g o g gk k i gk gn k ek k

2 2 5 5 2 8 6

19 34 36 21 14 21 19

0,835 0,845 1,005 0,89 0,89 0,94 0,815

1,01 1,175 0,89 0,875 0,86 0,86 0,905

f m

9 16 6 16 7 8 24

19 34 48 13 15 23 23

0,85 0,96 1,07 0,95 0,95 1,02 0,9

fg

i9hg

gj

le

gk

le j i j

le i l m

l i on

en

en

i o

2 7

5 57

0,89 0,875

0,86 1,025

fg

i gn

i h

le

5 31

10 57

0,95 0,88

lg

i oj f

7DEHOD   5HVXOWDGR GD FRQWDJHP GH 3&8 H 3) QRV SURMHWRV GD DFDGHPLD /HJHQGD


Fator de Ajuste Tcnico Fator de Ajuste Ambiental Pontos de Caso de Uso no Pontos de Casos de Uso

Arquivo de Interface Externa Arquivo Lgico Interno

Consulta Externa Fator de Ajuste Tcnico

ajustados

Entrada Externa Sada Externa

Ajustados

Pontos de Funo no ajustados Pontos de Funo Ajustados


gk

qp qp l rst uv uv w f h g m m h o e g e e g gj le ej h i 9ek k f k m h i j m h k i l g k k h k i l h k i 9ek i 9ek i j k i l k i oe k i l h k i oe o i9ek e h i o h k i f k i o k i 9ek n i 9ek h k x y f uv rst h m rst g e n ek o j

qp

ajustados

g f h

l en

Ajustados Fator de Ajuste Tcnico Fator de Ajuste Ambiental Pontos de Caso de Uso no
e f o n e f f n k e e f m m i l k i l i l k g n n h ek g j g h gn

Pontos de Casos de Uso

3&8
e j f k #

7DEHOD   5HVXOWDGR GD FRQWDJHP GH 3&8 H 3) QRV SURMHWRV GD LQG~VWULD

Sada Externa Entrada Externa

/HJHQGD

i mn m

e g i e g gn

i h

j me i hk f h e

i mg f

j i n f i m l

le g f g g

i9e j o

gn

i hj h e

e n

i m h e o

f h

Arquivo de Interface Externa Arquivo Lgico Interno

,1'675,$

n me h o e f m n j e gj e m n e h e

m f k o o m h o e e o g h n oe n f h

i 9ek f f i 9ek i 9ek f 9ek i g i j g k i 9ek o i 9ek n i9ek k i 9e e m i 9e ej d

Fator de Ajuste Tcnico Fator de Ajuste Ambiental

Pontos de Caso de Uso no ajustados Pontos de Casos de Uso Ajustados

3)

lm m m

n f h g

n m o m

ek ej o n

n fg hg f

n h f h en

n l mn i j g l f i gk m i m mk h j k hn i j j e i n jo i o lm m n l i gj f i hgk k i fek f

me

e i hn o k

68

69

 (TXDomR GH UHODomR HQWUH 3) H 3&8 Com o intuito de se utilizar PCU e APF de forma combinada foi realizada uma investigao, com base nos dados das contagens de PCU e APF apresentados nas Tabelas 1 e 2 para averiguar a existncia de relao entre estas duas mtricas e a definio de uma equao que representasse esta relao atravs da anlise estatstica. O desenvolvimento de uma equao que descreva essa relao permitir a projeo de PF a partir de valores de PCU obtidos na fase inicial dos projetos. Para realizar a anlise estatstica, foram definidas as seguintes etapas: i) planejamento da anlise estatstica e ii) realizao da anlise estatstica e interpretao dos resultados. L 3ODQHMDPHQWR GD DQiOLVH HVWDWtVWLFD

Como citado anteriormente, foram contados 19 projetos, sendo 9 da academia e 10 da indstria. O objetivo principal dessa contagem era identificar uma relao entre as medidas que pudesse ser expressa atravs de uma equao a ser utilizada para realizar a gesto da estimativa do projeto durante o processo de desenvolvimento do projeto. Dessa forma, o objetivo principal avaliar a seguinte hiptese de estudo: +LSyWHVH GH (VWXGR   Existe uma relao entre PCU e APF resultantes de contagens

em projetos de desenvolvimento de software desenvolvidos na academia e na indstria e esta relao pode ser representada por uma equao matemtica. No entanto, como os projetos foram desenvolvidos em ambientes diferentes ou seja, na academia e em trs empresas distintas, levantou-se a questo se os resultados das contagens poderiam ser agrupados ou no. Diante desta questo, decidiu-se fazer a anlise estatstica dos dados das contagens de PCU e APF nos projetos da academia e das empresas separadamente e testar as seguintes hipteses de estudo: +LSyWHVH GH (VWXGR   No existe diferena entre as equaes que representam a

relao entre PCU e APF em projetos de desenvolvimento de software de diferentes empresas. +LSyWHVH GH (VWXGR   No existe diferena entre as equaes que descrevem a

relao entre PCU e APF dos projetos da academia e da indstria. Estas hipteses sero testadas atravs da anlise de regresso, que uma das modalidades de anlise da relao existente entre duas variveis. Esta ferramenta estatstica utiliza a relao

70

existente entre variveis quantitativas de maneira que uma varivel possa ser estimada a partir da outra (NETER; WASSERMAN; KUTNER, 1989). Esta relao expressa por uma equao matemtica e o problema consiste em estabelecer a funo matemtica que melhor exprima a relao existente entre as duas variveis, no caso deste trabalho, PCU e APF. Na rea de engenharia de software, tcnicas de regresso vm sendo bastante empregadas no estudo de relaes entre variveis. Por exemplo, Caldiera et al. (1998) considerou vrias equaes de regresso para descrever a relao entre o seu mtodo de estimativa de tamanho (OOFP) e o tamanho final da aplicao estimado em linhas de cdigo (LOC). Karner (1993) tentou encontrar a relao entre PCU e os recursos necessrios para concluir o projeto (em homens/hora). Tichenor (1997) usou a regresso linear para encontrar a relao entre o resultado da contagem de seu mtodo ()DVW FRXQW) e APF (IFPUG) e entre APF e dias gastos pela equipe de desenvolvimento em uma amostra de projetos concludos. LL 5HDOL]DomR GD DQiOLVH HVWDWtVWLFD H LQWHUSUHWDomR GRV UHVXOWDGRV

7HVWH GD +LSyWHVH GH HVWXGR  A hiptese de estudo 1 a principal suposio deste trabalho, pois a existncia de uma relao entre PCU e APF uma condio essencial para que estas duas mtricas sejam utilizadas de forma combinada no processo de gesto de estimativa, atravs de modelos matemticos que descrevam esta relao. O uso de modelos ou equaes matemticas que descrevam a relao entre PCU e APF permitir a projeo de PF a partir de contagens de PCU. No presente caso, foram testadas equaes linear e polinomial de 2 grau ou quadrtica como descritoras da relao entre PCU e APF. Estes modelos so representados pelas seguintes equaes: Quadrtico: \ E  E [  E [
| { z { z

Linear: \

E E [

varivel independente, no caso, PCU. Nestas equaes, E  E H E representam respectivamente, o intercepto14, o coeficiente de efeito linear e o coeficiente de efeito quadrtico.
| { z

O termo \ indica a varivel dependente, no caso APF e o termo [ representa a

No caso da equao linear, a relao entre as variveis representada por uma linha reta enquanto que no modelo quadrtico, uma linha curva representa esse tipo de relao.
14

Intercepto a altura na qual a linha de regresso corta o eixo Y (NETER; WASSERMAN; KUTNER, 1989).

71

verificao da adequao de uma ou outra equao desenvolvida atravs de testes estatsticos que avaliam, dentro de uma margem de erro, hipteses de nulidade dos coeficientes das equaes. Assim, o teste sobre a adequao da equao linear feito estabelecendo-se uma hiptese nula sobre o coeficiente linear (E ). A aceitao dessa hiptese indicaria que o valor de E sendo zero, a equao linear no adequada para descrever a relao entre PCU e APF. Com relao equao quadrtica, a hiptese de nulidade a ser testada refere-se ao coeficiente quadrtico (E ). Assim, se a hiptese nula, de que b2 zero, for aceita, o coeficiente quadrtico deve ser retirado da equao. Para ambas equaes, a hiptese alternativa a de que os coeficientes linear e quadrtico so diferentes de zero. A rejeio da hiptese nula com conseqente aceitao da hiptese alternativa indica que as equaes so adequadas para descrever a relao entre PCU e APF. Estas hipteses so propostas da seguinte maneira: a. Para teste de adequao da equao linear: Hiptese nula: H0 : b1= 0 Hiptese alternativa Ha : b1  Hiptese nula: H0 : b2 = 0
| { {

b. Para teste de adequao da equao quadrtica: Hiptese alternativa Ha : b2  Estas hipteses so testadas atravs de um teste t15. Nesse teste, um valor de t calculado pelas formulas: para esse coeficiente; padro para esse coeficiente. o W calculado for igual ou menor ao valor de W da tabela (para o nvel de significncia e o grau de O valor de W calculado comparado com o valor de W existente em tabelas estatsticas17. Se
| | | | { { { {

a. equao linear: W

E V E onde E o coeficiente linear e V E o desvio padro16 E V E onde E o coeficiente quadrtico e V E o desvio

b. equao quadrtica: W

liberdade), a hiptese de nulidade aceita e se o W calculado maior que o valor W da tabela, essa

hiptese rejeitada em favor da hiptese alternativa. Nesses testes, existe sempre a possibilidade
15

O teste de t , que baseado na distribuio de 6WXGHQW, usado para pequenas amostras e tem aplicaes em testes de hipteses ou de significncia para mdias e calculo de intervalos de confiana (MARKUS, 1974). O desvio padro a raiz quadrada da varincia do coeficiente de regresso Tabelas estatsticas so tabelas com valores crticos que servem de comparao com os valores de t calculado, ao nvel de significncia estabelecido e com os mesmos graus de liberdade.

16 17

72

de rejeio da hiptese de nulidade quando na realidade ela verdadeira. A possibilidade desse erro, que conhecido como Erro tipo I , deve ser estabelecido pelo analista estatstico, e chamada de nvel de confiana. Os valores de tabela de W variam em funo desses nveis de confiana. Atualmente, os pacotes de anlise estatstica ao realizarem testes de W para os

coeficientes de equao de regresso, produzem um valor S18, que indica, para o W calculado, qual

o nvel de confiana ou probabilidade de incorrer o Erro tipo I. Como exemplo, se for estabelecido priori um nvel de confiana de 5%, a hiptese nula ser rejeitada sempre que o valor de S calculado pelo pacote estatstico for igual ou menor que 0,05. No presente estudo, o software 6WDWLVWLFDO $QDO\VLV 6RIWZDUH (SAS) e os modelos de

programao propostos por Freund e Litteli (1991) e Smith e Cody (1991) foram utilizados para anlise de regresso dos dados coletados nos projetos da academia e indstria. Para os testes da Hiptese 1, as anlises de regresso foram realizadas nos dados de contagem de PCU e PF nos projetos agrupados da seguinte maneira: a. nove projetos da academia; b. cinco projetos da Empresa A; c. cinco projetos das Empresas B+C. Os projetos da academia foram analisados separadamente porque haviam sido desenvolvidos seguindo processos e tecnologias diferentes. Alm disso, foram desenvolvidos por alunos em final de curso, sem experincia em desenvolvimento de software. Os projetos da indstria apesar de basearem no RUP e UML foram separados em dois grupos de cinco projetos (Empresa A e Empresas B + C). Os projetos da Empresa A foram analisados separadamente para identificar se havia diferena nas equaes encontradas para uma nica empresa, j que para esta empresa haviam sido contados cinco projetos, amostra mnima para fazer a anlise estatstica. As contagens dos projetos das Empresas B e C foram agrupadas visando obteno de uma amostra de tamanho suficiente para permitir o estudo da relao entre as variveis PCU e PF, j que haviam sido contados apenas 2 e 3 projetos respectivamente da Empresa B e C e tambm por verificar que o ambiente, processos e tecnologias utilizadas por elas eram bastante semelhantes, apesar da empresa B ser uma autarquia pblica com 100 profissionais

18

S ou nvel de significncia indica a probabilidade de ocorrncia de erro tipo I, ou seja de rejeitar-se a hiptese de nulidade quando ela verdadeira.

73

e a empresa B ser uma fbrica 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 so apresentados na Tabela 3. Nesta Tabela, pode-se observar que para as trs situaes analisadas (academia, Empresa A e Empresas B + C) os valores de S do coeficiente quadrtico esto acima do nvel de confiana de 5% (S ! ), o que nos leva a aceitar a hiptese de nulidade (H0 : b2 = 0 ) de que os coeficientes quadrticos so zero e que, portanto uma equao quadrtica no adequada para descrever a relao entre PF e PCU observada nas empresas A, B + C e academia. A mesma tabela mostra que na equao linear, os valores de p para os coeficientes lineares so menores que 0,05 o que rejeita a hiptese de nulidade (H0 : b1= 0 ) para todos eles. Assim, a hiptese alternativa (Ha : b1  p DFHLWD H FRQFOXL-se que equaes lineares so as mais adequadas para descrever a relao entre PCU e PF em projetos da academia, Empresa A e Empresa B + C. 7DEHOD   9DORUHV GRV QtYHLV GH VLJQLILFkQFLD S REWLGRV SHOR WHVWH W QDV HTXDo}HV GH UHJUHVVmR TXDGUiWLFD H OLQHDU 7HVWH W QtYHLV GH VLJQLILFkQFLD S
 ~ ~ }

0RGHORV 4XDGUiWLFD Empresa A Empresas B e C academia /LQHDU Empresa A Empresas B e C academia

,QWHUFHSWR E

&RHILFLHQWH OLQHDU E

&RHILFLHQWH TXDGUiWLFR E

0,324 0,348 0,514 0,861 0,461 0,340

0,954 0,036 0,139   

0,2964 0,1358 0,8600 -

Nesta Tabela 3, observa-se tambm que para os interceptos os valores de p so maiores que 0,05, indicando uma aceitao da hiptese de nulidade (H0 : b0= 0), ou seja de que os interceptos das equaes lineares descrevendo a relao entre PCU e PF em projetos da academia e industrias zero. De fato, ao considerar que PCU e PF so variveis quantitativas de medida de tamanho de software, zero um valor possvel para o intercepto de uma equao linear descrevendo relao entre as duas variveis, pois quando PCU for zero, obrigatoriamente, PF tambm ser zero.

74

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

7DEHOD  9DORUHV GRV QtYHLV GH VLJQLILFkQFLD S REWLGRV SHOR WHVWH W QDV HTXDo}HV GH UHJUHVVmR OLQHDU VHP LQWHUFHSWR
,QWHUFHSWR E &RHILFLHQWH OLQHDU E

7HVWH W QtYHLV GH VLJQLILFkQFLD S


&RHILFLHQWH TXDGUiWLFR E
 ~ ~ }

0RGHOR /LQHDU VHP LQWHUFHSWR Empresa A Empresas B e C academia 7HVWH GD +LSyWHVH GH HVWXGR 

  <

Neste teste, a hiptese verificada a de que no existe diferena entre as equaes que representam a relao entre PCU e APF em projetos de desenvolvimento de diferentes industrias. A eventualidade de no existirem diferenas entre essas equaes permitir que as contagens de PCU e PF realizadas nas trs empresas sejam agrupadas. Com isso, um nmero maior de casos analisados resultar numa equao que permitir maior preciso nas estimativas. Neste estudo, como foram realizadas contagens em cinco projetos da Empresa A, em trs projetos da Empresa

75

B e em dois da Empresa C, na comparao entre as equaes das industrias, as contagens dos projetos avaliados nas Empresas B e C foram agrupadas conforme relatado anteriormente. Assim, a comparao foi realizada entre a equao que descreve a relao PCU e APF dos projetos das Empresas B e C (que passaram a serem consideradas uma nica empresa) e aquela que descreve a mesma relao para os projetos da Empresa A. A comparao entre as equaes foi realizada conforme indicado por Neter e Wasserman (1974) e compe-se dos seguintes passos: i) Ajuste do modelo completo ou sem restries para obteno da Soma de Quadrado do Erro do modelo completo SQE(C)19. O modelo completo consiste no ajuste de equaes separadamente para a relao entre PCU e APF dos projetos da Empresa A e das Empresas B + C. Como este passo j foi completado anteriormente no teste da hiptese 1, o SQE do modelo completo ser a soma do valor de SQE obtido na regresso da Empresa A com o valor de SQE obtido na regresso das Empresas B + C. Esses valores foram fornecidos pelo pacote SAS. ii) Ajuste do modelo restrito para obteno da Soma de Quadrado do Erro do modelo restrito SQE(R). Neste caso, uma nica equao linear foi definida para representar a relao entre PCU e PF para o agrupamento dos dados de contagem das Empresas A, B e C, ou seja 10 projetos. Esse ajuste foi realizado pelo pacote SAS, que forneceu o valor de SQE. Uma das hipteses a serem testadas indica que os interceptos e coeficientes lineares das equaes definidas para a empresa A e empresas B + C so iguais. A hiptese alternativa a de que interceptos e coeficientes lineares so diferentes. Estas hipteses podem ser descritas da seguinte maneira: b. C2: b0 Empresa A E0 Empresas B + C ou b1 Empresa A E1 Empresas B + C ou ambos so diferentes. Nesse teste, um valor de ) calculado pela formula: O teste estatstico para verificar qual das hipteses acima ir prevalecer um teste )20. a. C1: b0 Empresa A = b0 Empresas B + C e b1 Empresa A = b1 Empresas B + C

19 20

O teste ) utilizado para comparao de varincias.

SQE o somatrio dos desvios entre o valor observado e o valor estimado pelo modelo de regresso elevado ao quadrado

76 ) 64( 5 64( &   64( & Q  Q  RQGH Q o numero de projetos


{ | { |

contados na Empresa A e Q o nmero de projetos contados nas Empresas B + C.

pela formula acima com o valor de ) encontrado em tabelas estatsticas. O valor de ) da tabela encontrado, considerando-se um nvel de significncia e os graus de liberdade do numerador (2) e do denominador (Q  Q ) da formula acima. Se o valor do ) calculado for menor ou igual ao calculado for maior que F da tabela optamos por & ou que as equaes so diferentes. valores gerados pelo pacote estatstico SAS. Os valores foram: SQE (Empresa A) = 14402 SQE (Empresas B+C) = 12587 SQE (Empresas A+B+C) = 51518 SQE(C) = 14402 + 12587 = 26629 SQE(R) = 51518 tabela de 6,94. Assim, como o valor de ) calculado menor que o valor de ) da tabela foi entre PCU e PF nas Empresas A e B + C. Considerando que as equaes so iguais, aconselhvel o agrupamento das contagens de PF e PCU, para estabelecimento de uma nica B + C). A equao estabelecida foi a seguinte: 3) 7HVWH GD +LSyWHVH  No existe diferena entre as equaes que descrevem a relao entre PCU e PF dos projetos da academia e da indstria. Seguindo a mesma lgica relatada na hiptese anterior, a inexistncia de diferenas entre as equaes geradas para academia e indstria permitir o agrupamento de todos os dados de contagens realizados para ajuste de uma s equao que descreveria a relao entre PCU e PF para projetos da indstria e da Academia. Nesta comparao as hipteses so: a. C1: b0 industria = b0 academia e b1 industria = b1 academia equao para descrio da relao entre as duas variveis em projetos da indstria (Empresas A +  3&8
{ |

A aceitao de uma ou outra hiptese realizada pela comparao do valor de ) calculado

do ) da tabela, conclumos & ou que no existe diferena entre as equaes. Se o valor de )


{

A comparao entre as equaes definidas para Empresa A e Empresas B + C utilizou n = 5 (n de casos estudados) n = 5 (n de casos estudados) n = 10 (n de casos estudados)

Aplicando a formula acima temos um ) calculado com valor de 2,80. O valor de ) da

adotado & ou seja, no existe diferena entre as equaes definidas para representar a relao

77 b. C2: b0 industria E0 academia ou diferentes. Seguindo os passos utilizados anteriormente a comparao entre a equaes lineares da industria e academia seria: SQE (industria) = 51518 SQE (academia) = 12628 SQE (indstria + academia) = 270012 SQE(C) = 51518 + 12628 = 64146 SQE(R) = 270012 tabela de 4,54. Assim, como o valor de ) calculado maior que o valor de F da tabela foi PCU e PF na indstria e na academia. A Figura 2 mostra a representao grfica das equaes desenvolvidas para academia e indstria. A reta indica os valores estimados a partir da equao encontrada para a academia (PF=1,4615 PCU) e para a indstria (PF=2,8905 PCU). O nvel de significncia S indica a possibilidade de erro ao aceitar-se que existe uma relao entre as variveis PCU e PF e que essa relao descrita por uma equao linear. No caso, o valor de S menor que 0,0001. Outra estatstica apresentada nesta Figura o coeficiente de determinao R. Esse coeficiente indica quanto da variabilidade existente em PF explicado com a utilizao da varivel PCU. Um valor alto como o encontrado (R = 0,97) e o baixo nvel de significncia S indicam o excelente ajuste das equaes definidas. Os valores de R inicialmente encontrados para a academia (R = 0,9697) e para a indstria (R = 0,9723) foram arredondados para 0,97. Devido a isso, os valores de R foram iguais para as duas equaes. As diferenas entre as equaes da academia e indstria podem ser atribudas ao nvel de complexidade dos projetos desenvolvidos e ao nmero de casos de uso definidos. Os projetos de concluso de curso desenvolvidos na academia no utilizam, na maioria das vezes, AIEs e possuem um nmero relativamente baixo de ALIs, o que implica em uma pontuao menor de PF para estes projetos. Por outro lado, so definidos muitos casos de uso de baixa complexidade
|

b1 industria

E1 academia ou ambos so

n = 10 (n de casos estudados) n = 9 (n de casos estudados) n = 19 (n de casos estudados)

Aplicando a formula acima temos um ) calculado com valor de 24,07. O valor de ) da

adotado & ou seja, existe diferena entre as equaes definidas para representar a relao entre

78

(com apenas 1 ou 2 transaes). Isto tambm contribui para que a contagem de PCU fique superior e conseqentemente diminui a diferena entre o total de PCU e PF. J os projetos da indstria, alm de serem mais complexos em relao ao nmero de funes de dados e de funes transacionais, so melhores definidos, ou seja, os nmeros de casos de uso representam as funes do software de forma mais adequada, o que pode torn-los menores em nmero de casos de uso descritos e mais complexos em relao ao nmero de transaes realizadas.

800 700 600 500

DFDGHPLD
3)  3&8

800 700 600 500 400

LQG~VWULD
3)  3&8

400

300 200 100 0 0 100 200




300

R = 0,97 p < 0,0001


300 400

200 100 0 0 100 200




R = 0,97 p < 0,0001


300 400

)LJXUD   5HODomR HQWUH 3&8 H $3) HP SURMHWRV GD DFDGHPLD H GD LQG~VWULD importante ressaltar ainda, que estas equaes serviram para mostrar que existe uma relao entre APF e PCU e que essas mtricas podem ser utilizadas de forma combinada. Para que as equaes sejam utilizadas na prtica pelas empresas que fizeram parte desta pesquisa e pela academia recomendamos o refinamento das mesmas atravs da contagem final dos projetos utilizados no escopo deste trabalho e a gerao de novas equaes a serem utilizadas para projeo de PF de futuros projetos desenvolvidos em ambientes semelhantes. Para obter maior preciso na equao a ser utilizada para projetar PF, importante que cada empresa da indstria encontre a equao de relao entre a APF e PCU atravs das contagens de seus prprios projetos, desenvolvidos com base em processos, padres e tecnologias especficas ao ambiente de desenvolvimento de software da empresa.

79

A seguir ser apresentado o estudo realizado na terceira etapa da pesquisa ou seja, a identificao das aes gerenciais a serem utilizadas pelo gerente do projeto durante o processo de gesto de estimativa de tamanho.

,GHQWLILFDomR GDV Do}HV JHUHQFLDLV D VHUHP WRPDGDV SHORV JHUHQWHV


A partir da gesto de estimativas associada gerncia de projetos, o gerente ter informaes 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 decises de ajustes no plano e no cronograma com base em aes gerenciais sendo, dessa forma, fornecido o apoio definido no objetivo do processo de gesto de estimativa de tamanho descrito na seo 4.2. No entanto, para facilitar a tomada de deciso nesse momento, necessrio identificar quais aes so mais relevantes e podero subsidiar os gerentes de projeto na execuo do processo de gesto de estimativa. Para identificar estas aes, foi realizada uma pesquisa de campo, com gerentes de projetos de software, baseada em aes gerenciais, disponveis na literatura e apresentadas no captulo 3. Para realizar esta pesquisa foram definidas trs etapas: definio, a qual foi formalizado o objetivo do estudo, e coleta e anlise de dados, na qual foi feita a pesquisa de campo propriamente dita e a anlise dos resultados. Estas etapas sero descritas a seguir. L 'HILQLomR O objetivo do estudo foi definido com base na estrutura da tcnica *RDO 4XHVWLRQ

0HFWULFV (GQM), conforme proposto por Wohlin et al.(2000) e Solingen e Berghout, (1999) (QUADRO 16).
3URSyVLWR: Identificar

4XDGUR   2EMHWLYR GH (VWXGR

2EMHWR um conjunto de aes gerenciais

3RQWR GH YLVWD: gerentes de projeto de software

1R FRQWH[WR GH gesto de estimativa de tamanho de projetos de software

80

Considerando este objetivo e o contexto da gesto de estimativa que permitir ao gerente de projeto uma forma de estimar, revisar e recalcular o tamanho do projeto para que possa realizar uma melhor gesto do tempo ou prazo de desenvolvimento do projeto (considerando a medida de tamanho), foi analisado ento quais os momentos em que o gerente de projeto precisa tomar aes gerenciais relacionadas ao tempo ou prazo do mesmo. Um primeiro momento logo no incio do projeto quando o gerente faz uma primeira estimativa para definir prazos para o cliente. Com a estimativa de tamanho inicial, o gerente pode perceber que o prazo que o cliente deseja receber o produto impraticvel diante do tamanho do necessrio identificar  TXDLV Do}HV GHYHP VHU WRPDGDV TXDQGR R FURQRJUDPD GR SURMHWR p projeto a ser desenvolvido. Dessa forma, para alcanar o objetivo definido no Quadro 16,

LPSUDWLFiYHO. Foram, ento, listadas diferentes aes baseadas nas recomendaes de Jurison (1999); Pressman (2002), PMBOK (2000), CMM, nvel 2 (PAULK, 2000) e McGARRY et al. (2001) apresentadas no captulo 3. Assim, atravs da pesquisa de campo, foi solicitado aos gerentes de projeto a indicao das aes mais recomendadas , recomendadas , pouco recomendadas ou no recomendadas . Uma vez definido um prazo com o cliente, necessrio que o gerente acompanhe o cronograma durante todo o processo de desenvolvimento do software, buscando mant-lo dentro do prazo estabelecido. Dessa forma, para alcanar o objetivo definido no Quadro 16, necessrio identificar  TXDLV Do}HV GHYHP VHU WRPDGDV SDUD PDQWHU R FURQRJUDPD GR SURMHWR GHQWUR de campo, foi solicitado que os gerentes de projeto identificassem a periodicidade em que essas aes devem ser tomadas na prtica, ou seja, no incio do desenvolvimento do projeto , semanalmente , mensalmente , aps o final de cada fase de desenvolvimento , as que so tomadas esporadicamente , sem periodicidade definida e as no praticadas pelos gerentes . No entanto, medida que o gerente de projeto acompanha continuamente a execuo do projeto, mesmo tomando aes para mant-lo no prazo, pode acontecer do cronograma atrasar por diferentes fatores. Como citado no captulo 3, Farias (2002) realizou uma pesquisa em que identificou diferentes fatos que levam um cronograma a atrasar (como por exemplo, equipe de desenvolvimento indisponvel, projeto com alto grau de inovao, entre outros). Dessa forma, Assim, foi decidido identificar  TXDLV Do}HV GHYHP VHU WRPDGDV SDUD FDGD IDWR LGHQWLILFDGR apesar de todo o controle, o cronograma pode sofrer algum atraso devido a algum desses fatos. GR SUD]R Uma lista de aes foi definida com base nos mesmos autores anteriores. Na pesquisa

81 FRPR FDXVDGRU GR DWUDVR QR FURQRJUDPD GR SURMHWR, de forma a melhor alcanar o objetivo definido no Quadro 16. Os fatos que provocam atraso no cronograma foram identificados no estudo realizado por Farias (2002). Esses fatos foram listados juntamente com as possveis aes a serem tomadas pelo gerente, para evit-los ou minimizar a ocorrncia dos mesmos. Essas aes tambm foram definidas baseadas nos autores citados acima. Esse conjunto de questes, contendo as aes e fatos, foi organizado em um questionrio apresentado no Apndice B. ii) &ROHWD H DQiOLVH GH GDGRV A coleta de dados foi realizada atravs da aplicao do questionrio apresentado no Apndice B. Os participantes do estudo foram os gerentes de projetos de software da indstria (empresas pblicas e privadas) e alunos do curso de Ps-graduao em Gesto do Conhecimento e Tecnologia da Informao (GCTI) da UCB, cujo perfil so de profissionais que trabalham na indstria na rea de TI. Esses participantes so representativos para os profissionais que desempenham a funo de gerente de projeto. Desta forma, as aes gerenciais indicadas pelos participantes sero baseadas na experincia pessoal de cada respondente do questionrio. Foram enviados 23 questionrios via e-mail para profissionais de empresas pblicas e privadas e distribudos 25 pessoalmente, para os alunos do curso de Ps-Graduao em GCTI da UCB. Do total de 48 questionrios distribudos, obteve-se 37 respostas. A primeira parte do questionrio identificou as caractersticas dos profissionais que participaram da pesquisa como: a formao profissional, rea de atuao e experincia na gesto de projetos conforme mostram as Figuras 3 e 4. Dentre os respondentes, 36 atuam na indstria e alguns desses atuam tambm na academia como aluno de ps-graduao, professor e ou pesquisador conforme mostra a Figura 3. Apenas 1 respondente atua apenas na academia.

82

$WXDomR QD ,QG~VWULD
Gerente de TI Gerente de projeto 2 3 1 3 9 19 Membro de projeto Gerente de estimativa de projeto Consultor externo No respondeu

$WXDomR QD $FDGHPLD
Professor 1 0 6 2 19 Pesquisador Aluno psgraduao Gerente de estimativa Consultor externo

)LJXUD   UHD GH DWXDomR GRV UHVSRQGHQWHV Em relao formao profissional, identificou-se que alm do curso de graduao, 23 dos respondentes possuem especializao, 18 possuem mestrado, 3 possuem doutorado e 8 possuem certificaes. Dentre os profissionais certificados, 3 so certificados pelo PMI, 1 pelo IFPUG e 4 em outras reas (Figura 4).
)RUPDomR SURILVVLRQDO UHD GH FHUWLILFDomR

18

Doutorado Mestrado Especializao Graduao Certificao 4

IFPUG PMI Outro 3

37

23

)LJXUD   )RUPDomR SURILVVLRQDO GRV UHVSRQGHQWHV Identificou-se tambm a experincia dos respondentes em relao ao tempo de atuao em gesto de projetos e o nmero de projetos gerenciados. A Figura 5 mostra que 13 possuem de 5 a 10 anos e 12 de a 1 a trs anos de experincia. Apenas 3 possuem mais de 10 anos de experincia, sendo que a maioria dos respondentes gerenciou de 1 a 5 projetos de software.

83

13

)LJXUD   ([SHULrQFLD HP JHVWmR GH SURMHWRV Quanto gesto de tempo de execuo de projetos, verificou-se que a experincia dos respondentes varia entre mdia a baixa conforme mostra a Figura 6. Aps identificar as caractersticas dos respondentes, os resultados da pesquisa foram acordo com as questes definidas na etapa L GHILQLomR conforme apresentado a seguir.
([SHULrQFLD HP JHVWmR GH WHPSR GH H[HFXomR GH SURMHWRV
Alta Mdia Baixa 11 19 Nenhuma No respondeu

analisados em conjunto (j que 36 dos respondentes so da indstria e apenas 1 da academia) de

)LJXUD   ([SHULrQFLD HP JHVWmR GH WHPSR GH H[HFXomR GH SURMHWRV 4XHVWmR  4XDLV Do}HV GHYHP VHU WRPDGDV TXDQGR R FURQRJUDPD GR SURMHWR p LPSUDWLFiYHO" Para responder esta questo, foram identificadas na literatura as aes a serem tomadas pelo gerente ainda na fase de planejamento, ou mais especificamente, aps a definio do cronograma do projeto, caso o cronograma seja irreal ou impraticvel de se executar. Para cada ao, foi solicitada a indicao do nvel de recomendao representado pela escala de 1 a 4 ou seja, 4- muito recomendada, 3- recomendada, 2- pouco recomendada e 1 - no recomendada de acordo com a experincia do respondente (APNDICE B, I Planejamento).

"bb%b"c

bb (c

bbE7

12

bc b""bb'b#@cS"c

bEc

7HPSR GH DWXDomR HP JHVWmR GH SURMHWRV

1 - 3 proj 11 3 - 5 proj 5 - 10 proj mais de 10 proj 10 no respondeu

bEc

84

A Tabela 5 apresenta o resultado para a questo 1 de acordo com a freqncia da indicao das aes (listadas na coluna 1) por nvel de recomendao (apresentado em negrito nas colunas de 2 a 6). Por exemplo, a ao 1 teve 26 indicaes para o nvel 4. Isto mostra que esta ao muito recomendada. Por outro lado, os resultados mostram que a ao 6 no recomendada por 100% dos respondentes do questionrio. Alm das aes apresentadas inicialmente no questionrio, trs outras aes foram sugeridas por um dos respondentes: medir a satisfao do cliente, motivar a equipe e oferecer treinamento. 7DEHOD   $o}HV UHFRPHQGDGDV TXDQGR R FURQRJUDPD p LPSUDWLFiYHO
$o}HV  4 0 0 1 0 0  0 0 10 3 3  1tYHO GH UHFRPHQGDomR  0 5  10 14 0   14 2 2 5 0 

1. Reunir-se com o cliente, apresentar a estimativa detalhada em relao ao esforo e a durao estimada para o projeto e negociar novo prazo. 2. Definir uma estratgia de desenvolvimento incremental que entregue a funcionalidade crtica na data prevista e adie as funes restantes. 3. Negociar o aumento do oramento e contratar mais recursos humanos apesar de que esta soluo pode comprometer a qualidade do produto. 4. Contratar consultoria especializada para resolver problemas tcnicos. 5. Substituir os tcnicos que no tem apresentado resultados satisfatrios. 6. Ignorar a realidade e esperar completar o prazo determinado no cronograma.

7  6   0

2 1mR UHVSRQGHX  1mR UHFRPHQGDGD  3RXFR 5HFRPHQGDGD  5HFRPHQGDGD  0XLWR UHFRPHQGDGD

O Quadro 17 sintetiza as respostas para a questo (1), por ordem decrescente de indicao das aes pelos respondentes do questionrio.

85 4XDGUR   $o}HV D VHUHP WRPDGDV TXDQGR R FURQRJUDPD p LPSUDWLFiYHO


$o}HV PDLV UHFRPHQGDGDV $o}HV UHFRPHQGDGDV

4XHVWmR  4XDLV Do}HV GHYHP VHU WRPDGDV TXDQGR R FURQRJUDPD GR SURMHWR p LPSUDWLFiYHO"

$o}HV SRXFR UHFRPHQGDGDV $o}HV QmR UHFRPHQGDGDV 2XWUDV Do}HV LQGLFDGDV

$omR  Reunir com o cliente, apresentar a estimativa detalhada em relao ao esforo e a durao estimada para o projeto e negociar novo prazo. $omR Definir uma estratgia de desenvolvimento incremental que entregue a funcionalidade crtica na data prevista e adie as funes restantes. $omR  Contratar consultoria especializada para resolver problemas tcnicos. $omR  Substituir os tcnicos que no tem apresentado resultados satisfatrios. $omR  Negociar o aumento do oramento e contratar mais recursos humanos. $omR  Ignorar a realidade e esperar completar o prazo determinado no cronograma 100% respondentes. Medir a satisfao do cliente, motivar a equipe e oferecer treinamento.

A prxima questo do questionrio (APNDICE B, II Acompanhamento), visa identificar as aes que permitem controlar ou manter o cronograma dentro do prazo em resposta questo (2) apresentada na etapa L GHILQLomR (Tabela 6).

SUD]R

4XHVWmR  4XDLV Do}HV GHYHP VHU WRPDGDV SDUD PDQWHU R FURQRJUDPD GR SURMHWR GHQWUR GR Foi solicitada aos respondentes, a indicao das aes de acordo com a escala de

periodicidade em que elas so realizadas na prtica: 1- no incio do desenvolvimento, 2 semanal, 3 mensal, 4 aps o trmino de cada fase de desenvolvimento, 5 sem periodicidade definida e 6 - no pratica estas aes. A Tabela 6 mostra os resultados de acordo com a freqncia das respostas. De acordo com esta tabela, pode-se verificar que nove (2 a 8, 10 e 18) das vinte e duas aes propostas para a questo devem ser adotadas no incio do desenvolvimento, sete (9, 12 14, 16, 17 e 19) semanalmente e seis sem periodicidade definida (1,11, 16, 17, 21 e 22). A Tabela 6 mostrou tambm que a ao 10 foi a mais indicada, seguida da ao 21 e posteriormente das aes 3, 5, 12, 18 e 19. Os resultados apresentados na Tabela 6 indicam que a maioria das aes recomendadas para manter o cronograma no prazo (16 das 22) deve ser tomadas no incio do desenvolvimento, semanalmente ou sem periodicidade definida conforme mostra o Quadro 18.

86

7DEHOD   $o}HV D VHUHP WRPDGDV SDUD FRQWURODU RX PDQWHU R FURQRJUDPD QR SUD]R


$o}HV 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 necessrio para implementar cada atividade. 3.Incluir reservas oramentrias para resolver problemas ou executar o plano de contingncia. 4. Identificar e documentar as restries no plano do projeto que limitaro a realizao das atividades e elaborar um plano de contingncia. 5. Verificar se todas as atividades e tarefas que visam alcanar o objetivo do projeto constam no cronograma e foram entendidas pela equipe. 6. Identificar se os marcos de referncia do projeto foram estabelecidos de modo que o progresso possa ser acompanhado. 7. Verificar se todo o esforo e durao do projeto foram atribudos corretamente a cada atividade do cronograma. 8. Verificar se as interdependncias entre as atividades foram adequadamente indicadas. 9. Identificar questes que podem causar problemas futuros, providenciar aes corretivas e alertar a equipe do projeto. 10. Identificar as atividades que no so do projeto ou que dependem de fornecedores para serem executadas. 11. Identificar possveis mudanas que influenciam no cronograma (ex: na legislao, no escopo ou tecnologia). 12. Identificar e coordenar as atividades e tarefas realizadas em paralelo. 13. Identificar quais datas do cronograma foram alcanadas e quais no foram. 14. Conduzir reunies peridicas para que cada membro do projeto possa relatar o progresso e os problemas atuais. 15. Analisar os relatrios de desempenho do projeto e avaliar os resultados das revises conduzidas ao longo do processo de desenvolvimento. 16. Atualizar o plano, os documentos tcnicos e informar a equipe e clientes. 17. Ter membros representativos nas reunies de revises tcnicas 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, difceis de serem substitudas ou est comprometido com outros projetos. 19. Controlar a produtividade da equipe. 20. Refinar as estimativas realizadas no incio do projeto durante todo o ciclo de desenvolvimento do projeto. 21. Contratar consultoria externa para auxiliar no uso da tecnologia. 22. Facilitar a comunicao entre os membros da equipe.  5        7  8 10 0 0 0 0 3  0 1 8 5  11 12 1 6 10 6 5 5  2 9    10   1  6 1 11 3HULRGLFLGDGH   3 2 3 2 5 6 6 8 6 7 3 5 6 7 8  6 7 6 11 11 1 3 4 4 4 4 5 9 9 6 6 5 3 10 1 8 9 6 3 2   4 8 7 4 4 5 4 9 3  3 3 4 7   8 5 5    2 0 4 3 0 1 1 1 0 1 1 0 1 1 3 1 4 2 2 2 5 2

 3 2

(1) No incio do desenvolvimento (2) Semanal (3) Mensal (4) Aps o trmino de cada fase de desenvolvimento (5) Sem periodicidade definida (6) No pratica estas aes.

87 4XDGUR   $o}HV D VHUHP WRPDGDV TXDQGR R FURQRJUDPD HVWi GHQWUR GR SUD]R


1R LQtFLR GR GHVHQYROYLPHQWR GR SURMHWR

4XHVWmR  4XDLV Do}HV GHYHP VHU WRPDGDV SDUD PDQWHU R FURQRJUDPD GR SURMHWR GHQWUR GR SUD]R"

6HPDQDOPHQWH

0HQVDOPHQWH $SyV R ILQDO GH FDGD IDVH GH GHVHQYROYLPHQWR 6HP SHULRGLFLGDGH GHILQLGD

1mR SUDWLFDGDV 2XWUDV Do}HV

$omR  Identificar as atividades que no so do projeto ou que dependem de fornecedores para serem executadas. $omR  Incluir reservas oramentrias para resolver problemas ou executar o plano de contingncia. $omR  Verificar se todas as atividades e tarefas que visam alcanar o objetivo do projeto constam no cronograma e foram entendidas pela equipe. $omR  Identificar se h algum membro da equipe que possui habilidades nicas, difceis de serem substitudas ou est comprometido com outros projetos. $omR  Avaliar o tempo necessrio para implementar cada atividade. $omR  Identificar se os marcos de referncia do projeto foram estabelecidos de modo que o progresso possa ser acompanhado. $omR  Verificar se as interdependncias entre as atividades foram adequadamente indicadas. $omR  Identificar e documentar as restries no plano do projeto que limitaro a realizao das atividades e elaborar um plano de contingncia. $omR  Verificar se todo o esforo e durao do projeto foram atribudos corretamente a cada atividade do cronograma. $omR  Conduzir reunies peridicas 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 alcanadas e quais no foram. $omR  Identificar questes que podem causar problemas futuros, providenciar aes corretivas e alertar a equipe do projeto. $omR  Atualizar o plano, os documentos tcnicos e informar a equipe e clientes. $omR  Ter membros representativos nas reunies de revises tcnicas para garantir o entendimento comum das necessidades do cliente e evitar futuras surpresas. $omR  Analisar os relatrios de desempenho do projeto e avaliar os resultados das revises conduzidas ao longo do processo de desenvolvimento. $omR  Refinar as estimativas realizadas no incio do projeto durante todo o ciclo de desenvolvimento do projeto. Esta indicao coincide com a proposta do processo de gesto de estimativa, definido neste trabalho (ver Figura 7). $omR . Contratar consultoria externa para auxiliar no uso da tecnologia. $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 comunicao entre os membros da equipe. $omR  Identificar possveis mudanas que influenciam no cronograma (ex: na legislao, no escopo ou tecnologia). $omR  Atualizar o plano, os documentos tcnicos e informar a equipe e clientes. $omR  Ter membros representativos nas reunies de revises tcnicas para garantir o entendimento comum das necessidades do cliente e evitar futuras surpresas. $omR  Ignorar a realidade e esperar completar o prazo determinado no cronograma. Medir a satisfao do cliente, motivar a equipe e oferecer treinamento.

A ltima questo do questionrio (APNDICE B II Acompanhamento) identificou as apresentada na etapa L GHILQLomR. As aes foram indicadas de acordo com os fatos que provocam atraso no cronograma. Os nmeros indicados nas colunas representam as aes listadas aes a serem tomadas pelo gerente quando o cronograma est atrasado em resposta a questo (3)

88

no topo da tabela e as linhas representam os fatos que provocam o atraso no cronograma. Foi solicitada a indicao das aes a serem tomadas para cada fato. 4XHVWmR  4XDLV Do}HV GHYHP VHU WRPDGDV SDUD FDGD IDWR LGHQWLILFDGR FRPR FDXVDGRU GR A seguir sero apresentadas as aes indicadas para cada fato. Os nmeros destacados representam a freqncia de respostas mais significantes conforme mostra a Tabela 7. 7DEHOD   $o}HV D VHUHP WRPDGDV TXDQGR R FURQRJUDPD HVWLYHU DWUDVDGR
$o}HV D VHUHP WRPDGDV TXDQGR R FURQRJUDPD HVWLYHU DWUDVDGR
7. 8. 1. 2. 3. 4. 5. 6. Rever o planejamento do projeto e identificar desvios no cronograma. Agregar novas pessoas na equipe do projeto. Redistribuir as pessoas na equipe. Rever as funes do software, prioriz-las e deixar as menos importantes para futuras verses. Rever o cronograma e buscar alcanar o prximo marco do projeto na data prevista para garantir o trmino do projeto na data esperada. Caso no haja possibilidade de recuperao do atraso, o gerente deve rever o cronograma e negociar com as partes envolvidas. Controlar a comunicao entre os membros do projeto. Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de alternativas de respostas a riscos. 9. Verificar se as atualizaes do cronograma requerem ajustes em outros aspectos do plano geral do projeto. 10. Registrar os desvios do cronograma, identificar quais atividades ocorreram e o motivo de sua ocorrncia. 11. Contratar consultoria especializada.

DWUDVR QR FURQRJUDPD GR SURMHWR"

)DWRV TXH SURYRFDP DWUDVR QR FURQRJUDPD

$o}HV UHFRPHQGDGDV
C 4

12 8
4

10 1 3 9
7

0 2 1 2 10 6 7 4 5 3 0 2 0 2

6 3 7 3 2 6 3 5 6 3 5

1 9 7 5 4 3 5 4 4 4 4 3 7 8

8 12 11 5 6 5 4 7 6 6 9 10 6

8 1 1 1 6 6 6 4 5

6 14

4 9

4 6 9 8 18 4 4 6 6 6
4

3. Prazos e custos estabelecidos arbitrariamente. 4. Mtodo de estimativa de tamanho inadequado. 5. Gerncia inexperiente. 6. Equipe de desenvolvimento inexperiente em Engenharia de Software. 7. Equipe de desenvolvimento inexperiente no domnio da aplicao. 8. Equipe de desenvolvimento inexperiente nos mtodos e ferramentas utilizadas. 9. Processo de desenvolvimento inadequado. 10. Levantamento ou acompanhamento de requisitos com pessoas inexperientes. 11. Alto grau de competio na empresa do cliente. 12.Falta de comprometimento do usurio/cliente. 13. Oramento insuficiente. 14. Requisitos complexos. 15. Hardware e/ou software necessrios no disponveis no momento definido.

9 7 11 8 9
C

7 5 3 5 7 6 7 9
C

9 4 5 5 6 4 5 5 7 5 7

17 2
C

9 9
4

1 3 0 6 0

9 3 5 2

4 7 8

11 11

2. Projeto com alto grau de inovao.

1. Equipe de desenvolvimento indisponvel.

3 4

7 4 1 1 9 1

89

)DWRV TXH SURYRFDP DWUDVR QR FURQRJUDPD


16. Dependncia de produtos ou servios externos que afetam o produto, o oramento, o cronograma ou a continuidade do projeto. 17. Mudanas de requisito que no foram refletidas em mudanas do cronograma. 18. Falta de identificao dos riscos previsveis e imprevisveis no incio do projeto. 19. Falta de identificao das dificuldades tcnicas e humanas no incio do projeto. 20. Falta de comunicao entre os membros do projeto. 12

$o}HV UHFRPHQGDGDV
0 3 0 5 3 0 0 0 7 6 5 6 4 6 3 6 11 6 8 5 12 11 11 8 3 4 4 2 6
C 4

4 11 10 6 4

7 9 7 6 3

1 2 2 4 2

10 13 10 3

Com base na Tabela 7, foram destacadas as aes mais indicadas para cada fato causador do atraso no cronograma e apresentado no Quadro 19 abaixo. 4XDGUR   $o}HV PDLV LQGLFDGDV SDUD FDGD IDWR
)DWRV TXH SURYRFDP DWUDVR QR FURQRJUDPD  (TXLSH GH GHVHQYROYLPHQWR LQGLVSRQtYHO  3URMHWR FRP DOWR JUDX GH LQRYDomR  3UD]RV H FXVWRV HVWDEHOHFLGRV DUELWUDULDPHQWH  0pWRGR GH HVWLPDWLYD GH WDPDQKR LQDGHTXDGR $omR  Rever o planejamento do projeto e identificar desvios no cronograma $omR  Agregar novas pessoas na equipe do projeto. $omR  Rever o planejamento do projeto e identificar desvios no cronograma. $omR  Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de respostas a riscos $omR  Rever o cronograma e negociar com as partes envolvidas, caso no haja possibilidade de recuperao do atraso $omR  Rever o planejamento do projeto e identificar desvios no cronograma. $omR  Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de alternativas de respostas a riscos. $omR  Verificar se as atualizaes do cronograma requerem ajustes em outros aspectos do plano geral do projeto. $omR  Rever o cronograma e negociar com as partes envolvidas, caso no haja possibilidade de recuperao do atraso. $omR  Contratar consultoria especializada. $omR  Agregar novas pessoas na equipe do projeto. $omR  Agregar novas pessoas na equipe do projeto. $omR  Registrar os desvios do cronograma, identificar quais atividades ocorreram e o motivo de sua ocorrncia. $omR  Redistribuir as pessoas na equipe. $omR  Contratar consultoria especializada. $o}HV PDLV LQGLFDGDV

 *HUrQFLD LQH[SHULHQWH

 (TXLSH GH GHVHQYROYLPHQWR LQH[SHULHQWH HP (QJHQKDULD GH 6RIWZDUH

4 4

90 4XDGUR  FRQW  $o}HV PDLV LQGLFDGDV SDUD FDGD IDWR


)DWRV TXH SURYRFDP DWUDVR QR FURQRJUDPD  (TXLSH GH GHVHQYROYLPHQWR LQH[SHULHQWH QR GRPtQLR GD DSOLFDomR  (TXLSH GH GHVHQYROYLPHQWR LQH[SHULHQWH QRV PpWRGRV H IHUUDPHQWDV XWLOL]DGDV  3URFHVVR GH GHVHQYROYLPHQWR LQDGHTXDGR  /HYDQWDPHQWR RX DFRPSDQKDPHQWR GH UHTXLVLWRV FRP SHVVRDV LQH[SHULHQWHV  $OWR JUDX GH FRPSHWLomR QD HPSUHVD GR FOLHQWH  )DOWD GH FRPSURPHWLPHQWR GR XVXiULRFOLHQWH  2UoDPHQWR LQVXILFLHQWH  5HTXLVLWRV FRPSOH[RV  +DUGZDUH HRX VRIWZDUH QHFHVViULRV QmR GLVSRQtYHLV QR PRPHQWR GHILQLGR $o}HV PDLV LQGLFDGDV $omR  Agregar novas pessoas na equipe do projeto. $omR  Contratar consultoria especializada. $omR  Rever o planejamento do projeto e identificar desvios no cronograma. $omR  Contratao de consultoria especializada. $omR  Rever o planejamento do projeto e identificar desvios no cronograma; $omR  Agregar novas pessoas na equipe do projeto. $omR  Controlar a comunicao entre os membros do projeto. $omR  Registrar os desvios do cronograma, identificar quais atividades ocorreram e o motivo da sua ocorrncia. $omR  Rever o planejamento do projeto e identificar desvios no cronograma; $omR  Rever o cronograma e negociar com as partes envolvidas, caso no haja possibilidade de recuperao do atraso. $omR  Controlar a comunicao entre os membros do projeto. $omR  Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de alternativas de respostas a riscos. $omR  Rever o planejamento do projeto e identificar desvios no cronograma; $omR  Rever as funes do software, prioriz-las e deixar as menos importantes para futuras verses. $omR  Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de alternativas de respostas a riscos. $omR  Rever as funes do software, prioriz-las e deixar as menos importantes para futuras verses. $omR  Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de alternativas de respostas a riscos. $omR . Rever o planejamento do projeto e identificar desvios no cronograma. $omR . Rever o cronograma e negociar com as partes envolvidas, caso no haja possibilidade de recuperao do atraso. $omR . Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de alternativas de respostas a riscos. $omR  Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de alternativas de respostas a riscos. $omR  Rever o cronograma e negociar com as partes envolvidas, caso no haja possibilidade de recuperao do atraso. $omR  Rever o planejamento do projeto e identificar desvios no cronograma

 'HSHQGrQFLD GH SURGXWRV RX VHUYLoRV H[WHUQRV TXH DIHWDP R SURGXWR R RUoDPHQWR R FURQRJUDPD RX D FRQWLQXLGDGH GR SURMHWR

91

4XDGUR  FRQW  $o}HV PDLV LQGLFDGDV SDUD FDGD IDWR


)DWRV TXH SURYRFDP DWUDVR QR FURQRJUDPD  0XGDQoDV GH UHTXLVLWR TXH QmR IRUDP UHIOHWLGDV HP PXGDQoDV GR FURQRJUDPD  )DOWD GH LGHQWLILFDomR GRV ULVFRV SUHYLVtYHLV H LPSUHYLVtYHLV QR LQtFLR GR SURMHWR  )DOWD GH LGHQWLILFDomR GDV GLILFXOGDGHV WpFQLFDV H KXPDQDV QR LQtFLR GR SURMHWR  )DOWD GH FRPXQLFDomR HQWUH RV PHPEURV GR SURMHWR $omR  Rever o planejamento do projeto e identificar desvios no cronograma. $omR  Rever o cronograma e buscar alcanar o prximo marco do projeto na data prevista para garantir o trmino do projeto na data esperada. $omR  Rever o cronograma e negociar com as partes envolvidas, caso no haja possibilidade de recuperao do atraso. $omR  Verificar se as atualizaes do cronograma requerem ajustes em outros aspectos do plano geral do projeto. $omR . Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de alternativas de respostas a riscos. $omR  Rever o planejamento do projeto e identificar desvios no cronograma. $omR . Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de alternativas de respostas a riscos. $omR  Rever o cronograma e negociar com as partes envolvidas, caso no haja possibilidade de recuperao do atraso. $omR  Controlar a comunicao entre os membros do projeto $o}HV PDLV LQGLFDGDV

A ao 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 questo 3, pode-se concluir que as aes mais indicadas pelos respondentes, (independente do fato causador do atraso), quando o cronograma est atrasado, so as apresentadas no Quadro 20 em ordem de decrescente de indicao. Alm das aes apresentadas no questionrio (APNDICE B), alguns respondentes indicaram outras aes relevantes a serem tomadas, quando o cronograma est atrasado e as associaram aos fatos conforme mostra tambm o Quadro 20. O nmero apresentado entre parntesis indica a quantidade de respondentes que indicaram a ao.

92 4XDGUR   $o}HV D VHUHP WRPDGDV SHORV JHUHQWHV TXDQGR R FURQRJUDPD HVWi DWUDVDGR
$o}HV D VHUHP WRPDGDV SHORV JHUHQWHV TXDQGR R FURQRJUDPD HVWi DWUDVDGR $omR  Rever o planejamento do projeto e identificar desvios no cronograma. $omR  Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de alternativas de respostas a riscos. $omR  Rever o cronograma e negociar com as partes envolvidas, caso no haja possibilidade de recuperao do atraso. $omR  Registrar os desvios do cronograma, identificar quais atividades ocorreram e o motivo de sua ocorrncia. $omR  Verificar se as atualizaes do cronograma requerem ajustes em outros aspectos do plano geral do projeto. $omR  Agregar novas pessoas na equipe do projeto. $omR  Contratar consultoria especializada. $omR  Controlar a comunicao entre os membros do projeto. $omR  Rever o cronograma e buscar alcanar o prximo marco do projeto na data prevista para garantir o trmino do projeto. $omR  Rever as funes do software, prioriz-las e deixar as menos importantes para futuras revises. $omR  Redistribuir as pessoas na equipe. )DWR  H  - Ao 12. Oferecer treinamento (5). )DWR   Ao 13. Capacitar a equipe (1). )DWR   Ao 14. Substituir a gerncia (1). )DWR  - Ao 15. Fazer revises peridicas e constantes com o usurio (1). )DWR   Ao 16. Rever o processo para adequ-lo necessidade da empresa (1).

2XWUDV Do}HV LQGLFDGDV GH DFRUGR FRP R IDWR SHORV UHVSRQGHQWHV

Finalmente, aps estudar e complementar os procedimentos de contagem da APF e PCU para projetos OO de acordo com a literatura, aplicar estes procedimentos na contagem de projetos reais (academia e indstria), encontrar a relao entre estas mtricas e identificar as aes a serem tomadas pelo gerente do projeto, foi definido um processo de gesto de estimativa de tamanho, incorporando todas as etapas acima para apoiar o gerente do projeto durante todo o processo de desenvolvimento do projeto. Este processo ser descrito a seguir.

 3URFHVVR GH JHVWmR GH HVWLPDWLYD GH WDPDQKR GH SURMHWR GH VRIWZDUH


O processo de gesto de estimativa de tamanho de projeto de software visa apresentar atividades a serem realizadas durante a gesto de estimativa de tamanho de forma integrada com os processos de desenvolvimento e gesto de projetos de software. Para executar as atividades do processo de gesto de estimativas so utilizadas informaes, procedimentos e recursos que so considerados entradas importantes para este processo tais como: i) documentao do projeto de software;

93

ii) iii) iv) v) vi) vii)

procedimentos de contagem de PCU e PF; equao de relao entre PF e PCU; hardware e software necessrios realizao das estimativas; histrico de estimativas de tamanho de projeto de software desenvolvidos na empresa; plano e cronograma do projeto de software; aes a serem tomadas durante o acompanhamento do projeto de desenvolvimento de software.

Os itens (ii), (iii) e (vii) foram definidos nas sees 4.3, 4.4.4 e 4.5 deste captulo. Os principais produtos de sada ou resultados do processo de gesto de estimativas de tamanho so: i) ii) iii) iv) v) vi) vii) nmero de PCU contados para o projeto; nmero de PF projetados e contados (em diferentes fases do processo de desenvolvimento); planilhas com os resultados das contagens; diferena entre o nmero de PF projetado e o nmero de PF contado; relatrio de controle atual do projeto de desenvolvimento; lista de aes gerenciais a serem executadas para corrigir os desvios do projeto; base de dados de histrico de estimativas atualizada.

Este processo tem como principais clientes o gerente comercial da empresa; o gerente de projeto de software, os membros de projeto de software e o usurio gestor do produto de software. O processo de gesto de estimativas compe-se das seguintes atividades: atividade 1: Realizar a contagem de tamanho inicial em PCU; atividade 2: Projetar a estimativa em PF; atividade 3: Realizar a contagem de tamanho em PF; atividade 4: Comparar o nmero de PF projetado com o nmero de PF contado; atividade 5: Obter informaes gerenciais do projeto; atividade 6: Comparar as estimativas com o cronograma planejado; atividade 7: Providenciar aes de ajuste no projeto; atividade 8: Realizar estimativa de tamanho final em PF (PF entregue).

94

Para cada atividade do processo sero descritos a seguir os objetivos, o responsvel, os pr-requisitos necessrios para sua realizao, as tarefas que a compe, os produtos de entrada e sada e as diretrizes21 a serem utilizadas para a sua realizao conforme apresentado no Quadro 21. 4XDGUR   $WLYLGDGHV GR SURFHVVR GH JHVWmR GH HVWLPDWLYD GH WDPDQKR

$WLYLGDGH  5HDOL]DU D FRQWDJHP GH WDPDQKR LQLFLDO HP 3&8 2EMHWLYR Identificar a primeira estimativa de tamanho do projeto em PCU 5HVSRQViYHO Gerente de projeto de software 3UpUHTXLVLWR Existncia do modelo e descrio de casos de uso gerados no processo de

7DUHIDV Realizar a contagem de PCU 3URGXWRV GH HQWUDGD Solicitao de estimativa de tamanho do projeto Artefatos gerados no processo de desenvolvimento de software 3URGXWRV GH VDtGD Nmero de PCU contados e planilhas geradas na contagem (Modelo e descrio de casos de uso) Documentar o resultado da contagem realizada

desenvolvimento de software

'LUHWUL]HV Procedimentos de contagem de PCU descritos no Captulo 2 e na seo 4.3 deste captulo. $WLYLGDGH  3URMHWDU D HVWLPDWLYD HP 3)

2EMHWLYR Estimar o nmero de PF no incio do projeto, usando a equao que descreve a 5HVSRQViYHO Gerente de projeto de software ter realizado a estimativa do projeto em PCU 7DUHIDV Aplicar a equao de relao 3URGXWRV GH HQWUDGD Nmero de PCU contados 3URGXWRV GH VDtGD Nmero de PF projetados Equao de relao entre PF e PCU relao entre PCU e PF

3UpUHTXLVLWR Ter encontrado uma equao de relao entre PF e PCU para a organizao e

21

Diretrizes so normas, regras, procedimentos e ou documentos utilizados durante a execuo de uma atividade do processo.

95 'LUHWUL]HV No tem
#

$WLYLGDGH  5HDOL]DU D FRQWDJHP GH WDPDQKR HP 3) 5HVSRQViYHO Gerente de projeto de software

2EMHWLYR Identificar a primeira estimativa de tamanho do projeto em PF 3UpUHTXLVLWR Existncia do Modelo de casos de uso, Diagramas de seqncia dos casos de

uso e do Modelo de classes de anlise 7DUHIDV Realizar a contagem de PF Documentar a contagem realizada

3URGXWRV GH HQWUDGD Artefatos gerados no processo de desenvolvimento de software 3URGXWRV GH VDtGD Nmero de PF contados e planilhas geradas na contagem (Modelo de casos de uso Diagramas de seqncia e Modelo de classes de anlise)

'LUHWUL]HV Procedimentos de contagem de PF descritos no Captulo 2 e na seo 4.3 deste captulo. $WLYLGDGH  &RPSDUDU D FRQWDJHP UHDOL]DGD HP 3) FRP R Q~PHUR GH 3) SURMHWDGR 2EMHWLYR Analisar os resultados das estimativas de tamanho projetadas para PF (atravs da equao), com a estimativa de tamanho realizada em PF para o projeto 5HVSRQViYHO Gerente de projeto de software 3UpUHTXLVLWR Existncia do nmero de PF projetado e do nmero de PF contado 3URGXWRV GH HQWUDGD Nmero de PF projetado e o nmero de PF contado

7DUHIDV Analisar e comparar os resultados de PF

'LUHWUL]HV No tem

3URGXWRV GH VDtGD Diferena entre o nmero de PF projetado e o nmero de PF contado $WLYLGDGH  2EWHU LQIRUPDo}HV JHUHQFLDLV GR SURMHWR 5HVSRQViYHO Gerente de projeto de software

2EMHWLYR Levantar as informaes relevantes sobre o desenvolvimento do projeto 3UpUHTXLVLWR Existncia de estimativas realizadas em PCU e PF (projetado e contado), cronograma do projeto e relatrios de acompanhamento do projeto 7DUHIDV Identificar as informaes e a situao atual do desenvolvimento do projeto

3URGXWRV GH HQWUDGDNmero de PCU e PF projetado e contado, planejamento do projeto


22

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

96

cronograma do projeto, estimativas de esforo e custo do projeto e relatrios de acompanhamento ou controle do projeto, 'LUHWUL]HV No tem 3URGXWRV GH VDtGD Relatrio com a situao atual do desenvolvimento do projeto

$WLYLGDGH  &RPSDUDU DV HVWLPDWLYDV FRP R FURQRJUDPD SODQHMDGR 2EMHWLYR Identificar a situao atual do cronograma 5HVSRQViYHO Gerente do projeto de software

3UpUHTXLVLWR Existncia de estimativas em PCU e em PF (projetada e contada) e relatrio

da situao atual do projeto fornecido pelo processo de gesto de projetos. pela equipe do projeto

7DUHIDV Comparar as atividades planejadas no cronograma com as atividades realizadas Comparar o esforo e os custos estimados com a ltima contagem realizada em PF Analisar os problemas e os riscos identificados no projeto Identificar os fatos que causaram os problemas 3URGXWRV GH HQWUDGD Nmero de PCU e PF (projetado e realizado) e relatrio com a situao atual do projeto 3URGXWRV GH VDtGD Relatrio da situao atual do cronograma e Lista de aes gerenciais selecionadas pelo gerente do processo de gesto de estimativas com base no resultado do estudo realizado na seo 4.5) 'LUHWUL]HV Aes gerenciais proposta neste trabalho Identificar as aes gerenciais mais adequadas para solucionar o problema

$WLYLGDGH  3URYLGHQFLDU Do}HV GH DMXVWH QR SURMHWR

3UpUHTXLVLWR Existncia do nmero de PCU e de PF (projetado e realizado), situao atual cronograma e aes a serem tomadas pelos gerentes 7DUHIDV Verificar a lista de aes recomendadas Executar as aes recomendadas para ajustar o projeto caso o cronograma seja 3URGXWRV GH HQWUDGD: Nmero de PCU e PF (projetado e estimado), situao atual do impraticvel, esteja atrasado ou as aes para evitar futuros atrasos

5HVSRQViYHO Gerente do projeto de software

2EMHWLYR Corrigir os desvios do cronograma do projeto e evitar novos problemas

97

cronograma e lista de aes recomendadas problemas identificados

3URGXWRV GH VDtGD Lista de aes de ajustes a serem executadas para corrigir os desvios ou 'LUHWUL]HV: No tem

$WLYLGDGH  5HDOL]DU D FRQWDJHP ILQDO GH 3)

5HVSRQViYHO Gerente de estimativa de tamanho de projetos

2EMHWLYR Identificar o tamanho real do produto de software 3UpUHTXLVLWR Artefatos gerados durante o processo de desenvolvimento de software,

produto de software desenvolvido e base de dados com o histrico das estimativas realizadas. 7DUHIDV Atualizar a contagem anterior com base na documentao atual e no produto de software concludo Armazenar os resultados das contagens realizadas durante todo o processo de 3URGXWRV GH HQWUDGD Artefatos gerados durante o processo de desenvolvimento de software (Modelo de casos de uso, modelo de anlise e projeto, Modelo de Entidade e Relacionamento MER), planilhas utilizadas nas contagens anteriores e produto de software. atualizadas 3URGXWRV GH VDtGD Nmero final de PF e Base de dados de histrico das estimativas 'LUHWUL]HV Procedimentos de contagem de PF definidos no captulo 3 na sesso 4.3 A seguir, ser apresentado o relacionamento deste processo com os processos de desenvolvimento e de gesto de projeto software.  5HODFLRQDPHQWR GR SURFHVVR GH JHVWmR GH HVWLPDWLYD GH WDPDQKR FRP RV SURFHVVRV GH desenvolvimento do projeto na Base de dados de histrico de estimativas

GHVHQYROYLPHQWR H GH JHVWmR GH SURMHWRV GH VRIWZDUH

O processo de gesto de estimativa foi definido de forma integrada com os processos de desenvolvimento e gesto de projetos de software. As atividades desses processos foram definidas com base na NBR ISO/IEC 12.207 (ANBT, 1998) e NBR ISO/IEC 10.006 (ABNT, 2000) no PMBOK (2000), na prtica chave do CMM nvel 2 que aborda as estimativas (PAULK ET AL., 2000) apresentadas no captulo 3.

98

A norma NBR ISO/IEC 10.006 (ABNT, 2000) utiliza os processos de gesto de projetos relacionados a interdependncias entre os processos, ao escopo, tempo, custo, recursos, pessoal, comunicao, risco e suprimentos como s reas de conhecimento proposta pelo PMBOK (2000). Os processos relacionados ao tempo e a rea de conhecimento gesto de tempo , so utilizados durante a execuo das atividades dos processos de desenvolvimento e de gesto propostas pela NBR ISO/IEC 12.207 (ABNT, 1998) conforme mostra o Quadro 11, apresentado no captulo 3. Esses processos geram informaes de entrada para o processo de estimativa de tamanho e utilizam os produtos de sada deste processo de gesto de estimativas e as aes gerenciais identificadas atravs do estudo realizado neste trabalho. O relacionamento do processo de gesto de estimativas com os processos de desenvolvimento e gesto de software, ocorre conforme mostra a Figura 7. A Figura 7 dividida em trs partes. A primeira parte apresenta um processo de desenvolvimento de software, suas principais atividades ou disciplinas (modelagem de negcio, requisitos, anlise e projeto, implementao, testes e implantao) e os principais artefatos gerados pelas atividades e utilizados no processo de gesto de estimativa de tamanho, conforme proposto pelo processo OO apresentado no Apndice C. A segunda parte desta Figura, mostra o processo de gesto de estimativas de tamanho, suas respectivas atividades descritas na seo anterior e os elementos utilizados durante a execuo deste processo como a equao de relao entre a APF e PCU, os valores do PF projetados e contados durante o desenvolvimento do projeto e a lista de aes gerenciais identificadas na seo 4.5 deste captulo. A terceira parte mostra o processo de gesto de projetos de software e seus respectivos processos conforme proposto pelo PMBOK (2000). O relacionamento entre os trs processos apresentados na Figura 7 ocorre atravs: i) das principais atividades e artefatos gerados pelo processo de desenvolvimento de software (definidos com base no Apndice C) que so pr-requisitos ou documentos de entrada para o processo de estimativa de tamanho; ii) dos processos de gesto de projetos propostos pelo PMBOK, que utilizam as informaes geradas pelo processo de gesto de estimativa de tamanho e ao mesmo tempo subsidiam este processo com informaes sobre o plano,

99

cronograma e relatrios do status do projeto em desenvolvimento (definidos com base no PMBOK (2000) e nos Quadro 13 e 14 apresentados no captulo 3); iii) de informaes do histrico das estimativas realizadas durante o processo de desenvolvimento do projeto e outras informaes relevantes sobre o projeto. Essas informaes sero reutilizadas em futuros projetos conforme recomenda a NBR ISO/IEC 10006 (ABNT, 2000) e o CMM nvel 2 (PAULK et al. 2000). O processo de gesto de estimativa de tamanho mostra atravs da Figura 7, que a estimativa inicial do projeto ser realizada atravs do PCU com base no modelo e descrio de casos de uso do sistema definidos na disciplina de requisitos do processo de desenvolvimento (atividade 1). O modelo de casos de uso de negcio, gerado na disciplina de modelagem de negcio, no utilizado neste processo porque nesse modelo ainda no foram identificados os casos de uso que representam as funes do software a ser desenvolvido. Com base no resultado da contagem de PCU e na equao de relao entre APF e PCU ser projetado nmero de PF desempenhar as atividades do processo de SODQHMDPHQWR que faz parte dos processos de gesto (atividade 2). Atravs do PCU encontrado e do PF projetado, o gerente do projeto poder

de projetos tais como: i) estimar o esforo e custo do projeto; ii) elaborar o plano e o cronograma do projeto; e iii) negociar compromissos com o cliente de acordo com os recursos necessrios. Nesse ponto, o gerente do projeto deve identificar e documentar os riscos do software associado aos custos, recursos, cronograma e aspectos tcnicos do projeto e elaborar planos de contingncias como recursos humanos alternativos, hardware, software e ferramentas adicionais.

/HJHQGD

Atividade

#

"

Modelo de casos de uso de negcio

)LJXUD   5HODFLRQDPHQWR GR SURFHVVR GH JHVWmR GH HVWLPDWLYD GH WDPDQKR FRP RV SURFHVVRV GH GHVHQYROYLPHQWR H JHVWmR GH SURMHWRV GH VRIWZDUH

Artefatos

 

Dados Processo

 !

    


  


&

)     

Informao
Histrico de estimativas

0 1   

Base de dados dados

'

 ! 

 

Histrico de estimativas

100

101

A projeo de PF ser gerenciada e re-estimada durante todo o ciclo de desenvolvimento do projeto de software, medida que novos artefatos forem desenvolvidos. Assim que os diagramas de seqncia e os de classes de anlise forem gerados, ser realizada a primeira contagem de PF (atividade 3). Posteriormente, na disciplina de projeto ser realizada nova contagem de PF com base no diagrama de classes de projeto. Em seguida, a estimativa de PF projetada ser comparada com a estimativa de PF encontrada (atividade 4). Nesse ponto do projeto, o gerente poder comparar os resultados das estimativas com as informaes gerenciais do projeto, obtidas atravs dos processos de SODQHMDPHQWR H FRQWUROH GR SURMHWR (processos de gesto de projetos), e verificar se o cronograma possvel de se realizar ou impraticvel, se est dentro do prazo ou se est atrasado (atividade 5 e 6). Deve ser verificado o grau de completitude das atividades realizadas, o trabalho j concludo, o esforo e os recursos gastos com o planejamento inicial. Com base nos resultados dessa comparao, o gerente ir providenciar aes de ajustes no projeto, de acordo com as aes gerenciais validadas atravs da pesquisa realizada neste trabalho (atividade 7). Em geral, as aes incluem revises no plano de desenvolvimento do projeto, aes para melhorar o desempenho da equipe e comunicao das decises para as pessoas envolvidas. As mudanas no tamanho do projeto estimado podem afetar as negociaes realizadas anteriormente, tornando necessrio novas negociaes com o cliente. O cronograma e o plano do projeto rastreado pelo gerente durante os processos de planejamento, controle e execuo do projeto, conforme proposto pelo PMBOK (2000), CMM nvel 2, rea chave de planejamento de projeto de software (PAULK et al., 2000) e de acordo com as necessidades do projeto e as diretrizes da organizao. Finalmente, aps a implementao e testes do produto e com base nos artefatos principais (subsistemas e produto final do sistema) ser realizada a ltima contagem de PF (atividade 8) para subsidiar os acertos finais com o cliente, antes de disponibilizar o produto e encerrar o processo de gesto do projeto. A contagem inicial em PCU, a projeo de PF e todas as contagens de PF realizadas durante o desenvolvimento do projeto, devem ser armazenadas em repositrios de cada organizao. Com base na contagem de diversos projetos possvel refinar a equao de relao entre PCU e APF e projetar PF com maior preciso para a organizao.

102

 &RQVLGHUDo}HV ILQDLV GR FDStWXOR


Este captulo apresentou um processo de gesto de estimativa de tamanho de software, definido de forma integrada com os processos de desenvolvimento e gesto de projetos de software. Para subsidiar este processo, foram realizadas as seguintes atividades: i) padronizao dos procedimentos de contagem da APF e PCU para projetos de software OO conforme a literatura; ii) aplicao dos procedimentos de contagem da APF e PCU em 19 projetos, sendo nove da academia e dez da indstria; iii) investigao da relao entre PCU e APF com base nos resultados da contagem dos projetos da academia e indstria; e iv) identificao das aes gerenciais a serem tomadas pelos gerentes de projeto quando o cronograma impraticvel de se realizar, est dentro do prazo ou est atrasado. Em relao aplicao dos procedimentos de contagem da APF e PCU nos projetos da academia e indstria, observou-se que para fazer uma contagem com mais preciso de fundamental importncia que o projeto seja bem documentado e que haja possibilidade de realizar entrevistas com o gerente ou membros da equipe envolvida no projeto para esclarecimento de dvidas ou complementao das informaes necessrias para a realizao da estimativa. Isto importante porque nem sempre todas informaes esto explcitas na documentao do software. Em alguns dos projetos contados detectou-se inconsistncia em relao aos casos de uso descritos no modelo de anlise e os realizados no modelo de projeto. Este tipo de inconsistncia dificulta a contagem e pode contribuir para uma estimativa imprecisa. Dessa forma, pode-se destacar que a aplicao da APF e PCU ajuda a determinar o nvel de qualidade e adequao da documentao do projeto. Portanto, recomendvel que a documentao seja mantida atualizada e consistente durante todo o processo de desenvolvimento do projeto. Ainda em relao documentao dos projetos, pode-se destacar que os diagramas e descrio de casos de uso, o diagrama de seqncia e os diagramas de anlise e projeto de classes so fundamentais para a realizao de estimativas com maior preciso porque esses diagramas fornecem informaes relevantes para a realizao das estimativas de tamanho. Quanto identificao das caractersticas tcnicas do sistema, observou-se uma certa dificuldade entre os gerentes com pouca experincia em desenvolvimento de software OO para

103

indicar os nveis de influncia dos fatores de ajustes tcnicos e ambientais no projeto conforme observadas por Anda et al.(2001). Alm dos pontos destacados acima, foram observados outros aspectos especficos contagem de PCU realizadas nos projetos da academia e indstria tais como: i) Os diagramas de caso de uso e respectivas descries quando elaboradas atravs de padres pr-definidos pela organizao e com base em um mesmo processo de desenvolvimento de software facilitam, o processo de contagem. ii) A identificao das transaes 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 transao entre diferentes contadores de uma mesma organizao. iii) iv) A realizao da estimativa em PCU rpida, exige muito pouco esforo e pode trazer muitos benefcios para a organizao j que realizada no incio do projeto. A preciso da estimativa em PCU vai depender da qualidade da anlise de requisitos, o que poder influenciar na estimativa realizada por qualquer mtodo usado na fase inicial do projeto. Devido a isso, de fundamental importncia que a estimativa inicial seja refinada ao longo do processo de desenvolvimento em APF como proposto neste trabalho. Em relao contagem de PF, as seguintes consideraes so relevantes: i) As classes e respectivos atributos responsveis pela realizao de cada transao devem ser descritos de forma explcita para facilitar a identificao da complexidade das funes transacionais, j que a complexidade depende do nmero 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 so gerados durante o desenvolvimento conforme j comprovado em experincias anteriores disponveis na literatura. A investigao da relao entre PCU e APF, foi realizada com base nos resultados da contagem dos projetos da academia e indstria. Esses resultados foram analisados e utilizados em testes estatsticos para identificar a equao de relao entre as duas mtricas. De acordo com os resultados obtidos nesses testes, podem-se fazer as seguintes consideraes:

104

i)

 3&8 para projetos da indstria comprovando a primeira suposio deste trabalho. ii) As equaes 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 mtricas pode gerar estimativa mais seguras, pois a estimativa realizada no incio 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 decises com maior segurana. iii) Recomenda-se que todos os resultados das estimativas e o histrico do projeto, incluindo as aes gerenciais utilizadas para ajustes no projeto, sejam armazenados em uma base de dados histrica para subsidiar a gesto de novos projetos e melhorar os processos de gesto de estimativa da empresa, o de gesto e desenvolvimento de projetos de software. Neste captulo, foi realizado ainda, um estudo para identificar as aes gerenciais a serem tomadas pelo gerente do projeto durante a execuo do processo de gesto de estimativas. Finalmente, considerando os procedimentos de contagem apresentados no captulo 2 e na seo 4. 3 deste captulo, a equao de relao encontrada entre a APF e PCU e as aes gerenciais identificadas foi definido o processo de gesto de estimativa de tamanho integrado com os processos de gesto e desenvolvimento de software conforme mostra a Figura 7.

descrita pelas equaes 3)

Para os projetos estudados foi constatado que a relao entre PF e PCU pode ser  3&8 para projetos da academia e 3)

105

&DStWXOR  &RQFOXVmR H SHUVSHFWLYDV IXWXUDV


No mercado competitivo atual, uma preocupao constante das organizaes o cumprimento de cronogramas e o custo efetivo de seus projetos de desenvolvimento de software. Todas estas caractersticas dependem de um gerenciamento adequado do projeto. Nesse gerenciamento de fundamental importncia que o plano efetivo do projeto se baseie em estimativas mais precisas de tamanho, uma vez que, o tamanho de um projeto de software uma das primeiras estimativas a ser realizada, pois dessa dimenso depende a definio do esforo, custos e prazos necessrios para a definio do plano de desenvolvimento do software. Diante desta necessidade, este trabalho teve como objetivo propor aos gerentes uma melhor forma de estimar, revisar e recalcular o tamanho do projeto medida que novos artefatos estejam disponveis durante o processo de desenvolvimento do projeto de software orientado a objetos. Para atender a este objetivo foram definidos os seguintes objetivos especficos: i) ii) iii) iv) Estudar as principais caractersticas da APF e PCU e aplic-las em projetos de software orientados a objetos; Investigar a existncia de relao entre as mtricas APF e PCU; Definir uma equao que descreva esta relao e possa ser usada para projetar PF a partir de PCU; Identificar as aes gerenciais a serem tomadas pelo gerente durante o controle e acompanhamento do projeto. Para atender o objetivo i) foram estudadas as principais caractersticas da APF e PCU e padronizados os procedimentos de contagem da APF e PCU para projetos de software OO. Posteriormente, estes procedimentos foram aplicados em 19 projetos de software OO desenvolvidos pela academia e indstria, buscando a relao entre as estimativas de APF e PCU. De acordo com os resultados obtidos atravs da aplicao da APF e PCU em projetos OO da academia e da indstria e com a investigao da relao entre PCU e APF foram atendidos os objetivos ii) e iii) e aceitas s suposies inicialmente definidas neste trabalho: i) h uma relao linear entre PF e PCU, e a equao que descreve essa relao pode ser utilizada para projetar PF a partir de PCU logo no incio do projeto; e ii) a APF e PCU podem ser utilizadas de forma combinada.

106

da academia (3)  3&8) difere daquela que descreve a mesma relao em projetos da indstria (3)  3&8). Para atender o objetivo iv) foi realizado um estudo entre 37 gerentes de projeto da indstria da academia visando identificar as aes gerenciais a serem tomadas pelo gerente,

Foi constatado tambm que a equao que descreve a relao entre PF e PCU nos projetos

quando o cronograma for impraticvel de se realizar, tiver dentro do prazo mas precisa ser controlado e quando tiver atrasado. Os resultados deste estudo foram apresentados no captulo 4, seo 4.5. Finalmente, com base nos resultados acima foi proposto um processo de gesto de estimativa de tamanho de forma integrada com os processos de desenvolvimento e gesto de projetos de software. Dessa forma, o gerente poder estimar, revisar e recalcular o tamanho do projeto medida que novos artefatos estejam disponveis durante o processo de desenvolvimento do projeto de software orientado a objetos. Portanto, como contribuies deste trabalho, podem ser destacadas: i) a proposio de um processo de gesto de estimativa de tamanho de projetos de software relacionado com os processos de desenvolvimento e gesto de projeto de software e combinando o uso da APF e PCU, nas fases ii) do processo de desenvolvimento do projeto nas quais estas mtricas tm aplicao mais adequada; a identificao da equao de relao entre PF e PCU para a academia e indstria, o que indica que cada organizao pode encontrar a equao de relao entre estas mtricas com base em dados de projetos reais desenvolvidos internamente e pode usar a equao e o resultado da contagem de PCU para projetar PF no incio do projeto e assim usar a APF e PCU de forma combinada. iii) a lista de aes a serem tomadas pelos gerentes durante a execuo e controle do projeto. Assim, o gerente poder usar o processo de gesto de estimativa de tamanho conforme proposto, de forma relacionada com os processos de desenvolvimento e gesto de projetos, especialmente, a gesto de tempo (cronograma) para garantir maior preciso nas estimativas de tamanho e, conseqentemente, nas estimativas de custo, esforo e produtividade da equipe. Dessa forma, o gerente poder gerenciar o projeto de forma mais eficiente, tomando decises com base

107

nas aes gerenciais identificadas neste estudo e garantindo melhoria dos processos, da qualidade do produto e da satisfao do cliente. Os resultados deste trabalho indicam vrias 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 concludo. Com base nos resultados dessas estimativas, gerar nova equao de relao para validar a equao gerada neste trabalho quando os referidos projetos ainda estavam em desenvolvimento; ii) implantar o processo de gesto de estimativa de tamanho de projetos em uma das empresas que participaram desta pesquisa, para verificar a adequao da equao de relao encontrada entre a APF e CPU na projeo de PF de novos projetos e das aes gerenciais indicadas neste trabalho; iii) iv) v) definir uma ferramenta para apoiar o processo e garantir o reuso do histrico das estimativas realizadas durante o processo de desenvolvimento do projeto; definir como o processo de gesto de estimativa de tamanho pode ser realizado iterativamente considerando o desenvolvimento dirigido por casos de uso; verificar a possibilidade de contar as funes transacionais atravs dos mtodos das classes definidos no diagrama de classes, conforme proposto por Minkiewicz (1997) citado por Caldiera, et al. (1998)

108

5HIHUrQFLDV ELEOLRJUiILFDV
ABDEL-HAMID, T. Software project control: an experimental investigation of judgment with 1993. p. 603 612. ABRAN, A. et al. Functional size measurement methods: COSMIC-FFP: design and field trials. In: FESMA-AEMES Software Measurements Conference. 2000. AGUIAR, M. Pontos de funo ou pontos de caso de uso? Como estimar projetos orientados a objetos. 'HYHORSHUV 0DJD]LQH V. 7, n. 77. Jan., 2003. ANDA, B. Comparing effort estimates based on Use Case Points with expert Estimates. 2002. 13 p. ________; et al. Estimating software development effort based on use cases: experiences from 3URFHHGLQJV Toronto, Oct. 1 5, 2001, p. 487 502. industry. In: International Conference on the Unified Modeling Language (UML2001), 4. fallible information ,((( 7UDQVDFWLRQV RQ 6RIWZDUH (QJLQHHULQJ. V. 19, n. 6, June,

(PSLULFDO $VVHVVPHQW LQ 6RIWZDUH (QJLQHHULQJ ($6(   Keele, UK, April, 8 10,

ARNOLD, M.; PEDROSS, P. Software size measurement and productivity rating in a large-scale software development department. In: International Conference on Software Engineering, 20. 3URFHHGLQJV 1998. p. 490 493. Disponvel em:http://dlib2.computer.org/conferen/icse/8368/pdf/83680490.pdf? Acesso em 25/02/03. A ROLE- BASED guide to the Rational Unified Process. March, 2003. Ch. 14, p. 271. ASSOCIAO BRASILEIRA DE NORMAS TCNICAS (ABNT). 1%5 ,62,(& : Gesto da qualidade: diretrizes para a qualidade de gerenciamento de projetos. Rio de ________. 1%5 ,62,(& : Tecnologia de Informao: processos do ciclo de vida de software. Rio de Janeiro:ABNT. 1998. 38 p. BASILI. V.; CALDIERA, G.; ROMBACH, H. (QF\FORSpGLD RI 6RIWZDUH (QJLQHHULQJ. V. 2, 1994. p. 527 532. Goal Question Metric paradigm. In: Janeiro:ABNT. 2000. 17 p.

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. 7KH XQLILHG PRGHOLQJ ODQJXDJH XVHU JXLGH Reading: ADDISON-WESLEY. 1999. 482p. CALDIERA, G et al. Definition and experimental evaluation of Function Points for objectoriented systems. In: International Symposium on Software Metrics , 5. 3URFHHGLQJV

109

IEEE. March 20 21, 1998, Bethesda, Maryland. P. 167 179. Acesso em 10/02/03 CARBONE, M.; SANTUCCI,G. )DVW Disponvel em: http://dlib2.computer.org/conferen/ metrics/9201/ pdf/92010167.pdf? 6HULRXV UML based metrics for effort estimation.S. d.

CUNHA, G.; ALMEIDA, E. Estimativa de projetos com base em Casos de Uso. In: SIMPSIO 2003, Recife. $QDLV Recife, CenPRA/SENAC. 2003. p. 53 - 60. INTERNATIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE (SIMPROS), 4,

DAMODARAN, M; WASHINGTON, A. Estimation using use case points. &RPSXWHU 6FLHQFH 3URJUDP Texas Victoria: Acesso em 22/09/2003. DEKKERS, C. Measuring the logical or functional size of software projects and software ________; McQUAID. P. The dangers of using software metrics to (Mis)Manage. ,((( Mar./Apr.2002. p. 24 30. ________. Uses Cases and Function Points Wheres the Fit? Jan.1999.6 p. In: 0HWULFV 6WUDWHJLHV. application. ,62 %8//(7,1 May, 2003. p. 10 13. University of Houston. S.d. 4 p. Disponvel em: http://bfpug.com.br/Artigos/UCP/Damodaran-Estimation_Using_Use_Case_Points.pdf

FARIAS, L. D. 3ODQHMDPHQWR GH ULVFRV HP DPELHQWHV GH GHVHQYROYLPHQWR GH VRIWZDUH RULHQWDGRV D RUJDQL]DomR. Rio de Janeiro, UFRJ/COPPE. Tese (Mestrado). FEITOSA, C.; JANSEN, S. Processo de estimativa e acompanhamento de tamanho e esforo para o ProSCes. In: Encontro da Qualidade e produtividade em software (EQPS), 2003, Fortaleza. Fortaleza, MCT. 10 slides. Disponvel em: http://www.google.com.br. Acesso FENTON, N., NEIL, M. Software Metrics: Roadmap. )XWXUH RI 6RIWZDUH (QJLQHHULQJ _______; PFLEEGER, S. 6RIWZDUH PHWULFV a rigorous & practical approach. Boston: PWS _______. 6RIWZDUH 0HWULFV a rigorous approach. Chapman & Hall; 1991. 3RLQW $QDO\VLV 1997. 11 p. Acesso em 10/02/2003.Disponvel em: http://dlib2.computer.org/conferen/tools/8383/pdf/83830192.pdf? Publishing Company, 1997. 638 p. /LPHULFN ,UHODQG $&0 p. 359-370, 2000. em 19/12/2003.

FETCKE, T.; ABRAN, A; NGUYEN, T. 0DSSLQJ WKH 22-DFREVRQ DSSURDFK LQWR )XQFWLRQ

110 FREUND, R. & LITTELL, R. 6$6 6\VWHP IRU UHJUHVVLRQ: SAS series in statistical applications. FUREY, S. Why we should use Function Points. ,((( Mar./April, 1997. 2 p. software projects. Addison-Wesley: EUA. 2000. 363 p. 2.ed. Cary: SAS Institute Inc. 1991. 210p.

GARMUS, D., HERRON, D. )XQFWLRQ 3RLQW $QDO\VLV Measurement Practices for successful

GUPTA R.; GUPTA S. Object Point Analysis. In: IFPUG Conference, 1996. 3URFHHGLQJV HAZAN, C. $QiOLVH GH 3RQWRV SRU )XQomR: uma abordagem gerencial. SERPRO. 1999. 1 v. Dallas, 1996. Rio de Janeiro,

IFPUG. International Function Point Users Group. )XQFWLRQ 3RLQW &RXQWLQJ 3UDFWLFHV Case _______. )XQFWLRQ 3RLQW &RXQWLQJ 3UDFWLFHV 0DQXDO Release 4.1. Ohio: IFPUG. 2000. 1 v. INTERNATIONAL SOFTWARE BENCHMARKING STANDARDS GROUP (ISBSG). INTERNATIONAL STANDARD ORGANIZATION (ISO).,62,(& '75 :Software ________. ,62,(& 75  Information technology: Software process assessment part 1: concepts and introductory guide. 1998. Engineering:Guide for the application of ISO/IEC 12207 to project management.1999.31 p. Benchmarking Repository, Release 6. ISBSG. Abr, 2002. Study 3 Analysis, Construction. Release 2.0. Princeton Junction: IFPUG. 2001. 246 p.

JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. 8QLILHG 6RIWZDUH 'HYHORSPHQW 3URFHVV. Addison-Wesley, 1996. JOHNSON, D.; BRODMAN, J. Applying CMM project planning practices to diverse JONES, C. Software Challenges: )XQFWLRQ SRLQW a new way of looking at tools. Computer, August, 1994. p. 66 67. Acesso em 24/02/03.Disponvel em: JORGENSEN, M.; INDAHL, U.; SJOBERG, D. (IIRUW HVWLPDWLRQ: software effort estimation JURISON, J. Software project management: the manager s view. &RPPXQLFDWLRQV RI WKH KARNER, G. 8VH &DVH 3RLQWV: resource estimation for Objectory projects. Objective Systems SF AB (copyright owned by Rational/IBM), 1993. DVVRFLDWLRQ IRU ,QIRUPDWLRQ 6\VWHPV V. 2, article 17, Sep. 1999. 56 p. by analogy and regression toward the mean. 18p. http://dlib2.computer.org/co/books/co1995/pdf/rx102.pdf? environments. IEEE Software. July/Aug. 2000. p. 40 47.

111 KITCHENHAM, B. Counterpoint: the problem with Function Point. ,((( 6RIWZDUH 1997 2 p. Acesso em 10/02/03.Disponvel em: http://dlib2.computer.org/so/books/so1997/pdf/s2029.pdf? KUSUMOTO, S; INOUE, K.; KASIMOTO, T. Function Point Measurement for Object-Oriented Requirements Specification. In: Annual International Computer Software and Aplications Conference, 10/02/03. LONGSTREET, 24. 3URFHHGLQJV IEEE, 2000. 6p. Acesso em: http://dlib2.computer.org/conferen/COMPSAC/0792/pdf/07920543.pdf?

March,

D. )XQGDPHQWDOV RI )XQFWLRQ 3RLQW $QDO\VLV. Blue Springs: Longstreet

Consulting Inc., 2002. Disponvel em: http://www.ifpug.com/Articles/default.htm. Acesso ________. 8VH &DVH DQG )XQFWLRQ 3RLQW Blue Springs: Longstreet Consulting Inc., 2000. MARKUS, R. (OHPHQWRV GH HVWDWtVWLFD DSOLFDGD. Porto Alegre: UFRGS, 1974. 327p. makers. Boston: Addison-Wesley. 2001. 277p. 1999. Disponvel em: http://www.ifpug.com/fpafund.htm. Acesso em 04/04/03. em 01/04/03.

McGARRY, J. et al. 3UDFWLFDO VRIWZDUH PHDVXUHPHQW objective information for decision

McPHEE, C. 6(1* : Software process management: software size estimation. University of Calgary. 19/09/03 MCT. MINISTRIO DE CINCIA E TECNOLOGIA. Notcias de TI: mercado de software crescer 5,3% em 2004. Notcia publicada na Computerworld em 12/11/03. 2003a. Acesso em 06/01/2004. Disponvel em: http://www.mct.gov.br/Temas/info/Imprensa/Noticias_Anteriores/Noticias_2003/Software _2003.htm _______. Notcias de TI: uma vitria do software brasileiro. Notcia publicada no Estado em 29/09/03. 2003b. Acesso em 06/01/2004. Disponvel em: http://www.mct.gov.br/Temas/info/Imprensa/Noticias_Anteriores/Noticias_2003/Software _______. 4XDOLGDGH H SURGXWLYLGDGH QR VHWRU GH VRIWZDUH EUDVLOHLUR Braslia: Ministrio de Cincia e Tecnologia. Secretaria de Poltica de Informtica. 2002. 258p. (n. 4). _2003.htm. 11p. Disponvel em: http://sern.ucalgary.ca/~cmcphee/SENG621/Software_Size_Estimation.html Acesso em

112

MISIC, V.; TESIC, D. Downsizing the estimation of software quality: a small object-oriented

case study. In: Technology of Object-Oriented Languages and Systems. 3URFHHGLQJV S.d.

10 p. Disponvel em: http://dlib2.computer.org/conferen/tools/9096/pdf/90960308.pdf? MLLER, K.H.; PAULISH, D.J.; 6RIWZDUH 0HWULFV a practioner' guide to improved product s MURTHI, Sanjay. Preventive risk management for software projects. ,((( ,7 3UR Sep./Oct., NETER, J; WASSERMAN, W; KUTNER, M. $SSOLHG OLQHDU UHJUHVVLRQ PRGHOV. Homewood: NETER, J; WASSERMAN, W. $SSOLHG OLQHDU VWDWLVWLFDO PRGHOV Homewood, Illinois: Richard PAULK, M. et al. 7KH FDSDELOLW\ PDWXULW\ PRGHO: guidelines for improving the software process. Boston: Addison Wesley. 2000. 441p. Carnegie Mellon University: Software PITTMAN, Matthew. Lessons learned in managing object-oriented development. ,((( PMBOK. 3URMHFW 0DQDJHPHQW %RG\ RI .QRZOHGJH Belo Horizonte: PMIMG, 2000 (edio PRESSMAN, R. (QJHQKDULD GH 6RIWZDUH 5. ed. Rio de Janeiro: McGraw-Hill, 2002. 843 p. (GJH 2002. Disponvel em: traduzida pelo PMI/MG). 6RIWZDUH. Jan. 1993, 43 53 p. Engineering Institute. D. Irvin, 1974. IRWIN. 1989. 667 p. il. 2002. p. 9 15. development. IEEE Computer Society Press, Chapmam & Hall; 1993 Acesso em: 25/02/03.

PROBASCO, L. Dear Dr. Use Case: what about Function Point and Use Cases? 7KH 5DWLRQDO

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 computer.org/conferen/apaqs/0825/pdf/08250121.pdf? Acesso em 10/02/03. RATIONAL UNIFIED PROCESS. development teams 2001a Rational. 2001a. Acesso em 25/01/04. http:///www.rational.com/media/whitepapers/rup_bestpractices.pdf. Quality Software, 1. 3URFHHGLQJV IEEE, 2000. 6 p. Disponvel em: http://dlib2. 5DWLRQDO 8QLILHG 3URFHVV best practices for software Disponvel em:

113 BBBBBBBB 5DWLRQDO 6RIWZDUH &RUSRUDWLRQ 1997-2000, 2001b (www.rational.com) 23.

REEL, J. S. Critical success factors in software projects. ,((( 6RIWZDUH May/June, 1999 p. 18 RIBU, K. (VWLPDWLQJ REMHFWRULHQWHG VRIWZDUH SURMHFWV ZLWK XVH FDVHV. Oslo: University of ROSS, M. Size does matter: continuous size estimating and tracking. 4XDQWLWDWLYH 6RIWZDUH SCHNEIDER, G.; WINTERS, J. Use case and project plan. In: ----------. $SS\LQJ XVH FDVHV a SMITH, J. 7KH HVWLPDWLRQ RI HIIRUW EDVHG RQ 8VH &DVHV Rational software white paper. SMITH & CODY, R. $SSOLHG VWDWLVWLFV DQG WKH 6$6 SURJUDPPLQJ ODQJXDJH. 3.ed. New York: SOLINGEN, R.; BERGHOUT, E. 7KH *RDO4XHVWLRQ0HWULF PHWKRG: a practical guide for SYMONS, C. R. Function Point Analysis: difficulties and improvements. ,((( 7UDQVDFWLRQV RQ 6RIWZDUH (QJLQHHULQJ V. 14, n. 1, Jan. 1988. 11p. Disponvel em: http://dlib2.computer.org/ts/ books/ts1988/pdf/e0002.pdf Acesso em 10/02/03. TICHENOR, C. B. The internal revenue service function point analysis program: a brief. In: 591 592. Disponvel em: http://dlib2.computer.org/ conferen/ Intenational Computer Software and Application Conference, 21. 3URFHHGLQJV 1997. p. quality improvement of software development. London: McGraw-Hill. 1999. 199p. North-Holland. 1991. 443p. Cupertino: Rational Software. 1999. 15 p. practical guide. 2. ed. New York: Addison Weslwy, 2001. captulo 10, p. 143 159. 0DQDJHPHQW Disponvel em: http://www.qsm.com. Acesso em 19/09/03. s.d . 16 p. Oslo, 2001.132 p. Tese (Mestrado Department of Informatics)

THOMSETT, Rob. ([WUHPH SURMHFW PDQDJHPHQW executive report. V. 2, n. 2, 2002. 32 p. Disponvel em: http://www.cutter.com/consortium. UEMURA, T.; KUSUMOTO, S.; INOUE, K. Function point measurement tool for UML design 62 69. Disponvel em: http://dlib2. computer. VALENA, A. (VWLPDWLYD GH HVIRUoR GH VRIWZDUH RULHQWDGR D REMHWRV. Recife. 2003.43 p. Academic Publisheres. 2000. 204 p. Org/conferen/metrics/0403/pdf/04030062.pdf? Acesso em 10/02/03. specification. In: International Symposium on Software Metrics , 6. $QDLV IEEE, 1999, p.

compsac/8105/pdf/81050591.pdf? Acesso em 25/02/03.

WOHLIN et al. ([SHULPHQWDWLRQ LQ VRIWZDUH HQJLQHHULQJ an introduction. Boston: Kluwer

114

$SrQGLFH $  &DUDFWHUtVWLFDV JHUDLV H DPELHQWDLV TXH LQIOXHQFLDP QR VLVWHPD

$SrQGLFHV

Este questionrio visa identificar o nvel de influncia das caractersticas tcnicas, de acordo com a APFIFPUG (2001) e PCU- KARNER (1993), e das caractersticas ambientais propostas por KARNER (1993) em projetos de desenvolvimento de software Orientado a Objetos. &$5$&7(5,=$d2 '2 *(5(17( '2 352-(72 28 0(0%52 '$ (48,3( 1RPH 2SFLRQDO  LQG~VWULD UHD GH $WXDomR (PDLO 2SFLRQDO  DFDGHPLD

Gerente de TI Gerente de projeto Membro de projeto Consultor/Contador Doutorado Mestrado

)RUPDomR Nvel e rea ( ) Eng de Software ( ) Gesto de TI e do Conhecimento

( ) Outro ( ) Outro

([SHULrQFLD Tempo de atuao em gesto de projetos Nmero de projetos gerenciados

Professor Pesquisador Aluno de graduao Consultor/Contador

( (

) anos ) projetos

Especializao ( ) Anlise de Sistemas ( ) Outro Graduao Certificao ( ) Cincia da Computao ( ) Outro ( ) IFPUG ( ) PMI

Experincia em gesto de estimativas: (tempo, riscos, recursos, custos, etc.) ( ) Alta ( ) Mdia ( ) Baixa ( ) Nenhuma

7tWXOR GR SURMHWRVLVWHPD
,16758d(6

Assinale o grau de influncia de cada caracterstica abaixo no projeto ou sistema de acordo com a escala de 0 a 5. Aps responder as questes abaixo encaminhe o arquivo com suas respostas para o seguinte e-mail: edmeia.andrade@embrapa.br ou edmeiaandrade@brturbo.com .  &RPXQLFDomR GH GDGRV Os dados e as informaes de controle utilizados na aplicao so enviados ou recebidos atravs de recursos de comunicao de dados. 0 ( ) O processamento da aplicao puramente EDWFK ou executado em um PC isolado. 1 ( ) A aplicao EDWFK mas tem entrada de dados remota ou impresso remota. 2 ( ) A aplicao EDWFK mas tem entrada de dados remota e impresso remota. 3 ( ) Captura de dados RQOLQH via terminal de vdeo ou via um processador IURQWHQG, para alimentar processos EDWFK ou sistemas de consultas (4XHU\ 6\VWHPV). 4. ( ) Mais que um IURQWHQG, mas a aplicao suporta apenas um tipo de protocolo de comunicao. 5. ( ) Mais que um IURQWHQG e a aplicao suporta mais de um tipo de protocolo de comunicao.

&$5$&7(567,&$6 7e&1,&$6 3523267$6 3(/$ $3) ,)38* 

 3URFHVVDPHQWR GLVWULEXtGR Dados ou processamento distribudo entre vrias unidades de processamento CPU

115

0 ( ) A aplicao no auxilia na transferncia de dados ou processamento entre as CPUs da instalao. 1 ( ) A aplicao prepara dados para o usurio final processar em outra CPU da instalao. Por exemplo, planilhas eletrnicas ou gerenciadores de banco de dados de PC. 2 ( ) Os dados so preparados para transferncia, transferidos e processados em uma outra CPU da instalao (mas NO para processamento pelo usurio final como visto no item 1). 3 ( ) Processamento distribudo e transferncia de dados RQOLQH apenas em uma direo. 4. ( ) Processamento distribudo e transferncia de dados RQOLQH em ambas direes. 5 ( ) As funes de processamento so executadas dinamicamente na CPU mais apropriada.

 'HVHPSHQKR Identifica os objetivos de SHUIRUPDQFH da aplicao estabelecidos e aprovados pelo usurio 0 ( ) Nenhuma exigncia especial de SHUIRUPDQFH foi fixada pelo usurio. 1 ( ) Requisitos de SHUIRUPDQFH foram estabelecidos e revisados, mas nenhuma ao especial foi necessria. 2 ( ) O tempo de resposta crtico durante as horas de pico. O intervalo de tempo limite (GHDGOLQH) do processamento sempre para o prximo dia til. Nenhuma considerao especial para utilizao de CPU foi requerida. 3 ( ) O tempo de resposta crtico durante todo o horrio de utilizao. Os requisitos de prazo de processamento com outros sistemas so limitantes. No foi necessrio nenhum procedimento especial para utilizao de CPU. 4. ( ) Os requisitos de SHUIRUPDQFH estabelecidos pelo usurio so rigorosos o bastante para requerer tarefas de anlise de SHUIRUPDQFH na fase de anlise e projeto da aplicao. 5 ( ) Alm do descrito no item 4, ferramentas de anlise de SHUIRUPDQFH foram usadas nas fases de projeto, desenvolvimento e/ou implementao a fim de proporcionar a SHUIRUPDQFH estabelecida pelo usurio.

 8WLOL]DomR GH HTXLSDPHQWR H necessidade de se fazer consideraes especiais no projeto do sistema para que a configurao do equipamento no fique sobrecarregada. 0 ( ) No h restries operacionais explcitas ou implcitas. 1 ( ) Existem restries operacionais, mas so menos restritivas do que aplicaes tpicas. Nenhum esforo extra necessrio para suplantar as restries. 2 ( ) Algumas consideraes sobre tempo e segurana so necessrias. 3 ( ) Necessidades especiais de processador para uma parte especfica da aplicao. 4 ( ) Restries operacionais estabelecidas requerem ateno especial a nvel de processador central ou processador dedicado para executar a aplicao. 5 ( ) Alm do descrito acima, existem sobrecargas a nvel das unidades de processamento (CPUs) distribudas da instalao.  9ROXPH GH WUDQVDo}HV alto e tem influncia no projeto, desenvolvimento, implantao e manuteno da aplicao. 0 ( ) Nenhum perodo de pico de transaes esperado. 1 ( ) Picos de transaes mensais, quadrimestrais, sazonais e anuais so esperados. 2 ( ) Picos semanais de transaes so esperados. 3 ( ) Picos dirios de transaes so esperados. 4 ( ) Altos volumes de transaes foram fixados pelo usurio para a aplicao, o que fora a execuo de tarefas de anlise de performance na fase de projeto da aplicao. 5 ( ) Requer o uso de ferramentas de anlise de performance nas fases de projeto, desenvolvimento e/ou implantao, alm das consideraes acima.  (QWUDGD GH GDGRV 2QOLQH A aplicao possui funes que fornecem entrada de dados e informao de controle RQOLQH 0 ( ) Todas as transaes so processadas em modo EDWFK 1 ( ) 1% a 7% das transaes so entradas de dados interativas. 2 ( ) 8% a 15% das transaes so entradas de dados interativas. 3 ( ) 16% a 23% das transaes so entradas de dados interativas. 4. ( ) 24% a 30% das transaes so entradas de dados interativas. 5. ( ) Mais de 30% das transaes so entradas de dados interativas.  (ILFLrQFLD GR XVXiULR ILQDO As funes RQOLQH fornecidas enfatizam um projeto da aplicao voltado para a eficincia do usurio final.

116

Menus Documentao/Help 2QOLQH Movimento automtico do cursor Movimento de Tela (VFUROOLQJ) vertical e horizontal Impresso remota (via transaes RQOLQH) Teclas de Funo pr-definidas Execuo de jobs EDWFK a partir de transaes RQOLQH Seleo de dados da tela via movimentao do cursor Uso intenso de vdeo reverso, brilho intensificado, sublinhado, cores e outros recursos de vdeo Documentao de transaes RQOLQH via KDUG FRS\ Interface para mouse 3RSXS Windows O mnimo possvel de telas para executar as funes do negcio Fcil navegao entre telas (por exemplo, atravs de teclas de funo) Suporte bilnge (suporta dois idiomas, contar como quatro itens) Suporte multilinge (suporta mais de dois idiomas, contar como seis itens) 0 ( ) A aplicao no 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 no h nenhum requisito do usurio relacionado eficincia. 4. ( ) Apresenta 6 ou mais dos itens acima, e os requisitos estabelecidos para eficincia do usurio so rigorosos o suficiente para que a fase de projeto da aplicao inclua fatores para: minimizar a digitao, maximizar os GHIDXOWV, utilizar WHPSODWHV etc. 5. ( ) Apresenta 6 ou mais dos itens acima, e os requisitos estabelecidos para eficincia do usurio so rigorosos o suficiente para que seja necessrio o uso de ferramentas e processos especiais para demonstrar que os objetivos de eficincia foram alcanados.  $WXDOL]DomR RQOLQH A aplicao possibilita a atualizao RQOLQH dos Arquivos Lgicos Internos. 0 ( ) Nenhuma atualizao. 1 ( ) Atualizao RQOLQH de 1 a 3 arquivos de controle. O volume de atualizaes baixo e a recuperao de dados simples. 2 ( ) Atualizao RQOLQH de 4 ou mais arquivos de controle. O volume de atualizaes baixo e a recuperao de dados simples. 3 ( ) Atualizao RQOLQH da maioria dos Arquivos Lgicos Internos. 4. ( ) Alm dos itens anteriores, a proteo contra perda de dados essencial e foi especificamente projetada e codificada no sistema. 5. ( ) Alm dos itens anteriores, altos volumes de dados trazem consideraes sobre custo para o processo de recuperao. Exigem procedimentos de recuperao totalmente automatizados com a mnima interveno do operador.

 3URFHVVDPHQWR FRPSOH[R Pode ser dividido nas seguintes categorias:


0 1 2 3 4 5

( ( ( ( ( (

) ) ) ) ) )

Processamento especial de auditoria e/ou processamento especial de segurana. Processamento lgico extensivo. Processamento matemtico extensivo. Grande quantidade de processamento de excees, resultante de transaes incompletas que necessitam de reprocessamento. Por exemplo: transaes incompletas de ATMs causadas por interrupes de comunicao, valores de dados ausentes ou validaes de erros. Processamento complexo para manipular mltiplas possibilidades de entrada/sada. Por exemplo: mltiplos meios e independncia de equipamentos. No apresenta nenhum dos itens acima. Apresenta um dos itens acima. Apresenta dois dos itens acima. Apresenta trs dos itens acima. Apresenta quatro dos itens acima. Apresenta todos os itens acima.

117
 5HXWLOL]DomR GH FyGLJR A aplicao e o seu cdigo foram especificamente projetados, desenvolvidos e suportados para serem reutilizados em outras aplicaes. 0 ( ) No apresenta cdigo reutilizvel. 1 ( ) O cdigo reutilizvel usado somente dentro da prpria aplicao. 2 ( ) Menos de 10% da aplicao foi feita, levando-se em conta a sua utilizao por outras aplicaes. 3 ( ) 10% ou mais da aplicao foi feita, levando-se em conta a sua utilizao por outras aplicaes. 4. ( ) A aplicao foi projetada e documentada para facilitar a reutilizao de cdigo e a aplicao customizada pelo usurio a nvel do cdigo fonte. 5. ( ) A aplicao foi projetada e documentada para facilitar a reutilizao de cdigo e a aplicao customizada para uso atravs de parmetros que podem ser atualizados pelo usurio.  )DFLOLGDGH GH LPSODQWDomR Um plano de implantao e converso de dados e/ou ferramentas de converso de dados foi preparado e testado durante a fase de testes dos sistemas. 0 ( ) Nenhuma considerao especial foi feita pelo usurio e nenhum procedimento especial foi requerido para a implantao. 1 ( ) Nenhuma considerao especial foi feita pelo usurio, mas um procedimento especial foi requerido para a implantao. 2 ( ) Requisitos de implantao e converso de dados foram fixados pelo usurio, e roteiros de implantao e converso de dados foram preparados e testados. O impacto da converso de dados no projeto no considerado importante. 3 ( ) Requisitos de implantao e converso de dados foram fixados pelo usurio e roteiros de implantao e converso de dados foram preparados e testados. O impacto da converso de dados no projeto considerado importante. 4. ( ) Alm do descrito no item 2, ferramentas automatizadas de implantao e converso de dados foram preparadas e testadas. 5. ( ) Alm do descrito no item 3, ferramentas automatizadas de implantao e converso de dados foram preparadas e testadas.  )DFLOLGDGH RSHUDFLRQDO  Procedimentos efetivos de inicializao, EDFNXS e recuperao foram desenvolvidos e testados. A aplicao minimiza a necessidade de atividades manuais, tais como montagem de fitas magnticas, manuseio de formulrios e interveno manual do operador. 0 ( ) Nenhuma considerao especial sobre facilidade operacional, alm dos procedimentos normais de EDFNXS, foi feita pelo usurio. 1 ( ) Procedimentos eficientes de inicializao, EDFNXS e recuperao foram preparados, mas a interveno do operador necessria. 2 ( ) Procedimentos eficientes de inicializao, EDFNXS e recuperao foram preparados, mas nenhuma interveno do operador necessria (contar como dois itens). 3 ( ) A aplicao minimiza a operao de montagem de fitas magnticas. 4 ( ) A aplicao minimiza a necessidade de manuseio de formulrios. 5. ( ) A aplicao foi projetada para no precisar de interveno do operador no seu funcionamento normal. Apenas a inicializao e parada do sistema ficam a cargo do operador. A recuperao automtica de erros uma caracterstica da aplicao.  0~OWLSORV ORFDLV  A aplicao foi especificamente projetada, desenvolvida e suportada para ser instalada em mltiplos locais de uma organizao ou para mltiplas organizaes. 0 ( ) Nenhuma solicitao do usurio para considerar a necessidade de instalar a aplicao em mais de um local. 1 ( ) Necessidade de instalao em mltiplos locais foi levada em considerao no projeto do sistema e a aplicao foi projetada para operar somente em ambientes idnticos de hardware e software 2 ( ) Necessidade de instalao em mltiplos locais foi levada em considerao no projeto do sistema e a aplicao foi projetada para operar somente em ambientes similares de hardware e software 3 ( ) Necessidade de instalao em mltiplos locais foi levada em considerao no projeto do sistema e a aplicao foi projetada para operar inclusive em ambientes diferentes de hardware e/ou software. 4. ( ) Um plano de documentao e manuteno foi elaborado e testado para suportar a aplicao em mltiplos locais e a aplicao atende aos itens 1 e 2. 5. ( ) Um plano de documentao e manuteno foi elaborado e testado para suportar a aplicao em mltiplos locais e a aplicao atende ao item 3.  )DFLOLGDGH GH PXGDQoDV  A aplicao foi especificamente projetada, desenvolvida para suportar manuteno, visando facilidade de mudanas. Por exemplo:

118

capacidade de consultas/relatrios flexveis est disponvel dados de controle do negcio so agrupados em tabelas passveis de manuteno pelo usurio. 0 ( ) Nenhum requisito especial do usurio para projetar a aplicao, visando minimizar ou facilitar mudanas. 1 ( ) fornecido recurso da consulta/relatrios flexveis capaz de manipular solicitaes simples de consulta (TXHU\ UHTXHVWV). Por exemplo: lgica de DQGRU aplicada a somente um Arquivo Lgico Interno (contar como um item). 2 ( ) fornecido recurso de consulta/relatrios flexveis capaz de manipular solicitaes de consulta (TXHU\ UHTXHVWV) de mdia complexidade. Por exemplo: lgica de DQGRU aplicada a mais de um Arquivo Lgico Interno (contar como dois itens). 3 ( ) fornecido recurso de consulta/relatrios flexveis capaz de manipular solicitaes complexas de consulta (TXHU\ UHTXHVWV). Por exemplo: combinaes de lgica de DQGRU aplicadas a um ou mais Arquivos Lgicos Internos (contar como trs itens). 4 ( ) Dados de controle so mantidos em tabelas que so atualizadas pelo usurio atravs de processos RQOLQH e interativos, mas as alteraes s so efetivadas no prximo dia til. 5 ( ) Dados de controle so mantidos em tabelas que podem ser atualizadas pelo usurio atravs de processos RQ OLQH e interativos e as alteraes so efetivadas imediatamente (contar como dois itens)

2875$6 &$5$&7(567,&$6 7e&1,&$6 3523267$6 3(/2 .$51(5 

 )DFLOLGDGH GH LQVWDODomR Indica o nvel de preparao de procedimentos e ferramentas para instalao do sistema 0 ( ) Nenhuma considerao especial foi feita pelo usurio e nenhum procedimento especial foi requerido para a instalao. 1 ( ) Nenhuma considerao especial foi feita pelo usurio, mas um procedimento especial foi requerido para a instalao. 2 ( ) Requisitos de instalao foram fixados pelo usurio. 3 ( ) Requisitos de instalao foram fixados pelo usurio e roteiros de instalao foram preparados e testados. 4. ( ) Alm do descrito no item 2, ferramentas automatizadas de instalao foram preparadas e testadas. 5. ( ) Alm do descrito no item 3, ferramentas automatizadas de instalao foram preparadas e testadas.  3RUWDELOLGDGH  A aplicao foi especificamente projetada, desenvolvida e suportada para ser instalada em mltiplas plataformas (Windows, Unix, Linux, etc) 0 ( ) Nenhuma solicitao do usurio para considerar a necessidade de instalar a aplicao em mais de uma plataforma 1 ( ) Necessidade de instalao em mltiplas plataformas foi levada em considerao no projeto do sistema e a aplicao foi projetada para operar somente em ambientes idnticos de KDUGZDUH e software 2 ( ) Necessidade de instalao em mltiplas plataformas foi levada em considerao no projeto do sistema e a aplicao foi projetada para operar somente em ambientes similares de KDUGZDUH e software 3 ( ) Necessidade de instalao em mltiplas plataformas foi levada em considerao no projeto do sistema e a aplicao foi projetada para operar inclusive em plataformas diferentes. 4. ( ) Um plano de documentao e manuteno foi elaborado e testado para suportar a aplicao em mltiplas plataformas e a aplicao atende aos itens 1 e 2. 5. ( ) Um plano de documentao e manuteno foi elaborado e testado para suportar a aplicao em mltiplas plataformase a aplicao atende ao item 3.  $FHVVRV VLPXOWkQHRV FRQFRUUrQFLD Indica o volume de acesso simultneo a aplicao No esperado acesso simultneo So esperados acessos simultneos esporadicamente Acessos simultneos so esperados. Acessos simultneos so esperados diariamente Muitos acessos simultneos foram fixados pelo usurio para a aplicao, o que fora a execuo de tarefas de anlise de performance na fase de projeto da aplicao. 5 ( ) Requer o uso de ferramentas controle de acesso nas fases de projeto desenvolvimento e/ou implantao, alm das consideraes acima.  &DUDFWHUtVWLFDV HVSHFLDLV GH VHJXUDQoD Indica o nvel de segurana exigido pela aplicao 0 1 2 3 4 ( ( ( ( ( ) ) ) ) )

119

0 ( ) Nenhuma solicitao do usurio para considerar a necessidade de controle de segurana da aplicao 1 ( ) Necessidade de controle de segurana foi levada em considerao no projeto do sistema 2 ( ) Necessidade de controle de segurana foi levada em considerao no projeto do sistema e a aplicao foi projetada para ser acessada somente por usurios autorizados 3 ( ) Necessidade de controle de segurana foi levada em considerao no projeto do sistema e a aplicao foi projetada para ser acessada somente por usurios autorizados. O acesso ser controlado e auditado. 4. ( ) Um plano de segurana foi elaborado e testado para suportar o controle de acesso a aplicao 5. ( ) Um plano de segurana foi elaborado e testado para suportar o controle de acesso a aplicao e a auditoria  )DFLOLGDGHV HVSHFLDLV GH WUHLQDPHQWR Indica o nvel de facilidade de treinamento de usurios ( ) Nenhuma solicitao do usurio para considerar a necessidade de treinamento especial ( ) Necessidade de treinamento especial foi levada em considerao no projeto do sistema ( ) Necessidade de treinamento foi levada em considerao no projeto do sistema e a aplicao foi projetada para ser acessada com facilidade pelos usurios 3 ( ) Necessidade de treinamento especial foi levado em considerao no projeto do sistema e a aplicao foi projetada para ser utilizada por usurios de diversos nveis 4 - 5 ( ) Um plano de treinamento foi elaborado e testado para facilitar o uso da aplicao &$5$&7(567,&$6 $0%,(17$,6 3523267$6 3(/2 .$51(5   )DPLOLDULGDGH FRP R 3URFHVVR GH 'HVHQYROYLPHQWR GH 6RIWZDUH Indica a experincia da equipe com o processo/mtodo utilizado para desenvolvimento do projeto. 0 ( ) A equipe no familiar com o processo de desenvolvimento de software 1 ( ) A equipe tem conhecimento terico 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 experincia no uso do processo em diferentes projetos 5. ( ) Toda a equipe tem experincia no uso do processo em vrios projetos diferentes.  ([SHULrQFLD QD $SOLFDomR Indica a experincia com diferentes tipos de aplicao ou com o tipo de aplicao que est sendo desenvolvida. 0 ( ) Todos os membros da equipe so novatos 1 - 2 ( ) Poucos membros da equipe possuem alguma experincia (de 1 a 1 ano). Os outros so novatos. 3 ( ) Todos os membros tem mais de 1 ano de experincia 4 ( ) A maioria da equipe tem 2 anos de experincia 5. ( ) Todos os membros so experientes  ([SHULrQFLD FRP 22 QD /LQJXDJHP H QD 7pFQLFD GH 'HVHQYROYLPHQWR Mede a experincia da equipe com anlise e projeto OO, modelagem de casos de uso, classes e componentes. 0 ( ) A equipe no familiar com anlise e projeto OO. 1 ( ) Todos os membros tem menos de 1 ano de experincia. 2 3 ( ) Todos os membros tem de 1 a 1 ano de experincia 4 ( ) A maioria da equipe tem mais de 2 anos de experincia 5. ( ) Todos os membros so experientes ( mais de 2 anos)  &DSDFLGDGH GR /tGHU GH 3URMHWR Indica a experincia do lder com anlise de requisitos e modelagem. 0 ( ) O lder do projeto novato. 1 - 2 ( ) Possui experincia de poucos projetos 3 - 4 ( ) Pelo menos 2 anos de experincia com vrios projetos 5. ( ) Pelo menos 3 anos de experincia com projetos variados  0RWLYDomR Descreve a motivao total da equipe. 0 ( ) No motivada 1 - 2 ( ) Pouca motivada 3 - 4 ( ) A equipe est motivada para fazer um bom trabalho 5. ( ) A equipe est muito motivada e inspirada 0 1 2

 5HTXLVLWRV HVWiYHLV Mede o grau de mudana de requisitos e inseguranas sobre o significado dos requerimentos.

120

0 ( ) 1-2 ( ) 3-4( ) 5. ( )

 7UDEDOKDGRUHV FRP GHGLFDomR SDUFLDO Mede a estabilidade da equipe e a influencia do trabalho parcial na produtividade. 0 ( ) No tem membro com dedicao parcial 1 -2 ( ) Poucos membros (20%) trabalham em perodo parcial 3 -4 ( ) A metade dos membros da equipe trabalham em perodo parcial 5. ( ) Toda os membros da equipe trabalham em perodo parcial  'LILFXOGDGH GD /LQJXDJHP GH 3URJUDPDomR Indica a experincia com ferramentas primrias de desenvolvimento e com a linguagem de programao escolhida 0 ( ) Todos os membros da equipe so programadores experientes 1 ( ) A maioria dos membros da equipe possuem mais de 2 anos de experincia 2 ( ) Todos os membros tem mais de 1 ano de experincia 3 ( ) A maioria da equipe tem mais de 1 ano de experincia 4 ( ) poucos membros da equipe tem alguma experincia (1 ano). Os outros so novatos. 5. ( ) Todos os membros da equipe so novatos

Requisitos muito instveis com mudanas freqentes Requisitos instveis. Clientes demandam algumas mudanas realizadas em diversos intervalos Estabilidade global. Pequenas mudanas so necessrias Requisitos estveis ao longo do desenvolvimento

121

$SrQGLFH %  *HVWmR GH HVWLPDWLYDV HP SURMHWRV GH VRIWZDUH


Este questionrio visa a identificar as aes a serem tomadas pelo gerente de projeto em relao gesto de estimativa de projeto durante a sua execuo. A estimativa de tamanho realizada no incio do projeto atravs de Pontos de Caso de Uso (PCU) e Pontos de Funo (PF) refinada ao longo do desenvolvimento do projeto e comparada com a estimativa de tempo planejada atravs da definio do cronograma. Portanto, durante a gesto, torna-se necessrio identificar a situao real do projeto em relao ao tempo estimado, ou seja, se o cronograma est dentro do prazo ou atrasado. &$5$&7(5,=$d2 '2 *(5(17( '2 352-(72 1RPH 2SFLRQDO  UHD GH $WXDomR LQG~VWULD Gerente de TI Gerente de projeto Membro de projeto Gerente de estimativas de projeto Consultor externo ([SHULrQFLD 7HPSR GH DWXDomR HP JHVWmR GH SURMHWRV DQRV  ( ) 1 3 ( ) 3 5 ( ) 5 - 10 ( ) mais de 10 1~PHUR GH SURMHWRV JHUHQFLDGRV ( ) 1 3 ( ) 3 5 ( ) 5 - 10 ( ) mais de 10 Gesto de tempo de execuo de projetos: ( ) Alta ( ) Mdia ( ) Baixa ( ) Nenhuma (PDLO 2SFLRQDO  DFDGHPLD Professor Pesquisador Aluno de ps-graduao Gerente de estimativas de projeto Consultor externo )RUPDomR 1tYHO H UHD ( ) Doutorado ( )Eng de Software ( ) Outro

( ) Mestrado ( ) Gesto de TI e do ( ) Outro Conhecimento (em curso) ( )Especializao ( ) Anlise de Sistemas ( ) Outro ( )Graduao ( ) Cincia da Computao ( ) Outro ( ) Certificao: ( ) IFPUG ( ) PMI ( ) Outro

(GPpLD /HRQRU 3HUHLUD GH $QGUDGH e-mail HGPHLDDQGUDGH#EUWXUERFRP; HGPHLDDQGUDGH#HPEUDSDEU

&RQWDWR

$V Do}HV GH JHVWmR GH HVWLPDWLYD UHODFLRQDGDV QHVWH TXHVWLRQiULR HVWmR EDVHDGDV HP 35(660$1   30%2.  H -85,621  H RV IDWRV TXH SURYRFDP DWUDVR QR FURQRJUDPD IRUDP LGHQWLILFDGRV QR WUDEDOKR GH )DULDV  
,  3/$1(-$0(172 $o}HV UHFRPHQGDGDV HP XP FURQRJUDPD LPSUDWLFiYHO

Com base na lista de aes descritas abaixo, assinale com um X a coluna correspondente ao nvel de recomendao que voc considera mais adequado em relao s aes a serem adotadas quando a data de entrega do produto definida no planejamento impraticvel.  1mR UHFRPHQGDGD  3RXFR 5HFRPHQGDGD  5HFRPHQGDGD  0XLWR UHFRPHQGDGD Obs: Caso voc queira indicar outras aes relevantes, acrescente-a na lista abaixo e indique o nvel de recomendao correspondente.

$o}HV D VHUHP WRPDGDV TXDQGR R FURQRJUDPD p LPSUDWLFiYHO

19(/ '( 5(&20(1'$d2

122

1. Reunir-se com o cliente, apresentar a estimativa detalhada em relao ao esforo e a durao estimada para o projeto e negociar novo prazo. 2. Definir uma estratgia de desenvolvimento incremental que entregue a funcionalidade crtica na data prevista e adie as funes restantes. 3. Negociar o aumento do oramento e contratar mais recursos humanos apesar de que esta soluo pode comprometer a qualidade do produto. 4. Contratar consultoria especializada para resolver problemas tcnicos. 5. Substituir os tcnicos que no tem apresentado resultados satisfatrios. 6. Ignorar a realidade e esperar completar o prazo determinado no cronograma.
,,  $&203$1+$0(172 2 FURQRJUDPD HVWi QR SUD]R

1. Com base na lista de aes descritas abaixo, assinale com um X a coluna correspondente periodicidade em que voc tem realizado aes de acompanhamento e controle do cronograma:  1R LQtFLR GR GHVHQYROYLPHQWR  6HPDQDO  0HQVDO  $SyV R WpUPLQR GH FDGD IDVH GH GHVHQYROYLPHQWR  6HP SHULRGLFLGDGH GHILQLGD  1mR SUDWLFD HVWDV Do}HV Obs: Caso voc queira indicar outras aes relevantes, acrescente-a na lista abaixo e indique a periodicidade que a mesma realizada.

$o}HV D VHUHP WRPDGDV SDUD FRQWURODU R FURQRJUDPD 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 necessrio para implementar cada atividade.

3.Incluir reservas oramentrias para resolver problemas ou executar o plano de contingncia. 4. Identificar e documentar as restries no plano do projeto que limitaro a realizao das atividades e elaborar um plano de contingncia. 5. Verificar se todas as atividades e tarefas que visam alcanar o objetivo do projeto constam no cronograma e foram entendidas pela equipe. 6. Identificar se os marcos de referncia do projeto foram estabelecidos de modo que o progresso possa ser acompanhado. 7. Verificar se todo esforo e durao do projeto foram atribudos corretamente a cada atividade do cronograma. 8. Verificar se as interdependncias entre as atividades foram adequadamente indicadas. 9. Identificar questes que podem causar problemas futuros, providenciar aes corretivas e alertar a equipe do projeto. 10. Identificar as atividades que no so do projeto ou que dependem de fornecedores para serem executadas. 11. Identificar possveis mudanas que influenciam no cronograma (ex: na legislao, no escopo ou tecnologia). 12. Identificar e coordenar as atividades e tarefas realizadas em paralelo. 13. Identificar quais datas do cronograma foram alcanadas e quais no foram

123

14. Conduzir reunies peridicas para que cada membro do projeto possa relatar o progresso e os problemas atuais. 15. Analisar os relatrios de desempenho do projeto e avaliar os resultados das revises conduzidas ao longo do processo de desenvolvimento. 16. Atualizar o plano, os documentos tcnicos e informar a equipe e clientes. 17. Ter membros representativos nas reunies de revises tcnicas 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, difceis de serem substitudas ou est comprometido com outros projetos. 19. Controlar a produtividade da equipe. 20. Refinar as estimativas realizadas no incio do projeto durante todo o ciclo de desenvolvimento do projeto. 21. Contratar consultoria externa para auxiliar no uso da tecnologia. 22. Facilitar a comunicao entre os membros da equipe.
,,  $&203$1+$0(172 2 FURQRJUDPD HVWi DWUDVDGR

1. A seguir ser apresentada a tabela que relaciona fatos que podem provocar atrasos no cronograma e aes a serem tomadas quando o cronograma do projeto est atrasado. Os nmeros indicados nas colunas representam as aes descritas abaixo. Cada linha da tabela representa um fato e o conjunto de aes associadas. 0DUTXH FRP XP ; DV Do}HV TXH GHYHP VHU WRPDGDV SDUD FDGD IDWR OLVWDGR QD WDEHOD Obs.: Caso voc queira indicar outras aes relevantes, acrescente-a na lista de aes 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 ao correspondente.
$o}HV D VHUHP WRPDGDV TXDQGR R FURQRJUDPD WLYHU DWUDVDGR

1. 2. 3.
4. 5.

6.

Rever o planejamento do projeto e identificar desvios no cronograma. Agregar novas pessoas na equipe do projeto Redistribuir as pessoas na equipe. Rever as funes do software, prioriz-las e deixar as menos importantes para futuras verses. Rever o cronograma e buscar alcanar o prximo marco do projeto na data prevista para garantir o trmino do projeto na data esperada. Caso no haja possibilidade de recuperao do atraso, o gerente deve rever o cronograma e negociar com as partes envolvidas. )DWRV TXH SURYRFDP DWUDVR QR FURQRJUDPD

11. Contratar consultoria especializada. 12.

Controlar a comunicao entre os membros do projeto. Fazer ajustes no plano e documentar as aes para contemplar as revises de tempo, custo, seqncia de atividades e anlise de alternativas de respostas a riscos. 9. Verificar se as atualizaes do cronograma requerem ajustes em outros aspectos do plano geral do projeto. 10. Registrar os desvios do cronograma, identificar quais atividades ocorreram e o motivo de sua ocorrncia.
7. 8.

$o}HV UHFRPHQGDGDV

 



1. Equipe de desenvolvimento indisponvel. 2. Projeto com alto grau de inovao. 3. Prazos e custos estabelecidos arbitrariamente. 4. Mtodo de estimativa de tamanho inadequado.

124

5. Gerncia inexperiente. 6. Equipe de desenvolvimento inexperiente em Eng. Soft. 7. Equipe de desenvolvimento inexperiente na aplicao. 8. Equipe de desenvolvimento inexperiente nos mtodos e ferramentas utilizadas. 9. Processo de desenvolvimento inadequado. 10. Levantamento de requisitos com pessoas inexperientes. 11. Alto grau de competio na empresa do cliente. 12.Falta de comprometimento do usurio/cliente. 13. Oramento insuficiente. 14. Requisitos complexos. 15. Hardware e/ou software necessrios no disponveis no momento definido. 16. Dependncia de produtos ou servios externos que afetam o produto, o oramento, o cronograma ou a continuidade do projeto. 17. Mudanas de requisito que no foram refletidas em mudanas do cronograma. 18. Falta de identificao dos riscos previsveis e imprevisveis no incio do projeto. 19. Falta de identificao das dificuldades tcnicas e humanas no incio do projeto. 20. Falta de comunicao entre os membros da equipe do projeto.

125

$SrQGLFH &  3URFHVVR GH GHVHQYROYLPHQWR GH VRIWZDUH RULHQWDGR D REMHWRV


O processo de desenvolvimento de software inclui as perspectivas organizacionais, funcionais e comportamentais e deve refletir os principais objetivos do desenvolvimento como: i) construir software de alta qualidade, ii) encontrar as falhas no incio do desenvolvimento; e iii) manter as regras do oramento e cronograma. Nesse sentido, a escolha do processo a ser adotado no desenvolvimento depende da natureza da aplicao e das caractersticas do projeto. No escopo deste trabalho, o processo de desenvolvimento de software foi baseado no 5DWLRQDO 8QLILHG 3URFHVV (RUP). O RUP tem como principais caractersticas: i) a avaliao contnua dos riscos do projeto no final de cada iterao; ii) a gerao de produtos interdependentes em todas as iteraes; iii) baseado na tecnologia OO, fortemente orientado a utilizao de casos de uso, centrado na arquitetura e na UML; e iv) iterativo e incremental (RATIONAL..., 2001b). A idia principal do desenvolvimento iterativo e incremental a entrega do produto em partes (PITTMAN, 1993). No modelo de desenvolvimento incremental, cada componente projetado em detalhes, implementado, testado e disponibilizado. Os resultados de cada incremento so apenas parte de uma soluo que tem como objetivo, oferecer uma verso operacional do software possibilitando ao usurio, ter alguma funo em uso na medida em que as outras partes do projeto esto em desenvolvimento. 2001). No RUP, o software construdo em vrias iteraes ( uma seqncia distinta de atividades que resultam em uma verso do produto) durante as seguintes fases de desenvolvimento: i) concepo (estabelece os casos de uso de negcio do sistema e delimita o escopo do projeto); ii) elaborao (analisa o domnio do problema, estabelece a arquitetura do sistema, desenvolve o plano do projeto e elimina os elementos de riscos do projeto); iii) construo (so desenvolvidos, testados e integrados os componentes do sistema baseando-se na arquitetura definida); e iv) transio (so realizados os testes do produto e executados os ajustes, de acordo com a validao do usurio para assegurar uma disponibilizao adequada do software para os usurios). (JACOBSON; BOOCH; RUMBAUGH, 1996; RATIONAL..., 2001a e RATIONAL, 2001b). As fases variam de acordo com o tempo. Cada fase percorre um intervalo A cada nova verso, a funo disponibilizada refinada e novas funes so adicionadas. (MURTHI, 2002; PFLEEGER,

126

de tempo entre dois pontos de verificaes principais, definidas como marcos no projeto. No final de cada fase uma avaliao executada para determinar se os objetivos foram atingidos. Se a avaliao for satisfatria o projeto poder passar para a prxima fase. A passagem pelas quatro fases e respectivas disciplinas23 do processo determina uma iterao e produz uma verso do software. As disciplinas ou atividades deste processo so: modelagem de negcio, requisitos, anlise e projeto, implementao, teste e implantao. Alm destas, o RUP dispe de algumas disciplinas de suporte ao processo como o gerenciamento de mudanas e configurao, o gerenciamento de projetos e ambiente. A GLVFLSOLQD GH PRGHODJHP GH QHJyFLR modela visualmente o processo de negcio

usando os casos de uso de negcio. Esta disciplina garante um entendimento comum entre os interessados sobre o qu o processo precisa para apoiar a organizao. Os casos de uso de negcio so analisados e documentados atravs do modelo de casos de uso de negcios e do modelo de classes de negcio. Nem todos os projetos fazem a modelagem de negcios ( 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 atravs do software a ser desenvolvido. Nessa disciplina so identificados, organizados e documentados os requisitos do sistema. Os principais artefatos gerados nessa disciplina so: glossrio do software, memrias de reunies de levantamento de requisitos, lista de necessidades, relatrio de viabilidade tcnica, documento de viso do software (cenrios), modelo de casos de uso, definio da arquitetura candidata e prottipo de interface com usurio. O modelo de caso de uso um dos principais artefatos resultantes dessa disciplina. A DQiOLVH H SURMHWR tem como finalidade transformar os requisitos em um modelo com

suficientes detalhes para mostrar como os casos de uso do sistema sero realizados na implementao. Na anlise, gerado o modelo de anlise que constitui-se dos seguintes diagramas: de classes de anlise, de interao (colaborao ou seqncia), de estados ou de atividades. O projeto visa refinar o modelo de anlise e desenvolver uma arquitetura robusta para o software compatvel com o ambiente de implementao e com o desempenho desejado para o software. Os principais artefatos gerados nessa disciplina so: modelo de projeto (diagrama de
23

Disciplinas so as macro-atividades desenvolvidas durante as fases do RUP.

127

classes de projeto,

componentes e

modelo de dados), diagramas de interao de projeto,

definio da arquitetura (configurao da plataforma tecnolgica, diagrama de implantao e diagrama de subsistemas) e verso preliminar do plano de teste A LPSOHPHQWDomR visa desenvolver as classes, objetos e componentes, testar os

componentes e integr-los em subsistemas, conforme definido na arquitetura do software. Nessa disciplina, so gerados os cdigos fonte dos componentes, os resultados dos testes dos componentes, o plano de integrao de componentes, os subsistemas integrados e o produto de software. A GLVFLSOLQD GH WHVWHV visa identificar e garantir que defeitos sejam identificados antes de

disponibilizar o software. Deve ser verificada a interao entre objetos, a adequao da integrao de todos os componentes do software e se todos os requisitos foram corretamente implementados. Os casos de uso fornecem os cenrios necessrios para identificao funcional de cenrios de teste. Esses cenrios de teste so usados para originar casos de teste e scripts de teste. Dessa forma, a funcionalidade do sistema verificada executando-se cenrios de teste que experimentam cada caso de uso. Os principais produtos so o plano de teste, os casos de teste definidos, os resultados dos testes realizados, o documento de solicitao de mudanas no software aprovado pelos usurios. A LPSODQWDomR visa personalizar a instalao, empacotar o produto oferecido e permitir o

acesso ao software. Para isso, necessrio definir o plano de implantao do projeto e iteraes, manuais do usurio, do sistema e de treinamento antes da implantao do software. Em cada disciplina so gerados um ou mais artefatos. Alguns deles esto listados na coluna 2 do Quadro 22. Os artefatos destacados em negrito so geralmente utilizados para realizar a estimativa de tamanho durante o processo de desenvolvimento de um projeto de software OO, porque fornecem informaes relevantes sobre as funes do software, necessrias para fazer a estimativa de tamanho tanto atravs da APF como do PCU. Os artefatos gerados nas disciplinas acima representam os aspectos estticos e dinmicos de um sistema. Os artefatos estticos so aqueles que no mudam em uma verso do sistema, como classes, pacotes, componentes e os artefatos dinmicos descrevem informaes sobre objetos e como essas informaes so transmitidas em um servio ou funo. Geralmente, a parte esttica do sistema representada pelos diagramas de classes, de objetos, de componentes e de implantao e a parte dinmica atravs do diagrama de casos de uso, de seqncia, de

128

colaborao, de estado e de atividades. Esses diagramas so alguns dos artefatos mais importantes gerados durantes o processo de desenvolvimento de software OO. A seguir, apresentada uma breve descrio de cada um desses diagramas de acordo com Booch; Rumbaugh; Jacobson (1999): i) 'LDJUDPD GH FDVRV GH XVR

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, dependncias, generalizao e relacionamentos de associao. Geralmente, utilizado para modelar o contexto e os requisitos de sistemas. Casos de uso representam as funes de um sistema e o relacionamento entre elas. Um caso de uso pode tambm incluir um comportamento de um outro caso de uso atravs de um relacionamento do tipo includo ou estendido. O comportamento comum representado em um caso de uso do tipo includo para evitar a cpia das mesmas funes em diversos casos de uso. O caso de uso estendido representa um comportamento opcional ou alternativo ao cenrio principal, o qual indica que uma instncia do caso de uso pode ou no incluir o comportamento especificado (COCKBURN, 2000, citado por RIBU, 2001). Os atores podem estar associados atravs da generalizao, a qual utilizada para agrupar o comportamento comum entre os atores (RIBU, 2001). A UML no descreve como o modelo de casos de uso deve ser estruturado nem como cada caso de uso deve ser documentado. H apenas uma sugesto de Ivar Jacobson para usar um formulrio para a descrio estruturada dos casos de uso (RIBU, 2001) ii) 'LDJUDPD GH FODVVHV Este diagrama mostra a viso esttica do projeto do sistema atravs de um conjunto de classes, interfaces e a colaborao entre seus relacionamentos. Uma classe de objetos descreve um grupo de objetos com propriedades similares (atributos), comportamento comum (mtodos ou operaes), relacionamentos comuns com outros objetos e semnticas idnticas. Uma classe pode ser abstrata, ou seja, aquela que permite que um conjunto de subclasses tenha o mesmo comportamento, mas que no foi projetada para ter instncias. Uma classe abstrata representa um conceito e as classes dela derivadas representam implementaes desse conceito.

129

Cada classe classificada de acordo com seu esteretipo. Os esteretipos pr-definidos na UML so: classes de fronteira, de entidade, de controle, de exceo, parametrizada, utilitria e meta classe. Os trs primeiros esteretipos (fronteira, controle e entidade) so os mais comuns. Uma classe de fronteira modela a comunicao entre os atores e o sistema, uma classe de entidade modela informao e comportamento persistentes e uma classe de controle modela o comportamento de controle especfico a um ou mais casos de uso. Os objetos (instncia de uma classe) atuam no comportamento de um sistema colaborando entre si para produzir as funes necessrias. A colaborao realizada atravs de relacionamentos entre as classes. Na modelagem orientada a objetos, os relacionamentos mais importantes so dependncias, generalizao e associao. A dependncia um relacionamento entre dois elementos de modelagem, no qual uma mudana em um elemento de modelagem (o elemento independente) afetar o outro elemento de modelagem (o elemento dependente). A generalizao um relacionamento taxonmico entre um elemento mais geral (superclasse) e um elemento mais especfico (subclasse). A subclasse totalmente consistente em relao superclasse e contm informaes adicionais. Uma instncia da subclasse pode ser usada onde superclasse permitir. O mecanismo que torna possvel a generalizao a herana, que pode ser simples ou mltipla. Na herana simples, a subclasse herda as caractersticas de apenas uma superclasse e na herana mltipla a subclasse herda as caractersticas de mais de uma superclasse. Uma associao implica na existncia de uma ligao entre os objetos das classes associadas. Podem ser binrias, ternrias ou de ordem mais elevada. Uma agregao (tipo especial de associao) estabelece o relacionamento entre o todo e suas partes, no qual os objetos que representam os componentes de das partes so associados a um objeto que representa a estrutura inteira. O diagrama de classes contm tambm pacotes, subsistemas ou instncias como os objetos. iii) Este diagrama tambm a base para outros diagramas como os diagramas de 'LDJUDPD GH REMHWRV componente e de implantao.

Este diagrama mostra um conjunto de objetos e seus relacionamentos. Os objetos so instncia da classe, mas pode tambm representar instncias de colaborao, componentes e ns.

130

Este diagrama pode ser considerado como um caso especial de um diagrama de classes ou de um diagrama de colaborao. Este diagrama contm objetos e ligaes e utilizado sob a perspectiva real ou para prottipos da viso dos requisitos funcionais do sistema. iv) 'LDJUDPD GH FRPSRQHQWHV Este diagrama mostra a organizao e as dependncias entre um conjunto de componentes. Estes diagramas esto relacionados ao diagrama de classes, no qual um componente pode mapear uma ou mais classes, interface ou colaborao. v) 'LDJUDPD GH LPSODQWDomR Este diagrama mostra a configurao de ns de processamento em tempo de execuo e os componentes, os processos e os objetos que dependem deles. Os componentes representam manifestaes de unidades de cdigo em tempo de execuo. YL 'LDJUDPDV GH VHTrQFLD um diagrama de interao que enfatiza o tempo de ordenao da mensagem, ou seja mostra o comportamento de um caso de uso do sistema de forma cronolgica. Com base no comportamento, so atualizados os modelos estticos. Os diagramas de seqncia so definidos com base na descrio dos casos de uso e mostram um conjunto de objetos que participam da interao no topo do diagrama (nome e classe a qual pertence), as mensagens enviadas e recebidas de outros objetos, os mtodos ou operaes e os respectivos parmetros. Geralmente, coloca-se o objeto que inicia a interao esquerda e outros objetos subordinados a direita. As mensagens enviadas e recebidas so colocadas nas linhas verticais (que representam a existncia de um objeto num perodo de tempo. Muitos dos objetos que aparecem no diagrama de interao existem enquanto durar a interao). vii) 'LDJUDPD GH FRODERUDomR

um diagrama de interao que enfatiza a estrutura organizacional dos objetos que enviam e recebem mensagens. Este diagrama mostra um conjunto de objetos, as ligaes entre eles e as mensagens enviadas e recebidas. viii) 'LDJUDPD GH HVWDGR Este diagrama consiste dos estados, transies, 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 condies de transio que provocam mudana de comportamento do objeto (RIBU, 2001).

131

ix) sistema

'LDJUDPD GH DWLYLGDGHV

um tipo especial de diagrama de estado que mostra o fluxo de atividades dentro do A arquitetura do sistema em geral representada atravs das seguintes vises: i) de casos de uso (consiste dos diagramas e descrio de casos de uso e dos diagramas de atividades); ii) de projeto (constitui-se dos diagramas de classes, de interao e de estado); iii) de processo, (compe-se dos diagramas de classes e de interao); iv) implementao (diagramas de componentes); e v) de implantao (diagramas de implantao). Os artefatos mais importantes para o processo de estimativa de tamanho de um projeto de software so os destacados em negrito no Quadro 22: documento de viso do sistema, modelo de casos de uso (diagrama e descries de casos de uso); modelo de anlise (diagramas de classes de objetos e de seqncia) modelo de projeto (diagramas de classes de objetos, de seqncia e de entidade e relacionamentos); subsistemas e o produto final do software ou sistema. O documento de viso captura os requisitos de nvel alto e as restries de projeto, para fornecer ao leitor uma compreenso do sistema a ser desenvolvido. Ele fornece informaes necessrias, do ponto de vista de um negcio, para determinar se vale ou no a pena investir no projeto e est, portanto, diretamente relacionado ao caso de negcio. Comunica os principais questionamentos relacionados ao projeto e funciona como um regulador com base no qual todas 4XDGUR   $UWHIDWRV JHUDGRV GXUDQWH R SURFHVVR GH GHVHQYROYLPHQWR GH SURMHWR GH VRIWZDUH RULHQWDGR D REMHWRV
'LVFLSOLQD 0RGHODJHP GH QHJyFLR Modelo de casos de uso de negcio Modelo de classes de negcio $UWHIDWRV

as decises futuras devero ser validadas.

Glossrio do sistema de informao Atas de reunies de levantamento de necessidades Lista de necessidades. Relatrio de viabilidade tcnica 'RFXPHQWR GH YLVmR GR VLVWHPD 0RGHOR GH FDVRV GH XVR Definio da arquitetura candidata Prottipo de interface com usurio

5HTXLVLWRV

132 4XDGUR  FRQW  $UWHIDWRV JHUDGRV GXUDQWH R SURFHVVR GH GHVHQYROYLPHQWR GH SURMHWR GH VRIWZDUH RULHQWDGR D REMHWRV
'LVFLSOLQD $QiOLVH H 3URMHWR ,PSODQWDomR 7HVWHV ,PSOHPHQWD omR $UWHIDWRV 0RGHOR GH $QiOLVH (Diagramas de classes de anlise, de interao (colaborao e seqncia), de estados e de atividades 0RGHOR GH 3URMHWR (Diagrama de Classes de projeto, Componentes e Modelo de Dados) Diagramas de Interao de Projeto Definio da arquitetura (Configurao da plataforma, Diagrama de implantao e de subsistemas) Verso preliminar do Plano de Teste Modelo de implementao Cdigo fonte do componente. Resultados dos testes de componentes Cdigo fonte do componente corrigido Plano de integrao de componentes 6XEVLVWHPDV LQWHJUDGRV 3URGXWR GH VRIWZDUH Plano de teste atualizado com Procedimentos de teste e Casos de teste definidos Resultados dos testes Documento de solicitao de mudanas 6LVWHPD DSURYDGR SHORV XVXiULRV Plano de implantao do projeto e iteraes Manual do usurio Manual do sistema Material de treinamento 3URGXWR ILQDO GR VRIWZDUH SDUD XVR

Rational.... (2001a)