Guia Medicao Ati

Guia de Contagem APF Verso 1.
HISTRICO DE REVISES Data 20/11/2010 01/03/2011 15/12/2012 Verso 1.00 1.1 2.00 Descrio Criao do Guia de Contagem APF Reviso Atualizao das Informaes Autor Clio Santana Gustavo Santos
Guia de Contagem APF ATI www.ati.pe.gov.br
Pg. 2 de 66
SUMRIO 1. INTRODUO ............................................................................................................................................. 5 1.1. Definies, Acrnimos e Abreviaes ............................................................................................. 5 2. OBJETIVOS DO DOCUMENTO .................................................................................................................. 6 3. ESTIMATIVAS DE PROJETO DE SOFTWARE .......................................................................................... 6 3.1. DETALHAMENTO DO PROCESSO DE ESTIMATIVA ................................................................. 10 3.2. PAGAMENTO BASEADO NO CICLO DE VIDA DA ENTREGA ................................................... 16 3.3. ESTIMATIVA DE PRAZO .............................................................................................................. 17 3.4. ESTIMATIVA DE CUSTO .............................................................................................................. 19 4. CONTAGEM DE PONTOS DE FUNO PARA PROJETOS DE MANUTENO .................................. 19 4.1. PROJETOS DE MELHORIA ......................................................................................................... 19 4.2. PROJETOS DE MANUTENO CORRETIVA ............................................................................ 23 4.3. MANUTENO COSMTICA ....................................................................................................... 24 4.4. MANUTENO ADAPTATIVA EM REQUISITOS NO FUNCIONAIS ........................................ 25 4.4.1. REDESENVOLVIMENTO DE PROJETOS EM OUTRA PLATAFORMA ............................. 25 4.4.2. ATUALIZAO DE PLATAFORMA...................................................................................... 26 4.4.3. ADEQUAO DE FUNCIONALIDADES S MUDANAS DE NEGCIO .......................... 27 4.4.4. APURAO ESPECIAL ....................................................................................................... 28 4.4.5. MANUTENO EM PGINAS ESTTICAS DE INTRANET, INTERNET OU PORTAL..... 29 4.4.6. MANUTENO DE DOCUMENTAO DE SISTEMAS LEGADOS .................................. 30 4.4.7. VERIFICAO DE ERROS .................................................................................................. 30 4.4.8. FATOR DE CRITICIDADE DE SOLICITAO DE SERVIO ............................................. 31 4.4.9. PONTOS DE FUNO DE TESTE ...................................................................................... 31 5. ITENS NO MENSURVEIS ..................................................................................................................... 32 6. ASPECTOS NO CONSIDERADOS PELO IFPUG CONSIDERADOS PELA ATI ................................... 34 6.1. MLTIPLAS MDIAS ..................................................................................................................... 34 6.1.1. MLTIPLAS MDIAS ............................................................................................................. 35 6.1.2. MESMOS DADOS DE SADA COMO DADOS EM ARQUIVOS E RELATRIOS IMPRESSO 36 6.1.3. MESMOS DADOS DE ENTRADA BATCH E ON-LINE........................................................ 36 6.1.4. MLTIPLOS CANAIS DE ENTREGA DA MESMA FUNCIONALIDADE ............................. 36 6.1.5. RELATRIOS EM MLTIPLOS FORMATOS ..................................................................... 37 6.2. DATA WAREHOUSE..................................................................................................................... 37 6.3. BUSSINES INTELIGENCE (BI) ....................................................... Error! Bookmark not defined. 6.4. AUTOMAO DE PROCESSOS DE NEGCIO (BPM) .............................................................. 47 6.5. PORTAIS ......................................................................................... Error! Bookmark not defined.
Pg. 3 de 66
6.6. SERVIOS SOA (SERVICES ORIENTED ARCHITECTURE) ....... Error! Bookmark not defined. 7. LIES APRENDIDAS .............................................................................................................................. 52 7.1. CONTRATOS .................................................................................. Error! Bookmark not defined. 7.2. REQUISITOS ................................................................................................................................. 52 7.2.1. GRANULARIDADE X QUANTIDADE DE REQUISITOS...................................................... 52 7.2.2. ATENO A REQUISITOS NO FUNCIONAIS .................................................................. 53 7.2.3. ATENO A RELATRIOS ................................................................................................. 54 8. CONSIDERAES SOBRE A CONTAGEM DE PONTOS DE FUNO ................................................ 55 8.1. CONSIDERAO SOBRE MUDANAS DE REQUISITOS ......................................................... 56 8.2. CONSIDERAO SOBRE PROJETOS CANCELADOS ............................................................. 57 8.3. CONSIDERAES SOBRE REDUO DE CRONOGRAMA..................................................... 57 8.4. CONSIDERAES SOBRE CICLO DE VIDA ITERATIVO INCREMENTAL ............................... 63 8.5. COMO UMA EMPRESA PBLICA PODE SE FILIAR AO IFPUG. ............................................... 63 8.6. CERTIFICAO CFPS ................................................................................................................. 64 9. PROCESSO DE REVISO DO GUIA DE CONTAGEM ............................................................................ 65 9.1. REVISO PARA CORREO DE INCONSISTNCIAS E SITUAES NO PREVISTAS ...... 65 9.2. REVISO PARA ADOO DE NOVAS VERSES DO CPM...................................................... 65 10. CONCLUSO ........................................................................................................................................... 65 REFERNCIAS BIBLIOGRAFIAS ................................................................................................................. 65
Pg. 4 de 66
1. INTRODUO
A Agncia Estadual de Tecnologia da Informao do Estado de Pernambuco (ATI-PE) seguindo o caminho de muitas empresas governamentais brasileiras tm iniciado a utilizao da 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 tais como a independncia da soluo tecnolgica utilizada) e s recomendaes dos rgos de controle do governo federal brasileiro. O Manual de Prticas de Contagem de Pontos de Funo ou (CPM) que hoje se apresenta na verso 4.3 publicado pela International Function Point User Group (IFPUG) publicado em 201 define as regras de contagem de Pontos de Funo. No entanto, a contagem de Pontos de Funo baseada no projeto lgico da aplicao e nas fases iniciais do ciclo de vida do software que considera 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), admitindo normalmente manutenes corretivas e perfectivas. . 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 N 4 DE 12 DE NOVEMBRO DE 2010, 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.
1.1. Definies, Acrnimos e Abreviaes APF: Anlise de Pontos de Funo; CMMI-Acq: Capability Maturity Model Integration for Aquisition CPM: Manual de Prticas de Contagens do IFPUG; MPS.BR: Melhoria de Processo do Software Brasileiro IFPUG: International Function Points Group User (www.ifpug.org); Pg. 5 de 66
PF: Pontos de Funo.
2. OBJETIVOS DO DOCUMENTO
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, proposto por Cludia Hazan (2008). Alm disto, estaro contidas neste manual um conjunto de prticas de contagens que so institucionalizadas pela ATI. Outra seo deste mesmo manual ser destinado a documentar as lies aprendidas da ATI durante o contnuo aprendizado da utilizao da tcnica. Alem destas sees introdutrias, este documento encontra-se organizado da seguinte maneira: A Seo 3 define o processo de estimativas de projetos de software integrado ao processo de acompanhamento de contratos de fornecedores da ATI, indicando o momento de realizao das estimativas e as anlises a serem realizadas; A Seo 4 apresenta diretrizes para a estimativa e a contagem de Pontos de Funo de todos os tipos de projetos de manuteno de software; A Seo 5 descreve as atividades associadas ao processo de contratao cujos itens no so mensurveis pela IFPUG em Pontos de Funo; A Seo 6 apresenta algumas consideraes importantes sobre utilizao de mtricas para dimensionar as mudanas de requisitos, reduo de cronograma e atividades de negcio; A Seo 7 apresenta as lies aprendidas pela ATI na utilizao de pontos por funo, estas lies podem ser dirigidas as prticas de contagens ou at mesmo a forma de escrever os requisitos; A Seo 8 apresenta o processo de reviso deste guia de contagem; Finalmente, a Seo 9 conclui o documento apresentando sugestes para trabalhos futuros.
3. ESTIMATIVAS DE PROJETO DE SOFTWARE

Este Captulo tem como propsito descrever um processo de estimativas de projetos de software aderente ao modelo Capability Maturity Model Integration for Aquisition ( CMMI-Acq), ao modelo de Melhoria de Processo do Software Brasileiro (MPS.BR) e baseado no modelo proposto por Hazan (2008). Neste contexto, so apresentados os sete nveis de mtodos Contagem de Pontos de Funo e quando cada um deles deve ser utilizado para estimar o tamanho dos projetos de software em PF, alguns modelos simplificado de estimativas para estimar o esforo dos projetos em homem_hora (HH), a frmula de Capers Jones para estimar os prazos dos projetos. Ser apresentado tambm nesta seo a integrao do modelo de contagem da ATI ao seu processo de desenvolvimento.
Pg. 6 de 66
A Figura 1 ilustra um processo de Estimativas de Projetos de Software aderente rea de processo de Planejamento do Projeto de Aquisio do nvel 2 do CMMI-ACq. Este processo baseado no modelo da Cludia Hazan (2008) e ser descrito em linhas gerais nos pargrafos seguintes.
Legenda
Identificar a necessidade de contagem para contrato em APF Identificar usurios, reunir documentao e levantar requisitos iniciais da soluo. Determinar escopo da contagem, fronteiras e identificar requisitos funcionais do usurio
Etapas Etapas antes antes do do inicio inicio da da Sprint. Sprint. Etapas Etapas Durante Durante a a Sprint Sprint Etapas Etapas Aps Aps Recebimento Recebimento da da Sprint Sprint Etapas Etapas durante durante a a transao transao entre entre Sprints Sprints
Identificar demandas que sero implementadas na Sprint
Agrupar demandas ligadas ao mesmo requisito funcional.
Realizar contagem estimativa de tamanho funcional da Sprint
Derivar Custo e Prazo da entrega baseado no tamanho funcional.

Base Histrica
Realizar contagem funcional da entrega realizada pelo fornecedor
Reavaliar Custo e Prazo da entrega realizada pelo fornecedor
Atualizar Base Histrica do Projeto baseado na diferenas entre a estimativa e a Medio

Base Histrica
Figura 1: Processo de Estimativas de Projetos de Software
Este processo est inserido no contexto do processo Scrum da ATI. As trs primeiras etapas acontecem no momento de planejar a contratao. Neste momento em que se verificadas solues existentes no mercado, busca por propostas e levantamento das principais caractersticas da soluo, o momento de se dimensionar uma contagem estimativa (o processo de contagem estimativa ser detalhado mais a frente). As etapas na Sprint (vermelho) tem como principal insumo (artefato de entrada) um documento de requisitos. Como as estimativas devem ser realizadas no incio do processo de desenvolvimento de software, ou mesmo da Sprint ento, o artefato utilizado um documento inicial de requisitos, por exemplo: Documento de Viso ou Formalizao Simples de Requisitos utilizados no Mantis da prpria ATI. O estimador deve analisar os requisitos para garantir a qualidade bem como agrupar as demandas no mesmo requisito para evitar a contagens mltiplas do mesmo requisito para s assim estimar o tamanho
Pg. 7 de 66
do projeto de software. Embora nas etapas iniciais possa existir a contagem estimada do sistema, a mesma s serve para dimensionamento do contrato e no para acompanhamento de projeto. Assim, o prximo passo a derivao das estimativas de prazo (cronograma) e (oramento) da demanda com base na estimativa de tamanho e nos dados histricos de projetos concludos da organizao. 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 documentados. 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 ou Sprint concluda, deve-se novamente aferir e documentar o tamanho, prazo e custo 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 e incorporadas a este guia bem como a base histrica. A alimentao contnua desta base histrica (ltima atividade) que ir garantir a ATI uma melhoria das estimativas ao longo do projeto. Desta forma 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. Seu objetivo quantificar uma ordem de grandeza para o total de pontos por funo que sero empregados para construir determinada soluo. 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. 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 Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 8 de 66
resultados da estimativa. Neste momento sero, dependendo do detalhe da documentao sero permitidos 4 nveis de detalhamento de contagem dos seis apresentados pela totalmetrics (2004). O Nvel menos detalhado conhecido por se basear apenas na base histrica. Considere a Figura 2 como um exemplo hipottico de base histrica.
Figura 2: Base histrica do ISBSG e do Meu projeto
O Nvel 6 de contagem dado pela estimativa mais estvel desta base histrica . Suponha que o elemento que menos varia nas contagens histricas da ATI seja a pontuao dos ALIs em relao ao projeto todo. Considerando o projeto acima, os ALIs representam cerca de 27% da pontuao total do projeto. Ento neste caso apenas desejado se calcular a pontuao de todos os ALIS e aplicar a regra de trs. Vale ressaltar que importante escolher a estrutura que menos varia no processo, suponha que para o caso anterior as sadas externas que representam em mdia 12% do total de pontuao dos projetos da ATI, varie entre 0% e 40% ento no um elemento confivel para a escolha da regra de trs. O quinto nvel, conhecido como contagem indicativa, onde necessrio apenas identificar os ALIs e AIEs da aplicao. No necessrio identificar as funes de transao. Mesmo as funes de dados no ser necessrio o seu detalhamento. Identificadas as funes de dados utilizada a frmula a seguir:
PF = 35*N de ALIs + 15*N de AIEs

Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 9 de 66
Estes nmeros de 35 e 15 podem ser calibrados para melhor representar as necessidades da organizao e deve ser guiado pela base histrica da organizao. O quarto nvel conhecido como contagem estimativa da NESMA. Nesta contagem necessrio identificar todas as funes de dados e todas as funes de transao. Para realizar a contagem necessrio considerar todas as funes de dados simples e todas as funes transacionais mdias. Vale ressaltar que estas contagens no devem ser utilizadas em conjunto com o fornecedor, estas contagens so apenas para dimensionar um valor de pontos de funo que um contrato pode precisar. O segundo marco de contagem a contagem intermediria que deve ser realizada antes da execuo de cada demanda. Neste marco j deve existir documentao dos requisitos suficientes para a realizao de uma contagem detalhada que o 3 Nvel de detalhamento proposto pela totalmetrics (2004) e que coincide com a contagem IFPUG considerando as faixas de contagem. Neste momento tambm pode ser realizada a contagem interligada e anotada (1 Nvel) que tem toda rastreabilidade da contagem bem como o detalhamento dos itens de dados. O terceiro marco de contagem a contagem final que deve ser realizada ao final da execuo. Este marco deve ser utilizado para emisso de fatura e pagamento ao fornecedor. Para tal deve-se utilizar os nveis de detalhamento de contagem do 3 at o 1. 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 ressaltar que as mudanas de requisitos tambm sero consideradas no tamanho projeto a ser faturado.. Alm disso, se estas mudanas forem significativas, maiores que a evoluo de requisitos prevista na estimativa inicial, o prazo do projeto deve ser reestimado. Toda mudana de requisito deve passar por uma anlise de impacto da ATI e ser aprovada pelo cliente.
3.1. DETALHAMENTO DO PROCESSO DE ESTIMATIVA

O processo de estimativa utilizado visa aferir o tamanho em PF podendo ser de maneira simplificada para os nveis de detalhamento 4, 5 e 6. Estas contagens simplificadas so baseadas no conhecimento dos requisitos iniciais do projeto e na documentao do contrato. 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 3).
Pg. 10 de 66
Figura 3: Modelo Lgico da Anlise de Pontos de Funo [SERPRO 2010]
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. Uma vez identificado o processo elementar, o estimador deve buscar o entendimento deste para classific-lo em Entrada Externa (EE), Consulta Externa (CE) ou Sada Externa (SE). Adicionalmente, o estimador deve descobrir os dados associados ao processo elementar, visando a determinao da complexidade funcional da funo identificada. . Na anlise do processo elementar tambm so identificados, os grupos de dados lgicos da aplicao, que so classificados como Arquivos Lgicos Internos (ALI) ou Arquivos de Interface Externa (AIE). A determinao do nvel de detalhamento da contagem depende da documentao obtida. Caso seja possvel identificar todas as funes de AIE e ALI o ideal utilizar o 5 Nvel de detalhamento (AIE * 35 + AIE * 15). Quando existe detalhamento suficiente sobre alguma das informaes como ALI, AIE, mais
Pg. 11 de 66
difcil encontrar EE, SE e CE nestas condies pois elas dependem do ALI e AIE, usa-se o 6 nvel de detalhamento. Caso no seja possvel a identificao da complexidade das funcionalidades melhor usar o mtodo da Nesma, ou 4 nvel de detalhe 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 categorias: Arquivos Lgicos Internos (ALI): 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. A pontuao destes elementos segundo o IFPUG est descrita na Tabela 1 Tabela 1: Pontuao dos Arquivos Lgicos Internos [IFPUG 2010]
Pg. 12 de 66
Arquivos de Interface Externa (AIE): 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, a referncia 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. 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. A pontuao destes elementos segundo o IFPUG est descrita na Tabela 2 Tabela 2: Pontuao dos Arquivos de Interface Externa [IFPUG 2010]
Entradas Externas (EE): 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. A pontuao destes elementos segundo o IFPUG est descrita na Tabela 3
Tabela 3: Pontuao das Entradas Externas [IFPUG 2010] Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 13 de 66
Consultas Externas (CE): funcionalidades que apresentam informaes para o usurio sem a utilizao de clculos ou algoritmos. So os processos elementares do tipo l - imprime, l - apresenta dados, incluindo consultas, relatrios, gerao de arquivos pdf, xls, downloads, entre outros. Consideraes: Uma funcionalidade desenvolvida 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. A pontuao destes elementos segundo o IFPUG est descrita na Tabela 4 Tabela 4: Pontuao das Consultas Externas [IFPUG 2010]
Sadas Externas (SE): 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: Uma funcionalidade desenvolvida 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
Pg. 14 de 66
clculos ou algoritmos para processar os dados referenciados nos arquivos lgicos ou atualizar campos (normalmente indicadores) nos arquivos ou mudar o comportamento da aplicao. Caso no haja conhecimento da aplicao de APF ou sobre o processo elementar (funcionalidade analisada), considere as Sadas Externas com complexidade Mdia. A pontuao destes elementos segundo o IFPUG est descrita na Tabela 5 Tabela 5: Pontuao das Consultas Externas [IFPUG 2010]
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:
AFP = ADD + CFP

Onde: AFP Tamanho da Aplicao ADD Tamanho das Funes Entregues Quadro 1: Totalizao da Pontuao em Desenvolvimento de Software [IFPUG 2010] CFP Tamanho das Funes de Converso.
Pg. 15 de 66
A frmula de contagem ou de estimativa de Pontos de Funo para Softwares Prontos a seguinte:
AFP = ADD
Onde: AFP Tamanho da Aplicao ADD Tamanho das Funes Quadro 2: Totalizao da Pontuao para Aplicaes Prontas [IFPUG 2010] Entregues A frmula de contagem ou de estimativa de Pontos de Funo para Projetos de Melhoria a
seguinte:
AFP = ADD + CHGA + CFP + DEL

Onde: AFP Tamanho da Aplicao ADD Tamanho das Funes Entregues CHGA Funes Alteradas CFP Tamanho das Funes de Quadro 3: Totalizao da Pontuao para Aplicaes Prontas [IFPUG 2010] Converso. 3.2. PAGAMENTO BASEADO NO CICLO DE VIDA DA ENTREGA DEL Funes Excludas;
O prximo passo a definio da forma de pagamento baseado pelas entregas, visando remunerar o fornecedor por entrega tornando o processo menos oneroso para o mesmo e incentivando a cumprir resultados. Est facultado a ATI decidir se ir utilizar este tipo de pagamento e em qualquer granularidade, tais como editais ou contratos. Assim a ATI pode inclusive pagar apenas uma porcentagem do valor cheio de uma determinada demanda se partes das entregas no for necessrias naquele contrato. Atualmente a ATU utiliza a seguinte distribuio (Tabela 6).
Pg. 16 de 66
Tabela 6: Remunerao da ATI por fase de Ciclo de Vida
3.3. ESTIMATIVA DE PRAZO

As estimativas de prazo no so lineares com o tamanho do projeto. O melhor tempo de desenvolvimento, no qual h uma melhor relao custo x benefcio de alocao de recursos e menor prazo de desenvolvimento, dado o tamanho de um projeto especfico, sugerido e utilizado nas estimativas de prazo deste manual. Jones [Jones, 2007] prope uma frmula para o clculo do melhor tempo de desenvolvimento, denominado Td e de Regio Impossvel (RI) de desenvolvimento (Figura 4). Na Regio Impossvel (RI), a adio de mais recursos ao projeto no implicar em reduo no prazo. Note que a curva mostra que quanto menor o prazo almejado para a concluso do projeto, maior ser o esforo requerido e 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. O mtodo utilizado para estimar o prazo dos projetos (Td) baseado na frmula de Capers Jones [Jones, 2007]. A frmula de Capers Jones estima o prazo, baseando-se no tamanho do projeto em Pontos de Funo, da seguinte maneira:
Td = V t
Td: prazo de desenvolvimento V: tamanho do projeto em Pontos de Funo t: o expoente t definido de acordo com a Tabela 7
Pg. 17 de 66
Figura 4: Relao entre a Estimativa de Prazo e de Esforo [Jones 2007]
Tabela 7: Expoente t por tipo de Projeto
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 integraes, Datawarehousing, Geoprocessamento, Workflow Software Bsico, Frameworks, Sistemas Comerciais
Expoente t
0,32 a 0,33 0,34 a 0,35 0,36
0,37 0,39 0,40
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 seja necessrio receber o projeto em um prazo menor que o tudo 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 pode-se 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 Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 18 de 66
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%. Os percentuais de aumento de esforo so estimados, podendo ser reajustados conforme avaliao da base histrica dos servios realizados no rgo.
3.4. ESTIMATIVA DE CUSTO

A estimativa de custo do projeto deve levar em considerao o custo de um ponto de funo. A contratada j dever considerar o custo da hora de todos os profissionais envolvidos no desenvolvimento da soluo de software. O clculo do custo do projeto (CP) ser ento da seguinte forma: CP = QPF x CPF Onde: QPF: Tamanho do Projeto em PF CPF: Custo para implementar um Ponto de Funo na plataforma em questo
4. CONTAGEM DE PONTOS DE FUNO PARA PROJETOS DE MANUTENO

Esta seo tem como propsito descrever os diversos tipos de projetos de manuteno e mostrar uma soluo para o seu dimensionamento em Pontos de Funo, visto que o manual de prticas de contagem CPM no contempla projetos de manuteno (maintenance) apenas o de Melhoria (enhancement). Quanto documentao de projetos de manuteno pequenos (menores que 100 PF), deve-se registrar a solicitao e documentar os requisitos da aplicao impactada pela demanda, de forma detalhada, visando apoiar a contagem de Pontos de Funo da demanda. importante tambm documentar as estimativas e a contagem de Pontos de Funo.
4.1. PROJETOS DE MELHORIA

O Projeto de Melhoria (enhancement), tambm denominada de projeto de melhoria funcional, ou manuteno evolutiva, est associado s mudanas em requisitos funcionais da aplicao, ou seja, a incluso de novas funcionalidades, alterao ou excluso de funcionalidades em aplicaes implantadas. Segundo o padro IEEE Std 1229 [IEEE 1998], esta manuteno seria um tipo de manuteno adaptativa, definida como: modificao de um produto de software concludo aps a entrega para mant-lo
Pg. 19 de 66
funcionando adequadamente em um ambiente com mudanas. O projeto de melhoria considerado um tipo de projeto de manuteno adaptativa com mudanas em requisitos funcionais da aplicao, ou seja, com funcionalidades includas, alteradas ou excludas na aplicao, segundo o CPM 4.3. Este documento separa o projeto de melhoria, quando as mudanas so associadas aos requisitos funcionais e a manuteno adaptativa quando as mudanas esto associadas aos requisitos no funcionais da aplicao. Um projeto de melhoria consiste em demandas de criao de novas 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 4.3
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 Dados so reordenados
Pg. 20 de 66
A contagem ou estimativa de Pontos de Funo de projetos de manuteno evolutiva (projetos de melhoria) seguir conforme preconizada pela publicao "Function Point Analysis for Software Enhancement Guidelines" da Nesma Netherlands Software Metrics Users Association [NESMA, 2009], entidade que aprofunda o tema e apresenta alternativas tcnicas proposta original do IFPUG. Contudo recomendado que para contrataes sejam apenas definidas o padres do IFPUG e que caso sejam necessrias a adoo da NESMA (2009) como boas prticas de projetos de melhoria, que ela seja escrita no edital e no citada como NESMA para que no haja confuso do fornecedor sobre quando usarNESMA ou quando usar o IFPUG. Pela NESMA temos: TAMANHO EM PF = (PF INCLUIDO + PF EXCLUIDO + PF ALTERADO + PF CONVERSO)
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, incluso o fator de impacto conforme preconizada pela [NESMA, 2009]. PF_EXCLUDO = Pontos de Funo associados s funcionalidades existentes na aplicao que sero excludas no projeto de manuteno, incluso o fator de impacto conforme preconizada pela [NESMA, 2009]. 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. Importante ressaltar que a contagem dos PF_Converso so efetuadas de forma separada da contagem dos PF_No_Ajustados, por serem de produtividades diferentes, ou seja, ao contar os PF_Converso utilizar produtividade prpria, quando for o caso. Na maioria casos, as operaes de alterao e incluso possuem um tratamento diferenciado em relao incluso, alguns pesos podem ser atribudos a tais tarefas como forma de compensar o esforo e custo associado a tais tarefas. Esta prtica comum no mercado e conhecida como Deflator. A sugesto da NESMA para tal aplicao e a que ser seguida pela ATI : PF_INCLUIDO = QPI; PF_EXCLUIDO = QPE x 0.40;
Pg. 21 de 66
PF_FD_ALTERADO = FD-QPA x FFD, sendo FFD entre 0,25 e 1,00, conforme Tabela 7 (para funes de dados); PF_FT_ALTERADO = FT-QPA x FFT, sendo FFT entre 0,25 e 1,50, conforme Tabela 8 (para funes transacionais); PF_ALTERADO = PF_FD_ALTERADO + PF_FT_ALTERADO. Onde: QPI = Quantidade de Pontos de Funo includos; QPE = Quantidade de Pontos de Funo excludos; PF_FD_ALTERADO = Pontos de Funo alterados para Funes de Dados; PF_FT_ALTERADO = Pontos de Funo alterados para Funes Transacionais; FD-QPA = Quantidade de Pontos de Funo alterados em funes de dados; FT-QPA = Quantidade de Pontos de Funo alterados em funes transacionais; FFD = Fator de impacto de alteraes em funes de dados; FFT = Fator de impacto de alteraes em funes transacionais O clculo dos fatores de impacto obtido atravs dos percentuais de alteraes conforme abaixo: Funes de Dados: Percentual de alteraes em funes de dados (PFD) = QTDEA / (QTDET x 100) QTDEA = Quantidade de Tipos de Dados Elementares Alterados QTDET = Quantidade de Tipos de Dados Elementares Totais Com o valor obtido em PFD, procura-se na tabela qual o valor do fator de impacto: Tabela 7: Calculo do PFD para funo de Dados [NESMA 2009]
PFD Fator de Impacto (FFD)
Fator de Impacto em Funes de Dados Alteradas (FFD) Entre 33% e Entre 66% e Entre 0 e 33% 66% 100% 0,25 0,5 0,75
Maior que 100% 1
Funes Transacionais:
Pg. 22 de 66
Percentual de alteraes em funes transacionais (PFT1) = QTDEA / QTDET x 100 Percentual de alteraes em funes transacionais (PFT2) = QFDLA / QFDLT x 100 QTDEA = Quantidade de Tipos de Dados Elementares Alterados QTDET = Quantidade de Tipos de Dados Elementares Totais QFDLA = Quantidade de Funes de Dados Lgicos Alterados QFDLT = Quantidade de Funes de Dados Lgicos Totais
Tabela 8: Calculo do FFT para funo de Dados [NESMA 2009]
Fator de Impacto em Funes Transacionais Alteradas (FFT) PFT2 / PFT1 Entre 0 e 66% Entre 66% e Maior que 100% 100% Entre 0% e 33% 0,25 0,5 0,75 Entre 33% e 66% 0,5 0,75 1 Entre 66% e 100% 0,75 1 1,25 Maior que 100% 1 1,25 1,5
Caso FFT seja maior que 1, recomenda-se reconsiderar a melhoria.
4.2. PROJETOS DE MANUTENO CORRETIVA

Mesmo com a execuo de atividades de garantia da qualidade, pode-se identificar defeitos na aplicao entregue. A manuteno corretiva altera o software para correo de defeitos. Encontra-se nesta categoria, as demandas de correo de erros (bugs) em funcionalidades em sistemas em produo. importante destacar que as demandas de manuteno corretiva freqentemente precisam ser atendidas com urgncia. Assim, o grau de criticidade do projeto poder trazer impacto nas estimativas de custo e esforo. O padro IEEE [IEEE,1998] define um tipo de manuteno corretiva, denominado de Manuteno Emergencial como manuteno corretiva no programada executada para manter o sistema em estado operacional. Quando o sistema em produo tiver sido desenvolvido pela contratada, a manuteno corretiva ser do tipo Garantia, conforme prazos e demais clusulas do contrato em questo . Quando o sistema no tiver sido desenvolvido pela contratada, dever ser estimado e calculado o tamanho do projeto de manuteno corretiva. A estimativa e dimensionamento de tamanho de projetos de manuteno corretiva em Pontos de Funo devem levar em considerao a documentao do sistema
Pg. 23 de 66
disponvel e os artefatos a serem mantidos sendo aplicados alguns deflatores. Seguem as frmulas a serem consideradas:
a) Aplicao sem documentao ou com documentao desatualizada ou 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 pela contratada.
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
Em todos os trs itens acima, os percentuais de multiplicao so estimados, podendo ser reajustados conforme avaliao da base histrica dos servios realizados no rgo.
4.3. MANUTENO COSMTICA

So consideradas manutenes cosmticas ou Adaptativas Mudana de Interface, as demandas associadas alteraes de interface, por exemplo, fonte de letra, cores de telas, logotipos, mudana de botes na tela, mudana de posio de campos ou texto na tela.
Pg. 24 de 66
Nestes casos, a aferio do tamanho em Pontos de Funo da funcionalidade ou das funcionalidades corrigidas considera 10% do PF_Alterado, seguindo os conceitos do CPM 4.3. No ser contemplada a redocumentao das funcionalidades da aplicao impactadas pela manuteno nas demandas desta categoria.
4.4. MANUTENO ADAPTATIVA EM REQUISITOS NO FUNCIONAIS

Seguindo os conceitos da IEEE, existem vrios tipos de Manuteno Adaptativa. Quando h mudana em requisitos funcionais, estes projetos so denominados de projetos de Melhoria, descritos na seo 4.1. Quando h mudana em requisitos no funcionais de interface, estes projetos so denominados de Manuteno Cosmtica ou Manuteno Adaptativa Mudana de Interface. 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 Manual 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. Importante ressaltar que a contagem dos PF_Converso so efetuadas de forma separada da contagem dos PF_No_Ajustado, por serem de produtividades diferentes, ou seja, ao contar os PF_Converso utilizar produtividade prpria, quando for o caso. Neste caso, poder ser criado um multiplicador conforme avaliao da base histrica dos servios realizados no rgo.
Pg. 25 de 66
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:
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

Nos dois itens acima, os percentuais de multiplicao so estimados, podendo ser reajustados conforme avaliao da base histrica dos servios realizados no rgo.
c) Equalizao de Base de Dados via Scripts
Nesse caso ser considerada a produtividade correspondente a tecnologia envolvida. Ou seja, se para o sistema desenvolvido em Java a produtividade de 10 horas por pontos de funo e sero necessrias 50 horas para realizar tal equalizao nesse caso ser aplicada a seguinte frmula. PF:
quantitativo de horas / Produtividade da tecnologia, ou seja, caso um atividade de equalizao necessite de 50 horas a conta realizada ser 50 / 10 = 5 PF.
d) Adaptao de Aplicao para Multibrowsers
Pg. 26 de 66
e) Ajustes de Infra Estrutura necessrios para aplicaes mais complexas (webservices, certificao digital, ecm.)
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 realizadas em rotinas de integrao com outros software (ex: alterao em sub-rotinas 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.
Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 27 de 66
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.
Nos dois itens acima, os percentuais de multiplicao so estimados, podendo ser reajustados conforme avaliao da base histrica dos servios realizados no rgo. 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. Verses futuras deste Manual devem contemplar os novos tipos no definidos neste documento.
4.4.4. APURAO ESPECIAL

So funcionalidades executadas apenas uma vez para: corrigir problemas de dados incorretos na base dados das aplicaes ou atualizar dados em bases de dados de aplicaes, detalhado no item 4.3.4.1; gerar um relatrio especfico ou arquivo para o usurio por meio de recuperao de informaes nas bases da aplicao. Caso a apurao seja de correo de dados, devido a erros de funcionalidades de aplicaes desenvolvidas pela contratada, observar as clusulas contratuais com relao a garantias e prazos de correo.
4.3.4.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
Pg. 28 de 66
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, considera-se 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, 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.3.4.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
4.4.5. MANUTENO EM PGINAS ESTTICAS DE INTRANET, INTERNET OU PORTAL

Nesta seo so tratadas manutenes especficas em pginas estticas de Portais, Intranets ou Websites. A demanda consiste na publicao de pginas HTML. Estas demandas so consideradas como desenvolvimento de consultas com a utilizao de ferramentas para apoiar a publicao. Nestes casos, considera-se 50% dos Pontos de Funo das consultas desenvolvidas. Cada pgina contada como uma consulta. As consultas so consideradas Consultas Externas Simples (3 PF).
QTD_SIMPLES: Quantidade de Pginas com complexidade Simples PF_SIMPLES: QTD_SIMPLES X 0,5 QTD_INTERMEDIARIA: Quantidade de Pginas com complexidade Intermediria PF_ INTERMEDIARIA: QTD_ INTERMEDIARIA X 0,8 Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 29 de 66
QTD_COMPLEXAS: Quantidade de Pginas com complexidade Complexa PF_ COMPLEXAS: QTD_ COMPLEXAS X 1,2 PF_TOTAL = PF_SIMPLES + PF_INTERMEDIARIA + PF_ COMPLEXAS * Deve ser definido de forma clara como classificar cada pgina em uma das categorias. Exemplo: O Portal XXX ser desenvolvido e foi verificado que o mesmo composto de: 50 pginas simples 20 pginas intermedirias 10 pginas complexas PF_SIMPLES = 50 * 0,5 = 25 PF_INTERMEDIARIA = 20 * 0,8 = 16 PF_COMPLEXA = 10 * 1,2 = 12 PF_TOTAL = 25 + 16 + 12 = 53
4.4.6. MANUTENO DE DOCUMENTAO DE SISTEMAS LEGADOS

Nesta seo so tratadas demandas de documentao ou atualizao de documentao de sistemas legados. Observe que o desenvolvedor deve realizar uma Engenharia Reversa da aplicao para gerar a documentao. Para este tipo de projeto, caso a demanda seja apenas a documentao de requisitos, devem ser considerados 20% dos Pontos de Funo da aplicao em questo, conforme a frmula abaixo.
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 conforme clusulas contratuais e documentadas no documento de estimativas do projeto.
4.4.7. VERIFICAO DE ERROS

So consideradas verificaes de erro ou anlise e soluo de problemas as demandas referentes a todo comportamento anormal ou indevido apontado pelo cliente nos sistemas aplicativos. Neste caso, a equipe de desenvolvimento da ATI se mobilizar para encontrar a(s) causa(s) do problema ocorrido. Se for constatado erro de sistema, a demanda ser atendida como manuteno corretiva. Entretanto, uma vez no constatado o problema apontado pelo cliente ou o mesmo for decorrente de regras de negcio implementadas ou utilizao incorreta das funcionalidades, ser realizada a aferio do tamanho em Pontos de Funo das funcionalidades verificadas, e ser considerado 25%.
Pg. 30 de 66
4.4.8. FATOR DE CRITICIDADE DE SOLICITAO DE SERVIO

Em funo da criticidade e da necessidade de alocao de recursos extras para atendimento da demanda no prazo estipulado pelo cliente, poder ser adotado um Fator de Criticidade de 1,35 (um vrgula trinta e cinco), que dever ser multiplicado pelo tamanho funcional da demanda considerada crtica, de modo a remunerar adequadamente o aumento do esforo de atendimento. Este fator considerado para demandas que devem ser atendidas em finais de semana, feriados e fora do horrio comercial. Entende-se como horrio comercial o horrio local.
4.4.9. PONTOS DE FUNO DE TESTE

Muitas vezes, em projetos de manuteno o conjunto de funes de dados e funes transacionais a serem testadas maior do que a quantidade de funes a serem implementadas, i.e., alm das funcionalidades que so afetadas diretamente pelo projeto de manuteno, outras precisam ser testadas [NESMA, 2009]. O tamanho das funes a serem testadas deve ser aferido em Pontos de Funo de Teste (PFT). No considerar as funcionalidades includas, alteradas ou excludas do projeto de manuteno na contagem de Pontos de Funo de Teste.
A contagem de PFT deve considerar o seguinte [NESMA, 2009]: Determinar o tamanho em Pontos de Funo de cada funo de dados ou transacional envolvida no teste. Calcular o tamanho em Pontos de Funo de todas as funes de dados ou transacionais envolvidas no teste.
A converso do PFT em Ponto de Funo deve ser feita de acordo com a frmula abaixo: PF = PFT x 0,20 importante ressaltar que as funes testadas consideradas no PFT devem estar documentadas. Observe que estas funes faro parte do escopo do projeto de manuteno. Nos itens da seo 4 acima, os percentuais so estimados, podendo ser reajustados conforme avaliao da base histrica dos servios realizados no rgo. Em casos onde no h percentuais, pode-se aplicar algum percentual, tambm conforme avaliao da base histrica dos servios realizados no rgo.
Pg. 31 de 66
5. ITENS NO MENSURVEIS
Deve-se ressaltar que o processo de desenvolvimento de solues possui vrias atividades que devem ser consideradas como um projeto separado, levando-se em conta as horas realizadas, dentre outras: Treinamentos em Tecnologia, Metodologias, Mtricas, etc . encontram-se nesta categoria as demandas de treinamentos em linguagens de programao, ferramentas de gesto, processos, modelos da qualidade, mtricas, etc. Estes servios so executados por consultores de terceiros, 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. Mapeamento de Processos de Negcio : Encontramse nesta categoria as demandas de elaborao e levantamento de documentao contendo o mapeamento de processos de negcio de uma organizao ou de parte de uma organizao. Estes servios so executados por consultores da ATI ou terceiros, especialistas em BPM (Business Process Modeling). Elaborao de Plano Diretor de Tecnologia da Informao (PDTI): encontram-se nesta categoria demandas para elaborao de PDTIs para clientes. Estes servios so executados por consultores do ATI ou terceiros com o apoio dos funcionrios da ATI especialistas nas atividades associadas elaborao de um PDTI. Definio de Processo de Desenvolvimento de Solues : Encontram-se nesta categoria demandas para definio de Processos de Software aderentes s necessidades da ATI e observando as boas prticas de modelos como CMMI, Scrum ou normas como a IN 04. Estes servios so executados por consultores da ATI ou terceiros, especialistas nas atividades de processos de software e na customizao de ferramentas para facilitao do processo. Outros servios prestados que tambm no possuem Pontos de Funo associados so os seguintes: Administrao de Dados: Este servio requer uma equipe de ADs com um nmero de profissionais defino junto ao Cliente/Fornecedor, dedicada para atender as demandas associadas definio e manuteno do modelo de dados de negcio. 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 (testes, homologao, implantao), desempenhadas pelos DBAs da equipe de desenvolvimento, j esto consideradas dentro do projeto de software, no cabendo cobrana adicional.
Pg. 32 de 66
Anlise de Soluo: Servio de apoio destinado anlise de regras de negcio implementadas em solues de TI. Estas demandas no possuem contagem de PF associada. Consultoria: Servio de apoio destinado anlise de regras de negcio a serem implementadas em solues de TI realizado por consultores especialistas da ATI. 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: Treinamento para Implantao: So demandas de treinamentos sobre 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 de terceiros que estaro realizando atividades de preparao de treinamento ede instrutoria. Em alguns casos, pode ocorrer tambm o deslocamento do instrutor, que tambm deve ser cobrado do cliente. Especificao de Negcio: Esta atividade a primeira atividade a ser 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 as legislaes em vigor da ATI. Portanto. Caso o cliente demande para terceiros 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 desenvolvimento de software. Suporte: Esta atividade realizada sob demanda para solucionar diversos tipos de problemas que em sua maioria problemas com infra-estrutura ou apoio a informao (suporte a usurio). A natureza destes servios no so desenvolvimento de software no cabendo de forma alguma a aferio por ponto de funo. Help Desk: Esta atividade realizada com a alocao de pessoas cujo objetivo atender seja por telefone, internet ou presencialmente informaes a respeito de determinados servios da ATI. A forma
Pg. 33 de 66
mais comum de pagamento por este servio por profissional contratado. E mesmo assim, a natureza desse servio tambm no de desenvolvimento de software assim no cabendo pontos por funo.
6. ASPECTOS NO CONSIDERADOS PELO IFPUG CONSIDERADOS PELA ATI

Algumas atividades que no esto presentes no Manual de Prticas de Contagem (CPM 4.3.1) do IFPUG j esto resolvidas dentro do mbito da ATI. Nesta seo iremos apresentar como a ATI considera tais aspectos.
6.1. MLTIPLAS MDIAS

Esta subseo tem como propsito apresentar as diretrizes de Contagem de Pontos de Funo utilizadas na ATI em relao ao tema Mltiplas Mdias. Esta abordagem reconhecida pelo IFPUG. As definies apresentadas tm como base o artigo Considerations for Counting with Multiple Midia Release 1.0 publicado pelo IFPUG [IFPUG, 2009] e pelo Serpro (2010). Considerando-se a contagem de PF de funcionalidades entregues em mais de uma mdia, a aplicao das regras de contagem de Pontos de Funo definidas no CPM tem levado a duas abordagens alternativas, a saber: single instance e multiple instance. A abordagem single instance considera que a entrega de uma funo transacional em mltiplas mdias no deve ser utilizada na identificao da unicidade da funo. A abordagem multiple instance leva em considerao que a mdia utilizada na entrega da funcionalidade uma caracterstica de identificao da unicidade da funo. Assim, funcionalidades nicas so reconhecidas no contexto da mdia na qual elas so requisitadas para operar. importante enfatizar que o IFPUG reconhece ambas abordagens single instance e multiple instance para a aplicao das regras definidas no CPM. A determinao de da contagem de PF seguindo a abordagem multiple instance ou single instance depende do gestor do contrato ou gestor do produto que est relacionada aquela contagem. As estimativas e contagens de PF realizadas pelo ATI sero baseadas na abordagem multiple instance, com exceo dos casos de consultas em .pdf, .doc, .xls e consultas idnticas em tela e papel, que sero consideradas uma nica funcionalidade. A seguir so descritos os termos comuns definidos pelo IFPUG [IFPUG, 2009]: Canal: tambm refere-se a midia. Mltiplos canais sinnimo de mltiplas midias.
Pg. 34 de 66
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 utilizado para incluir, dentre outros: diferentes plataformas tcnicas e formatos de arquivos como diferentes mdias. Mltiplas Mdias: quando a mesma funcionalidade entregue em mais de uma mdia. Freqentemente, somente uma mdia 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 mdia 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 mdia 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 mdias que so requisitadas para a funcionalidade ser entregue. A abordagem multiple instance reconhece que a mdia 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 mdias. O entendimento destes exemplos facilitar o entendimento de outros cenrios envolvendo mltiplas mdias. 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 ATI. Os cenrios descritos nas sees seguintes no representam uma lista completa de situaes de mltiplas mdias. O entendimento destes exemplos facilitar o entendimento de outros cenrios envolvendo mltiplas mdias. 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 ATI.
6.1.1. MLTIPLAS MDIAS

Neste cenrio, uma aplicao apresenta uma informao em uma consulta em tela. A mesma informao pode ser impressa caso requisitado pelo usurio na tela em questo. Nesses casos, a ATI utiliza a abordagem single instance, considerando que dados idnticos sendo apresentados em tela e relatrio impresso devem ser contados como uma nica funo.
Pg. 35 de 66
Caso as lgicas de processamento da consulta em tela 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 a contagem de PF de dados idnticos sendo apresentados usando mais de um tipo de mdia deve incluir toda instncia da funo em cada tipo de mdia. Neste exemplo, duas funes so contadas apresentao de dados em tela; apresentao de dados impressos.
6.1.2. MESMOS DADOS DE SADA COMO DADOS EM ARQUIVOS E RELATRIOS IMPRESSO

Uma aplicao grava dados em um arquivo de sada e imprime um relatrio com informaes idnticas as gravadas no arquivo. Nesses casos, a ATI 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 mdia e a contagem de PF incluir todas as instncias de tipos de mdia. Neste cenrio, duas funes so contadas gerao arquivo e apresentao dos dados impressos.
6.1.3. MESMOS DADOS DE ENTRADA BATCH E ON-LINE

Uma informao pode ser carregada na aplicao por meio de dois mtodos: arquivo batch e entrada on-line. O processamento do arquivo batch executa validaes durante o processamento. O processamento on-line tambm executa validaes das informaes. A abordagem utilizada pela ATI a single instance conta apenas uma funcionalidade. Na ATI porm pode ser considerada a abordagem multiple instance que conta duas funcionalidades: a entrada de dados batch e a entrada de dados on-line quando a lgica de processamento utilizada nas validaes em modo batch diferente da lgica de processamento das validaes nas entradas de dados on-line. Portanto, fica a cargo do gestor de contrato ou produto da ATI definir se ser uma ou duas funcionalidades.
6.1.4. MLTIPLOS CANAIS DE ENTREGA DA MESMA FUNCIONALIDADE

Uma funcionalidade deve ser disponibilizada em mltiplos canais, por exemplo, consulta de dados em pgina Web e consulta de dados no telefone celular. A abordagem single instance conta apenas uma funcionalidade. Na ATI novamente pode ser utilizada a abordagem multiple instance que conta duas funcionalidades: a consulta de dados na Web e a consulta de dados via celular. Considera-se que esta soluo justa quando funcionalidade desenvolvida duas vezes para os dois canais. Algumas vezes, so at projetos de desenvolvimento distintos, um projeto relativo ao sistema Web e outro para o sistema via celular. Portanto, nestes casos a ATI contar duas funcionalidades.
Pg. 36 de 66
6.1.5. RELATRIOS EM MLTIPLOS FORMATOS

Um relatrio deve ser entregue em diferentes formatos, por exemplo em um arquivo html e um formato de valores separados por vrgula. Nestes casos, conforme sugerido na abordagem multiple instance, a ATI considera a ferramenta utilizada na gerao dos relatrios. Se a equipe de 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 a ATI contar apenas uma vez, observando que a funcionalidade ser da ferramenta e no da aplicao.
6.2. DATA WAREHOUSE

Esta subseo tem como propsito apresentar as diretrizes de Contagem de Pontos de Funo utilizadas na ATI em relao ao tema Data Warehouse. Esta abordagem reconhecida pelo IFPUG. As definies apresentadas tm como base o artigo Function Points & Counting Enterprise Data Warehouses Release 1.0 publicado pelo IFPUG [IFPUG, 2007]. Um aspecto crucial da contagem de Data Warehouses que apresentou desafios significativos dos contadores de ponto de funo est em definir a fronteira da aplicao. Uma fronteira impropriamente definida, pode distorcer de forma considervel os resultados da anlise de ponto de funo. Com base nessas regras de definio de fronteira, o que segue abaixo deve ser excludo dos limites da aplicao: Arquivos lgicos mantidos pelo(s) sistema(s) de origem, exceto se eles so referenciados durante o processamento dos arquivos de chegada com os dados. Tabelas Temporrias, Staging Areas, Tabelas de cdigos Data Marts. Estes podem ser contados como fronteiras de aplicaes separadas.
Algumas consideraes incluem: O propsito da contagem, Os usurios so um grupo distinto; ex.: um departamento especfico como marketing, diferente grupo de usurios do Data Warehouse e; A existncia de dados externos alm daquele disponvel dentro do Data Warehouse.
Figura 4 uma representao grfica de como a fronteira de um Data Warehouse pode ser definida.
Pg. 37 de 66
Figura 4: Figura Ilustrativa de um Fronteira de DW A Figura 4 esta mostrando um limite em volta das Staging Areas/Depsito de Dados Operacionais/Data Warehouses e limites em torno de Data Marts especficos. uma representao grfica de como as fronteiras podem ser definidas. Embora este diagrama mostre todos os trs Data Marts fora da fronteira, esse nem sempre pode ser o caso. Acrnimos comuns: ETL = Extrair, Transformar & Carregar ODS = Depsito de Dados Operacionais EDW = Enterprise Data Warehouse BO = Business Objects
Funcionalidade fsica Muitos sistemas de Data Warehouse contm vrias reas fsicas onde os dados so armazenados antes, durante e depois que os dados so recebidos do sistema de origem e so processados. Nesse contexto, importante diferenciar a funcionalidade do negcio das funes fsicas e tcnicas.
Pg. 38 de 66
Os Data Warehouses geralmente usam tecnologia da web para tornar as suas informaes mais acessveis aos usurios. Esses Websites podem incorporar informaes nos relatrios ou consultas; informao de metadados; dicionrios de dados; ferramentas de Consulta; treinamento; e membros de grupos de projetos em um local conveniente. Quando esses Websites existem, o Analista do Ponto de Funo precisa determinar se a fronteira do Data Warehouse inclui ou exclui o Website que fornece acesso a ele. Segue algumas dicas para ajudar nessa deciso: Se um Website central usado para acessar vrios Data Warehouses dentro da empresa, e este mantido por uma equipe especfica e no pela equipe que mantm os Data Warehouses, essa uma boa indicao que o Website uma aplicao separada cuja funo primria fornecer acesso aos Data Warehouses. Se um servio web foi construdo para fornecer capacidades de relatrio para um Data Warehouse especfico, e mantido por esta equipe de Data Warehouse, provavelmente seria contado como parte do aplicativo de Data Warehouse.
Observao: A fronteira do aplicativo no se baseia necessariamente em como a organizao do software gerenciada. Porm, conhecer quem desenvolveu o Website que fornece acesso a um Data Warehouse em particular pode ser til quando se define a fronteira da aplicao. Anatomia Fsica de uma Data Warehouse Tipicamente, existem trs segmentos fsicos dentro do Data Warehouse; Staging Areas, o depsito de dados operacionais e o Data Warehouse. Staging Areas. Essa Staging Area usada para armazenar uma verso atual do Data Warehouse que existe no sistema original. Esta cpia fsica criada por vrias razes, inclusive: Desempenho O sistema operacional pode reduzir a carga de processamento imposta pelas leituras requeridas antes que a transformao dos dados comece. Segurana Sistemas origem podem controlar o que os programas tm acesso em suas reas. Ao fornecer uma exportao, o sistema de origem mantm controle sobre o que enviado.
Os dados armazenados nas Staging Areas so os mesmos ou muito similares aos do sistema original, em suas estruturas e valores de dados. A Staging Area raramente vista ou descrita por um usurio do negcio ou um usurio administrador. Depsito de Dados Operacionais (ODS) O ODS contm dados transacionais detalhados que so (tipicamente), de alguma forma, modificados. A fonte original desses dados o sistema de origem via a rea de etapas. Considere como os
Pg. 39 de 66
dados podem ser modificados quando determinam se um armazenamento de dados e o tipo de funo de dados (ALI ou AIE). Os dados nesse segmento do Data Warehouse podem ser descritos como: Integrados Validados Freqentemente atualizados Detalhados Volteis
O segmento ODS suporta a habilidade para, via data mining, buscar informaes sumarizadas para as informaes de nvel transacional, detalhadas e atuais. O Data Warehouse a ltima rea de acomodao (dentro do limite do aplicativo de Data Warehouse) para os dados transformados. Quando dados so armazenados aqui, eles passaram por um processamento via ETL (Extrair, Transformar e Carregar). Exemplos desse processamento incluem: Validao Integrao Limpeza Verificaes de qualidade Sumarizao
Projetos de Data Warehouse contm muitos documentos que o Analista do Ponto de Funo pode usar para auxiliar na contagem do ponto de funo. Alguns dos documentos mais teis so os diagramas de modelo de dados, que ajudar a determinar dados e funes transacionais para a contagem. Os diagramas de modelo de dados incluem: Tabelas Fato Tabelas Agregadas Tabelas de existncia Dimenses Tabelas de Visualizao Metadados
Tabela Fato A tabela fato a principal tabela de interesse em um modelo dimensional. Uma tabela fato contm medidas relacionadas a negcios e cada tabela fato pode ser conectada a tabelas dimensionais ou a outras tabelas fato.Os dados da fato no Data Warehouse se parecem tipicamente com aqueles contidos no sistema de origem ou ODS, mas foram submetidas ao processo ETL e portanto seu significado pode ter sido mudado drasticamente.
Pg. 40 de 66
A estrutura de chave estrangeira na tabela fato permite que os campos definidos em entidades dimensionais acessem informaes adicionais. Uma contagem de DET (TDs) tipicamente incluir campos da entidade da tabela fato e da entidade dimensional. Dependendo da abordagem de modelagem usada pela equipe do projeto, o esquema de estrela representado pode incluir s os campos que so requeridos para definir a informao da entidade, do fato ou pode incluir todos os campos que so definidos para a entidade dimensional, mas so requeridos para uso em outras entidades do fato. Em resumo, tabelas fato contm agrupamentos identificveis do usurio de dados e so geralmente mantidos por um ou mais processos de ETL (processos elementares). Como tais, eles so contados como Arquivos Lgicos Internos. Uma palavra final de advertncia sobre contagem dos tipos de dados (DETs ou TDs) certifique-se de contar somente os requeridos para a entidade fato em anlise. Tabelas Agregadas Tabelas Agregadas um tipo especial de tabela fato. Tabelas Agregadas deveriam ser contadas? Depende da razo para a existncia da tabela agregada, que pode existir por razes de desempenho ou negcios. Razes de Desempenho Um conjunto de medidas pode ser criado medida que os dados so carregados, pois do tempo requerido para que tais clculos sejam feitos nos relatrios muito grande. Nesse caso, estas tabelas agregadas no devem ser contadas como ALIs ou AIEs. Propsitos de Negcio Os usurios podem requerer que as tabelas agregadas sejam construdas para satisfazer um propsito funcional de negcios. Por exemplo, informaes da fato nem sempre podem ser expressveis no mesmo nvel de detalhe; ou custos de remessa podem ser disponveis ao nvel de cliente da fatura de envio, mas no no nvel da linha da fatura ou o nvel do produto. Tabelas de Existncia de Fato (Factless Fact Existence Table) Esse tipo especial de tabela fato no contm medidas numricas de negcio, mas ela documenta a existncia de um evento. Para determinar se deve ser includo na contagem de pontos de funo, faa a anlise funcional conforme esboado nas regras do Manual de Prticas de Contagem. Vejamos um exemplo na Figura 5.
Pg. 41 de 66
Figura 5: Exemplo de Tabelas de Existncia de Fatos
Essa tabela fato da figura 5 usada para definir quais produtos sero oferecidos, a quais estabelecimentos e durante quais promoes. Essa tabela ajudar o analista na avaliao da eficcia de promoes ao identificar os estabelecimentos e produtos participantes. Similar a tabelas associativas encontradas no modelo relacional normalizado, tabelas de existncia gerenciam excees onde certos exemplos de uma tabela se relacionam a um ou mais outras tabelas. Nesse exemplo, a entidade Promotion Products uma tabela contvel. A exigncia em permitir rastrear promoes fica satisfeita com essa entidade. Isso define que produtos sero oferecidos ou foram oferecidos em quais estabelecimentos durante as promoes. A contagem resultante um arquivo de baixa complexidade geralmente um ALI. Tabelas dimensionais Tabelas dimensionais contm as informaes descritivas necessrias para permitir uma anlise da informao relacionada a fato e contm informaes para permitir a verificao do carregamento dos dados. Tipicamente, uma tabela fato s conter DETs que permitam uma medio em particular (na tabela fato) para ser considerada pelos campos nas tabelas dimensionais.
Pg. 42 de 66
Dimenses e Fatos Como eles Coexistem? Fisicamente, tabelas fato contm s os DETs requeridos para representar alguma medida de negcios e so rodeadas pela mesma tabela fsica por DETs do tipo chave estrangeiras que conectam a dimenses de forma a permitir mais descrio de qualquer evento em particular. Ao contar os elementos dos dados para a incluso da tabela fato todos os elementos de dados identificveis do usurio na tabela de fato e os dados elementares das tabelas dimensionais que so requeridos para definir o registro da tabela de fatos. Tabelas de visualizao Como as tabelas de visualizao podem ser contadas? Basicamente, existem duas formas em que as tabelas de visualizao podem ser contadas durante a anlise do ponto de funo. Processos elementares Se uma tabela de visualizao criada e enviada para fora do Data Warehouse para consumo de outro aplicativo (fronteira diferente de aplicativo) assim a transao pode ser contada como uma sada externa ou consulta externa para o aplicativo do Data Warehouse. Parte de um ou mais processos elementares Se a tabela de visualizao criada para uso do Data Warehouse ento ela no deve ser contada como uma nica funo (processo elementar). A tabela de visualizao deve ser analisada para determinar a fonte desses dados. As funes de dados usados para criar a tabela de visualizao devem ser consideradas como um FTRs em potencial para determinar a complexidade das funes transacionais, que acessam aqueles dados em particular.
Metadados A forma mais simples, talvez no a mais clara, de descrever metadados : Dados sobre dados. Os metadados proporcionam mais informao sobre o objeto que est sendo analisado. Os metadados so usados por dois grupos de pessoas em uma organizao: usurios que desempenham anlise relacionada a negcios e aqueles que desempenham anlises relacionadas tcnica. Cada conjunto de usurios tem diferentes necessidades desde a configurao da aplicao at a definio de campos usados em um relatrio especfico. Metadados tcnicos incluem: Descrio de tabelas Descrio de atributos Relaes da entidade Regras de processamento de dados Relacionamento de chaves Categorias de metadados de negcios incluem: Dicionrio de dados Proprietrios de dados Informao assuntos da rea
Um dos elementos-chave, para ter em mente ao analisar os tipos de metadados para incluir em sua anlise quem foi definido como os usurios do aplicativo. Isso afeta a quantidade de arquivos que podero existir.
Pg. 43 de 66
Funes de Transao Existem quatro categorias de transaes/funes que so usados num Data Warehouse tpico. So eles: Extrair, Transformar e Carregar dados Relatrios Funes Administrativas Funes de Metadados.
ETL, ou Extrair Transformar e Carregar (ETL) o conjunto de transaes de banco de dados usado para extrair informaes de um banco de dados, transform-los e carreg-los em um segundo banco de dados. As fontes de dados para o Data Warehouse esto em aplicativos ou sistemas que so externos ao Data Warehouse (fora da fronteira). Dados de origem so extrados ou recuperados de bancos de dados externos por processos no Data Warehouse. Uma vez que os dados so buscados da origem, so transformados usando regras de negcios fornecidas pelo usurio bem como pelo administrador do armazm de dados (Transform). Depois que os dados so transformados, eles so ento carregados no Data Warehouse (Carrega ou Transporta). Conta-se uma EE para cada Carregamento/Transporte de dados de aplicativo de origem que mantm um ou mais ALIs no Data Warehouse. Lembre-se que a inteno primeira dessas transaes manter dados lgicos no Data Warehouse ou alterar o comportamento do sistema. A lgica especial de processamento se aplica na transformao e carregamento de dados. No conte trs EEs separadas para cada passo do processo (ex.: uma EE de Extrao, uma EE de Transformao, e uma EE de Carregamento), uma vez que todos os trs so requeridos para completar o processo elementar. Conta um Arquivo referenciado (FTR) para cada ALI mantido. Conte um Arquivo referenciado (FTR) para cada leitura de ALI ou AIE durante o processamento da entrada externa. Conte s um Arquivo referenciado (FTR) para cada ALI que mantido e lido. Conte um AIE para cada grupo lgico de dados que copiado de um sistema de origem para o Data Warehouse sem nenhuma lgica especial de processamento. Nesse caso, tambm no conte uma EE para a extrao de dados. (A exigncia lgica referenciar os dados. Os dados existem no Data Warehouse devido ao desempenho ou outras consideraes de design/arquitetura do que uma necessidade do usurio de negcios.)
Relatrio / Consulta
Consultar e fazer relatrios sobre os dados contidos no Data Warehouse so importantes funes de negcios. O analista do ponto de funo, precisa determinar quais funes de relatrio ou consulta fazem parte do Data Warehouse e quais so considerados fora da fronteira. Existem pelo menos duas categorias de relatrios: relatrios adhoc e programados. Relatrios adhoc representam uma solicitao a cada vez com parmetros diferentes selecionados pelo usurio, enquanto relatrios programados so criados periodicamente (diariamente, semanalmente, mensalmente) e, tipicamente, no podem ser modificados pelos usurios.
Pg. 44 de 66
Relatrios programados geralmente requerem uma anlise formalizada e um ciclo de vida de desenvolvimento. Como tal, relatrios programados so geralmente contados pelo contador do ponto de funo enquanto relatrios adhoc, criados por um usurio final, no podem ser contados. Uma exceo a essa orientao seria contar a funcionalidade oferecida ao usurio para criar seus prprios relatrios adhoc. Os dois exemplos seguintes de ferramentas de relatrio podem ser usados para criar relatrios adhoc e padro. 1. Ferramenta de Relatrio internamente desenvolvida: Essa ferramenta criada por desenvolvedores para suportar usurios do Data Warehouse. A fronteira de contagem determina se a ferramenta de relatrio desenvolvida contada como um componente do Data Warehouse ou um aplicativo separado. Se os usurios vem a ferramenta como parte do Data Warehouse, deve ser considerada estando dentro da fronteira do Data Warehouse. Outras reas que podem influenciar a deciso de incluir a ferramenta como componente do Data Warehouse so a lgica de processamento e localizao/manuteno dos dados lgicos que suportam os relatrios. Supondo que a ferramenta de relatrio desenvolvida se estabelece dentro dos limites do Data Warehouse, conte pelo menos uma SE (EO) ou CE (EQ) para cada relatrio ou consulta desenvolvida e/ou suportada para satisfazer as necessidades do usurio. Siga as orientaes CPM para determinar se o relatrio ou consulta um processo elementar nico. 2. Software Comercial de prateleira (COTS)/Ferramenta de Relatrio Comprada (ex.:. Relatrios Crystal, Cognos, Business Objects, etc): Para contagens de desenvolvimento e melhoria, um contador do ponto de funo deve contar s as funes que foram personalizadas ou feitas para o usurio de negcios ou administrativo. Se h uma necessidade ou solicitao de negcios para contar todo o portflio de funes do software, (por exemplo, para avaliar as caractersticas ou funes proporcionadas pelo COTS), COTS e as funes personalizadas podem ser contados, mas o portflio deve ser considerado um limite de aplicativo separado do Data Warehouse, contado como um aplicativo separado, e categorizado de acordo. Conte um SE (EO) ou CE (EQ) para cada relatrio ou consulta desenvolvida e/ou suportada para satisfazer as necessidades do usurio. Siga as orientaes CPM para determinar se o relatrio ou consulta um processo elementar nico. Funes Administrativas Data Warehouses possuem inmeras funes administrativas. Enquanto muitas so tcnicas por natureza e requeridas para manter o Data Warehouse ativo e operante; algumas so de natureza de negcios e podem ser contadas. Perguntas que o contador pode fazer para ajudar a determinar se uma funo administrativa de lgica tcnica ou de negcios incluem:
Pg. 45 de 66
As funes foram desenvolvidas para suportar um usurio do aplicativo (ex.: administrador do sistema, arquiteto de dados)? Existem exigncias nicas de segurana (ex.: logins, segmentao de acesso por permisses, senhas)? Supondo que o contador possa responder as questes acima afirmativamente: Conte um EE (EI) para cada funo nica administrativa (ex.: segurana, questes do usurio) que mantm um ALI ou modifica o comportamento do sistema Conte uma SE (EO) ou CE (EQ) para relatrios produzidos para suportar essas funes. Use regras de CPM para determinar os tipos de transao Metadados Metadados so geralmente definidos como dados sobre dados. Em um Data Warehouse pode haver pelo menos dois tipos: Informao que suporta as caractersticas, funes e dados de negcios (ex.: dicionrio de dados) Informao que suporta as funes tcnicas do Data Warehouse (ex.: programaes para backups ou ajustes de desempenho). importante revisar e entender o propsito e objetivos da Contagem do Ponto de Funo, na medida em que isso ir clarear quem so os usurios e que funcionalidade de usurio pode ser considerada. Ambos os tipos de metadados exigem a assistncia de um administrador. A partir de uma perspectiva de dados de negcios, pode-se incluir um arquiteto de dados. A partir de uma perspectiva tcnica que poderia incluir um administrador do sistema. Ao tentar analisar quais caractersticas e funes desempenhadas nessas capacidades administrativas so contadas, til fazer as seguintes questes. 1. As funes de metadados foram desenvolvidas para apoiar um usurio do aplicativo? Se a resposta sim, conte um EE (EI) para cada funo nica mantendo os metadados, e conte uma SE (EO) ou CE (EQ) para os relatrios de metadados produzidos. 2. As funes metadados foram desenvolvidas para suportar funes ou caractersticas tcnicas opostas lgica de negcios? Se a resposta sim, essas funes no so contadas. Elas foram criadas por propsitos tcnicos. Concluso A nica natureza dos Data Warehouses apresenta o Analista do Ponto de Funo com um nmero de desafios a fornecer essas empresas dados de tamanhos precisos e mtricas relacionadas que podem ser usados para tomar as melhores decises possveis. Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 46 de 66
6.3. AUTOMAO DE PROCESSOS DE NEGCIO (BPM)

Viso Geral de Processos Automatizados em um Ambiente BPMS (Figura 6).
Sistema Legado
BPMS
Processo automatizado
WS
WS Sistema Legado
WS
WS
Sistema Legado
Figura 6: Viso Geral de Processos Automatizados em um Ambiente Definies:
Um BPMS (Business Process Management System) um Sistema no qual se pode desenvolver aplicativos integrados para gerenciamento de processos de negcios contemplando recursos como: documentao de processos, execuo automatizada de processos, possibilidade de criao de indicadores gerenciais de processos em painis de controle, upload e trmite de documentos eletrnicos, com possibilidade de certificao digital e integrao com sistemas legados atravs da filosofia SOA (Service Oriented Architecture).
Os processos organizacionais automatizados so executados dentro do ambiente BPMS. Na ATI este ambiente proporcionado pela ferramenta GILES. Interface de integrao a tecnologia utilizada para integrar aplicaes possibilitando a troca e atualizao de dados. Exemplos dessas tecnologias so: webservice, broker ou view, etc.
Pg. 47 de 66
6.3.1. Fronteira da Aplicao
Na contagem de pontos de funo um dos passos iniciais da anlise a determinao da fronteira da aplicao. Para a contagem de pontos de funo de automao de processos deve-se considerar como fronteira da aplicao, apenas a interface conceitual do processo de negcio que ser automatizado. Tendo o cuidado para no considerar na contagem, as funcionalidades que j integram e fazem parte do ambiente BPMS, no qual o mesmo ser desenvolvido. Ou seja, as funcionalidades pertinentes ferramenta BPMS esto fora da aplicao a ser desenvolvida (aqui o processo de negcio a ser automatizado).
6.3.2. Situao acesso ao BPMS:

Para acessar as atividades de um processo automatizado o usurio dever logar no ambiente BPMS. Como a funcionalidade de login uma funcionalidade do ambiente BPMS, essa NO deve ser contada como funcionalidade no projeto de desenvolvimento/manuteno de automao de um processo de negcio.
6.3.3. Cadastro de usurios e grupos organizacionais:

O ambiente BPMS-Agiles disponibiliza algumas funcionalidades de cadastro como por exemplo: usurios e grupos organizacionais. Onde os usurios podem ser alocados aos grupos organizacionais. Os projetos de automao processos devem considerar essas funcionalidades de cadastro como um AIE que mantido pela aplicao giles, e os processos automatizados acessaro seus dados, contando estes como Tipos de Dados.
6.3.4. Funcionalidades da aplicao giles

O ambiente BPMS-Agiles disponibiliza de vrias funcionalidades que no devem ser contadas nos projetos de desenvolvimento/manuteno de automao de um processo de negcio, pois apesar de poderem ser utilizadas nos processos organizacionais NO devem ser contadas, pois fazem parte da aplicao giles. Exemplos: Consulta: Minhas atividades, Meus Processos, Monitoramento de Processos Entrada: Iniciar algum processo de negcio
Pg. 48 de 66
6.3.5. Recebimento de dados de outras aplicaes utilizando interface de integrao

Em projetos de automao de processos que realizam integrao e troca de informaes com outras aplicaes externas, comum se deparar com algumas situaes durante a anlise de pontos de funo: Cenrio 1: O primeiro caso so situaes onde o processo automatizado precisa ler/consultar um arquivo mantido por uma aplicao externa. Exemplo: Um processo X precisa consultar os dados de um funcionrio atravs de sua matrcula que so mantidos num sistema de RH. O entendimento para esse cenrio de contagem de um AIE no processo automatizado referente aos dados consultados e mantidos no sistema de RH e tantos Tipos de Dados que foram consultados. Nesta situao o arquivo consultado j contado como um ALI na aplicao externa. Acentuando que a interface de integrao utilizada nessa transao apenas a tecnologia para acessar os dados mantidos em outras aplicaes, assim no afetam a contagem. Cenrio 2: O segundo caso so situaes onde o processo automatizado necessita verificar ou consistir alguma informao em uma aplicao externa que possui total domnio da regra de negcio envolvida na transao. Exemplo: Um processo X necessita verificar se um determinado funcionrio pode solicitar uma licena sem vencimento. Toda regra envolvida para essa verificao de responsabilidade e realizada na aplicao externa, onde o processo X solicita essa verificao na aplicao externa. Para esse cenrio onde toda a regra de negcio esta fora do processo X no se justifica nenhuma contagem de pontos de funo.
6.3.6. Atualizao de dados em outras aplicaes utilizando interface de integrao

Os processos automatizados que necessitem manter dados em outra aplicao onde as regras de negcio relativas essa manuteno, esto presentes fora da fronteira, ou se seja, esto presentes na interface de integrao e/ou em outras aplicaes externas (como por exemplo no banco de dados ou sistema legado, no que se refere a contagem no deve ser considerado um ALI para o processo automatizado. Os dados de entrada utilizados nessa transao que foram atualizados na aplicao externa sero considerados Tipos de Dados. Acentuando que a interface de integrao utilizada nessa transao apenas a tecnologia para acessar os dados mantidos em outras aplicaes, assim no afetam a contagem.
Pg. 49 de 66
6.3.7. Dados de Cdigo

Os dados de cdigo so uma implementao de requisitos tcnicos e no devem influenciar o tamanho funcional da aplicao, apesar de poderem representar at metade do modelo de dados em terceira forma normal, assim no devem ser contados. As funcionalidades que existam exclusivamente para a manuteno de dados de cdigo no devem ser consideradas processos elementares, assim como os dados de cdigo no devem ser considerados como arquivos referenciados nos processos elementares que os leiam e/ou atualizem. Observao: essas tabelas s sero contadas se possurem atributos que so determinantes na definio de regras de negcio. Para tal, essas regras de negcio, no devem basear-se apenas no cdigo do registro.
6.3.8. Processo Elementar
Algumas atividades modeladas em BPMN, apesar de se apresentarem distintas no modelo, podem constituir apenas uma transao completa para o negcio, com sentido de completude de determinado requisito funcional para o usurio. Assim, devem ser contadas como apenas uma transao. Assim sendo, factvel que se tenha na modelagem BPMN mais de uma atividade ou mesmo um conjunto de atividades que sejam correspondentes a um nico requisito funcional, sendo portanto considerado na contagem como uma nica transao Ateno: Alguns modelos BPMN podem apresentar atividades que foram modeladas apenas para melhor entendimento do negcio e, que no constitui um processo elementar para o sistema. Assim no devem ser levadas em considerao na contagem. Exemplo1: Na figura 8 abaixo foram includas no modelo as atividades Vistar Documentao e Pendncias e Solicitar Resoluo de Pendncias. Apesar de serem duas atividades no modelo, para o negcio elas constituem apenas um processo elementar, individualmente elas no constituem uma transao completa. A atividade Vistar Documentao e Pendncias sem a Solicitao de Resoluo das Pendncias no considerado um processo completo para o usurio.
Pg. 50 de 66
Figura 8: Exemplo de atividades distintas que compem um nico processo elementar Exemplo2: Uma mesma atividade que pode ser realizada por pessoas/entidades diferentes deve ser contada apenas uma vez. Na Figura 9 abaixo a atividade Resolver Pendncia constitui uma transao completa, tem significado para o usurio, autocontida e deixa o negcio da aplicao em um estado consistente. Isso independente da entidade que a realiza. O mesmo ocorre com a atividade Assinar Contrato, conforme podemos observar na Figura 10.
Figuras 9 e 10: Exemplos de atividades distintas que compem um nico processo elementar
Pg. 51 de 66
6.3.9. Atividade com prazos

Atividades que tenham um prazo para serem realizadas, onde aps a expirao do prazo uma notificao/lembrete disparada, essa notificao seja por e-mail, sms ou outro meio, no deve ser contada, pois faz parte do negcio da atividade. Exemplo: Na figura 11 abaixo a atividade Assinar Contrato tem um prazo de 01 (um) dia para ser realizada. Se o prazo expirar primeiro do que a concluso da atividade, ento ser disparada uma atividade para notificar o responsvel avisando do ocorrido e solicitando a sua realizao. A notificao em si seja por email, sms ou algum outro meio, no tem sentido completo de negcio para o usurio, apenas um procedimento integrante deste.
Figura 11: Exemplo de atividade de notificao que no representa um processo elementar
7. LIES APRENDIDAS 7.1. REQUISITOS

primordial que os requisitos de software sejam escritos de forma coerente a nova forma de medio que Pontos de Funo. Embora a engenharia de requisitos tradicional no aconselhe, o que vemos na prtica que os requisitos devem ser fracionados de forma tal a representar a mnima unidade funcional que seja compreendida pelo usurio e que seja testvel pelo desenvolvedor. Este fracionamento traz a organizao o controle dos requisitos de forma tal a conhecer o produto da melhor forma possvel, e requisitos menores so mais fceis de gerenciar mudanas. O Capability Maturity Model Integration (CMMI) no trata da forma como os requisitos sero escritos mas ainda assim quando se tratamos de APF algumas observaes devem ser consideradas.
7.1.1. GRANULARIDADE X QUANTIDADE DE REQUISITOS
Pg. 52 de 66
Ponto de funo aponta claramente o conceito de processo elementar que representa um requisito do usurio. Isso quer dizer que ele completo do ponto de vista de usurio, deixa o sistema consistente e a funcionalidade entregue reconhecida pelo usurio. Desta forma ao fracionar demais os requisitos, vrias funcionalidades so quebradas em partes que sozinhas no tem valor de negcio algum o que pode levar a um desentendimento sobre o pro cesso elementar. Por exemplo, uma funcionalidade solicitada pelo usurio que composta por 3 passos, realizadas em momentos diferentes por pessoas diferentes, provavelmente ser um NICO requisito pois se mostra como um nico processo elementar que s faz sentido se os 3 passos forem dados. Assim, tanto faz realizar 0, 1 ou 2 passos, para o usurio aquela parte no concluda irrelevante. Seguindo o exemplo anterior, suponha que a funo uma SE complexa (Que custa 7 PF) poderia ser quebrada em 2 EE simples (3 pontos cada uma) e 1 SE simples (4 Pontos) o que levaria ao total de 10 PF. 3 Pontos mais caro em uma nica funcionalidade. Ento identificar o processo elementar um passo mais importante do que identificar requisitos e fluxo de servios.
7.1.2. ATENO A REQUISITOS NO FUNCIONAIS

O Ponto por Funo mede software de acordo com seu tamanho funcional (Requisitos funcionais) e os requisitos no funcionais esto com preo embutidos dentro do ponto de funo (Ver a parte de precificao na seo de consideraes para a contagem). Ento cuidado ao solicitar melhorias no funcionais devem ser observados. Por exemplo, um caso recente que houve na ATI, se tratava de um sistema que criava e gerenciava documentos. S que para motivos de usabilidade, foi solicitado que dois tipos especiais de documentos fossem criados e gerenciados (Atas de Registro de Preo e Licitaes). Esta solicitao visou o ganho de tempo da criao de atas e licitaes bem como preparar o sistema para trabalhar com estes dois modelos. Desta forma, os dois tipos de documentos solicitados foram a criao do produto final do sistema, criao de documentos, e no novas funcionalidades. Ou seja, um usurio do sistema poderia ter criado o documento tipo Ate e o documento tipo Licitaes e disponibilizar para o estado sem o nus. Parece pouca coisa, mas a interferncia no sistema, uma vez que as atas e licitaes eram gerenciadas como quaisquer documentos, mas em locais especficos, o que tornou o sistema 40% maior do que o necessrio, e isso tambm implicou em custos. Ento pedido ateno neste aspecto, e alguns cuidados como solicitar as melhorias no funcionais para TODO o sistema. Ou seja, se necessrio que um requisito de segurana seja aplicado em uma transao, solicitar que este requisito seja estendido a todo sistema. Isso pode baratear o produto. Guia de Contagem APF ATI www.ati.pe.gov.br
Pg. 53 de 66
7.1.3. ATENO A RELATRIOS

Um dos pontos mais problemticos em pontos de funo uma vez que relativamente comum aparecer em um sistema relatrios parecidos, mas que so diferentes nos dados em que apresentam. Isso significa que novas funcionalidades (Consultas ou Sadas Externas) surgem a cada novo relatrio e que relatrios parecidos significam funcionalidades parecidas embora diferentes. Ento neste ponto recomendada a juno de vrios relatrios parecidos em um nico relatrio que atende a todas as demandas isto significa uma reduo no s do pagamento, mas, do tamanho do sistema uma vez que manutenes no sistema ocorrero uma vez s.
7.2. DICAS NA DEFINIO DA FRONTEIRA

A fronteira determina o que interno e externo para uma aplicao, de acordo com a viso do usurio, sendo de fundamental importncia na medio funcional. Um erro nesta atividade pode ocasionar duplicidade na identificao de funes, identificao incorreta ou at sua omisso. Em muitos casos isto reflete no aumento da contagem, trazendo prejuzo para a instituio. Seguem algumas dicas que podem auxiliar na identificao da fronteira: A fronteira deve ser delineada de uma perspectiva de negcio, no devendo levar em considerao detalhes tcnicos ou de implementao. * Obtenha uma documentao do fluxo de dados do sistema e desenhe uma fronteira em volta para destacar quais partes so internas e externas aplicao. Verifique como a aplicao gerenciada; se desenvolvida ou mantida em sua totalidade ou em partes por equipes distintas. Verifique se h usurios distintos especificando requisitos para cada parte do software. Is to pode representar fronteiras entre os sistemas. Identifique reas funcionais atribuindo propriedade a certos tipos de objetos, como entidades e processos.
Documente previamente as fronteiras de todas as aplicaes que podero ser objeto de medio.
7.3. DICAS NA IMPLANTAO DO PROCESSO
Pg. 54 de 66
A utilizao de pontos de funo na contratao de desenvolvimento de software tm crescido bastante no mercado brasileiro. Entretanto este processo ainda no atingiu sua total maturidade. Por isso, algumas empresas encontram dificuldade na utilizao da tcnica e acabam sendo mal sucedidas em seus projetos. Seguem algumas dicas que podem minimizar ou at evitar problemas na implantao deste processo: Capacitao: conhecer corretamente a tcnica de pontos de funo fundamental. Embora seja bvio, observa-se que muitas organizaes erram neste passo bsico. Estabelecer objetivos iniciais modestos: comear com um projeto piloto em um sistema simples. Avaliar os resultados, efetuar as correes necessrias, revisar os objetivos e seguir em frente. Esteja ciente das limitaes da tcnica: Existem domnios de problema em que a APF no indicada. Por exemplo, em sistemas de otimizao a tcnica no adequada para medir as partes com alta complexidade algortmica. A tcnica tambm no recomendada para estimativa de projetos muito pequenos (< 100) ou atividades pontuais, pois pode haver distores significativas. Busque ajuda se necessrio: Uma consultoria externa pode evitar "cabeadas desnecessrias" e agilizar o processo, trazendo experincias e ajudando a corrigir rumos. Tambm existe um grupo de usurios muito ativo no Brasil, o BFPUG (Brazilian Function Point Users Group) que possui um frum de discusso ideal para este objetivo. Cuidado com os conflitos de interesse: a medio do servio em pontos de funo nunca deve ser realizada somente pelo fornecedor, pois ele ser remunerado justamente pelo resultado da medio! Observa-se esta prtica indesejvel em algumas organizaes (inclusive pblicas). Pode-se utilizar pessoal interno para realizar a medio, ou na pior das hipteses validar por amostragem as medies realizadas. Outra opo contratar uma empresa externa para este servio. Esteja atento ao preo do ponto de funo: este item to impor tante que vale abord-lo em mais detalhes.
8. CONSIDERAES SOBRE A CONTAGEM DE PONTOS DE FUNO

Esta seo apresenta consideraes especiais sobre o dimensionamento em Pontos de Funo de mudana de requisitos, projetos cancelados e reduo de cronograma. E sugere mtricas para o dimensionamento de atividades de negcio.
Pg. 55 de 66
8.1. CONSIDERAO SOBRE MUDANAS DE REQUISITOS

Em projetos de desenvolvimento e manuteno de software bastante comum as mudanas de requisitos no decorrer do projeto, conforme o usurio e o desenvolvedor adquirem mais conhecimento sobre o negcio [Sommerville, 2007]. O CPM denomina este fenmeno de Scope Creep. Como os requisitos no podem ser congelados, ento temos que gerenci-los de forma efetiva. Nas estimativas iniciais de tamanho de projetos de desenvolvimento, aps a fase de especificao, considerando-se o documento de viso inicial do projeto, recomenda-se utilizar um percentual para evoluo de requisitos de 30% a 40%. Nas estimativas, aps a fase de requisitos, utilizando-se como insumo as especificaes de casos de uso, deve-se considerar um percentual de 20% a 30%. Por exemplo, suponha que aps a anlise do Documento de Viso de um Projeto, aplicando-se a CEPF, foi obtido o tamanho de 200 PFs, ento o tamanho estimado do projeto considerado de 270 PFs (200 + 35%), utilizando-se a premissa de evoluo de requisitos em 35%. Esta premissa deve ser documentada. Uma mudana de requisito gera retrabalho da equipe de desenvolvimento, aumentando assim o esforo e o custo do projeto. 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. Para tratar o dimensionamento das mudanas de requisitos torna-se importante definir a distribuio de esforo pelas macroatividades do projeto, visando definir o valor agregado ao projeto aps cada fase do ciclo de vida. A Tabela 6 na Seo 3.2 estabelece os percentuais por atividade de forma a permitir a contagem de mudana conforme o estgio do projeto. Esta distribuio percentual de pagamento deve ser definida no contrato de software. 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 25% Design, Arquitetura 15% Implementao 40%
Pg. 56 de 66
Assim, o tamanho da mudana de 4 PFs (5 PF x 80% = 4 PFs).
8.2. CONSIDERAO SOBRE PROJETOS CANCELADOS

Em alguns casos, devido s mudanas no ambiente do cliente, uma demanda ou parte de um projeto de desenvolvimento ou manuteno pode ser cancelado pelo cliente ou fornecedor. Nestes casos, o tamanho funcional do que foi cancelado ser aferido por meio da contagem de Pontos de Funo das funcionalidades canceladas e um Fator de Impacto. O Fator de Impacto definido com base no percentual de esforo alocado a construo da funcionalidade em questo, observando as tabelas de distribuio de esforo contidas na Seo 3.2 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. Este fator de impacto pode ser desconsiderado quando o cancelamento vem por parte do fornecedor, sendo assim no ser pago o que no foi entregue, e vale lembrar que este fator de impacto pode ser substitudos por multas em SLAs no edital.
8.3. CONSIDERAES SOBRE REDUO DE CRONOGRAMA

As estimativas de prazo no so lineares com o tamanho do projeto, assim pretende-se pesquisar mais sobre o melhor tempo desenvolvimento (onde h uma melhor relao custo x benefcio de alocao de recursos e menor prazo de desenvolvimento), dado o tamanho de um projeto especfico. Jones [Jones, 2007] prope uma frmula para o clculo do melhor tempo de desenvolvimento, descrita na seo 3.3. Alguns projetos devido legislao e a outros fatores externos a ATI possuem um prazo imposto pelo cliente. Se este prazo for igual ou superior ao prazo calculado pela Frmula de Capers Jones (2007) (expoente t) ou em caso de projetos pequenos (menores que 100 PF) ainda se faz necessrio calcular o prazo Mximo de entrega. No entanto, se o projeto tiver um prazo imposto pelo cliente inferior ao prazo calculado, ento se deve considerar como risco de projeto: 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.
Pg. 57 de 66
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.
8.4. CONSIDERAES SOBRE A PRECIFICAO

Nesta seo sero tratados aspectos referentes a precificao do ponto de funo, apresentando os fatores que influenciam no preo e que devem ser considerados na definio dos critrios de contratao dos servios de desenvolvimento e manuteno de software. Tambm sero apresentados alguns exemplos onde os requisitos no funcionais e as caractersticas do projeto podem aumentar significativamente o esforo de desenvolvimento, elevando assim os custos e o preo mdio do ponto de funo. Guia de Contagem APF Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 58 de 65 8.4.1. Tamanho Funcional x Esforo de Desenvolvimento Embora exista uma forte relao entre o tamanho funcional de um software (medido em Pontos de Funo) e o esforo gasto no seu desenvolvimento (medido em pessoas-hora), os Pontos de Funo no medem diretamente o esforo de desenvolvimento. Nesse sentido, os Pontos de Funo so semelhantes ao metro quadrado na construo civil: embora o metro quadrado influa consideravelmente no esforo de construo e no custo de um imvel, outros fatores podero contribuir tanto ou mais quanto o metro quadrado. Exemplos de fatores so a localizao do imvel, a idade, o material utilizado na construo e acabamento, o prestgio do arquiteto, etc. Da mesma forma, dois sistemas podem ter a mesma medida em Pontos de Funo e preos totalmente diferentes. Por exemplo, um sistema pode ser monousurio, implementado em uma ferramenta como o Access; o outro pode ser uma aplicao web com vrias camadas, envolvendo um mainframe e sofisticados dispositivos de segurana. Neste caso, certamente a quantidade de horas e o preo de cada um desses sistemas ser completamente diferente. A concluso que o tamanho em Pontos de Funo apenas um dos fatores que influem sobre o esforo de desenvolvimento e sobre o custo de um sistema. Outros fatores importantes so a confiabilidade desejada para o software, a metodologia de desenvolvimento utilizada, o nvel de testes requerido, a complexidade dos algoritmos, a dificuldade da plataforma computacional, o estilo de interface com o usurio, o grau de reutilizao desejado, a capacidade e experincia da equipe, a disponibilidade de ferramentas de software adequadas e outros. 8.4.2. Valor do Ponto de Funo O valor R$/PF ir variar de acordo com o trabalho exigido para a entrega das funcionalidades do software levando em considerao o padro tcnico e de qualidade solicitada pelo cliente, como tambm a Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 58 de 66
quantidade de entregveis (artefatos, documentos, modelos, etc) exigidos. Em resumo, tudo aquilo que afeta custo de forma significativa, mas que no tem relao direta com o tamanho medido pela APF acaba sendo computado no preo do ponto de funo. Exemplo 1: ao se contratar uma empresa apenas para o trabalho de codificao e testes de um sistema espera-se que o preo do ponto de funo seja inferior ao caso da contratao da mesma empresa para a realizao de todo o ciclo de desenvolvimento do sistema, desde o levantamento de requisitos at a implantao. Exemplo 2: o preo do ponto de funo para a entrega apenas do software certamente inferior ao preo do ponto de funo onde, alm do software, devem ser entregues vrios documentos (subprodutos) como: modelos da UML, manual de usurio, ajuda on-line, prottipos, casos e planos de testes, etc. Exemplo 3: atualmente a gama de tecnologias disponveis para desenvolvimento de sistemas enorme, cada uma delas podendo influenciar diretamente na produtividade (tanto positivamente quanto Guia de Contagem APF Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 59 de 65 negativamente) do trabalho a ser realizado. Sendo assim bastante comum no mercado a a diferenciao do R$/PF de acordo com a plataforma tecnolgica (mainframe, web, cliente-servidor, etc) e/ou linguagem de programao (cobol, C, java, .net, etc). Exemplo 4: A APF, segundo o padro IFPUG, mede manutenes desconsiderando o tamanho da manuteno que a funo sofrer. Geralmente o esforo para se manter uma funo costuma ser inferior ao de se desenvolv-la. Sendo assim, pode haver diferenciao de preo do ponto de funo em projetos de melhoria para funcionalidades novas, alteradas e excludas. Exemplo 5: ao se contratar uma empresa de desenvolvimento de sistemas estabelecendo SLAs (acordos de nveis de servios) muito rgidos, relacionados produtividade da equipe e qualidade do produto, de se esperar um preo do ponto de funo superior ao de um contrato com um menor nvel de exigncias. Em resumo, no existe um preo nico para ponto de funo bem como no h atualmente uma tabela de preos disponvel publicamente onde se possa consultar valores para o preo do ponto de funo. At mesmo porque esta uma informao considerada reservada ou estratgica para muitas organizaes. Porm possvel obter informaes de preo dos contratos governamentais atravs de uma pesquisa nas licitaes ocorridas, no dirio oficial ou diretamente com o rgo do governo. Outra possibilidade para se obter essa tabela de preos recorrer s organizaes que mantm base histrica de projetos de software (exemplo: ISBG - www.isbsg.or) e efetuar uma converso dos indicadores de taxa de entrega (H/PF) para preo (R$/PF). Porm mesmo que se consiga obter uma tabela de valores R$/PF, a variao dos nmeros to significativa que facilmente se encontra uma faixa de Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 59 de 66
valores cuja variao entre o mnimo e o mximo pode ser de at 10 vezes, por exemplo, de R$100/PF a R$1.000/PF. Para obter uma informao mais realista do preo (ou custo) do PF melhor buscar isto internamente nos projetos j realizados. Para projetos j concludos uma informao certamente disponvel o quanto se pagou ou se cobrou por cada projeto e quais atividades estavam compreendidas. Caso o tamanho funcional (PF) dos projetos no esteja disponvel, pode-se obt-lo rapidamente atravs de uma medio ou de uma estimativa; basta analisar seus requisitos. Tendo o preo do projeto e o seu tamanho em pontos de funo, obtm-se o seu preo por ponto de funo (R$/PF). No entanto provvel que sua organizao empreenda projetos de diferentes tipos. Neste caso deve-se proceder a anlise do R$/PF para cada categoria de projetos, pois dificilmente um preo nico ser representativo para projetos de tipos distintos. 8.4.3. Preo Ideal do Ponto de Funo na APE No contexto das instituies pblicas encontramos um cenrio onde necessrio contratar servios de desenvolvimento e manuteno para vrios projetos, muitas vezes de naturezas diferentes, de acordo Guia de Contagem APF Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 60 de 65 com o planejamento estratgico e as diretrizes do governo. Porm, no vivel que as instituies realizem uma contratao especfica para cada projeto, devido aos altos custos de um processo licitatrio, bem como, a complexidade tcnica de se gerenciar vrios contratos de pequeno porte. Por isso, uma boa prtica que vem sendo adotada na APE que projetos de caractersticas semelhantes sejam atendidos por uma mesma contratao, salvo aqueles cuja natureza estratgica ou o grande porte prescindam de uma contrao especfica. Desta forma, podemos obter alguns benefcios como um maior controle dos projetos, atravs de uma gesto centralizada, e a reduo de custos, atravs de um maior volume de servios contratados e tambm pela diminuio de processos licitatrios na APE. Porm, importante observar que, em se tratando de projetos de caractersticas diferentes, dificilmente poderemos chegar a um preo ideal do ponto de funo sem que haja grandes distores. Isto ocorre por conta do nvel de esforo exigido em cada projeto, que acaba influenciando diretamente no preo cobrado pelo fornecedor. Ento, se no houver um planejamento eficaz da contratao, corremos o risco de que os projetos mais simples saiam muito caros para a instituio, enquanto os projetos mais complexos saiam de grande prejuzo para o fornecedor. Para minimizar este problema, recomenda-se que os projetos de caractersticas similares (processo, tecnologia, requisitos no funcionais, requisitos de qualidade, SLAs) sejam agrupados em categorias que devero ser licitadas separadamente (lotes diferentes de preo). Se observarmos estes projetos em um nvel macro perceberemos que as situaes extremas se compensam e, em mdia, existe uma maior
Pg. 60 de 66
linearidade na relao entre o esforo e o tamanho funcional, permitindo que o fornecedor estabelea um preo mdio justo para ambas as partes. O objetivo manter o equilbrio financeiro entre instituio x fornecedor num conjunto de projetos realizados durante o perodo do contrato, numa relao que represente vantagem para ambos os lados. Seguem alguns critrios de similaridade que causam impacto no esforo e podem ser utilizados para categorizao de projetos: Aspectos no funcionais; Complexidade e lgica de processamento; Requisitos de disponibilidade e performance; Mix de tecnologias envolvidas; Processo de desenvolvimento utilizado; Tamanho ordem de grandeza do projeto; Artefatos construdos; Nvel de exigncia dos Acordos de Nveis de Servio;
Alm de categorizar os projetos importante manter uma base histrica de indicadores de esforo e custo. Os indicadores devem estar associados aos objetivos estratgicos da instituio e devem ser coletados e acompanhados de forma sistemtica. Podemos citar como exemplo a taxa de entrega (H/PF) e Guia de Contagem APF Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 61 de 65 o preo (R$/PF), que podem ser obtidos atravs de quanto se cobrou por cada projeto, a quantidade de horas de trabalho reportada e quantos pontos de funo foram entregues no perodo. Estes nmeros so de grande importncia, pois refletem a experincia da prpria organizao nos projetos medidos em pontos de funo, podendo ser usados para acompanhamento dos contratos, melhoria das estimativas, referncias para futuras contrataes e como base de comparao com outras instituies. Desta forma, as instituies podem aproveitar as lies aprendidas para calibrao do preo do ponto de funo, obtendo assim um valor mais adequado a sua realidade. 8.4.4. Consideraes
Pg. 61 de 66
Atravs dos exemplos podemos perceber o impacto direto do esforo de desenvolvimento sobre o preo do ponto de funo. Desta forma, de extrema importncia que os requisitos para contratao de servios sejam bem definidos, de acordo com as caractersticas dos projetos e baseados nas necessidades dos clientes, para que a instituio no sobrecarregue o fornecedor com exigncias que no agregaro valor ao projeto e que, com certeza, iro aumentar o preo cobrado por ponto de funo. Por outro lado, a instituio no pode ser omissa na hora de estabelecer os critrios de contratao buscando um menor preo, pois isso acarretar em baixa qualidade de servios e insatisfao do cliente. A melhor alternativa buscar equilbrio entre estes fatores, garantindo assim melhores contrataes, bem como, um melhor relacionamento entre contratante e contratada. Uma iniciativa neste sentido foi a ata de registros de preo para desenvolvimento de sistemas em pontos de funo, elaborada pela ATI em outubro de 2010, cujos servios foram divididos em lotes de acordo com a tecnologia utilizada (JAVA Demoiselle, JAVA MakerAll e Dot Net). Para esta contratao a ATI realizou um levantamento dos fatores necessrios para a maioria dos projetos de governo, como aderncia a arquitetura padro do estado, atividades do ciclo de vida de projetos e SLAs de qualidade e produtividade. Estes fatores influenciam diretamente no esforo, por isso foram includos no edital para formao do preo do ponto de funo. Estima-se que esta primeira contratao trouxe uma economia para a ATI algo em torno de 4.000.000 (Quatro Milhes) de R$ Desta forma, as instituies da APE que tiverem interesse podero aderir a esta ata para atendimento de suas demandas, garantindo assim os nveis de qualidade e produtividade padro do governo, desde que estes nveis atendam as necessidades de seus projetos. Alm disso, estaro respeitando os princpios da economicidade e eficincia, evitando os custos e a longa durao de um novo processo licitatrio, alm da economia de escala no preo do ponto de funo para um maior volume de servios. Guia de Contagem APF Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 62 de 65 Alm disso, fundamental que as instituies mantenham uma base histrica de indicadores dos projetos para melhoria contnua das estimativas e controle das contrataes. Isso vai refletir em resultados positivos para a instituio e, conseqentemente, melhores servios para o cidado.
Pg. 62 de 66
8.5. CONSIDERAES SOBRE CICLO DE VIDA ITERATIVO INCREMENTAL

Segundo experincias obtidas pela prpria ATI a soma das partes pode ser maior do que o todo. Ou seja, se a ATI recebe de um fornecedor 3 Iteraes de 300 Pontos no necessariamente o produto final conter 900 pontos. Ser necessrio para a ATI identificar em cada um dos seus editais a compensao de ao fim das iteraes recuperar a diferena do tamanho do sistema (final) e da soma das partes que deve ser maior.
8.6. COMO UMA EMPRESA PBLICA PODE SE FILIAR AO IFPUG.

O que um rgo do governo deve fazer para obter a filiao ao IFPUG? Normalmente as maiores dvidas dizem respeito ao pagamento da filiao, que deve ser feito em dlares no exterior. Contudo vrios rgos estaduais, federais e empresas estatais j se filiaram e permanecem filiados. Os passos iro variar um pouco dependendo do rgo, mas basicamente so: 1. Dirigir-se rea de compras, suprimentos ou filiaes a associaes, com uma solicitao devidamente embasada, justificando a necessidade de filiao ao IFPUG. Ressaltar que o nico fornecedor dos servios almejados o IFPUG (por exemplo, para ter acesso ao CPM e realizar o exame CFPS o IFPUG a nica fonte). 2. Aprovado o pedido, a rea de compras provavelmente solicitar ao IFPUG uma invoice (fatura, ou instrumento de cobrana) que servir de base ao pagamento e especificar o valor a ser pago. A invoice pode ser solicitada via e-mail ao escritrio do IFPUG, tendo-se o cuidado de enviar ao IFPUG todos os dados necessrios identificao do rgo: razo social, endereo, CNPJ, etc. Orientar o escritrio do IFPUG sobre a necessidade de colocar todos os dados na invoice. Normalmente a invoice vir atravs de e-mail. 3. Recebida a invoice, a rea de compras estar ciente do valor a ser pago (conforme o tipo de filiao solicitado) e dos dados bancrios do IFPUG para remessa do dinheiro. Nesta data (10 de Dezembro de 2010) esses dados so: International Function Point Users Group 191 Clarksville Rd. Princeton Junction, NJ 08550 Sovereign Bank 44 Princeton Hightstown Rd Princeton Jct., NJ 08550 877-768-1145 ABA # 231372691 Account # 0741078090 Amount:______________ Swift Code: SVRNUS33 Notar que o campo Amount (valor) acima deve ser preenchido com o valor da filiao acrescido de US$ 50.00 (cinquenta dlares norte-americanos), correspondentes taxa de remessa internacional cobrada pelo banco e repassada ao filiado pelo IFPUG. 4. De posse dos dados bancrios acima, um funcionrio do rgo deve ir a uma agncia do Banco do Brasil, que realizar o servio de remessa eletrnica ao exterior. Este servio uma operao de Guia de Contagem APF ATI www.ati.pe.gov.br Pg. 63 de 66
cmbio, devendo existir uma taxa cobrada pelo BB e possivelmente impostos. Efetuada a remessa, o BB fornecer um comprovante em reais, que ser contabilizado pelo rgo. Dessa forma, no existir contabilmente uma operao em dlar no rgo, mas sim um pagamento em reais ao BB (esta uma dvida que costuma surgir - alguns colegas dizem "Meu rgo no pode realizar pagamentos em dlares", mas isto no deve constituir impeditivo, j que o fato contbil ser registrado em reais). 5. Realizada a transferncia, uma cpia do comprovante fornecido pelo BB dever ser enviada via fax ou e-mail ao IFPUG, juntamente com o formulrio de filiao que pode ser baixado de http://www.ifpug.org/membership/membershipApplication.pdf (ver http://www.ifpug.org/membership/). Notar que o nome do rgo dever aparecer exatamente da mesma maneira no comprovante do BB e no formulrio de filiao - no colocar, por exemplo, Agncia Estadual de Tecnologia da Informao em um documento e ATI no outro, etc.). 6. Tudo isto feito, os contatos constantes do formulrio de filiao recebero um e-mail de confirmao com identificao de usurio e senha para acesso rea de filiados do site do IFPUG. Notar que este retorno pode levar mais de uma semana. Se demorar demais, enviar ao IFPUG uma mensagem em ingls solicitando explicao. 7. A filiao ao IFPUG vence sempre no dia 30 de junho de cada ano, independentemente da poca da filiao. Um indivduo ou organizao que se filie ao IFPUG como Regular Member entre primeiro de maio e 30 de junho de qualquer ano pagar o preo normal da filiao. Contudo, tal indivduo ou organizao ter sua filiao estendida at 30 de junho do ano seguinte. Ou seja, bom ter cuidado em quando realizar a filiao.
8.7. CERTIFICAO CFPS

O Exame CFPS - Administrado pela Prometric - acesse http://www.prometric.com,CFPS - Certified Function Point Specialist - a certificao conferida pelo International Function Point Users Group s pessoas aprovadas no exame de certificao CFPS. necessrio ser filiado ao IFPUG para obter e manter a certificao CFPS. A certificao CFPS reconhecida internacionalmente e vlida por at 3 (trs) anos. A partir de julho de 2003, a certificao conferida por 1 (um) ano e revalidada anualmente, por at 3 anos, enquanto a pessoa permanecer filiada ao IFPUG. A interrupo da filiao implica na perda da certificao. Aps 3 anos, necessrio fazer novo exame (a menos que a pessoa utilize o programa de recertificao, ainda no implantado fora dos E.U.A.). O custo do exame U$250, pagos diretamente Prometric, empresa que realiza o exame. possvel confirmar se uma pessoa detm a certificao CFPS atravs de consulta ao IFPUG, enviando um e-mail a ifpug@ifpug.org. ou consultando no site do IFPUG.
Pg. 64 de 66
A certificao a garantia de que o profissional entende e utiliza corretamente as regras do IFPUG para a contagem de pontos de funo. Todos os profissionais de APF (Anlise de Pontos de Funo) devem buscar a certificao.
9. PROCESSO DE REVISO DO GUIA DE CONTAGEM 9.1. REVISO PARA CORREO DE INCONSISTNCIAS E SITUAES NO PREVISTAS
A reviso deste guia ser feita sempre que a ATI, clientes e fornecedores verificarem inconsistncias entre uma definio do CPM e uma regra constante deste documento e situaes no previstas neste guia. Para situaes no previstas neste guia, dever-se- recorrer equipe de contagem do cliente e a coordenao da rea de mtricas da USG-GND da ATI que decidiro pela atualizao deste guia ou do contrato.
9.2. REVISO PARA ADOO DE NOVAS VERSES DO CPM

A adoo de nova verso do CPM como referncia para este Guia de Contagem no ser imediata sua publicao. Nesse caso dever haver uma avaliao da nova verso pela ATI para se decidir sobre a atualizao do guia.
10. CONCLUSO
Este documento apresentou um guia para o dimensionamento de tamanho de todos os tipos de projetos de software desenvolvidos pela ATI seguindo 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.
REFERNCIAS BIBLIOGRAFIAS
[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, Editora Devmedia, pp.25-31. (2008).
Pg. 65 de 66
[IEEE,1998] IEEE Computer Society. IEEE Standard for Software Maintenance. IEEE Std 1219, (1998). [IFPUG, 2007] IFPUG. Function Points & Counting Enterprise Data Warehouses . Release 1.0, September, (2009). [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 , McGraw Hill, (2007). [NESMA, 2009] NESMA. Function Point Analysis for Software Enhancement Guidelines. Version 2.2.1, (2009). [Serpro, 2010] SERPRO. Roteiro de Contagem de Pontos de Funo. (2010). [Sommerville, 2007] SOMMERVILLE, I. Software Engineering. Pearson Education Limited, 8th Edition, (2007). [TotalMetrics, 2004] TotalMetrics. Levels of Function Point Counting. (2004).
Pg. 66 de 66

Guia Medicao Ati

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Guia Medicao Ati

Caricato da

Copyright:

Formati disponibili

Guia de Contagem APF Verso 1.

Guia de Contagem APF ATI www.ati.pe.gov.br

Guia de Contagem APF ATI www.ati.pe.gov.br

Guia de Contagem APF ATI www.ati.pe.gov.br

Guia de Contagem APF ATI www.ati.pe.gov.br

PF: Pontos de Funo.

3. ESTIMATIVAS DE PROJETO DE SOFTWARE

Guia de Contagem APF ATI www.ati.pe.gov.br

Identificar demandas que sero implementadas na Sprint

Agrupar demandas ligadas ao mesmo requisito funcional.

Realizar contagem estimativa de tamanho funcional da Sprint

Derivar Custo e Prazo da entrega baseado no tamanho funcional.

Realizar contagem funcional da entrega realizada pelo fornecedor

Reavaliar Custo e Prazo da entrega realizada pelo fornecedor

Atualizar Base Histrica do Projeto baseado na diferenas entre a estimativa e a Medio

Figura 1: Processo de Estimativas de Projetos de Software

Guia de Contagem APF ATI www.ati.pe.gov.br

Figura 2: Base histrica do ISBSG e do Meu projeto

PF = 35*N de ALIs + 15*N de AIEs

3.1. DETALHAMENTO DO PROCESSO DE ESTIMATIVA

Guia de Contagem APF ATI www.ati.pe.gov.br

Figura 3: Modelo Lgico da Anlise de Pontos de Funo [SERPRO 2010]

Guia de Contagem APF ATI www.ati.pe.gov.br

Guia de Contagem APF ATI www.ati.pe.gov.br

Guia de Contagem APF ATI www.ati.pe.gov.br

AFP = ADD + CFP

Guia de Contagem APF ATI www.ati.pe.gov.br

A frmula de contagem ou de estimativa de Pontos de Funo para Softwares Prontos a seguinte:

AFP = ADD + CHGA + CFP + DEL

Guia de Contagem APF ATI www.ati.pe.gov.br

Tabela 6: Remunerao da ATI por fase de Ciclo de Vida

3.3. ESTIMATIVA DE PRAZO

Guia de Contagem APF ATI www.ati.pe.gov.br

Figura 4: Relao entre a Estimativa de Prazo e de Esforo [Jones 2007]

Tabela 7: Expoente t por tipo de Projeto

0,37 0,39 0,40

3.4. ESTIMATIVA DE CUSTO

4. CONTAGEM DE PONTOS DE FUNO PARA PROJETOS DE MANUTENO

4.1. PROJETOS DE MELHORIA

Guia de Contagem APF ATI www.ati.pe.gov.br

Guia de Contagem APF ATI www.ati.pe.gov.br

Guia de Contagem APF ATI www.ati.pe.gov.br

PFD Fator de Impacto (FFD)

Maior que 100% 1

Guia de Contagem APF ATI www.ati.pe.gov.br

Tabela 8: Calculo do FFT para funo de Dados [NESMA 2009]

Caso FFT seja maior que 1, recomenda-se reconsiderar a melhoria.

4.2. PROJETOS DE MANUTENO CORRETIVA

Guia de Contagem APF ATI www.ati.pe.gov.br

PF = PF_ALTERADO x 0,80 c) Aplicao com documentao completa

4.3. MANUTENO COSMTICA

Guia de Contagem APF ATI www.ati.pe.gov.br

4.4. MANUTENO ADAPTATIVA EM REQUISITOS NO FUNCIONAIS

4.4.1. REDESENVOLVIMENTO DE PROJETOS EM OUTRA PLATAFORMA

Guia de Contagem APF ATI www.ati.pe.gov.br

4.4.2. ATUALIZAO DE PLATAFORMA

a) Atualizao de Plataforma com necessidade de redocumentao de requisitos

PF = (PF_NO_AJUSTADO x 0,50) + PF_CONVERSO b) Atualizao de Plataforma sem necessidade de redocumentao de requisitos

PF = (PF_NO_AJUSTADO x 0,40) + PF_CONVERSO

c) Equalizao de Base de Dados via Scripts

d) Adaptao de Aplicao para Multibrowsers

Guia de Contagem APF ATI www.ati.pe.gov.br

4.4.3. ADEQUAO DE FUNCIONALIDADES S MUDANAS DE NEGCIO

a) Adequao de funcionalidades com necessidade de redocumentao

PF = 35N de ALIs + 15N de AIEs