Análise de Pontos de Função - PDF
Download "Análise de Pontos de Função"
Joana Chaplin Beppler
1 Análise de Pontos de Função Uma aplicação nas estimativas de tamanho de Projetos de Software Claudia Hazan Graduada em Informática pela Universidade do Estado do Rio de Janeiro (UERJ), Mestre em Engenharia de Sistemas e Computação pelo Instituto Militar de Engenharia (IME), Em Doutoramento em Engenharia de Software pela PUC-Rio, atua como consultora de métricas e qualidade de software no Serviço Federal de Processamento de Dados (SER- PRO), ministrando treinamento de Análise de Pontos de Função com estimativas e apoiando a empresa e seus clientes na contagem de Pontos de Função, nas estimativas de projetos de software e gestão de contratos baseados em Pontos de Função. A indústria de software continua sentindo os efeitos da crise do software da década 80. Isto pode ser observado quando analisamos os três principais sintomas da crise do software apresentados por Pressman em 2006, a saber: A produtividade não tem acompanhado a demanda por serviços; A qualidade do software, em alguns sistemas, não é adequada; As estimativas de prazo e custo são freqüentemente imprecisas. Este último sintoma, que está associado a um dos principais problemas que a indústria de software tem enfrentado (a falta de previsibilidade de custo e prazo de projetos de software), pode levar a conseqüências desastrosas, tais como: conflitos entre o gerente do projeto e a equipe, baixa estima da equipe, entrega de software de baixa qualidade, perda de imagem da organização, e até mesmo o cancelamento do projeto. Assim, torna-se importante o investimento na implantação de um processo de estimativas efetivo, visando a melhoria da previsibilidade de custo, prazo e esforço. Este artigo tem como propósito apresentar um processo de estimativas de projetos de software, aderente ao modelo CMMI, utilizando a métrica de Pontos de Função para estimar o tamanho funcional do projeto de software. Processo de Estimativas de Projetos de Software Esta seção apresenta uma visão geral de um processo de estimativas de projetos de software aderente à área de processo de Planejamento do Projeto do nível 2 do CMMI. A Figura 1 ilustra um processo de Estimativas de Projetos de Software. Este processo é descrito nos parágrafos seguintes. O principal insumo (artefato de entrada) para um processo de estimativas é o documento de requisitos. Como as Edição 02 Engenharia de Software Magazine 25
2 estimativas devem ser realizadas no início do processo de desenvolvimento de software, então, o artefato utilizado é freqüentemente um documento inicial de requisitos (por exemplo: Documento de Visão) ou até mesmo um documento do próprio cliente (por exemplo: modelo de processo de negócios ou manual do usuário, no caso de redesenvolvimento). O responsável pelas estimativas deve analisar os requisitos para garantir a qualidade e então estimar o tamanho do projeto de software. O próximo passo é a derivação das estimativas de esforço, prazo (cronograma), custo (orçamento) com base na estimativa de tamanho e nos dados históricos de projetos concluídos da organização, assim como o estabelecimento da estimativa de recursos computacionais críticos. Neste ponto, as principais estimativas foram geradas, no entanto estas precisam ser documentadas. As premissas e suposições utilizadas na geração das estimativas também devem ser documentadas. A análise das estimativas por um estimador independente, um profissional que não atue na equipe do projeto, constitui uma boa prática. O estimador independente poderá analisar a consistência das estimativas e a qualidade das suas documentações. No decorrer do processo de desenvolvimento, as estimativas devem ser acompanhadas conforme o refinamento dos requisitos. O projeto deve ser re-estimado se ocorrerem mudanças significativas nos requisitos funcionais ou não funcionais. Quando o projeto é concluído, deve-se documentar o tamanho, prazo, custo, esforço e recursos realizados, assim como outros atributos relevantes do projeto, visando a coleta de dados para a melhoria do processo de estimativas. As lições aprendidas também devem ser documentadas. O foco deste artigo está na geração de estimativas de tamanho de projetos de software. Observe que a estimativa de tamanho é a primeira a ser gerada e a partir dela são derivadas as demais estimativas. Por isso, a importância desta estimativa. A literatura apresenta várias métricas de tamanho. Na indústria brasileira, podese destacar a utilização de três métricas: LOC (Line of Code), Pontos por Casos de Uso e Pontos de Função. A seção seguinte apresenta as vantagens e desvantagens da utilização destas métricas. Métricas de Tamanho de Projetos de Software A métrica Linhas de Código (LOC) é de fato a mais antiga. A principal vantagem é que a contagem de linhas de código pode ser automatizada por uma ferramenta. As desvantagens são as seguintes: muitas vezes, o significado de uma linha de código é subjetivo, por exemplo, contar ou não linhas de comentário no código fonte; a métrica não é adequada para ser um indicador de produtividade, por exemplo, o desenvolvedor que escrever mais linhas de código será mais produtivo do que o desenvolvedor que escrever um algoritmo mais elegante e mais eficiente com menos linhas de código. Além disso, torna-se bastante complicado e subjetivo aplicar esta métrica em um processo de estimativas cujo insumo é um documento inicial de requisitos. Portanto, não é recomendado o uso da métrica LOC como unidade de medida para as estimativas de tamanho. A métrica Pontos por Casos de Uso (PCU) foi proposta por Gustav Karner com o propósito de estimar recursos para projetos de software orientados a Banco de Dados Histórico de Projetos da organização Documentar Estimativas e Premissas Documentar Acompanhamento Documentar Resultados finais e Lições Aprendidas Coletar e Analisar Requisitos Iniciais Estimar Tamanho Estimar Esforço Estimar Cronograma Estimar Custo Estimar Recursos Computacionais Críticos Analisar e Aprovar Estimativas Acompanhar Estimativas Figura 1. Processo de Estimativas de Projetos de Software objeto, modelados por meio de especificação de Casos de Uso. A métrica é de fácil aplicação, não requer muito tempo de treinamento ou experiência prática. No entanto, o PCU somente pode ser aplicado em projetos de software cuja especificação tenha sido expressa em casos de uso. Além disso, como não existe um padrão único para a escrita de uma especificação de caso de uso, diferentes estilos na escrita do caso de uso ou na sua granularidade podem levar a resultados diferentes na medição por PCU. Assim, a métrica se torna subjetiva. E ainda, devido ao processo de medição do PCU ser baseado em casos de uso, o método não pode ser empregado antes de concluída a análise de requisitos do projeto. Na maioria das vezes existe a necessidade de se obter uma estimativa antes da finalização desta etapa. Então, esta métrica não é recomendada para utilização como unidade de medida das estimativas de tamanho de projetos de software. A métrica Pontos de Função (PF), definida por Allan Albrecht em 1979, tem sido utilizada de forma crescente pela indústria de software. O IFPUG (International Calibrar e Melhorar o Processo Reestimar,conforme necessidade 26 Engenharia de Software Magazine Análise de pontos de função
3 Function Point Users Group), criado em 1986, é responsável pela atualização das regras de Contagem de Pontos de Função, descritas no CPM (Counting Practices Manual), que se encontra na versão 4.2.1, publicada em 2005 no IFPUG. O IFPUG também é responsável pelo exame de certificação de especialistas em contagem de Pontos de Função, denominada CFPS (Certified Function Point Specialist). A métrica Pontos de Função é uma medida de tamanho funcional de projetos de software, considerando as funcionalidades implementadas, sob o ponto de vista do usuário. Tamanho funcional é definido como tamanho do software derivado pela quantificação dos requisitos funcionais do usuário (Dekkers, 2003). A contagem de Pontos de Função é independentemente da metodologia de desenvolvimento e da plataforma utilizadas no desenvolvimento da aplicação. Assim, a autora recomenda a utilização da métrica Pontos de Função nas estimativas de tamanho de projetos de software. A autora tem utilizado a métrica para estimar os projetos dos clientes da organização Serviço Federal de Processamento de Dados (SERPRO) desde 2003, tendo obtido excelentes resultados. A seção seguinte apresenta o método Contagem Estimativa de Pontos de Função (CEPF), utilizado para estimar o tamanho de projetos de software. Contagem Estimativa de Pontos de Função Antes de definir o método de estimativas CEPF, é importante destacar que estimar significa utilizar o mínimo de tempo e esforço para se obter um valor aproximado dos Pontos de Função do projeto de software investigado (Meli, 1999). Assim, para evitar confusão, é recomendável sempre fazer uma distinção entre os termos e conceitos: Contagem de Pontos de Função e Estimativa de Pontos de Função. Contagem de Pontos de Função: significa medir o tamanho do software por meio do uso das regras de contagem do IFPUG (IFPUG, 2005); Estimativa de Pontos de Função: significa fornecer uma avaliação aproximada do tamanho de um software utilizando métodos diferentes da Contagem de Pontos de Função do IFPUG. Além do método Contagem indicativa de Pontos de Função, existem diversos métodos para estimar tamanho de projetos em Pontos de Função, descritos na literatura, dentre outros: Contagem Indicativa, Contagem Indicativa Inteligente, Estimativas Percentuais. O método CEPF visa aferir o tamanho em PF de maneira simplificada, com base no conhecimento dos requisitos iniciais do projeto. Inicialmente, os requisitos funcionais iniciais documentados nas propostas comerciais, nos documentos de visão, ou em qualquer especificação inicial do sistema do usuário são mapeados nos tipos funcionais da Análise de Pontos de Função (APF): Arquivo Lógico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta Externa (CE) e Saída Externa (SE). Posteriormente, os Pontos de Função são associados a cada função identificada, baseando-se nas tabelas de complexidade e de contribuição funcional do CPM. O estimador deve realizar uma leitura no documento inicial de requisitos, buscando informações relevantes para a identificação de processos elementares. O processo elementar é definido como a menor unidade de atividade significativa para o usuário (IFPUG, 2005). O processo elementar deve ser completo em si mesmo, independente e deixar a aplicação em um estado consistente (IFPUG, 2005). Uma vez identificado o processo elementar, o estimador deve buscar o entendimento deste para classificá-lo em Entrada Externa, Consulta Externa ou Saída Externa. Adicionalmente, o estimador deve descobrir os dados associados ao processo elementar, visando a determinação da complexidade funcional da função identificada. Caso não seja possível a identificação da complexidade da funcionalidade em questão, recomenda-se a utilização da complexidade Média. Na análise do processo elementar também são identificados, os grupos de dados lógicos da aplicação, que são classificados como Arquivos Lógicos Internos ou Arquivos de Interface Externa. Caso não seja possível a identificação da complexidade da função de dados em questão, recomenda-se a utilização da complexidade Simples. A seguir são apresentadas dicas para ajudar no mapeamento dos requisitos funcionais da aplicação nos tipos funcionais da APF. As necessidades e funcionalidades especificadas para o projeto, contidas no documento inicial de requisitos, devem ser enquadradas em uma das seguintes tabelas: Tabela 1 - Contagem dos Arquivos Lógicos Internos (ALIs): Banco de Dados Lógico da Aplicação (tabelas e arquivos mantidos pela aplicação). Considerações: Identifique os grupos de dados lógicos de aplicação nos modelos de dados ou diagrama de classes ou a partir dos requisitos funcionais, descritos nos documentos de requisitos (Documento de Visão, Relação de Casos de Uso, etc.). Não considere arquivos físicos, arquivos de índices, arquivos de trabalho e tabelas de relacionamento sem atributos próprios (tabelas que existem para quebrar o relacionamento nxn e apenas transportam as chaves estrangeiras). As entidades fracas também não são consideradas um ALI. Se possível, tente descobrir os atributos lógicos, campos reconhecidos pelo usuário, e subgrupos de dados existentes para obter a complexidade funcional, segundo as regras de contagem do CPM (IFPUG, 2005). Caso não seja possível, a experiência tem mostrado que a maioria dos ALIs dos sistemas são de complexidade Simples. Nº ALIs Simples: X 7 PF Nº ALIs Médio: X 10 PF Nº ALIs Complexo: X 15 PF Total PF da Tabela 1: Tabela 1. Identificação dos Arquivos Lógicos Internos da Aplicação Tabela 2 - Contagem de Arquivos de Interface Externa (AIEs): Banco de Dados de outras Aplicações, apenas referenciados pela aplicação que está sendo estimada (tabelas e arquivos mantidos por outra aplicação). Considerações: Identifique os grupos de dados lógicos de outras aplicações referenciados pela aplicação que está sendo estimada. Freqüentemente, o referenciamento de dados ocorre para a validação de informações em cadastros ou consultas. Algumas vezes, relatórios ou consultas referenciam dados externos de outras aplicações, também considerados AIEs. Não são considerados arquivos físicos, arquivos de índice, arquivos de Edição 02 Engenharia de Software Magazine 27
4 trabalho, tabelas de relacionamento sem atributos próprios e entidades fracas. A experiência tem mostrado que praticamente 100% dos AIEs dos sistemas são Simples. Porque, segundo o CPM (IFPUG, 2005), são considerados para a determinação da complexidade funcional do AIE apenas os atributos referenciados pela aplicação que está sendo contada. Nº AIEs Simples: X 5 PF Nº AIEs Médio: X 7PF Nº AIEs Complexo: X 10 PF Total PF da Tabela 2: Tabela 2. Identificação dos Arquivos de Interface Externa da Aplicação Tabela 3 - Contagem de Entradas Externas (EEs): Funcionalidades que mantêm os Arquivos Lógicos Internos (ALIs) ou alteram o comportamento da aplicação. Considerações: Identifique as funcionalidades de inclusão, alteração e exclusões de dados. Conte separadamente as inclusões, alterações e exclusões de dados, isto é, cada função independente de inclusão ou alteração ou exclusão deve ser contada separadamente. A aplicação possui funções de entrada de dados que alteram o comportamento dela, por exemplo: processamentos batch, ou processamento de informações de controle? Caso positivo, estas funções também devem ser identificadas como Entradas Externas. Se você não possui conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Entradas Externas identificadas com complexidade Média. Nº EEs Simples: X 3 PF Nº EEs Média: X 4 PF Nº EEs Complexa: X 6 PF Total PF da Tabela 3: Tabela 3. Identificação das Entradas Externas da Aplicação Tabela 4 - Contagem de Consultas Externas (CEs): funcionalidades que apresentam informações para o usuário sem a utilização de cálculos ou algoritmos. São os processos elementares do tipo lê - imprime, lê - apresenta dados, incluindo consultas, relatórios, geração de disquetes ou CDs, downloads, entre outros. Considerações: Você está desenvolvendo uma função para apresentar informações para o usuário: uma consulta, relatório, browse, listbox, download, geração de um arquivo, geração de CD ou de disquete? Esta função não possui cálculos ou algoritmos para derivação dos dados referenciados nem altera um Arquivo Lógico Interno, nem muda o comportamento do sistema? Caso positivo, estas funções devem ser identificadas como Consultas Externas. Caso não haja conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Consultas Externas com complexidade Média. Nº CEs Simples: X 3 PF Nº CEs Média: X 4 PF Nº CEs Complexa: X 6 PF Total PF da Tabela 4: Tabela 4. Identificação das Consultas Externas da Aplicação Tabela 5 - Contagem de Saídas Externas (SEs): Funcionalidades que apresentam informações para o usuário com utilização de cálculos ou algoritmos para derivação de dados ou atualização de Arquivos Lógicos Internos ou mudança de comportamento da aplicação. São as consultas ou relatórios com totalização de dados, relatórios estatísticos, gráficos, geração de disquetes com atualização log, downloads com cálculo de percentual, entre outros. Considerações: Você está desenvolvendo uma funcionalidade para apresentar informações para o usuário: uma consulta ou relatório com totalização de dados, etiquetas de código de barras, gráficos, relatórios estatísticos, download com percentual calculado, geração de arquivo com atualização de log? Caso positivo, estas funções devem ser identificadas como Saídas Externas. Observe que esta função deve ter cálculos ou algoritmos para processar os dados referenciados nos arquivos lógicos ou atualizar campos (normalmente indicadores) nos arquivos ou mudar o comportamento da aplicação. Caso não haja conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Saídas Externas com complexidade Média. Nº SEs Simples: X 4 PF Nº SEs Média: X 5 PF Nº SEs Complexa: X 7 PF Total PF da Tabela 5: Tabela 5. Identificação dos Saídas Externas da Aplicação A Estimativa de tamanho do projeto em PFs deve ser gerada totalizando-se os PFs obtidos nas Tabelas 1, 2, 3, 4, e 5. Uma aplicação da Contagem Estimativa de Pontos de Função Esta seção tem como propósito apresentar um exemplo utilizando o método CEPF, bem como a derivação das estimativas de esforço e prazo, a partir da estimativa de tamanho do projeto em PF. No exemplo apresentado, é descrito um sistema hipotético, parte de um sistema real, visando apresentar uma visão geral de um procedimento de estimativas de maneira prática. Suponha que o setor de treinamento de uma empresa solicitou um sistema, denominado STREINA, para apoiar as atividades de planejamento e acompanhamento das atividades de capacitação dos funcionários. A Tabela 6 apresenta 28 Engenharia de Software Magazine Análise de pontos de função
5 as necessidades e funcionalidades do STREINA, retiradas do Documento de Visão do projeto. Além das funcionalidades apresentadas na Tabela 6, devese considerar os requisitos de cadastro de usuários e controle de acesso da aplicação. Estas funcionalidades estarão disponíveis para o perfil administrador do sistema. Para facilitar o entendimento da aplicação da CEPF, a Tabela 7 mostra a contribuição para a contagem de PFs não ajustados dos tipos funcionais da APF. A complexidade funcional das funcionalidades identificadas é inferida em uma contagem estimativa, quando não se possui informação suficiente do projeto para aplicar as regras de contagem do CPM. Conforme mencionado, recomenda-se utilizar a complexidade Simples para os Arquivos Lógicos (ALI e AIE) e a complexidade Média para as Funções Transacionais (EE, CE, SE). Aplicando-se o método Contagem Estimativa de Pontos de Função, tem-se o resultado apresentado na Tabela 8. Totalizando o tamanho em PFs das funcionalidades descritas na Tabela 8, tem-se 170 PFs não ajustados. Suponha que o fator de ajuste da contagem seja de 1,10. O fator de ajuste da contagem de PF é determinado com base na avaliação das 14 Características Gerais dos Sistemas, que descrevem as funcionalidades gerais das aplicações, por exemplo: performance, reuso, usabilidade, etc. O manual de práticas de contagem (CPM) apresenta a descrição das características e de suas ponderações, denominadas níveis de influência. O cálculo do PF Ajustado é obtido multiplicando-se os PFs Não Ajustados pelo Fator de Ajuste. Assim, temos 187 Pontos de Função Ajustados estimados. De posse da estimativa de tamanho, procede-se com a geração da estimativa de esforço. Neste exemplo, utiliza-se o modelo simplificado de estimativas de esforço, descrito por Hazan em Para isto, deve-se obter um índice de produtividade por meio de análise do banco de dados de histórico de projetos da organização, observando-se os atributos do projeto em questão e o esforço realizado em projetos similares. Este projeto é pequeno (menos de 200 PFs) e será desenvolvido em JAVA por uma equipe com experiência intermediária na plata- Id Func. F 1.1 F 1.2 F 1.3 F 1.4 F 1.5 F 1.6 F 1.7 F 1.8 F 1.9 F 1.10 F 1.11 Necessidade 1 Controlar capacitações Descrição das Funcionalidades/atores envolvidos Cadastrar evento de capacitação Planejar evento de capacitação Planejar cronograma de capacitação Consultar cronograma de capacitação Consultar eventos de capacitação por data e local Consultar detalhes de um evento de capacitação Informar resultado da avaliação de um evento de capacitação Emitir Certificado de Participantes Cadastrar avaliação do evento de capacitação (após treinamento) Participantes do treinamento Consultar acompanhamento de comunidade capacitada Gerar Consultas Gerenciais (Gráficos e Relatórios) de Capacitação Gerente Tabela 6. Funcionalidades do Sistema de Treinamentos (STREINA) Descrição do Complexidade Benefício Crítico Tipo Funcional Simples Média Complexa Arquivo Lógico Interno (ALI) 7 PFs 10 PFs 15 PFs Arquivo de Interface Externa (AIE) 5 PFs 7 PFs 10 PFs Entrada Externa (EE) 3 PFs 4 PFs 6 PFs Saída Externa (SE) 4 PFs 5 PFs 7 PFs Consulta Externa (CE) 3 PFs 4 PFs 6 PFs Tabela 7. Contribuição para Contagem de PF dos Tipos Funcionais da APF Edição 02 Engenharia de Software Magazine 29
6 Descrição da Função Tipo Funcional Complexidade Tamanho (PF) Usuários ALI Simples 7 PF Incluir usuário EE Simples 3 PF Alterar usuário EE Simples 3 PF Excluir usuário EE Simples 3 PF Lista de usuários CE Simples 3 PF Consultar usuários CE Simples 3 PF Controle de acesso da aplicação SE Simples 4 PF Alterar senha EE Simples 3 PF Esqueceu senha SE Simples 4 PF Capacitação ALI Média 10 PF Incluir evento de capacitação EE Média 4 PF Alterar evento de capacitação EE Média 4 PF Planejar evento de capacitação EE Média 4 PF Consultar plano evento capacitação CE Média 4 PF Definir cronograma de capacitação EE Média 4 PF Consultar cronograma evento capacitação SE Média 5 PF Consultar eventos de capacit. por data e local SE Média 5 PF Consultar detalhes de evento de capacitação CE Complexa 6 PF Incluir participantes para evento EE Média 4 PF Alterar participantes para evento EE Média 4 PF Excluir participantes para evento EE Simples 3 PF Consultar participantes cadastrados no evento CE Média 4 PF Enviar para para participação do evento SE Média 5 PF Informar avaliação de participante - resultados EE Simples 3 PF Consultar avaliação de participante - resultados CE Média 4 PF Emitir Certificado para o Participante SE Média 5 PF Lista de Participantes com Emissão de Certificado Pendente CE Simples 3 PF Avaliação de Evento de Capacitação ALI Simples 7 PF Cadastrar avaliação de evento de capacitação EE Simples 3 PF Alterar avaliação de evento de capacitação EE Simples 3 PF Consultar avaliação de evento de capacitação CE Simples 3 PF Consultar dados de acompanhamento de comunidade capacitada detalhada SE Média 5 PF Enviar de notificação para avaliação do evento SE Média 5 PF Consultas Gerenciais (3 gráficos e 3 relatórios com dados calculados) 6 SE Média 30 PF Tabela 8. Estimativa de Tamanho do Sistema de Treinamentos (STREINA) forma. Assim, o índice de produtividade hipotético utilizado é o de 12 horas/pf. Então, a estimativa de esforço é de: 187 x 12 = 2244 HH (homens_hora). O próximo passo é a estimativa de prazo, aplicando-se a fórmula de Caper Jones (1998) de aproximação de Tempo Ótimo de Desenvolvimento (Td) com um expoente t = 0,34, tem-se: Td = 187 0,34 = 5,92 meses. Considerando-se o prazo estimado de 6 meses e o esforço estimado de 2244 HH, o próximo passo é a estimativa do tamanho da equipe de desenvolvimento ideal para atuar no projeto em questão. Segundo Jones (1997), a produtividade média diária no Brasil é de 6 horas/dia. E ainda, em média um mês possui 22 dias úteis. Então, tem-se: prazo = (esforço em HH) / (tamanho equipe * 6 * 22). Então, aplicando-se a fórmula, obtém-se o tamanho da equipe ideal para atuar no projeto, que deve ser constituída por três recursos, incluindo desenvolvimento e gestão. O COCOMO II também possui fórmulas para o cálculo do Td, baseadas em parâmetros de calibragem e de mapeamento (Boehm, 2000). É importante destacar que as organizações devem ter ou construir um banco de dados histórico, contendo informações de projetos concluídos, com a finalidade de gerar as estimativas de prazo, custo e esforço com uma acurácia adequada. Aplicando-se o COCOMO II para as estimativas de esforço e prazo do STREINA, tem-se o seguinte: Fator de Produtividade Linear (Pessoas_Mês/KSLOC) para desenvolvimento WEB: 2,51 (Roetzheim, 2005); Fator Exponencial para desenvolvimento WEB: 1,030 (Roetzheim, 2005) 1 PF = 33 SLOC em JAVA (Jons, 1997); Esforço = Fator de Produtividade x KSLOC Fator Exponencial (Roetzheim, 2005); Esforço = 2,51 x [(33 x 170)/1000] 1,030 = 30 Engenharia de Software Magazine Análise de pontos de função
7 14,83 Pessoas_Mês. Note o que o insumo para o COCOMO é PF Não Ajustado, por isso considerou-se 170 PFs; O COCOMO considera o dia com 7h e o mês com 22 dias úteis, então o esforço em HH é o seguinte: 14,83 * 7 * 22 = 2284 HH. Note que o cálculo do esforço estimado é próximo ao 2244 HH obtido pelo modelo simplificado; Prazo (Td) = 2,5 x (Esforço 0,32 ) = 5,9 meses (Aguiar, 1999); Note que o prazo estimado pela fórmula de Caper Jones 5,92 meses, ficou bastante próximo do prazo estimado pelo COCOMO. Na prática, torna-se importante aplicar mais de um modelo de estimativas e analisar-se os resultados obtidos. Caso fosse utilizada a fórmula de esforço da ferramenta Cost Xpert, apresentada por Aguiar em 1999, o resultado seria o seguinte: E= 2,4 x (V 1,05 ) = 14,68 Pessoa_Mês, sendo V o tamanho do projeto em KSLOC. Note que este é bem próximo do esforço estimado, utilizando-se os parâmetros propostos por Roetzheim em Caso fosse utilizado o esforço de 14,68 como insumo para o cálculo do prazo, este continuaria sendo estimado em 5,9 meses. A estimativa de custo deve considerar o valor da hora da equipe alocada ao projeto (custo de pessoal), bem como outros custos de ambiente, ferramentas, deslocamentos, consultoria, etc. Algumas empresas possuem dados históricos de custo por PF de projetos concluídos, possibilitando a derivação direta da estimativa de custo a partir da estimativa de volume em Pontos de Função. A estimativa de recursos computacionais críticos em um projeto WEB deve considerar, dentre outros, a disponibilidade dos servidores utilizados para desenvolvimento, homologação e produção do sistema e outros recursos de hardware relevantes. É importante ressaltar que após a geração das estimativas, deve-se adicionar um percentual, prevendo uma evolução natural dos requisitos do projeto. Este percentual deve ser obtido por meio de dados de históricos de um indicador de estabilidade de requisitos de projetos concluídos da organização. As ferramentas de estimativas também trabalham desta forma, solicitando que o usuário (estimador) forneça tal percentual. No entanto, devido à ausência de dados históricos analisados para tal indicador, a autora tem se baseado em análise de publicações e sua experiência profissional. A autora tem utilizado um percentual de 20% a 35% para os projetos com Documento de Visão. Esta variação de percentual é diretamente proporcional ao detalhamento do Documento de Visão e conhecimento dos requisitos do projeto pelo analista de negócios. Para alguns projetos estimados, baseados apenas em atas de reunião ou documentos menos detalhados, foi utilizado o percentual de 40%. Em projetos pequenos com documentos de requisitos com um detalhamento adequado, o percentual varia de 10% a 25%. A CEPF deve ser refinada, conforme o conhecimento dos requisitos do projeto evolui, em marcos definidos no plano do projeto. Assim, não há retrabalho no processo de estimativas, as estimativas de PF anteriores não são descartadas e sim refinadas, conforme os requisitos do projeto evoluem. Conclusão A indústria tem demonstrado dificuldade na previsibilidade de prazo e custo dos projetos de software. No entanto, muitas organizações ainda estimam projetos, sem a utilização de processo, de maneira artesanal, baseando-se apenas na opinião dos líderes ou gerentes do projeto. De fato, o método de estimar projetos baseando-se na opinião de especialistas é bastante eficaz. O problema é quando a equipe não possui especialistas no domínio do projeto em questão. Este trabalho apresentou um processo para as organizações nas estimativas de projetos de software, utilizando métodos aderentes às melhores práticas do CMMI nível 2. Espera-se que com a utilização de processos, o cenário caótico em relação à previsibilidade de projetos seja melhorado. O método Contagem Estimativa de Pontos de Função tem sido utilizado com sucesso pela autora, além deste apoiar nas estimativas dos projetos, este também tem se mostrado bastante eficaz no suporte ao processo de engenharia de requisitos. Referências AGUIAR, M. Estimativas Confiáveis de Prazos para Gerentes de Projetos. Developer s Magazine, Maio 1999, pp AGARWAL, R. et al. Estimating Software Projects. ACM SIGSOFT, Software Engineering Notes vol 26 nº4, July 2001, pp BOEHM, B.W. Software Cost Estimation With COCOMO II. Prentice Hall, New Jersey, DEKKERS, C. Measuring the logical or functional Size of Software Projects and Software Application. Spotlight Software, ISO Bulletin May 2003 pp HAZAN C.; STAA, A. v. Análise e Melhoria de um Processo de Estimativas de Tamanho de Projetos de Software. Monografias em Ciências da Computação nº 04/05, Departamento de Informática PUC-Rio, ISSN , Fevereiro IFPUG. Counting Practices Manual. Version 4.2.1, January, JONES, C. Applied Software Measurement: Assuring Productivity and Quality. Prentice Hall, Second Edition, JONES, C. Estimating Software Costs. McGraw-Hill, MELI, R.; SANTILLO, L. Function Point Estimation Methods: A Comparative Overview. Proceedings of FESMA 99, Amsterdam, Netherlands, October 1999, pp PRESSMAN, R. S. Engenharia de Software, 6ª edição, MC Graw Hill, São Paulo, ROETZHEIM, W. Estimating and Managing Project Scope for New Development. Crosstalk The Journal of Defense Software Engineering, April 2005, pp Edição 02 Engenharia de Software Magazine 31
Como Definir Processos de Estimativas aderentes às Melhores Práticas do CMMI?
Como Definir Processos de Estimativas aderentes às Melhores Práticas do CMMI? Claudia Hazan Serviço Federal de Processamento de Dados (SERPRO) Cenário Sintomas da Crise do Software As estimativas de prazo
Anexo VII GUIA DE CONTAGEM DE PONTO DE FUNÇÃO
1. Objetivos Este documento tem como propósito apresentar, de forma resumida, um roteiro contagem de Pontos de Função que usou como referência o Manual de Práticas e Contagens, versão 4.3.1 (CPM - Counting
Uma Aplicação da Análise de Pontos de Função
Uma Aplicação da Análise de Pontos de Função no Planejamento e Auditoria de Custos de Projetos de Desenvolvimento de Sistemas Renato Cesar da Cunha Ferreira renato.cesar@papem.mar.mil.br Pagadoria de Pessoal
Introdução - Cenário
Como evitar Armadilhas em Contratos de Software Baseados na Métrica Pontos de Função Claudia Hazan Serviço Federal de Processamento de Dados (SERPRO) 1 Introdução - Cenário Demanda crescente por Sistemas
Como evitar armadilhas em. contratos de fábricas de software. Doutrina
Como evitar armadilhas em Doutrina contratos de fábricas de software Claudia Hazan 1 Introdução A Tecnologia da Informação tem sido utilizada em vários segmentos do mercado na automatização de processos,
Manual de Métricas de Software do <SISP> Análise de Pontos de Função
Manual de Métricas de Software do Análise de Pontos de Função Histórico de Versões Data Versão Descrição Autor Revisor Aprovado por 11/07/10 1 Manual para auxílio na contagem de pontos de função
Roteiro SERPRO de Métricas para Contratos de Software. Data Versão Descrição Autor Revisor Aprovado por
Roteiro SERPRO de Métricas para Contratos de Software Histórico de Versões Data Versão Descrição Autor Revisor Aprovado por 30/04/2010 1.0 Roteiro Corporativo de Métricas para Contratos de Sistemas Claudia
Uma Aplicação da Análise de Pontos de Função no Planejamento e Auditoria de Custos de Projetos de Desenvolvimento de Sistemas
Uma Aplicação da Análise de Pontos de Função no Planejamento e Auditoria de Custos de Projetos de Desenvolvimento de Sistemas Renato Cesar da Cunha Ferreira 1, Claudia Hazan 2 1 Pagadoria de Pessoal da
Uso de Métricas em Contratos de Fábrica de Software Roteiro de Métricas do SISP 2.0
Uso de Métricas em Contratos de Fábrica de Software Roteiro de Métricas do SISP 2.0 Claudia Hazan claudia.hazan@serpro.gov.br claudia.hazan@serpro.gov.br 1 Objetivos Definir a Métrica Pontos de Função
Guia de Contagem APF Versão 1.00
Versão 1.00 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 20/11/2010 1.00 Criação do Guia de Contagem APF Célio Santana / Gustavo Santos Guia de Contagem APF ATI www.ati.pe.gov.br Pág. 2 de 65 SUMÁRIO
Eduardo Alves de Oliveira. eduaopec@yahoo.com.br IME Instituo Militar de Engenharia LES PUC-Rio Laboratório de Engenharia de Software da Puc - Rio
Eduardo Alves de Oliveira eduaopec@yahoo.com.br IME Instituo Militar de Engenharia LES PUC-Rio Laboratório de Engenharia de Software da Puc - Rio Processo de Desenvolvimento de Software; Produtividade:
Proposta de Utilização de FDD e APF para Melhoria do Processo de Software
Proposta de Utilização de FDD e APF para Melhoria do Processo de Software Cristiane Ribeiro da Cunha, Cristina D Ornellas Filipakis Curso de Sistemas de Informação Centro Universitário Luterano de Palmas
Claudia Hazan, MSc. Claudinhah@yahoo.com
Implementação de um Processo de Medições de Software Claudia Hazan, MSc. Certified Function Point Specialist Claudinhah@yahoo.com Agenda Introdução Qualidade de Software Medições de Software Análise de
Roteiro de Métricas SERPRO. Roteiro SERPRO de Contagem de Pontos de Função e Estimativas
Roteiro SERPRO de Contagem de Pontos de Função e Estimativas 1 Histórico de Versões Data Versão Descrição Autor Revisor Aprovado por 15/04/2010 1.0 Roteiro Corporativo de Contagem de Pontos de Função.
Function Point Analysis: Uma Aplicação na Gestão de Projetos de Manutenção de Software
Function Point Analysis: Uma Aplicação na Gestão de Projetos de Manutenção de Software Claudia Hazan, CFPS CENÁRIO MANUTENÇÃO DE SOFTWARE Definição Desenvolvimento Manutenção GERÊNCIA DA MANUTENÇÃO Planejar
Análise de Ponto de Função APF. Aula 08
Análise de Ponto de Função APF Aula 08 Agenda Parte 01 Introdução a Métricas de Software Parte 02 A Técnica de APF Técnicas de Contagem Verificação de Requisitos Estimativas (Modelos e Ferramentas) Gerenciamento
Synergia. Synergia. Treinamento em Análise de Pontos de Função 1
Treinamento em Análise de Pontos de Função 1 Synergia Synergia O Synergia é o laboratório de Engenharia de Software do Departamento de Ciência da Computação da Universidade Federal de Minas Gerais (UFMG),
Roteiro de Métricas de Software do SISP Versão 1.0
Roteiro de Métricas de Software do SISP Versão 1.0 Brasília, 29 de novembro de 2010. Roteiro de Métricas de Software do SISP 2 Presidente da República Luiz Inácio Lula da Silva Ministério do Planejamento,
Guia de Contratação em Pontos de Função. Versão 1.0
Guia de Contratação em Pontos de Função Página: 2 de 20 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 14/02/2014 0 Criação do documento a partir dos Editais de Fábrica por linhas de negócio Célula
Plano de Projeto. 1. Introdução. 2. Escopo do Projeto. Projeto: Biblioteca Central da UFES. Versão: 2.0. Responsável: Ricardo de Almeida Falbo
Plano de Projeto Projeto: Biblioteca Central da UFES Versão: 2.0 Responsável: Ricardo de Almeida Falbo 1. Introdução Este documento apresenta a versão 2.0 do Plano de Projeto para o projeto de desenvolvimento
Instituto de Ciências Matemáticas e de Computação. PONTOS DE FUNÇÃO Uma medida funcional de tamanho de software N 0 105 RELATÓRIOS TÉCNICOS DO ICMC
Instituto de Ciências Matemáticas e de Computação ISSN - 0103-2569 PONTOS DE FUNÇÃO Uma medida funcional de tamanho de software WAINE TEIXEIRA JÚNIOR ROSELY SANCHES N 0 105 RELATÓRIOS TÉCNICOS DO ICMC
Análise de Ponto de Teste. Uma proposta de adaptação
Análise de Ponto de Teste Uma proposta de adaptação Agenda Histórico O que é Análise de Ponto de Teste (APT)? A Técnica APT Dificuldades no uso da APT Proposta de adaptação Análise de Ponto de Teste Adaptada
Desmistificando Pontos de Função: Entendendo a Terminologia por Carol A. Dekkers, Quality Plus Technologies, Inc. email: dekkers@qualityplustech.
Desmistificando Pontos de Função: Entendendo a Terminologia por Carol A. Dekkers, Quality Plus Technologies, Inc. email: dekkers@qualityplustech.com Abstrato: A análise de Pontos de Função é uma abordagem
Avaliação do Tamanho Funcional de Ferramentas de E-learning
ISSN 0103-9741 Monografias em Ciência da Computação n 16/05 Avaliação do Tamanho Funcional de Ferramentas de E-learning Claudia Hazan Hugo Fuks Carlos José Pereira de Lucena Departamento de Informática
Estimativa de Projetos de Software com Pontos de Função
Estimativa de Projetos de Software com Pontos de Função Intercambio Empresarial FUMSOFT 29/05/12 Belo Horizonte MG Brasil Sejam Todos Bem-Vindos 1 FATTO Consultoria e Sistemas Missão: Ajudar nossos clientes
Núcleo de Métricas: Alcançando a Excelência na Governança de TI
Núcleo de Métricas: Alcançando a Excelência na Governança de TI Gustavo Siqueira Simões - PMP e CFPS http://www.linkedin.com/in/gustavosimoes gustavo.simoes@fattocs.com.br skype: gustavosimoes +55(11)
Roteiro de Métricas de Software da ANEEL - v1.0
Roteiro de Métricas de Software da ANEEL - v1.0 Brasília DF Controle de Versão Data Versão Descrição Autor Revisor Aprovado por 24/09/2012 1.0 Emissão Inicial João Celestino 2 Sumário 1 Introdução... 4
PFI. Pontos de Função de Implementação. BFPUG Brazilian Function Point Users Group. Versão 1.00 22/04/2004. Mauricio Aguiar.
PFI Pontos de Função de Implementação Equipe Mauricio Aguiar Valter Braghin Nelson Camargo Irapuã da Costa Jr. Gabriel Dalla Lana Elina Madeira Versão 1.00 22/04/2004 BFPUG Brazilian Function Point Users
V Simpósio Internacional de Recife, PE - Brasil 3-5/11/2003. Especificação de Indicadores para Gestão de Requisitos
Especificação de Indicadores para Gestão de Requisitos Claudia Hazan, MSc.,CFPS claudinhah@yahoo.com Cenário Agenda Modelo CMM e CMMI Gerência de Requisitos Indicadores de Rastreabilidade Indicadores de
Síntese das discussões do fórum Livro-APF: Julho/2010
Síntese das discussões do fórum Livro-APF: Julho/2010 Assunto: Estimativa de Aumento de Produtividade Data: 01/07/2010 Link: http://br.groups.yahoo.com/group/livro-apf/message/2577 Dúvida: Existe alguma
Modelos de Negócio Baseados em Pontos de Função
Modelos de Negócio Baseados em Pontos de Função Mauricio Aguiar e Diana Baklizky ti MÉTRICAS Av. Rio Branco, 181/1910 Rio de Janeiro, RJ R. Domingos de Morais, 2243/36 São Paulo, SP Brasil www.metricas.com.br
MINISTÉRIO DA INTEGRAÇÃO NACIONAL SECRETARIA EXECUTIVA DEPARTAMENTO DE GESTÃO ESTRATÉGICA COORDENAÇÃO-GERAL DE TECNOLOGIA DA INFORMAÇÃO ENCARTE R
ENCARTE R Estimativa de de Software Estimativa de de Software: Contratação de Serviços de Fábrica de Software Página 1 de 10 SUMÁRIO 1 REFERÊNCIAS... 3 1 INTRODUÇÃO... 3 3.1 ESTIMATIVA PRELIMINAR... 4
Software na medida certa: desmistificando pontos de função
FATTO Consultoria e Sistemas - www.fattocs.com Software na medida certa: desmistificando pontos de função Guilherme Siqueira Simões +55 (27) 8111-7505 guilherme.simoes@fattocs.com.br Fatto Consultoria
Gerando Estimativas Confiáveis com COCOMO II e o Banco de Dados do ISBSG
www.metricas.com.br Gerando Estimativas Confiáveis com COCOMO II e o Banco de Dados do ISBSG Mauricio Aguiar, CFPS PSM Qualified Instructor ti MÉTRICAS Ltda DEZ 2002 mauricio@metricas.com.br www.metricas.com.br
Métricas de software: Comparação entre Pontos de Função e Cocomo II Software metrics: Comparing Function Points and Cocomo II
Métricas de software: Comparação entre Pontos de Função e Cocomo II Software metrics: Comparing Function Points and Cocomo II Augusto Nogueira Zadra 1 Erivelton Oliveira Carvalho 2 Joécio Farley Santos
TÉCNICAS DE ESTIMATIVAS DE CUSTOS ANÁLISE POR PONTOS DE FUNÇÃO. Alessandro Kotlinsky Deise Cechelero Jean Carlos Selzer. Resumo
TÉCNICAS DE ESTIMATIVAS DE CUSTOS ANÁLISE POR PONTOS DE FUNÇÃO Alessandro Kotlinsky Deise Cechelero Jean Carlos Selzer Resumo Este artigo descreve os conceitos gerais relacionados a técnica de Análise
Roteiro de Métricas de Software do SISP Versão 2.0
Roteiro de Métricas de Software do SISP Versão 2.0 Presidenta da República Dilma Vana Rousseff Ministra do Ministério do Planejamento, Orçamento e Gestão Miriam Aparecida Belchior Secretário de Logística
Roteiro de Métricas de Software do SISP Versão 2.1
Roteiro de Métricas de Software do SISP Versão 2.1 Presidenta da República Dilma Vana Rousseff Ministro do Ministério do Planejamento, Orçamento e Gestão Nelson Barbosa Secretário de Logística e Tecnologia
Síntese das discussões do fórum Livro-APF: Abril/2012
Síntese das discussões do fórum Livro-APF: Abril/2012 Nessa síntese foram abordados, em 127 mensagens, os seguintes assuntos: Correlação entre a estimativa de tamanho do novo sistema, o projeto e a migração
Medição de tamanho para Sistemas de Data Mart
1 Universidade Católica de Brasília Programa de Pós-Graduação em Gestão do Conhecimento e Tecnologia da Informação Medição de tamanho para Sistemas de Data Mart Angélica Toffano Seidel Calazans Orientadores:
Guia de Contagem. Análise de Pontos de Função ANEXO 10. Última atualização em: 18/09/2011
ANEXO 10 Análise de Pontos de Função Guia de Contagem Última atualização em: 18/09/2011 Praça dos Açorianos, s/n - CEP 90010-340 Porto Alegre, RS 0 -XX - 51-3210-3100 http://www.procergs.com.br Sumário
Síntese das discussões do fórum Livro-APF: Abril/2011
Síntese das discussões do fórum Livro-APF: Abril/2011 Nessa síntese foram abordados, em 96 mensagens, os seguintes assuntos: Contagem em manutenção de Sistemas Legados Processos Elementares distintos de
Histórico de Revisão. Data Versão Descrição Autor
Histórico de Revisão Data Versão Descrição Autor 04/2015 1.0 Elaboração do manual. Márcia Regina Guiotti Bomfim José Romildo Andrade Página 2 de 45 Sumário SUMÁRIO... 3 1. OBJETIVO... 5 2. REFERÊNCIAS
Métricas para Contratação de Desenvolvimento de Software
Métricas para Contratação de Desenvolvimento de Software Guilherme Siqueira Simões guilherme.simoes@fattocs.com.br SEMANATIC 2015 I Semana Estadual de Tecnologia da Informação e Comunicação TIC Vitória-ES,
ESTIMATIVA DE TAMANHO DE SOFTWARE POR MEIO DA TÉCNICA DE ANÁLISE DE PONTOS DE FUNÇÃO
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ UTFPR DIRETORIA DE PESQUISA E PÓS-GRADUAÇÃO ESPECIALIZAÇÃO EM ENGENHARIA DE SOFTWARE DANIELE WOLFART ESTIMATIVA DE TAMANHO DE SOFTWARE POR MEIO DA TÉCNICA DE