Resumo APF

1. Por que medir software?

Por que nos damos ao trabalho de medir projetos de software? Qual o ganho nisso, e que respostas eu obtenho com mtricas? Mtricas ajudam a responder perguntas cruciais no desenvolvimento e gerenciamento de projetos de software. Para estimar o esforo necessrio no atendimento de novos requisitos. Mtricas permitem estimar o tamanho do software em qualquer fase do ciclo de vida. Assim possvel saber qual o real esforo por trs do atendimento a certos requisitos. Para acompanhar acompanho o progresso do meu projeto? Mtricas permitem controle e correo de problemas. Atravs delas possvel determinar se o projeto est atrasado, ou se estourou o oramento e, ainda, quanto de trabalho ainda resta a ser re alizado. Para tomar decises. Devo contratar mais recursos, diminuir o escopo, ou aumentar a produtividade? Mtricas permitem justificar e defender decises tomadas. Atravs delas possvel realizar anlises de riscos e determinar se alguns marcos do projeto foram alcanados. Para anlise de make or buy. Devo implementar do zero ou comprar pronto? Devo terceirizar? Mtricas ajudam na anlise de make or buy. A empresa pode usar o seu histrico de desempenho e compar-lo aos nveis oferecidos pelo mercado para tomar esta deciso. Para subsidiar contratos. Como devo contratar um fornecedor? Vou pagar por hora? Contratos de homem-hora remuneram somente a passagem do tempo. Mtricas como Pontos de Funo medem o produto e remuneram o resultado (funcionalidade) entregue.

2. O que medir?
Voc deve medir aquilo que relevante para anlise. Pode ser (dentre outras coisas): Recursos e Custos (pessoas, ferramentas, oramento, contabilizao, etc.); Qualidade (tempo mdio entre falhas, incidentes, problemas, etc.); Cronograma (atrasos, marcos, entregas, etc.); Progresso (entregveis, funcionalidades prontas, documentos validados, etc.); Tamanho (PF).

Vamos nos concentrar no Tamanho do Software, que a medida relacionada a Pontos de Funo.

Qual medida melhor representa o tamanho? primeira vista, a unidade mais intuitiva seria o nmero de linhas de cdigo. Teoricamente, dois programas de mesma linguagem de programao poderiam ser comparados e o que tivesse mais linhas de cdigo seria maior. Porm, isto uma falcia. A contagem de linhas de cdigo envolve uma srie de riscos que inviabilizam o seu uso como medida: No h padronizao na contagem (Conto comentrios? E linhas em branco? E diretivas ao compilador? Devo contar cada comando como uma linha?); LOC no significa nada para clientes e usurios . No tem foco no negcio, na funcionalidade. 1 milho de linhas de cdigo muito ou pouco? No h como estimar confiavelmente a quantidade de LOC nas fases iniciais do ciclo de vida. Depender de linguagem de programao inaceitvel. Isso gera problemas quando um sistema implementado em vrias linguagens, ou quando essas prprias linguagens evoluem (JSE 1.4, 5.0, 6.0, etc...).

Percebe-se, ento, que invivel utilizar linhas de cdigo como medida. O mtodo adotado como padro mundial para medir o tamanho funcional de um software a Anlise de Pontos de Funo, sendo eles (os Pontos de Funo) a medida adotada. APF uma tcnica de medio das funcionalidades fornecidas do ponto de vista do usurio e tem por objetivo tornar a contagem independente de tecnologia utilizada. APF busca medir o que o software faz, e no como ele foi construdo. Apesar disso, importante perceber que APF no mede diretamente esforo, produtividade ou custo. exclusivamente uma medida de tamanho funcional do software. Esse tamanho funcional, junto com outras variveis e o histrico da sua organizao que pode ser usado para derivar outras informaes.

3. Histrico da APF
Na dcada de 70, Allan Albrecht foi encarregado de medir a produtividade de vrios projetos de software desenvolvidos na IBM, mas estes projetos tinham sido programados em linguagens distintas, inviabilizando a utilizao da medida de linhas de cdigo. Isso motivou a busca por uma medida que fosse independente da linguagem de programao utilizada. Aps a proposta inicial na IBM, o mtodo se popularizou e deu incio ao IFPUG. O IFPUG ( International Function Point Users Group ) uma entidade sem fins lucrativos, composta por pessoas e empresas de diversos pases, cuja finalidade promover um melhor gerenciamento de processos de desenvolvimento e manuteno de software com o uso de pontos de funo e outras tcnicas de medio. quem mantm o CPM (Counting Practices Manual ), onde o mtodo de contagem est descrito em detalhes.

Os principais objetivos do IFPUG Counting Practices Manual, Release 4.3, so Manter conformidade com a norma ISO/IEC 14143-1:2007 Information technology Software measurement Functional size measurement Definition of concepts Prover uma descrio clara e detalhada da contagem de pontos de funo Garantir que as contagens sejam consistentes com as prticas de contagem dos afiliados do IFPUG Fornecer um guia para permitir a contagem de pontos de funo a partir dos entregveis das metodologias e tcnicas mais conhecidas Prover um entendimento comum para permitir que os fornecedores de ferramentas forneam suporte automatizado para a contagem de pontos de funo

Os grandes releases do CPM foram os seguintes: Aps as definies iniciais na IBM, o crescimento do uso de pontos de funo trouxe um grande aumento no nmero de aplicaes medidas. Esta ampliao da aplicao desafiou a descrio original da medida e tornou necessria a criao de um guia para interpretao das regras originais em novos ambientes. Isto foi refletido na Release 2.0 (abril de 1988) do International Function Point Users Group (IFPUG) Function Point Counting Practices Manual. A Release 3.0 (abril de 1990) do IFPUG Function Point Counting Practices Manual foi o principal marco na evoluo da medio do tamanho funcional. Pela primeira vez, o Comit de Prticas de Contagem do IFPUG trabalhou para transformar o que era uma coleo de muitas interpretaes das regras em um documento verdadeiramente coerente, representando uma viso consensual das regras de contagem de ponto de funo. Neste sentido, este foi o primeiro passo para o estabelecimento de padres reais para a medio de pontos de funo, os quais poderiam ser aplicados a diversas organizaes. A Release 4.0 (janeiro de 1994) foi o marco seguinte na evoluo da medio do tamanho funcional. Essa release abordou o uso de pontos de funo nas fases iniciais do desenvolvimento dos projetos, para estimar o tamanho do projeto utilizando disciplinas de engenharia da informao. O nmero rapidamente crescente de aplicaes com janelas de interface grfica do usurio (GUI) exigiu que fosse includa a contagem de GUI nessa release. Devido a cada vez mais contagens estarem acontecendo em uma vasta variedade de situaes, a release colocou nfase na interpretao e prtica das regras de contagem. Exemplos foram includos ao longo da documentao e estudos de casos complementaram o material. Finalmente, a Release 4.0 continuou a esclarecer e aumentar a consistncia da contagem de pontos de funo. Release 4.3 (janeiro de 2010). As regras e o processo da anlise de pontos de funo (APF) do IFPUG so concisos e fceis de usar. Para refletir isto e tornar o Manual de Prticas de Contagem (CPM) cada vez mais atraente como um manual de referncia, o Comit de Prticas de Contagem (CPC) decidiu reestruturar o CPM 4.3 de modo a compatibiliz-lo com os padres de formatao da ISO. Alm disso, a Release 4.3 contm pequenas modificaes e fornece novos exemplos, bem como explicaes e

interpretaes melhoradas para as regras existentes, que iro aumentar ainda mais a consistncia entre contadores. Verso atual: CPM 4.3.1.

Observao: outro grande grupo de usurios de pontos de funo a NESMA (Netherlands Software Metrics Users Association), sediado na Holanda. Suas aes e objetivos so bem prximos aos do IFPUG, inclusive com forte colaborao entre ambas, mas existem algumas diferenas, principalmente na contagem de projetos de melhoria. Hoje j existe um padro ISO para mtodos de Medio Funcional, sendo a norma ISO 14143 a que estabelece conceitos padronizados a serem seguidos por qualquer mtodo de medio. Esta garante que todos os mtodos de medio de tamanho funcional sejam baseados em conceitos similares e possam ser testados para assegurar que eles se comportam de maneira similar e da forma esperada por um mtodo de medio. O mtodo do CPM est de acordo com esse padro, e descrito na norma ISO 20926 (CPM 4.3). Observaes sobre o mtodo de Pontos por Caso de Uso. At o incio da dcada de 90, existia uma noo de que APF no era adequada para sistemas orientados a objetos, apesar disto ser uma falcia. Alm disso, processos que utilizam UML e Casos de Uso para especificar sistemas se popularizaram rapidamente. Assim, foi proposto o mtodo de Pontos de por Caso de Uso. O mtodo consiste basicamente de: 1. Contar atores e casos de uso, identificado suas complexidades; 2. Calcular os PCUs no ajustados; 3. Ajustar os PCUs de acordo com a complexidade tcnica e a complexidade ambiental. A princpio os mtodos de APF e PCU so parecidos, mas na prtica h diferenas significativas: 1. PCU s pode ser aplicado a projetos que utilizem a tcnica de casos de uso (como voc faz para medir aplicaes legadas, sem casos de uso, por exemplo?); 2. Devido ao processo de medio do PCU ser baseado em casos de uso, o mtodo no pode ser empregado antes de concluda a anlise de requisitos do projeto. APF permite voc estimar o tamanho do software mesmo antes da finalizao desta etapa. 3. difcil conseguir medidas padronizadas e consistentes para PCUs, pois no existe um padro nico de escrita para casos de uso. 4. A determinao da complexidade tcnica e complexidade ambiental est sujeita a certo grau de subjetividade que dificulta a aplicao consistente do mtodo. O fator de ajuste da APF tambm tem o mesmo problema, mas o IFPUG tem vrias diretrizes para minimizar o risco. Mesmo assim, o uso do fator de ajuste na APF tende a ser eliminado pelo IFPUG em breve. 5. No h um grupo coeso para contagem de PCUs como existe para APF.

 um erro achar que o PCU ser um mtodo melhor que a APF se o projeto for especificado via casos de uso. APF pode ser (e ) aplicada a casos de uso, sem dificuldade alguma. Em suma, no benefcio adicional do PCU sobre a APF.

3. Anlise de Pontos de Funo

Anlise de Pontos de Funo um mtodo para a medio de tamanho funcional de software a partir da viso do usurio. O que medido? A anlise de pontos de funo mede o software quantificando as tarefas e servios (isto , funcionalidade) que o software fornece ao usurio, primordialmente com base no projeto lgico. Os objetivos da anlise de pontos de funo so medir: A funcionalidade implementada no software, que o usurio solicita e recebe; A funcionalidade impactada pelo desenvolvimento, melhoria e manuteno de software, independentemente da tecnologia utilizada na implementao.

Para qu medir? As organizaes podem aplicar este Padro Internacional para medir o tamanho de um produto de software a fim de: dar suporte anlise de qualidade e produtividade; estimar o custo e recursos requeridos para o desenvolvimento, melhoria e manuteno do software; fornecer um fator de normalizao para a comparao de software; determinar o tamanho de um pacote de aplicao adquirido, por meio do dimensionamento funcional de todas as funes includas no mesmo; ajudar os usurios a determinar o benefcio provido por um pacote de aplicao para a sua organizao, por meio do dimensionamento funcional das funes que correspondam especificamente aos seus requisitos.

Quais so as vantagens? O processo de anlise de pontos de funo : Suficientemente simples para minimizar o custo adicional introduzido pelo processo de medio; Uma medida consistente entre diversos projetos e organizaes.

3.1. Aplicabilidade
APF pode ser aplicado a todos os domnios funcionais. O IFPUG publica constantemente artigos fornecendo orientaes para a utilizao do mtodo em ambientes e domnios diferentes. Os analistas de pontos de funo do IFPUG identificaram diferentes taxas de entrega (horas para entregar um ponto de funo) relacionadas construo de aplicaes em diferentes domnios funcionais, calibradas para diversos tamanhos de projeto e complexidade do software. Existe uma organizao, a ISBSG (International Software Benchmarking Standards Group), cuja misso manter um repositrio pblico de mtricas de projetos de software. Neste repositrio existem informaes de mais de 6.000 projetos de software de dezenas de pases, o que possibilita a anlise de produtividade, boas prticas, custos, etc., tudo organizado por domnio e tecnologias utilizadas.

4. Processo de Medio
Para conduzir uma contagem de pontos de funo devem ser executadas as seguintes atividades, a fim de identificar e classificar os componentes funcionais bsicos (ALI, AIE, EE, SE, CE): a) Reunir a documentao disponvel ; b) Determinar o escopo e a fronteira da contagem, identificando os Requisitos Funcionais do Usurio; c) Medir as funes de dados d) Medir as funes de transao e) Calcular o tamanho funcional f) Documentar a contagem de pontos de funo g) Reportar o resultado da contagem de pontos de funo

5.1 Reunir a documentao disponvel.

A documentao de suporte a uma contagem de pontos de funo deve descrever a funcionalidade entregue pelo software ou a funcionalidade impactada pelo projeto de software medido. Deve ser obtida documentao suficiente para conduzir a contagem de pontos de funo, ou acesso a especialistas no assunto capazes de fornecer informaes adicionais para suprir quaisquer falhas na documentao. Geralmente, no h um nico documento que resolva todas as necessidades de informao da medio; logo, o mais comum que a medio seja feita com base na anlise de mais de um tipo de documento. Em geral, os itens a seguir so teis quando se faz alguma medio de tamanho funcional: Documentos de requisitos Diagrama de entidades Modelos de objetos Modelos de dados Arquivo e esquemas banco de dados (com lgica, atributos necessrios do usurio identificados) Acordos de Interface com descries de entradas em lote/arquivos de transao e interfaces de/para outras aplicaes Exemplos de relatrios, telas online e outras interfaces de usurio Demonstrao da operao de aplicao Uma ou mais especialistas na aplicao (para a aplicao que est sendo medida) Um ou mais clientes/usurios de aplicao (passveis de serem consultados durante o processo de medio) Guia de usurio, manual de treinamento e ajuda da aplicao Documentao do projeto do sistema Especificaes funcionais

5.2 Determinar o escopo e a fronteira da contagem, identificando os Requisitos Funcionais do Usurio.

Exemplo de Aplicao (Recursos Humanos):

Para determinar o escopo e fronteira da contagem e identificar os Requisitos Funcionais do Usurio, devem ser executadas as seguintes atividades: a) Identificar o propsito da contagem NOTA 1 Uma contagem de pontos de funo conduzida a fim de fornecer uma resposta para uma questo de negcio, sendo a questo de negcio que determina o propsito. NOTA 2 O propsito da contagem determina o escopo da contagem. EXEMPLO 1 O propsito da contagem poderia ser a determinao do tamanho de uma release de software especfica. EXEMPLO 2 O propsito da contagem poderia ser a determinao do tamanho de uma aplicao, como parte do esforo da organizao para determinar o tamanho de seu portfolio de software. b) Identificar o tipo de contagem, com base no propsito, como um dos seguintes: 1) uma contagem de pontos de funo de projeto de desenvolvimento; 2) uma contagem de pontos de funo de aplicao; 3) uma contagem de pontos de funo de um projeto de melhoria. Um projeto de desenvolvimento um projeto para desenvolver e fornecer a primeira verso de um software. O tamanho funcional do projeto de desenvolvimento uma medida de funcionalidade oferecida aos usurios com a primeira instalao do software. De certa forma uma contagem estimada, pois pode haver mudanas durante o desenvolvimento que modifiquem a contagem.

Um projeto de melhoria um projeto para desenvolver e entregar manutenes no software. O tamanho funcional do projeto de melhoria uma medida das funcionalidades adicionadas, alteradas e excludas na concluso de um projeto de melhoria. Segundo a ISO, as manutenes podem ser: Manuteno Adaptativa: acompanhar mudanas no ambiente, por exemplo, para acompanhar uma nova verso de sistema operacional; Manuteno Corretiva: correo de erros e problemas; Manuteno Perfectiva: melhorias em geral (documentao, desempenho, usabilidade, etc.). Um tamanho funcional de uma aplicao uma medida de funcionalidade que uma aplicao oferece ao usurio. Ela tambm e chamado de baseline (verso estabilizada) ou tamanho funcional instalado. Este tamanho fornece uma medida de funes atuais que o aplicativo fornece ao usurio. O nmero inicializado quando o projeto de desenvolvimento da contagem de ponto de funo finalizado. atualizado toda vez que um projeto de melhoria finalizado alterar funes da aplicao c) Determinar o escopo da contagem, com base no propsito e tipo de contagem. O escopo define quais funes sero includas na contagem, se ela abranger um ou mais sistemas ou apenas parte de um sistema. Por exemplo, voc pode decidir se vai contar uma ou mais aplicaes ou ento apenas parte de uma aplicao. Alm disso, pode abranger: Todas as funcionalidades disponveis; Apenas as funcionalidades efetivamente utilizadas pelo usurio; Apenas algumas funcionalidades especficas (relatrios, transaes cadastrais, etc.).

d) Determinar a fronteira de cada aplicao contida no escopo da contagem com base na viso do usurio e no em consideraes tcnicas. A fronteira uma interface conceitual entre o software sob estudo e seus usurios. A fronteira (tambm chamada de fronteira da aplicao): Define o que externo aplicao; Indica a fronteira entre o software que est sendo medido e o usurio; Atua como uma membrana atrav s da qual os dados processados pelas transaes (EEs, SEs e CEs) passam para dentro e para fora da aplicao; Envolve os dados lgicos mantidos pela aplicao (ALIs); Auxilia na identificao dos dados lgicos referenciados mas no mantidos pela aplicao (AIEs); Depende da viso externa do negcio do usurio da aplicao. independente de consideraes de tcnicas e/ou implementao.

Um usurio qualquer pessoa ou coisa que se comunica ou interage com o software a qualquer momento. Podem ser hardware, outras aplicaes, outros sistemas, etc. Se um

usurio fosse apenas uma Pessoa, no seria possvel medir PFs para sistemas que no tm interface grfica com o usurio. A viso do usurio representa uma descrio formal das necessidades dos negcios do usuri o, na linguagem do usurio. Os desenvolvedores traduzem a informao do usurio para informaes em linguagem tcnica a fim de prover uma soluo. A viso do usurio: uma descrio das funes do negcio; Pode ser feito por declarao verbal pelo usurio atravs de seu ponto de vista; aprovada pelo usurio; Pode ser usada para medir o tamanho funcional; Pode variar na forma fsica (ex., catlogo de transaes, propostas, documento de requisitos, especificaes externas, especificaes detalhadas, manuai s do usurio).

EXEMPLO: Se o propsito for estimar o custo de uma melhoria nas aplicaes de Recursos Humanos (RH) e Benefcios, ento: - o tipo de contagem uma contagem de projeto de melhoria; - o escopo dever incluir as funes transacionais e de dados includas, alteradas ou excludas referentes tanto aplicao de RH quanto de Benefcios, assim como quaisquer requisitos de converso referentes a cada aplicao; - a viso do usurio que RH e Benefcios so reas funcionais diferentes, por esse motivo so aplicaes separadas; - existe uma fronteira entre as aplicaes de RH e de Benefcios, assim como entre cada aplicao e o usurio. A viso do usurio pode ser materializar atravs de alguns artefatos ou insumos do projeto, tais como (exemplos): Histria de Usurio; Proposta de Projeto; Especificao de necessidades de negcio; Especificao de casos de uso; Prottipos de interface, etc.

e) Os requisitos do usurio podem incluir uma mistura de requisitos funcionais e nofuncionais; identificar quais requisitos so funcionais e excluir os no-funcionais. Requisitos Funcionais so aqueles que capturam o que o software deve fazer em termos de tarefas e servios. <<Ver o curso de Requisitos para exemplos de Requisitos Funcionais>>. Requisitos no funcionais so restries ou qualidades e caractersticas do sistema. Hierarquia de classificao de requisitos segundo a norma ISO/IEC 14143:

5.3 Medir as funes de dados

Uma funo de dados representa a funcionalidade fornecida ao usurio para atender suas necessidades internas e externas de armazenamento de dados. Toda a funcionalidade de dados dentro do escopo da contagem deve ser avaliada para identificar cada grupo lgico de dados. Uma funo de dados pode ser um arquivo lgico interno ou um arquivo de interface externa. ` O termo arquivo aqui no significa arquivo fsico ou tabela. Nesse caso, arquivo se refere a um grupo de dados logicamente relacionados e no implementao fsica destes grupos de dados. A chave pensar em um modelo conceitual (entidades) e no no modelo lgico (tabelas). Exemplo: mesmo que uma Entidade (BD) esteja distribuda entre vrias tabelas devido a tcnicas de normalizao, o Arquivo Lgico ainda um s. Devem ser executadas as seguintes atividade para medir as funes de dados: 1) Identificar funes de dados (ALI e AIE); Um arquivo lgico interno (ALI) um grupo de dados ou informaes de controle, reconhecido pelo usurio e mantido dentro da fronteira da aplicao sendo medida. A principal inteno de um ALI armazenar dados mantidos por um ou mais processos elementares da aplicao sendo medida. O diagrama simplificado anterior apresenta um grupo de dados relacionado a empregado mantido dentro da Aplicao de Recursos Humanos como um exemplo de Arquivo Lgico Interno.

Um arquivo de interface externa (AIE) um grupo de dados ou informaes de controle, reconhecido pelo usurio, e que apenas referenciado pela aplicao sendo medida, mas que so mantidos dentro da fronteira de outra aplicao. A principal inteno de um AIE armazenar dados referenciados por um ou mais processos elementares da aplicao sendo medida. Isto significa que um AIE contado para uma aplicao deve ser obrigatoriamente um ALI em alguma outra aplicao. O diagrama simplificado anterior mostra informao de taxa de converso mantida pelo Sistema Monetrio e que referenciado pela Aplicao de Recursos Humanos como um exemplo de Arquivo de Interface Externa. 2) Contar DERs e RLRs para cada funo de dados; Dado Elementar Referenciado (tipo de dado elementar) DER: atributo nico, reconhecido pelo usurio e no repetido. Por exemplo, a Aplicao A pode identificar e utilizar um endereo como: rua, cidade, estado e CEP. A Aplicao B pode ver o endereo como um bloco de dados sem considerar os componentes individuais. A Aplicao A contaria quatro DERs; a Aplicao B contaria um DER. Por exemplo, a Aplicao A pode contar Data como trs DERs, dia, ms e ano. J a Aplicao B pode contar Data como um nico DER, se os trs campos sempre forem manipulados juntos. Por exemplo, a Aplicao X mantm e/ou referencia um ALI que contm CPF, Nome, Rua, Caixa Postal, Cidade, Estado e CEP. A Aplicao Z mantm e/ou referencia Nome, Cidade e Estado. A Aplicao X contaria sete DERs; a Aplicao Z contaria trs DERs. Importante lembrar que no so contadas as vrias ocorrncias de um tipo de dado. Por exemplo, caso uma entidade tenha um conjunto de Telefones, mesmo que sejam vrios, o conjunto contado como um nico tipo de dado. Registro Lgico Referenciado (tipo de registro elementar) RLR: subgrupo de dados elementares referenciados, reconhecido pelo usurio, contido em uma funo de dados. Conte um RLR para cada funo de dados (por padro cada funo de dado tem um subgrupo de DERs para ser contado como um RLR) Por exemplo, em uma Aplicao de Recursos Humanos, so armazenados dados sobre os Funcionrios da empresa. Ocorre que, cada Funcionrio, pode ser Mensalista ou Diarista.

Se o analista fosse modelar isso em classes, provavelmente obteria trs classes diferentes: a superclasse Funcionrio e as subclasses Funcionrio Mensalista e Funcionrio Diarista, sendo as duas ltimas subtipos da primeira. Nesse caso, deve-se contar apenas um ALI, no caso o Funcionrio, que contm trs RLRs: Funcionrio (padro), Funcionrio Mensalista e Funcionrio Diarista.

Podemos ainda mapear esses termos para a anlise de pontos de funo, conforme mostrado na seguinte matriz:

3) Determinar a complexidade funcional de cada funo de dados, de acordo com a seguinte tabela:

Analisando esta tabela, pode-se perceber que no necessrio contar EXATAMENTE o nmero de DERs e RLRs em uma aplicao. Na verdade, isto s relevante quando a quantidade est nos limites das faixas dessa tabela de complexidade. Alm disso, uma eventual classificao incorreta da complexidade da funo afeta de forma bem limitada o resultado final da medio. Mais importante identificar corretamente a quantidade de funes (tanto de dados como de transaes). 4) Determinar o tamanho funcional de cada funo de dados, de acordo com a seguinte tabela:

Importante: algumas entidades no so contadas como Arquivos Lgicos (Funes de Dados). Apesar de armazenarem dados, alguns arquivos so uma implementao de requisitos tcnicos, e no devem influenciar o tamanho funcional da aplicao.

Exemplos: 1. Dados de Cdigo tambm chamados de Metadados, em geral so especificados pelo prprio desenvolvedor em resposta a requisitos tcnicos. a. Normalmente consistem do campo-chave e um ou dois outros campos. b. Raramente mudam; c. Podem ser dados estticos, dados de substituio ou mesmo faixas de valores vlidos; d. Exemplo: Arquivos que armazenam a sigla e o nome das unidades da federao; 2. Arquivos de ndice utilizados para melhorar o desempenho na recuperao de dados. 3. Arquivos Temporrios que, por exemplo, so utilizados em vrias etapas de um processamento batch. 4. Dados Distribudos que so espalhados em vrios arquivos fsicos, porm representam uma nica entidade lgica. 5. E outras (ver manual)...

5.4 Medir as funes de transao

Uma funo de transao um processo elementar que fornece funcionalidade ao usurio para processamento de dados. Toda a funcionalidade de transao dentro do escopo da contagem deve ser avaliada, a fim de identificar cada processo elementar nico Uma funo de transao pode ser uma entrada externa, sada externa ou consulta externa. 1) Identificar cada processo elementar requerido pelo usurio; Processo elementar: menor unidade de atividade significativa para o usurio. Constitui uma transao completa, e autocontida. Ao final de sua execuo, deixa o negcio da aplicao em um estado consistente. Por exemplo, os requisitos do usurio para adicionar um funcionrio incluem informaes de salrio e dependentes. Um funcionrio no ter sido criado se no forem includas todas as respectivas informaes. Incluir separadamente apenas parte das informaes deixar o negcio de incluir um funcionrio em um estado inconsistente. Se forem includos tanto o salrio do empregado quanto as informaes do(s) dependente(s), a unidade de atividade ser concluda e o negcio ser deixado em um estado consistente. EXEMPLO 1 Um Requisito Funcional do Usurio pode estabelecer que deve ser fornecida uma funo para Manter Informaes de Empregado. Esse requisito decomposto em unidades de trabalho menores tais como Incluir Empregado, Alterar Empregado e consultar Empregado.

EXEMPLO 2 Os requisitos individuais podem estabelecer a necessidade de incluir diversos tipos de informaes de empregado (por exemplo, endereo, salrio e informaes de dependentes), mas a menor unidade de atividade significativa para o usurio Incluir Empregado. 2) Classificar cada processo elementar como uma funo de transao de Entrada Externa (EE), Sada Externa (SE) ou Consulta Externa (CE); Uma entrada externa (EE) um processo elementar que processa dados ou informaes de controle recebidas de fora da fronteira da aplicao. A inteno primria de uma EE manter um ou mais ALIs e/ou alterar o comportamento do sistema. O diagrama simplificado anterior mostra o processo de cadastrar um novo empregado na Aplicao de Recursos Humanos como um exemplo de uma Entrada Externa. Um Processo Elementar deve ser classificado como Entrada Externa se o mesmo: 1) Incluir lgica de processamento para receber dados ou informaes de controle que entrem pela fronteira da aplicao; 2) Tiver um das seguintes intenes primrias i.Manter um ou mais ALIs, ou ii.Alterar o comportamento da aplicao. Em geral, o nome das transaes de Entrada Externa possuem termos bem caractersticos, como incluir, alterar, excluir, editar, registrar, gravar, carregar, etc. Exemplo de EE: Janela que permite adicionar, excluir ou alterar registros em um arquivo lgico.

Uma sada externa (SE) um processo elementar que envia dados ou informaes de controle para fora da fronteira da aplicao e inclui processamento adicional alm daquele existente em uma consulta externa. A inteno primria de uma sada externa apresentar dados ao usurio atravs de lgica de processamento que no seja apenas recuperao de dados ou informao de controle. A lgica de processamento deve contar ao menos uma frmula matemtica ou clculo, e/ou criar dados, e/ou manter um ou mais ALIs, e/ou alterar o comportamento do sistema. O diagrama simplificado anterior mostra o processo de gerar um relatrio que sumariza todos os empregados da Aplicao de Recursos Humanos como um exemplo de Sada Externa. Um Processo Elementar deve ser classificado como Sada Externa se o mesmo tiver a inteno primria de apresentar informaes ao usurio e incluir pelo menos uma das seguintes formas de lgica de processamento: 1) Clculos matemticos so executados; 2) Um ou mais ALIs so atualizados; 3) Dados derivados so criados (exemplos: totalizaes, percentagens, mdias, etc.).

4) O comportamento da aplicao alterado. Exemplos de SE: Relatrios com totalizao de dados; Relatrios que tambm atualizao arquivos; Consultas com clculos ou apresentao de dados derivados; E outros...

Uma consulta externa (CE) um processo elementar que envia dados ou informaes de controle para fora da fronteira da aplicao. A inteno primria de uma consulta externa apresentar dados ao usurio atravs de recuperao de dados ou informao de controle. A lgica de processamento no contm frmula matemtica, nem clculo, nem cria dados derivados. Nenhum ALI mantido durante o processamento, nem o comportamento do sistema alterado. O diagrama simplificado anterior mostra o processo de solicitar dados de empregado como um exemplo de Consulta Externa. Um Processo Elementar deve ser classificado como Consulta Externa se o mesmo tiver a inteno primria de apresentar informaes ao usurio e: 1) Referenciar uma funo de dados para recuperar dados ou informaes de controle; 2) No satisfizer os critrios para ser classificado como uma SE. Exemplos de CE: Drop-Downs, desde que recuperem dados de arquivos lgicos dinamicamente. Drop-Downs estticos no so considerados. Menus gerados dinamicamente de acordo com alguma configurao da aplicao.

A Tabela a seguir apresenta um resumo do relacionamento entre a inteno primria e o tipo de funo de transao.

3) Contar os ALRs - Arquivos Lgicos Referenciados e DERs Referenciados;

- Dados Elementares

Para cada funo de transao, um ALR deve ser contado para cada funo de dados (ALI ou AIE) nica que for acessada (lida e/ou gravada) pela funo de transao. Podem ser ALIs que so lidos/gravados pela aplicao ou AIEs que so lidos de outra aplicao. Alm disso, a fim de contar DERs para uma funo de transao, as seguintes atividades devem ser executadas a) Revisar tudo o que atravesse (entre e/ou saia) a fronteira, b) Contar um DER para cada atributo nico, reconhecido pelo usurio e no repetido que atravesse (entre e/ou saia) a fronteira durante o processamento da funo de transao, Exemplo: para atualizar um Cliente, o usurio deve fornecer o seu nome e CPF (dois DERs). 4) Determinar a complexidade funcional de cada funo de transao; A complexidade funcional de cada funo de transao ser determinada utilizando-se o nmero de ALRs e DERs, em conformidade com as tabelas a seguir:

5) Determinar o tamanho funcional de cada funo de transao; O tamanho funcional de cada funo de transao ser determinado utilizando-se o tipo e a complexidade funcional, de acordo com a tabela a seguir:

5.5 Calcular o tamanho funcional

A frmula para calcular a contagem final de pontos de funo depende do tipo de contagem. O tamanho funcional de um projeto de desenvolvimento dever ser calculado utilizando-se a Frmula: DFP = ADD + CFP* Onde, DFP a contagem de pontos de funo do projeto de desenvolvimento; ADD o tamanho das funes a serem entregues ao usurio pelo projeto de desenvolvimento; CFP o tamanho da funcionalidade de converso.

* So funes construdas e entregues pelo projeto (de desenvolvimento ou melhoria) para serem usadas no momento da instalao do projeto para converter dados ou fornecer outros requisitos de converso especificados pelo usurio, como relatrios de verificao da converso. A caracterstica destas funes que elas so descartadas aps o seu uso, no fazendo parte da aplicao aps sua instalao. Quando o sistema entra em operao, essas funes no so mais necessrias. Talvez um nome melhor para essas funes fosse "funes de transio". Funes de converso no so tcnicas. So realizadas a partir do ponto de vista do usurio. Por exemplo, a migrao de plataforma tecnolgica no contada como uma funo de converso. Exemplo: ao instalar uma nova aplicao de RH, o usurio precisa que dados sejam migrados de uma outra aplicao legada e populados na nova aplicao.

O tamanho funcional de uma aplicao, medido aps o projeto de desenvolvimento, ou a qualquer tempo no ciclo de vida da aplicao dever ser calculado utilizando-se a frmula a seguir: AFP = ADD Onde, AFP a contagem de pontos de funo da aplicao; ADD o tamanho das funes a serem entregues ao usurio pelo projeto de desenvolvimento (excludo o tamanho de qualquer funcionalidade de converso), ou a funcionalidade existente no momento da contagem da aplicao.

O tamanho funcional de um projeto de melhoria dever ser calculado utilizando-se a frmula a seguir: EFP = ADD + CHGA + CFP + DEL Onde, EFP a contagem de pontos de funo do projeto de melhoria; ADD o tamanho das funes includas pelo projeto de melhoria; CHGA o tamanho das funes alteradas pelo projeto de melhoria conforme as mesmas esto / estaro aps a implementao; CFP o tamanho da funcionalidade de converso; DEL o tamanho das funes excludas pelo projeto de melhoria.

Observaes sobre o Fator de Ajuste: para adequar-se norma ISO 14143 (medio do tamanho funcional), o IFPUG tornou o fator de ajuste opcional na apli cao da tcnica de anlise de pontos de funo. Mesmo antes disso, vrios usurios da APF j no utilizavam o fator de ajuste. O propsito do fator de ajuste medir requisitos gerais da aplicao (no funcionais). Ele ajusta os pontos de funo em + ou 35% de acordo com a influncia de 14 caractersticas gerais.

5.6 Documentar a contagem de pontos de funo

Nem sempre o que interessa na contagem de pontos de funo apenas o nmero final que reflete o tamanho medido. No basta entregar ao cliente o nmero final da medio (ou estimativa). preciso que junto seja entregue tambm toda a memria de clculo do processo de anlise que resultou naquele nmero. Caso contrrio, quem recebe a medio no tem como conferir se o resultado est correto ou no. Dessa forma, muito comum que a medio seja entregue com a planilha de contagem final, permitindo que todo processo de anlise seja verificado. As vantagens disso so as seguintes:

Agrega valor e confiabilidade medio; Facilita um eventual processo de auditoria Minimiza os erros do analista responsvel pela medio.

O nvel de documentao deve estar alinhado ao propsito da contagem. Por exemplo, se o propsito for estimar uma ordem de grandeza de custo para o projeto, qual o sentido de detalhar ao mximo a medio? importante lembrar que um dos objetivos fundamentais da medio ser simples. Logo, o nvel de documentao deve ser bem dosado para que equilibre o esforo a ser gasto na medio e a necessidade de informao que lhe agregue valor. Lembre-se que uma medio mais detalhada implica mais tempo e custo para esta atividade. Assim, apesar do nvel de documentao ser previamente acordado entre as partes interessadas na medio, no mnimo, a contagem de pontos de funo deve ser documentada como segue: O propsito e o tipo da contagem; O escopo da contagem e a fronteira da aplicao; A data da contagem; Uma lista de todas as funes de dados e de transao, incluindo o respectivo tipo e complexidade, bem como o nmero de pontos de funo atribudo a cada uma; O resultado da contagem; Quaisquer suposies feitas e questes resolvidas.

Alm de outras informaes opcionais...

5.7 Reportar o resultado da contagem de pontos de funo

A prtica de reportar consistentemente os resultados das contagens de pontos de funo permitir que os leitores identifiquem o padro com o qual as mesmas mantm conformidade. Os resultados que mantenham conformidade com este Padro Internacional devero ser reportados como segue: S FP (IFPUG IS) Onde, S o resultado da contagem de pontos de funo; FP a unidade de tamanho do mtodo FSM do IFPUG; IS este Padro Internacional (ISO/IEC 20926:200x).

EXEMPLO 250 FP (IFPUG-ISO/IEC 20926:200x) Os resultados que mantiverem conformidade com uma customizao local deste Padro Internacional devero ser reportados como: S FP (IFPUG ISc)

Onde, c representa um ou mais caracteres indicando que o resultado no mantm conformidade plena com este Padro Internacional. EXEMPLO 250 FP (IFPUGISO/IEC 20926:200x a)

6.

Fator de Ajuste

No clculo de Pontos de Funo brutos, ou no ajustados, NO so considerados aspectos tcnicos ou baseados em requisitos no funcionais. Mesmo assim, sabido que existem fatores no funcionais que afetam o tamanho da aplicao. O Fator de Ajuste uma tentativa de compensar ou ajustar alguns pontos de funo na aplicao baseado em Caractersticas Gerais do Sistema que tentam refletir a complexidade do sistema. Estas caractersticas gerais afetam a aplicao como um todo e podem modificar a contagem de acordo com diversos nveis de influncia. importante lembrar que o IFPUG no submeteu o Fator de Ajuste para fins de conformidade ao processo de medio previsto pela norma ISO 14143 No obstante, ele ainda faz parte do Manual de Contagem como um apndice e suas regras ainda so cobradas na prova de certificao. Mesmo assim, a tendncia a de extino do fator de ajuste no futuro prximo (a ser explicado mais frente). As 14 caractersticas gerais do sistema so: 1. Comunicao de Dados 2. Processamento Distribudo 3. Performance 4. Configurao Intensamente Utilizada 5. Volume de Transaes 6. Entrada de Dados On-Line 7. Eficincia do Usurio Final 8. Atualizao On-Line 9. Processamento Complexo 10. Reusabilidade 11. Facilidade de Instalao 12. Facilidade de Operao 13. Mltiplos Locais 14. Facilidade de Mudana Com base nos requisitos estabelecidos pelo usurio, cada caracterstica geral do sistema (CGS) deve ser avaliada em termos de seus nveis de influncia (NI) em uma escala de 0 a 5.

Para diminuir a subjetividade, cada uma das descries das caractersticas gerais do sistema seguintes inclui diretrizes para a determinao do nvel de influncia. Cada diretriz contm uma definio da CGS, regras para determinao do nvel de influncia e, em situaes nas quais a regra requer esclarecimento adicional, so fornecidas dicas para ajudar a aplicar as regras consistentemente em todas as plataformas. No se pretende que as dicas cubram todas as situaes. Ao invs disso, a inteno que as mesmas forneam orientao adicional para a determinao do nvel de influncia apropriado. Exemplo (CGS 06): A caracterstica Entrada de Dados On-line descreve os nveis segundo os quais os dados so informados ou recuperados atravs das transaes interativas. Interfaces on-line com o usurio para entrada de dados, funes de controle, relatrios e consultas so fornecidos pela aplicao. 0. Todas as transaes so processadas de modo batch 1. 1% a 7% das transaes so interativas 2. 8% a 15% das transaes so interativas 3. 16% a 23% das transaes so interativas 4. 24% a 30% das transaes so interativas 5. Mais de 30% das transaes so interativas Neste caso, para a realidade das aplicaes atuais, a grande maioria delas pontuar com 5. Percebe-se aqui uma grande defasagem nas diretrizes do IFPUG com a realidade atual. Determinados os nveis de influncia das 14 caractersticas gerais, o fator de ajuste calculado com a seguinte frmula: VAF = (TDI x 0,01) + 0,65 Onde TDI o somatrio dos nveis de influncia das caractersticas gerais (pode chegar a 70). Sendo assim, o fator de ajuste pode resultar numa variao de mais ou menos 35% na contagem de pontos de funo. Crticas ao Fator de Ajuste

Mesmo antes do Fator de Ajuste se tornar opcional, poucos usurios utilizavam-no. Algumas razes levaram a isso 1. A grande subjetividade na interpretao das CGS. Por exemplo, a CGS 07 lida com facilidade de uso do sistema por parte do usurio. difcil determinar isso objetivamente, mesmo com diretrizes. 2. A constatao que algumas CGSs esto desatualizadas. Como o caso, claramente, da CGS 06. 3. Apesar de serem subjetivas, podem afetar significativamente a contagem. Uma pequena diferena de interpretao pode fazer com que sua contagem seja bastante modificada. Basta lembrar que cada mudana no nvel de influncia afeta o tamanho final em 1%. 4. No apropriado que todas as CGSs possuam o mesmo peso para nvel de influncia, nem que o limite mximo de uma caracterstica seja 5%. Por exemplo, para determinados projetos, Reusabilidade pode ter um impacto muito maior do que 5%. 5. Existem requisitos importantes que no so contemplados por nenhuma das 14 CGSs. Por exemplo, voc at encontra itens relacionados a Segurana da Informao na CGS 09, mas de maneira insuficiente, muito superficial.