guia de orientação de métricas - caixa econômica federal

CAIXA – Guia de Orientação de Métricas

Página 1 de 73

# PÚBLICO

Guia de Orientação de Métricas

GT Métricas

Outubro de 2016 Versão 17


Página 2 de 73

Sumário Sumário ..................................................................................................................................................... 2

Histórico de Revisões .......................................................................................................................................... 4

Objetivo do Guia de Orientações de Métricas ..................................................................................................... 6

Capítulo 1. Orientações gerais sobre o processo de métricas da CAIXA .......................................................... 7

1. Orientações Relevantes quando da Leitura deste Guia ................................................................. 7

2. Técnicas de Medição na CAIXA ..................................................................................................... 8

3. Análise de Pontos de Função na CAIXA ......................................................................................... 8

4. Ponto SNAP na CAIXA ................................................................................................................... 9

5. Processo de Medição .................................................................................................................... 9

6. Artefatos do Processo de Métricas da CAIXA .............................................................................. 10

7. Validação das Medições Realizadas ............................................................................................ 13

Capítulo 2. Medição de Serviços em APF ...................................................................................................... 15

1. Fronteira da Aplicação e Escopo ................................................................................................. 15

2. Migração de Base de Dados ........................................................................................................ 15

3. Fator de Ajuste da Contagem (IFPUG) ........................................................................................ 16

4. Fator de Ajuste do Serviço em Projetos de Migração de Base de Dados ..................................... 16

5. AIE – Arquivo de Interface Externa ............................................................................................. 16

6. Code Data ou Code Table ........................................................................................................... 16

7. Code Data VS AIE ........................................................................................................................ 16

8. Contagem de interfaces com sistemas - AIE................................................................................ 17

9. Impacto das alterações das características de itens de dados de um ALI e nas funções

transacionais que o mantêm (CPM 4.3.1) .......................................................................................................... 17

10. Integração de Sistemas ............................................................................................................... 18

11. Integração de Sistema de Segurança .......................................................................................... 18

12. Consultas Dinâmicas ................................................................................................................... 18

13. Funcionalidades iguais apresentadas em diferentes formatos de saída ...................................... 18

14. Desenvolvimento em Múltiplas camadas (mainframe, web) ...................................................... 19

15. Medição de componentes .......................................................................................................... 19

16. Funcionalidades Batch ................................................................................................................ 19

17. Necessidade de realização de terceira contagem ....................................................................... 19

Capítulo 3. Log, Trilha de Auditoria, Registro de Eventos e Histórico ............................................................ 20

1. Definições................................................................................................................................... 20

2. Interpretação ............................................................................................................................. 20

Capítulo 4. Procedimento para Medição de Alteração de Escopo ................................................................. 21

1. Alteração de Escopo ................................................................................................................... 21

2. Gestão Financeira das Demandas com Alteração de Escopo ....................................................... 23

3. Passos do Fluxo Sintético da Gestão Financeira de Demandas com Alteração de Escopo ........... 24

Capítulo 5. Atualização de Baseline de Serviço, de Baseline de Produção e Contagem de Aplicação ............ 28

1. Conceitos .................................................................................................................................... 28

2. Contagem de Aplicação de Produtos no Mercado ...................................................................... 28

3. Repositório Oficial da CAIXA ....................................................................................................... 28

Capítulo 6. Manutenção Adaptativa, Perfectiva e Corretiva. ........................................................................ 29

1. Esclarecimento sobre diferença entre Manutenção Adaptativa e Perfectiva .............................. 29

2. Procedimento a ser adotada para medição de Manutenção Adaptativa e Perfectiva ................. 29

3. Esclarecimento do processo a ser adotado para medição de Manutenção Corretiva. ................. 30


Página 3 de 73

Capítulo 7. Processo de Divergência entre Contagens .................................................................................. 31

1. Esclarecimentos sobre divergências entre Contagens ................................................................. 31

Capítulo 8. SNAP – Software Non-functional Assessment Process ................................................................ 33

1. Fronteira da Aplicação e Escopo ................................................................................................. 33

2. Partição ...................................................................................................................................... 33

3. Categoria e Subcategoria ............................................................................................................ 33

4. Subcategoria Interfaces do Usuário ............................................................................................ 33

5. Subcategoria Métodos de Ajuda ................................................................................................. 34

6. Subcategorias Múltiplos Métodos de Entrada e Múltiplos Métodos de Saída ............................ 35

7. Subcategorias Múltiplas Plataformas ......................................................................................... 35

8. Subcategoria Tecnologia de Banco de Dados .............................................................................. 36

9. Subcategoria Software Baseado em Componentes .................................................................... 37

10. Subcategoria Movimentações de Dados Internos ....................................................................... 38

Capítulo 9. SISRA – URA ............................................................................................................................... 39

1. Contagem dos Servidores de Aplicação SISRA – URA .................................................................. 39

Capítulo 10. CONTRATO HOME BROKER ........................................................................................................ 40

1. Diretrizes para o Contrato HOME BROKER ................................................................................. 40

Capítulo 11. Orientação de Contagem UST para Portais de Conteúdo ............................................................ 41

1. Objetivo ..................................................................................................................................... 41

2. Contextualização ........................................................................................................................ 41

3. Glossário .................................................................................................................................... 41

4. Definição .................................................................................................................................... 42

5. Insumos necessários para realização da medição ....................................................................... 45

6. Tabela de Remuneração para PORTAL DE CONTEÚDO do Segmento/Carteira NOVAS

TECNOLOGIAS ................................................................................................................................................... 46

Capítulo 12. Diretrizes de Contagem do SIDEC ............................................................................................... 51

1. Introdução .................................................................................................................................. 51

2. Critérios de agrupamento e/ou segregação ................................................................................ 51

Capítulo 13. Diretriz de contagem para sistemas DW/BI ................................................................................ 54

1. Conceitos Gerais para DW/BI ..................................................................................................... 54

2. Visão Geral de Contagem ........................................................................................................... 56

3. FUNÇÕES DE TRANSAÇÃO .......................................................................................................... 57

4. FUNÇÕES DE DADOS ................................................................................................................... 64

5. MEDIÇÃO SNAP .......................................................................................................................... 68

Capítulo 14. Glossário .................................................................................................................................... 72


Página 4 de 73

Histórico de Revisões

Data Versão Descrição Autor

05/2007 1 Elaboração da proposta do Guia de

Orientação de Métricas

Angélica Toffano Seidel Calazans/GESOL, Rubens

Alves /REDEA SP, Mônica Calçada /REDEA RJ,

Rosalina Firmino/ REDEA BR, Iraina Cristina Diniz

Lisboa/GEDES, Rodrigo Antunes/REDEA BR.,

Mauro Lemes /REDEA BR, Catia Krauss/REDEA

SP, Marcia Dondi /REDEA RJ, Alexandre de Barros

Zanoto/REDEA SP, Caio Paro/REDEA SP, João

Afonso de Souza Oliveira/REDEABR e Jose Luis

Gonçalez Moure/REDEA RJ.

04/2008 2 Complementação do contrato futuro - (Concorrência n.° 001/2006)

Adequação da fórmula de Alteração de

Escopo

Angélica Toffano Seidel Calazans/GESOL, Rubens

Alves /REDEA SP, Mônica Calçada /REDEA RJ,

Rosalina Firmino/ REDEA BR, Iraina Cristina Diniz

Lisboa/GEDES, Rodrigo Antunes/REDEA BR.,

Mauro Lemes /REDEA BR, Catia Krauss/REDEA

SP, Marcia Dondi /REDEA RJ, Alexandre de Barros

Zanoto/REDEA SP, Caio Paro/REDEA SP, João

Afonso de Souza Oliveira/REDEABR e Jose Luis

Gonçalez Moure/REDEA RJ.

03/2009 3 Adequação ao Novo Modelo de

Contratação

Angélica Toffano Seidel Calazans/GEART, Barbara

Tamisa/GEART, Marisa Micussi/GEITI, Daniele

/GEITI, Wirlinda /GEITI, Rodrigo

Antunes/REDEABR, Carlos REDEABR, Kester

/REDEASP, Ronaldo /REDEASP, José Eduardo

/REDEARJ, Andre /REDEARJ, Ricardo

/REDEABR, Cecília/REDEARJ.

05/2009 4 Reunião presencial 07/05/2009 Presencial de métricas 02/05 a 08/05/2009

07/2010 5 Nomenclatura dos artefatos e unidades,

insumos, diferença entre as manutenções

e INM 7 para manutenção. Atualização em

28/07/2010.

GT Métricas

05/2011 6 Correção da descrição do cálculo do item 4

da tabela de Itens Não Mensuráveis-INM

(10/05/2011)

GT Métricas

01/2012 7 Atualização das Siglas

Alteração item 6.1

GESOL e GT Métricas

03/2012 8 Atualização e revisão geral em relação aos

novos contratos de fábrica em 2012

Barbara Tamisa Florentino da Silva, GESOL

06/2012 9 Atualização e revisão geral em relação aos

novos contratos baseados na

segmentação por linha de negócio e

contrato Home Broker.

Daniele Lucena Ribeiro, GEMOD

06/2012 9 Revisão e reformulação da versão 9.

Aprovada em reunião do GT-Métricas em

28/06/2012.

GT Métricas: Fatima Saldanha Cesarino,

CEDES/RJ; Andre de Abreu Ferreira, CEDES/RJ;

Barbara Tamisa Florentino da Silva, GESOL;

Daniele Lucena Ribeiro, GEMOD; Jaqueline

Hoeltgebaum, CEDES/BR; Iara Salles Farias,

CEDES/SP; Fabrizio da Silva Rocha, GEMOD.


Página 5 de 73

08/2012 10 Atualização referente à medição de Portal

de Conteúdo.

Daniele Lucena Ribeiro, GEMOD;

08/2012 Revisão e reformulação da versão 10.

Aprovada em reunião do GT-Métricas em

31/08/2012.

GT Métricas: Fatima Saldanha Cesarino,

CEDES/RJ; Andre de Abreu Ferreira, CEDES/RJ;

Barbara Tamisa Florentino da Silva, GESOL; Roman

Dario Cuattrin, CEDES/BR; Iara Salles Farias,

CEDES/SP; Sidonio Amorim de Oliveira,

CEDES/SP; Fabio Martorano da Cruz, CEDES/SP;

Daniele Lucena Ribeiro, GEMOD;

09/2013 11 Revisão da Versão 10

10/2014 12 Revisão e reformulação da versão 11. GT Métricas: CEDESRJ: Andre de Abreu Ferreira,

Fatima Saldanha Cesarino; CEDESBR: Elcio Gomes

Pereira Martins, Luiz Gustavo Queiroga Pena;

CEDESSP: Fabio Martorano da Cruz; CETEC:

Ricardo Rocha Bomfim; GEMOD: Ricardo Ney Silva

Santos, Deyver José Gonçalves

07/2015 13 Revisão da versão 13. GT Métricas: CEDESRJ: Andre de Abreu Ferreira,



CEDESSP: Fabio Martorano da Cruz; CETEC:

Ricardo Rocha Bomfim; GEMOD: Deyver José

Gonçalves

02/2016 14 Revisão da versão 13 e organização do

guia de orientação de métricas em

capítulos.

GT Métricas: CEDESRJ: Andre de Abreu Ferreira,



CEDESSP: Fabio Martorano da Cruz; Mauricio

Minoru; GEMOD: Deyver José Gonçalves

04/2016 15 Revisão devido à reestruturação e

correção de item em duplicidade (no

capítulo 3 os itens 2.1 e 2.2)

Bárbara Tâmisa F. da Silva – GEDTI

09/2016 16 Inclusão de novas subcategorias SNAP no

Capítulo 8, após estudo no contexto do

Escritório de Mobilidade.



Pereira Martins, Andro Márcio Correa Louredo;

GEDTI: Anderson Ricardo Frezza, Bárbara Tâmisa

F. da Silva

10/2016 17 Inclusão de nova subcategoria SNAP no

Capítulo 8, após elaboração de diretrizes

de contagem para sistemas DW/BI.

Inclusão do Capítulo 13 - Diretriz de

contagem para sistemas DW/BI.



Pereira Martins, Andro Márcio Correa Louredo;

CEDESSP: Raymundo da Silva Campos Junior;

GEDTI: Bárbara Tâmisa F. da Silva


Página 6 de 73

Objetivo do Guia de Orientações de Métricas 1. O GT de Métricas da CAIXA foi criado em 2002, por iniciativa da Gerência Nacional

à época responsável pelo desenvolvimento de soluções tecnológicas na CAIXA, com o objetivo de analisar e definir assuntos relativos a métricas de software e sua aplicação nas unidades de desenvolvimento. Este grupo tem realizado estudos sobre a aplicação de técnicas de medição de software na TI da CAIXA, acompanhado o processo de medição e sugerido orientações para que as unidades de desenvolvimento trabalhem de forma padronizada, orientando sua atuação operacional sob os mesmos conceitos.

2. Os assuntos tratados neste Guia de Orientações de Métricas são respostas às dúvidas que permeiam o processo de medição da CAIXA e apropriações conceituais que consideram as características e necessidades institucionais. Algumas direcionam o uso de técnicas de medições nos serviços terceirizados, outras explicitam o uso, acompanhamento e condições de aplicação de regras de medição e processos.


Página 7 de 73

Capítulo 1. Orientações gerais sobre o processo de métricas da CAIXA 1. Orientações Relevantes quando da Leitura deste G uia 1.1. Este guia está organizado por capítulos que são compostos de temas correlacionados visando esclarecer a aplicação das técnicas de

medições previstas contratualmente. Cabe esclarecer que nem todos os itens são aplicáveis a todos os contratos. Neste caso devem ser observadas as regras dispostas em cada contrato.

1.2. Abaixo são listados os capítulos e o seu contexto de aplicação no processo de medição.

Capítulo Aplicação Capítulo 1. Orientações gerais sobre o processo de métricas da CAIXA

• Regra a ser utilizada em todo o processo de medição e em todos os contratos que viabilizem serviço de desenvolvimento e manutenção de sistemas remunerados pela APF.

Capítulo 2. Medição de Serviços em APF

Capítulo 3. Log, Trilha de Auditoria, Registro de Eventos e Histórico

Capítulo 4. Procedimento para Medição de Alteração de Escopo

Capítulo 5. Atualização de Baseline de Serviço, de Baseline de Produção e Contagem de Aplicação Capítulo 6. Manutenção Adaptativa, Perfectiva e Corretiva.

Capítulo 7. Processo de Divergência entre Contagens • Regra a ser utilizada em todo o processo de medição e em todos os contratos que viabilizem serviço de desenvolvimento e manutenção de sistemas remunerados por: APF, SNAP, UST e INM.

Capítulo 8. SNAP – Software Non-functional Assessment Process • Regras aplicáveis ao contrato 6870/2015 sistemas de informação para automação de produtos e serviços bancários de agências - SISAG.

• Regras aplicáveis ao Termo de Referência da Carteira de Cartão de Débito Novo Pregão 2016 • Regras aplicáveis ao Termo de Referência da Carteira de Mobilidade Pregão 2016.

Capítulo 9. SISRA - URA • Regras aplicáveis aos contratos de sistemas de URA. Capítulo 10. CONTRATO HOME BROKER • Regras aplicadas aos serviços de Manutenção Evolutiva do contrato 0758/2012, Processo

5307.01.0548.01/2012, operacional na CEDES/SP, referente ao aluguel de solução de negociação on-line de títulos e valores mobiliários negociados na Bolsa de Valores, Mercadorias e Futuros de São Paulo – BM&FBOVESA, denominada HOME BROKER.

Capítulo 11. Orientação de Contagem UST para Portais de Conteúdo • Regras aplicadas ao contrato nº 1497/2012, referentes à linha de negócio Novas Tecnologia, mas de caráter restritivo, por se aplicar apenas às soluções de Portal de Conteúdo.

Capítulo 12. Diretrizes de Contagem do SIDEC • Regras aplicadas para realização de contagem envolvendo tão somente o sistema SIDEC, constante no contrato nº 05405/2012.

Capítulo 13. Diretriz de contagem para sistemas DW/BI • Diretrizes a serem utilizadas em todo o processo de medição funcional para todos os sistemas de Data Warehouse remunerados pela APF e para medições não funcionais com método SNAP, subcategoria 1.4 – Movimentações de Dados Internos.

Capítulo 14. Glossário • Utilizado em todo o processo de medição e em todos os contratos.


Página 8 de 73

2. Técnicas de Medição na CAIXA 2.1. A CAIXA utiliza a técnica de Análise de Pontos de Função – APF para determinar

tamanho funcional.

2.2. Para visão de tamanho exclusivamente não funcional, a CAIXA adota: 2.2.1. Tabela de Itens Não Mensuráveis pela APF. Entretanto, esta abordagem está em

desuso e sua aplicação é condicionada a existência de contratos de prestação de serviços de TI que explicitamente citem tais tabelas em seus editais e/ou termos de referência.

2.2.2. Metodologia Software Non-Functional Assessment Process (SNAP), nos contratos

que permitem tal recurso observando sempre as subcategorias homologadas pela CAIXA.

2.2.3. UST – Unidade de Serviço Técnico, nos contratos que permitem tal recurso. 2.3. Deverão sempre ser observadas as regras nos contratos de desenvolvimento, que

detalham tratamentos específicos para medições de software. 3. Análise de Pontos de Função na CAIXA 3.1. Pontos de função é uma medida de tamanho, usada para medir o desenvolvimento

de software do ponto de vista do usuário.

3.2. O desenvolvimento de software pode ser medido na perspectiva do produto final instalado, (contagem da aplicação) ou na perspectiva do produto em desenvolvimento, quer seja uma demanda de manutenção (Projeto de Melhoria) ou a criação de uma nova solução tecnológica (Projeto de Desenvolvimento).

3.3. A medida de tamanho associada à solicitação do usuário é estabelecida pela quantificação da funcionalidade que o software provê ao usuário, observado o escopo que estabelece as funcionalidades que serão incluídas em uma determinada contagem.

3.4. Para estabelecer tamanho funcional, a técnica de Análise em Pontos de Função - APF, de acordo com as especificações contidas no Function Point Counting Practices Manual (CPM), versão 4.3.1 ou superior, publicado pelo IFPUG – International Function Point Users Group, é adotada pela CAIXA para estabelecer o tamanho funcional das soluções desenvolvidas e mantidas em seu Portfólio de TI.

3.5. Na CAIXA, a técnica preconizada pelo IFPUG é conhecida como método de CONTAGEM DETALHADA e as técnicas definidas pela NESMA (Netherlands Software Metrics Users Association) são conhecidas como método de CONTAGEM ESTIMADA ou método de CONTAGEM INDICATIVA.

3.6. No processo de medição da CAIXA, não há adoção da abordagem Multiple Media publicada pelo IFPUG, tampouco adoção do Roteiro de Métricas de Software do SISP ou qualquer diretriz adicional de mercado ou academia. Todas as apropriações e adaptações válidas são listadas neste Guia de Orientações de Métricas, que representa o único meio de apropriação, esclarecimento e exemplificação das regras de APF no contexto institucional.


Página 9 de 73

4. Ponto SNAP na CAIXA 4.1. A CAIXA adotará o Software Non-functional Assessment Process (SNAP), conforme

Manual de Práticas de Avaliação APM/SNAP versão 2.3 nas subcategorias delimitadas neste Guia de Métricas (vide Capítulo 8 - SNAP – Software Non-functional Assessment Process) para a medição dos requisitos não funcionais nos contratos que permitam tal métricas.

4.2. Amparado pela publicação mais estável da metodologia SNAP/IFPUG, o GT de Métricas, recomendou a adoção desta técnica para medição dos requisitos não funcionais. Esta métrica possibilitará estabelecer uma ligação entre o tamanho não funcional e o esforço para prover os requisitos não funcionais. Ademais, a utilização do SNAP poderá prover melhorias no atual modelo de estimativas utilizado pela CAIXA.

4.3. É facultada a CAIXA a adoção de versão posterior a 2.3 do APM/SNAP.

4.4. Caso a CAIXA opte por uma versão posterior a 2.3, a CONTRATADA obriga-se a adaptar-se, no prazo máximo de 1 (um) mês, a partir da comunicação formal pela CAIXA.

4.5. O método de determinação do tamanho não funcional DETALHADO SNAP seguirá a metodologia descrita pelo IFPUG Manual de Práticas de Avaliação APM/SNAP versão 2.3.

4.6. Não há previsão no Manual de Práticas de Avaliação APM/SNAP versão 2.3 forma para determinar o tamanho não funcional ESTIMADO SNAP. No entanto, no contexto da CAIXA, será estabelecido um processo de determinação do tamanho não funcional ESTIMADO SNAP, conforme o Capítulo 8 - SNAP – Software Non-functional Assessment Process deste Guia de Orientação de Métricas.

4.7. Não serão adotados conceitos análogos àqueles da contagem indicativa (NESMA) para SNAP.

5. Processo de Medição 5.1. Na perspectiva do Processo de Medição de Software da CAIXA, a atividade de

contagem é exercida por empregado CAIXA ou empresa especializada por ela designada, não sendo admitido acatar medições de Fábricas de Software ou Terceiros.

5.2. Caso conste em algum contrato a execução de contagem pelo fornecedor do serviço, a CAIXA deve, obrigatoriamente, proceder com a execução de uma nova contagem, sem desobrigar a CONTRATADA a fornecer a medição prevista em contrato.

5.3. Mesmo sendo da CAIXA a atividade de medição, cabe à CONTRATADA gerar sua contagem, e fiscalizar os resultados produzidos em seus processos internos, bem como aqueles produzidos pela CAIXA ou por empresa especializada que represente a Contratante.

5.4. As diferenças entre as contagens da CAIXA e da Contratada são objetos de divergência, observado o processo descrito no Capítulo 7 - Processo de Divergência entre Contagens.

5.5. No processo de medição deve ser priorizada a aplicação do método de contagem detalhada do IFPUG.


Página 10 de 73

6. Artefatos do Processo de Métricas da CAIXA 6.1. Os modelos de todos os artefatos de métricas estão disponíveis no http://ppds.caixa. 6.2. Todos os artefatos de métricas utilizados no processo de medição devem ser

armazenados no repositório oficial da CAIXA, conforme o padrão da metodologia adotada, vinculados ao seu respectivo projeto/sistema.

6.3. A tabela abaixo apresenta a lista de artefatos presentes no processo de medição:

ARTEFATO DESCRIÇÃO Laudo de Contagem.xls Planilha que contém informações sobre:

• Solicitação de demanda de medição de software (preenchimento pela equipe de desenvolvimento)

• Contagem realizada e considerações sobre a contagem (preenchimento pela equipe interna ou pela empresa contratada de métricas)

• Formulário de divergência (preenchimento pela fábrica de desenvolvimento em caso de divergência)

Estimativa_Estruturada.xls Planilha que contém informações sobre as estimativas de prazo e custo relacionadas a demandas que seguem o Cenário de Desenvolvimento Análise Estruturada. Essa planilha recebe os dados da contagem da planilha Contagem_APF.xls.

Estimativa_Unificado.xls Planilha que contém informações sobre as estimativas de prazo e custo relacionadas a demandas que seguem a Metodologia de Desenvolvimento Processo Unificado. Essa planilha recebe os dados da contagem da planilha Contagem_APF.xls

Estimativa_Versoes.xls Planilha para contagens de pacotes de demandas de desenvolvimento que contém informações sobre:

• Solicitação de demanda de medição de software (preenchimento pela equipe de desenvolvimento)

• A contagem realizada e considerações sobre a contagem (preenchimento pela equipe interna ou pela empresa contratada de métricas)

• Formulário de divergência (preenchimento pela fábrica de desenvolvimento em caso de divergência)

Auditoria_Metrica.doc Validação de estimativas por amostragem: documento utilizado pelo SME – Segmento de Métricas para registrar a validação das contagens de produtos e serviços.

6.4. A qualquer momento, a CAIXA poderá criar/excluir/modificar/atualizar os artefatos vigentes.

6.5. Insumos básicos para aplicação das técnicas de APF por cenário de

desenvolvimento 6.5.1. No ciclo de desenvolvimento de sistemas definidos pela CAIXA está previsto a

produção e a entrega de artefatos que representem o produto de software requerido.

6.5.2. Cabe à equipe de projeto/manutenção executora do serviço, a produção de artefatos previstos nas metodologias da CAIXA e necessários ao produto de software requerido com a devida qualidade assegurada, tanto na perspectiva funcional, quanto na não funcional.

6.5.3. Também é responsabilidade da equipe de projeto/manutenção executora do serviço, assegurar que os artefatos gerados sejam passíveis de medição pela APF. Essa obrigação também é aplicada aos serviços medidos por outras técnicas.


Página 11 de 73

6.5.4. Quando não for exigida contratualmente adequação aos padrões, às normas, às rotinas e à metodologia da CAIXA, deve ser negociado entre as partes, CONTRATANTE e CONTRATADA, os insumos básicos e condições para aplicação da técnica de medição. Entretanto, é responsabilidade da CONTRATADA prover as informações necessárias à contagem, garantida à qualidade exigida para aplicação do método preconizado pelo IFPUG ou do método previsto em contrato.

6.5.5. É obrigatória a identificação das funcionalidades que compõem o escopo do produto de software requerido, bem como a identificação – na perspectiva da fronteira do sistema – daquelas que estão sendo incluídas, alteradas ou excluídas.

6.5.6. Ressalta-se que a precisão do tamanho obtido na contagem é diretamente proporcional à qualidade dos artefatos que servirão de insumos ao processo de medição.

6.5.7. Considerando os cenários de desenvolvimento mais utilizados na CAIXA, os insumos básicos são listados na tabela a seguir.

Cenário de Desenvolvimento Análise Estruturada

Documentação Contagem Indicativa

Anteprojeto A partir do Planejamento

Contagem Estimada

Contagem Detalhada

Modelo Preliminar de dados ou excepcionalmente Modelo conceitual (por Ex. em caso de VSAM)

X* X

Especificação preliminar de requisitos X Modelo de dados ou excepcionalmente Modelo conceitual (por Ex. em caso de VSAM)

X* X

Especificação suplementar X X Modelo de dados aprovado pela AD X X X DFD - nível de explosão de acordo com a fase do projeto (opcional no anteprojeto para todas as classes de projeto. A partir do planejamento, opcional para a classe 1, recomendado para a classe 2 e mandatório para a classe 3 de projetos)

X X

Lista de requisitos aprovada pelo gestor (evidência de aprovação em email ou ata)

X

Registro de requisitos detalhados aprovados pelo gestor (evidência de aprovação em email ou ata)

X

Protótipo (opcional para Classe 1 e recomendável para as classes 2 e 3 de projetos)

X

AIMM - Análise de Impacto de Mudança para Manutenção

X X *:Deve existir pelo menos um dos documentos O Opcional Opcopasdfasdf

Cenário de Desenvolvimento Processo Unificado


Iniciação A partir da Elaboração

Contagem Estimada

Contagem Detalhada

Modelo lógico de dados ou excepcionalmente Modelo conceitual (por. Ex. em caso de VSAM)

X

Modelo visão X Modelo lógico de dados aprovado pelo AD X X X Relatório sintético de casos de uso

X Validação do Modelo de Dados X Casos de usos homologados X Especificação suplementar X X Regras de Negócio X


Página 12 de 73

Mensagens do Sistema X Protótipo ou Descrição da Interface do Caso de

Uso (quando possível) X

AIMM - Análise de Impacto de Mudança para Manutenção

X X

Cenário de Desenvolvimento Ágil


Contagem Estimada

Contagem Detalhada

Regras de Negócio x Produto Backlog aprovado X x História do Usuário x x Lista de Funcionalidades x x Modelo lógico de dados x x Documento Visão x Protótipo x

6.5.8. As contagens detalhadas para demandas PERFECTIVA e ADAPTATIVA necessitam

possuir como insumo pelo menos a Especificação Suplementar. 6.6. Insumos básicos para aplicação da técnica SNAP por cenário de

desenvolvimento

Cenário de Desenvolvimento Processo Unificado

Documentação A partir da

Iniciação Elaboração Estimada Detalhada

Análise de Impacto da Mudança para Manutenções ou Plano de Atendimento.

X X

Arquivo com a demanda do RTC ou solicitação de serviço

X X

Relatório sintético de casos de uso X Requisitos e/ou Caso de Uso X X Funcionalidades que terão outra Camada de apresentação, modelo de dados e documento de visão

X

Requisitos Não Funcionais (Especificação Suplementar), modelo de dados e modelo físico de dados, diagrama de classes.

X X

Documento de Arquitetura X X Protótipo ou Descrição da Interface do Caso de Uso X

Cenário de Desenvolvimento Análise Estruturada

Documentação Anteprojeto A partir do

Planejamento Contagem Estimada

Contagem Detalhada

Especificação preliminar de requisitos X DFD - nível de explosão de acordo com a fase do projeto (opcional no anteprojeto para todas as classes de projeto. A partir do planejamento, opcional para a classe 1, recomendado para a classe 2 e mandatório para a classe 3

X X

Lista de requisitos X Requisitos Não Funcionais (Especificação Suplementar), modelo de dados e modelo físico de dados, diagrama de classes.

X X

Registro de requisitos detalhados X

Protótipo (opcional para Classe 1 e recomendável para as classes 2 e 3 de projetos)

X

Documento de Arquitetura, Modelo de Dados. X X


Página 13 de 73

AIMM - Análise de Impacto de Mudança para Manutenção X X

6.7. Insumos necessários para aplicação da Tabela de Ite ns Não

Mensuráveis pela APF 6.7.1. O uso da TABELA DE ITENS NÃO MENSURÁVEIS está em descontinuidade no

processo de medição de software da CAIXA. A aplicação desta tabela condicionada a existência de contratos de prestação de serviços de TI que explicitamente citem tais tabelas em seus editais e/ou termos de referência.

ITENS

Documentação 1 2 3 4 5 6 7 9 10 Análise de Impacto da Mudança e/ou Plano de X X X X X X X X X Arquivo com a demanda do RTC, solicitação de serviço ou especificação de negócio.

X X X X X X X X X

Relatório com a descrição das mudanças e evidências

X X X X X X

Requisitos das funções transacionais que terão outra Camada de apresentação, modelo de dados.

X

Requisitos e modelo de dados. X Especificação de programa. X

1-Telas/Layout; 2-Campos/Variáveis; 3-Mensagens; 4-Menus; 5-Dados Hard Coded; 6-Parâmetros Processamento; 7-Camada Apresentação Adicional; 9-Code Table; 10-Programas Auxiliares Ou Componentes/ Sub-Rotinas.

6.7.2. Quando não for exigida contratualmente adequação aos padrões, às normas, às

rotinas e à metodologia da CAIXA, deve ser negociado entre as partes, CONTRATANTE e CONTRATADA, os insumos básicos e condições para aplicação da técnica de medição. Entretanto, é responsabilidade da CONTRATADA prover as informações necessárias à contagem, garantida à qualidade exigida para aplicação do método preconizado pelo IFPUG ou do método previsto em contrato.

7. Validação das Medições Realizadas 7.1. Na CAIXA, o termo validação é aplicado em três cenários distintos: (1) Contrato de

Métricas (terceirização do serviço de medição); (2) Processo de Verificação de Qualidade; (3) Fiscalização de Serviços Contratados medidos.

7.2. Na perspectiva do Contrato de Métricas (1), o termo refere-se ao serviço de Validação de Contagem, que é executado por empresa especializada em métricas de software, onde a partir de uma medição pré-existente são gerados o artefato de contagem e o relatório de divergências/erros. Esse processo é de uso exclusivo da CAIXA e, é aplicado aos contratos de desenvolvimento e manutenção de soluções tecnológicas que possuem regras contratuais exigindo que o fornecedor (desenvolvedor) do serviço execute contagem em pontos de função e/ou em contagens realizadas por empregado CAIXA. Neste contexto, a CAIXA:

7.2.1. Recebe a contagem do fornecedor, ou da equipe CAIXA, e os insumos que fundamentaram a medição;

7.2.2. Contrata empresa especializada para contar a demanda a partir dos insumos;

7.2.3. Diante do resultado, entrega a contagem do fornecedor/equipe CAIXA e solicita a análise comparativa das duas contagens. Os resultados são discutidos com o a equipe fornecedora da contagem original.


Página 14 de 73

7.3. Na perspectiva de Processo de Verificação de Qualidade (2), o termo Validação de Contagem refere-se ao produto gerado em uma fase do processo de desenvolvimento/manutenção de software que pode passar por um processo de aferição de qualidade, composto por técnicas e critérios específicos. Neste caso, a Validação de Contagem é realizada segundo o plano de qualidade do projeto e/ou práticas da unidade, observado o processo metodológico adotado no atendimento do serviço e suas respectivas necessidades.

7.4. Na perspectiva de Fiscalização de Serviços Contratados (3), o termo Validação de Contagem refere-se ao DEVER da Administração Pública de FISCALIZAR os seus contratos, conforme o artigo 67 da Lei 8.666/93. Essa obrigação da CAIXA, quando falamos no Contrato de Métricas, é assumida pelos SME – Segmento de Métricas, que validam as contagens contratadas por amostragem. Este processo de fiscalização é também conhecido como Auditorias dos SME, cujo processo possui artefato específico, denominado Plano de Auditoria. A execução é exclusivamente realizada por empregado da CAIXA.

7.5. A qualquer tempo, toda vez que um processo de validação resultar em ajuste no

tamanho inicialmente estabelecido, a CAIXA adotará as providencias necessárias à correção de valores pagos indevidamente, caso existam, sem prejuízo as demais sanções e penalidades contratuais, quando cabíveis. Essa instrução é aplicada a todos os fornecedores envolvidos no processo de desenvolvimento que tiveram seus serviços vinculados ao tamanho medido. Os ajustes nas demais estimativas devem observar o modelo de contratação vigente para o serviço em análise.


Página 15 de 73

Capítulo 2. Medição de Serviços em APF 1. Fronteira da Aplicação e Escopo

1.1. As fronteiras das aplicações e o escopo da medição são definidos pela CAIXA. A

qualquer momento, segundo a visão de negócio, a CAIXA poderá ajustar as fronteiras das aplicações.

1.2. O escopo da medição sempre considerará os objetivos da CAIXA. 2. Migração de Base de Dados 2.1. O conceito de migração de dados pressupõe que foi desenvolvido um novo sistema

(ou funcionalidade) para substituir um (a) já existente e, para que o novo sistema possa começar a ser utilizado, é necessário que haja a extração de dados do antigo e a carga destes dados no novo sistema. Dentro da própria contagem do projeto, devido a uma migração, devem ser contadas as entradas externas que povoarão (conversão e gravação) a base de dados do novo sistema e as consultas/saídas externas referentes a relatórios sobre a conversão dos dados solicitados pelo gestor.

2.2. Normalmente, em uma migração, há uma entrada externa para cada grupo de dados sendo migrado. Porém, isso não é uma regra e as entradas externas devem ser contadas conforme a visão do usuário. Estas entradas externas englobam: a extração/leitura dos dados do sistema antigo, conversões destes dados, se for o caso, e a carga dos dados no novo sistema.

2.3. Os arquivos onde se encontram os dados do sistema antigo não devem ser contados como AIEs. As extrações dos dados do sistema antigo não devem ser contadas como CEs nem SEs.

2.4. Dependendo da complexidade do processo de migração de dados e das necessidades das áreas de negócio, a CAIXA poderá classificar tal processo como Projeto de Migração de Base de Dados, caracterizando escopo específico, mas ainda aplicando integralmente os conceitos do IFPUG. Caso o processo de migração não seja classificado como Projeto de Migração de Base de Dados, deve ser aplicada a regra geral acima descrita.

2.5. Por características específicas das soluções, não é recomendado adotar Projeto de Migração de Base de Dados em soluções de Portal de Conteúdo.

2.6. O artefato de contagem do projeto de migração deve ser preenchido da seguinte forma:

2.6.1. As funções de dados devem ser obrigatórias e oriundas do projeto de desenvolvimento, e o seu preenchimento no artefato de contagem ficará com o status “não se aplica” quando esta função já tenha sido contada no projeto de desenvolvimento;

2.6.2. É pré-requisito para contagem de projeto de migração o modelo de dados do sistema de negócio ou artefato similar;


Página 16 de 73

2.7. Situações não previstas neste Guia serão discutidas no GT de Métricas e incluídos em versões posteriores deste documento.

3. Fator de Ajuste da Contagem (IFPUG) 3.1. De acordo com o IFPUG, aplicação das CGSs, cálculo do VAF, e cálculo do tamanho

funcional ajustado não estão incluídos no FSM do IFPUG e são considerados opcionais no CPM do IFPUG.

3.2. A CAIXA não adota o conceito de Pontos de Função Ajustados. 4. Fator de Ajuste do Serviço em Projetos de Migraç ão de Base de

Dados 4.1. Para projetos de Migração de Base de Dados, o Valor do Fator de Ajuste do Serviço

será fixado pela CAIXA para derivação de estimativa de custo, esforço e prazo e será estabelecido em 1,35 (um vírgula trinta e cinco), sem qualquer vínculo com a avaliação das características gerais do sistema e com o fator de ajuste da contagem.

4.2. O temo Fator de Ajuste do Serviço é um definição contratual, aplicada quando da existência de regras específicas, explicitamente descritas. Não deve ser confundido com Fator de Ajuste da Contagem, conceito de uso opcional descrito no Manual de Práticas de Contagem do IFPUG e não adotado pela CAIXA.

5. AIE – Arquivo de Interface Externa 5.1. No processo de medição os AIE são obrigatoriamente identificados e medidos. A

remuneração à CONTRATADA deverá observar a regra contratual vigente. Havendo previsão de pagamento do AIE, o preenchimento do artefato de contagem deve estar registrado como AIE de esforço.

6. Code Data ou Code Table 6.1. Os conceitos de Code Data e Code Table na CAIXA observam as definições do CPM

4.3.1. 7. Code Data VS AIE 7.1. Há casos em que um sistema A consulta/referencia somente os campos “código” e

“descrição” de um grupo de dados do sistema B. Devemos considerar que no sistema A existe uma Code Table ou um AIE? Depende:

7.1.1. Se o grupo de dados referenciado for um ALI no sistema B, então devemos contar

um AIE no sistema A (conforme decisão CPC);

7.1.2. Se o grupo de dados referenciado for Code Data no sistema B, então devemos considerá-lo também como Code Data no sistema A.


Página 17 de 73

7.2. Um exemplo da situação 7.1.1 seria o caso do SIICO onde os dados de UF (Unidade Federativa) são um ALI e, por isso, devem ser referenciados como AIE por outros sistemas, mesmo que estes sistemas só referenciem a Sigla e o Nome da UF.

8. Contagem de interfaces com sistemas - AIE 8.1. Devem ser considerados os grupos de dados distintos segundo visão do usuário da

aplicação que estiver sendo contada. De acordo com o manual, a fronteira é dependente da visão de negócio externa do usuário da aplicação. Ela é independente de considerações técnicas ou de implementação.

8.2. Exemplo : Considere que no SIICO existem os seguintes ALIs: “Unidade” contendo dados das unidade da CAIXA; “Imóvel” contendo os dados de todos imóveis da CAIXA, inclusive das unidades; e “Tipo de Meio de Comunicação”, contendo informações, por exemplo, se um telefone é PABX, Celular, etc.

8.2.1. Agora imagine que foi solicitada a contagem do SIXXX e que o gestor deseja ver os seguintes dados das Unidades CAIXA: CNPJ, Endereço e Telefone Geral.

8.2.2. Para recuperar esses dados devemos referenciar no SIICO “Unidade”, “Imóvel” e “Tipo de Meio de Comunicação”. Porém, na visão do usuário da aplicação sendo contada (SIXXX), ele está recuperando apenas informações de Unidade. No negócio do gestor do SIXXX há apenas o grupo lógico de dados de Unidade, ele não reconhece os grupos: “Imóvel” e “Tipo de Meio de Comunicação”. Assim, devemos contar no SIXXX somente o AIE “Unidade”.

9. Impacto das alterações das características de it ens de dados de um

ALI e nas funções transacionais que o mantêm (CPM 4 .3.1) 9.1. Manutenções evolutivas e alterações de escopo que apresentem funcionalidades

impactadas com alterações nas características de campos em tabelas e telas não serão medidas pela APF se estiverem relacionadas a questões técnicas.

9.2. Exemplo 01 : Suponha uma solicitação que parta de um DBA a partir da observação sobre um determinado campo ter uma definição de tamanho bem maior que os valores realmente armazenados e deseja reduzi-lo para otimizar o espaço ocupado pelo banco de dados. Se for relativa a uma necessidade do negócio, será medido conforme descrito no manual (CPM 4.3.1, Parte 2, Página 4-2), a partir da evidência da solicitação do gestor e da aprovação da área de suporte/qualidade sobre a ocorrência de alteração nos atributos.

9.3. Exemplo 02 : Suponha uma mudança de origem externa à organização - mudança do número do telefone de 7 para 8 dígitos e do CEP de 5 para 8 dígitos. Quanto às funções transacionais que referenciam este ALI alterado, deve-se considerar: Segundo orientação do CPC, o simples fato de o DER alterado cruzar a fronteira da aplicação nas transações que o mantêm ou referenciam NÃO é suficiente para pontuarmos essas transações como alteradas na contagem da manutenção evolutiva. Somente serão pontuadas na contagem da manutenção evolutiva aquelas transações que, em decorrência da alteração do DER, sofrerem alteração em sua lógica de processamento (mudança na forma de validação do DER, por exemplo).

9.4. Exemplo 03 : Numa aplicação, o gestor solicitou que o campo de número do telefone residencial do cliente passe a suportar 8 dígitos. Além disso, foi solicitado que nas funcionalidades de inclusão e alteração de clientes, caso o cliente resida no Distrito Federal, seja obrigatório que seu telefone residencial tenha oito dígitos, sendo que o primeiro à esquerda deve ser igual a 3. Desta forma, observa-se alteração na lógica de processamento das entradas externas de inclusão e alteração de clientes. Ambas


Página 18 de 73

seriam pontuadas na manutenção evolutiva como “alteradas”. As funcionalidades de exclusão de cliente e consulta a clientes não sofreram alteração alguma em decorrência da mudança do DER e não seriam pontuadas.

10. Integração de Sistemas 10.1. Para contagem de integração de sistemas será aplicado os cenários de

compartilhamento de dados previstos no CPM 4.3.1.

10.2. Nos cenários de integração de dados entre sistemas que sejam providas por outra aplicação (MIDDLEWARE) será adotado o white paper (Pontos de Função & Contagem de Software Aplicativo Middleware) do IFPUG que trata deste tema. Exemplo de Middleware : SICLI - IPPO – Interface Padrão Parametrizada Online.

11. Integração de Sistema de Segurança 11.1. Na CAIXA as unidades de desenvolvimento possuem diferentes estruturas de

segurança dos seus sistemas, devendo avaliar os cenários na realização da contagem.

11.2. Os ALR deverão ser avaliados para determinar complexidade na função de transação LOGON. Estes ALR deverão ser observados se estão registrados nos insumos de contagem apresentados.

11.3. Nas funções de transação em que o sistema de segurança seja referenciado (exemplo SISGR) deverá ser avaliada a necessidade de negócio, e não sua restrição tecnológica, para que seja contada.

12. Consultas Dinâmicas 12.1. Considerar como uma função transacional do tipo CE ou SE, independentemente da

quantidade de resultados que ele gera. Para se determinar a complexidade deve ser considerado o cenário mais abrangente com todos os possíveis DER – Dados Elementares Referenciados e ALR - Arquivos Lógicos Referenciados.

13. Funcionalidades iguais apresentadas em diferent es formatos de

saída 13.1. As funcionalidades iguais apresentadas em diferentes formatos de saída só serão

consideradas uma única vez para a contagem. Formatos diferentes não caracterizam quebra de lógica de processamento no ponto de vista do usuário.

13.2. Esta abordagem está alinhada ao item 3.6 do Capítulo 1 Orientações gerais sobre o processo de métricas da CAIXA, onde a CAIXA não adota o conceito de Multiple Media.


Página 19 de 73

14. Desenvolvimento em Múltiplas camadas (mainframe , web)

14.1. Há casos em que o gestor solicita que uma mesma transação esteja disponível em duas plataformas diferentes (mainframe e web, por exemplo). Sob a ótica da APF, há apenas um processo elementar, pois ambas as transações implementam a mesma funcionalidade.

14.2. Esta abordagem está alinhada ao item 3.6 do Capítulo 1 Orientações gerais sobre o processo de métricas da CAIXA, onde a CAIXA não adota o conceito de Multiple Media. Sob a ótica do SNAP, este item pode ser medido e remunerado (caso haja previsão contratual) pela subcategoria Múltiplos Métodos de Saída, conforme item 4 Capítulo 8 SNAP – Software Non-functional Assessment Process.

15. Medição de componentes 15.1. Será avaliada a perspectiva funcional conforme CPM 4.3.1 IFPUG. 16. Funcionalidades Batch 16.1. Há casos em que rotinas batch são consideradas processos elementares e há casos

em que não são. Por determinação do CPC, os processos batch disparados pelo relógio do sistema (clock) em que nenhuma informação cruza a fronteira, não são considerados como processos elementares. Eles complementam algum processo elementar da aplicação.

16.2. Entretanto, no contexto CAIXA, o GT de Métricas identifica que automatização de funcionalidades que poderiam ser executadas de forma online com entrada de dados (por ex. data), mas que estão implementadas de forma batch. Neste cenário, ainda que não existam dados cruzando a fronteira da aplicação, a CAIXA reconhecerá como uma função transacional se:

16.2.1. A funcionalidade for a menor unidade de atividade significativa para o usuário e não

for parte de outro processo elementar.

16.2.2. A intenção primária for classificada exclusivamente como uma EE (Entrada Externa).

16.2.3. Ao final da execução a aplicação ficar em estado consistente. 16.3. Nestes casos, deverão consideradas como processos elementares considerando que

a forma de implementação é fator tecnológico.

17. Necessidade de realização de terceira contagem

17.1. Se não houver alteração funcional não é necessária a terceira contagem.

17.2. A equipe deve analisar e verificar se na contagem detalhada anterior não foram

incluídas funções, por exemplo de conversão. Nesse caso a contagem final (terceira contagem) seria necessária.

17.3. A equipe deve formalizar a não existência de alterações funcionais e a adoção da segunda contagem como a contagem final.


Página 20 de 73

Capítulo 3. Log, Trilha de Auditoria, Registro de E ventos e Histórico 1. Definições 1.1. Histórico : registro de informações passadas, quer seja para prestação de contas (a

órgão externos, superiores ou processos internos) ou por exigência do próprio cenário de negócio. Sua existência é justificada negocialmente e sua ausência traz um impacto e uma consequência negocial.

1.2. Log : registro de eventos cujo objetivo é possibilitar a monitoração dos recursos, bem como a auditoria do ambiente tecnológico da CAIXA.

1.3. Trilha de auditoria : constitui-se de um “log” (registro) de eventos históricos pré-definidos, destinado a ações de apuração de ocorrências, devendo identificar quem realizou a ação, quando, onde e o que foi realizado.

1.4. Registro de evento : monitoração de eventos associados à navegação e/ou acesso as funcionalidades do sistema, para fins estatísticos ou de obtenção de indicadores de uso do aplicativo.

2. Interpretação 2.1. Para que a Trilha de Auditoria ou Registro de Eventos sejam considerados como ALI

do sistema sendo contado, eles devem ser relevantes para o negócio. Sugere-se que seja avaliado o desenvolvimento de uma funcionalidade para o usuário realizar a consulta a esses dados e incorporá-la ao sistema.

2.2. O histórico, na maioria das vezes, é considerado registro lógico do ALI relacionado, devendo ser solicitado pelo gestor e deve haver no sistema funcionalidades de consulta a tais dados.

2.3. O Log não deverá ser medido ou ratificado por ser gerado de forma automática pelo

SGBD (ou por outro recurso tecnológico como, por exemplo, o servidor de transações), pertencendo, portanto, ao âmbito da tecnologia.


Página 21 de 73

Capítulo 4. Procedimento para Medição de Alteração de Escopo 1. Alteração de Escopo 1.1. Alteração de escopo é a mudança solicitada durante a execução do serviço de

desenvolvimento de novo sistema ou manutenção de um sistema existente. Estas solicitações de mudanças podem ou não ocasionar variações no tamanho do sistema que nem sempre são refletidas na contagem de pontos de função do sistema e serviços já desenvolvidos. Como forma de objetivar critérios de contratação, a CAIXA utiliza a fórmula de alteração de escopo para calcular a quantidade de PF a ser remunerada na execução das alterações referentes a entregas já realizadas e aceitas pela CAIXA, até o momento da alteração de escopo ser notificada à CONTRATADA.

1.2. Uma mudança só é caracterizada como alteração de escopo quando da existência de requisitos detalhados e homologados pelo Gestor.

1.3. A fórmula para calcular a quantidade de Pontos de Função para adequação das alterações nas fases/atividades já realizadas:

PF_Devido = { [ (Pi x Fri) + (Pe x Fre) + (Pa x Fra ) ] x (Pfe / Pft) }

Legenda:

PF_Devido Quantidade de Pontos de Função devida para adequação das alterações nas fases / atividades já realizadas

Pi Pontos de função das funções incluídas

Pe Pontos de função das funções excluídas

Pa Pontos de função das funções alteradas DEPOIS da alteração de escopo

Fri Fator de redução para funções incluídas = 1

Fre Fator de redução para funções excluídas = 1/4

Fra Fator de redução para funções alteradas = 1/2

Pfe Somatório da quantidade de PF das entregas contratadas já realizadas

Pft Tamanho funcional do serviço (sem inclusão de itens não-mensuráveis) ANTES da alteração de escopo

1.4. Observação: A atualização do tamanho do projeto de desenvolvimento e/ou

manutenção de software antes e após a alteração de escopo é obrigatória, para que a demanda inicial (agora alterada) possa ser redimensionada com relação à quantidade de pontos de função necessários para completar o projeto.

1.5. Quando da ocorrência de uma alteração de escopo três valores de pontos de função

devem ser obtidos: 1.5.1. A contagem detalhada ATUALIZADA do escopo antes da alteração de escopo; 1.5.2. A contagem DETALHADA da alteração de escopo; 1.5.3. A contagem DETALHADA após a alteração de escopo. Caso as funcionalidades

INCLUIDAS ainda não tenham os requisitos que as detalhem, então estas funcionalidades deverão ser medidas conforme o método preconizado pela NESMA.


Página 22 de 73

1.6. Para Portal de Conteúdo, a fórmula sofre adaptação para converter PF em UST, a saber:

UST Devida = { [(Pi x Fri) + (Pe x Fre) + (Pa x Fra ) ] x (Pfe / Pft) } * 8,73

Legenda:

UST_Devida Quantidade de UST devida para adequação das alterações nas fases / atividades já realizadas

Pi Pontos de função das funções incluídas

Pe Pontos de função das funções excluídas

Pa Pontos de função das funções alteradas DEPOIS da alteração de escopo

Fri Fator de redução para funções incluídas = 1

Fre Fator de redução para funções excluídas = 0 (zero)

Fra Fator de redução para funções alteradas = 1/2

Pfe Somatório da quantidade de PF das entregas contratadas já realizadas

Pft Tamanho funcional do serviço (sem inclusão de itens não-mensuráveis) ANTES da alteração de escopo

8,73 Fator de Conversão de PF para UST

1.7. Esclarecimentos e exemplificações sobre o ajuste financeiro das demandas após a

ocorrência de uma alteração de escopo são apresentados no item 2 do Capítulo 4 Procedimento para Medição de Alteração de Escopo.

1.8. Cabe à equipe de desenvolvimento, interna ou terceirizada, registrar nos documentos

previstos na metodologia da CAIXA a alteração de escopo, única evidência que viabiliza a remuneração. A ausência de controle de mudança inviabiliza a caracterização da alteração de escopo e a consequente medição.


Página 23 de 73

2. Gestão Financeira das Demandas com Alteração de Escopo

Figura 1 - Fluxo sintético da gestão financeira de demandas com alteração de escopo.


Página 24 de 73

3. Passos do Fluxo Sintético da Gestão Financeira d e Demandas com Alteração de Escopo 1. Identificação da alteração de escopo

Identificam-se as funções alteradas, incluídas e excluídas pela alteração de escopo. Essa análise é realizada utilizando-se o artefato Análise de impacto de mudança para manutenção.

2. Identificação do percentual já entregue do serviço até o momento da alteração de escopo: Identifica-se o percentual já realizado do trabalho referente à Ordem de Serviço de desenvolvimento ou manutenção. Esse percentual servirá para mostrar o quanto deve ser remunerado para o retrabalho referente à alteração de escopo.

3. Quantificação dos pontos de função por meio da fórmula de alteração de escopo Etapa onde se aplica a fórmula de alteração de escopo, identificando as funções incluídas, alteradas e excluídas e o percentual já realizado do trabalho, assim como os indicadores percentuais por tipo de funcionalidade (100% para as incluídas, 50% para as alteradas e 25% para as excluídas). Nessa fase, abre-se a Ordem de Serviço de alteração de escopo na ferramenta de gestão de contratação. Se necessário, é ainda solicitada a atualização da contagem pré-existente antes da alteração de escopo.

4. Atualização do tamanho funcional do serviço após alteração de escopo Ocorre a contagem da linha de base do serviço após a alteração de escopo. Tem por objetivo identificar e atualizar o novo tamanho do serviço, para representar o que ainda deverá ser remunerado em PF. Aplica-se a fórmula:

AFP = (UFPB + ADD + CHGA) - (CHGB + DEL) Onde:

AFP – Número de pontos de função não ajustados do escopo total do serviço. UFPB – Número de pontos de função não ajustados da aplicação antes da alteração de escopo. ADD – Número de pontos de função não ajustados das funções incluídas pela alteração de escopo. CHGA – Número de pontos de função não ajustados das funções modificadas depois do término da alteração de escopo. CHGB – Número de pontos de função não ajustados das funções modificadas antes d do término da alteração de escopo. DEL - Número de pontos de função não ajustados das funções excluídas pela alteração de escopo.

5. Atualização do novo tamanho do sistema após a alteração de escopo e do percentual restante a ser remunerado Identifica-se o percentual e quantitativo de PF a ser remunerado, considerando o tamanho antes da alteração de escopo e o tamanho após a alteração de escopo. O novo tamanho do sistema não representa o quantitativo em PF a ser remunerado. O cálculo do quantitativo em PF a ser remunerado considera o percentual já realizado sobre o tamanho anterior a alteração de escopo mais o percentual a realizar sobre o tamanho posterior a alteração de escopo, ou seja: Quantidade de PFs a remunerar = (Quantidade de PF da linha de base anterior à alteração de escopo x o percentual já entregue do serviço antes da alteração de escopo) + (Quantidade de PF da linha de base posterior à alteração de escopo x percentual ainda a ser entregue do serviço depois da alteração de escopo)

6. Contagem de apli cação Ao final do desenvolvimento e/ou manutenção, após a entrega do sistema/manutenção é realizada/atualizada a contagem de aplicação.

7. Cálculo da quantidade de PF devido (a ser remunerado) ao final O tamanho funcional obtido da contagem de aplicação não representa o quantitativo em PF a ser remunerado, ou seja, o quantitativo de PF devido. O tamanho a ser remunerado considera o percentual já realizado sobre o tamanho anterior a alteração de escopo, mais o percentual a realizar sobre o tamanho posterior a alteração de escopo e mais o scope creep (se houver), representado pela fórmula: Quantidade de PFs devido ao final do desenvolvimento/manutenção = Quantidade de PF da linha de base anterior à alteração de escopo x o percentual já entregue do serviço antes da alteração de escopo + Quantidade de PF da linha de base posterior à alteração de escopo x percentual ainda a ser entregue do serviço depois da alteração de escopo + Quantidade de PF da contagem de aplicação (Final) – PF da linha de base posterior a alteração de escopo


Página 25 de 73

3.1. Algumas Considerações 3.1.1. As fórmulas apresentadas visam remunerar as Contratadas no caso de alterações de

escopo; 3.1.2. As fórmulas para o cálculo da “Quantidade de PF a remunerar” garantem a correta

remuneração em caso de alterações de escopo tanto aumentando quanto diminuindo o tamanho da aplicação após a alteração de escopo;

3.1.3. No caso de várias alterações de escopo sequenciais, a fórmula de “Quantidade de PF

a remunerar” considerará para “PF da linha de base posterior a alteração de escopo” o quantitativo de PF da linha de base da última alteração de escopo definida;

3.1.4. No caso de alterações recursivas1, será necessário emitir TR e TA da alteração de

escopo em andamento, antes de abrir outra Ordem de Serviço para a segunda alteração de escopo.

3.2. A título de exemplo , em uma simulação desse processo com uma alteração de

escopo no final da fase de construção é apresentada, considerando 88% do ciclo de desenvolvimento/manutenção executado.

SIMULAÇÃO DO PROCESSO DE ALTERAÇÃO DE ESCOPO

Contagem ini cial do

desenvolvimento 83 PF

Calculo alteração escopo

Alteração de escopo: incluídos 40 PFs, alterados 29 PFs e excluídos 0 PFs pela 1a alteração de escopo. Desta forma o tamanho da alteração de escopo é de: PF_Devido = [ (Pi x Fri) + (Pe x Fre) + (Pa x Fra) ] x (Pfe / Pft) PF_Devido = [ (40 x 1) + (29 x 0,5) ] x 0,88 = (40 + 14,5) x 0,88 = 54,5 PF x 0,88 = 47,96 PF Isso quer dizer que a alteração de escopo será remunerada considerando 88% (o que já foi realizado) – 47,96 PF

SISTEMA DE CONTRATAÇÃO

Automatização de operações pelo SISTEMA DE CONTRATAÇÃO Abertura de OS de alteração escopo e o sistema calcula o qtd PF - Inserir as alterações (qtd alterados, incluídos e excluídos) - Inserir o percentual a ser considerado já realizado (ou não, se o sistema conseguir recuperar) O SISTEMA DE CONTRATAÇÃO calcula o quantitativo de PF da alteração Observações: Neste caso o SISTEMA DE CONTRATAÇÃO não deve recalcular retroativamente o tamanho do sistema, pois o esforço advindo do tamanho em PFs já contempla todas as atividades necessárias para estabelecer a alteração de escopo pelas fases já executadas (ou seja: os 88% já realizados do projeto de software).


Abrir OS métrica para atualizar a linha de base de tamanho do Serviço: atualização do tamanho funcional do serviço após alteração de escopo

Este passo é fundamental para comparar dois resultados:

1) Valor calculado: o valor da nova linha de base de tamanho do serviço conforme cálculo pela fórmula

AFP = (UFPB + ADD + CHGA) - (CHGB + DEL) , onde:

UFPB – PF não ajustados (tamanho antes da alteração de escopo)

1 Entende-se por alteração de escopo recursiva a alteração de escopo que surge considerando funcionalidades já sendo alteradas por outra alteração de escopo ainda não finalizada.


Página 26 de 73

ADD – PF adicionados

CHGA – PF alterados (tamanho depois da alteração de escopo)

CHGB – PF alterados (tamanho antes da alteração de escopo)

DEL – PF excluídos

2) O valor medido, por uma nova contagem do serviço após a alteração de escopo.

Caso exista uma diferença entre esses valores, ela pode ser devida à existência de Scope Creep das funcionalidades da aplicação (aumentando ou diminuindo o seu tamanho medido).

Tais valores devem ser considerados para fins de tamanho final e remuneração, conforme exemplificado a seguir.

Novo tamanho ou linha base

após alteração escopo

Considerando somente a ocorrência de alteração de escopo, a atualização da linha de base de tamanho do serviço o é calculada por: • APF nova LB1 = (83 +40+29) – (36 + 0),

Onde: 36 PF corresponde ao tamanho das funções alteradas, antes da alteração de escopo. Ou seja: APF nova LB1 = 116 PFs

OBS: A aplicação cresceu em tamanho 33 PFs (116 – 83), embora o tamanho da alteração de escopo tenha sido de 47,96 PFs

Entrega alteração escopo


Remuneração da alteração de escopo A partir do tamanho 47,96 PF, calcular o valor monetário da remuneração. Emite TR e TA da alteração de escopo, de acordo com o contrato.

Recontagem da demanda

Considerando neste estudo de caso que o resultado da contagem final da aplicação forneceu o resultado de 120 PFs

Contagem da linha base ao

final do sistema 120 PF


Lançar no SISTEMA DE CONTRATAÇÃO o resultado da contagem final do sistema (120 PF) O sistema deve calcular a quantidade de PF devido ao final (que pode não corresponder a contagem total do sistema), usando a fórmula:

PF devido ao final = (tamanho inicial x 88%)

( (representa o que já foi feito no sistema, antes da alteração de escopo) +

((tamanho após alteração escopo) x 12%

( (representa o que foi feito no sistema após a alteração de escopo – fase de transição – considerando o novo tamanho após a alteração de escopo) +

(tamanho final – tamanho após alteração escopo) (*)

( (representa a correção do scope creep –ocorrido ao longo do desenvolvimento) (**) Ou seja: (83 x 0,88) + (116 x 012) + (120 – 116) = 73,04 + 13,92 + 4 = 90,96 PF

• (*) Tamanho final – tamanho após alteração escopo (para remunerar


Página 27 de 73

o scope creep)

• (**) O esforço gasto para estabelecer a alteração de escopo nos 88% realizados do sistema no momento da alteração de escopo, já foi remunerado pelos 47,96 PFs relativos ao tamanho da própria alteração de escopo.

Considerações: • Desta forma não haverá pagamento em duplicidade de funcionalidades. • O SISTEMA DE CONTRATAÇÃO diminui o valor em PF já pago (sem

considerar o valor pago para a alteração de escopo) do PF que deve ser pago ao final.

• Ao final do desenvolvimento o valor remunerado será de: 90,96 PF + 47,96 PF = 138,92 PFs, embora o tamanho final medido para a aplicação tenha sido de 120 PF.

Emitir TR e TA

3.3. Esquematicamente, a simulação da alteração de escopo no final da fase de

construção é apresentada, considerando 88% do ciclo de desenvolvimento/manutenção executado:

Figura 2 – Sintetização da gestão financeira de alteração de escopo.


Página 28 de 73

Capítulo 5. Atualização de Baseline de Serviço, de Baseline de Produção e Contagem de Aplicação

1. Conceitos 1.1. A CAIXA mantém, além da Contagem de Aplicação, dois tipos de Baseline de

Contagem, que se caracterizam como estratégia de atualização das contagens frente à existência de sistemas legados.

1.2. Contagem de Aplicação : Conceito conforme CPM 4.3.1.

1.3. Baseline de Produção/Aplicação : Associada à aplicação instalada, o objetivo da

baseline de produção é compor a visão do tamanho funcional do todo ao longo do tempo, a partir da incorporação controlada das funcionalidades medidas em soluções de desenvolvimento/manutenção.

1.3.1. Trata-se do agrupamento das funcionalidades medidas de uma aplicação, preservando-se o conceito de unicidade, considerando as várias demandas de intervenção no sistema. É mantida sob demanda da CAIXA para cada indicação de que o produto foi instalado/atualizado em ambiente de produção. Será iniciada com uma contagem de aplicação.

1.4. Baseline de Serviço : Associada aos serviços executados, retrata o tamanho funcional de um conjunto de funcionalidades que foram medidas e agrupadas por sistema segundo um determinado critério. Agrupa os serviços medidos, preservando-se o conceito de unicidade, considerando as várias demandas medidas que obedeçam ao critério estabelecido. É versionada a cada conjunto de inclusão/alteração de funcionalidade(s).

1.4.1. Diferencia-se da baseline de produção por refletir todas as funcionalidades medidas

nos serviços de medição realizados pela fábrica de métricas, independente da instalação do produto em ambiente de produção.

2. Contagem de Aplicação de Produtos no Mercado

2.1. O fornecedor da solução deve prover à CAIXA a contagem de aplicação do produto

(adquirido, licenciado, em cessão de direito de uso ou assemelhado), bem como os insumos que subsidiaram a medição, sempre que no contrato estiverem estabelecidos serviços remunerados em PF.

2.2. A partir da entrega da contagem e insumos, a CAIXA executará nova medição e fornecerá ao fornecedor seu resultado. Em caso de discordância, o fornecedor deverá solicitar a execução de processo de divergência (Capítulo 7 Processo de Divergência entre Contagens)

3. Repositório Oficial da CAIXA

3.1. O termo baseline também é usado na disciplina de Gerência de Configuração e se

caracteriza por agrupar um conjunto de artefatos em um determinado tempo para representar um evento/situação específico, incluindo código-fonte, quando aplicável.

3.2. Quando da execução do processo de medição deverá existir no repositório da CAIXA uma baseline para fins de contagem, denominada Baseline de Contagem ou de Medição, que não deve ser confundido com os conceitos do item anterior (Capítulo 5 Atualização de Baseline de Serviço, de Baseline de Produção e Contagem de Aplicação).


Página 29 de 73

Capítulo 6. Manutenção Adaptativa, Perfectiva e Cor retiva. 1. Esclarecimento sobre diferença entre Manutenção Adaptativa e

Perfectiva

1.1. De acordo com a TE027 Manutenções Adaptativas e Perfectivas referem-se a:

1.1.1. Manutenção Adaptativa : Adequação do sistema às mudanças de ambiente operacional, compreendendo hardware e software básico, mudanças de versão, linguagem e SGBD, que gerem impacto/alteração na(s) funcionalidade(s), sendo que na perspectiva funcional, visão do usuário, as funcionalidades não são incluídas, alteradas ou excluídas.

1.1.2. Manutenção Perfectiva : Corresponde às adequações do sistema à necessidade de melhorias, sem alteração de funcionalidades, sob o ponto de vista do usuário. A finalidade da manutenção perfectiva é promover a melhoria de desempenho, a manutenibilidade e usabilidade do sistema.

1.1.3. A diferença entre as duas manutenções é que na manutenção Adaptativa existe o conceito de abandono da infra-estrutura atual (hardware, software, sistema operacional, linguagem, SGBD) pela necessidade de adequação a outra, e na Perfectiva são implementadas melhorias no produto de software como funcionamento adicional em outro sistema operacional e não adaptações substituindo a tecnologia utilizada anteriormente.

2. Procedimento a ser adotada para medição de Manut enção

Adaptativa e Perfectiva

2.1. Após a classificação do serviço a ser contratado, conforme a TE 027, observado que a demanda se caracteriza como uma manutenção perfectiva ou adaptativa, para se derivar o tamanho funcional do serviço é necessário:

2.1.1. Identificar o quantitativo de programas impactados identificando as funcionalidades correspondentes.

2.1.2. Identificar o tamanho funcional correspondente a essas funcionalidades, considerando a visão do usuário.

2.1.3. Identificar a forma de contratação do serviço, segundo regras do contrato (fases, disciplinas, pacote de trabalho) e o percentual de contratação.

2.1.4. Aplicar o fator de ajuste do tipo de serviço contratado, de acordo com a previsão contratual.

2.2. Para exemplificar, assuma um sistema que possui tamanho funcional de 1.000 PF.

2.2.1. Quando da alteração da versão do banco de dados, caracterizando uma manutenção adaptativa, observou-se que 10 programas são impactados, necessitando de ajustes.

2.2.2. Esses 10 programas estão vinculados, conforme análise do Gerente de Projeto, a 20 funcionalidades do sistema.

2.2.3. Essas 20 funcionalidades correspondem a um tamanho funcional de 60 PF.

2.2.4. Portanto, aplicado o Fator de Ajuste do Serviço de 50%, temos a remunerar à Contratada: 60PF * 50% - Totalizando 30 PF.


Página 30 de 73

2.3. O exemplo ora citado não deve ser assumido como regra geral, pois cada contrato especifica as regras de remuneração (forma e percentuais de contratação), segundo modelo específico.

2.4. As funcionalidades impactadas são também denominadas “funcionalidade afetada”. Como em Manutenção Adaptativa ou Perfectiva as funcionalidades, na perspectiva funcional (visão do usuário), não são incluídas, alteradas ou excluídas, é assumido um dos termos para representar a alteração: afetada ou impactada.

2.5. Nos artefatos de contagem, para efeito de caracterização das funcionalidades impactadas no escopo da contagem, a funcionalidade será considerada ALTERADA, na perspectiva técnica, sendo o termo “ALTERADO” associado a todas as funcionalidades que compõem o escopo da medição.

3. Esclarecimento do processo a ser adotado para me dição de

Manutenção Corretiva.

3.1. Quando aplicável ao contrato, por existir regras contratuais que remuneram a Manutenção Corretiva em PF, seguem as mesmas diretrizes do item 0 do Capítulo 6 Manutenção Adaptativa, Perfectiva e Corretiva.


Página 31 de 73

Capítulo 7. Processo de Divergência entre Contagen s 1. Esclarecimentos sobre divergências entre Contage ns

1.1. A atividade de contagem é exercida por empregado CAIXA ou empresa especializada por ela designada, não sendo admitido acatar medições de Fábricas de Software ou Terceiros. Caso a medição seja realizada por empregado CAIXA é permitida a solicitação de validação do resultado das medições por empresa especializada.

1.2. O fato da atividade de contagem ser executada pela CAIXA não desobriga o contratada de contar suas demandas e fornecer orçamento segundo o modelo do contrato.

1.3. Após a recepção da contagem, não havendo concordância do fornecedor com o total de pontos de função apresentado (ou com outra unidade de medição), deve ser enviado à CAIXA o Formulário de Divergência, em modelo especificado em metodologia CAIXA, com as contestação e fundamentações que sustentam o pleito de revisão, mesmo que o fornecedor não se submeta aos demais padrões do ciclo de vida de desenvolvimento/manutenção.

1.4. Sempre que a unidade de medição for ou envolver pontos de função, a solicitação de divergência deve ser assinada por profissional certificado pelo IFPUG, que representará o fornecedor nas atividades necessárias aos estabelecimentos de consenso entre as partes.

1.5. As condições e os prazos de divergência são estabelecidos em contrato. Caso não constem regras específicas, devem ser observadas as diretrizes:

1.5.1. Existindo divergência entre as contagens da CAIXA e da CONTRATADA, esta deverá encaminhar pedido de revisão formal à CAIXA, no prazo máximo de 5 (cinco) dias úteis, a contar da divulgação do resultado pela CAIXA.

1.5.2. Não havendo manifestação da CONTRATADA no prazo estipulado, valerá a contagem realizada pela CAIXA.

1.5.3. A CAIXA somente acatará o pedido de revisão que apresentar relatório técnico e justificativas, segundo padrão definido pela CAIXA, e identificar o profissional do quadro da CONTRATADA, com certificação CFPS (Certified Function Point Specialist) válida, que participará do processo de divergência, quando a unidade de medição for ou envolver pontos de função.

1.5.4. Quando o objeto da divergência for a perspectiva não funcional na(s) subcategoria(s) SNAP homologada(s) pela CAIXA - para aqueles contratos que preveem tal forma de medição - o pedido de revisão deverá ser realizado por profissional com certificação CSP (Certified SNAP Practitioner) válida.

1.5.5. A revisão da contagem e elaboração da proposta de solução do impasse será realizada por profissional CFPS/CSP da CONTRATADA, em conjunto com o profissional indicado pela CAIXA, podendo este ser do seu quadro funcional e/ou de empresa CONTRATADA pela CAIXA para representá-la, devendo ambos serem detentores das mesmas certificações.

1.5.6. A apresentação da proposta deverá ocorrer no prazo de 5 (cinco) dias úteis, a contar da data estabelecida pela CAIXA para início das atividades.

1.5.7. Durante a existência de divergências, a CONTRATADA não está autorizada a rever as estimativas de prazo e custo da demanda, bem como os níveis de atendimento da OS.


Página 32 de 73

1.5.8. O resultado da divergência implicará em ajuste financeiro sempre que observado acréscimos ou decréscimo no tamanho do produto medido.

1.5.9. Nas contagens cuja divergência seja inferior ou igual a 5% (cinco por cento) do total da contagem, prevalecerá a menor delas.

1.5.10. As validações das medições realizadas, incluindo processos de auditoria internos ou externos, poderão resultar em divergência de contagem, sendo o resultado da contagem comunicado pela CAIXA à CONTRATADA, aplicando-se os mesmos procedimentos e prazos previstos para divergência de contagem.

1.5.11. As divergências de contagem em que se constatar a ausência de informações nos insumos fornecidos, informações essas necessárias à aplicação da técnica de APF ou outra em uso, sujeitará a CONTRATADA às sanções pelo descumprimento das obrigações de natureza técnica e/ou contratuais.

1.6. As validações das medições realizadas, executadas na perspectiva do Contrato de Métricas, seguem o mesmo processo de divergência, sendo a CAIXA dispensada da exigência de profissional certificado pelo IFPUG, por ser tratar de fiscalização de serviços contratados. Entretanto, caso a divergência afete serviços contratos de outros fornecedores, o processo deve ser executado em no mínimo dois estágios. O primeiro junto à empresa especializada em métricas. O segundo, após conclusão do primeiro, como o fornecedor de desenvolvimento/manutenção de software, sendo obrigatório à CAIXA apresentar profissional certificado pelo IFPUG do seu próprio quadro ou de empresa CONTRATADA pela CAIXA para representá-la durante o segundo estágio ou naqueles subsequentes que se fizerem necessários.


Página 33 de 73

Capítulo 8. SNAP – Software Non-functional Assessment Process 1. Fronteira da Aplicação e Escopo

1.1. As fronteiras das aplicações e o escopo da medição são definidos pela CAIXA. A

qualquer momento, segundo a visão de negócio, a CAIXA poderá ajustar as fronteiras das aplicações.

1.2. As fronteiras lógicas das aplicações precisam ser consistentes entre os processos da APF e o do SNAP.

2. Partição 2.1. De acordo com o Manual de Práticas de Avaliação APM/SNAP uma partição é um

conjunto de funções de software dentro da fronteira da aplicação que compartilham critérios e valores de avaliação homogêneos. Uma partição requer esforço de desenvolvimento, que pode não ser refletido ao medir o aspecto funcional do projeto/produto utilizando a APF.

2.2. A partição será estabelecida pela CAIXA. Uma fronteira pode conter mais de uma partição, entretanto, não podem ocorrer sobreposições entre elas. A qualquer momento a CAIXA poderá ajustar as partições.

3. Categoria e Subcategoria

3.1. O método SNAP/IFPUG instituiu 4 categorias e 14 subcategorias como norteadores

para avaliação do tamanho técnico do software. Cada subcategoria, considerando sua natureza, define as Unidades de Contagens SNAP (UCSs).

3.2. Das subcategorias preconizadas no APM, a CAIXA adotará somente as subcategorias listadas a seguir.

3.3. As manutenções ou projetos que não forem classificados nas subcategorias homologadas neste Guia não serão consideradas para cálculo de prazo e custo.

4. Subcategoria Interfaces do Usuário 4.1. Desenvolvimento e manutenção de elementos de interface gráfica do usuário,

deverão ser medidos conforme descrito na subcategoria 2.1 do APM/SNAP, considerando o conceito de Elemento de Interface do Usuário do método.

4.2. O objetivo da aplicação da subcategoria 2.1 é tratar impactos em elementos de interface do usuário que aprimoram a usabilidade, aparência, capacidade de aprendizagem, dentre outros, desde que estes não estejam vinculados a requisitos funcionais do usuário.

4.3. Estes cenários não poderão ser enquadrados em manutenções perfectivas e/ou adaptativas.

4.4. Exemplos: organização dos elementos em uma tela; telas criadas para criar, alterar, excluir ou consultar entidade Dado de Código; elementos de interface tais como botões, campos, plano de fundo, cores, dentre outros; títulos, rótulos ou mensagens na interface; e animações ou efeitos especiais de abertura ou encerramento da aplicação.


Página 34 de 73

4.5. Elementos de interface do usuário vinculados a requisitos funcionais em tempo de desenvolvimento ou manutenção destes, devem ser medidos apenas por APF.

4.6. Elementos de interface de ajuda devem ser tratados conforme descrito no item 5

deste capítulo. 4.7. Esta subcategoria é aplicada em cenários específicos da CAIXA, tais como os

sistemas SIAME, SIAMF, SIMOB, dentre outros sistemas de Mobilidade (aplicativos móveis), podendo ser ampliado a outros cenários de acordo com a necessidade da CAIXA.

4.8. Para esta subcategoria, o processo de medição não funcional SNAP/IFPUG terá

métodos de contagem DETALHADA e ESTIMADA da seguinte forma: 4.8.1. Método de contagem DETALHADA:

• Conforme descrito no APM 2.3.

4.8.2. Método de contagem ESTIMADA:

• Um dos parâmetros de complexidade desta subcategoria, é o número de Elementos IU distintos impactados no desenvolvimento ou manutenção da interface. Sendo assim, para que a medição estimada seja realizada, os Elementos IU precisam ser especificadas.

• Outro parâmetro de complexidade desta subcategoria, é a soma do número de propriedades distintas configuras para cada Elementos IU. De modo geral, essa informação não estará disponível nas fases iniciais dos projetos. Portanto, para contagens estimadas, o Tipo de IU terá complexidade baixa.

• Na tabela abaixo estão descritas as fórmulas de cálculo dos Pontos SNAP (PS) ESTIMADA:

Subcategoria Fórmula adotada para ESTIMADA

Interfaces do Usuário PS = 2* Qtde de Elementos de IU distintos

5. Subcategoria Métodos de Ajuda 5.1. Desenvolvimento e manutenção de elementos de ajuda na interface do usuário ou

páginas web estáticas, deverão ser medidos conforme descrito na subcategoria 2.2 do APM/SNAP.

5.2. Exemplos: páginas web estáticas, dicas de ferramenta, pop-ups, manual do usuário,

ajuda dinâmica ao posicionar o mouse (ajuda de contexto) janela de ajuda (como F1 no Word MS), dentre outros.

5.3. Esta subcategoria é aplicada em cenários específicos da CAIXA, tais como os



Página 35 de 73

5.4. Para esta subcategoria, o processo de medição não funcional SNAP/IFPUG terá apenas o método de contagem DETALHADA, uma vez que essa subcategoria depende da escolha do tipo de ajuda do elemento. O método de contagem detalhada será realizado conforme descrito no APM 2.3.

6. Subcategorias Múltiplos Métodos de Entrada e Múl tiplos Métodos de

Saída 6.1. Para estas subcategorias, o processo de identificação não funcional SNAP/IFPUG

terá os métodos de contagem DETALHADA e ESTIMADA da seguinte forma: 6.1.1. Método de contagem DETALHADA:

• Conforme descrito no APM 2.3


• As Unidades de Contagem SNAP (UCS) para “Múltiplos Métodos de Entrada” e “Múltiplos Métodos de Saída” é o Processo Elementar.

• Para estas subcategorias podem figurar UCS dos tipos de função de transação previstos pelo CPM 4.3.1 – Entrada Externa, Consulta Externa e Saída Externa.

• Na contagem ESTIMADA, a CAIXA adotará a complexidade Média, conforme previsto no APM SNAP, para as UCS envolvidas nas identificações nas subcategorias “Múltiplos Métodos de Entrada” e “Múltiplos Métodos de Saída”.



Múltiplos métodos de entrada PS = 4* Qtde de métodos de entrada

Múltiplos métodos de saída PS = 4* Qtde de métodos de saída

7. Subcategorias Múltiplas Plataformas 7.1. Serão considerados conforme descrito na subcategoria do APM/SNAP, a

subcategoria MÚLTIPLAS PLATAFORMAS somente deve ser utilizada se o mesmo conjunto de funcionalidades estiver sendo entregue em múltiplas plataformas.

7.2. A CAIXA preserva o conceito de processo elementar, conforme CPM/IFPUG, independente das plataformas que serão utilizadas para sua construção. Entretanto os aspectos técnicos de múltiplas plataformas somente serão considerados quando houver replicação desta mesma funcionalidade, em plataformas distintas.

7.3. No contexto do CONTRATO SISAG, as plataformas são: Estação Operacional (EO) e Estação Financeira (EF).

Plataformas de software: EO e EF: Java

Plataformas de Sistema Operacional: EF: Linux

EO: Windows

Interface Gráfica/Browser EF: Swing (Java) EO: Firefox


Página 36 de 73

7.4. As plataformas do Cartões de Débito ainda não estão previstas neste Guia. Estas

serão discutidas no GT de Métricas e incluídos em versões posteriores deste documento.

7.5. No contexto dos sistemas de Mobilidade, as plataformas são: IOS, Android e

Windows Phone.

7.6. Caso seja identificado que um grupo de funcionalidades, que estão disponíveis em apenas uma das plataformas e necessitem estar disponíveis em outra, ou ainda, em uma nova plataforma – elaborada de acordo com os objetivos da CAIXA, estas funcionalidades poderão ser avaliadas nesta subcategoria MÚLTIPLAS PLATAFORMAS. Estes cenários não poderão ser enquadrados em manutenções perfectivas e/ou adaptativas.

7.7. Para esta subcategoria, o processo de identificação não funcional SNAP/IFPUG terá

os métodos de contagem DETALHADA e ESTIMADA da seguinte forma:

7.7.1. Método de contagem DETALHADA:

• Conforme descrito no APM 2.3


• Para as contagens estimadas, considerando que a disponibilização de um grupo de funcionalidade em outra(s) plataforma(s) é de domínio e planejamento prévio. Ou seja, os parâmetros de determinação de complexidade para esta subcategoria (Natureza das plataformas e Número de plataformas para se operar) são possíveis de obtê-los para uma para estimativa preliminar utilizando a mesma forma de cálculo de Pontos SNAP para uma contagem detalhada.

• Desta forma, para essa subcategoria a CAIXA não apropriou qualquer conceito de contagem estimada SNAP. O que fará diferença entre uma contagem estimada e detalhada (de mesmo escopo) é o momento e detalhamento das necessidades da solução.

• Caso não seja possível a identificação da quantidade de plataformas a CAIXA adotará a contribuição mínima de pontos SNAP (10 PS) para o conjunto de processos elementares.

7.7.2.1. Exemplo : Foi solicitado pelo gestor a criação de duas novas plataforma denominadas Estação Móvel (EM) e Estação Corporativa (EC). O objetivo destas novas plataformas é disponibilizar todas as funcionalidades da plataforma EO. Nas novas plataformas serão utilizados os browsers Chrome e Dolphin. A melhoria acima será avaliada na subcategoria Múltiplas Plataformas.

• O PS seria a Soma dos PS para (Categoria 2 na tabela SNAP/APM para 2 plataformas + PS para Categoria 3). Ou seja: PS = 40 + 10 = 50

8. Subcategoria Tecnologia de Banco de Dados 8.1. Desenvolvimento e manutenção de recursos e operações inseridos na base de dados

sem afetar o requisito funcional do usuário, deverão ser medidos conforme descrito na subcategoria 3.2 do APM/SNAP.

8.2. Exemplos: Tabelas de dados de código; storage procedures para manutenção dos dados de código; índices em tabelas para melhoria de performance, dentre outros.


Página 37 de 73

8.3. Esta subcategoria é aplicada em cenários específicos da CAIXA, tais como os sistemas SIAME, SIAMF, SIMOB, dentre outros sistemas de Mobilidade (aplicativos móveis), podendo ser ampliado a outros cenários de acordo com a necessidade da CAIXA.

8.4. Para esta subcategoria, o processo de medição não funcional SNAP/IFPUG terá




• Um dos parâmetros de complexidade desta subcategoria, é a quantidade de alterações realizadas na base de dados. Sendo assim, para que a medição estimada seja realizada tais alterações devem ser possíveis de ser aproximadas.

• Outro parâmetro de complexidade desta subcategoria, é o tamanho do arquivo lógico impactado na manutenção do banco de dados. De modo geral, essa informação não estará disponível nas fases iniciais dos projetos. Portanto, para contagens estimadas, o Arquivo Lógico terá complexidade baixa.



Tecnologias de Banco de Dados PS = 6* Qtde de alterações realizadas

9. Subcategoria Software Baseado em Componentes 9.1. Desenvolvimento e manutenção de componentes utilizados dentro da fronteira da

aplicação, deverão ser medidos conforme descrito na subcategoria 4.1 do APM/SNAP.

9.2. Exemplos: componentes nativos do aplicativo móvel; Street View; Map; dentre outros.

9.3. Esta subcategoria é aplicada em cenários específicos da CAIXA, tais como os


9.4. Para esta subcategoria, o processo de medição não funcional SNAP/IFPUG terá apenas o método de contagem DETALHADA, uma vez que essa subcategoria depende da escolha do tipo de Componente (desenvolvido internamente ou adquirido). O método de contagem detalhada será realizado conforme descrito no APM 2.3.


Página 38 de 73

10. Subcategoria Movimentações de Dados Internos 10.1. Será considerado conforme descrito na subcategoria 1.4 do APM/SNAP,

considerando o conceito de Partição do método, havendo a necessidade de existir movimentação de dados entre partições, com manipulação específica de dados.

10.2. Requisitos de movimentação de dados interna de uma stage para outra, sem que

haja manipulação de dados específica, ou seja, exista apenas cópia dos dados, a subcategoria não poderá ser aplicada.

10.3. Exemplo: Movimentação dos dados mantidos (temporariamente) na DSA para o ODS

ou DM de um Data Warehouse. Estes dados são cópias dos sistemas de origem e não há requisitos de movimentação de dados interna.

10.4. Esta subcategoria é aplicada em cenários específicos da CAIXA, tais como sistema

de CRM (SIGRC) e sistemas que possuem características de um Data Warehouse. 10.5. Esta subcategoria é medida conforme orientações do Capítulo 13. 10.6. Para esta subcategoria, o processo de medição não funcional SNAP/IFPUG terá




• Um dos parâmetros de complexidade desta subcategoria é a quantidade de DER transferidos para dentro e para fora de uma partição. Geralmente, essa informação não estará disponível no início de um projeto, impossibilitando a aplicação dessa subcategoria para este fim.

• Esta subcategoria poderá ser aplicada para realização de estimativas em casos que a quantidade de DER transferidos for especificada.



Movimentação de Dados Internos PS = 6* Qtde de DER transferidos


Página 39 de 73

Capítulo 9. SISRA – URA 1. Contagem dos Servidores de Aplicação SISRA – URA 1.1. Os “servidores de aplicações” consistem de servidores lógicos armazenados em uma

única máquina, responsáveis por prover a disponibilização de recursos computacionais a serem consumidos pela URA. Esta, ao invocá-los, completa a execução de um processo de negócio disponibilizado ao cliente via interface de voz.

1.1.1. Para a medição dos componentes da aplicação (servidores) recomenda-se a execução

das seguintes atividades, tal como detalhado:

1.1.1.1. Os servidores lógicos criados para desempenhar uma função específica dentro do ambiente URA deve ser considerado como um componente da aplicação.

1.1.1.2. Quando a solicitação de inclusão de novo componente for demandada pela

CONTRATADA, caberá a ela a descrição do componente e os seus motivadores, que será avaliado para determinação se o servidor lógico criado atenderá a definição de componente.

1.1.1.3. Quando incluído novo componente, devem ser medidas todas as funcionalidades incluídas para o componente e todas as funções de transação impactadas no SISRA para referenciar o componente.

1.1.1.4. Caso exista a necessidade de alteração de um componente (funções de dados ou transação), não devem ser consideradas como impactadas as funcionalidades do SISRA em virtude da alteração realizada no componente que é utilizado por esta funcionalidade. Nesse cenário, deve ser medido apenas as funções impactadas (para o componente sendo medido).

1.1.1.5. Os conceitos para a identificação de funções de dados para a URA e seus componentes devem seguir as definições do CPM 4.3.1. Caso seja identificado que um grupo de funcionalidades - que estão disponíveis no SISRA – consumam dados disponibilizados por um componente, o grupo lógico de dados referenciados devem ser considerados como AIEs.

1.1.1.6. Os conceitos para a identificação de funções de transação para a URA e seus componentes devem seguir as definições do CPM 4.3.1. Caso seja identificado que a função de transação – sendo analisada no SISRA - reutilize funções disponibilizadas por um componente, deve-se considerar que as funcionalidades reutilizadas são lógicas de processamento.


Página 40 de 73

Capítulo 10. CONTRATO HOME BROKER 1. Diretrizes para o Contrato HOME BROKER 1.2. Manutenções 1.2.1. Apenas manutenções evolutivas e corretivas são prevista em contrato. Não cabe remuneração

por adequações de natureza perfectiva ou adaptativa.

1.2.2. As corretivas são responsabilidades da CONTRATADA, sem ônus para a CAIXA.

1.2.3. Manutenções evolutivas são remuneradas em pontos de função, exceto “aquelas adequações referentes às normas e leis quer regulamentam a negociação de títulos de valores mobiliários no Brasil, tendo em vista que este tipo de adequação já está contemplado no fornecimento de licença de uso da solução.” (Contrato 0758/2012, Anexo I – Termo de Referência, item 6.2.1).

1.2.4. Os serviços de implantação da solução está inclusa no escopo da contratação limitado a 40 horas, sendo as atividades adicionais não previstas medidas e remuneradas. (Contrato 0758/2012, Anexo I – Termo de Referência, item 2.2.4). Para tanto, é aplicado o percentual referente às atividades previstas.

1.2.5. No Processo de Divergência de Contagem devem ser observadas as condições e prazos especificados em contrato.


Página 41 de 73

Capítulo 11. Orientação de Contagem UST para Portai s de Conteúdo

1. Objetivo 1.1. Descrever as definições e exemplos de cada item de PERSPECTIVA NÃO FUNCIONAL UST

- (Unidade de Serviço Técnico) aplicada a portal de conteúdo. Estas orientações podem ser atualizadas de acordo com a necessidade da CAIXA.

1.2. A perspectiva funcional em UST é derivada da aplicação do método de contagem em PF do

IFPUG, observada a regra de conversão de PF para UST; que prevê o descarte de funcionalidades excluídas para fins de remuneração e de demais derivações de estimativas.

2. Contextualização 2.1. Estas orientações surgiram para esclarecer a aplicação do processo de medição de projetos

envolvendo Portais previstos contratualmente na Carteira de NOVAS TECNOLOGIAS. 2.2. Para apoiar o processo de medição da PERSPECTIVA NÃO FUNCIONAL foi definido um

novo artefato para auxiliar a medição, o Mapeamento de Fragmentos. Nele estão mapeados os fragmentos de acordo com cada template, tornando-se, portanto, um insumo necessário para a medição de UST. O artefato Mapeamento de Fragmentos de cada demanda deve ser validado e homologado pela coordenação responsável.

2.3. Por fim, cabe destacar que de acordo com o item 7.3.2.1 do contrato N° 1497/2013, quando

houver medição funcional para uma peça, esta não poderá ser medida pelo tamanho não funcional, ou seja, não poderá haver sobreposição da medição funcional pela não funcional, não cabendo qualquer remuneração adicional por esforços de caráter técnico/tecnológico.

3. Glossário 3.1. FRAGMENTO ESTÁTICO : Criação ou manutenção de fragmento que não apresenta

característica interativa e/ou dinâmica que reflete em alteração na exibição e/ou comportamento dos conteúdos do documento em que está inserido. O fragmento deve permanecer inalterado com ou sem interação com usuário.

3.2. FRAGMENTO DINÂMICO: Criação ou manutenção de fragmento que apresenta animação,

característica interativa e/ou dinâmica com mudanças na exibição e/ou comportamento solicitados pelo gestor.

3.2.1. Exemplos: Carrossel de imagens, mídias (players de vídeo/áudio), banner Interativo onde, quando o usuário passar o mouse sob banner, este aumenta de tamanho, muda imagem, altera forma de visualização, conteúdos em abas e etc.

3.3. TEMPLATE: Criação ou manutenção de desenvolvimento programático de páginas ou peças,

com finalidade de instanciamento e reuso em fluxo de customização e publicação pelo usuário final utilizando ferramenta de gerenciamento de conteúdo.

3.4. DIAGRAMAÇÃO: Criação do "esqueleto" de uma página compreendendo a definição de

linhas de grade - GRID e montagem/posicionamento de conteúdo (fragmentos) nas páginas conforme definições dos Artefatos WEB* ("Layout" e "Guia de Montagem").


Página 42 de 73

3.5. NAVEGAÇÃO: Criação de URL e implementação de um "NÓ" para navegação; Atualizações de referências e links para um nó de navegação conforme definições dos Artefatos WEB relativos à entrega.

3.6. MASTER PAGE: São páginas mestres que definem a estrutura padrão do site. Masters

pages serão consideradas como templates.

3.6.1. Exemplos: Definições de cabeçalho, rodapé, estrutura de grid e etc. 3.7. PAGE LAYOUT: São características específicas de layout disponíveis a serem aplicadas

individualmente nas páginas. Pages layout serão consideradas como templates. 3.8. RESPONSIVIDADE: Para a responsividade, considera-se a dimensão adaptada de acordo

com o dispositivo, sendo eles Desktop, Tablet, Mobile e etc. Por tanto, os fragmentos e os templates tem o seu desenvolvimento multiplicado de acordo com a responsividade de cada peça.

4. Definição 4.1. Para medir o tamanho do produto e/ou serviços de Portal de Conteúdo, é aplicado o conceito

de UST nas perspectivas funcionais e não funcionais. 4.2. Os itens que compõem o tamanho do produto/serviço e as regras de conversão estão

descritos no item 6 do Capítulo 11 Orientação de Contagem UST para Portais de Conteúdo. 4.3. PORTAIS DE CONTEÚDO UTILIZANDO TECNOLOGIA MS/C MS

Item Descrição Unidade de Medida

1 DESIGNER

Ajustes de banner (tamanho/cores/fonte), criação de banner, animação em Flash (até 30 frames- 3 segundos), tratamento de imagens e estruturar gráfico em layout de páginas (montagem de wireframe). Exemplos: Redimensionar Banner do Home da CAIXA, inserir banner na página de Classificados CAIXA. Para tratamento de Imagens, enquadram-se as seguintes atividades: Alteração de cores, fontes, ícones, tamanho ou qualquer outro item que componha o elemento. “Estruturar gráfico em layout de páginas” deve ser interpretado como a inserção de elementos gráficos desenho da página. Exemplo de alteração de elemento: Alteração do Slogan da Marca CAIXA De: O banco que acredita nas pessoas Para: A vida pede mais que um banco.

Elemento

2 DESIGNER

MINISITE - Definição do layout simples (adaptar a um modelo já existente). Entende-se como Minisite um site que contenha até quatro páginas (links) no mesmo domínio, sem contar a página principal, relacionadas ao mesmo assunto. Exemplo : Minha Casa Melhor, onde o internauta visualiza a página principal e quatro subpáginas referentes ao programa social. Para validação, será necessário avaliar o domínio de onde as páginas se encontram. Por exemplo, todos os links deverão iniciar com http://minhacasamelhor.com.br/nomedapágina Observação : Uma vez que um site é medido como “Minisite”, fica vedada a utilização do item 1 (Designer de Elementos Gráficos) da tabela de CMS.

Minisite


Página 43 de 73

Observação 2: Trata-se de uma adaptação de um template já existente ou reaproveitamento de algum outro site.

3 DESIGNER

MINISITE - Definição do layout complexo (criação ou uso de Tabelas / Div / Flash / Recortes e etc.). Observação: Segue a mesma definição do item 02, porém trata-se de criação do designer.

Minisite

4 CONSTRUÇÃO

E-CAIXA POSTAL, Inclusão de imagens, Criação de redirects específicos...Entende-se como E-CAIXA POSTAL a criação (inclusão de imagens, links e pequenos textos) de e-mail comercial. Por exemplo, o usuário que se cadastra no site de Loterias para receber diariamente os resultados das modalidades.

E-CAIXA

5 CONSTRUÇÃO

MINISITES - Cargas Licitação, Poupança, etc. Observação: Segue a mesma definição do item 02, porém trata-se da construção (codificação) do minisite. Minisite

6 CONSTRUÇÃO Criação de Template. Consiste na criação de um layout que será utilizado na ferramenta MS CMS. Template

7 CONSTRUÇÃO

Configuração do ambiente do publicador de conteúdo. Entende-se por “Configuração do ambiente do publicador de conteúdo” a realização da configuração de “stage” (agendamento da rotina de publicação de conteúdo) de acordo com os horários solicitados. Por exemplo: Criação de uma rotina onde a Home da CAIXA será atualizada automaticamente às 13h, 15h e 19h.

Ambiente

8 ADAPTAÇÕES

Manutenção para adequação aos Padrões W3C. O Consórcio World Wide Web (W3C) é um consórcio internacional no qual organizações filiadas, uma equipe em tempo integral e o público trabalham juntos para desenvolver padrões para a Web. Exemplo: Necessidade de adequação de páginas para um correto funcionamento nos principais navegadores.

Tela/Página

9 ADAPTAÇÕES

Manutenção para adequação à Acessibilidade. Necessidade de adequação do site para atender os requisitos dos padrões de acessibilidade. Exemplo: Aumentar/Diminuir fonte (A+/A-) Tela/Página

4.4. PORTAIS DE CONTEÚDO – DEMAIS TECNOLOGIAS

Item Descrição Complexidade/Exemplos Unidade de Medida

1

Conteúdo - Fragmentos de Página - ESTÁTICO

Criação ou manutenção de Fragmento que não apresenta característica interativa e/ou dinâmica que reflete em alteração na exibição e/ou comportamento dos conteúdos do documento em que está inserido. Compreende a utilização de Linguagem de Marcação (HTML, XML, XHTML, etc.), Linguagem de Script Client-

Bai

xo Linguagem de marcação (por

exemplo, HTML.). Exemplo: Logotipo da CAIXA, imagens estáticas.

Fragmento

2

Méd

io

Linguagem de Marcação (por exemplo HTML) + Linguagem de Script (por exemplo Javascript) ou Linguagem de Definição de Apresentação (por exemplo CSS) Exemplo: Caixas de Texto, menus estáticos que não sejam apenas imagem, rodapé.

Fragmento


Página 44 de 73

3

Side (Javascript, VbScript, etc.) e Linguagem de Definição de Apresentação (CSS, etc.).

Alto

Linguagem de Marcação (por exemplo, HTML) + Linguagem de Script (por exemplo, Javascript) + Linguagem de Definição de Apresentação (por exemplo, CSS) Exemplo: Tratamento de imagens via Script. Obs. Tendo em vista que não é possível validar visualmente o uso de scripts, será obrigatório informar sua utilização no Mapeamento de Fragmentos.

Fragmento

4

Conteúdo - Fragmentos de Página - DINÂMICO

Criação ou manutenção de Fragmento que apresenta animação, característica interativa e/ou dinâmica com mudanças na exibição e/ou comportamento do documento em que está inserido. Compreende a utilização de Linguagem de Marcação (HTML, XML, XHTML, etc.), Linguagem de Script Client-Side (Javascript, VbScript, etc.), Linguagem de Definição de Apresentação (CSS, etc.) e por fim compreende também a implementação de RIAs - Rich Internet Applications ou Rich Web Clients² (Flash, Silverlight, etc.).

Bai

xo

Linguagem de Marcação (por exemplo, HTML) + Linguagem de Script (por exemplo, Javascript) ou Linguagem de Definição de Apresentação (por exemplo, CSS). Compreende também a implementação de peças ou conteúdos animados construídos por Agências Publicitárias. Exemplo: Banner dinâmico, Menus sem aplicação de CSS.

Fragmento

5

Méd

io

Linguagem de Marcação (por exemplo HTML) + Linguagem de Script (por exemplo Javascript) + Linguagem de Definição de Apresentação (por exemplo CSS) Exemplo: Menus dinâmicos com a aplicação de CSS

Fragmento

6

Alto

Compreende o desenvolvimento de fragmentos com conteúdo animado e/ou interativo, utilizando RIAs ou Rich Web Clients. Exemplos: Carrossel de imagem, Mapas dinâmicos, APIs Google, mídias (players), Applets, galeria de fotos e etc.

Fragmento

7

Template

Criação ou manutenção de Desenvolvimento programático de páginas ou peças, com finalidade de instanciamento e reuso em fluxo de customização e publicação pelo usuário final utilizando ferramenta de gerenciamento de conteúdo.

Bai

xo Linguagem de Marcação (por

exemplo, HTML) + Linguagem de Script (por exemplo Javascript) ou Linguagem de Definição de Apresentação (por exemplo CSS). Exemplo: Cabeçalho(Header), rodapé(Footer) e o meio.Compreende a “fôrma para fragmentos” .

Template

8

Méd

io

Linguagem de Marcação (por exemplo, HTML) + Linguagem de Script (por exemplo, Javascript) + Linguagem de Definição de Apresentação (por exemplo, CSS)

Template


Página 45 de 73

Exemplo: Template responsivo (ajuste de tamanho do template de acordo com o dispositivo - Desktop/Tablet/Mobile), etc.

9

Alto

Compreende a criação de templates utilizando recursos de programação específicos (APIs) Exemplo: [Template ao fundo "Google Maps" sem o campo de busca]

Template

10 Diagramação

Criação do "esqueleto" de uma página compreendendo a definição de linhas de grade - GRID e montagem/posicionamento de conteúdo (fragmentos) nas páginas conforme definições dos Artefatos WEB* ("Layout" e "Guia de Montagem").

Exemplo: Montagem/Posicionamento dos Fragmentos em um template. Observação: Em manutenção de páginas, só deverá ser contada diagramação se houver reposicionamento dos fragmentos no template.

Páginas

11 Navegação

Criação de URL e implementação de um "Nó" para navegação; Atualizações de referências e links para um nó de navegação conforme definições dos Artefatos WEB relativos à entrega.

Exemplo: Criação de página em branco (sem templates e fragmentos) para possível alimentação de conteúdo por parte da área gestora.

Páginas

5. Insumos necessários para realização da medição 5.1. Projetos e Manutenções 5.1.1. Mapeamento de Fragmentos – perspectiva não funcional. 5.1.2. Análise de Impacto segregada entre as perspectivas funcionais e não funcionais; 5.1.3. Deverá ser informada no campo 21 do FSDMS a tabela do contrato a ser utilizada (MS/CMS

ou Outras Tecnologias).


Página 46 de 73

6. Tabela de Remuneração para PORTAL DE CONTEÚDO do Segmento/Carteira NOVAS TECNOLOGIAS

TABELA DE REMUNERAÇÃO PARA PORTAIS DE CONTEÚDO - MS /CMS PERSPECTIVA NÃO FUNCIONAL

ITEM DESCRIÇÃO

UNIDADE DE MEDIDA - para cada

-

QUANTIDADE DE UST POR

UNIDADE DE MEDIDA

TOTAL DE UST (UST)

FÓRMULA DE

REMUNERAÇÃO1,5

SUBMETIDO VALIDAÇÃO

e AUDITORIA

1 DESIGNER

Ajustes de banner (tamanho/cores/fonte), criação de banner, animação em Flash (até 30 frames- 3 segundos), tratamento de imagens e estruturar gráfico em layout de páginas (montagem de wireframe).

Elemento 0,35 ∑Elemento(s) * 0,35 UST * Vlr.da UST * FA SIM

2 DESIGNER MINISITE - Definição do layout simples (adaptar a um modelo já existente) Minisite 29,33 ∑Minisite(s) * 29,33 UST * Vlr.da UST *

FA SIM

3 DESIGNER MINISITE – Definição do layout complexo (criação ou uso de Tabelas / Div / Flash / Recortes, etc.) Minisite 57,79 ∑Minisite(s) * 57,79

UST * Vlr.da UST * FA SIM

4 CONSTRUÇÃO E-CAIXA POSTAL Inclusão de imagens Criação de redirects específicos

E-CAIXA 10,04 ∑E-CAIXA(s) * 10,04 UST * Vlr.da UST * FA

SIM

5 CONSTRUÇÃO MINISITES Cargas Licitação, Poupança, etc. Minisite 60,41 ∑Minisite(s) * 60,41 UST * Vlr.da UST *

FA SIM

6 CONSTRUÇÃO Criação de Template Template 64,95 ∑Template(s) * 64,95 UST * Vlr.da UST * FA SIM

7 CONSTRUÇÃO Configuração do ambiente do publicador de conteúdo Ambiente 11,79 ∑Ambiente(s) * 11,79 UST * Vlr.da UST * FA SIM

8 ADAPTAÇÕES Manutenção para adequação aos Padrões W3C Tela/Página 12,75 ∑Tela/Página(s) *

12,75 UST * Vlr.da UST *

FA SIM

9 ADAPTAÇÕES Manutenção para adequação à Acessibilidade Tela/Página 10,91 ∑Tela/Página(s) * 10,91

UST * Vlr.da UST * FA SIM


Página 47 de 73

TABELA DE REMUNERAÇÃO PARA PORTAIS DE CONTEÚDO - MS /CMS PERSPECTIVA FUNCIONAL 2 - IFPUG - APF

ITEM DESCRIÇÃO

SITUAÇÃO DA FUNCIONALIDADE NO CONTEXTO DA

SOLUÇÃO

UNIDADE DE MEDIDA - para cada -


UNIDADE DE MEDIDA

TOTAL DE UST (UST)

FÓRMULA DE REMUNERAÇÃO1,5


e AUDITORIA

10

FUNCIONALIDADE 3

Processo Elementar, segundo conceito do Manual de Práticas

de Contagem do IFPUG: Entrada Externa, Saída Externa,

Consulta Externa.

Incluídas PF 8,73 ∑PF * 8,73 UST * Vlr.da UST * FA SIM

11 Alteradas4 PF 4,37 ∑PF * 4,37 UST * Vlr.da UST * FA SIM

12 Excluídas PF 0 ∑PF * 0 NÃO REMUNERADAS, pois

os esforços de exclusão estão nos serviços do Grupo 2.

SIM

13 Funções de Dados, segundo conceito do Manual de Práticas de Contagem do IFPUG: ALI

Incluídas PF 8,73 ∑PF * 8,73 UST * Vlr.da UST * FA SIM

14 Alteradas4 PF 4,37 ∑PF * 4,37 UST * Vlr.da UST * FA SIM

15 Excluídas PF 0 ∑PF * 0 UST * Vlr.da UST * FA SIM

16 Funções de Dados, segundo conceito do Manual de Práticas de Contagem do IFPUG: AIE

Incluídas PF 0 ∑PF * 0 NÃO REMUNERADAS, pois os esforços de exclusão estão

nos serviços do Grupo 2.

SIM

17 Alteradas4 PF 0 ∑PF * 0 SIM

18 Excluídas PF 0 ∑PF * 0 SIM

19

Alteração de Escopo (Ver Fórmula Detalhada do

Termo de Referênia, item 12.5 Alteração de Escopo)

Incluídas PF (Ver Fórmula Detalhada do Termo de Referênia, item 12.5 Alteração de Escopo)

SIM

Alteradas PF SIM

Excluídas PF 0 ∑PF * 0 NÃO REMUNERADAS, pois os

esforços de exclusão nos serviços do Grupo 2.

SIM

1 Incidirá sobre a Fórmula de Remuneração ora apresentada a DISTRIBUIÇÃO DE ESFORÇO E PRAZOS DAS METODOLOGIAS DA CAIXA. 2 Funcionalidades medidas pela APF/IFPUG não podem ser adicionadas de UST referentes à PERSPECTIVA NÃO FUNCIONAL. 3 Quando não for possível estabelecer a complexidade das funcionalidades, elas devem ser consideradas com complexidade BAIXA. Não será aplicada a técnica da NESMA. 4 Para Manutenções Perfectivas e Adaptativas, as funcionalidades que compõem o escopo da manutenção devem ser medidas na Perspectiva Funcional e consideradas como alteradas (SITUAÇÃO DA FUNCIONALIDADE NO CONTEXTO DA SOLUÇÃO). 5 AF: Fator de Ajuste de Serviço, conforme do Termo de Referência - Anexo I, item 21 - FORMA DE PAGAMENTO DOS SERVIÇOS.


Página 48 de 73

TABELA DE REMUNERAÇÃO PARA PORTAIS DE CONTEÚDO - DE MAIS TECNOLOGIAS DE DESENVOLVIMENTO PERSPECTIVA NÃO FUNCIONAL

ITEM DESCRIÇÃO COMPLEXIDADE UNIDADE

DE MEDIDA - para cada -

QUANTIDADE DE UST POR UNIDADE DE

MEDIDA

TOTAL DE UST (UST)

FÓRMULA DE REMUNERAÇÃO SIMPLIFICADA 3, 7


e AUDITORIA

1 Conteúdo - Fragmentos de Página - ESTÁTICO

Peças integrantes de

um documento - DOM1. A definição

do escopo dos fragmentos é

descrita no Artefato "Wireframe".

Criação ou manutenção de Fragmento que não apresenta característica interativa e/ou dinâmica que reflete em alteração na exibição e/ou comportamento dos conteúdos do documento em que está inserido. Compreende a utilização de Linguagem de Marcação (HTML, XML, XHTML, etc.), Linguagem de Script Client-Side (Javascript, VbScript, etc.) e Linguagem de Definição de Apresentação (CSS, etc.).

Bai

xa

Compreende a utilização de linguagem de Marcação. Fragmento 4,45 ∑ Fragmento(s)

* 4,45 UST * Vlr. da

UST * FA SIM

2

Méd

ia Linguagem de Marcação +

Linguagem de Script ou Linguagem de Definição de Apresentação.

Fragmento 8,82 ∑ Fragmento(s) * 8,82

UST * Vlr. da UST * FA SIM

3 Alta

Linguagem de Marcação + Linguagem de Script + Linguagem de Definição de Apresentação.



4

Conteúdo - Fragmentos de Página -DINÂMICO

Peças integrantes de

um documento - DOM1. A definição

do escopo dos fragmentos é

descrita no Artefato "Wireframe".

Criação ou manutenção de Fragmento que apresenta animação, característica interativa e/ou dinâmica com mudanças na exibição e/ou comportamento do documento em que está inserido. Compreende a utilização de Linguagem de Marcação (HTML, XML, XHTML, etc.), Linguagem de Script Client-Side (Javascript, VbScript, etc.), Linguagem de Definição de Apresentação (CSS, etc.) e por fim compreende também a implementação de RIAs - Rich Internet Applications ou Rich Web Clients² (Flash, Silverlight, etc.).

Bai

xa

Linguagem de Marcação + Linguagem de Definição de Apresentação ou Linguagem de Script. Compreende também a implementação de peças ou conteúdos animados construídos por Agências Publicitárias.



5

Méd

ia

Linguagem de Marcação + Linguagem de Script + Linguagem de Definição de Apresentação. Compreende também a implementação de peças ou conteúdos animados construídos por Agências Publicitárias.



6 Alta

Compreende o desenvolvimento de fragmentos com conteúdo animado e/ou interativo, utilizando RIAs ou Rich Web Clients construídos pela Fábrica.




Página 49 de 73

TABELA DE REMUNERAÇÃO PARA PORTAIS DE CONTEÚDO - DE MAIS TECNOLOGIAS PERSPECTIVA NÃO FUNCIONAL

ITEM DESCRIÇÃO COMPLEXIDADE UNIDADE

DE MEDIDA - para cada -

QUANTIDADE DE UST POR UNIDADE DE

MEDIDA

TOTAL DE UST (UST)

FÓRMULA DE REMUNERAÇÃO

SIMPLIFICADA3,7


e AUDITORIA

7

Template

Criação ou manutenção de Desenvolvimento programático de páginas ou peças, com finalidade de instanciamento e reuso em fluxo de customização e publicação pelo usuário final utilizando ferramenta de gerenciamento de conteúdo

Bai

xa

Compreende a criação de templates utilizando Linguagem de Marcação + Linguagem de Definição de Apresentação ou Linguagem de Script.

Template 26,45 ∑ Template(s) * 26,45


8

Méd

ia

Compreende a criação de templates utilizando Linguagem de Marcação + Linguagem de Script + Linguagem de Definição de Apresentação.

Template 53,25 ∑ Template(s) * 53,25


9 Alta

Compreende a criação de templates utilizando recursos de programação (API) específicos.

Template 79,18 ∑ Template(s)

* 79,18 UST * Vlr. da UST

* FA SIM

10 Diagramação

Criação do "esqueleto" de uma página compreendendo a definição de linhas de grade - GRID e montagem/posicionamento de conteúdo (fragmentos) nas páginas conforme definições dos Artefatos WEB* ("Layout" e "Guia de Montagem").

Não se aplica. Página 8,82 ∑Página(s) 8,82


11 Navegação

Criação de URL e implementação de um "Nó" para navegação; Atualizações de referências e links para um nó de navegação conforme definições dos Artefatos WEB relativos à entrega.

Não se aplica. Página 4,45 ∑Página(s)

* 4,45 UST * Vlr. da UST

* FA SIM


Página 50 de 73

TABELA DE REMUNERAÇÃO PARA PORTAIS DE CONTEÚDO - DE MAIS TECNOLOGIAS PERSPECTIVA FUNCIONAL 4 - IFPUG - APF

ITEM DESCRIÇÃO

SITUAÇÃO DA FUNCIONALIDADE

NO CONTEXTO DA SOLUÇÃO

UNIDADE DE

MEDIDA


TOTAL DE PF (conversão

PF para UST)

TOTAL DE UST (UST)

FÓRMULA DE REMUNERAÇÃO

SIMPLIFICADA 3


e AUDITORIA

12

FUNCIONALIDADE 5

Processo Elementar, segundo conceito do Manual de Práticas

de Contagem do IFPUG: Entrada Externa, Saída Externa,

Consulta Externa.

Incluídas PF 8,73 ∑PF * 8,73 UST * Vlr.da UST * FA SIM 13 Alteradas6 PF 4,37 ∑PF * 4,37 UST * Vlr.da UST * FA SIM

14 Excluídas PF 0 ∑PF * 0 NÃO REMUNERADO Serviços Grupo 2. SIM

15 Funções de Dados, segundo conceito do Manual de Práticas de Contagem do IFPUG: ALI

Incluídas PF 8,73 ∑PF * 8,73 UST * Vlr.da UST * FA SIM 16 Alteradas6 PF 4,37 ∑PF * 4,37 UST * Vlr.da UST * FA SIM 17 Excluídas PF 0 ∑PF * 0 UST * Vlr.da UST * FA SIM 18 Funções de Dados, segundo

conceito do Manual de Práticas de Contagem do IFPUG: AIE

Incluídas PF 0 ∑PF * 0 NÃO REMUNERADO

Regra contratual.

SIM 19 Alteradas6 PF 0 ∑PF * 0 SIM 20 Excluídas PF 0 ∑PF * 0 SIM

21

Alteração de Escopo(Ver Fórmula Detalhada no Termo de Referência, item 12.5 Alteração

de Escopo)

Incluídas PF (Ver Fórmula Detalhada do Termo de Referênia, item 12.5 Alteração de Escopo) SIM

Alteradas PF

Excluídas PF 0 ∑PF * 0 NÃO REMUNERADO Serviços Grupo 2 SIM

1 Document Object Model - http://www.w3.org/DOM/ 2 Rich Web Client Activity Statement - http://www.w3.org/2006/rwc/Activity.html 3 Incidirá sobre a Fórmula de Remuneração ora apresentada a DISTRIBUIÇÃO DE ESFORÇO E PRAZOS DAS METODOLOGIAS DA CAIXA. 4 Funcionalidades medidas pela APF/IFPUG não podem ser adicionadas de UST referentes à PERSPECTIVA NÃO FUNCIONAL. 5 Quando não for possível estabelecer a complexidade das funcionalidades, elas devem ser consideradas BAIXA. Não será aplicada a técnica da NESMA. 6 Para Manutenções Perfectivas e Adaptativas, as funcionalidades que compõem o escopo da manutenção devem ser medidas na Perspectiva Funcional e consideradas como alteradas (SITUAÇÃO DA FUNCIONALIDADE NO CONTEXTO DA SOLUÇÃO). 7 AF: Fator de Ajuste de Serviço, conforme do Termo de Referência - Anexo I, item 21 - FORMA DE PAGAMENTO DOS SERVIÇOS.


Página 51 de 73

Capítulo 12. Diretrizes de Contagem do SIDEC

1. Introdução 1.1. O sistema SIDEC, em seu processamento diário, é capaz de receber aproximadamente

7.300 tipos de registros diferentes, identificados no que se convencionou chamar de Tabela TD/CL. Estes registros comandam o registro de movimentações ocorridas na conta corrente de um cliente CAIXA, a atualização do cadastro de clientes, além de outras informações necessárias a gestão das contas correntes.

1.2. A diversidade das informações recebidas e também a sua semelhança em muitos tipos de registro, tem dificultado a determinação dos processos elementares do SIDEC, dentro da visão de processos elementares preconizada pela Análise de Pontos de Função.

1.3. Esta diretriz registra as premissas que devem ser observadas pelo analista de métricas ao realizar medições estimadas ou detalhadas do sistema SIDEC, em relação aos seus processos elementares.

2. Critérios de agrupamento e/ou segregação 2.1. Os critérios de agrupamento e/ou segregação estão vinculados à tabela de TD/CL

disponível à época. Esta tabela, em anexo, apresenta os tipos de registro recebidos pelo SIDEC, sua classificação em funções e subfunções, a denominação da movimentação da conta corrente, o histórico da movimentação e os tipos de contas onde estas movimentações podem ser aceitas.

2.2. Com o conhecimento sobre o sistema e as regras da Análise de Pontos por Função, foram

estabelecidos os critérios abaixo, que estão relacionados em ordem de prioridade em sua aplicação.

Critério Fundamentação Regra da Análise

de Pontos de Função

Orientação

1 – Registros cujo código TD seja igual a 00-0 devem ser correlacionados as funcionalidades precedentes ao processo automático.

Os registros cujo código TD é igual a 00-0 são registros gerados em outros processamentos batch do próprio sistema SIDEC. Estes registros têm a finalidade de registrar, por exemplo, a efetivação de movimentações futuras de crédito ou débito, a cobrança de tarifas sobre contas correntes etc.

Uma EE é um processo elementar que processa dados ou informações de controle que vêm de fora da fronteira da aplicação. Uma CE/SE é um processo elementar que envia dados ou informações de controle para fora da fronteira da aplicação.

É necessário que esses códigos 00-0 sejam correlacionados a funcionalidades identificadas na contagem para que façam parte do tamanho da aplicação SIDEC, ou seja, estes TD 00-0 sempre serão precedidas de outra funcionalidade que recebem os dados de fora por um arquivo de Movimento. Para a contagem ter precisão é necessário o Processo Elementar que originou o TD=0.00. Normalmente existe uma funcionalidade de Cadastramento anterior e a automática é uma parte que deve ser agrupada em um único requisito. A numeração do SCF será um bom indicador para


Página 52 de 73

encontrar a funcionalidade de Cadastramento anterior que terão o mesmo número.

2 – Registros com código CF (Código de função) que tenham o mesmo significado devem ser agrupados como realizando o mesmo processo elementar.

Na tabela TD/CL o código da função estabelece uma função específica solicitada pelo Gestor ou Gestores do sistema. Como exemplo, citamos o código 582, que apresenta 4 linhas na tabela TD/CL com código de subfunção 000. Os movimentos recebidos com este código devem ser entendidos como executando um único processo elementar, conforme a descrição de sua denominação.

Um processo elementar é a menor unidade de atividade que é significativa para o usuário.

Para os processos identificados como um único processo elementar e que possuam a sua lógica de processamento diferente, é necessário que a Fábrica de Software descreva quais são as diferenças de processamento destas funcionalidades. Recomendamos que utilize as regras estabelecidas no CPM 4.3.1 de lógica de processamento.

3 – Funções que utilizem layouts de entrada de dados diferentes deverão ser consideradas como processos elementares distintos.

Dentro das funções estabelecidas pelo usuário, existem particularidades no recebimento e tratamento de suas informações. Estas particularidades estão registradas nos layouts de entrada de dados dos movimentos recebidos. Cerca de 300 layouts distintos foram identificados e relacionados aos movimentos de entrada de dados recebidos pelo SIDEC.

Quando comparado a um processo elementar já identificado, conte dois processos elementares como o mesmo processo elementar se eles: - requerem o mesmo conjunto de DERs e; - requerem o mesmo conjunto de ALRs e; - requerem o mesmo conjunto de lógicas de processamento para completar o processo elementar.

Recomendamos que no futuro os documentos de requisitos do SIDEC, estejam coerentes com os requisitos do sistema, auxiliando a diferenciar os processos elementares.

4 – Funções que tenham a mesma denominação e histórico devem ser agrupadas como realizando o mesmo processo elementar.

Existem funções que pela quantidade de subfunções envolvidas abrangem mais de um código de função ou que por motivos desconhecidos ficaram registradas em códigos diferentes. Nestes casos, deve-se examinar se a denominação e o histórico da movimentação são idênticos e agrupá-las em um único processo elementar. Exemplo: os códigos de função 343 e 345, com denominação Acerto Débito de IOF e histórico DEB.IOF


Caso a CAIXA receba a identificação destas funcionalidades como distintas, estas deverão ser incluídas na contagem.

5 – Funções que tenham operações distintas.

Existem funções que tratam operações distintas para o mesmo TD.

Um processo elementar é a menor unidade de atividade que é significativa para o

As operações distintas não serão consideradas suficientes para considerar a quebra de


Página 53 de 73

usuário. processo elementar. Havendo diferença nas regras de negócio para as operações, a fábrica de Software deverá descrever estas diferenças..

6 – Função que contém o objetivo de executar Lançamentos de MARCAÇÕES deverá ser considerada desde que tenham entradas de dados, por exemplo, informações de marcação registradas no movimento diário e que não seja TD 00. O lançamento de desmarcação deverá ser desconsiderado, pois aplicando as regras de pontos de função possui a mesma intenção do processo de marcação, ou seja, atualizar o status de um determinado indicador de conta. Para considerar os processos de marcação será necessário aplicar o critério 2.

Esta funcionalidade, de execução diária, Mensal, tem como objetivo a marcação de contas de vários lançamentos, exemplo marcar contas encerradas.


Caso a CAIXA receba a identificação destas funcionalidades de marcação e desmarcação como distintas, estas deverão ser incluídas na contagem.


Página 54 de 73

Capítulo 13. Diretriz de contagem para sistemas DW/ BI 1. Conceitos Gerais para DW/BI

1.1. Business Intelligence (BI)

1.1.1. É um processo orientado a tecnologia para análise de dados e apresentação de informações disponibilizadas que apoia executivos, gerentes de negócios e outros usuários finais em tomadas decisões de negócios. BI inclui uma variedade de ferramentas, aplicações e metodologias que possibilitam organizações coletar dados de sistemas internos e fontes externas, preparar para análises, desenvolver e executar consultas nos dados, criar relatórios, dashboards e visualizações de dados para gerar resultados analíticos tanto para tomadores de decisões corporativas, quanto para trabalhadores operacionais.

1.2. Data Warehouse (DW)

1.2.1. É um Banco de dados organizado para dar suporte à tomada de decisões estratégicas das organizações. É utilizado para armazenar informações relativas às atividades de uma organização de forma consolidada. Possibilita a análise de grandes volumes de dados que são coletados a partir de sistemas transacionais.

1.3. Data Marts (DM)

1.3.1. Os Data Marts (vide item 7, Figura 1 – Visão Geral) armazenam os dados em seu estágio final de transformação. Pode-se encontrar nesta fronteira as tabelas dimensões, fatos, agregadas e tabelas históricas. Enquanto o Data Warehouse usa dados de toda a corporação, os Data Marts possuem o mesmo objetivo, mas em geral tratam apenas de um assunto ou processo de negócio. No contexto da CAIXA geralmente os dados são carregados diretamente dos Sistemas Origem para os Data Marts.

1.4. Extração, Transformação e Carga (ETL)

1.4.1. É o processo de extração de dados de um ou mais sistemas de origem, seguido de transformações, para atender às necessidades de negócios, e cargas destes na base de dados do Data Warehouse.

1.5. Metadados

1.5.1. Os metadados (vide item 11, Figura 1 – Visão Geral) são geralmente definidos como dados sobre dados. O metadado é uma informação estruturada que descreve, explica, localiza ou ainda facilita a descoberta, utilização ou gestão de um dado e contém tanto definições técnicas (Informações necessárias para as diversas ferramentas que precisem armazenar, manipular e movimentar dados), quanto negociais (informações necessárias aos usuários de negócio para entender o contexto de negócio e o significado dos dados). Os metadados são marcos ou pontos de referência que permitem circunscrever a informação sob todas as formas.

1.5.2. No cenário CAIXA, os metadados não serão medidos como funções de dados, nem como funções de transação, uma vez que atualmente estes são resolvidos pelas ferramentas OLAP e não representam requisitos funcionais do usuário.

1.6. Tabelas Fato

1.6.1. Representam o alicerce do Data Warehouse. Elas contêm as métricas fundamentais da organização, e são o alvo final da maioria das consultas do DW. A tabela fato trabalha com tabelas dimensão.


Página 55 de 73

1.7. Tabelas Dimensão

1.7.1. Cada tabela dimensão representa uma coleção de dados descritivos correlacionados. Em outras palavras, detalha as informações contidas numa tabela Fato. Uma tabela dimensão pode ter relacionamento com mais de uma Fato.

1.8. Tabelas Dimensão Hierárquica

1.8.1. Representam um conjunto de dados que descrevem a Dimensão a qual está ligada. Se trata de uma tabela Dimensão que não se relaciona diretamente com uma tabela Fato.

1.9. Tabelas Dimensão Estáticas

1.9.1. Tabelas que armazenam dados estáticos: code tables.

1.10. Área de Consolidação de Dados Operacionais (ODS - Operational Data Store)

1.10.1. É uma estrutura de dados utilizada para armazenar dados operacionais da aplicação oriundos dos sistemas de origem e é responsável pela consolidação destes.

1.10.2. O ODS pode ser usado para consolidar informações operacionais de diversas fontes para que análises e relatórios possam ser realizados ao mesmo tempo em que operações de negócios estão ocorrendo, podendo servir como origem para soluções de suporte às tomadas de decisões. Este é o lugar onde a maioria dos dados está alojado antes de serem transferidos ao armazém de dados principal, o qual armazenará dados a longo prazo ou os arquivará.

1.11. Data Staging Area (DSA)

1.11.1. Essa estrutura é usada para armazenar uma versão atual dos dados que existem no sistema de origem. É uma área de armazenamento e um conjunto de processos que higienizam, transformam, combinam, armazenam e preparam dados de origem para serem usados no Data Warehouse. A DSA pode ser construída em estruturas de banco de dados ou em sistema de arquivos e geralmente são de natureza temporária. É criada geralmente por motivos de performance e segurança, e raramente é vista ou especificada por um usuário de negócio.

1.12. Tabelas Agregadas

1.12.1. Costumam ser sínteses construídas principalmente para melhorar o desempenho das tabelas fato. As agregações são armazenadas em tabelas separadas, e não nas tabelas fato, onde os dados são desagregados.

1.13. Tabelas Ponte

1.13.1. Às vezes é necessário modelar uma estrutura muitos-para-muitos entre as tabelas dimensão e tabelas fatos. Por exemplo, um funcionário de uma empresa pode pertencer a vários departamentos, e o mesmo departamento pode ser ocupado por vários funcionários. Diante deste tipo de situação, será preciso modelar uma estrutura muitos-para-muitos entre as tabelas dimensão e tabelas fato. Essa estrutura é chamada de tabela Ponte (Bridge Table) e se assemelha ao conceito de tabela associativa do CPM v.4.3.1.

1.14. Processamento Analítico On-line (On-Line Analytical Processing – OLAP)

1.14.1. O Processamento Analítico On-line (OLAP) é um conceito de interface com o usuário que proporciona a capacidade de conhecer os dados, permitindo a visualização das informações a partir de diversas perspectivas.


Página 56 de 73

1.15. Camada Semântica (ou contexto) / Universo/ Cubos

1.15.1. Representação negocial dos dados do DW ou de um banco de dados transacional. Permite ao usuário interagir com os seus dados sem a necessidade de se conhecer detalhes sobre o banco de dados ou onde os dados estão armazenados.

1.16. Métricas/Medidas

1.16.1. Correspondem a resultados de fórmulas criadas a partir de um requisito de usuário, são valores numéricos segmentados, divididos, agregados e analisados. Esses valores geralmente são mapeados para colunas numéricas em uma tabela fato do Data Warehouse, mas também podem ser criados em atributos de dimensão. Essas métricas são os valores mais importantes de um cubo OLAP (Camada Semântica), sendo o principal interesse dos usuários finais que consomem as informações disponibilizadas pela Camada Semântica.

1.17. Partição (SNAP)

1.17.1. Uma partição é um conjunto de funções de software dentro da fronteira da aplicação que compartilham critérios e valores de avaliação homogêneos. Uma partição requer esforço de desenvolvimento, que pode não ser refletido ao medir o aspecto funcional do projeto/produto utilizando a APF.

1.17.2. O posicionamento da partição pode ser subjetivo. É comum haver dificuldade em estabelecer onde uma partição termina e a outra começa. Deve-se posicionar a partição a partir de uma perspectiva não-funcional dos usuários, tais como manutenibilidade, portabilidade ou instalabilidade, ao invés de se basear em considerações técnicas ou físicas.

1.17.3. Assim como a fronteira da aplicação, a partição é definida pela CAIXA. É importante que a partição seja posicionada cuidadosamente, pois todos os dados que a cruzam impactam no tamanho SNAP.

1.17.4. Nesse guia, esse conceito é utilizado principalmente na análise da estrutura ODS de um DW, podendo ser identificada como uma partição e consequentemente, haverá impacto na medição SNAP da aplicação. Dessa forma, é importante que os especialistas das aplicações DW/BI da CAIXA façam essa análise e delimite as partições no início do projeto, pois o resultado dessa análise irá impactar diretamente na medição não funcional da aplicação.

2. Visão Geral de Contagem

2.1. Na medição de projetos de DW/BI, além da identificação dos requisitos funcionais, é necessário identificar as características não funcionais consideradas como um esforço adicional não cobertos pela medição funcional. Este guia descreve alguns desses requisitos e orienta quanto à medição funcional e não funcional. Os cenários descritos nos itens 3, 4 e 5 são exemplos não exaustivos.

2.2. Este guia tem como objetivo orientar a medição tanto de projetos de desenvolvimento, quanto de Projetos de Melhoria, de acordo com as regras do CPM v.4.3.1 e APM v.2.2. Além disso, o guia de uso utilizou como referência os papers do IFPUG (2007) e NESMA (2014), que propõem uma metodologia de contagem específica para o contexto de projetos DW/BI.

2.3. A figura a seguir demonstra a visão geral da arquitetura do DW para aplicação dos métodos de medição:


Página 57 de 73

Figura 3 - Visão Geral

Fonte: Ti Métricas/2016

2.4. Na figura acima, as estruturas por meio das quais há tráfego de dados foram identificadas como possíveis partições (conceito do método SNAP).

2.5. Fronteira da aplicação

2.5.1. A fronteira de cada sistema é definida de acordo com a visão da CAIXA, normalmente por sigla (sistema), considerando principalmente a perspectiva negocial.

2.6. Sistemas Origem

2.6.1. Representam as aplicações que mantêm os dados fontes que originam as informações que serão processadas pelo Data Warehouse ou Data Mart. Os sistemas de origem estão representados pelo item 1 da Figura 1 - Visão Geral.

2.7. Sistemas DW/DM

2.7.1. Compreende toda a estrutura de dados existente para o funcionamento do negócio, como: Data Staging Area (DSA), Operational Data Store (ODS) / Enterprise Data Warehouse (eDW), Data Warehouse ou Data Marts e On-Line Analytical Processsing (OLAP).

3. FUNÇÕES DE TRANSAÇÃO

3.1. Este item apresenta os cenários identificados na contagem de funções de transação. São considerados como funções de transação todos os processos de extração de dados dos sistemas de origem para manutenção do Data Mart, bem como todos os processos construídos para apresentação dos dados do mesmo.

3.2. A tabela a seguir descreve os cenários que serão apresentados nesta sessão.

Tabela 1 - Cenários das Função de Transação Cenário

Descrição

Cenário 1 Processo de ETL - Extração, Transformação e Carga

Cenário 2 Processo de ETL – Tabelas Fato e tabelas Dimensão

Cenário 3 Processo de ETL – Tabelas Dimensão Estática (Dado de Código)

Cenário 4 Processo de ETL – Tabelas de Agregação


Página 58 de 73

Cenário 5 Processo de ETL – Tabelas Ponte

Cenário 6 Relatórios, Painéis e Dashboards pré-definidos

Cenári o 7 Geração de interfaces para outros sistemas/usuários

Cenário 8 Modelagem de Camadas Semânticas ou Universos

Cenário 9 Funções Administrativas


3.3. Cenário 1: Processo de ETL - Extração, Transfo rmação e Carga

3.3.1. É o processo de extração de dados de um ou mais sistemas de origem, seguido de transformações, para atender às necessidades de negócios, e cargas destes na base de dados do Data Warehouse (DW). O processo de ETL está representado pelos itens 2, 4 e 6 da Figura 1 - Visão Geral.

3.3.2. Neste cenário, serão descritas três perspectivas importantes no processo de ETL que devem ser considerados na medição: Extração dos dados de origem, ETL para manutenção do Data Mart e ETL para manutenção do Data Mart com ODS.

3.3.3. Extração dos dados de origem:

3.3.3.1. Segundo NESMA (2014), a extração dos dados nos sistemas de origem durante o processo de ETL ocorre de duas maneiras:

1. Geração de flat files2 pelos sistemas de origem (vide Item 2, Figura 2 - Geração de flat file pelo sistema de origem)

2. Uma interface direta entre o sistema de origem e o DSA (vide Item 2, Figura 3 - Dados disponibilizados para carga no DW)

3.3.3.2. No primeiro caso, existe um requisito na fronteira do sistema de origem de geração de flat files, para posteriormente, ser carregado pelo processo de ETL na base do DW. Normalmente, este requisito está fora do escopo da aplicação sendo medida e deve ser medida com CE ou SE no escopo do sistema de origem responsável pela geração desses arquivos, conforme as regras do CPM v.4.3.1.

3.3.3.3. No caso da existência de uma interface direta entre as duas bases, não ocorre transferência dos dados do sistema de origem para o DW, porém, os dados ficam disponíveis para que o DW os utilize. Dessa forma, os dados disponibilizados pelo sistema de origem serão medidos como DERs para a Entrada Externa do processo de ETL de carga no DW.

3.3.3.4. Adicionalmente, poderá existir uma cópia de dados dos sistemas de origem, sem nenhuma lógica de processamento vinculada na geração dos dados. Nesse caso, a cópia de dados reflete um requisito não funcional e os dados copiados do sistema de origem, utilizados pelo processo de ETL, serão medidos apenas como DERs para a Entrada Externa de carga no DW.

3.3.3.5. A figura a seguir demonstra o exemplo de um requisito de geração de flat file pelo sistema de origem (vide item 2):

2 Flat files: Arquivos com estrutura de campos horizontal, nos quais cada registro corresponde a uma linha de dados onde os campos estão organizados posicionalmente ou por algum tipo de separador (vírgula, espaço em branco etc).


Página 59 de 73

Figura 4 - Geração de flat file pelo sistema de origem


3.3.3.6. A figura a seguir demonstra o exemplo de dados disponibilizados para carga no DW (vide item 2):

Figura 5 - Dados disponibilizados para carga no DW

Fonte: Ti Métrica/2016

3.3.4. ETL para manutenção do Data Mart:

3.3.4.1. O processo de ETL para manutenção do Data Mart pode ser realizado de forma completa ou de forma incremental. Na carga completa, todos os dados da origem são extraídos e transformados, recarregando os dados antigos e adicionando os novos. Deve-se contar uma Entrada Externa para cada requisito de carga completa do usuário que mantenha um ALI no DM (Exemplo: Tabelas Fato e/ou tabelas Dimensão).

3.3.4.2. A carga incremental considera apenas os novos registros no ETL, inserindo-os ao DM. Deve-se contar uma Entrada Externa para cada requisito de carga incremental do usuário que mantenha um ALI no DM.

3.3.4.3. Em todos os dois casos, o processo elementar é identificado conforme o requisito funcional de manutenção do DM, considerando que a menor unidade de atividade significativa para o usuário é a ETL, tendo seu início com a extração dos dados de origem, sofrendo transformações durante o processamento e por fim sendo finalizada com a carga dos dados nas tabelas do DM.

3.3.4.4. Nota: Normalmente há apenas um requisito de carga em tabelas Fato e tabelas Dimensão e nesse caso, deve-se contar apenas uma EE para cada tabela mantida no DM. Entretanto, se houver a necessidade negocial de existir os dois requisitos (carga completa e carga incremental) poderá ser contada uma EE para cada tipo de carga.


Página 60 de 73

3.3.4.5. A figura a seguir demonstra o exemplo de um requisito de ETL que mantém o DM (vide itens 2, 4 e 6):

Figura 6 - Processo ETL de manutenção do DM


3.3.5. ETL para manutenção do Data Mart com ODS:

3.3.5.1. Há casos em que o ODS não é uma simples cópia dos dados dos sistemas de origem, tendo relevância para o negócio da aplicação. Nesses casos, as informações oriundas das origens carregadas pela ETL precisam ser armazenadas no ODS a fim serem consolidadas antes de serem transferidas para o DW/DM. Assim, haverá um requisito para movimentação destas informações do ODS para o DW/DM. Esse requisito de movimentação interna de dados poderá ser medido conforme o item 5.3 deste documento.

3.3.5.2. Dessa forma, o processo de ETL (sendo iniciado na extração dos dados de origem e finalizado com a manutenção do DW/DM, representado pelos itens 2, 4 e 6 da figura 4) será medido como uma função de transação pela APF e adicionalmente, os requisitos de movimentação interna dos dados mantidos no ODS para o DW/DM serão medidos com o método SNAP (subcategoria 1.4), uma vez que não há dados atravessando a fronteira da aplicação.

3.3.5.3. Nota: Para que haja requisitos de movimentação interna do ODS para o DW/DM, é necessário que o ODS seja reconhecido como uma partição pela CAIXA.

3.4. Cenário 2: Processo de ETL – Tabelas Fato e ta belas Dimensão

3.4.1. Um processo de ETL que mantenha uma tabela fato ou uma tabela dimensão, se reconhecido como um requisito funcional, deverá ser medido como uma Entrada Externa. Além disso, caso existam processos de ETL para manter os níveis hierárquicos de uma tabela dimensão, também deverão ser medidos como Entradas Externas para a aplicação.

3.4.2. A figura a seguir demonstra o exemplo de requisitos de ETL que mantenham uma tabela dimensão e seus níveis hierárquicos (vide itens 2, 4, 6 e 7):


Página 61 de 73

Figura 7 - Processo de ETL – Tabelas Dimensão


3.5. Cenário 3: Processo de ETL – Tabelas Dimensão Estática (Dado de Código)

3.5.1. As tabelas dimensão estática são consideradas de acordo com o conceito de dado de código do CPM v.4.3.1 e consequentemente, não contribuem para o tamanho funcional. Dessa forma, os processos de ETL de manutenção de tabelas dimensão estática serão desconsiderados da contagem.

3.6. Cenário 4: Processo de ETL – Tabelas de Agrega ção

3.6.1. Raramente uma tabela agregada pode ser construída por razões de negócio, porém se for o caso, o processo de ETL que à mantém será medido como Entrada Externa.

3.6.2. Para os casos de tabelas agregada por motivos não funcionais (Exemplo: desempenho), a medição será realizada de acordo com o item 5, Medições SNAP, Cenário 5: Criação/ Alteração de Tabelas Agregadas por motivos Técnicos.

3.7. Cenário 5: Processo de ETL – Tabelas Ponte

3.7.1. O processo de ETL que mantém uma tabela ponte identificada com ALI ou RLR na aplicação (Cenário 9: Tabelas Ponte, do item 4 deste documento), deve ser medido com Entrada Externa para o sistema.

3.8. Cenário 6: Relatórios, Painéis e Dashboards pr é-definidos

3.8.1. Quando houver requisitos funcionais do usuário de consulta aos dados mantidos dentro do DW, através de consultas, relatórios, painéis e/ou dashboards pré-definidos (vide item 8, Figura 7 – Relatórios, Painéis e Dashboards pré-definidos), será medido uma Consulta Externa ou Saída Externa para cada requisito funcional identificado, conforme as regras de identificação de funções de transação do CPM v.4.3.1.

Nota: Um painel ou um dashboard é uma exibição das informações necessárias para atingir um ou mais objetivos, consolidadas e organizadas em uma única tela de forma que as informações possam ser monitoradas. Devem ser medidos como função de transação apenas os relatórios.

3.8.2. A figura a seguir demonstra o exemplo destes requisitos que recuperam dados do DW:


Página 62 de 73

Figura 8 – Relatórios, Painéis e Dashboards pré-definidos


3.9. Cenário 7: Geração de interfaces para outros s istemas/usuários

3.9.1. Em alguns casos, há a necessidade de comunicação do Data Warehouse com outros sistemas/usuários, por meio da geração de interfaces, arquivos etc (vide item 9, Figura 1 – Visão Geral). Entendendo que este requisito tem a intenção primária de apresentar informações para fora da fronteira do DW, o mesmo deve ser medido como uma Consulta Externa ou Saída Externa, conforme as regras de medição de funções de transação do CPM v.4.3.1.

3.10. Cenário 8: Modelagem de Camadas Semânticas ou Universos

3.10.1. A Camada Semântica, também descrita como Universo ou Contexto, é uma representação negocial dos dados do DW ou de um banco de dados transacional. A modelagem desta Camada Semântica permite ao usuário interagir com seus dados sem a necessidade de se conhecer detalhes sobre o banco de dados ou onde os dados estão armazenados. A Camada Semântica armazena estes dados, os quais poderão ser consultados pelo usuário por meio de funcionalidades ou consultas AD-HOC na camada OLAP (vide item 10, Figura 8 - Camada Semântica).

3.10.2. Desta forma, entendendo que existe um requisito funcional de consulta dos dados mantidos no DW, independente de como estes são preparados para a consulta e os quais o usuário acessará em algum momento, o mesmo deverá ser medido como um processo elementar e consequentemente, uma função de transação. Este requisito pode ser comparado a um relatório dinâmico, onde o usuário pode ter diferentes resultados de acordo com suas escolhas de filtros.

3.10.3. Deverá ser medida uma Consulta Externa ou Saída Externa para cada Camada Semântica modelada, uma vez que este requisito tem a intenção primária de apresentar informações para fora da fronteira da aplicação.

3.10.4. A Camada Semântica é configurada com as tabelas que são mantidas no DW/DM (Exemplo: Tabelas Fato e Tabelas Dimensão), assim, todos os arquivos lógicos (identificados a partir desta configuração) que compõem a Camada Semântica deverão ser medidos como ALRs para a função de transação em questão. Os DERs serão contados de acordo com as informações disponibilizadas para a consulta.

3.10.5. Adicionalmente, os requisitos de métricas/medidas da Camada Semântica serão medidos em SNAP conforme o item 5.4 deste documento.

3.10.6. A figura a seguir representa uma consulta AD-HOC dos dados preparados na Camada Semântica (vide item 10):


Página 63 de 73

Figura 9 - Camada Semântica


3.11. Cenário 9: Funções Administrativas

3.11.1. Há casos em que as funções administrativas são de natureza de negócio e podem ser contadas. Caso as funções administrativas sejam desenvolvidas para apoiar um usuário da aplicação, ou existirem exigências únicas de segurança, deverão ser medidas conforme as regras de funções de transação do CPM v.4.3.1. Funções administrativas podem ser medidas como Entradas Externas, quando tem a intenção primária de manter um ALI ou modificar o comportamento do sistema. Serão medidas Consulta Externas ou Saídas Externas quando existirem relatórios que apoiem as Funções Administrativas.

Nota : Para que estas funções possam ser medidas é necessário que existam especificações de requisitos do usuário que comprovem sua necessidade negocial.

3.11.2. Quadro resumo de contagem de funções de transação em projetos DW/BI

3.11.2.1. A tabela a seguir apresenta o resumo das diretrizes de como medir cada cenário.

Tabela 2 - Resumo da medição das Funções de Transação

Cenário Descrição Como medir

Cenário 1 Processo de ETL - Extração,

Transformação e Carga

Uma CE ou SE no escopo do sistema de

origem para cada geração de flat file

Uma EE para cada ETL completa que

mantenha um ALI no DM

Uma EE para cada ETL incremental que

mantenha um ALI no DM

Cenário 2

Processo de ETL – Tabelas

Fato e tabelas Dimensão

Uma EE para cada ETL que mantenha uma

tabela Fato


tabela Dimensão identificada como ALI

Uma EE para cada ETL que mantenha um

nível hierárquico de uma tabela Dimensão,

quando o mesmo for identificado como RLR

do ALI

Cenário 3 Processo de ETL – Tabelas Não colaboram com o tamanho funcional


Página 64 de 73

Dimensão Estática (Dado de

Código)

Cenário 4 Processo de ETL – Tabelas

de Agregação


Tabela Agregada de negócio

Cenário 5 Processo de ETL – Tabelas

Ponte


Tabela Ponte identificada como RLR ou ALI

Cenário 6 Relatórios, Painéis e

Dashboards pré-definidos

Uma CE ou SE para cada Relatórios, Painéis

e/ou Dashboards pré-definidos

Cenário 7 Geração de interfaces para

outros sistemas/usuários

Uma CE ou SE para cada requisito de

geração de interface/arquivos

Cenário 8 Modelagem de Camadas

Semânticas ou Universos

Uma CE ou SE para cada Camada

Semântica modelada

Cenário 9 Funções Administrativas Uma EE para cada função administrativa de

negócio que mantem um ALI ou modifica o

comportamento do sistema

Uma CE ou SE para cada relatório que

apoiem as funções administrativas de

negócio.


4. FUNÇÕES DE DADOS

4.1. Esse item apresenta os cenários identificados na contagem de funções de dados. A tabela a seguir descreve os cenários que serão apresentados nessa sessão.

Tabela 3 - Cenários das Funções de Dados Cenário Descrição

Cenário 1 Data Staging Area (DSA)

Cenário 2 Operational Data Store (ODS)

Cenário 3 Arquivos do Sistema de Origem – Para validação de dados

Cenário 4 Arquivos do Sistema de Origem - Dados de Código

Cenário 5 Tabelas Fato

Cenário 6 Tabelas Dimensão

Cenário 7 Tabelas Dimensão Estáticas (Dados de Código)

Cenário 8 Tabela de Agregação

Cenário 9 Tabelas Ponte


4.2. Cenário 1: Data Staging Area (DSA)

4.2.1. Essa estrutura (vide item 3, Figura 1 – Visão Geral), quando utilizada, possui propósito técnico e, portanto, não contribui para o tamanho funcional da aplicação.


Página 65 de 73

4.3. Cenário 2: Operational Data Store (ODS)

4.3.1. Quando o ODS não for uma simples cópia dos dados dos sistemas de origem e estes dados forem relevantes para o negócio, será possível medir os requisitos de movimentação dos dados para o DM. Entretanto, não haverá medição de funções de dados nessa estrutura, pois as informações armazenadas e reconhecidas pelo usuário serão medidas nas entidades de negócio mantidas na área do DM.

4.3.2. O item 5 da figura a seguir representa a área ODS reconhecida como uma partição:

Figura 10 - Operational Data Store (ODS)

Fonte: Ti Métricas/2016 4.4. Cenário 3: Arquivos do Sistema de Origem – Par a validação de dados

4.4.1. Existem casos onde o processo de ETL tem a necessidade de consultar entidades externas à fronteira da aplicação, ou tabelas Dimensão Compartilhadas para validação de dados. Essa necessidade ocorre durante o processamento da ETL, com o objetivo de referenciar dados para validação e por isso, a entidade acessada com esse propósito deverá ser medida como um arquivo de interface externa (AIE).

4.4.2. Em algumas situações, entidades de dados ou parte de entidades de dados são copiadas para a DSA do DW como simples cópia sem processamento adicional (vide cenário 4 do CPM v4.3.1), tampouco há a necessidade negocial de serem mantidas na ODS, DW ou DM, tendo apenas como propósito a utilização na validação durante o processamento das ETLs solicitadas pelo usuário. Nestes casos, se não se tratar de dados de código, estas cópias de entidades ou parte de entidades devem ser medidas como AIE.

Nota : Para que um arquivo seja medido como AIE, é necessário que o mesmo seja um ALI na fronteira de origem, conforme as regras do CPM v.4.3.1.

4.4.3. A figura a seguir demonstra o exemplo de um requisito de validação de dados à uma entidade no sistema de origem ou à uma tabela Dimensão compartilhada:


Página 66 de 73

Figura 11 - Arquivos do Sistema de Origem – Para validação de dados

Fonte: Ti Métricas/2016 4.5. Cenário 4: Arquivos do Sistema de Origem - Dad os de Código

4.5.1. Conforme o entendimento do conceito de Dados de Código, arquivos consultados para qualquer propósito que se encaixem nessa classificação, serão desconsiderados da contagem.

4.6. Cenário 5: Tabelas Fato

4.6.1. São as principais entidades de negócio de um Data Warehouse, contêm as métricas fundamentais da organização, e são o alvo final da maioria das consultas. Serão sempre identificadas como Dados de Negócio, contribuindo para o tamanho funcional.

4.6.2. Devem ser analisadas considerando somente os dados relevantes à tabela fato que está sendo analisada. Assim sendo, serão classificadas como ALI na medição, conforme a parte 2 do CPM v.4.3.1 (Medir Funções de Dados, pg. 2-5).

4.6.3. O item 7 da figura a seguir demonstra o exemplo de um requisito de armazenamento de uma tabela Fato em um DW:

Figura 12 - Tabelas Fato

Fonte: Ti Métricas/ 2016


Página 67 de 73

4.7. Cenário 6: Tabelas Dimensão

4.7.1. Tabelas dimensão deverão ser medidas como arquivos lógicos independentes da tabela Fato, quando representarem requisitos funcionais.

4.7.2. As tabelas Dimensão Hierárquicas ligadas a uma determinada dimensão, quando representarem requisitos funcionais, deverão ser medidas como Registros Lógicos Referenciados (RLR), conforme as regras de medição de funções de dados do IFPUG.

4.7.3. O item 7 da figura a seguir demonstra o exemplo de um requisito de armazenamento de uma tabela Dimensão e seus níveis hierárquicos em um DW:

Figura 13 - Tabelas

Dimensão


4.8. Cenário 7: Tabelas Dimensão Estáticas (Dados d e Código)

4.8.1. As tabelas dimensão estática são consideradas de acordo com o conceito de dado de código do CPM v.4.3.1 e consequentemente, não contribuem para o tamanho funcional. No entanto, um dado de código pode aparecer na medição SNAP dependendo do cenário existente, de acordo com o item 5.1 deste documento.

4.9. Cenário 8: Tabela de Agregação

4.9.1. Raramente uma tabela agregada pode ser desenvolvida por razões de negócio, porém se for o caso, este tipo de tabela deve ser medida como ALI, conforme as regras estabelecidas pelo CPM v.4.3.1.

4.9.2. As tabelas agregadas desenvolvidas com propósito não funcional deverão ser medidas por SNAP, de acordo com o item 5, Medições SNAP, Cenário 5: Criação/ Alteração de Tabelas Agregadas por motivos Técnicos.

4.10. Cenário 9: Tabelas Ponte

4.10.1. Sabendo que o conceito de tabela ponte se assemelha ao conceito de tabela associativa do IFPUG. Dessa forma, uma tabela ponte pode ser um ALI, um RLR ou simplesmente não contribuir com o tamanho funcional. Essa análise deverá ser realizada conforme o CPM v.4.3.1.

4.11. Quadro resumo de contagem de funções de dados em projetos DW/BI

4.11.1. A tabela a seguir apresenta o resumo das diretrizes de como medir cada cenário.


Página 68 de 73

Tabela 4 - Resumo da medição das Funções de Dados

Cenário Descrição Como medir

Cenário 1 Data Staging Area (DSA) Não colaboram com o tamanho funcional e não

funcional.

Cenário 2 Operational Data Store (ODS) Não colaboram com o tamanho funcional.

Cenário 3 Arquivos do Sistema de Origem

– Para validação de dados

Um AIE para cada entidade externa ou

Dimensão compartilhada consultada durante um

processo de ETL para validação de dados

Cenário 4 Arquivos do Sistema de Origem

- Dados de Código

Não colaboram com o tamanho funcional

Cenário 5 Tabelas Fato Um ALI para cada tabela Fato

Cenário 6 Tabelas Dimensão Um ALI para cada tabela Dimensão que

represente requisitos funcionais

Um RLR para cada nível hierárquico de tabela

Dimensão que represente requisitos funcionais

Cenário 7 Tabelas Dimensão Estáticas

(Dados de Código)

Não colaboram com o tamanho funcional

Cenário 8 Tabela de Agregação Um ALI para cada tabela Agregada construída

por razões de negócio

Tabelas Agregada construídas por motivos

técnicos devem ser medidas com SNAP, de

acordo com o Cenário 5: Criação/Alteração de

Tabelas de Agregação por motivos Técnicos

do item 5.5.

Cenário 9 Tabelas Ponte Analisar de acordo com o conceito de entidade

associativa do CPM v.4.3.1.


5. MEDIÇÃO SNAP

5.1. Este item apresenta os cenários identificados para a contagem de pontos SNAP (Software Non-functional Assessment Process). O método SNAP-IFPUG deverá ser utilizado para medir certas funcionalidades ou características específicas não cobertas pela diretriz funcional.

5.2. A tabela a seguir descreve os cenários que serão apresentados nesta sessão.

Tabela 5 - Cenários das Funções SNAP Cenário Descrição

Cenário 1 Criação de dados de código

Cenário 2 Cálculos complexos

Cenário 3 Movimentação de dados entre partições do DW


Página 69 de 73

Cenário 4 Construção de Métricas

Cenário 5 Criação/ Alteração de Tabelas Agregadas por motivos Técnicos


5.3. Cenário 1: Criação de dados de código

5.3.1. O método SNAP é utilizado em aplicações DW com o objetivo de medir funcionalidades e/ou características que necessitam de esforço adicional de desenvolvimento que não é coberto pela medição funcional. Dessa forma, por entender que não há esforço adicional e que não há distinção no esforço aplicado para a criação de dados de código em aplicações DW e aplicações transacionais comuns, estes também não serão medidos com o método SNAP.

5.3.2. Nota: De acordo com o método SNAP, os dados de código são agrupados como um grupo de dados e podem ser medidos como ALR (APM v.2.2, parte 1) em alguns casos. Para esta diretriz, ALRs de dados de código podem ser medidos com a utilização da subcategoria 1.4 (Movimentação interna de dados), uma vez que este requisito é reconhecido como um esforço adicional e não é considerado pela medição funcional.

5.4. Cenário 2: Cálculos complexos e Operações lógi cas extensivas

5.4.1. Nos projetos de Data Warehouse, a realização de cálculos complexos ou operações lógicas extensivas pode ocorrer em processos de extração de dados dos sistemas de origem, em processos de movimentação interna de dados entre as camadas da solução (Exemplo: ODS e DM) e processos de geração de dados para outras aplicações/usuário.

5.4.2. Quando estes requisitos de operações matemáticas complexas (um ou mais algoritmos) ou operações lógicas extensivas existirem, por exemplo durante o processo de ETL e métricas da Camada Semântica, estes deverão ser medidos por meio da subcategoria 1.2 (Operações Lógicas e Matemáticas) do método SNAP.

Notas:

1. Um algoritmo é definido pelo SNAP Assessment Practices Manual (APM) como uma série de equações e cálculos matemáticos executados com, ou de acordo com as lógicas operacionais para produzir resultados reconhecidos pelo usuário.

2. Uma operação lógica extensiva é definida pelo SNAP Assessment Practices Manual (APM) como uma operação lógica que contém um mínimo de 4 níveis de aninhamento e/ou contém mais que 38 DERs necessários para operar a operação lógica.

5.5. Cenário 3: Movimentação de dados entre partiçõ es do DW

5.5.1. Quando houver requisitos de movimentação interna de dados entre depósitos de dados do DW (vide itens 4 e 6, Figura 13 - Movimentação de dados entre partições do DW), mais especificamente entre os servidores ODS e o servidor DM, os mesmos deverão ser medidos por meio da subcategoria 1.4 (Movimentação interna de dados) do método SNAP.

5.5.2. Para o parâmetro de complexidade “Número de ALR do processo elementar” desta subcategoria, deverão ser consideradas a quantidade de ALRs identificados para a medição funcional, conforme orientação da diretriz funcional, somados a um ALR para os dados de código, caso existam, conforme o APM v.2.2.

5.5.3. Adicionalmente, quando for identificado a existência de cálculos matemáticos complexos durante o processamento da movimentação interna, a subcategoria 1.2 (Operações Lógicas e Matemáticas) também deverá ser aplicada.


Página 70 de 73

Notas :

1. Para que haja a medição de requisitos de movimentação interna do ODS para o DM, é necessário que o ODS seja reconhecido como uma partição pela CAIXA (vide item 1 deste documento, conceito de Partição). Dessa forma as estruturas ODS e DW (ou DM) serão consideradas partições, conforme conceito do APM v.2.2.

2. Apesar dos dados das origens passarem pela DSA (essa movimentação está representada pelo item 4 da figura 13), estes são cópias da origem e não há requisitos de movimentação interna de dados da DSA para outro depósito de dados (ODS ou DM). A DSA é criada geralmente por motivos de performance e segurança, e raramente é vista ou especificada por um usuário de negócio.

5.5.4. O item 6 da figura a seguir demonstra um requisito de movimentação interna entre as partições ODS e DM. O item 4 demonstra o caminho dos dados que passam pela DSA até o ODS:

Figura 14 - Movimentação de dados entre partições do DW


5.6. Cenário 4: Construção de Métricas

5.6.1. As métricas são resultadas de fórmulas criadas a partir de um requisito de usuário, geralmente mantidas em tabelas fato e apresentadas ao usuário por meio da camada OLAP (Camada Semântica).

5.6.2. As métricas ou medidas valoradas podem ser resolvidas nos projetos de Data Warehouse, tanto em processos de ETL, quanto em processos da camada OLAP. Quando implementadas nos processos de ETL, as métricas são armazenadas na base de dados do Data Mart. Quando implementadas nos processos da camada OLAP, ou seja, na Camada Semântica, as métricas são construídas em tempo de execução. Independentemente de onde foram implementadas (Camada Semântica ou ETL), as métricas sofrem operações de projeção e serão tratadas como requisitos de armazenamento.

5.6.3. Dessa forma, as métricas serão medidas de acordo com a subcategoria 3.2 (Tecnologia de Banco de dados).

5.6.4. Para o parâmetro de complexidade “Número de alterações no banco de dados” desta subcategoria, deverão ser consideradas a quantidade de métricas desenvolvidas ou alteradas.

5.6.5. Caso as métricas contemplem requisitos de operações matemáticas complexas por meio de algoritmos (criação ou manutenção), ou operações lógicas extensivas, os mesmos deverão


Página 71 de 73

ser medidos, além da subcategoria 3.2, por meio da subcategoria 1.2 (Operações Lógicas e Matemáticas).

Notas :

1. A UCS (Unidade de contagem SNAP) deve corresponder ao processo elementar, neste caso, como o universo não é medido por APF na CAIXA, deve-se considerar o processo que representa a visão/necessidade do usuário, exemplo: Disponibilizar informações negociais (OLAP).

2. Um algoritmo é definido pelo SNAP Assenssment Practices Manual (APM) como uma série de equações e cálculos matemáticos executados com, ou de acordo com as lógicas operacionais para produzir resultados reconhecidos pelo usuário.

5.7. Cenário 5: Criação/Alteração de Tabelas de Agr egação por motivos Técnicos

5.7.1. Quando houver requisitos de tabelas agregadas com propósitos não funcionais, por exemplo uma view criada para armazenar dados de um determinado período com o propósito de otimizar consultas, os mesmos deverão ser medidos por meio da subcategoria 3.2 (Tecnologia de Banco de dados).

5.7.2. Quadro resumo de medição SNAP em projetos DW/BI

5.7.2.1. A tabela a seguir apresenta o resumo das diretrizes de como medir cada cenário.

Tabela 6 - Resumo da medição SNAP Cenário Descrição Como medir

Cenário 1 Criação de dados de código Não colabora com o tamanho funcional e

não funcional3

Cenário 2 Cálculos complexos Utilizar a subcategoria 1.2

Cenário 3 Movimentação de dados entre

partições do DW

Utilizar a subcategoria 1.4

Cenário 4 Construção de Métricas Utilizar a subcategoria 3.2

Utilizar também a subcategoria 1.2 quando

aplicável.

Cenário 5 Criação/ alteração de tabelas

Agregadas por motivos técnicos

Utilizar a subcategoria 3.2


3 Os dados de código serão considerados como ALR na medição da subcategoria 1.4, conforme o cenário 3.


Página 72 de 73

Capítulo 14. Glossário

• ALI – Arquivo Lógico Interno. Grupo de dados ou informações de controle identificável pelo usuário, logicamente relacionado e mantido na fronteira da aplicação.

• AIE – Arquivo de Interface Externa. Grupo de dados ou informações de controle

identificável pelo usuário, logicamente relacionado e mantidos fora da fronteira da aplicação, ou seja, em outra aplicação.

• APF – Análise de Pontos de Função: Método padrão para medir sistemas e projetos de

desenvolvimento e manutenção de sistemas sob a perspectiva do usuário.

• CE – Consulta Externa. Processo elementar que envia dados ou informações de controle para fora da fronteira da aplicação. A lógica de processamento deve obrigatoriamente recuperar dados ou informações de controle de um ALI ou AIE.

• Code Data – Dados de código – Provêem uma lista de valores válidos que um atributo

pode ter. Atendem a requisitos técnicos e não interferem no tamanho funcional da aplicação.

• Code Table – Tabela de código - Armazena Dados de Código.

• Laudo de Contagem FSDMS - Documento utilizado para solicitação de demanda de

medição de sistema É através deste artefato que as planilhas contidas no documento de Estimativa são alimentadas

• CPC – Counting Practices Committee – Comitê de Práticas de Contagem do IFPUG que,

entre outras coisas, é responsável por difundir as melhores práticas de contagem de pontos de função e por esclarecer dúvidas acerca da aplicação da APF.

• CPM – Counting Pratices Manual. Manual de Práticas de contagem de Análise de Pontos

de Função, mantido pelo IFPUG (Grupo Internacional de Usuários de Pontos de Função).

• DER – Dados Elementares Referenciados. O mesmo que itens de dados nomenclatura utilizada na CAIXA. Campo único, reconhecido pelo usuário, não repetido.

• EE – Entrada Externa. Processo elementar que processa dados ou informações de

controle recebidos de fora da fronteira da aplicação para manter um ou mais ALIs do sistema ou alterar o comportamento do sistema.

• ESTIMATIVA - Artefato utilizado para estimativas - Metodologia de Desenvolvimento de

sistemas Estruturada e Processo Unificado.

• Fator de Ajuste – Indica a funcionalidade geral fornecida pela aplicação ao usuário. É um valor percentual calculado a partir do nível de influência de cada uma das Características Gerais do Sistema. O fator de ajuste do IFPUG não é aplicado no contexto da CAIXA.

• FSW – Fábrica de Software – Empresa contratada pela CAIXA para prestar serviços de

desenvolvimento de Software.


Página 73 de 73

• GT Métricas – Grupo de trabalho de métricas. Este grupo realiza estudos sobre a aplicação de métricas na TI da Caixa e sugere orientações para que as Representações trabalhem de forma padronizada.

• MDS – Metodologia de Desenvolvimento de Sistemas da CAIXA

• Processo Elementar – Menor unidade de atividade significativa para o usuário. Deve

ser completo em si mesmo e deixar o negócio da aplicação sendo contada em estado consistente.

• PU – Processo Unificado

• SE – Saída Externa. Um processo elementar que envia dados ou informações de

controle para fora da fronteira da aplicação. A lógica de processamento deve obrigatoriamente conter ao menos uma fórmula matemática ou cálculo, ou criar dados derivados.

guia de orientação de métricas - caixa econômica federal

Documents