Scribd Logo
Upload

Welcome to Scribd!

  • 7 views

    Anallise Pontgos de Funcao - DocPlayer

    Uploaded by

    pagbarros

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content

    You might also like

    Anallise Pontgos de Funcao - DocPlayer

    Uploaded by

    pagbarros
    7 views7 pages

    Original Title

    Anallise Pontgos de Funcao_DocPlayer

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    Download as pdf
    7 views7 pages

    Anallise Pontgos de Funcao - DocPlayer

    Uploaded by

    pagbarros

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    Download as pdf
    of 7
    a Analise de\Pontos de Fun¢ao UIE VaTech Peat Thi Be CLUE Re aC aC NTL] Claudia Hazan audinaheyahoo com Géaés em fia pee Uniesiade ead do i eno (UR), Mee fe Engen de Stems Goputg pel steve Mar de Engend fm Doutrameta em Engr de St ware pala PCR, a ane as de rise quad de sare ne Sere Federal ce Pein ce Dies (0 P20 rnstande amet de die de Poss deFungcom esis expand 4 enpres ses ces na anagem de Pent de agi ait dept esata «gest earths emPores dering Inddstria de software continua sentindo os efeitos da erise do software da década 80. Isto pode ser observado quando analisamos 1s trés principais sintomas da crise do software apresentados por Pressman em 2006, a saber: +A produtividade nio tem acompanha- do a demanda por servicos; +A qualidade do software, em alguns sistemas, nio é adequada; + As estimativas de prazo e custo sio freqtientemente imprecisas, Este iltimo sintoma, quest associado a um dos principais problemas que a indd falta de previsibilidade de custo e prazo de projetos de software), pode levar a conseqdéncias desastrosas, tals como: conflitos entre o gerente do projeto © a equipe, baixa estima da equipe, entrega desoftware de baixa qualidade, perdade imagem da organizacio, e até mesmo 0 cancelamento do projeto. Assim, torna-se tria de software tem enfrentado (a Edicao 02 - Engenharia de Software Maga: importante o investimento na implanta- ‘io de um processo de estimativas efeti- vo, visando a melhoria da previsibilidade de custo, prazo e esforco, Este artigo tem como propésite apre sentar um processo de estimativas de projetos de software, aderente ao modelo CMML utilizando.a métrica de Pontosde Fungo para estimar o tamanho funcio- nal do projeto de software, Processo de Estimativas de Projetos de Software Esta sego apresenta uma visio geral de tum processo de estimativas de projetos de software aderente a érea de processo de Planejamento do Projeto do nfvel 2 do CMMI A Figura 1 ilustra um processo de Estimativas de Projetos de Software Tste processo ¢ descrito nos pardgrafos seguintes, O principal insumo (artefato de en- trada) para um processo de estimativas 60 documenta de requisites. Como as, 25 estimativas devem ser realizadas no inicio do processo de desenvolvimento de software, entao, 0 artefato utilizado 6 freqiientemente um documento inicial de requisitos (por exemplo: Documento de Visio) ou até mesmo um documento do préprio cliente (por exemplo: modelo de processo de negécios ou manual do ‘usuério, no caso de redesenvolvimento} © responsével pelas estimativas deve analisar os requisitos para garantie a qualidade e entio estimar o tamanho do projeto de software. © préximo passo € a derivagio das estimativas de esforgo, prazo (cronograma), custo (orgamento) ‘combbase naestimativa de tamanho enos dados histéricos de projetos concluidos da organizagdo, assim como o estabe- lecimento da estimativa de recursos computacionais ceticos, Neste ponto, as principais estimativas foram geradas, no entanto estas precisam ser documenta- das. As premissas e suposigBes utiliza das na geracio das estimativas também cdevem ser documentadas. ‘A andlise das estimativas por um es- timador independent, um profissional ‘que no atue na equipe do projeto, cons- titui uma boa prética. © estimador inde- pendente poder analisar a consisténcia das estimativas e 2 qualidade das suas, documentagées. No decorrer do proces- 50 de desenvolvimento, as estimativas sdevem ser acompanhadasconforme ore finamento dos requisitos. © projeto deve ser re-estimado se ocorrerem mudangas significativas nos requisitos funcionais, ou nao funcionais. Quando 0 projeto 6 conclusdo, deve-se documentar 0 ta- mano, prazo, custo, esforgo e recursos realizados, assim como outeos atxibutos relevantes do projeto, visando acoleta de ddados paraamelhoria do processo dees- timativas. As ligbes aprendidas também ever ser documentadas. © foco deste artigo estd na geragio de cestimativas de tamanho de projetos de software. Observe que a estimativa de ta- ‘mano éa primeiraaser geradaea partir dla so derivadas as demaisestimati Por isso, aimportincia desta estimativa, literatura apresenta varias métricas de tamanho. Na indtstria brasileira, pode- se destacar a utilizagio de trés métricas LOC (Line of Code), Pontos por Casos de ‘Usoe Pontos de Funcio. A segio seguinte presenta a8 vantagens e desvantagens da uilizagdo destas métricas Métricas de Tamanho de Projetos de Software A métrica Linhas de Cédigo (LOC) éde fatoamais antiga. A principal vantagemé ‘queacontagem delinhas de eédigo pode ser automatizada por uma ferramenta. AS desvantagens so as seguintes: muitas vezes, 0 significado de uma linha de e6- digo ¢ subjetivo, por exemplo, contar ou ‘no linhas de comentériono cédigo fonte; ‘a métrica no 6 adequada para ser um indicador de produtividade, por exem- plo, 0 desenvolvedor que escrever mais, linhas de e6digo sera mais produtivo do que © desenvolvedor que escrever um algoritmo mais elegante e mais eficiente ‘com menos linhas de eédigo. Além disso, torna-se bastante complicado e subjetivo aplicar esta métrica em um proceso de cestimativas cujo insumo éum documento inicial de requisitos. Portanto, nao é re- ‘comendado o uso da métrica LOC como unidade de medida para as estimativas de tamanho, A métrica Pontos por Casos de Uso (PCU) foi proposta por Gustav Karner com 0 propésito de estimar recursos para projetos de software orientados a ol ‘objeto, modelados por meio de especi- ficagio de Casos de Uso. A métrica é de fécil aplicago, ndo requer muito tempo de treinamento ou experiéncia pritica. No entanto, 0 PCU somente pode ser aplicado em projetos de software cuja especificagao tenha sido expressa em ‘casos de uso, Além disso, como ndo existe ‘um padrio tinico para a escrita de uma especificagao de caso de uso, diferentes cstilos na escrita do caso de uso ou na sua ‘granularidade podem levar a resultados diferentes na medicéo por PCU. Assim, ‘a métrica se torna subjetiva. E ainda, de- vvido a0 processo de mediggo do PCU ser aseado em casos de uso, 0 método nao pode ser empregado antes de coneluida a andlise de requisitos do projeto. Na ‘maioria das vezes existe a necessidade de se obter uma estimativa antes da fi- nalizagdo desta etapa. Entio, esta métrica no érecomendada para utilizagio como unidade de medida das estimativas de tamanho de projetos de software. Amétrica Pontos de Fungio (PF), defi- znida por Allan Albrechtem 1979, tem sido utilizada de forma erescente pela indi tria de software, O LEPUG (International Coletar e Analsar Requisitos Iniciais Estimar Tamanho i Estimar Esforgo. i Banco de Dados Histérico de Projetos| Estimar Cronograma| da organizagéo i Estimar Custo necessidade Reestimar,conforme Documentar Ealimar Recursos ‘Computacionais Critco ‘Analsare Aprovar Estimativas Documentar I Documentar ‘Aeompanhar Estimativas Resultados finais I @ Ligées Aprendidas Calibrar e Melhorar| 0 Proceso Figura, Procerro ce Ertmativas Ge Projetor ce Softaare 26 Engenharia de Software Magazine — Andlise de pontos de funcao Eunction Point Users Group), criado em 1986, 6 responsdvel pela atualizagso das regras de Contagem de Pontos de Fangio, descritas no CPM (Counting Practices ‘Manua), que se encontra na versio 421, publicada em 2005 no IFPUG. O IFPUG também é responsavel pelo exame de certficagio de especalistas em conta: sgem de Pontos de Fungio, denominada (CEPS (Certified Function Point Specials). A iétrica Pontos de Fungi 6 uma medida de tamanho funcional de projetos de sot tware, considerando as funcionalidades implementadas, sob o ponto de vista do usuario. Tamanho funcional ¢ definido como “tamanho do software derivado pela quantificagio dos requisites funcio- nais do usurio” (Dekkers, 2003) ‘A contagem de Pontos de Fungdo é independentemente da metodologia de desenvolvimento ¢ da plataforma utilizadas no desenvolvimento da aplicagdo. Assim, a autora recomenda a utilizagdo da métrica Pontos de Funcio nas estimativas de tamanho de projetos de software. A autora tem atilizado a métrica para estimar os projetos dos clientes da organizagio Servigo Federal de Processamento de Dados (SERPRO) desde 2003, tendo obtido excelentes resultados. ‘A segio seguinte apresenta 0 método ‘Contagem Estimativa de Pontos de Fangio (CEPA), utilizado para estimar 0 tamanho de projetos de software. Contagem Estimativa de Pontos de Fungao Antes de definir 0 método de estima tivas CEPF, € importante destacar que “estimar significa utilizar o mfnimo de tempo e esforgo para se obter um valor aproximado dos Pontos de Fungio do projeto de software investigada” (Mel, 1999). Assim, para evitar confusso, é re- comendvel sempre fazer uma distingio centre os termoseconceites: Contagem de Pontos de Fungéo e stimativa de Pontos de Fungio. *Contagem de Pontos de Fungéo: sig- nifica mediro tamanho do software por meio do uso das regras de contagem do IFPUG (IFPUG, 2005); +Estimativa de Pontos de Fungio: significa fornecer uma avaliagfo aprox mada do tamanho de um software ui zanddo métodos diferentes da Contagem de Pontos de Fungao do IFPUG. ‘Alem do método Contagem indicativa de Pontos de Fungio, existem diversos métodos para estimar tamanho de pro- jelos em Pontos de Fungio, descritos na literatura, dentre outros: Contagem Indi- «ativa, Contagem Indicativa Inteigente, Estimativas Percentuais, © método CEPF visa aferir o tamanho ‘emPF de maneira simplificada, com base zo conhecimento dos requisites iniciais do projeto. Inicialmente, os requisitos funcionais iniciais documentados nas propostas comerciais nos documentos de Visdo, ou em qualquer especificagéoini- ial do sistema do usuario sio mapeados ‘nos tipos funcionais da Anélise de Pontos ‘de Fungio (APF): Arquivo Logico interno (ALD, Arquivo de Interface Externa(ATE), Entrada Externa (EE), Consulta Externa (CB)eSaida Externa 6B. Posteriormente, (05 Pontos de Fungéo sio associados a cada fungio identificada, baseando-se nas tabelas de complexidade e de contei- Dbuigdo funcional do CPM. © estimador deve realizar uma leitu- za no documento iniial de requisites, buscando informagies relevantes para a identiticagio de processos elementares. (© processo elementar € definido como a menor unidade de atividadesignficativa para o usuéri (IFPUG, 2005). O processo lementardevesercompletoemsimesmo, independente e deixar aaplicagio em um estado consistent 1FPUG, 2005) Uma vez identiticado o processo elementar, 0 esti- rmador deve buscar oentendimento deste para classificé-lo em Entrada Externa, Consulta Externa ou Saida Externa, Adi- onalmente, 0 estimador deve descobrie 08 dados associados ao processo elemen- tar, visando a determinagdo da comple- Xidade funcional da fungio identificada ‘Caso nao seja possivel a identificagso da complexidade da funcionalidade em ques- tao, recomenda-se a uilizagio da com- plexidade Média. Na andlise do processo ‘lementar também so identifcados, 08 ‘grupos de dadoslogicos da aplicagio, que ‘io clasificados como Arquivos Légicos Intemosou Arquivos de interface Externa, Caso no seja possivel a identificagso da complexidade da funsdo de dados em questdo, recomenda-se a utilizagso da ‘complexidade Simples. ‘A soguir sio apresentadas dicas para ajudar no mapeamento dos requisitos funcionais da aplicacio nos tipos fun- cionais da APF Edicao 02 - Engenharia de Software Maga: a As necessidades ¢ funcionalidades ‘especificadas para 0 projeto, contidas no documento inicial de requisitos, devem ser enquadradas em uma das seguintes tabelas: Tabela 1 - Contagem dos Arquivos Logicos Internos (ALI Banco de Dados Légico da Aplicagio (tabelas e arquivos mantidos pela aplicagéo). Consideragbes: Identifique os grupos de dados légicos de aplicagdo nos mode- Tosde dadosou diagrama de classes ou a partir dos requisitos funcionais, descritos nosdocumentos de requisitos (Documen- tode Visio, Relacio de Casos de Uso, etc). Nao considere arquivos fisicos, arquivos de {ndiees, arquivos de trabalho etabelas de relacionamento sem atributos proprios (abelas que existem para quebrar orela- cionamento nxn e apenas transportam as chaves estrangeiras) As entidaces fracas também nao sfo consideradas um ALI. Se possivel, tente descobrir os atributos légicos, campos reconhecidos pelo ust- frio, e subgrupos de dados existentes para obter a complexidade funcional, segundo as regras de contagem do CPM EPUG, 2005). Caso nao seja possivel, a ‘experiéncia tem mostrado que a maioria dos ALIs dos sistemas sao de complext- dace Simples. Crees a for Orr poe SPF Pn Tabela 1. léenticagso dos Arquivos Légicos Intemnas da Apicagae ‘Tabela2-Contagem de Arquivosde In- terface Extera (AIES): Banco de Dados de coutras AplicagSes, apenas referenciados pela aplicacao que esté sendo estimada (tabelas e arquivos mantidos por outa aplicagio) Consideragdes: Identifique os grupos de dados Iogicos de outras aplicagbes roferenciados pela aplicagso que ests sendo estimada. Freqientemente, 0 referenciamento de dados ocorre para a validagéo de informagies em cadastros ou consultas. Algumas vezes, relatrios ou consultasreferenciam dados externos deoutrasaplicagbes, também considera. dos AIBs. Nao sao considerados arquivos fisicos, arquivos de indice, arquivos de 27 trabalho, tabelas de relacionamento sem atributos préprios e entidades fracas A cexperiéncia tem mostrado que pra- ticamente 100% dos AIEs dos sistemas sio Simples. Porque, segundo 0 CPM AIFPUG, 2008), s80 considerados para a determinagio da complexidade funcional do IE apenas os atributosreferenciados pela aplicagio que esté sendo contada. cs frre Pro Pon Tabela2.Identiicagao dos Arquivos de Interface Externa da Aphcagio ‘Tabela3-Contagem de Entradas Exter- ‘nas (EES Funcionalidades que mantém (05 Arquivos Légicos Internos (ALI) ou alteram 0 comportamento da aplicagSo. ConsideragSes:Identifique as funciona lidades de inchusdo,alteragio eexclasdes dedados. Conte separadamente as inclu- ses, alteragbeseexclusdes de dads isto 6 cada fungio independente de inclasto oualteragio ou exclusdo deve ser contada separadamente. A aplicagio poss fun~ ‘60s de entrada de dados que alteram 0 comportamento dela, por exempla: pro- cessamentos batch, ou processamento de informagdes de controle? Caso positvo, estas fungdes também devem ser identi- ficadas como Entradas Externas, Se vocé no possi conhecimento da \gio de APF ou sobre 0 processo clementar (funcionalidade analisada), considere as Entradas Externas identifi- cadas com complexidade Média. cor fare Crees fone ‘Tabela 3. entiicagio das Entradas Externas da Aplicagio Tabela 4 - Contagem de Consullas Ex: ternas (CES): funcionalidades que apre- sentam informagies pata o usuério sem a.utilizagio de célculos ou algoritmnos, $30 ‘0s processos elementares do tipo prime’, “Ie - apresenta dados’, incluindo consullas relat6rios, geragdo de disquetes ‘ou CDs, dovnloads entre outros Consideragies: Vocé est desenvol- vendo uma fungéo para apresentar informagées para 0 usuério: uma con- sulta, relatsrio, browse, listbox, download, zgeragio de um arquivo, geragio de CD ‘ou de disquete? Esta fungio nie pos caleulos ot algoritmos para derivagio dos dados referenciados nem altera um Arquivo Légico Interno, nem muda 0 ‘comportamento do sistema? Caso positi- ‘vo, estas fungdes devem ser identificadas ‘como Consultas Externas, Caso nio haja conhecimento da aplica- ‘glo de APF ousobre o processo elementar (uncionalidade analisada), considere as Consultas Externas com complexidade Média, cos ar Pree fone Tabela 4. dentiicagio das ConsultasExternas daApleagi Tabela5 - Contagem de Saidas Externas (GEs): Funcionalidades que apresentam informagdes para o usudrio com utili zagio de eSleulos ou algoritmos para derivagio de dados ou atwalizagao de Arquivos Légicos Internos ou mudanca de comportamento da aplicagso. S50 as consulta ou relatérios com totalizagao dedaclos relatos estatisticos,graticos, seragio de disquetes com atualizagio log, downloads com célculo de percental, entre outros Consideragies: Voct ests desenvolven- do uma funcionalidade para apresentar informagoes para o usuario: uma consulta ou relatério com totalizagio de dados, etiquetas de cédigo de barras, gréficos, relatérios estatisticos, download com percentual calculado, geragio de arquivo com atualizacio de log? Caso positivo, estas {ungSes devem ser identificadas como Saidas Externas, Observe que esta fungio deve ter célculos ow algoritmos para processar os dados referenciadosnos arquivos logicosou atualizar campos (nor malmente indicadores) nos arquivos ow -mudar o comportamento da aplicacao, Caso nao haja conhecimento da aplica ‘fo de APF ou sobre o processo elementar (funcionalidade analisada), considere as Safdas Externas com complexidade Média, aah 1S a Tabela 5. Identiicacao dos Sadas Externas da Aplisgso ‘A Bstimativa de tamanho do projetoem. PFs deve ser gerada totalizando-se os PFS obtidos nas Tabelas 1, 2,3,4,¢5. Uma aplicagao da Contagem Estimativa de Pontos de Fungéo Esta segio tem como propésito apre- sentar um exemplo uilizando o método CEPR, bem como a derivagio das esti- mativas de esforgo e prazo, a partir da estimativa de tamanho do projetoem PE. No exemplo apresentado, € descrito um sistema hipotético, parte de um sistema real, visando apresentar uma visio geral de tum procedimento de estimativas de maneira pratic. Suponha que o setor de treinamento de uma empresa solicitou um sistema, denominado STREINA, para apoiar as atividades de planejamento e acompa- nnhamento das atividades de capacitagdo dos funcionérios. A Tabela 6 apresenta 28 Engenharia de Software Magazine — Anélise de pontos de fungio as necessidades ¢ funcionalidades do STREINA, retiradas do Documento de Visio do projeto, Além das funcionali= dades apresentadas na Tabela 6, deve- se considerar os requisitos de cadastro de usuérios © controle de acesso da aplicagao. Estas funcionalicades estardo disponiveis para o g do sistema, Para facilitar 0 entendimento da apli- cagio da CEPF, a Tabela 7 mostra a contribuigao para a contagem de PFs nko ajustados dos tipos funcionais da APE, A complexidade funcional das funcionalidades identificadas ¢ inferida em uma contagem estimativa, quando rio se possui informagio suficiente do projeto para aplicar as regras de conta- gem do CPM, Conforme mencionado, recomenda-se utilizar a complexidade ‘Simples para os Arquivos L6gicos (ALI © AIE) e a complexidade Média para as, FungSes Transacionais (EE, CE, SE). Aplicando-se 0 método Contagem Es timativa de Pontos de Funcio, tem-se 0 resultado apresentado na Tabela 8. Totalizando o tamanho em PPs das incionalidades descritas na Tabela 8, tem-se 170 PFs nio ajustados. Suponha que o fator de ajuste da contagem seja de 1110, O fator de ajuste da contagem de PF 6 determinado com base na avaliagio das, 14 Caracteristicas Gerais dos Sistemas, que descrevem as funcionalidades gerais, das aplicagées, por exemplo: performan. ce, reuso, usabilidade, ete, O manual de praticas de contagem (CPM) apresenta a deserigio d ponderagées, denominadas niveis de influéncia, © célculo do PF Ajustado € obtide multiplicando-se os PEs Nao Ajustados pelo Fator de Ajuste. Assim, temos 187 Pontos de Fungo Ajustados estimados. De posse da estimativa de tamanho, procede-se com a geragao da estimativa de esforgo, Neste exemplo, utiliza-se 0 modelo simplificado de estimativas de esforgo, descrito por Hazan em 2008. Para isto, deve-se obler um indice de produtividade por meio de andlise do ‘banco de dados de histérico de projetos da organizagio, observando-se os atti- bbutos do projeto em questio e o esforso realizado.em projetos similares. Este pro- jeto é pequeno (menos de 200 PF) e ser desenvolvido em JAVA por uma equipe com experiéncia intermediaria na plata- exfil administrador caracteristicas e de suas PLANEJAMENTO “oar apctains om fay [Siateeteeancrso Tei ria [Pinsereeete petro Tei Pineoremnarana de apcte mn carnage tpt eae constr coogi apie ie ra deca Tee centre cacti pate fs rail aie contr eabe de evn ce acai fe i Tei blr edn wali de uneven dace ty dod alga de enn de capcagi Tei ai oe oT fs eae f19_ [alters de ns dap stone) Pree dower Fn __Sstransinanet eonmide putes Tee er Cea Gees eR) ncn ‘ 1 |cerente Tabela 6.Funcionaldades do Sistema de Treinamentos(STREINA) Tandon Sine ie Cane sao apo en AL 7 07% 150 Aga de reer 5 7 107% ra era a 7 oF Sitar a 57 7s cout ens a os PFs Edicao 02 - Engenharia de Software Maga: Tabela 7. Contribuigo para Contager de PF dos Tipos Funcionals da APF 29 his Singhs 1 ‘arabe & Snake a tears € Stes a berate a Singhs a7 isa deh « Singhs oF onsite € Singhs a onto cexesn apa 5 Snake a kerbs Ga Sings vm squeceaseha s Singh oF anacage a Meda a nr evet epee a wide a pte ede pce & we om Puneet de cance fe Wed a nator pine een apa « Meds a Den cweyana decane & Ned a nstarenegaa ee apace © Meda 7 nr reat erie s Nida 7 reheat & Conlon mF Indep ara vee f Midi a ieparcputes pane & Mea a dir acpnes pa evo & Singles 3 orate esas is « Medi ma Earp eal ur parenaio do ete s Meds sm roma ao departures = Singles cor aap departs @ Ned m3 En rapa ripe = Ned 7 isa de Paiute Eis de ride Pdee @ Singles ve alan de voce pn a Singles Te aor ane deena ee apna & Stns 7 hier naa deen de apace tf Singles a covariance de apa € Singles FF ovat as er scenguhanens te oaiade @ wen oe peaks —ctdbde Enviar enantio par wagadowent E Ned 7 nats Geren re ti om de ad) se Ned sar ta 30 Engenharia de Software Magazine Analise de pontos de funcso la 6. Estimativa de Tamanha do Sistema de Teinamentos(STRANA) forma, Assim, 0 indice de produtividade hipotético utilizado & o de 12 horas/PF. Entdo, a estimativa de esforco 6 de: 187 x 12= 2244 HH (homens_hora). © préximo passo é a estimativa de prazo, aplicando-se a formula de Caper Jones (1998) de aproximagio de Tempo Otimo de Desenvolvin ‘um expoente 592 meses. Considerando-se o prazo estimado de 6 meses eo esforso esti- mado de 2244 HH, 0 proximo passo é a estimativa do tamanho da equipe de desenvolvimento ideal para atuar no projeto.em questio. Segundo Jones (1997), a produtividade média didria no Brasil de 6 horas/dia. E ainda, em média um més possui 22 dias tes. Entio,temese: prazo = (esforgo em HH) / (tamanho cequipe * 6 * 22). Entio, apicando-se a férmula, obtémseo tamanho da equipe ideal para atuar no projet, que deve ser consttufda por ts recursos, incluindo desenvolvimento e gestic © COCOMO I também possuiféemulas para o eflealo do Ti, baseadas em pari- mnetros de calrayem e de mapeamento {Boehen, 2000 £ importante destacar que as onganizagSes devem ter ou construirum ‘banca de dadoshistrico contend informa es de projets conchidos coma final dede gear as estimatvas de prazo, custoe esforgo com uma scuréca wloquad Aplicando-se o COCOMO Il para a5 es- Limativas de estorgoe prazo doSTREINA, teno0 0 guint + Fator de Produtividade Linear (Pesso- as_Més/KSLOC) para desenvolvimento WEB: 2,51 (Roetzheim, 2005) *Fator Exponencial para desenvolvi- mento WEB: 1080 (Roetzheim, 2005) +1 PF~33SLOCom JAVA (fons, 1997); + Bsforgo ~ Fator de Produtividade x KSLOCT** "rrr! (Roetzheim, 2005); 2,81 x [63 x 70/1000) = * Esforso 114,83 Fessoas_Més. Note o que o insumo para o COCOMO € PF Nao Ajustado, por isso considerou-se 170 PES; + OCOCOMO considera o dia com 7h e ‘© més com 22 dias tts, entdo 0 esforgo ‘emHH 6 0 seguinte: 1483 *7*22 =2284 HI, Note que o célculo do esforgo esti- mado é préximo ao 2244 HH obtido pelo modelo simplificado; *Prazo (Td) = 2,5 x (Esforgo™) = 59 meses (Aguiar, 1999); *Note que 0 prazo estimado pela f6r- mula de Caper Jones ~ 592 meses ficou bastante préximo do prazo estimado pelo cocomo, [Na pratica, oma-se importante aplicar mais de um modelo de estimativas e analisar-se os resultados obtidos. Caso fosse utilizada a formula de esforco da ferramenta Cost Xpert, apresentada por Aguiar em 1999, 0 resultado seria 0 seguinte: B= 2,4 x (V ) = 14,68 Pes- soa_Mes, sendo V 0 tamanho do projeto em KSLOC. Note queeste ébem préximo do esforco estimado, utilizando-se os pardmetros propostos por Roetzheim ‘em 2005. Caso fosse utilizado 0 esforco dde 14,68 como insumo para o céleulo do prazo, este continuaria sendo estimado fem 59 meses. ‘Aeestimativa de custo deve considerar © valor da hora da equipe alocada 20 projeto (custo de pessoal), bem como outros custos de ambiente, ferramentas, deslocamentos, consultoria,ete. Algumas empresas possuem dados histéricos de custo por PF de projetos concluidos, possibilitando a derivagio direta da es- timativa de custo a partir da estimativa dde volume em Pontos de Fungio. ‘A estimativa de recursos computacio- nais criticos em um projeto WEB deve considerar, dentre outros, a disponibili- dade dos servidores utilizados para de- senvolvimento, homologacio-e produgio dosistema eoutros recursos de hardware relevantes E importante ressaltar que aps a ge- ragio das estimativas, deve-se adicionar tum percentual, prevendo uma evolucio natural dos requisitos do projeto. Este percentual deve ser obtido por meio de dados de histéricos de um indicador de estabilidade de requisitos de projetos conclutdos da organizacio. ‘As ferramentas de estim também trabalham desta forma, solicitando que © usudrio (estimador) fornega tal per- centual, No entanto, devido & auséncia de dados histéricos analisados para tal indicador, a autora tem se baseado em analise de publicagdese sua experiencia profissional. A autora tem utilizado um percentual de 20% a 35% para os projetos com Documenta de Visio. Esta variagio de percentualédirelamente proporcional ao detalhamento do Documenta de Visio econhecimento dos requisitos do projeto pelo analista de negécios. Para alguns projets estimados, basea- ddos apenas em atas de reunio ou doc :mentos menos detalhados, oi utilizadoo percentual de 0%. Em projetos pequenos com documentos de requisitos com um detalhamento adequado, o percentual varia de 10% a 25%, ‘ACEPF deve ser refinada, conforme 0 conhecimento dos requisitos do projeto evolui, em marcos definidos no plano do projto. Assim, no hé retrabalho no processo de estimativas, as estimativas de PF anteriores no sio descartadas e sim refinadas, conforme os requisitos do projeto evoluem Conclusao ‘A indistria em demonstrado dificulda- dena previsibilidade de prazoe custo dos projetosde software. Noentanto, muitas organizagdes ainda estimam projetos, sema utilizagao de processo, de maneira “artesanal’, baseando-se apenas na opi- rio dos lideres ou gerentes do projeto. De fato, 0 método de estimar projetos baseando-se na opiniso de especialistas 6 bastante eficaz. O problema é quando a equipe nao possui especialistas no do- :inio do projeto em questa, Este trabullhoapresentou um processo para asorganizagBesnasestimativasde projetos

    You might also like