Uso da análise de pontos de função aplicada ao PMBOK

Using the function point analysis applied to the PMBOK guide

Luiz Alexandre Hiane da Silva Maciel & Celso Massaki Hirata & Edgar Yano
Instituto Tecnológico de Aeronáutica

Resumo

A Análise de Pontos de Função (APF) é utilizada para medir o tamanho das funcionalidades do software segundo a visão do usuário, o que possibilita realizar uma estimativa do esforço necessário para seu desenvolvimento. Para tornar mais efetivo o uso da APF, deve-se situá-la em um contexto de gerenciamento de projetos de software. Assim, utiliza-se a APF em conjunto com outras técnicas a fim de efetivamente planejar e controlar os recursos do projeto com base nos pontos de função. Propõe-se que essa associação seja realizada entre a APF e o PMBOK por meio das áreas de conhecimento Gerenciamento de Escopo, Gerenciamento de Prazos e Gerenciamento de Custos. A proposta prevê para o Gerenciamento do Escopo a identificação das funções de transação e dados reconhecidas pelo usuário a partir do escopo do sistema e a criação de uma Work Breakdown Structure (WBS) orientada por funcionalidade ou por fase de desenvolvimento para que seja possível a inclusão do tamanho funcional de cada item facilitando assim a gestão dos pacotes. Para o Gerenciamento do Prazo é utilizado o tamanho funcional e as demais características técnicas do sistema definidas, tais como, experiência da equipe, maturidade do processo de desenvolvimento e recursos computacionais da aplicação, para que seja produzida a estimativa de esforço e duração do projeto por meio do modelo paramétrico de estimativas COCOMO II. Finalmente, o Gerenciamento do Custo conta com a aplicação da técnica Análise de Valor Obtido usando como unidade de medida do andamento do desenvolvimento os pontos de função implementados até o momento da análise. Para verificação da proposta deste estudo, foi utilizado um caso prático da COMPSIS – Computadores e Sistemas Ltda, uma indústria brasileira líder em soluções tecnológicas na área de gestão de trafego rodoviário e mobilidade situada em São José dos Campos, Brasil.

Introdução

A Análise de Pontos de Função (APF) é uma técnica que mapeia o software em suas funções reconhecidas pelo usuário, o que propicia um dimensionamento mais realista. Da mesma forma que existem unidades de medida relacionadas com diversos setores das atividades humanas, encontra-se nos pontos de função uma unidade de medida do software, assim como a hora é utilizada para medir tempo e o quilômetro para medir distância. (Longstreet 2005, 1)

Apesar das vantagens que o dimensionamento por meio de pontos de função fornece ao gerenciamento de projetos de software, poucas organizações utilizam a APF com este fim, ou seja, grande parte das organizações utiliza os pontos de função para realizar apenas uma medição funcional do tamanho do software, sem uma vinculação forte com a gestão do projeto.

A Análise de Pontos de Função foi desenvolvida durante a década de 70 e publicada em 1979 por Allan Albrecht (Vazquez 2003, 42) como uma técnica que se propõe a substituir a contagem de linhas de código, de modo a minimizar as dificuldades encontradas para se determinar o tamanho do software a ser desenvolvido.

Dentro desse cenário, este estudo visa descrever como a Análise de Pontos de Função pode ser usada em três das áreas de conhecimento do PMBOK, que são: a área de Gerenciamento de Escopo, a área de Gerenciamento de Custos e a área de Gerenciamento de Prazos para obter uma forma clara de planejamento e controle de projetos de software.

Mesmo sendo relevante na indústria de software, não cabe a essas três áreas escolhidas definirem uma unidade de medida para quantificar o software. Dessa maneira, fica a critério de cada organização, estabelecer a sua forma de quantificar o software e daí gerenciar as unidades de software a serem entregues e extrair os parâmetros indicativos de custo e prazo.

Um trabalho correlato (Andrade 2004, 100), mostra a existência da cooperação entre os processos de estimativa, desenvolvimento e gerenciamento de software. Busca uma cooperação entre os pontos de caso de uso, que são utilizados no início do projeto de software quando não se possui muita informação sobre o mesmo, e pontos de função, que são utilizados nas demais fases do projeto quando já se possui um nível razoável de conhecimento do mesmo tornando possível realizar estimativas mais completas.

Caracterização do Estudo de Caso

O estudo de caso abordado neste trabalho e proposto pela empresa COMPSIS trata-se de uma adaptação de um dos módulos de seu Sistema de Arrecadação e Auditoria em Pedágios, aplicado em 45% das praças de pedágio brasileiras. Esse módulo chama-se Sistema de Arrecadação de Tarifas Eletrônico (ETCS). O processo de desenvolvimento em cascata está presente na maioria dos projetos da empresa, porém esta vem, nos últimos anos, aplicando o desenvolvimento incremental. Isto aconteceu após a elaboração e implantação de um novo processo de desenvolvimento de software, cujas fases, atividades e artefatos foram estipulados pela equipe de Engenharia de Software interna. O ETCS foi desenvolvido com a utilização de um método interno de planejamento e acompanhamento, baseado na experiência dos seus especialistas.

Precisão do Dimensionamento

Atualmente a técnica APF fornece uma precisão conforme o nível de conhecimento que se tem do software a ser desenvolvido. A maior precisão está na contagem detalhada que é a contagem oficial do International Function Point Users Group (IFPUG). Existem também as contagens estimada e indicativa que foram desenvolvidas por Netherlands Software Metrics Users Association (NESMA), com o intuito de possibilitar a contagem com antecedência nos projetos de software, mas fornecendo uma precisão menor do que a detalhada.

Na contagem detalhada, tem-se a complexidade de cada função analisada minuciosamente no intuito de determinar o tamanho de cada uma por meio de seus elementos de dados e arquivos referenciados. Por esse método (IFPUG 1994), as funções têm sua complexidade definida em simples, média e complexa.

Conforme o método descrito em (NESMA 1998), na contagem estimada, a complexidade das funções não é avaliada, considera-se apenas a existência ou não dessas funções e atribui-se uma complexidade padrão para as funções de transação e outra para as funções de dados. A contagem indicativa considera apenas as funções de dados, que possuem complexidades fixas, não importando o seu número de elementos de dados. Nesse estudo utilizaremos a contagem estimada para determinar o total de pontos de função do estudo de caso proposto, pois não buscamos uma estimativa precisa, mas a definição de uma seqüência de tarefas de apoio à gestão do projeto.

Contagem de Pontos de Função em processos de desenvolvimento de software

A seguir, são propostos momentos em que a contagem poderia ser realizada pela primeira vez dentro de um projeto de software. Esses momentos dependem do processo de desenvolvimento. Durante as pesquisas para elaboração desse trabalho foram considerados dois processos de desenvolvimento, a saber, o processo em cascata e o processo incremental e iterativo. Esse último será focado especificamente no IBM® Rational Unified Process (RUP), pois se acredita que é um dos processos incrementais e iterativos mais utilizados pelas empresas.

O processo em cascata é composto pelas fases: levantamento de requisitos, análise de requisitos, projeto, implementação, testes e implantação. Um primeiro momento no qual se pode realizar a contagem de pontos de função, é aquele entre o levantamento e a análise de requisitos. Essa contagem é a estimada, pois de posse dos requisitos seriam identificadas as funções e os dados a serem manipulados.

No Processo Unificado, como estabelecido na documentação, um primeiro momento no qual se pode realizar a contagem, é aquele entre as disciplinas de requisitos e de análise e design, dentro da fase de iniciação e na primeira iteração. Estabelecer o escopo do software e estimar o custo geral e a programação para o projeto inteiro, está entre os objetivos principais da fase de iniciação. Essa contagem é estimada e com o aumento do conhecimento do projeto aplica-se a contagem detalhada.

Gerenciamento de Escopo

Escopo do ETCS

Para a montagem da WBS do ETCS é necessário conhecer o seu escopo, o qual está transcrito a seguir:

“O ETCS tem o objetivo de registrar os usuários que farão uso do pedágio eletrônico nas concessionárias brasileiras. O sistema será capaz de catalogar todos os usuários e, para cada um, associar um ou mais passes eletrônicos. Esses passes serão previamente cadastrados no sistema e à medida que houver demanda por novos passes, esses também serão cadastrados antes de serem entregues ao usuário do pedágio. A entrega dos passes será feita mediante um pedido registrado e pago no sistema. Para viabilizar a gestão operacional, o sistema deverá possuir os seguintes relatórios: lista de todos os usuários cadastrados, lista de todos os pedidos existentes e um relatório financeiro baseado nos pedidos criados no sistema. Esse relatório financeiro e sintético deverá fornecer os totais de valor e quantidade de passes dos pedidos processados nos últimos doze meses.”

Dimensionamento do ETCS

A partir do escopo acima, foram criadas a lista de funções e duas WBS. A primeira WBS é orientada por funcionalidade, veja figura 1. O objetivo é mostrar as características de cada WBS no apoio ao gerenciamento do desenvolvimento.

A WBS por funcionalidade da figura 1 organiza numa estrutura hierárquica todas as funções mencionadas no escopo do sistema. Ela está organizada em quatro níveis, a saber: o primeiro é o nível Sistema, o segundo é o nível Módulo, o terceiro é o nível Pacote e o quarto é o nível Função, tal qual ela é identificada pelo usuário. Nessa WBS existe um módulo chamado Dados que é responsável por agrupar todas as funções de dados identificadas pelo usuário, dessa forma, reduz-se o risco de que essas funções apareçam duplicadas na WBS.

Em seguida, é feito o dimensionamento do sistema utilizando-se as funções presentes no escopo e a contagem estimada dos pontos de função.

WBS do ETCS com tamanho funcional

Figura 1: WBS do ETCS com tamanho funcional

As funções identificadas são as seguintes:

Arquivos Lógicos Internos: Usuário, Pedido, Passe Eletrônico e Recebimento.

Entradas Externas: Incluir, Alterar e Excluir Passe; Incluir, Alterar e Excluir Usuário; Incluir, Alterar e Excluir Pedido; Recebe Pedido; Entrega de Passe.

Saídas Externas: Relatório Financeiro.

Consultas Externas: Consultar Usuário, Consultar Passe, Consultar Pedido, Relatório Lista Usuário e Relatório Lista Pedidos.

As funções de dados têm complexidade baixa e contribuem com 7 PF’s cada uma. As funções de transação são de complexidade média e contribuem com 4 PF’s para as EE’s / CE’s e com 5 PF’s para as SE’s (NESMA 1998). Dessa forma, o sistema ETCS possui 97 pontos de função não-ajustados. Essa informação passa a ser subsídio ao gerenciamento do escopo e a informação de tamanho funcional é incluída na WBS do sistema, conforme figura 1.

A segunda WBS, orientada por fases de desenvolvimento, está ilustrada na figura 2. Esta WBS, de certa forma, pode ser considerada geral, visto que vários projetos de software poderiam se utilizar dela. Ela está decomposta em seis itens no segundo nível que representam as fases do processo de desenvolvimento em cascata. Já no terceiro nível encontram-se os produtos que devem ser entregues. Por exemplo, em ETCS / Implementação devem ser entregues a versão inicial dos módulos do software, o manual de operação atualizado, o manual do usuário atualizado e assim por diante.

WBS por funcionalidades versus WBS por fases

Para o uso da APF, a WBS por funcionalidades é recomendada por organizar a decomposição do software em seus componentes funcionais elementares, o que facilita o emprego da técnica. Ressalta-se, desta forma, que a elaboração da WBS por funcionalidades pode servir como entrada para utilização da APF dentro do projeto de software. Todavia, em alguns projetos é necessário um controle das suas etapas, assim, deve-se utilizar a WBS por fases em conjunto com a WBS por funcionalidades visando conseguir um gerenciamento adequado. Uma dificuldade observada no caso de se utilizar apenas a WBS por fases com APF é que há um trabalho extra no acompanhamento do projeto de software. Por exemplo, considere que numa data D1 o módulo referente ao registro de usuário seja entregue. Na WBS da figura 1, isso equivale a vinte e três pontos de função que correspondem à soma do peso das funções do pacote Registro/Usuário com a função Dados/Usuário.

Já no caso da WBS por fases da figura 2, não se consegue definir de imediato o que foi concluído quando o conjunto da funcionalidade é realizado, ou seja, quanto do levantamento de requisitos, análise, projeto, implementação, testes e implantação foram cumpridos para que nesta data D1 o módulo referente ao registro de usuário fosse entregue. Desta forma, existe um trabalho extra do gerente de projeto em definir quanto de cada fase foi cumprido após a conclusão do módulo. Portanto, deve-se ressaltar que apesar da WBS por funcionalidades ser mais adequada para controlar, não necessariamente é mais adequada para o planejamento.

A fim de tornar compatível o planejamento e o controle deve-se considerar que a WBS por funcionalidade seja utilizada em projetos baseados no processo incremental enquanto que a WBS por fases seja utilizada em projetos baseados no processo em cascata.

WBS do ETCS organizada por fases do desenvolvimento

Figura 2: WBS do ETCS organizada por fases do desenvolvimento.

Gerenciamento de Prazos

O Gerenciamento de Prazos tem como objetivo principal definir as atividades, a duração e a programação dessas atividades para o projeto. Nesse cenário, a APF serve como base para a geração de estimativas, ou seja, a partir do tamanho do software a ser construído medido em pontos de função e aplicando-se métodos de estimativa, obtém-se o esforço e a duração para as atividades de desenvolvimento do projeto.

Para obter essas estimativas uma das abordagens é a paramétrica, na qual são utilizadas equações que assumem uma relação entre tamanho, esforço e prazo. Geralmente, calibradas a partir do histórico de centenas de projetos (Aguiar 2003, 2)

Atualmente, dois métodos paramétricos estão bastante difundidos entre o meio industrial e científico. Trata-se do modelo COnstructive COst MOdel (COCOMO II) e do modelo Software Lifecycle Management (SLIM), elaborado pela empresa Quantitative Software Management. Nesse estudo será considerado o COCOMO II que foi criado pela University of Southern California (USC), possui um grande número de documentação disponível, é suportado eletronicamente por um software de fácil operação e planilhas e gráficos eletrônicos.

Associando-se o COCOMO II com a técnica de APF e considerando que o nível de conhecimento que se tem do projeto evolui conforme o seu desenvolvimento, a figura 3 mostra qual a precisão de contagem de PFs deve ser utilizada de acordo com o modelo de estimativa do COCOMO II e o conhecimento que se tem do sistema. Os dados referentes ao COCOMO II foram extraídos de (Boehm 2000, 307).

COCOMO Versus APF

Figura 3: COCOMO Versus APF

O COCOMO II é formado basicamente pelas equações de esforço e duração as quais são descritas a seguir.

Esforço Estimado = PM = EM1 * … * EM17 * Ca * (T )B , ver (Boehm 2000, 29).

Onde: EM1…EM17 são os Multiplicadores de Esforço de 1 a 17 cujos valores são definidos para cada projeto conforme a avaliação dos envolvidos. Ca é uma das constantes do COCOMO II que permite a calibração do modelo a cada empresa-alvo. O valor original é 2,94. T é o tamanho do sistema em milhares de linhas de código. B é o expoente de influência do tamanho e é calculado pela fórmula abaixo.

B = Cb + 0, 01 * (SF 1 + … + SF 5) , ver (Boehm 2000, 31).

Onde: Cb é outra constante a ser calibrada para cada empresa-alvo. O valor nominal é 0,91. SF1…SF5 são os fatores de escala. Eles tratam do modo de desenvolvimento, dos riscos, da coesão da equipe e da maturidade do processo de desenvolvimento. Os valores são definidos pelo COCOMO conforme a avaliação dos envolvidos.

Tempo de Desenvolvimento = TDEV = Cc * PM(Cd+0,2*(B–0,91)) , ver (Boehm 2000, 57).

Onde: Cc é constante de calibração cujo valor original é 3,67. PM é o esforço estimado calculado anteriormente. Cd é constante de calibração cujo valor original é 0,28. B é o expoente do tamanho calculado anteriormente.

A seguir é apresentado o roteiro proposto por (Aguiar 2003, 4) para estimativa de esforço e duração usando o COCOMO II com dimensionamento do software por pontos de função. O roteiro consiste dos seguintes passos:

1-Calibrar o COCOMO II com os dados históricos da empresa-alvo; 2-Estimar o tamanho com pontos de função e converter em linhas de código usando uma tabela de conversão, Backfiring, como aquela proposta por Capers Jones (Boehm 2000, 20); 3-Determinar os fatores multiplicadores de esforço conforme o modelo do COCOMO II utilizado. O fator de ajuste proposto pela APF não é considerado pelo COCOMO II; 4-Determinar através do COCOMO II o esforço, a duração e a equipe média, e 5-Obter a distribuição do esforço e da duração pelas fases do processo de desenvolvimento.

Por meio do processo descrito acima, obtém-se uma linha de base da estimativa que, posteriormente, pode ser comparada com as demais linhas de base do projeto. Novas contagens são necessárias, especialmente após a definição da arquitetura e após o projeto detalhado, a fim de dar subsídios ao Gerenciamento de Custos e ao Processo de Métricas da empresa, contribuindo para a calibração do modelo de estimativas da empresa-alvo.

A estimativa do estudo de caso ETCS foi feita como descrito a seguir.

Utilizou-se a calibração original do COCOMO II, portanto os índices das fórmulas de estimativa foram mantidos inalterados. O dimensionamento do sistema por pontos de função foi realizado e obteve-se o total de pontos de função não-ajustados. Para a obtenção do esforço e da duração aplicou-se o modelo Projeto Preliminar do COCOMO II conforme demonstrado a seguir.

Linguagem do software = Java

Backfiring = 53 linhas de código / ponto de função

Total de Pontos de Função = 97

Total de linhas de código previstas (S) = 97 * 53 = 5141

Aplicação das fórmulas do COCOMO II:

B = 0,91 + 0,01 * (3,72 + 3,04 + 4,24 + 3,29 + 4,68) = 1,0997

PM = 1 * 2,94 * (5141 / 1000)1,0997 = 17,8 (homem-mês)

TDEV = 3,67 * 17,8 (0,28 + 0,2 * (1,0997 – 0,91)) = 9,2 meses

Equipe média do projeto = PM / TDEV = 1,93 pessoas-mês

Na figura 4 encontra-se a distribuição do esforço e duração por fase do projeto sugerida pelo software COCOMO II.2000 usando seus índices nominais. Veja em (Boehm 2000, 307) para uma relação detalhada das distribuições propostas pelo COCOMO II. A figura mostra as fases do processo em cascata, mas o COCOMO II também contempla o processo incremental.

Distribuição percentual e numérica para cada fase do projeto

Figura 4: Distribuição percentual e numérica para cada fase do projeto

Assim, são obtidas as estimativas de esforço e duração para o sistema e a respectiva distribuição desses valores pelas fases do desenvolvimento. A partir desse ponto dá-se início à programação das atividades conforme previsto no PMBOK com o propósito de obter os prazos para construção do sistema. É importante ressaltar que essa distribuição não é útil nos projetos planejados por funcionalidades e que nesse caso uma outra abordagem deve ser adotada.

Gerenciamento de Custos

Num projeto é necessário exercer controle sobre o planejamento existente e verificar se a realização do trabalho está dentro do esperado. Esse controle de custo e prazo aplicado em muitos projetos é baseado na técnica Análise do Valor Obtido (Earned Value Analysis). Por meio dessa técnica procura-se calcular periodicamente o andamento do projeto, tomando como base o custo real e a porção realizada do projeto. Os resultados desse cálculo são os indicadores financeiros de Variação de Programação (VP) e Variação de Custo (VC). Esses indicadores são obtidos a partir das equações abaixo: (Fleming 2000, 120)

VP = ValorObtido – ValorPlanejado         VC = ValorObtido – CustoReal

Nessas equações ValorObtido é o valor obtido com o trabalho realizado, ValorPlanejado é o valor correspondente ao trabalho planejado e CustoReal é o custo real do trabalho realizado. Analisando os indicadores VP e VC, é possível verificar se o projeto está ou não fora da programação, e se os gastos com recursos foram ultrapassados, se estão dentro ou mesmo abaixo do esperado.

Uma simulação do acompanhamento do ETCS usando a proposta desse trabalho foi elaborada logo abaixo.

A partir da figura 4 tem-se a equipe média necessária definida, calcula-se então o custo de mão-de-obra para o projeto. O Controle de Custo, conforme sugerido nesse estudo, será demonstrado utilizando-se um planejamento baseado em pontos de função e o cálculo do andamento por valor obtido. Uma vez que o planejamento tenha sido feito a partir das funções reconhecidas pelo usuário, tem-se a cada instante o total de pontos de função que deveriam estar implementados.

Custo previsto com mão-de-obra alocada é de R$ 40.000,00.

Total de pontos de função = 97

Custo unitário = R$ 412,37/PF

Será assumido que na data D1, deveria estar implementado o equivalente a 30 pontos de função, por exemplo, o módulo usuário completo e apenas a base de dados de pedidos.

Valor Planejado (VPL)= 30 * 412,37 = R$ 12.371,10

Andamento real reportado pelos desenvolvedores = 20 pontos de função

Valor Obtido (VO) = 20 * 412,37 = R$ 8.247,40

Custo realizado para 20 pontos de função = R$ 9.000,00

Custo unitário real = R$ 450,00/PF

Dessa forma, pode-se avaliar o andamento do projeto da seguinte maneira:

Variação de Programação (VP) = VO - VPL = 8.247,40 - 12.371,10 = R$ 4.123,70

Variação de Custo (VC) = VO - CA = 8.247,40 - 9.000,00 = R$ 752,60

Conclui-se então, que o projeto está tomando mais tempo e gastando mais do que o previsto.
Essa análise deve ser repetida periodicamente para criar um indicador do andamento do projeto e novas linhas de base, e ao passo que o projeto seja detalhado, deve-se considerar refazer as estimativas e a contagem dos pontos de função usando-se o modelo Pós Arquitetural do COCOMO II e a contagem de pontos de função do IFPUG.

Conclusão

A Análise de Pontos de Função pode ser relacionada com o gerenciamento do desenvolvimento de software e os processos de desenvolvimento existentes, fornecendo subsídio para um melhor acompanhamento dos projetos, como mostrado nesse estudo.

Este trabalho apresentou como a APF pode ser utilizada para auxiliar o gerenciamento de projetos, bem como uma avaliação do uso desta proposta através de um estudo de caso real de projeto da empresa Compsis. Demonstrou-se a aplicação considerando três áreas de conhecimento previstas no PMBOK, o Gerenciamento de Escopo, o Gerenciamento de Prazos e Gerenciamento de Custos. Com isso, foi possível demonstrar que a partir da APF é possível calcular o dimensionamento do esforço e chegar ao custo de desenvolvimento, fornecendo subsídios ao gerenciamento de projetos de software. Possibilita avaliar o estado atual do projeto de software, isto é, avaliar o andamento do projeto em relação aos prazos e custos acordados para entrega de um produto que atenda os requisitos levantados. Além disso, estabeleceu os momentos mais adequados dentro de um processo de desenvolvimento para obtenção das primeiras estimativas.

Propomos alguns estudos para trabalhos futuros com o intuito de consolidar o trabalho apresentado: 1) Realizar um estudo de caso mais abrangente da aplicação das propostas apresentadas criando comparativos com outras técnicas e 2) Estudar uma maneira que auxilie na obtenção do valor obtido, com a finalidade de facilitar a análise das variações de custo e programação.

Boehm, B., et al. (2000) Software Cost Estimation with COCOMO II. Upper Saddle River, NJ:Prentice-Hall.

Vazquez, C. E., et al. (2003) Análise de Pontos de Função Medição, Estimativas e Gerenciamento de Projetos de Software. São Paulo, Brasil:Érica.

Fleming, Q. W., et al. (2000) Earned Value Project Management. Newtown Square, PA:Project Management Institute.

Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK® Guide) (3rd ed.). Newtown Square, PA:Project Management Institute.

IFPUG. (1994) Function Point Counting Practices Manual: Release 4.0. Princeton Junction, NJ:International Function Point Users Group

Longstreet, D. (2004) Function Points Analysis Training Course. Longstreet Consulting Inc. Acessado 15/02/2005, de http://www.SoftwareMetrics.Com/freemanual.htm.

Longstreet, D. (2005) Fundamentals of Function Point Analysis. Longstreet Consulting Inc. Acessado 20/09/2004, de http://www.softwaremetrics.com/fpafund.htm.

Aguiar, M. (2003) Estimando os Projetos com Cocomo II. TI Métricas Ltda. Acessado 10/11/2004, de http://www.metricas.com.br/artigos.htm.

Andrade, E. L. P. de. (2004)Pontos de Casos de Uso e Pontos de Função na Gestão de Estimativa de Tamanho de Projetos de Software Orientados a Objeto. Brazilian Function Point Users Group. Acessado 10/09/2004, de http://www.bfpug.com.br/artigos.htm.

NESMA. (1998) Early Function Point Counting. Netherlands Software Metrics Users Association. Acessado 04/09/2004, de http://www.nesma.nl/english/earlyfpa.htm.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2005, Carlos Augusto Lombardi Garcia
Originally published as a part of 2005 PMI Global Congress Proceedings – Panama City, Panama

Advertisement

Advertisement

Related Content

  • Project Management Journal

    Identifying Challenges and a Research Agenda for Flow in Software Project Management member content locked

    By Dennehy, Denis | Conboy, Kieran Flow and its associated tools and metrics are increasingly being reported as an approach used to achieve continuous deployment of software and delivery of value in software development projects. Yet…

  • PM Network

    Escaping Pilot Purgatory member content locked

    By Waity, C. J. Pilot projects can bridge the gap between a brilliant idea and a valuable product—but only if the bridge is successfully completed and built to scale. And in the age of disruption, that doesn't…

  • PM Network

    Hands-On member content locked

    By Karunaratne, Charmaine Although the software development life cycle (SDLC) is an important part of any software project, IT project managers rarely seem to raise the topic. Instead, they leave it to the development teams…

  • PM Network

    Best of Both member content locked

    By Graetsch, Ulrike Maria When leaders at rapidly growing organizations establish a project management office (PMO), they're often seeking better control over which projects are started, more oversight of projects in…

  • Project Management Journal

    How to Buffer the Family Costs of Project Citizenship Behavior member content locked

    By Zhong, Rui | Xia, Nini | Hu, Xiaowen | Wang, Xueqing | Tiong, Robert Previous studies have mainly concentrated on the desirable aspects of project citizenship behavior (PCB) but largely ignored its dark sides. We seek to fill in this gap by exploring whether and when…

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.