Académique Documents
Professionnel Documents
Culture Documents
Histrico de Verses
Data Verso Descrio Roteiro Corporativo de Mtricas para Contratos de Sistemas Autor Revisor Aprovado por
30/04/2010
1.0
Claudia Hazan
Sumrio
1. INTRODUO..............................................................................................................................................................4 2. OBJETIVO......................................................................................................................................................................5 3. ESTIMATIVAS DE PROJETOS DE SOFTWARE...................................................................................................6 3.1 CONTAGEM ESTIMATIVA DE PONTOS DE FUNO (CEPF).........................................................................9 3.2 ESTIMATIVA DE ESFORO DE PROJETOS DE SOFTWARE............................................................................14 3.2.1 Distribuio de Esforo por Fase do Projeto...................................................................................................16 3.3 ESTIMATIVA DE PRAZO DE PROJETOS DE SOFTWARE...............................................................................16 3.3.1 Alocao de Equipe ao Projeto.........................................................................................................................19 3.4. MTODO PARA ESTIMATIVA DE CUSTO.................................................................................................19 3.5 ESTIMATIVA DE RECURSOS COMPUTACIONAIS ........................................................................................20 4. CONTAGEM DE PONTOS DE FUNO DE PROJETOS DE MANUTENO..............................................21 4.1 PROJETO DE MELHORIA ...................................................................................................................21 4.2 MANUTENO CORRETIVA.................................................................................................................23 4.3 MANUTENO COSMTICA.................................................................................................................25 4.4 MANUTENO ADAPTATIVA EM REQUISITOS NO FUNCIONAIS...................................................................25 4.4.1. Redesenvolvimento de Projetos em outra Plataforma.....................................................................................26 4.4.2. Atualizao de Plataforma...............................................................................................................................26 4.4.3.Adequao de Funcionalidades s Mudanas de Negcio...............................................................................27 4.5 APURAO ESPECIAL.......................................................................................................................29 4.5.1. Apurao Especial Base de Dados...............................................................................................................29 4.5.2. Apurao Especial Gerao de Relatrios...................................................................................................30 4.6 MANUTENO EM PGINAS ESTTICAS DE INTRANET, INTERNET OU PORTAL.................................................30 4.7 MANUTENO DE DOCUMENTAO DE SISTEMAS LEGADOS.......................................................................32 4.9 FATOR DE CRITICIDADE DE SOLICITAO DE SERVIO.............................................................................33 4.10PONTOS DE FUNO DE TESTE..........................................................................................................33 5. ATIVIDADES SEM CONTAGEM DE PONTOS DE FUNO............................................................................34 6. CONSIDERAES PARA CONTAGEM DE PONTOS DE FUNO ...............................................................37 6.1 CONSIDERAES SOBRE MUDANA DE REQUISITOS.................................................................................37 6.2 CONSIDERAES SOBRE PROJETOS CANCELADOS...................................................................................38 6.3 CONSIDERAES SOBRE REDUO DE CRONOGRAMA..............................................................................39 6.4 MTRICAS PARA ATIVIDADES DE NEGCIO.............................................................................................40 7. CONTAGEM DE PONTOS DE FUNO COM MLTIPLAS MDIAS............................................................42 7.1 CENRIO 1: MESMOS DADOS APRESENTADOS EM TELA E IMPRESSOS...........................................................44 7.2 CENRIO 2: MESMOS DADOS DE SADA COMO DADOS EM ARQUIVO E RELATRIO IMPRESSO...............................44 7.3 CENRIO 3: MESMOS DADOS DE ENTRADA BATCH E ON-LINE.....................................................................45 7.4 CENRIO 4: MLTIPLOS CANAIS DE ENTREGA DA MESMA FUNCIONALIDADE....................................................45 7.5 CENRIO 5: RELATRIOS EM MLTIPLOS FORMATOS..............................................................................45 8. PROCESSO DE REVISO DO GUIA DE CONTAGEM.......................................................................................47 8.1 REVISO PARA CORREO DE INCONSISTNCIAS E SITUAES NO PREVISTAS..............................................47 8.2 REVISO PARA ADOO DE NOVAS VERSES DO CPM..........................................................................47 9. CONCLUSO...............................................................................................................................................................48 REFERNCIAS BIBLIOGRFICAS...........................................................................................................................49 ANEXO I: DOCUMENTO DE REQUISITOS DE PROJETOS DE MANUTENO PEQUENOS (< 100 PFS) ............................................................................................................................................................................................51 ANEXO II: MODELO DE DOCUMENTO DE CONTAGEM DE PONTOS DE FUNO PARA PROJETOS DE MANUTENES PEQUENOS (< 100 PFS).........................................................................................................57 2
1. Introduo
O SERPRO, assim como muitas empresas governamentais brasileiras tm utilizado a mtrica de Pontos de Funo (PF) nas estimativas e dimensionamento de tamanho funcional de projetos de software, devido aos diversos benefcios de utilizao da mtrica (independncia da soluo tecnolgica utilizada) e s recomendaes dos rgos de controle do governo brasileiro. O manual de prticas de contagem de Pontos de Funo (CPM 4.3) [IFPUG, 2010] publicado pelo International Function Point Users Group (IFPUG) define as regras de contagem de Pontos de Funo. No entanto, a contagem de Pontos de Funo baseada no projeto lgico da aplicao (logical design) e nas fases iniciais do ciclo de vida do software, o documento de requisitos para a estimativa e elaborao do plano do projeto um documento inicial de requisitos, por exemplo: Documento de Viso, Formalizao Simples de Requisitos ou algum outro tipo de especificao elaborada pelo analista de negcios. Assim, torna-se importante o estabelecimento de mtodos para estimar o tamanho funcional dos projetos de software nas fases iniciais do ciclo de vida. Outro ponto a ser destacado a importncia da definio de mtodos para gerao de estimativas de prazo, esforo, custo e recursos computacionais dos projetos de software da empresa, visando melhorar o gerenciamento dos projetos. Alm disso, importante ressaltar que a mtrica de Pontos de Funo foi concebida como uma medida de tamanho funcional para projetos de desenvolvimento e de manuteno evolutiva de software. No entanto, os projetos de software no esto limitados a projetos de desenvolvimento e projetos de manuteno evolutiva ou Melhoria (enhancement). Assim, torna-se essencial a definio de mtodos para dimensionar o tamanho de projetos de manuteno (maintenance) baseados em Pontos de Funo para que estes projetos possam ser avaliados e gerenciados com base em uma mtrica. Observe que a Instruo Normativa 04, publicada pela SLTI/ MPOG, preconiza a utilizao de mtricas em contratos de software. Os Acrdos do Tribunal de Contas da Unio (TCU) recomendam a utilizao da mtrica Pontos de Funo No Ajustados. A verso 4.3 do CPM tambm reconhece o PF No Ajustado como mtodo padro do IFPUG.
4
2. Objetivo
Este documento tem como propsito apresentar um roteiro contagem de Pontos de Funo aderente ao Manual de Prticas de Contagem (CPM 4.3) e definir os tipos de projetos de manuteno e uma sistemtica para dimensionar o tamanho de tais projetos, utilizando a mtrica Pontos de Funo. Alm da contagem de Pontos de Funo, este roteiro apresenta um processo de estimativas com base na mtrica Pontos de Funo, aderente ao modelo CMMI. Este documento encontra-se organizado da seguinte maneira: O Captulo 1 apresenta a motivao para a elaborao do documento; O Captulo 2 mostra os objetivos aos quais este documento se prope e a organizao deste documento; O Captulo 3 define o processo de estimativas de projetos de software integrado ao processo, indicando o momento de realizao das estimativas e as anlises a serem realizadas; O Captulo 4 apresenta diretrizes para a estimativa e a contagem de Pontos de Funo de todos os tipos de projetos de manuteno de software; O Captulo 5 descreve as atividades associadas ao processo de desenvolvimento de software sem contagem de Pontos de Funo; O Captulo 6 apresenta algumas consideraes importantes sobre utilizao de mtricas para dimensionar as mudanas de requisitos, reduo de cronograma e atividades de negcio; O Captulo 7 define um Guia para contagem de Mltiplas Mdias; O Captulo 8 apresenta o processo de reviso deste guia de contagem; Finalmente, o Captulo 9 conclui o documento apresentando sugestes para trabalhos futuros.
Estimar Tamanho
Estimar Cronograma
Estimar Custo Estimar Recursos Computacionais Crticos Analisar e Aprovar Estimativas Acompanhar Estimativas Calibrar e Melhorar o Processo
Documentar Estimativas e Premissas Documentar Acompanhamento Documentar Resultados finais e Lies Aprendidas
Reestimar,conforme necessidade
Estimar Esforo
O principal insumo (artefato de entrada) para um processo de estimativas o documento de requisitos. Como as estimativas devem ser realizadas no incio do processo de desenvolvimento de software, ento, o artefato utilizado um documento inicial de requisitos, por exemplo: Documento de Viso ou Formalizao Simples de Requisitos. O estimador deve analisar os requisitos para garantir a qualidade e ento estimar o tamanho do projeto de software. O prximo passo a derivao das estimativas de esforo, prazo (cronograma), custo (oramento) com base na estimativa de tamanho e nos dados histricos de projetos concludos da organizao, assim como o estabelecimento da estimativa de recursos computacionais crticos e dos recursos da equipe a ser alocada ao projeto. Neste ponto, as principais estimativas foram geradas e precisam ser documentadas. As premissas e suposies utilizadas na gerao das estimativas, dentre outras: complexidade do projeto, plataforma de desenvolvimento, tipo do projeto, percentual de evoluo de requisitos, tambm devem ser documentadas [Hazan, 2008]. A realizao das estimativas por um analista de mtricas que no atue na equipe do projeto, constitui uma prtica recomendada. O analista de mtricas deve analisar tambm a consistncia da documentao utilizada na estimativa . No decorrer do processo de desenvolvimento, as estimativas devem ser acompanhadas conforme o refinamento dos requisitos. O projeto deve ser reestimado aps a fase de requisitos, quando for gerada a especificao de casos de uso, e sempre ocorrerem mudanas significativas nos requisitos funcionais ou no funcionais. Quando o projeto concludo, deve-se aferir e documentar o tamanho, prazo, custo, esforo e recursos realizados, assim como outros atributos relevantes do projeto, visando a coleta de dados para a melhoria do processo de estimativas. As lies aprendidas tambm devem ser documentadas [Hazan, 2008]. Portanto, para os contratos de projetos de software, baseados na mtrica Pontos de Funo, as estimativas devem ser realizadas em trs marcos do processo de desenvolvimento de software, a saber:
Estimativa inicial: realizada aps o fechamento do escopo do projeto. Geralmente, baseada em um documento inicial de requisitos, por exemplo Documento de Viso. Constitui uma boa prtica a previso de evoluo de requisitos, especialmente em projetos de desenvolvimento de mdio ou grande porte. Nessa etapa importante destacar os seguintes conceitos na rea de estimativas: Uma Estimativa obtida por meio de uma atividade tcnica, utilizando mtodos de estimativas. No deve sofrer interferncias polticas. A Meta um desejo, em funo de necessidades de negcio, estabelecida politicamente. Um Compromisso um acordo da gerncia com as equipes tcnicas para alcanar uma meta [Parthasarathy,2007]. Em um cenrio ideal os resultados da estimativa atendem as metas de negcio. Quando este cenrio no real, fundamental a reduo de escopo do projeto, de modo que a meta se adapte aos resultados da estimativa.
dos requisitos. Geralmente, leva em considerao a Especificao dos Casos de Uso e Regras de Negcio da aplicao.
Contagem de Pontos de Funo Final: realizada aps a homologao da aplicao. Esta contagem leva em considerao as funcionalidades efetivamente entregues para o usurio pela aplicao. Para fins de faturamento, que realizado durante o desenvolvimento, deve-se
considerar a Contagem de Referncia e posteriormente considerar os ajustes no faturamento aps a Contagem Final. importante ressasltar que as mudanas de requisitos tambm sero consideradas no tamanho projeto a ser faturado, conforme descrito na seo 6.2. Alm disso, se estas mudanas forem significativas, maiores que a evoluo de requisitos (scope creep) prevista na estimativa inicial, o prazo do projeto deve ser reestimado. Toda mudana de requisito deve passar por uma anlise de impacto do SERPRO e ser aprovada pelo cliente. As sees seguintes apresentam os mtodos de estimativas de tamanho prazo, custo e esforo utilizados nos projetos de software do SERPRO.
do tamanho de um software utilizando mtodos diferentes da Contagem de Pontos de Funo do IFPUG. O mtodo CEPF visa aferir o tamanho em PF de maneira simplificada, com base no conhecimento dos requisitos iniciais do projeto. Inicialmente, os requisitos funcionais iniciais documentados nas propostas comerciais, nos documentos de viso, formalizao simples de requisitos ou em qualquer especificao inicial do sistema do usurio so mapeados nos tipos funcionais da Anlise de Pontos de Funo: Arquivo Lgico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta Externa (CE) e Sada Externa (SE). Posteriormente, os Pontos de Funo so associados a cada funo identificada, baseando-se nas tabelas de complexidade e de contribuio funcional do CPM (Figura 2). O estimador deve realizar uma leitura no documento inicial de requisitos, buscando informaes relevantes para a identificao de processos elementares. O processo elementar definido como a menor unidade de atividade significativa para o usurio. O processo elementar deve ser completo em si mesmo, independente e deixar a aplicao em um estado consistente [IFPUG, 2010]. Em outras palavras, os processos elementares so funes transacionais independentes, isto , funes seqenciais pertencem a um mesmo processo elementar e funes independentes constituem processos elementares diferentes.
Documentao do Software
Mapeando em nmeros
Uma vez identificado o processo elementar, o estimador deve buscar o entendimento deste para classific-lo em Entrada Externa, Consulta Externa ou Sada Externa. Adicionalmente, o estimador deve descobrir os dados associados ao processo elementar, visando a determinao da complexidade funcional da funo identificada. Caso no seja possvel a identificao da complexidade da funcionalidade em questo, recomenda-se a utilizao da complexidade Mdia. Na anlise do processo elementar tambm so identificados, os grupos de dados lgicos da aplicao, que so classificados como Arquivos Lgicos Internos ou Arquivos de Interface Externa. Caso no seja possvel a identificao da complexidade da funo de dados em questo, recomenda-se a utilizao da complexidade Simples. importante ressaltar que se o estimador identificar mais de um Registro Lgico no Arquivo Lgico Interno, recomenda-se utilizar a complexidade Mdia. A seguir so apresentadas dicas para ajudar no mapeamento dos requisitos funcionais da aplicao nos tipos funcionais da APF. As necessidades e funcionalidades especificadas para o projeto, contidas no documento inicial de requisitos, devem ser enquadradas em uma das seguintes tabelas:
10
Tabela 1 - Contagem dos Arquivos Lgicos Internos (ALIs): Banco de Dados Lgico da Aplicao (tabelas e arquivos mantidos pela aplicao). Consideraes: Identifique os grupos de dados lgicos de aplicao nos modelos de dados ou diagrama de classes ou a partir dos requisitos funcionais, descritos nos documentos de requisitos (Documento de Viso, Relao de Casos de Uso, etc.). No considere arquivos fsicos, arquivos de ndices, arquivos de trabalho e tabelas de relacionamento sem atributos prprios (tabelas que existem para quebrar o relacionamento nxn e apenas transportam as chaves estrangeiras). As entidades fracas tambm no so consideradas um ALI. Se possvel, tente descobrir os atributos lgicos, campos reconhecidos pelo usurio, e subgrupos de dados existentes para obter a complexidade funcional, segundo as regras de contagem do CPM. Caso no seja possvel, a experincia tem mostrado que a maioria dos ALIs dos sistemas so de complexidade Simples.
N ALIs Simples: N ALIs Mdio: N ALIs Complexo: Total PF da Tabela 1: Tabela 1: Identificao dos Arquivos Lgicos Internos da Aplicao X 7 PF X 10 PF X 15 PF
Tabela 2 - Contagem de Arquivos de Interface Externa (AIEs): Banco de Dados de outras Aplicaes, apenas referenciados pela aplicao que est sendo estimada (tabelas e arquivos mantidos por outra aplicao). Consideraes: Identifique os grupos de dados lgicos de outras aplicaes referenciados pela aplicao que est sendo estimada. Freqentemente, o referenciamento de dados ocorre para a validao de informaes em cadastros ou consultas. Algumas vezes, relatrios ou consultas referenciam dados externos de outras aplicaes, tambm considerados AIEs. No so considerados arquivos fsicos, arquivos de ndice, arquivos de trabalho, tabelas de relacionamento sem atributos prprios e entidades fracas.
11
Geralmente, os AIEs dos sistemas possuem a classificao de complexidade Simples. Porque, so considerados para a determinao da complexidade funcional do AIE apenas os atributos referenciados pela aplicao que est sendo contada.
N AIEs Simples: N AIEs Mdio: N AIEs Complexo: Total PF da Tabela 2: Tabela 2: Identificao dos Arquivos de Interface Externa da Aplicao X 5 PF X 7PF X 10 PF
Tabela 3 - Contagem de Entradas Externas (EEs): Funcionalidades que mantm os Arquivos Lgicos Internos (ALIs) ou alteram o comportamento da aplicao. Consideraes: Identifique as funcionalidades de manuteno de dados. Conte separadamente a incluso, alterao e excluso de dados, isto , cada funo independente de incluso ou alterao ou excluso deve ser contada separadamente. A aplicao possui funes de entrada de dados que alteram o comportamento dela, por exemplo: processamentos batch, ou processamento de informaes de controle? Caso positivo, estas funes tambm devem ser identificadas como Entradas Externas. Se voc no possui conhecimento sobre o processo elementar (funcionalidade analisada), considere as Entrada Externa identificada com complexidade Mdia.
N EEs Simples: N EEs Mdia: N EEs Complexa: Total PF da Tabela 3: Tabela 3: Identificao das Entradas Externas da Aplicao X 3 PF X 4 PF X 6 PF
Tabela 4 - Contagem de Consultas Externas (CEs): funcionalidades que apresentam informaes para o usurio sem a utilizao de clculos ou algoritmos.
12
So os processos elementares do tipo l - imprime, l - apresenta dados, incluindo consultas, relatrios, gerao de outros. Consideraes: Voc est desenvolvendo uma funo para apresentar informaes para o usurio: uma consulta, relatrio, browse, listbox, download, gerao de um arquivo, gerao de arquivo psd, xls? Esta funo no possui clculos ou algoritmos para derivao dos dados referenciados nem altera um Arquivo Lgico Interno, nem muda o comportamento do sistema? Caso positivo, estas funes devem ser identificadas como Consultas Externas. Se voc no possui conhecimento sobre o processo elementar (funcionalidade analisada), considere as Consultas Externas com complexidade Mdia.
N CEs Simples: N CEs Mdia: N CEs Complexa: Total PF da Tabela 4: Tabela 4: Identificao das Consultas Externas da Aplicao X 3 PF X 4 PF X 6 PF
Tabela 5 - Contagem de Sadas Externas (SEs): Funcionalidades que apresentam informaes para o usurio com utilizao de clculos ou algoritmos para derivao de dados ou atualizao de Arquivos Lgicos Internos ou mudana de comportamento da aplicao. So as consultas ou relatrios com totalizao de dados, relatrios estatsticos, grficos, gerao de arquivos com atualizao log, downloads com clculo de percentual, entre outros. Consideraes: Voc est desenvolvendo uma funcionalidade para
apresentar informaes para o usurio: uma consulta ou relatrio com totalizao de dados, etiquetas de cdigo de barras, grficos, relatrios estatsticos, download com percentual calculado, gerao de arquivo com atualizao de log? Caso positivo, estas funes devem ser identificadas como Sadas Externas. Observe que esta funo deve ter clculos ou algoritmos para processar os dados referenciados nos arquivos lgicos ou atualizar campos (normalmente indicadores) nos arquivos ou mudar o comportamento da aplicao.
13
Caso no haja conhecimento da aplicao de APF ou sobre o processo elementar (funcionalidade analisada), considere as Sadas Externas com complexidade Mdia.
N SEs Simples: N SEs Mdia: N SEs Complexa: Total PF da Tabela 5: Tabela 5: Identificao dos Sadas Externas da Aplicao X 4 PF X 5 PF X 7 PF
A Estimativa de tamanho do projeto em PFs deve ser gerada totalizando-se os PFs obtidos nas Tabelas 1, 2, 3, 4, e 5. A frmula de contagem ou de estimativa de Pontos de Funo para Projetos de Desenvolvimento a seguinte:
Observao: PF_Converso: Pontos de Funo associados s funcionalidades de converso de dados dos projetos. Exemplos de funes de converso incluem: migrao ou carga inicial de dados para popular as novas tabelas criadas no sistema e relatrios associados migrao de dados.
O modelo simplificado de estimativas consiste em obter um ndice de produtividade em horas/PF para o projeto especfico em questo, e ento multiplicar o tamanho em PF do Projeto pelo ndice de produtividade, conforme a frmula [Vazquez, 2010]: Esforo (horas) = Tamanho (PF) x ndice de Produtividade (HH/PF) O ndice de produtividade depende de diversos atributos dos projetos, dentre outros: plataforma tecnolgica, complexidade do domnio, segurana, desempenho, usabilidade, tamanho do projeto, tipo de manuteno, desenvolvimento de componentes. Assim, com base em anlise de dados histricos de projetos do SERPRO, Benchmarking e anlise de literatura especfica, foi definida uma Tabela de Produtividade do SERPRO para ser utilizada nas estimativas de esforo da empresa. Esta tabela revisada com a periodicidade bimestral, considerando o feedback das equipes de desenvolvimento da empresa e novas anlises de dados. A poltica de preos do SERPRO foi estabelecida com base na anlise de dados histricos dos projetos da empresa. Considerando um projeto de desenvolvimento de uma soluo, alm da construo do sistema, dimensionada por meio da mtrica Pontos de Funo, podem ser necessrias outras atividades de consultoria ou anlise. A 2008]: EP = QHC + QHA + (QPF x EPF) Onde: QHC = Quantidade de Horas Perfil Consultor QHA = Quantidade de Horas Perfil Analista QPF = Tamanho do Projeto em PF EPF = Esforo para implementar um PF na plataforma em questo frmula utilizada para o clculo de esforo total de um projeto (EP) a seguinte [SERPRO,
15
3.2.1 Distribuio de Esforo por Fase do Projeto O prximo passo a definio da distribuio de esforo pelas macroatividades do projeto, visando definir o valor agregado ao projeto aps cada fase do ciclo de vida (Tabela 5).
Macro Atividades do Processo de Desenvolvimento de Software Engenharia de Requisitos Design, Arquitetura Implementao Testes Homologao Implantao Percentual de esforo (%) 25% 15% 40% 10% 5% 5%
A Tabela 5 uma sugesto de distribuio de esforo em projetos tpicos, no entanto, em se tratando um projeto com caractersticas especficas, estes percentuais devem ser alterados para o projeto em questo. Nesses casos, o estimador deve justificar, com observaes no documento de estimativas, as premissas utilizadas para a alterao dos percentuais. Os contratos estabelecidos com os clientes devem determinar o processo de desenvolvimento a ser seguido com percentual de esforo por fases.
consequentemente maior o custo do projeto. O aumento do esforo para reduzir o prazo acontece atravs da realizao de horas-extras e da incluso de pessoal adicional, gerando retrabalho. No entanto, a reduo de prazo tem um limite, como demonstra a regio impossvel da Figura 3 .
O mtodo utilizado para estimar o prazo dos projetos (Td) baseado na frmula de Capers Jones [Jones, 2007]. Posteriormente, pretende-se implantar o modelo COCOMO II para obteno de mais de uma estimativa de prazo para o projeto. A frmula de Capers Jones estima o prazo, baseando-se no tamanho do projeto em Pontos de Funo, da seguinte maneira:
Td = Vt
Onde: Td: prazo de desenvolvimento V: tamanho do projeto em Pontos de Funo t: o expoente t definido de acordo com a Tabela 6
17
Tipo de Sistema Sistema Comum Mainframe (desenvolvimento de sistema com alto grau de reuso ou manuteno evolutiva) Sistema Comum WEB ou Cliente Servidor Sistema OO (se o projeto OO no for novidade para equipe, no tiver o desenvolvimento de componentes reusveis, considerar sistema comum) Sistema Cliente/Servidor (com alta complexidade arquitetural e integrao com outros sistemas) Sistemas Gerenciais complexos com muitas Datawarehousing, Geoprocessamento, Workflow Software Bsico, Frameworks, Sistemas Comerciais
Tabela 7: Expoente t por tipo de Projeto
integraes,
importante destacar que o mtodo s funciona para projetos com mais de 100 PFs. Caso o projeto seja menor, o prazo deve ser obtido por meio de WBS. O prazo calculado considera todo o ciclo de vida do projeto, desde a fase de requisitos at a implantao. Assim, caso a estimativa tenha sido realizada ao final da fase de requisitos, descontar do prazo restante, o tempo gasto com a fase de requisitos. Caso o cliente precise receber o projeto em um prazo menor que o Td calculado, recomenda-se propor um processo de desenvolvimento incremental, priorizando funcionalidades em cada iterao de acordo com a necessidade dele. Caso, ainda assim, a estimativa no atenda s necessidades do cliente, ento podese reduzir o Td em at 25%, observando-se a Regio Impossvel. No entanto, quanto mais perto da Regio Impossvel, o esforo e o custo do projeto aumentam de maneira exponencial. Assim, de um modo geral, a reduo de prazo de 10 % implica no aumento de esforo de 25%; a reduo de prazo de 20% implica no aumento de esforo de 50% ; a reduo de prazo de 25% implica em um aumento de esforo de 60%. No recomendada a reduo de prazo em mais de 20%. Na seo seguinte abordada a questo da distribuio de esforo e alocao de pessoas ao projeto em questo.
18
3.3.1 Alocao de Equipe ao Projeto Na alocao de equipe, deve ser considerada a estimativa de prazo e a de esforo. A frmula utilizada a seguinte: Equipe = Esforo (HH) / (21 x prod. diria x Prazo ) Onde: prazo = Td em meses Prod. Diria = 6h/dia ou 7h/dia (recomenda-se considerar 6 horas/dia) 21 = dias teis contidos em 1 ms O tamanho da equipe obtido em quantidade de recursos para o desenvolvimento do projeto, deve-se considerar percentuais de alocao. Por exemplo, suponha uma Equipe de 2,2 recursos. Esta equipe pode conter 5 pessoas, sendo que 4 pessoas com 50% de alocao e um lder de projeto com 20% de alocao ao projeto.
Caso o contrato seja de preo fixo por Ponto de Funo, ento pode-se considerar o seguinte: CP = (QHC x VPC) + (QHA x VPA) + (QPF x VPF) Onde: VPF = Valor Unitrio do PF para o projeto em questo - Identificado de acordo com a Tabela de Servio Padro do Sistema de Oramento Tcnico do SERPRO. importante destacar que como o esforo para a construo do PF varivel, o preo do PF tambm varivel de acordo com os requisitos no funcionais do projeto. A poltica de preos do SERPRO define o preo do Ponto de Funo (VPF) para os diversos tipos de projetos da empresa.
do Recurso Computacional: [considere exclusivamente hardware: micro, perifrico, expanso de memria, rea em disco, banda de rede, etc] Descrio: Responsvel pela Disponibilizao: Data Limite:
Parmetros: Tipo
do Recurso: [D: recurso para ambiente de Desenvolvimento; P: recurso para ambiente de Produo; H: recurso para ambiente de Homologao]
Custo
(Opcional): [Custo do recurso computacional. No considerar custos de processamento ou custos operacionais de produo.] Caso o projeto a ser desenvolvido no possua nenhum recurso computacional crtico, deve ser registrado no documento de estimativas que o projeto no possui nenhum recurso computacional crtico.
20
21
funcionalidades (grupos de dados ou processos elementares), demandas de excluso de funcionalidades (grupos de dados ou processos elementares) e demandas de alterao de funcionalidades (grupos de dados ou processos elementares) em aplicaes implantadas em produo. Uma funo de dados (Arquivo Lgico Interno ou Arquivo de Interface Externa) considerada alterada, quando a alterao contemplar mudanas de item de dados, incluso ou excluso de item de dados. Ou mudana de tamanho (nmero de posies) ou tipo de campo (por exemplo: mudana de numrico ou alfanumrico), sendo que esta ocorre por mudana de regra de negcio do usurio. Uma funo transacional (Entrada Externa, Consulta Externa e Sada Externa) considerada alterada, quando a alterao contemplar: Mudana de itens de dados em uma funo existente; Mudana de arquivos referenciados; Mudana de lgica de processamento, segundo as aes das lgicas e processamento do CPM 43: A Lgica de Processamento definida como requisitos especificamente solicitados pelo usurio para completar um processo elementar. Esses requisitos devem incluir as seguintes aes: Validaes so executadas Frmulas matemticas e clculos so executados Valores equivalentes so convertidos Dados so filtrados e selecionados atravs da utilizao de critrios Condies so analisadas para verificar quais so aplicveis Um ou mais ALIs so atualizados Um ou mais ALIs e AIEs so referenciados Dados ou informaes de controle so recuperados Dados derivados so criados atravs da transformao de dados existentes, para criar dados adicionais O comportamento do sistema alterado Preparar e apresentar informaes para fora da fronteira Receber dados ou informaes de controle que entram pela fronteira da aplicao
22
Dados so reordenados A contagem ou estimativa de Pontos de Funo de projetos de manuteno evolutiva deve seguir a frmula de enhancement do CPM 4.3: PF = (PF INCLUIDO + PF ALTERADO + PF_CONVERSO + PF EXCLUIDO ) Definies: PF_INCLUDO = Pontos de Funo associados s novas funcionalidades que faro parte da aplicao. PF_ALTERADO = Pontos de Funo associados s funcionalidades existentes na aplicao que sero alteradas no projeto de manuteno. PF_EXCLUDO = Pontos de Funo associados s funcionalidades existentes na aplicao que sero excludas no projeto de manuteno. PF_CONVERSO = Pontos de Funo associados s funcionalidades de converso de dados dos projetos de melhoria. Exemplos de funes de converso incluem: migrao ou carga inicial de dados para popular as novas tabelas criadas e relatrios associados migrao de dados.
23
Quando o sistema em produo for desenvolvido pelo SERPRO, a manuteno corretiva ser do tipo Garantia, no sendo cobrada do cliente, desde que o prazo da solicitao seja inferior a 180 dias da data do recebimento da funcionalidade em questo. Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades corrigidas considera 30% do PF_Alterado, observando os conceitos do CPM 4.3, apresentados na seo 4.1. PF = PF_ALTERADO x 0,30
Quando o sistema no for desenvolvido pelo SERPRO, esta manuteno dever ser cobrada do cliente. A estimativa e dimensionamento de tamanho de projetos de manuteno corretiva em Pontos de Funo devem levar em considerao a documentao do sistema disponvel e os artefatos a serem mantidos. Seguem as frmulas a serem consideradas:
a)Aplicao
documentao incompleta e sem redocumentao de requisitos Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades corrigidas considera 70% do PF_Alterado, observando os conceitos do CPM 4.3, apresentados na seo 4.1. PF = PF_ALTERADO x 0,70 b)Aplicao sem documentao ou com documentao desatualizada ou incompleta ou completa e com redocumentao de requisitos Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades corrigidas considera 80% do PF_Alterado, seguindo os conceitos do CPM 4.3, apresentados na seo 4.1. Deve-se destacar que alm da correo as funcionalidades em questo e da documentao do projeto de manuteno corretiva realizado, a documentao das funcionalidades deve ser atualizada.
24
PF = PF_ALTERADO x 0,80 c)Aplicao com documentao completa Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades corrigidas considera 60% do PF_Alterado, seguindo os conceitos do CPM 4.3, mostrados na seo 4.1. Deve-se ressaltar que no h necessidade de correo da documentao do sistema, apenas dos artefatos associados correo do cdigo. PF = PF_ALTERADO x 0,60
Esta seo visa apresentar alguns tipos manutenes adaptativas associadas s mudanas em requisitos no funcionais da aplicao, a saber: Redesenvolvimento de projetos em outra plataforma, Atualizao de plataforma, Adequao de funcionalidades s mudanas de negcio. Caso sejam identificados outros tipos de projetos de manuteno adaptativa em requisitos no funcionais, estes devem ser definidos e incorporados nesse Roteiro de Contagem. 4.4.1. Redesenvolvimento de Projetos em outra Plataforma So considerados nesta categoria, projetos que precisam ser migrados para outra plataforma. Por exemplo, um sistema legado em COBOL precisa ser redesenvolvido em JAVA. Como estes projetos legados, freqentemente, encontram-se sem
documentao, ento sero considerados como novos projetos de desenvolvimento. Assim, ser utilizada a frmula de Projetos de Desenvolvimento do CPM 4.3. PF = PF_NO_AJUSTADO + PF_CONVERSO
PF_CONVERSO = Pontos de Funo associados s funcionalidades de converso de dados dos projetos de desenvolvimento. Exemplos de funes de converso incluem: migrao ou carga inicial de dados para popular as novas tabelas criadas e relatrios associados migrao de dados. 4.4.2. Atualizao de Plataforma So consideradas nesta categoria, demandas para uma aplicao existente ou parte de uma aplicao existente executar em verses mais atuais de browsers (ex: verso atual do Internet Explorer, Mozila, Firefox,...) ou de linguagens de programao (ex: verso mais atual do JAVA ou do Banco de Dados). Tambm so consideradas nesta categoria aplicaes Web desenvolvidas para executar em Internet Explorer que precisam executar tambm em browser em software livre. Nesta categoria foram observadas demandas dos seguintes tipos:
26
A)Atualizao de Plataforma com necessidade de redocumentao de requisitos Nestes casos, a aferio do tamanho em Pontos de Funo da aplicao ou da parte da aplicao que sofreu impacto considera 50% dos PFs, seguindo a frmula de projetos de desenvolvimento do CPM 4.3 e as funes de converso de dados, se aplicvel. Deve-se destacar que alm da adequao as funcionalidades em questo e da documentao do projeto de manuteno adaptativa realizado, a documentao das funcionalidades deve ser atualizada. PF = (PF_NO_AJUSTADO x 0,50) + PF_CONVERSO
B)Atualizao de Plataforma sem necessidade de redocumentao de requisitos Nestes casos, a aferio do tamanho em Pontos de Funo da aplicao ou da parte da aplicao que sofreu impacto considera 40% dos PFs, seguindo a frmula de desenvolvimento do CPM 4.3 e as funes de converso de dados, se aplicvel. PF = (PF_NO_AJUSTADO x 0,40) + PF_CONVERSO
4.4.3.Adequao de Funcionalidades s Mudanas de Negcio So consideradas nesta categoria as demandas de manuteno adaptativa associadas adequao de funcionalidades s mudanas de regras de negcio ou de Legislao ou requisitos de usabilidade que no se enquadram nas funes alteradas do Projeto de Melhoria, seguindo as regras de contagem do CPM. Observe que tais solicitaes envolvem aspectos no funcionais, sem alterao em requisitos funcionais. Por exemplo: replicao de funcionalidade (chamar uma consulta existente na aplicao de outra tela, por demanda do usurio); replicao de base de dados ou criao de base temporria para resolver problemas de performance ou segurana; Alterao no software para adaptao s alteraes
27
realizadas em rotinas de integrao com outros software (ex: alterao em subrotinas chamadas por este software). Nesta categoria foram observadas demandas dos seguintes tipos: A)Adequao de funcionalidades com necessidade de redocumentao Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades que sofreram impacto deve considerar 80% do PF_Alterado, seguindo os conceitos do CPM 4.3, apresentados na seo 4.1. Deve-se destacar que alm da adequao das funcionalidades em questo e da documentao do projeto de manuteno adaptativa realizado, a documentao das funcionalidades deve ser atualizada. PF = PF_ALTERADO x 0,80 B)Adequao de funcionalidades sem necessidade de redocumentao de requisitos Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades que sofreram impacto deve considerar 70% do PF_Alterado, seguindo os conceitos do CPM 4.3, apresentados na seo 4.1. No ser contemplada a documentao das funcionalidades nas demandas desta categoria. PF = PF_ALTERADO x 0,70 Para outros tipos de projetos de manuteno adaptativa no definidos neste documento, considerar um percentual do PF_Alterado, variando de 30% a 80%, de acordo com as caractersticas do requisito no funcional alterado. As premissas utilizadas devem ser acordadas entre o SERPRO e o cliente e documentadas no documento de estimativas do projeto.
28
4.5.1. Apurao Especial Base de Dados Uma apurao especial um projeto que inclui a gerao de procedimentos para atualizao da base de dados. Deve-se destacar que estas funes so executadas apenas uma vez, no fazendo parte da aplicao, visando a correo de dados incorretos na base de dados da aplicao ou atualizao em funo de modificao da estrutura de dados, por exemplo incluso do indicador de matriz sim ou no para um CNPJ. Nestes casos, a contagem de Pontos de Funo das funcionalidades desenvolvidas. Geralmente, estas funcionalidades so classificadas como Entradas Externas. PF = PF_NO_AJUSTADO Deve-se ressaltar que as funes de converso de dados (carga inicial de dados que ocorre na implantao de projetos de desenvolvimento ou de melhoria) no so apuraes especiais. Estas funes fazem parte do projeto de desenvolvimento ou de melhoria em questo, portanto devem ser contadas junto com estes projetos e no como apurao especial. Assim, nestes casos, considerase as frmulas de contagem de Pontos de Funo dos projetos em questo. Em alguns casos de Apurao Especial Atualizao de dados, o usurio solicita uma consulta prvia das informaes atualizadas para validao. De fato,
29
uma prtica interessante para evitar informaes errneas na base de produo dos sistemas. Esta Consulta Prvia, classificada como Consulta Externa ou Sada Externa deve ser dimensionada, considerando-se 60% do tamanho da funcionalidade em questo, conforme a frmula abaixo: PF = PF_NO_AJUSTADO x 0,60
4.5.2. Apurao Especial Gerao de Relatrios Uma apurao especial um projeto que inclui a gerao de relatrios em uma ou mais mdias para o usurio. Em alguns casos, so solicitadas extraes de dados e envio dos dados para outros sistemas. Caso neste envio de dados sejam requisitadas atualizaes no sistema de origem, ento estas funes so Sadas Externas, devido atualizao do Arquivo Lgico Interno. Deve-se destacar que estas funes so executadas apenas uma vez, no fazendo parte da aplicao. Nestes casos, considera-se contagem de Pontos de Funo das funcionalidades desenvolvidas. Freqentemente, estas funcionalidades so classificadas como Sadas Externas. Tambm podem ser classificadas como Consultas Externas, caso no possuam clculos ou criao de dados derivados. PF = PF_NO_AJUSTADO
31
Caso a demanda seja a gerao de artefatos de documentao de todas as fases do processo de desenvolvimento, deve-se considerar um percentual mais alto de 30% a 50%, dependendo dos artefatos a serem gerados. As premissas utilizadas devem ser acordadas entre o SERPRO e o cliente e documentadas no documento de estimativas do projeto.
32
nesta
categoria
programao, ferramentas de gesto, processos, modelos da qualidade, mtricas, etc. Estes servios so executados por consultores do SERPRO, especialistas no assunto em questo. Assim, devem ser consideradas as horas de consultoria para preparao e execuo do curso e o custo do deslocamento do instrutor, se for o caso.
Desenvolvimento
demandas de desenvolvimento de um curso na modalidade de Ensino a Distncia (EaD). Estas demandas devem ser remuneradas em horas.
demandas de elaborao de documentao contendo o mapeamento de processos de negcio de uma organizao ou de parte de uma organizao. Estes servios so executados por consultores do SERPRO, especialistas em BPM (Business Process Modeling).
encontram-se nesta categoria demandas para elaborao de PDTIs para clientes. Estes servios so executados por consultores do SERPRO, especialistas nas atividades associadas elaborao de um PDTI.
nesta categoria demandas para definio de Processos de Software, aderentes s melhores prticas do CMMI e IN04. Estes servios so executados por consultores do SERPRO, especialistas nas atividades de processos de software e na customizao da ferramenta para criao do site do processo.
34
Outros servios prestados que tambm no possuem Pontos de Funo associados so os seguintes:
Administrao
nmero de profissionais defino junto ao Cliente, dedicada para atender as demandas associadas definio e manuteno do modelo de dados de negcio do cliente. Esta equipe fica disponvel em horrio comercial para atendimento das demandas. Assim, estes servios no possuem contagem de PF associada. importante ressaltar que as atividades de banco de dados associadas ao projeto de desenvolvimento ou de manuteno, por exemplo, preparao de ambiente pelos (testes, da homologao, equipe de implantao), desempenhadas DBAs
serem implementadas em solues de TI realizado por consultores especialistas do SERPRO. As demais modalidades de consultoria tambm podem ser enquadradas neste item, por exemplo, Consultoria em Mtricas. Estas demandas no possuem contagem de PF associada. Outras atividades contidas em um processo de software devem ser gerenciadas dentro do projeto de desenvolvimento ou de manuteno, no entanto o esforo deve ser considerado separadamente da estimativa de esforo derivado da contagem de Pontos de Funo. Estas atividades tambm devem ser precificadas a parte. So elas:
utilizao do sistema a ser implantado para os gestores de soluo do cliente e usurios. O esforo deste servio deve ser considerado separadamente da estimativa de esforo derivada da contagem de PF. O preo deste servio deve ser calculado, levando-se em conta o preo da hora dos consultores do
35
SERPRO que estaro realizando atividades de preparao de treinamento e de instrutoria. Em alguns casos, pode ocorrer tambm o deslocamento do instrutor, que tambm deve ser cobrado do cliente. Deve-se ressaltar que este treinamento para implantao pode ser definido na modalidade de EaD, sendo tratado como um projeto de treinamento a parte. O esforo deste considerado dentro do projeto de EaD que no faz parte do projeto de desenvolvimento ou manuteno em questo.
executada em uma demanda de projeto de desenvolvimento e/ou de manuteno. O objetivo desta atividade gerar a Especificao da demanda. O principal produto gerado nesta atividade o artefato: Documento de Viso do Projeto (DV), que deve ser validado pelo cliente, por meio da assinatura do termo de aceite. Alm do DV podem ser gerados outros documentos, tais como: atas de reunio, documento de requisitos no funcionais e glossrio da especificao de negcio. O esforo desta atividade deve ser considerado separadamente da estimativa de esforo derivada da contagem de PF. importante ressaltar que esta atividade de responsabilidade dos Analistas de Negcios da empresa contratante, de acordo com a Instruo Normativa (IN 04). Portanto. Caso o cliente demande para o SERPRO a realizao desta atividade, esta deve ser cobrada em horas de consultoria. Observe que o Documento de Viso gerado nessa atividade o insumo para o planejamento (estimativas) e a atividade de Engenharia de Requisitos do processo de No captulo seguinte - Consideraes desenvolvimento de software.
36
Desenvolvimento de Software Engenharia de Requisitos Design, Arquitetura Implementao Testes Homologao Implantao
Por exemplo, suponha um relatrio de clientes em que no final da fase de implementao foi solicitada a exibio de uma nova informao. A equipe de desenvolvimento ter um retrabalho de vrias fases do ciclo de vida. Assim, o tamanho dessa mudana deve ser calculado da seguinte maneira: -Tamanho do relatrio de clientes (original) SE M 5 PF -Tamanho do relatrio de clientes (alterado) SE M- 5 PF O requisito alterado ser considerado 100% do PF, supondo que este ser entregue ao cliente sem passar por novas alteraes. Para o requisito original ser considerado o seguinte: Engenharia de Requisitos Design, Arquitetura Implementao 25% 15% 40%
esforo contidas na Seo 6.1 ou alguma diretriz especfica de distribuio de esforo do contrato em questo. O Fator de Impacto deve ser aplicado na contagem de Pontos de Funo das funcionalidades em questo. importante ressaltar que em um processo de desenvolvimento incremental uma funcionalidade pode por exemplo estar em fase de requisitos e de testes, porque o plano de testes construdo na fase de requisitos. O Progresso das atividades executadas em cada funcionalidade do projeto deve ser obtido por meio do acompanhamento do plano do projeto.
Reduo de prazo de 10%: aumento de esforo de 20% (projetos urgentes) Reduo de prazo de 20%: aumento de esforo de 50% (projetos crticos) de prazo de 25%: aumento de esforo de 60% (projetos de alta
Reduo
criticidade) Deve-se ressaltar que no possvel uma reduo de prazo maior que 25 %, devido aos clculos de Regio Impossvel e ainda conforme nos aproximamos da regio impossvel, o esforo e o custo do projeto aumentam de maneira exponencial.
39
Como os riscos da reduo de cronograma tambm so altos, no recomendada a reduo de cronograma. Deve-se tentar priorizar funcionalidades trabalhando com o ciclo de vida incremental. Caso o contrato seja baseado em preo por Pontos de Funo, este aumento de esforo ser refletido na contagem de PF. Assim, um aumento de esforo de 20% implica em aumento de 20% na contagem de PF; aumento de esforo de 50% implica em aumento de 50% na contagem de PF; o aumento de esforo de 60% implica em aumento de 60% na contagem de PF.
Pontos de Negcios (PN): esta mtrica deve ser aferida considerando 10% dos Pontos de Funo No Ajustados estimados com base nas funcionalidades identificadas e analisadas nos artefatos de negcio. Exemplo Projeto de Data Warehouse: De posse do modelo de dados do DW, devem ser contadas as Tabelas Fato e Tabelas Dimenso, caso no seja possvel identificar a complexidade das mesmas, devido a ausncia dos atributos das tabelas, considera-se a complexidade Simples. Deve-se contar duas entradas externas associadas s cargas das tabelas Fato e das tabelas Dimenso, a complexidade de tais funcionalidades deve ser avaliada como Mdia, considerando a ausncia de definio detalhada das funcionalidades. Para cada Estrela, deve-se considerar uma Sada Externa Complexa, considerando a gerao do Contexto de Anlise. Caso, os relatrios estejam definidos nesta fase, estes devem ser contados como Sadas Externas mdias. Caso contrrio, no sero contados. Deve-se ressaltar que a mtrica definida est em fase experimental. Assim,
esta pode ser utilizada em casos especficos, substituindo a mtrica homem_hora, em acordo entre as partes Contratante e Contratada (SERPRO).
41
Midia: descreve a maneira que os dados ou informaes se movimentam para dentro e para fora de uma fronteira de aplicao, por exemplo, apresentao de dados em tela, impressora, arquivo, voz. Este termo
42
utilizado para incluir, dentre outros: diferentes plataformas tcnicas e formatos de arquivos como diferentes midias.
Mltiplas Midias: quando a mesma funcionalidade entregue em mais de uma midia. Freqentemente, somente uma midia requisitada para um usurio especfico em um determinado momento, por exemplo consulta de extrato bancrio via internet como oposto a consulta de extrato bancrio via terminal do banco.
Multi-Midia: quando mais de uma midia necessria para entregar a funo, por exemplo, uma nova notcia publicada na Internet que apresentada em vdeo e texto. Observe que a notcia completa s apresentada para o usurio se ele ler o texto e assistir o video.
Abordagem Single Instance: esta abordagem no reconhece que a midia utilizada na entrega da funo transacional uma caracterstica de diferenciao na identificao da unicidade da funo transacional. Se duas funes entregam a mesma funcionalidade usando midias diferentes, elas so consideradas a mesma funcionalidade em uma contagem de Pontos de Funo.
Abordagem Multiple Instance: esta abordagem especifica que o tamanho funcional obtido no contexto de objetivo da contagem, permitindo uma funo de negcio ser reconhecida no contexto das midias que so requisitadas para a funcionalidade ser entregue. A abordagem multiple instance reconhece que a midia para entrega constitui uma caracterstica de diferenciao na identificao da unicidade da funo transacional.
Os cenrios descritos nas sees seguintes no representam uma lista completa de situaes de mltiplas midias. O entendimento destes exemplos facilitar o entendimento de outros cenrios envolvendo mltiplas midias. Este Roteiro deve ser atualizado considerando a publicao de novas diretrizes do IFPUG e novos cenrios que emergiro nas contagens de PFs dos projetos dos clientes do SERPRO.
43
7.2 Cenrio 2: Mesmos dados de sada como dados em arquivo e relatrio impresso
Uma aplicao grava dados em um arquivo de sada e imprime um relatrio com informaes idnticas as gravadas no arquivo. Nesses casos, o SERPRO utiliza a abordagem single instance considerando que os dados impressos e os dados apresentados no arquivo de sada sejam idnticos. Assim, apenas uma funcionalidade ser includa na contagem de Pontos de Funo. Caso as lgicas de processamento da gerao do arquivo de sada e do relatrio em papel sejam distintas, o processo elementar no nico e portanto a funcionalidade ser contada duas vezes. Observe que a abordagem multiple instance considera que dados idnticos esto sendo entregues em mais de um tipo de midia e a contagem de PF incluir todas as instncias de tipos de midia. Neste cenrio, duas funes so contadas gerao arquivo e apresentao dos dados impressos.
44
desenvolvimento precisar desenvolver o relatrio nos dois formatos na ferramenta em questo, sero contadas duas funcionalidades. Porque, a lgica de processamento de anlise de condies para verificar quais so aplicveis identificada. No entanto, se a ferramenta de desenvolvimento suportar um gerador de relatrios que o usurio visualize o relatrio em tela e o gerador permita ao usurio imprimir o relatrio, salvar em html ou salvar no formado de valores separados por vrgula, ento o SERPRO contar apenas uma vez, observando que a funcionalidade ser da ferramenta e no da aplicao.
46
47
9. Concluso
Este documento apresentou um guia para o dimensionamento de tamanho de todos os tipos de projetos de software desenvolvidos pelo SERPRO, visando a aderncia de todos os projetos desenvolvidos na empresa ao processo de Planejamento de Projetos de nvel 2 do CMMI e as diretrizes da Instruo Normativa IN04. A estimativa de tamanho utiliza a mtrica de Pontos de Funo No Ajustados como unidade de medida, conforme recomendado nos Acrdos do Tribunal de Contas da Unio (TCU). Como trabalho futuro recomenda-se a reviso e atualizao deste roteiro sempre que se verificar inconsistncia entre alguma definio do IFPUG, seja publicada em verses futuras do CPM ou em White Paper, ou quando for detectado um novo tipo de servio associado ao desenvolvimento de software no previsto neste trabalho. Tambm, pretende-se implantar outros modelos de estimativa de esforo e prazo, por exemplo o COCOMO II, visando a comparao das estimativas de prazo e esforo por mais de um mtodo. O COCOMO II tem sido utilizado pela CETEC na elaborao de Parecer Tcnico de Estimativas para clientes, quando requisitado.
48
Referncias Bibliogrficas
[Boehm, 2000] BOEHM, B.W. Software Cost Estimation With COCOMO II. Prentice Hall, New Jersey, 2000. [Hazan, 2008] HAZAN, C. Anlise de Pontos de Funo: Uma Aplicao nas Estimativas de Tamanho de Projetos de Software. Engenharia de Software Magazine, Edio 2, Devmedia, pp.25-31. [IEEE,1998] IEEE Computer Society. IEEE Standard for Software Maintenance. IEEE Std 1219, 1998. [Meli, 1999] MELI, R.; SANTILLO, L. Function Point Estimation Methods: A Comparative Overview. Proceedings of FESMA 99, Amsterdam, Netherlands, October 1999, pp. 271-286. [IEEE,1998] IEEE Computer Society. IEEE Standard for Software Maintenance. IEEE Std 1219, 1998. [IFPUG,2009] IFPUG. Considerations for Counting with Multiple Media. Release 1.0, September, 2009. [IFPUG,2010] IFPUG. Counting Practices Manual. Version 4.3, January, 2010. [Jones, 2007] JONES, C. Estimating Software Costs. Second Edition, Mc Graw Hill, 2007. [NESMA, 2009] NESMA. Function Point Analysis for Software Enhancement Guidelines. Version 2.2.1, 2009 [Parthasarathy,2007] PARTHASARATHY, M. A. Practical Software Estimation: function point methods for insourced and outsourced projects. Addison Wesley, New York, 2007. [Roetzheim, 2005] ROETZHEIM, W. Estimating and Managing Project Scope for New Development. CrossTalk, Vol. April, 2005.
49
[SERPRO, 2008]
SERPRO. Mtodos para Estimativa de Projetos de Software Baseado em Pontos de Funo. Relatrio do Grupo de Trabalho para Definio da Utilizao de Pontos de Funo nos Servios de Desenvolvimento e Manuteno de Sistemas. 2008.
[Sommerville, 2007] SOMMERVILLE, I. Software Engineering. Pearson Education Limited, 8th Edition, 2007. [Vazquez, 2010] VAZQUEZ, C. E.; SIMES, G. S.; ALBERT, R. M. Anlise de Pontos de Funo: Medio, Estimativas e Gerenciamento de Projetos de Software. 9 Edio. Editora rica, So Paulo.
50
<Nome do Sistema>
Verso 1.0
Histrico da Reviso
Data Verso Descrio Autor Aprovador
51
52
Identificao da Manuteno
Tipo Melhoria (Evolutiva) Corretiva Funcionalidade Fora do Prazo de Garantia Corretiva Funcionalidade No Desenvolvida pelo SERPRO Verificao de erros (Anlise e Soluo de Problemas) Cosmtica Adaptao de Interfaces Adaptativa Requisitos No Funcionais Tipo: Apurao Especial Base de Dados Apurao Especial Base de Dados Consulta Prvia Apurao Especial Emisso de Relatrio Publicao de Pgina em Intranet / Portal / Internet
Descrio dos Requisitos de Manuteno (para cada funcionalidade alterada, utilizar um quadro)
53
Houve mudana na regra de negcio (validaes, lgica de processamento, regras de clculo)? Sim No
54
Considere a tela de parmetros e a de resultados da consulta como apenas uma nica Consulta. Caso a consulta seja do tipo lista e consulta detalhes, considere como funes independentes e preencha quadros diferentes.
Nome da Consulta Total de Campos da Consulta Tabelas Acessadas Total de Campos Afetados = Total de Campos Calculados ou Totalizadores = Existe atualizao de dados (log, indicador...) Sim Campos Includos/Alterados/Excludos No
Houve mudana na regra de negcio (validaes, lgica de processamento, regras de clculo, campos de filtro)? Sim No
d) Relatrios Afetados pela Manuteno Considere a tela de parmetros e a de resultados do relatrio como apenas um nico Relatrio.
Nome do Relatrio Total de Campos no Relatrio
55
Tabelas Acessadas Total de Campos Afetados = Total de Campos Calculados ou Totalizadores = Existe atualizao de dados (log, indicador...) Sim Campos Includos/Alterados/Excludos No
Houve mudana na regra de negcio (validaes, lgica de processamento, regras de clculo, campos de filtro)? Sim No
56
ANEXO II: Modelo de Documento de Contagem de Pontos de Funo para Projetos de Manutenes Pequenos (< 100 PFs)
Histrico da Reviso
Data Verso Descrio Autor Aprovador
Nome Projeto: Nmero do SIGOP / Demanda / RT: Responsvel pela Contagem: Descrio da Solicitao de Mudana:
Descrio da Atividade Contagem PF Tipo de Manuteno / Total PFs
Observaes Relevantes: Conforme a tabela de atividades acima, o total de Pontos de Funo realizados no Projeto _____ na SM _________ de _____ PFs Ajustados.
57