ANLISE DE PONTOS DE FUNO

RENATA GARCIA OLIVEIRA

Universidade Cndido Mendes UCM Rio de Janeiro Abril/2012

ANLISE DE PONTOS DE FUNO

RENATA GARCIA OLIVEIRA

Trabalho de Concluso de Curso apresentado como requisitos para a concluso do curso de Ps-graduao em Gesto de Tecnologia da Informao e da Comunicao da Universidade Cndido Mendes.

Frederico Sauer, D.Sc. Orientador

Universidade Cndido Mendes UCM Rio de Janeiro Abril/2012

ii

Sumrio

Introduo 1.1 Benefcios no uso de Estimativa de Projeto 1.2 Necessidade das Estimativas no Governo Federal 1.3 Tcnicas de Estimativa de Tamanho 1.4 Contribuio e Estrutura do Trabalho Anlise de Ponto de Funo 2.1 Processo de Contagem 2.1.1 Contribuio de Arquivos Determinao da Complexidade Determinao da Contribuio 2.1.2 Contribuio de Transaes Determinao da Complexidade Determinao da Contribuio 2.2 Contagem de Ponto de Funo No-Ajustado 2.3 Contagem de Ponto de Funo Ajustado 2.3.1 Determinao do Nvel de Inuncia Comunicao de Dados Processamento Distribudo Performance Congurao Altamente Utilizada Volume de Transaes Entrada de Dados On-Line Ecincia do Usurio Final Atualizao On-Line Complexidade de Processamento Reusabilidade Facilidade de Instalao Facilidade de Operao Mltiplos Locais Facilidade de Mudana 2.4 Determinao dos Pontos de Funo Ajustados para diferentes tipos de Projeto 2.4.1 Clculo de Pontos de Funo Ajustado para um projeto de desenvolvimento 2.4.2 Clculo de Pontos de Funo Ajustado para um projeto de Manuteno/Melhoria 2.4.3 Clculo de Pontos de Funo para uma aplicao 2.4.4 Consideraes Estudo de Caso 3.1 Descrio do Sistema Escopo da Contagem iii

1 3 4 5 7 8 10 12 12 13 13 14 15 15 15 16 16 17 17 17 18 18 18 18 19 19 19 19 20 20 21 21 21 22 23 24 24 24

4 5

Aplicaes em Contratos do Governo Concluso

iv 29 33 34 35 42

Referncias Bibliogrcas Apndice A: AutoSys Contagem de Aplicao Apndice B: AutoSys Resultado da Contagem

LISTA DE FIGURAS

1.1 1.2 2.1 2.2 3.1 3.2

Resultado Tpico de Projeto. Evoluo do Gerenciamento de Projetos de 2004, 2006 e 2009. Variao do tamanho do projeto ao longo do seu ciclo de vida. Elementos de contagem de pontos funo. Resultado da Anlise de Ponto de Funo No Ajustado. Resultado do clculo do valor de ajuste.

1 2 9 10 27 28

LISTA DE TABELAS

2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 4.1

Fases do ciclo de vida vs possibilidade de medies. Tabela de complexidade funcional dos ALI e AIE. Tabela de contribuio das funes de dados. Tabela de complexidade das EE. Tabela de complexidade das SE e CE. Tabela de contribuio das funes do tipo transao. Tabela com as 14 caractersticas gerais do sistema. Identicao das Funes do Sistema AutoSys Identicao dos requisitos de dados do AutoSys Tabela ilustrando as contrataes atuais de fbrica de software pelos rgos Pblicos.

8 12 13 14 14 15 16 24 25 30

vi

CAPTULO I Introduo

No se consegue controlar o que no se consegue medir Tom DeMarco O projeto de desenvolvimento de software sempre apresentou desaos com relao ao cumprimento de cronograma e custos. Como mencionado por [McConnell, 1996], dois teros de todos os projetos atrasam, consideravelmente, suas estimativas. Na mdia, um projeto grande ultrapassa o prazo de 25-50%, sendo que o tamanho mdio do atraso aumenta com o tamanho do projeto. Um planejamento pouco preciso atinge diretamente os custos e a competitividade da organizao. Ao dimensionar um esforo menor do que o necessrio, ocorre a elevao dos custos. J ao dimensionar um esforo maior, elevando desmedidamente o lucro, corre-se o risco de perder espao no mercado para a concorrncia. Na tentativa de resolver este trade-off pode-se comprometer a qualidade do produto entregue ao cliente. Os efeitos de subestimar o esforo do projeto envolve a construo de um cronograma apertado para o que o projeto exige. Consequentemente, ocorre a diminuio do esforo de garantia de qualidade, necessidade de pessoal no meio do desenvolvimento do projeto, a frustrao da equipe ao falhar no atendimento do prazo e a perda de credibilidade com deadlines futuros.

Figura 1.1: Resultado Tpico de Projeto. J os efeitos de superestimar, alm de inuir na capacidade de concorrncia da empresa no mercado, tambm pode recair na Lei de Parkinson [Construx Software Inc., 2011]. Essa lei diz que o trabalho se expande para preencher o tempo disponvel para ser concludo, ou seja, a equipe de um projeto utilizar tanto tempo quanto for disponibilizado.

2 De acordo com [Construx Software Inc., 2011] umas das principais causas de atraso do projeto a expectativas irrealista, ou seja, estimativas imprecisas. Uma estimativa de tamanho/esforo eciente uma das atividades mais difceis no desenvolvimento de software e uma das mais importantes. Dentre as outras causas apontadas esto requisitos sem clareza ou mudanas de requisitos, um planejamento ou gerenciamento de projeto supercial, problemas de qualidade no controlados. A Figura 1.1 apresenta que mais da metade dos projetos analisados atrasam ou so cancelados. Nessa pesquisa, realizada pela Standish Group Survey, apenas 26% dos projetos cumpriram seus prazos. J a Figura 1.2 apresenta a evoluo dos projetos que falharam, que sofreram mudanas e tiveram sucesso nos anos de 2004, 2006 e 2009.

Figura 1.2: Evoluo do Gerenciamento de Projetos de 2004, 2006 e 2009. Segundo [Sommerville, 2004], no h nenhuma maneira simples de fazer uma estimativa precisa do esforo necessrio para desenvolver um sistema de software. Isso porque as primeiras estimativas so baseadas em informaes insucientes em uma denio de requisitos do usurio. Alm disso, o software pode rodar em computadores desconhecidos ou utilizando novas tecnologias e as pessoas do projeto podem ser desconhecidos. Por conta das diculdades em precisar o tamanho, recursos e prazos, a gerao das estimativas ocorre desde o incio do projeto evoluindo at o m do projeto quando os valores passaro a ser considerados exatos. Ao longo do desenvolvimento, deve ser realizado um renamento gradual da estimativa, uma vez que, atrasos e estouros do oramento podem ocorrer durante projeto. Todo esse trabalho na estimativa de tamanho de software serve de base para responder perguntas relacionadas com o planejamento do projeto. Perguntas tais como [Vazquez et al., 2003]: Quais produtos devem ser desenvolvidos (especicao, manuais, programas, mdulos, base de dados, planos de implantao e converso etc); Por meio de que atividades (identicao de classes de objetos, preparao de cenrios de interaes tpicas, construo de modelo funcional, validao de documentao tcnica etc.); Esforo envolvido (horas/homem, homem/ms etc.); De que prossionais (analistas, implementadores, documentadores, usurios etc.); Durante quanto tempo (semanas, meses, anos etc.);

3 Quais riscos devem ser identicados e contigenciados. Nas resolues das perguntas acima, a experincia prossional contribui muito no planejamento realista. No entanto, na rea de Tecnologia da Informao, devido a velocidade do avano tecnolgico e a rotativida de pessoal parte dessa experincia perdida. Vale ressaltar que, uma mudana na tecnologia pode signicar que a experincia adquirida em estimativas anteriores no sejam teis em um novo projeto [Sommerville, 2004]. Geralmente isso acontece em projetos que pretendem quebrar paradigmas, como por exemplo, o uso de web services, a utilizao de ERP (Enterprise Resource Planning) ou sistemas de banco de dados centralizado, uso de software de COTS (Commercial off-the-shelf ), desenvolvimento para e com reutilizao, uso de novas ferramentas CASE (Computer-Aided Software Engineering) e geradores de programa. Para o planejamento da gesto, mtricas secundrias de medio podem ser utilizadas, tais como, informaes de esforo, prazo e custo. Essas mtricas servem para compor um relatrio com a situao do projeto, seu progresso atual e as expectativas quanto sua situao futura. Contribuem para permitir uma rpida identicao e correo de problemas [Vazquez et al., 2003]. Outras mtricas complementares tambm podem ser utilizadas no auxlio do planejamento e gerenciamento do projeto. Tcnicas que objetivam ponderar o efeito de outros fatores como anlise de riscos e determinao de marcos de projeto (milestone) [Vazquez et al., 2003].

1.1

Benefcios no uso de Estimativa de Projeto

Essa seo se preocupa em apresentar de forma sucinta os benefcios na utilizao da Estimativa de Projeto. Apresentando as vantagens em seu uso, que como j foi dito, possibilita o auxlio em: Maior preciso do planejamento ao longo do tempo; Estimativas de esforo, prazo e custo: obteno atravs da gerao indireta das mtricas (mtricas secundrias); Acompanhamento do projeto: uso de relatrio com a situao do projeto, seu progresso atual e as expectativas quanto sua situao futura. Permitindo uma rpida identicao e correo de problemas; e Relacionamento com o cliente: maior visibilidade e controlabilidade do status do projeto. Segundo anlises baseadas em pontos de funo de [Behrens, 1983], o tamanho do projeto e o ambiente utilizado em sua construo so claramente os aspectos mais importantes na determinao da produtividade do projeto. Assim, o gerente de projetos deve se esforar para segmentar projetos (uso de construo em sub-mdulos e/ou sub-sistemas e uso de baselines) assumindo que no h adio sobre o total de pontos de funo. Pode, tambm, ser feita uma anlise baseada em pontos de funo para balizar um incentivo econmico na automatizao de ferramentas do ambiente de desenvolvimento. Na tentativa de elevar o nvel de qualidade dos produtos, organizaes comearam a implantar o uso de processos de software. [Andrade and Oliveira] arma que no adianta o uso de

4 processos de software se a organizao no atende o cumprimento de cronogramas e o custo efetivo de seus projetos. Todas essas caractersticas dependem de um gerenciamento adequado e um plano efetivo do projeto baseado em estimativas mais precisas de tamanho. Ao perceber os benefcios o Governo Federal iniciou uma campanha para utilizao da estimativa de software. Essa campanha visa aumentar o valor agregado do software para o usurio, conforme apresentado na seo seguinte.

1.2

Necessidade das Estimativas no Governo Federal

Na contratao de bens e servios de TI essencial a adoo de processo de trabalho formalizado, padronizado e judicioso quanto ao custo, oportunidade e aos benefcios advindos para a organizao. Esse processo melhora o relacionamento com os fornecedores e prestadores de servios, maximiza a utilizao dos recursos nanceiros alocados rea de TI e contribui decisivamente para que os servios de TI dem o necessrio suporte s aes da organizao no alcance de seus objetivos e suas metas. (Acrdo 1.603/2008-TCU-Plenrio)

O Processo de Contratao de TI do Governo Federal requer uma gesto de sistema de informao capaz de uniformizar os procedimentos, medir o desempenho da rea de TI, mitigar os riscos inerentes, gerenciar e controlar as iniciativas de TI nas organizaes para garantir a adoo de melhorias nos processos organizacionais. Para a gesto, segundo o item 9.4 do Acrdo 786/2006-TCU-Plenrio, tambm recomendado incluir: Fixao dos procedimentos e dos critrios de mensurao dos servios prestados, abrangendo mtricas, indicadores, valores aceitveis; Quanticao ou a estimativa prvia do volume de servios demandados, para ns de comparao e controle; Denio de metodologia de avaliao da adequao s especicaes e da qualidade dos servios com vistas aceitao e pagamento; Utilizao de um instrumento de controle, geralmente consolidado no documento denominado ordem de servio ou solicitao de servio; Denio dos procedimentos de acompanhamento e scalizao a serem realizados concomitantemente execuo para evitar distores na aplicao dos critrios; O modelo antigo de contratao de TI, apresentava a desvantagem de pagamento por homemhora (HH). Isso aumentava o risco de remunerao de horas improdutivas. Podendo resultar em uma onerao indevidamente do contrato. (Vide Acrdo 786/2006-TCU-Plenrio). J a contratao de prestao de servios (mensurados pelo resultado) mais vantajosa para o rgo ou entidade contratante, porque permite que a remunerao da contratada se d com base na entrega do produto requerido. Para o novo modelo de contratao, as tcnicas de estimativa de tamanho funcional do sistema se apresentam como ferramenta ideal para mensurao de servios prestados, uso de

5 mtricas, de indicadores tal como citado no item 9.4 do Acrdo 786/2006-TCU-Plenrio e conforme Instruo Normativa 04 (IN/SLTI 04/2012). A IN/SLTI 04/2012, que cuida da contratao de bens e servios da rea de TI, prev, em seu art.17, que o Projeto Bsico dever conter, dentre outras, as seguintes informaes de: denio do objeto; requisitos do servio; elementos para gesto do contrato (mtricas); e estimativa de preos. Deve-se ressaltar que a Instruo Normativa - IN04, associada ao processo de contratao de servios de Tecnologia da Informao pela Administrao Pblica Federal direta, autrquica e fundacional, publicada pela Secretaria de Logstica e Tecnologia da Informao (SLTI) do Ministrio do Planejamento Oramento e Gesto (MPOG) de 2010, preconiza a utilizao de mtricas em contratos de fbrica de software , e ainda destaca que a aferio de esforo por meio da mtrica homem-hora apenas poder ser utilizada mediante justicativa e sempre vinculada entrega de produtos de acordo com prazos e qualidade previamente denidos. Alm disso, realizar uma contrao atravs de Pontos de Funo, cria um meio-termo entre um contrato Fixed-Price (preo global ou preo total) e Time-Material (preo unitrio). Segundo o PMI, um contrato Fixed-Price s eciente quando o escopo est bem denido"e um contrato Time-Material eciente quando no h um escopo denido e o contrato de curta durao. Um contrato utilizando Pontos de Funo possui caractersticas de ambos. A quantidade de software" denida de forma xa, por um custo previamente acertado (como Fixed-Price). Cobra-se por unidade de trabalho realizado (como Time-Material) Segue na prxima seo, algumas tcnicas de estimativa de tamanhos conhecidas.

1.3

Tcnicas de Estimativa de Tamanho

Abaixo so apresentadas conhecidas tcnicas utilizadas na estimativa de tamanho de funo. Anlise de Pontos de Funo: um mtodo para medir o tamanho funcional do Software. A anlise de ponto de funo foi criada em 1979 por Alan Albrecht nos laboratrios da IBM, e um dos mtodos de mensurao de software mais utilizados no mundo. O padro mantido pela IFPUG (International Function Point Users Groups) que publica o Counting Practices Manual (Manual de Prticas de Contagem).[Sommerville, 2004]. Modelagem algortmica de custos: Um modelo desenvolvido usando informaes histricas de custos que relacionam alguma mtrica de software (geralmente, seu tamanho) aos custos de projeto. feita uma estimativa dessa mtrica e o modelo prev o esforo necessrio [Sommerville, 2004]. Anlise de Pontos por Casos de Uso: foi proposta por Gustav Karner (1993) com o propsito de medir o tamanho funcional de projetos de software orientados a objeto, modelados por meio de especicao de Casos de Uso. Sendo especca para projetos em caso de uso, pode resultar no problema da normalizao dos casos, uma vez que no h um nico padro de escrita. Resultando em diferentes estilos na especicao de um caso de uso e em diferentes granularidades. Julgamento de especialista: Vrios especialistas nas tcnicas de desenvolvimento de software propostas e no domnio da aplicao so consultados. Cada um deles estima o custo do projeto. Essas estimativas so comparadas e discutidas. O processo de estimativa

6 prossegue iterativamente at que seja atingida uma estimativa em comum.[Sommerville, 2004] Estimativa por analogia: Essa tcnica aplicvel quando outros projetos do mesmo domnio de aplicao foram concludos. O custo de um novo projeto pode ser estimado por analogia com esses projetos concludos.[Sommerville, 2004] A Lei de Parkinson: A Lei de Parkinson estabelece que o trabalho se expande para preencher o tempo disponvel. O custo determinado pelos recursos disponveis e no pela avaliao objetiva. Se o software deve ser entregue em 12 meses e 5 pessoas esto disponveis, o esforo necessrio estimado em 60 pessoas-ms. [Sommerville, 2004] Atribuio de preo para ganhar: O custo do software estimado para ser o que o cliente tiver disponvel para gastar no projeto. O esforo estimado depende do oramento do cliente, e no da funcionalidade do software. [Sommerville, 2004] LOC (lines of code): a unidade mais intuitiva como medida de tamanho a quantidade de linhas de cdigo. A aparente facilidade do uso de LOC perigosa, devido a falta de padronizao, falta de signicado para os usurios do objeto de medio, diculdade de aplicao nas fases iniciais do ciclo de vida e dependncia da linguagem de programao utilizada. Atualmente so cinco os mtodos padro de medio de tamanho funcional de software: ISO/IEC 14143-1:2007 Medio do Tamanho Funcional: dene o conceito de Medio do Tamanho Funcional (FSM - Functional Size Measurement). A concepo da medio do tamanho funcional (FSM) foi projetada para superar as limitaes dos mtodos anteriores de dimensionamento de software ao desviar o foco de como o software implementado para mensurar em termos das funes requeridas pelo usurio. IFPUG CPM 4.3.1:2010 (Counting Practices Manual, ISO/IEC 20926:2009 mais usada na Amrica): especica um conjunto de denies, regras e passos para aplicar o mtodo de medio do tamanho funcional IFPUG FSM (International Function Point Users Group Functional Size Measurement Method). A ISO/IEC 20926:2009 est em conformidade com todas as disposies obrigatrias da ISO/IEC 14143-1:2007. NESMA CPM 2.1 (ISO/IEC 24570:2005 mais usada na Europa): especica um mtodo de medida do tamanho funcional do software, fornecendo um manual de como determinar o tamanho dos componentes de software. Especica como calcular este tamanho, alm de fornecer manuais de aplicao. Mark II (ou MK II) CPM 1.3.1 (ISO/IEC 20968:2002): especica um conjunto de denies, convenes e atividades do mtodo de medio do tamanho funcional MkII. O mtodo pode ser utilizado para medir o tamanho funcional de qualquer software que possa ser descrito em termos de transaes lgicas (entrada, processo e sada). As regras de tamanho foram especicadas para domnio de aplicaes de sistemas de informao empresariais, tendendo a considerar caractersticas de storage e recuperao de dados. No obstante, o mtodo pode ser aplicado a outros domnios, considerando que contribuies de algoritmos complexos e requisitos de tempo real no sero computados.

7 COSMIC-FFP Measurement Manual 2.2 (ISO/IEC 19761:2011): especica um conjunto de denies, convenes e atividades do mtodo de medio do tamanho funcional. aplicvel aos domnios de sistemas de aplicao, tempo real ou uma composio dos dois. A ISO/IEC 19761:2011 no foi especicada para realizar medies de parte de software, tal como algoritmos complexos, ou funes de softwares especialistas, como simuladores, sistemas inteligentes, sistemas de previso do tempo ou processamentos de vdeo e audio. FISMA 1.1 (ISO/IEC 29881:2010): O ISO/IEC 29881:2010 especica um conjunto de denies, convenes e atividades para medir tamanho funcional de parte ou todo do software utilizando FiSMA 1.1. Visando o uso por pessoas envolvidas na aquisio, desenvolvimento, uso, suporte, manuteno, e auditoria de software. FiSMA baseado em um avaliao dos requisitos funcionais dos usurios, calculando o tamanho do software a partir da perspectiva do usurio.

1.4

Contribuio e Estrutura do Trabalho

Este trabalho visa contribuir com o uso de estimativa de tamanho de projeto de software de forma a garantir um melhor cumprimento de cronograma e custo do projeto. Esses objetivos so buscados como foco para a garantia de melhor qualidade do produto. Abaixo segue a estrutura de organizao deste trabalho. Captulo 1: feita uma introduo mostrando a importncia do uso de estimativa de tamanho; Captulo 2: neste captulo apresentado os conceitos bsicos sobre Anlise de Pontos de Funo; Captulo 3: um estudo de caso apresentado junto com a sua Anlise por Pontos de Funo visando a demonstrao da tcnica; Captulo 4: feito um pequeno estudo mostrando o uso de estimativa de tamanho pelo Governo Federal, sendo a tcnica mais utilizada a de Anlise de Ponto de Funo. Captulo 5: as concluses so explicitadas, tambm proposto pontos para melhorias e futuros trabalhos;

CAPTULO II Anlise de Ponto de Funo

A Anlise de Pontos de Funo (APF) um mtodo padro para medir sistemas do ponto de vista de seus usurios pela quanticao da funcionalidade solicitada e fornecida. Ponto de Funo a unidade de medida desta tcnica que tem por objetivo tornar a medio independente da tecnologia utilizada para a construo do software. Ou seja, a APF busca medir o que o software faz, e no como ele foi construdo. [Vazquez et al., 2003]. Um dos principais objetivos da anlise de Pontos de Funo (PF) avaliar o tamanho das capacidades/funes de um sistema do ponto de vista do usurio. Assim, a anlise baseia-se na interao do usurio com o sistema informatizado. Alm disso, ela permite que a estimativa de tamanho seja feita em qualquer fase do ciclo de vida do projeto conforme ilustrado na Tabela 2.1. Tabela 2.1: Fases do ciclo de vida vs possibilidade de medies.

Anlise de Ponto de Funo extremamente til em estimativas de projetos, gerenciamento de mudana de escopo, medio de produtividade e comunicao dos requisitos funcionais. A Figura 2.1 exemplica o gerenciamento da mudana de requisitos. Quando as vrias medies estimadas ao longo do ciclo de vida so analisadas entre si, pode-se obter um ndice de percentual de crescimento funcional entre as diversas etapas. Isso possibilita o ajuste renado de estimativa j na fase inicial de novos projetos. Com base na quantidade de pontos de funo e em indicadores como produtividade (PF/HM), o custo ($/PF) e indicadores de qualidade (Defeitos/PF), possvel extrapolar essas informaes que de outra forma seriam inacessveis ou de difcil apurao ou justicativa. Com base nesses indicadores possvel avaliar a performance interna em termos de QUANTO se pode produzir por unidade de tempo ou custo. Simplicando, se sabido o QUANTO se deve produzir, pode-se extrapolar quais sero o custo, prazo e esforo envolvido nesse trabalho. [Vazquez et al., 2003].

Figura 2.1: Variao do tamanho do projeto ao longo do seu ciclo de vida.

As vantagens de utilizar ponto de funo so [Ribeiro, 2001]: Independncia de tecnologia; Unidade de medida padro para software; Tcnica de estimativa de software; Ser simples; Se consistente e intercambivel; Ser compreensvel por no-tcnicos; Utilizvel desde o incio do sistema. Os benefcios no uso de ponto de funo: Uma tcnica que permite dimensionar o tamanho de um software a ser adquirido pela instituio; Uma tcnica para estimativas de custo e recursos para o desenvolvimento e manuteno de softwares; Suporte a anlise de produtividade e qualidade entre projetos com mesma metodologia de desenvolvimento, seja diretamente ou em conjunto com outras mtricas como esforo, defeito e custos; Um fator de normalizao para comparao de software; Implantao de um programa de mtricas; Ferramenta de auxlio gerencial nas reas, por exemplo, de gerenciamento de escopo e mudanas de requisitos; Ferramenta utilizada para fundamentar a negociao de contratos; Formar baseline para estimativas; Melhorar gerncia de projetos e relacionamentos com clientes; Entender e aperfeioar o processo.

10

2.1

Processo de Contagem

Os tipos de contagem de projeto se divide em trs, sendo eles de projeto de desenvolvimento, projeto de manuteno e aplicao. Esta monograa focar na contagem de projeto de desenvolvimento. Segue abaixo a explicao de cada um: Projeto de Desenvolvimento: mede as funcionalidades fornecidas aos usurios nais aps a primeira entrega do projeto; Projeto de Manuteno: mede as funcionalidades adicionadas, modicadas ou excludas do sistema pelo projeto, e tambm as eventuais funes de converso de dados; Aplicao: mede as atuais funcionalidades fornecidas aos usurios por uma aplicao j instalada. Esta contagem tambm realizada ao trmino de um projeto de desenvolvimento ou manuteno, gerando os pontos de funo da aplicao entregue. Ao iniciar o processo de medio funcional, um passo bastante importante o de denio da fronteira da aplicao e do escopo da contagem. A fronteira da aplicao dene um limite conceitual de comunicao do software com o mundo exterior (seus usurios). J o escopo dene a funcionalidade que ser includa em uma contagem particular. A Fronteira da Aplicao representa uma membrana atravs da qual os dados passam de fora para dentro da aplicao. Ela encapsula a lgica de manuteno dos dados da aplicao, auxilia na identicao dos dados lgicos referenciados, mas no mantidos dentro da aplicao. Dependente da viso externa de negcios do usurio, independente de consideraes tcnicas e/ou de implementao. O Escopo um conjunto ou subconjunto de software de tamanho conhecido. Por ser determinado pelo propsito da contagem, identica quais funes sero includas na contagem de pontos de funo, podendo incluir uma ou mais de uma aplicao. Alm disso, deve ser considerado tambm os tipos de funes e tipos de dados. Partindo do ponto de vista de um usurio, existem cinco funes bsicas dentro de um programa. Dessas funes, duas abordam os requisitos de dados de um usurio nal e so referidas como funes de dados. As outras atendem as necessidades do usurio para acesso a dados e so referidas como funes transacionais. Os 5 (cinco) componentes de Pontos de Funo apresentados na Figura 2.2:

Figura 2.2: Elementos de contagem de pontos funo.

11 Funo de Dados Arquivos Lgicos Internos Arquivos de Interface Externa Funo Transacional Entrada Externa Sada Externa Consulta Externa Os Arquivos Lgicos Internos (ALI) representam os dados que so mantidos na fronteira do sistema. J os Arquivos de Interface Externa (AIE) representa os dados que sero referenciados pelo sistema sem que o mesmo seja responsvel pela sua manuteno. Ou seja, o AIE deve ser obrigatoriamente um ALI de outra aplicao. Por exemplo, um piloto insere dados de navegao atravs de um display no cockpit antes da partida. Os dados so armazenados no sistema e podem ser modicados, sendo de responsabilidade do piloto as informaes inseridas ali. Este um exemplo de ALI. J se um piloto utilizar os dados de navegao oriundos de um GPS, ele deixa de ter a responsabilidade pela atualizao da informao, devendo, no entanto, fazer a referncia dos dados de navegao durante o voo. Neste caso, como os dados esto sendo usados somente como referncia, eles so uma AIE. As demais funes acessam os dados contidos no ALI e AIE e so conhecidas como funo transacional. So chamadas de Entrada Externa, Sada Externa e Consulta Externa. A Entrada Externa permite ao usurio manter Arquivos Lgicos Internos (ALI) atravs da capacidade de adicionar, alterar e excluir os dados. J a Sada Externa permite que o usurio produza resultados. Por exemplo, ao adicionar, alterar e excluir informaes de navegao, o piloto est utilizando a transao referida como uma Entrada Externa (EE). J quando o piloto utiliza o sistema para mostrar separadamente a velocidade de solo, velocidade do ar e velocidade do ar calibrada, ele est utilizando a transao referida como Sada Externa (SE). Isso porque os resultados apresentados so derivados de dados mantidos (velocidade da aeronave) e de dados referenciados (velocidade do ar). Por m a Consulta Externa (CE) prov a capacidade recuperar dados seguindo determinados critrios, no havendo a manipulao dos dados. Por exemplo, se um piloto exibe dados de reconhecimento do terreno sobrevoado, a sada resultante a recuperao direta de informaes armazenadas. Alm dos cinco componentes funcionais descritos acima, existe mais um passo para completar o clculo de pontos de funo. Este passo considera a determinao da complexidade funcional. Cada funo do tipo dado e transao possui um peso em PF, que determinado pela complexidade funcional que pode ser baixa, mdia ou alta. A complexidade funcional determinada com base na combinao dos agrupamentos de dados e elementos de dados de uma determinada funo. Aps a identicao e classicao de todas essas funes na contagem, o nmero de pontos de funo ser simplesmente a soma do peso de cada uma dessas funes. Nas sees seguintes, ser mostrado as matrizes nicas para cada um dos cinco componentes funcionais. O processo de contagem de pontos de funo no ajustados apresentado acima mede requisitos especcos dos usurios. Uma vez que o fator de ajuste mede requisitos gerais da

12 aplicao, o IFPUG tornou o fator de ajuste opcional visando adequao ao padro ISO/IEC 20926 de medio funcional. O valor do fator de ajuste indica a funcionalidade geral fornecida pela aplicao ao usurio. Calculado com base em 14 caractersticas gerais, produz variao de +/- 35% no tamanho do sistema. Ao nal da etapa de medio deve-se documentar o processo. O nvel de documentao depende da necessidade, uma vez que gerar tempo e custo, devendo ser previamente acordado. Um nvel baixo de detalhe pode servir para estimar a ordem de grandeza de custo do projeto. Por outro lado um alto nvel pode facilitar auditorias de medio, rastreamento das funes at os artefatos e manuteno e evoluo da medio.

2.1.1

Contribuio de Arquivos

Um arquivo se refere a um grupo de dados logicamente relacionados e reconhecido pelo usurio. Eventualmente, um arquivo no sentido da APF pode estar mapeado em um ou mais arquivos fsicos do sistema operacional ou em tabelas de banco de dados. Em outras palavras, cada entidade do modelo conceitual corresponderia a um ALI ou AIE O Arquivo de Interface Interno (ALI) um grupo de dados ou informaes de controle mantido na fronteira da aplicao. J o Arquivo de Interface Externa (AIE) um grupo de dados ou informaes de controle referenciado pela aplicao, estando conceitualmente fora da fronteira da aplicao. Exemplos de dados que no so considerados Arquivos Lgicos: arquivos de movimento (relatrios) recebidos de outra aplicao para manter um ALI. Entretanto os processos de carga e gerao desses arquivos podem ser funes do tipo transao; dados estticos; dados temporrios; arquivos introduzidos exclusivamente em funo da tecnologia utilizada. Determinao da Complexidade A determinao da complexidade funcional deve ser classicada em baixa, mdia e alta est baseada no nmero de tipos de dados (TD) e no nmero de tipos de registro (TR). A Tabela 2.2 ilustra a relao de quantidade dos tipos e complexidade funcional para ALI e AIE. Tabela 2.2: Tabela de complexidade funcional dos ALI e AIE.

13 A informao classicada em um tipo de dado (TD), ou Dado Elementar Referenciado, quando representa um nico campo, no repetido e reconhecido pelo usurio. O tipo de registro (TR), ou Registro Lgico Referenciado, um subgrupo de dados, reconhecido pelo usurio e componente de um ALI ou AIE, podendo ser opcional ou obrigatrio. Deve-se contar um TR para cada subgrupo opcional ou mandatrio do ALI ou AIE, se no existir subgrupos, conta-se o ALI ou AIE como um TR. A classicao do TR opcional e obrigatrio a generalizao de classes. Os tipos de dados de uma classe "POLIGONO", pode ter seus tipos de dados complementados por informaes como tamanho de raio e de arestas. Nesse caso, um nico arquivo lgico contado com trs tipos de registro, "POLIGONO"(TR obrigatrio) e as entidades "CIRCULO"e "HEXAGONO"(TR opcional). Determinao da Contribuio Aps a identicao dos arquivos e sua determinao de complexidade, deve-se calcular sua contribuio com base na tabela 2.3. Tabela 2.3: Tabela de contribuio das funes de dados.

Na prtica, a avaliao minuciosa da quantidade de TD ou TR mais critica quando estes nmeros esto no limite das faixas da tabela de complexidade. Alm disso a consistncia entre contagens se torna crtica quando a anlise usada na medio de contratos ou como fator de normalizao de dados coletados em iniciativas de melhoria de processos [Vazquez et al., 2003]. Um erro na avaliao dos tipos de dados afeta de forma limitada o resultado da medio. Sendo possvel ocorrer vrias interpretaes na anlise de pontos dos Arquivos, mesmo que estes se assemelhem a modelagem de dados da aplicao.

2.1.2

Contribuio de Transaes

As funes do tipo transao representam a funcionalidade provida ao usurio para o processamento de dados por uma aplicao. A transao deve ser completa e auto-contida, deixando o resultado em um estado consistente. Elas so classicadas em EE (Entrada Externa), SE (Sada Externa) e CE (Consulta Externa). Uma Entrada Externa processa dados ou informaes de controle que venha de fora da fronteira da aplicao. A inteno primria de uma EE manter um ou mais Arquivos Lgicos e/ou modicar o comportamento do sistema. No so exemplos de EE menus, telas de ltro e telas de login. A Sada Externa processa o envio de dados ou informao de controle para fora da fronteira da aplicao. No processamento lgico requerido, deve-se conter pelo menos uma frmula matemtica ou clculo, ou criar dados derivados (nesse caso, no sendo necessria a sua apresentao ao usurio). Uma SE tambm pode manter ou alterar o comportamento de um ou mais ALIs ou alterar o comportamento do sistema. No so exemplos de SE, Drop-downs (em geral so recuperaes e

14 apresentaes de dados) ou consultas e relatrios sem nenhum totalizador, que no atualizam arquivos, que no tenha dados derivados ou que no modique o comportamento do sistema. A Consulta Externa processa o envio de dados ou informao de controle para fora da fronteira da aplicao. A inteno apresentar informaes ao usurio atravs da recuperao de dados e informao de controle de um ALI ou AIE. O processamento lgico no contm nenhuma frmula matemtica ou clculo, ou cria dados derivados, o comportamento do sistema no alterado. Determinao da Complexidade A determinao da complexidade funcional deve ser classicada em baixa, mdia e alta est baseada no nmero de tipos de dados (TD) e no nmero de tipos de registro (TR). A Tabela 2.4 e 2.5 ilustra a relao de quantidade dos tipos e complexidade funcional. Tabela 2.4: Tabela de complexidade das EE.

Tabela 2.5: Tabela de complexidade das SE e CE.

Nas tabelas acima, percebe-se que no h um requisito mnimo para arquivos referenciados, no entanto uma Consulta Externa (CE), pela denio, deve referenciar ao menos um arquivo lgico. Um arquivo referenciado (AR), ou Arquivo Lgico Referenciado (ALR), um arquivo lgico interno (ALI) lido ou mantido pela funo do tipo transao. Tambm pode ser um arquivo de interface externa (AIE) lido pela funo do tipo transao. Assim, conta-se um AR para cada ALI ou AIE mantido ou lido durante o processamento. Frisando que no deve-se contar o mesmo arquivo mais de uma vez, mesmo numa situao de vrias leituras ou atualizaes. Tipo de Dado (TD), ou Dado Elementar Referenciado (DER), j foi denido no item 2.1.1. Com relao as regras de classicao, no se deve contar campos que so recuperados ou derivados pelo sistema e armazenados em um ALI se o campo no cruza a fronteira da aplicao. J para ocorrncia de erro ou conrmao que atravessa a fronteira deve-se contar um TD.

15 Determinao da Contribuio Aps a identicao dos arquivos e sua determinao de complexidade, deve-se calcular sua contribuio com base na tabela 2.6. Tabela 2.6: Tabela de contribuio das funes do tipo transao.

Na prtica, a avaliao dessas consideraes mais critica quando a quantidade de tipos de dados esto no limite das faixas da tabela de complexidade, mesmo havendo uma inconsistncia na contagem, afetaria de forma limitado o resultado nal. Um rigor maior deve ser dedicado correta identicao da quantidade de funes, pois isso produz um impacto muito mais signicativo [Vazquez et al., 2003].

2.2

Contagem de Ponto de Funo No-Ajustado

Para a contagem de Ponto de Funo No-Ajustado deve ser considerado os Arquivos e Transaes identicados na anlise e sua contribuio, conforma apresentado no clculo ??.
n i=1 o j=1 p k=1 q l =1 r m=1

ALIi Contribuicaoi

AIE j Contribuicao j EEk Contribuicaok SEl Contribuicaol

CEm Contribuicaom

A soma desses somatrios representa a contagem de ponto de funo no-ajustado (PFNA).

2.3

Contagem de Ponto de Funo Ajustado

O fator de ajuste est no Manual de Prticas de Contagem (atualmente em sua verso 4.3.1) do Grupo Internacional de Usurios de Pontos de Funo (IFPUG), sendo cobrada em provas de certicao como especialista em pontos de funo (CFPS - Certied Function Point Specialist). No entanto no faz parte do processo de medio para ns de certicao da ISO/IEC 14143:2007 (Medio de Tamanho Funcional).

16 Na anlise de pontos de funo, os requisitos funcionais so a base para o clculo dos pontos de funo e tamanho funcional de um software. Visando ir alm da medio funcional denida pela ISO/IEC 14143:2007, opta-se pela utilizao do fator de ajuste de funo. No seu escopo, alguns requisitos no funcionais so contemplados em 14 Caractersticas Gerais de Sistema (CGS) conforme apresentado na Tabela 2.7: Tabela 2.7: Tabela com as 14 caractersticas gerais do sistema.

O valor do fator de ajuste indica a funcionalidade geral fornecida pela aplicao ao usurio. O fator de ajuste baseado nas quatorze CGS, em que cada fator varia numa escala de zero (nenhuma inuncia) a cinco (grande inuncia), resultando numa variao de +/- 35% no tamanho do software. Assim, o tamanho do software ao ser ajustado pode variar entre 0,65 e 1,35. Aps a determinao dos nveis de inuncia (DI - Degres of Inuence) das 14 caractersticas gerais possvel saber o TDI (Total Degrees of Inuence - Nvel de Inuncia Geral) e o VAF (Value Adjustment Factor - Valor do Fator de Ajuste). Cada GCS inuencia 5% do valor nal da contagem e cada ponto atribudo ao nvel de inuncia varia em 1% o resultado nal.
14

T DI = DIi
i=1

VAF = 0, 65 + (T DI 0, 01) Qntd de Ponto de Funo Ajustado, PFA, PFA = PFNA VAF PFNA, Qntd de Ponto de Funo No-Ajustado, VAF, Valor do fator de ajuste.

2.3.1

Determinao do Nvel de Inuncia

O IFPUG fornece algumas diretrizes para determinao do nvel de inuncia das caracterstica geral. Essas diretrizes visa diminuir a subjetividade desta tarefa. Comunicao de Dados Descreve o grau pelo qual a aplicao comunica-se diretamente com o processador. Os dados ou informaes de controle utilizados pela aplicao so enviados ou recebidos por meio de recursos de comunicao.

17 A classicao do nvel de inuncia varia de uma aplicao puramente batch ou estao de trabalho isolada a uma aplicao que mais que um front-end, suportando mais de um tipo de protocolo de comunicao. A partir de uma pesquisa com amostras de 235 projetos de software realizado por [Lokan, 1998], podemos perceber que os projetos atuais so pontuados com 3, sendo 56% dos projetos pontuados com 4 ou 5. Aplicaes de tempo real, servidores de aplicao e middlewares so pontuados com 5. Processamento Distribudo Descreve o grau pelo qual a aplicao transfere dados entre seus componentes. Funes ou dados distribudos dentro da fronteira so caractersticas da aplicao. A classicao do nvel de inuncia varia de uma aplicao que no participa de transferncia de dados ou processamento de funes entre os componentes dos sistema a processamento de funo sendo executado dinamicamente no componente mais apropriado do sistema. Segundo [Lokan, 1998], para um sistema ser pontuado com 5 deveria ter componentes executando em mltiplos servidores ou processadores selecionados dinamicamente de acordo com sua disponibilidade. Esta caracterstica est mais presente em sistemas transacionais que em sistemas de suporte deciso. Performance Descreve o grau pelo qual consideraes de tempo de resposta e performance de throughput inuenciam o desenvolvimento da aplicao. Os requisitos de tempo, tais como tempo de resposta e taxa de transao, pode inuenciar no s no desenvolvimento, mas tambm suporte da aplicao. A classicao do nvel de inuncia varia de uma aplicao que no contm requisito temporal a aplicao que necessita de uso de ferramentas de anlise de performance de forma a garantir os requisitos temporais especicados. Nesta caracterstica importante a implementao de tarefas de anlises de performance para garantir os objetivos dos requisitos de performance envolvidos e como demonstrao ao cliente de seu comprimento. Esta caracterstica tem uma forte relao com o Volume de Transaes. Congurao Altamente Utilizada Descreve o grau pelo qual as restrio de recursos computacionais inuenciam o desenvolvimento da aplicao. Envolve restries quanto a um componente/equipamento que ser altamente utilizado ou necessidade de processamento acima da mdia. A classicao do nvel de inuncia varia de uma aplicao que no apresenta restries operacionais a aplicao que, por exemplo, apresente limitaes nos componentes distribudos da aplicao. A partir de uma pesquisa com amostras de 235 projetos de software realizado por [Lokan, 1998], podemos perceber que os projetos atuais so pontuados 2, sendo 77% dos projetos so pontuados entre 1 e 3. Aplicaes cientcas ou de engenharia com grandes exigncias de processamento pontuariam de 3 a 5.

18 Volume de Transaes Descreve em que nvel o alto volume de transaes de negcio inuencia o projeto, desenvolvimento, instalao e suporte da aplicao. A classicao do nvel de inuncia varia de uma aplicao que no apresenta nenhum pico de transaes a aplicao apresenta um alto volume de transaes, de tal forma que seja necessrio anlises de performance (estrita relao com CGS 3) atravs de ferramentas, nas fases de projeto, desenvolvimento e implantao. Os sistemas bancrios so mais inuenciados por esta caracterstica que os sistemas de engenharia. Um outro exemplo de sistema picos dirios de transao o de registro de pontos de funcionrios. Entrada de Dados On-Line Descreve em que grau so efetuadas entrada de dados na aplicao por meio de transaes iterativas. A classicao do nvel de inuncia varia de uma aplicao que processa todas as transaes em lote a aplicao com mais de 30% das transaes de entradas de dados on-line. Segundo [Lokan, 1998], esta caracterstica tem a maior pontuao e menor variao em comparao com as outras. Sendo 60% dos projetos pesquisados pontuados com nvel de inuncia 5. As pontuaes so baixas, geralmente 3, para um bloco de Cobol/mainframe/bancos projetos de uma organizao. Sendo a pontuao 5 para quase todo o resto. Talvez 30% seja um limiar muito baixo para os projetos atuais. Ecincia do Usurio Final Descreve em que nvel consideraes sobre fatores humanos e facilidade de uso pelo usurio nal inuenciam o desenvolvimento da aplicao. Basicamente, diz respeito a usabilidade da aplicao. A classicao do nvel de inuncia varia de acordo quantidade de requisitos de usabilidade atendidos, o maior nvel de inuncia requer uso de ferramentas e/ou processos especiais para demonstrar que os objetivos foram alcanados. [Lokan, 1998] arma que esta caracterstica mais importante para gerenciamento de sistemas de informao do que para sistemas de transao. Segundo [Vazquez et al., 2003], algumas diretrizes j esto defasadas, uma vez que a interface grca dos sistemas operacionais atuais j prov automaticamente vrios dos itens sugeridos para o aumento das ecincia do usurio nal. Aplicaes batch ou servidores sem interao com usurio pontuaro 0, aplicaes windows pontuaro de 3 a 5. Atualizao On-Line Descreve em que nvel os arquivos lgicos internos so atualizados de forma on-line. A classicao do nvel de inuncia varia de acordo com a quantidade de atualizaes online. O maior nvel de inuncia requer anlise do custo do processo de recuperao, uso de procedimentos altamente automatizados com um mnimo de interveno do operador. Segundo [Vazquez et al., 2003], algumas diretrizes esto defasadas, pois, exceo de aplicaes batch, a pontuao ser no mnimo 3.

19 Complexidade de Processamento Descreve o nvel de processamento lgico ou matemtico que inuencia o desenvolvimento da aplicao. Entre os exemplos de processamento lgico esto: processamento especial de auditoria ou de segurana da informao; processamento lgico ou matemtico extensivo; grande quantidade de processamento de excees; e processamento complexo para manipular mltiplas possibilidades de entrada e sada, meios e tipos de equipamentos (ex.: multimdia e independncia de dispositivo). A classicao do nvel de inuncia varia de acordo com a presena dos tipos de processamentos citados acima. Deve-se ter o cuidado de avaliar o processamento de acordo com a aplicao em geral e, no apenas, funcionalidades especcas. Normalmente os projetos so pontuados com 3, sendo poucos os projetos pontuados com 0 e 5. Reusabilidade Descreve o grau de reusabilidade do sistema, ou seja, os componentes do sistema podem ser utilizados em outras aplicaes. Para garantir reusabilidade necessrio que a construo desses componentes seja, desde o incio, projetada para tal. A classicao do nvel de inuncia varia de zero, em que no h cdigo reutilizvel, a cinco, em que a aplicao deve ser especicamente empacotada e documentada para fcil reutilizao, sendo customizada pelo usurio por meio de parmetros. Segundo [Vazquez et al., 2003], essa caracterstica est mais associada aos requisitos de qualidade do software do que a requisitos funcionais. Contm consideraes tcnicas que contraria o objetivo principal da tcnica de ponto de funo que medir o software do ponto de vista do usurio pela funcionalidade fornecida. Normalmente os projetos so pontuados entre 2 e 3, sendo uma preocupao maior a sistemas de suporte a deciso. Facilidade de Instalao Descreve o grau de converso de ambientes preexistentes e sua inuncia no desenvolvimento da aplicao. Em outras palavras, o nvel de facilidade de implantao da aplicao e as ferramentas de converso de dados disponibilizados so caractersticas da aplicao. A classicao do nvel de inuncia varia de zero, em que o usurio no deni requisitos, a cinco, em que os requisitos de converso e instalao foram fornecidos junto com ferramentas automticas. Testes so realizados de forma a atestar o funcionamento para o usurio. [Lokan, 1998] arma que as pontuaes so maiores para projetos de melhoria do sistema que para novos projetos, normalmente so maiores para mainframes que outras plataformas. Ao se referir a sistemas, so mais importantes para sistemas de engenharia do que para outras reas. Facilidade de Operao Descreve em que nvel a aplicao atende a alguns aspectos operacionais, como: inicializao, segurana e recuperao. As especicaes da aplicao demandam que sejam providos procedimentos automatizados que minimizem a interveno manual de operadores, tais como montagem de tas, manipulao de papel ou interveno manual pelo operador. O nvel de inuncia varia de nenhum requisito estabelecido pelo usurio a denies de requisitos com operao no-assistida, em que no necessria nenhuma interveno do operador

20 para operar o sistema, que no seja a inicializao e trmino da aplicao. A recuperao automtica de erros uma caracterstica da aplicao. [Lokan, 1998] arma que 62% dos projetos analisados em sua pesquisa apresentam pontuao baixa, sendo apenas 14% pontuados com 4 (quatro) ou 5 (cinco). Diferenas mais signicativas aparecem quando so realizados grupamentos por tipo de aplicao, em que, as pontuaes so mais altas para sistema de gerenciamento da informao e de suporte a deciso que para sistema de transao/produo e de informao de escritrio. Mltiplos Locais Descreve em que nvel a aplicao foi especicamente projetada, desenvolvida e suportada para ser instalada em mltiplos locais de uma organizao ou para diversas organizaes (diferentes ambientes de hardware e software). O nvel de inuncia varia de nenhum requisito especicado para essa caracterstica a denio de requisitos para que a aplicao opere em diferentes ambientes de hardware e de software, alm da elaborao e teste do plano de documentao e manuteno para suportar a aplicao em mltiplos locais. Na pesquisa realizada por [Lokan, 1998], o nvel de inuncia muito baixo para sistemas jurdicos e alto para sistemas de engenharia. Tambm mais alto para novos projetos do que projetos de melhoria e reengenharia. A mesma relao ocorre para sistemas da informao, sendo mais alto para sistema de gerenciamento da informao e de suporte a deciso que para sistemas de transao/produo e de informao de escritrio. Facilidade de Mudana Descreve em que nvel a aplicao foi especicamente projetada, desenvolvida e suporta manuteno, visando facilidade de mudanas atravs de capacidade de consultas e relatrios exveis, bem como a parametrizao dos dados de controle do negcio, de forma que o cliente possa modic-los a qualquer momento A classicao do nvel de inuncia varia de zero, em que fornecido recursos exveis de consulta e de emisso de relatrios que permitem a manipulao de pedidos simples, por exemplo, lgica aplicada a apenas um arquivo lgico (conte como um item), a cinco, em que dados de controle do negcio so mantidos pelo usurio por meio de processos interativos e as alteraes tm efeito imediato. Ou seja, [Vazquez et al., 2003] informa que nessa caracterstica avaliado os mecanismos de consultas exveis, em que o prprio usurio monta relatrios a partir dos dados disponveis no sistema, e tambm avaliado a manuteno de dados de controle do sistema, que reete a manuteno de parmetros de forma on-line por meio de manutenes de tabelas. Sendo, segundo [Lokan, 1998], essa caracterstica mais importante para sistema de gerenciamento de informao e de suporte a deciso e projetos de engenharia que para sistemas de transao/produo, projetos de mainframe e novos projetos.

21

2.4

Determinao dos Pontos de Funo Ajustados para diferentes tipos de Projeto

Para o clculo de pontos de funo ajustados (PFA) existem trs frmulas, a depender do tipo do projeto a ser contado. Os tipos so de projeto de desenvolvimento, de manuteno/melhoria e de aplicao. Nesse ltimo feita apenas a contagem dos pontos de funo, sem adio de cdigo ao sistema. As sees seguinte detalha as forma de calcular.

2.4.1

Clculo de Pontos de Funo Ajustado para um projeto de desenvolvimento

O projeto de desenvolvimento apresenta trs componentes em termos de funes: 1. Funcionalidades da aplicao includas pelos usurios como requisitos: Compreendem as funes usadas depois da instalao do sistema. Elas existem para satisfazer as necessidades de sada do negcio do usurio [International Function Point Users Group, 2011]. 2. Funcionalidades de converso includas pelos usurios como requisitos: Compreendem funcionalidades providas somente na instalao do sistema. Elas existem para converter dados ou proporcionar outros requisitos estabelecidos pelo usurio e necessrios converso [International Function Point Users Group, 2011]. 3. Valor do fator de ajuste da aplicao: Compreende a determinao das 14 caractersticas gerais do sistema em desenvolvimento, para avaliar a complexidade funcional da aplicao [International Function Point Users Group, 2011].

DFP, UFP, DFP = (UFP + CFP) VAF CFP, VAF,

Qntd de PF de desenvolvimento, Qntd de PF brutos apurados, Qntd de PF adicionados por processos de converso de dados, Valor do fator de ajuste.

2.4.2

Clculo de Pontos de Funo Ajustado para um projeto de Manuteno/Melhoria

Segundo o IFPUG o conceito de melhoria envolve apenas manutenes evolutivas na aplicao, ou seja, alteraes feitas na aplicao para atender aos novos requisitos de negcio do usurio. No so levadas em conta manutenes corretivas e preventivas. [Vazquez et al., 2003] Um projeto de melhoria consiste de trs componentes em termos de funes: 1. Funcionalidades da aplicao includas como requisitos pelo usurio para o projeto: Funes includas, alteradas ou excludas pelo projeto de melhoria; 2. Funcionalidades de Converso : Consiste dos pontos de funo entregues por causa de qualquer funcionalidade de converso requerida pelo usurio. [International Function Point Users Group, 2011]

22 3. Valor do fator de ajuste da aplicao Dois valores so considerados , segundo o manual: Valor do fator de ajuste ANTES do incio do projeto de melhoria (VAFB) Valor do fator de ajuste DEPOIS da concluso do projeto de melhoria (VAFA) Deve ser considerada que uma funo do tipo dado (ALI ou AIE) foi alterada quando ela foi modicada em sua estrutura com alguma incluso , alterao ou excluso de campos ou atributos. Uma funo do tipo transao considerada alterada quando h alterao em um dos itens a seguir [Vazquez et al., 2003]: Tipos de dados: Se houve incluso , alterao ou excluso da funo. Arquivos referenciados: Se foram includos , excludos ou alterados da funo. Lgica de processamento: Se qualquer lgica for includa , alterada ou excluda.

EFP = [(ADD + CHGA + CFP) VAFA] + (DEL VAFB)

EFP, ADD , CHGA, CFP, VAFA, DEL, VAFB,

Qntd de PF do projeto de melhoria, Qntd de PFNA das funes includas pelo projeto de melhoria, Qntd de PFNA das funes modicadas depois das modicaes, Qntd de PFNA adicionados pela converso, VAF da aplicao depois do projeto de melhoria, Qntd de PFNA das funes excludas pelo projeto de melhoria, VAF da aplicao antes do projeto de melhoria.

2.4.3

Clculo de Pontos de Funo para uma aplicao

Para calcular os pontos de funo de uma aplicao existem duas frmulas que so utilizadas: Frmula para Contagem Inicial: representa todas as funcionalidades requeridas pelo usurio de uma aplicao instalada. As funes da converso de dados no devem ser computadas no tamanho da aplicao entregue pois elas existiro somente para o processo de implantao do aplicativo [Vazquez et al., 2003]. AFP, Qntd de PFA da aplicao, AFP = ADD VAF ADD, Qntd de PFNA das funes instaladas, VAF, Valor do fator de ajuste da aplicao. Frmula usada aps o projeto de melhoria: aps a concluso de um projeto de melhoria os pontos de funo devem ser atualizados para reetir as mudanas na aplicao. Novamente as funes de converso de dados no devem ser computadas pois elas no fazem parte da aplicao [Vazquez et al., 2003].

23

AFP = [(UFPB + ADD + CHGA)(CHGB + DEL)] VAFA AFP, Qntd de PFA da aplicao, UFPB , Qntd de PFNA da aplicao antes do projeto de melhoria, Qntd de PFNA das funes includas pelo projeto de melhoria, ADD, CHGA, Qntd de PFNA das funes modicadas depois do seu trmino, CHGB , Qntd de PFNA das funes modicadas antes do seu trmino, DEL, Qntd de PFNA das funes excludas pelo projeto de melhoria, VAFA, VAF da aplicao depois do projeto de melhoria.

2.4.4

Consideraes

Segundo [Lokan, 1998], objees tericas forma como o VAF construdo poderia ser relevadas se houvesse algum benefcio prtico em seu uso. No entanto as evidncias apontam que no. No conjunto de dados utilizado em sua pesquisa, [Lokan, 1998] demonstra estatisticamente que o VAF no prov nenhuma assistncia, no sendo ecaz na estimativa de esforo do projeto, conrmando pesquisas anteriores realizadas por [Kitchenham, 1992] e [Kemerer, 1987]. Entretanto o registro dos valores individuais do CGS ainda pode ser til, tanto para comparaes histricas, quanto para compreender as diferenas entre projetos.

24

CAPTULO III Estudo de Caso

Neste captulo, desenvolveremos o processo de contagem de um sistema em desenvolvimento como estudo de caso. O Sistema escolhido o AutoSys, um sistema especco para controle uxo de uma loja de revenda de veculos e de nanciamentos. Neste estudo de caso, o sistema est na fase de desenvolvimento.

3.1

Descrio do Sistema

O AutoSys destinado ao controle e gerenciamento do comrcio de carros em uma concessionria e de gesto de nanciamentos. uma soluo automatizada e integrada, o que agiliza e possibilita a operacionalizao das vendas de forma centralizada, uma vez que qualquer concessionria poder acessar as operaes e relatrios centralizados ou locais com o devido acesso. O sistema deve manter os registros de todos os dados do negcio, sejam dos carros, dos clientes, dos funcionrios, das transaes nanceiras, da manuteno da loja e da manuteno do estoque. Tambm responsvel pela segurana e sigilo das informaes. Escopo da Contagem

Tabela 3.1: Identicao das Funes do Sistema AutoSys Login Vericao de Multas Estaduais CRUD Usurio Vericao de Multas Federais CRUD Cliente Vericao de Furto CRUD Funcionrio Vericao de Alienao CRUD Carro Verif. das Opes de Financiamento CRUD Financeira Consultar Pendncias do Carro CRUD Manuteno do Carro Cancelar Comprar Carro Comprar Carro Cancelar Vender Carro Trocar Carro Cancelar Trocar Carro Vender Carro CRUD Transao Financeira Relatrio Financeiro Simples Relatrio/Fluxo Trans. Financeiras Relatrio de Estoque Relatrio/Fluxo Clientes Relatrio Financeiro do Estoque O estudo de caso ter como escopo a primeira verso de implementao do sistema. Ou seja, alm o escopo a ser contado neste estudo de caso apresenta a primeira fase de desenvolvimento,

25 sendo as outras fases composta por mdulos que interagem com vrios outros sistemas, tais como sistema de permisses, sistema de nota scal, sistema de imposto de renda, sistema centralizado de help. A inteno do sistema automatizar as operaes administrativas realizadas pela loja, alm de melhorar o atendimento e otimizar o tempo gasto no levantamento nanceiro. Na identicao das funes, foi utilizado o acrnimo CRUD (Create, Read, Update and Delete) para identicar as funes bsicas de cadastro realizadas em um Arquivo Interno. As funes que este sistema ir realizar so apresentadas na tabela 3.1. A identicao das funes necessita atender aos requisitos de um processo elementar. Para isso, deve ser signicativa para o usurio, ser auto-contida e deixar a aplicao em estado consistente. O processo elementar tambm deve ser considerado nico, ou seja, nenhum outro processo elementar executa esta funo. Outra importante identicao a ser realizada so os requisitos de dados. Eles apresentam os tipos de dados que ser utilizado pelo sistema, conforme apresentado na tabela 3.2. Os campos observados com PK so chaves primrias e os com FK so chaves estrangeiras. Tabela 3.2: Identicao dos requisitos de dados do AutoSys Tabela Usurio Campos Login (PK) Nome Senha Criptografada Id. do Funcionrio (FK) Id. Da Pessoa (PK) Nome Completo CPF RG Endereo Cidade/Estado Celular Observao Id. Da Pessoa (PK, FK) Salrio Cargo Placa (PK) Chassis Modelo Kilometragem Marca Ano Cor Combustvel Proprietrio Atual (FK) Id. Da Financeira (PK) Nome da Financeira

Cliente

Funcionrio

Carro

Financeira Continued on Next Page. . .

Tabela 3.2 Continued Tabela Campos CNPJ Tabela de taxas Site de acesso Login de Acesso Senha de Acesso Placa (PK, FK) Id. do Custo (PK) Valor do Custo Descrio do Custo Id da Operao (PK) Tipo de Operao (Compra/Venda/Troca) Valor Corretor Externo (FK) Custo do Corretor Externo Placa (FK) Id. Transao Financeira (FK) Id Troca (FK) Id da Operao (PK) Id da Financeira (FK) Placa (FK) Taxa utilizada Entrada Qntdd Parcelas Valor das parcelas Id. Da Multa (PK) Placa (PK, FK) Descrio da Multa Valor da Multa Id. Da Multa (PK) Placa (PK, FK) Descrio da Multa Valor da Multa Placa (PK, FK) Valor total alienado Data de trmino Valor das parcelas Placa (PK, FK) Data Descrio

26

Custo Manuteno do Carro

Operao

Transao Financeira

Multas Estaduais

Multas Federal

Alienao

Furto

Para uma melhor organizao dos dados, a descrio das funes e documentao da anlise de ponto de funo est contida nos 5 e 5. Como resultado foram encontrados 259pontos de funo no ajustados, conforme consta na Figura 3.1 Tambm foi analisado no estudo de caso o fator de ajuste conforme o IFPUG (International

27 Function Point Users Group). Para isso foi determinado o fator de ajuste atravs do DI (Degrees of Inuence- Nveis de Inuncia). A gura 3.2 apresenta os resultados.

Figura 3.1: Resultado da Anlise de Ponto de Funo No Ajustado.

28

Figura 3.2: Resultado do clculo do valor de ajuste.

29

CAPTULO IV Aplicaes em Contratos do Governo

Alinhado com a Instruo Normativa n 4, cada vez mais as contrataes do governo vm utilizando a Anlise de Ponto de Funo como ferramenta de medio de tamanho funcional do software e mtricas de gesto nos contratos de sistema de software. Os principais tipos de contratos de prestao de servios de desenvolvimento ou manuteno de sistemas so os seguintes: Contrato por Preo Fechado, Contrato por homem-hora e Contrato baseado em Mtricas de Tamanho Funcional [Hazan, 2010]. O Contrato por Preo Fechado consiste no contrato de um produto com um preo denido para sua construo. Algumas vezes, as empresas que participam de uma licitao para este tipo contrato superestimam o tamanho do projeto, devido ao levantamento de requisitos ainda se encontrar numa fase inicial. O Contrato por homem-hora foi bastante utilizado pelos rgos Pblicos. Nesse tipo de contrato, o pagamento realizado pela hora de trabalho do prossional contratado. Trata-se de um contrato de terceirizao de mo de obra e no de Fbrica de software, trazendo muitos riscos gerenciais e trabalhistas da empresa contratada para o rgo Pblico contratante [Hazan, 2010]. O tipo de contrato de desenvolvimento e manuteno de sistemas baseado em mtricas de tamanho funcional tem sido utilizado por organizaes governamentais desde a dcada de 90. Nesse tipo de contratao, o pagamento da empresa contratada realizado por meio do dimensionamento do produto entregue, utilizando a mtrica estabelecida no contrato. As mtricas de tamanho mais utilizadas nos contratos so: Pontos por Casos de Uso, Pontos por Casos de Uso Ajustados, Pontos de Funo Ajustados e Pontos de Funo No Ajustados [Hazan, 2010]. Conforme j apresentado, a partir a publicao da verso 4.3 do Manual de Prticas de Contagem (CPM), os Pontos de Funo No Ajustados so considerados a mtrica padro do IFPUG (International Function Point Users Group) (2009). importante destacar tambm que o Tribunal de Contas da Unio (TCU) tambm tem recomendado, por meio da publicao de Acrdos, a utilizao de Pontos de Funo No Ajustados em contratos [Hazan, 2010]. Devido ao cenrio apresentado acima, atualmente, a maioria dos rgos Pblicos est utilizando a mtrica de Pontos de Funo No Ajustados em seus Editais para contratao de Fbrica de software . Atualmente, a maioria dos rgos Pblicos est utilizando a mtrica de Pontos de Funo No Ajustados em seus Editais para contratao de Fbrica de Software. Apenas visando ilustrar como estas contrataes esto ocorrendo, foram pesquisados alguns preges, as tecnologias requisitadas, a quantidade de pontos de funo contratados (demanda) apresentados na Tabela 4.1. Alm de apresentar o custo estimado por PF para realizao do prego e o custo efetivo de contratao.

Tabela 4.1: Tabela ilustrando as contrataes atuais de fbrica de software pelos rgos Pblicos.

30

31 Claro que muitos desses parmetros como tecnologia, demanda e custo depende muito da necessidade da organizao e tambm da localidade onde ser realizado o servio. Servido a Tabela 4.1 apenas como uma ilustrao do que vem acontecendo atualmente. Esse tipo de contratao realizada atravs de um planejamento e de mtricas de gesto, resolve muitos problemas na gesto do contrato. Alm disso garante um alinhamento com as melhores prticas de governana utilizados pelo mercado tais como MPS/BR, ITIL e CobiT. Isso tambm permite focar no alinhamento estratgico da rea de tecnologia com as reas nalsticas para uma excelncia em ecincia e eccia na utilizao dos recursos pblicos. No entanto, ainda surgem problemas comuns na contratao de software baseado em PF. Segue abaixo dez erros comuns apresentados pela [Hazan, 2010]: 1. Erro na Denio do Tamanho Funcional vs Esforo de Desenvolvimento. 2. Erro no Uso do PF nas Frmulas de Contagem descritas no CPM 3. Erro na Denio de Consulta Externa e Sada Externa 4. Erro na Identicao dos Arquivos Lgicos 5. Erro na Identicao de Processos Elementares 6. Erro na Identicao de Consultas Implcitas 7. Erro no Estabelecimento do Fator de Ajuste 8. Erro na Frmula de Clculo da Planilha de Contagem de PF 9. Erro na Determinao da Complexidade das Funes Alteradas em Projetos de Manuteno Evolutiva 10. Erro no Uso do CPM: Contagem de PF de Projetos de Manuteno (diferentes de manuteno evolutiva) Aps a apresentao de todos os problemas que podem acontecer em um contrato de software baseado em fbrica de software. Como evitar conitos entre contratantes e contratadas. 1. Obter um Documento de Requisitos com Qualidade: devendo este documento ser um acordo comum entre as partes; ser a base para a estimativa de PF; ser a base para a construo do projeto de software. 2. Estabelecer Regras para Evoluo de Requisitos: como os requisitos de software no permanecem congelados, importante estabelecer um percentual da atividade para cada fase do processo, facilitando o rastreamento do esforo. 3. Estabelecer Clusulas de Garantia da Qualidade: o CPM considera a funcionalidade recebida sem defeitos e o tempo de espera para a correo de defeitos pode ser muito grande. importante denir um indicador de defeitos/PF e uma clusula de multa. Tambm importante denir os tipos de defeitos no contrato, ex: bugs, defeitos em documentos, etc.

32 4. Estabelecer clusulas contratuais considerando cronograma e taxa de entrega: denir um modelo de estimativa a ser usado para denir o prazo de entrega. 5. Estabelecer o CPM como base para as contagens de PF ao invs de converses a partir de outras mtricas. 6. Estabelecer regras de dimensionamento de projetos de manuteno: dena frmulas baseadas na frmula de manuteno evolutiva do CPM no contrato de software. [Hazan, 2010] ainda considera que contratos de software baseados em preo xo por PF no uma boa prtica. Pois o esforo e o custo de projetos de software tambm so inuenciados por requisitos no funcionais. Assim ela recomenda um contrato baseado em preo por esforo (hora). Em que deve-se denir um modelo para derivar horas, baseando-se nos PF e requisitos no funcionais da aplicao.

33

CAPTULO V Concluso

The Roman bridges of antiquity were very inefcient structures. By modern standards, they used too much stone, and as a result, far too much labor to build. Over the years we have learned to build bridges more efciently, using fewer materials and less labor to perform the same task. Tom Clancy, The Sum of All Fears A partir da necessidade de uma melhor gesto e controle de um projeto so desenvolvidas tcnicas para maximizar os resultados de um projeto. Faz parte desses resultados a qualidade do produto, o cumprimento de prazos, o custo e a competitividade da organizao. Uma dessas tcnicas a estimativa de escopo do projeto. Possibilita medir o escopo do projeto, permitindo a gerao de indicadores de acompanhamento e normalizao do oramento a partir de uma comparao histrica com outros projetos semelhantes. Alm das vantagens de maior preciso do planejamento ao longo do tempo e de melhor relacionamento com o cliente. Esse ltimo deve-se a visibilidade e controlabilidade do status do projeto. No s o mercado percebeu a importncia de uma gesto mais ecaz, mas tambm o Governo Federal. Essa necessidade ca explicita nos Acrdos e, principalmente, na publicao da IN 04. Nesses documentos H a armao sobre a vantagem da contratao de prestao de servios na rea de TI, ou seja, a remunerao da contratada baseada na entrega do produto requerido. Dentre as tcnicas de estimativa de tamanho de software foi escolhida a Anlise de Ponto de Funo devido a sua popularidade e por ser um padro derivado da ISO/IEC 14143 (Medio do Tamanho Funcional). A tcnica de estimativa por ponto de funo pode ser utilizada no controle de mudana de escopo, medio de produtividade, comunicao dos requisitos funcionais. Na gesto de projetos, pode ser til na gerao de ndice percentual de crescimento funcional entre as diversas etapas no ciclo de vida e entre projetos semelhantes. Possibilita o ajuste renado de estimativa j na fase inicial de novos projetos. Este trabalho teve como objetivo apresentar a tcnica de ponto de funo, sua utilizao no mercado e tambm pelo governo federal. Tambm apresentou alguns problemas que surgem na contratao de software livre baseado em PF e algumas recomendaes para evitar o conito entre contratantes e contratadas. Como trabalho futuro pode ser apresentado um estudo de contrataes baseadas em ponto de funo. Assim como problemas comuns e recomendaes.

34

REFERNCIAS BIBLIOGRFICAS

E. L. P. d. Andrade and K. M. d. Oliveira. Aplicao de pontos de funo de casos de uso de forma combinada no processo de gesto de estimativa de tamanho de projetos de software orientado a objetos. Volume 7(1). C. A. Behrens. Measuring the productivity of computer systems development activities with function points. IEEE Trans. Softw. Eng., 9:648652, November 1983. ISSN 0098-5589. doi: 10.1109/TSE.1983.235429. URL http://portal.acm.org/citation.cfm?id=1313346. 1313876. Construx Software Inc., 2011. URL http://http://www.construx.com/. Construx Software Builders, Inc., acessado em maio de 2011. C. Hazan. Como evitar armadilhas em contratos de fbricas de software. Vol 117, jan/abr: 4756p, 2010. International Function Point Users Group, 2011. URL http://www.ifpug.org/. International Function Point Users Group, ltima modicao 26 de Setembro de 2011. C. Kemerer. An empirical validation of software cost estimation models. Vol 30(5):416429p, 1987. B. Kitchenham. Empirical studies of assumptions that underlie software cost-estimation models. Vol 34(4):211218p, 1992. C. J. Lokan. An empirical analysis of function point adjustment factors. Information and Software Technology, 42:649660, 1998. S. McConnell. Rapid Development: Taming Wild Software Schedules. Microsoft Press, 1996. ISBN 9781556159008. URL http://www.amazon.com/ Rapid-Development-Taming-Software-Schedules/dp/1556159005. A. L. Ribeiro, 2001. URL http://www.bfpug.com.br/Artigos/APF_Radial.ppt. Brazilian Function Point Users Group, acessado em agosto de 2011. I. Sommerville. Software Engineering (7th Edition). 9780321210265. Addison Wesley, 2004. ISBN

C. E. Vazquez, G. S. Simes, and R. M. Albert. Anlise de Pontos de Funo. rica, 2003. ISBN 8571948992. URL http://www.amazon.com/Anlise-de-Pontos-Funo/dp/ 8571948992.

35 CAPA

36 A

37 B

38 C

39 D

40 E

41 F

42 CAPA

43 A

44 B

45 C

46 D