uso de metricas em contratos de fabrica de software roteiro de metricas do sisp 2.0 claudia hazan...

Uso de Métricas em Contratosde Fábrica de Software – Roteiro

de Métricas do SISP 2.0

Claudia Hazanclaudia.hazan@serpro.gov.br

claudia.hazan@serpro.gov.br 1

Objetivos

• Definir a Métrica Pontos de Função

•Apresentar as Recomendações para Contratosde Software com Pontos de Função do GovernoBrasileiro

• Discutir o uso da métrica Pontos de Função emcontratos de Desenvolvimento e de Manutençãode Sistemas - Roteiro de Métricas do SISP 2.0

• Definir a Métrica Pontos de Função

•Apresentar as Recomendações para Contratosde Software com Pontos de Função do GovernoBrasileiro

• Discutir o uso da métrica Pontos de Função emcontratos de Desenvolvimento e de Manutençãode Sistemas - Roteiro de Métricas do SISP 2.0

Análise de Pontos de Função (APF)

Pontos de Função (PF): É uma medida dedimensionamento de software através dafuncionalidade implementada em umsistema, sob o ponto de vista do usuário.

Análise de Pontos de Função

Publicado como Padrão Internacional - norma ISO/IEC 14.143:2007

Pontos de Função (PF): É uma medida dedimensionamento de software através dafuncionalidade implementada em umsistema, sob o ponto de vista do usuário.

APF - Criada em 1979 por Allan Albrecht - IBM

Grupo de Usuários - Internacional: www.ifpug.orgIFPUG - International Function Point Users Group

Regras de Contagem descritas no manual:CPM - Counting Practices Manual - Versão 4.3 - Janeiro/2010

Certificação de Especialistas:CFPS - Certified Function Point Specialist

Grupo de Usuários - Internacional: www.ifpug.orgIFPUG - International Function Point Users Group

Medir a funcionalidade requisitadae recebida pelo usuário

Medir Projetos de Desenvolvimento e deManutenção Evolutiva independentemente datecnologia utilizada

Cenário – Contratos de Software

A Instrução Normativa 04 (IN04) publicada pelo MPOG/SLTIrecomenda o uso de métricas em contratos de software.

A contratação de serviços de fábrica de software deve utilizarmétricas no planejamento da aquisição e no gerenciamento docontrato, com restrições ao uso da métrica de esforço homem-hora.

O TCU tem recomendado em Acórdãos o uso da métrica Pontos deFunção (PF) em contratos de prestação de serviços dedesenvolvimento e manutenção de software.

A Métrica (PF) tem sido usada como base para contratos desoftware em muitas organizações.

A Instrução Normativa 04 (IN04) publicada pelo MPOG/SLTIrecomenda o uso de métricas em contratos de software.

A contratação de serviços de fábrica de software deve utilizarmétricas no planejamento da aquisição e no gerenciamento docontrato, com restrições ao uso da métrica de esforço homem-hora.

O TCU tem recomendado em Acórdãos o uso da métrica Pontos deFunção (PF) em contratos de prestação de serviços dedesenvolvimento e manutenção de software.

A Métrica (PF) tem sido usada como base para contratos desoftware em muitas organizações.

PF mede o tamanho funcional do projeto de software,independentemente da tecnologia e metodologiautilizadas.

PF torna possível a estimativa de tamanho de projetosde software nas fases iniciais do ciclo de vida.

O Manual de Práticas de Contagem (CPM) possuiregras objetivas para contagem de Pontos de Função.

PF considera a visão do usuário.

PF é independente da forma da modelagem dosrequisitos.

Cenário – Contratos de Software

PF mede o tamanho funcional do projeto de software,independentemente da tecnologia e metodologiautilizadas.

PF torna possível a estimativa de tamanho de projetosde software nas fases iniciais do ciclo de vida.

O Manual de Práticas de Contagem (CPM) possuiregras objetivas para contagem de Pontos de Função.

PF considera a visão do usuário.

PF é independente da forma da modelagem dosrequisitos.

Acórdão 1.782/2007 - PlenárioDeterminação

9.3.6. realize o adequado planejamento das necessidades deserviços de TI de modo a contemplar nele o levantamento daestimativa prévia de quantitativos de serviços demandados(pontos de função) por tecnologia a ser empregada tanto namanutenção quanto no desenvolvimento de sistemas,observando, assim, o disposto nos arts. 6º, inciso IX, e 7º,incisos I e § 2º, incisos I e II, da Lei 8.666/1993 quanto aoadequado nível de precisão dos serviços a serem licitados,bem como à necessária fundamentação do orçamento, quedeverá ser detalhado em quantitativos de serviçospropriamente avaliados e detalhados, nos termos da lei;

Recomendações TCU

Acórdão 1.782/2007 - PlenárioDeterminação

9.3.6. realize o adequado planejamento das necessidades deserviços de TI de modo a contemplar nele o levantamento daestimativa prévia de quantitativos de serviços demandados(pontos de função) por tecnologia a ser empregada tanto namanutenção quanto no desenvolvimento de sistemas,observando, assim, o disposto nos arts. 6º, inciso IX, e 7º,incisos I e § 2º, incisos I e II, da Lei 8.666/1993 quanto aoadequado nível de precisão dos serviços a serem licitados,bem como à necessária fundamentação do orçamento, quedeverá ser detalhado em quantitativos de serviçospropriamente avaliados e detalhados, nos termos da lei;

Acórdão nº 1.910/2007-PlenárioRecomendação

9.3.2.2. diferenciar, em sua fórmula de cálculo, os custos dospontos de função para desenvolver novas funcionalidadesdaqueles relativos a supressões ou alterações defuncionalidades existentes, utilizando, por exemplo, asseguintes alternativas que seguem:

9.3.2.2.1. definição de preço diferenciado para odesenvolvimento e a manutenção de software, considerandotambém o tipo de operação a ser realizada (inclusão,exclusão ou alteração de funcionalidade);

Recomendações TCU

9.3.2.2. diferenciar, em sua fórmula de cálculo, os custos dospontos de função para desenvolver novas funcionalidadesdaqueles relativos a supressões ou alterações defuncionalidades existentes, utilizando, por exemplo, asseguintes alternativas que seguem:

9.3.2.2.1. definição de preço diferenciado para odesenvolvimento e a manutenção de software, considerandotambém o tipo de operação a ser realizada (inclusão,exclusão ou alteração de funcionalidade);

9.3.2.2.2. adoção da forma de contagem dos pontos defunção em atividades de manutenção de softwarepreconizada pela publicação Function Point Analysis forSoftware Enhancement da Nesma - Netherlands SoftwareMetrics Users Association, entidade que aprofunda o tema eapresenta alternativas técnicas à proposta original do IFPUG,com respaldo no manual de contagem de ponto de funçãoCPM 4.2.1;

Recomendações TCU

9.3.2.2.2. adoção da forma de contagem dos pontos defunção em atividades de manutenção de softwarepreconizada pela publicação Function Point Analysis forSoftware Enhancement da Nesma - Netherlands SoftwareMetrics Users Association, entidade que aprofunda o tema eapresenta alternativas técnicas à proposta original do IFPUG,com respaldo no manual de contagem de ponto de funçãoCPM 4.2.1;

Acórdão 2.024/2007 – Plenário

9.2.2.2. prever metodologias de mensuração de serviços prestados queprivilegiem a remuneração da contratada mediante a mensuração deresultados, a exemplo da análise por Pontos de Função (métodopadronizado largamente utilizado no mercado nos dias de hoje para amensuração de serviços de desenvolvimento e manutenção desistemas, considerando as funcionalidades implementadas, sob oponto de vista do usuário), buscando eliminar a possibilidade deremunerar a contratada com base na quantidade de horas trabalhadasou nos postos de trabalho disponibilizados ou, caso tal caminho nãose mostre comprovadamente viável, restando como única opção aremuneração de serviços por horas trabalhadas, cuidar para que sejampreviamente definidos e especificados os serviços a serem executadose estabelecidos, também de antemão, os valores máximos de horasaceitáveis para cada um desses serviços, assim como explicitada ametodologia a ser utilizada para a identificação desse quantitativo dehoras;

Recomendações TCU

Acórdão 2.024/2007 – Plenário

9.2.2.2. prever metodologias de mensuração de serviços prestados queprivilegiem a remuneração da contratada mediante a mensuração deresultados, a exemplo da análise por Pontos de Função (métodopadronizado largamente utilizado no mercado nos dias de hoje para amensuração de serviços de desenvolvimento e manutenção desistemas, considerando as funcionalidades implementadas, sob oponto de vista do usuário), buscando eliminar a possibilidade deremunerar a contratada com base na quantidade de horas trabalhadasou nos postos de trabalho disponibilizados ou, caso tal caminho nãose mostre comprovadamente viável, restando como única opção aremuneração de serviços por horas trabalhadas, cuidar para que sejampreviamente definidos e especificados os serviços a serem executadose estabelecidos, também de antemão, os valores máximos de horasaceitáveis para cada um desses serviços, assim como explicitada ametodologia a ser utilizada para a identificação desse quantitativo dehoras;

Acórdão 1.274/2010 – PlenárioDeterminação

9.1.4. nos próximos editais e contratos de Tecnologia daInformação, ao utilizar mensuração de serviços, a exemploda Análise de Pontos de Função:

9.1.4.1. abstenha-se de possibilitar a remuneração tanto porponto de função quanto por homem-hora para os mesmostipos de serviço;

9.1.4.2. abstenha-se de vincular a métrica de tamanho (pontode função) à métrica de esforço (homem-hora);

Recomendações TCU

Acórdão 1.274/2010 – PlenárioDeterminação

9.1.4. nos próximos editais e contratos de Tecnologia daInformação, ao utilizar mensuração de serviços, a exemploda Análise de Pontos de Função:

9.1.4.1. abstenha-se de possibilitar a remuneração tanto porponto de função quanto por homem-hora para os mesmostipos de serviço;

9.1.4.2. abstenha-se de vincular a métrica de tamanho (pontode função) à métrica de esforço (homem-hora);

Acórdão 1.647/2010Recomendação

9.2.1. ao contratar desenvolvimento de software utilizando amétrica de Análise de Pontos de Função, evite adotar, comoúnico guia de referência para contagens, o Manual dePráticas de Contagem do IFPUG, adicionando ao contratocláusulas complementares que elucidem pontos em aberto,abordando, por exemplo, tópicos como:

9.2.1.1. diferenciação, em sua fórmula de cálculo, dos custosdos pontos de função para desenvolvimento de novasfuncionalidades daqueles relativos a supressões oualterações de funcionalidades existentes;

Recomendações TCU

9.2.1. ao contratar desenvolvimento de software utilizando amétrica de Análise de Pontos de Função, evite adotar, comoúnico guia de referência para contagens, o Manual dePráticas de Contagem do IFPUG, adicionando ao contratocláusulas complementares que elucidem pontos em aberto,abordando, por exemplo, tópicos como:

9.2.1.1. diferenciação, em sua fórmula de cálculo, dos custosdos pontos de função para desenvolvimento de novasfuncionalidades daqueles relativos a supressões oualterações de funcionalidades existentes;

9.2.1.2. diferenciação, em sua fórmula de cálculo, dos custos depontos de função para o desenvolvimento completo de umafuncionalidade (todas as fases do ciclo de desenvolvimento)daqueles necessários à execução de apenas uma fase do ciclo;

9.2.1.3. adoção de uma tabela de itens não mensuráveis;

9.2.1.4. definição das fronteiras a serem utilizadas nascontagens;

9.2.1.5. políticas para definição de: novas fronteiras, contagemde recursos reutilizáveis, remuneração de requisitos nãofuncionais e resolução de impasses acerca das contagens;

Recomendações TCU

9.2.1.2. diferenciação, em sua fórmula de cálculo, dos custos depontos de função para o desenvolvimento completo de umafuncionalidade (todas as fases do ciclo de desenvolvimento)daqueles necessários à execução de apenas uma fase do ciclo;

9.2.1.3. adoção de uma tabela de itens não mensuráveis;

9.2.1.4. definição das fronteiras a serem utilizadas nascontagens;

9.2.1.5. políticas para definição de: novas fronteiras, contagemde recursos reutilizáveis, remuneração de requisitos nãofuncionais e resolução de impasses acerca das contagens;

Como Evitar Armadilhas naGestão de Contratos de Softwarebaseados em Pontos de Função?

Roteiros de Contagem

Problemas da Utilização de PF em Contratos

• Empresas não possuem Maturidade em Gestãode Projetos.• Falta de Capacitação em Engenharia deRequisitos.• Falta de Conhecimento Adequado em Análisede Pontos de Função.

SOLUÇÃOImplantação de um Escritório de Métricas Corporativo comprofissionais especialistas em Análise de Pontos de Função e suasaplicações em Contratos e Estimativas.

Como Evitar Armadilhas?

1 Obter um Documento de Requisitos com Qualidade

O Documento de Requisitos constitui:

• um acordo comum entre o cliente e ofornecedor;

• a base para a estimativa de PF;

• a base para a construção do projeto desoftware.

Documentos de Requisitos commá qualidade ou um Pesadelo?

O Documento de Requisitos constitui:

• um acordo comum entre o cliente e ofornecedor;

• a base para a estimativa de PF;

• a base para a construção do projeto desoftware.

É fundamental garantir a Qualidade doDocumento de Requisitos.

1 Obter um Documento de Requisitos com Qualidade

Sugestão:Realizar inspeção de requisitos durante a Estimativa de Pontos deFunção. Hazan tem o aplicado o método CEPF para estimar otamanho dos projetos em PF.Como um efeito colateral desta estimativa, ela encontra defeitos nosdocumentos de requisitos, ex:• requisitos omissos,• requisitos inconsistentes,• requisitos incompletos, e• requisitos ambíguos.

HAZAN, C. et. al. É possível substituir processos de Engenharia de Requisitos porContagem de Pontos de Função? 8th International Workshop on RequirementsEngineering (WER2005), Porto, Portugal, June 2005.

2 Estabelecer Regras para Evolução de Requisitos

Requisitos de Software não permanecem “congelados”.Sugestão:Estabelecer um percentual para cada atividade do processo de software, ex: Requisitos:20%, design: 10%, implementação: 50%, teste: 15%, implantação: 5%.Quando um requisito é alterado, identificar as atividades executadas.

Exemplo: Relatório de Clientes – SE –média – 5 PF foi alterado logo após o final dafase de requisitos.Assim, a quantidade de PF para o pagamento é:Novo requisito (alterado) : SE – média – 5 PF

+ 20% do requisito original (1 PF) x 0,75 (redutor retrabalho)

Total: 5,75 PFs

Sugestão:Estabelecer um percentual para cada atividade do processo de software, ex: Requisitos:20%, design: 10%, implementação: 50%, teste: 15%, implantação: 5%.Quando um requisito é alterado, identificar as atividades executadas.

Exemplo: Relatório de Clientes – SE –média – 5 PF foi alterado logo após o final dafase de requisitos.Assim, a quantidade de PF para o pagamento é:Novo requisito (alterado) : SE – média – 5 PF

+ 20% do requisito original (1 PF) x 0,75 (redutor retrabalho)

Total: 5,75 PFs

3 Estabelecer Clausulas de Garantia da Qualidade

O CPM não estabelece regras para garantir aqualidade do projeto de software recebido.Contudo, a contagem de PF considera afuncionalidade requisitada e recebida (semdefeitos). Algumas vezes, o tempo de espera paracorreção de defeitos é enorme. Assim, é importanteestabelecer cláusulas contratuais para garantir aqualidade do produto.

Sugestão:

Definir um indicador de defeitos/ PF e uma cláusula de multa. Por exemplo,uma multa se o resultado do indicador de defeitos é maior que 0,3 defeitos/PF.É importante definir os tipos de defeitos no contrato.

4 Estabelecer cláusulas contratuais considerando cronograma etaxa de entrega

Problema: “a contratada não entrega nenhum projetode software”Sugestão:

• Estabelecer uma taxa de entrega mensal, ex.: 500 PF/mês

• Definir o modelo de estimativa a ser usado para definir o prazo deentrega, por exemplo “ Formula de Capers Jones”

Td (em meses) = V**t

Sugestão:

• Estabelecer uma taxa de entrega mensal, ex.: 500 PF/mês

• Definir o modelo de estimativa a ser usado para definir o prazo deentrega, por exemplo “ Formula de Capers Jones”

Td (em meses) = V**tJONES,C. Estimating Software Costs – Bringing Realism to Estimating. 2nd Edition,Mc Graw Hill, New York, 2007. New York.

5 Estabelecer o CPM como base para as contagens de PF aoinvés de conversões

Situação Comum: Algumas organizações estabelecem o uso do CPM nocontrato, contudo elas não contam PF de acordo com o CPM.

Algumas vezes, a Contagem de PF é baseada em uma fórmula deconversão, ex: Pontos por Casos de Uso (PCU) para PF. Não existe umafórmula para converter PCU para PF com acurácia.

As vezes, o contrato é baseado em PF, no entanto este é gerenciado comoum contrato de alocação de horas. A empresa contratada comunica ashoras alocadas sem a gestão da contratante. Estas horas são convertidasem PF, considerando uma taxa de produtividade definida com base nopreço por PF.

Situação Comum: Algumas organizações estabelecem o uso do CPM nocontrato, contudo elas não contam PF de acordo com o CPM.

Algumas vezes, a Contagem de PF é baseada em uma fórmula deconversão, ex: Pontos por Casos de Uso (PCU) para PF. Não existe umafórmula para converter PCU para PF com acurácia.

As vezes, o contrato é baseado em PF, no entanto este é gerenciado comoum contrato de alocação de horas. A empresa contratada comunica ashoras alocadas sem a gestão da contratante. Estas horas são convertidasem PF, considerando uma taxa de produtividade definida com base nopreço por PF.

Conte PF de acordo com as regras do CPM

6 Estabelecer regras de dimensionamento de projetos demanutenção

Contagem de PF é aplicada apenas em projetos de desenvolvimento e demanutenção de acordo com CPM.

Como considerar projetos de manutenção em Contratos baseados emContagem de PF?

Sugestão:

• Defina os tipos de projetos de manutenção comuns em suaorganização.

• Defina formulas baseadas na fórmula de melhoria do CPM nocontrato de software no Roteiro de Métricas.

•A Instrução Normativa 04, publicada pela SLTI/ MPOG,preconiza a utilização de métricas em contratos desoftware. Os Acórdãos do Tribunal de Contas da União(TCU) recomendam a utilização da métrica Pontos deFunção Não Ajustados.

•A versão 4.3 do CPM também reconhece o PF NãoAjustado como método padrão do IFPUG.

•O CPM não trata de processos de estimativas de prazo deprojetos.

•O CPM não define regras para o dimensionamento derequisitos não funcionais.

•Em se tratando de manutenção de sistemas, o CPM tratasomente Projetos de Melhoria (Manutenção Evolutiva).

•A Instrução Normativa 04, publicada pela SLTI/ MPOG,preconiza a utilização de métricas em contratos desoftware. Os Acórdãos do Tribunal de Contas da União(TCU) recomendam a utilização da métrica Pontos deFunção Não Ajustados.

•A versão 4.3 do CPM também reconhece o PF NãoAjustado como método padrão do IFPUG.

•O CPM não trata de processos de estimativas de prazo deprojetos.

•O CPM não define regras para o dimensionamento derequisitos não funcionais.

•Em se tratando de manutenção de sistemas, o CPM tratasomente Projetos de Melhoria (Manutenção Evolutiva).

Roteiro deContagem de PF

Medir e Estimar a funcionalidade requisitada erecebida pelo usuário. Definir métricas para tratarrequisitos não funcionais.

Medir Projetos de Desenvolvimento e todos tipos deprojetos de Manutenção independentemente datecnologia utilizada

Premissas

Medir Projetos de Desenvolvimento e todos tipos deprojetos de Manutenção independentemente datecnologia utilizada

Simplicidade: Ser simples o suficiente para minimizar otrabalho adicional envolvido no processo de medição.

Consistência: Prover uma medida consistente entrevários projetos e organizações.

Sugestões Projetos Desenvolvimento

Contagem de PF de Projetos de Desenvolvimento:Projeto para desenvolver e entregar a primeira versãode uma aplicação de software. Seu tamanhofuncional é a medida das funcionalidades entreguesao usuário no final do projeto. Também considera-seas funcionalidades de conversão de dados.Considerar a fórmula do CPM.

Projetos de Melhoria

Um projeto de melhoria consiste em:• demandas de criação de novas funcionalidades (grupos dedados ou processos elementares),•demandas de exclusão de funcionalidades (grupos de dados ouprocessos elementares), e•demandas de alteração de funcionalidades (grupos de dados ouprocessos elementares) em aplicações implantadas emprodução.

- Cálculo de PF de um Projeto de Melhoria (CPM)

PF_MELHORIA = PF_INCLUÍDO + PF_ALTERADO + PF_EXCLUÍDO +PF_CONVERSÃO

Projetos de Melhoria

PF_MELHORIA =PF_INCLUÍDO + (FI x PF_ALTERADO ) +(PF_EXCLUÍDO x 0,40) + PF_CONVERSÃO

FI : Fator de Impacto pode variar de 50% a 90%

FI = 50%: Funcionalidade desenvolvida pela contratada

FI = 75%: Funcionalidade de Sistema não desenvolvida pelacontratada.

FI = 90%: Funcionalidade de Sistema sem documentação atualizada. Acontratada deve redocumentar a funcionalidade mantida,gerando a documentação completa da mesma, aderente ao processode software da contratante.

Projetos de Manutenção - Corretiva

PF_CORRETIVA = PF_ALTERADO x FI

Projetos de Manutenção – Manutenção em Interface

São consideradas manutenções cosméticas ouAdaptativas – Mudança de Interface, as demandasassociadas à alterações de interface, por exemplo, fontede letra, cores de telas, logotipos, mudança de botõesna tela, mudança de posição de campos ou texto natela. Também se enquadram nessa categoria asmudanças de texto em mensagens de erro, validação,aviso, alerta ou conclusão de processamento.

PF_INTERFACE = 0,6 x QTD de Processos Impactados

Projetos de Mudança de Plataforma –Linguagem de Programação

São considerados nesta categoria, projetos queprecisam ser migrados para outra plataforma. Por exemplo,um sistema legado em COBOL precisa ser re-desenvolvidoem JAVA. São considerados como novos projetos dedesenvolvimento.

Projetos de Mudança de Plataforma – Bancode DadosNesta categoria encontram-se as demandas deredesenvolvimento de sistemas para executar em umoutro Sistema Gerenciador de Banco de Dados.Observe que caso não exista mudança nas funções dedados, ou seja, o banco de dados da aplicação sejamantido, então as funções de dados não devem sercontadas.

Nesta categoria encontram-se as demandas deredesenvolvimento de sistemas para executar em umoutro Sistema Gerenciador de Banco de Dados.Observe que caso não exista mudança nas funções dedados, ou seja, o banco de dados da aplicação sejamantido, então as funções de dados não devem sercontadas.

claudia.hazan@serpro.gov.br

• Atualização de versão - Linguagem de Programação

Projetos de Manutenção –Atualização de Versão

• Atualização de versão - Browser

• Atualização de versão – Banco de Dados

Projetos de Manutenção – Adaptação emFuncionalidades sem Alteração de Requisitos Funcionais

São consideradas nesta categoria as demandas de manutençãoadaptativa associadas a solicitações que envolvem aspectos nãofuncionais, sem alteração em requisitos funcionais.

PF_ADAPTATIVA = PF_ALTERADO x FI

FI = 90%: Funcionalidade de Sistema sem documentação atualizada. Acontratada deve redocumentar a funcionalidade mantida.

PF_ADAPTATIVA = PF_ALTERADO x FI

Exemplos:

- Aumentar a quantidade de linhas por página em um relatório;

– Colocar paginação em um relatório;

– Permitir exclusões múltiplas em uma funcionalidade que antes sópossibilitava a exclusão de um item;

– Adaptação de uma funcionalidade para possibilitar a chamadapor um Webservice ou para outro tipo de integração com outrossistemas;

Exemplos:

- Aumentar a quantidade de linhas por página em um relatório;

– Colocar paginação em um relatório;

– Permitir exclusões múltiplas em uma funcionalidade que antes sópossibilitava a exclusão de um item;

– Adaptação de uma funcionalidade para possibilitar a chamadapor um Webservice ou para outro tipo de integração com outrossistemas;

35claudia.hazan@serpro.gov.br

Apuração Especial – Base de DadosPF_AESP_BD = PF_INCLUÍDO

Apuração Especial – Consulta Prévia

PF_AESP_Consulta_Prévia = PF_INCLUÍDO

PF_AESP_BD_Pós_Prévia = PF_INCLUÍDO x 0,60

Apuração Especial – BD Pós Consulta Prévia

PF_AESP_Relatório = PF_INCLUÍDO

Apuração Especial – Geração de Relatório

Apuração Especial – Reexecução

PF_Reexecução_AESP = PF_INCLUÍDO x 0,10

Apuração Especial – Reexecução

PF_Atualização_de_Dados = PF_INCLUÍDO x 0,10

Atualização de Dados

Manutenção em Páginas Estáticas deIntranet, Internet ou Portal

A demanda consiste na publicação de páginas htmlPortais, Intranets ou Websites. Estas demandas sãoconsideradas como desenvolvimento de consultas com autilização de ferramentas para apoiar a publicação. Considera-se 20% dos Pontos de Função das consultas desenvolvidas.Cada página é contada como uma consulta. As consultas sãoconsideradas Consultas Externas Simples (3 PF).

Manutenção de Documentação de Sistemas LegadosCaso a demanda seja apenas a documentação derequisitos, devem ser considerados 25% dos Pontosde Função da aplicação em questão

PF = PF_NÃO_AJUSTADO x 0,25

Projetos de Manutenção – Verificação de ErrosSão consideradas verificações de erro ou análise e solução deproblemas as demandas referentes a todo comportamentoanormal ou indevido apontado pelo cliente nos sistemas.Caso o problema seja relatado em funcionalidades específicasda aplicação e uma vez não constatado o problema apontadopelo cliente ou o mesmo for decorrente de regras de negócioimplementadas ou utilização incorreta das funcionalidades,será realizada a aferição do tamanho em Pontos de Funçãodas funcionalidades verificadas, e será considerado 20% dotamanho funcional das funcionalidades analisadas

São consideradas verificações de erro ou análise e solução deproblemas as demandas referentes a todo comportamentoanormal ou indevido apontado pelo cliente nos sistemas.Caso o problema seja relatado em funcionalidades específicasda aplicação e uma vez não constatado o problema apontadopelo cliente ou o mesmo for decorrente de regras de negócioimplementadas ou utilização incorreta das funcionalidades,será realizada a aferição do tamanho em Pontos de Funçãodas funcionalidades verificadas, e será considerado 20% dotamanho funcional das funcionalidades analisadas

PF = PF_NÃO_AJUSTADO x 0,20OBS:Caso o sistema não esteja funcionando por problemas deinfra-estrutura (rede, banco de dados...). A demanda será tratadacomo Serviço em homem_hora.

Manutenção de Componente Interno ReusávelEm alguns casos são demandadas manutenções em componentesespecíficos de uma aplicação e estes são reusados por váriasfuncionalidades da aplicação.

Proposta: Considerar componente um processo elementarindependente e contar como uma funcionalidade. O componentedeverá ser testado. Além disso, as funcionalidades da aplicação quenecessitem de teste devem ser requisitadas pela contratante edimensionadas por meio da métrica Pontos de Função de Testes.

Em alguns casos são demandadas manutenções em componentesespecíficos de uma aplicação e estes são reusados por váriasfuncionalidades da aplicação.

Proposta: Considerar componente um processo elementarindependente e contar como uma funcionalidade. O componentedeverá ser testado. Além disso, as funcionalidades da aplicação quenecessitem de teste devem ser requisitadas pela contratante edimensionadas por meio da métrica Pontos de Função de Testes.

PF_Componentes = PF_NÃO_AJUSTADO

Pontos de Função de TestesMuitas vezes, em projetos de manutenção o conjunto defunções de dados e funções transacionais a serem testadasé maior do que a quantidade de funções a seremimplementadas, i.e., além das funcionalidades que sãoafetadas diretamente pelo projeto de manutenção, outrasprecisam ser testadas [NESMA, 2009].

Muitas vezes, em projetos de manutenção o conjunto defunções de dados e funções transacionais a serem testadasé maior do que a quantidade de funções a seremimplementadas, i.e., além das funcionalidades que sãoafetadas diretamente pelo projeto de manutenção, outrasprecisam ser testadas [NESMA, 2009].

O tamanho das funções a serem testadas deve ser aferidoem Pontos de Função de Teste (PFT). Não considerar asfuncionalidades incluídas, alteradas ou excluídas do projetode manutenção na contagem de Pontos de Função de Teste.

Pontos de Função de Testes

A contagem de PFT deve considerar o seguinte:•Determinar o tamanho em Pontos de Função de cadafunção de dados ou transacional envolvida no teste.•Calcular o tamanho em Pontos de Função de todas asfunções de dados ou transacionais envolvidas no teste.• A conversão do PFT em Ponto de Função deve ser feitade acordo com a fórmula abaixo:

PF = PFT x 0,15

A contagem de PFT deve considerar o seguinte:•Determinar o tamanho em Pontos de Função de cadafunção de dados ou transacional envolvida no teste.•Calcular o tamanho em Pontos de Função de todas asfunções de dados ou transacionais envolvidas no teste.• A conversão do PFT em Ponto de Função deve ser feitade acordo com a fórmula abaixo:

É importante ressaltar que as funções testadas consideradas no PFTdevem ser requisitadas pelo cliente e documentadas. Observe queestas funções farão parte do escopo do projeto de manutenção

Mudança de Requisito e Projetos Cancelados

Considerar o percentual das fases realizadas sobre a contagem dePF do requisito original.

Melhores Práticas

• Revisar o Roteiro sempre que tiver mudança de versão doManual CPM, ou publicação de White Paper pelo IFPUG.

• Revisar o Roteiro sempre que surgir uma situação não previstano mesmo.

• Analisar o Roteiro periodicamente, avaliando a simplicidade,consistência e adequação das fórmulas às demandas com baseno feedback das equipes de desenvolvimento.

• Incluir no Roteiro modelos para a Documentação de Requisitosde Projeto de Desenvolvimento e de Manutenção.

• Incluir modelos para a Documentação da Contagem de Pontosde Função.

• Revisar o Roteiro sempre que tiver mudança de versão doManual CPM, ou publicação de White Paper pelo IFPUG.

• Revisar o Roteiro sempre que surgir uma situação não previstano mesmo.

• Analisar o Roteiro periodicamente, avaliando a simplicidade,consistência e adequação das fórmulas às demandas com baseno feedback das equipes de desenvolvimento.

• Incluir no Roteiro modelos para a Documentação de Requisitosde Projeto de Desenvolvimento e de Manutenção.

• Incluir modelos para a Documentação da Contagem de Pontosde Função.

Programa de Capacitação em APF do SISP

- Curso Básico de Análise de Pontos de Função (EaD) – 30 horas

- Curso de Contagem de Pontos de Função – Presencial – 32 horas

- Curso de Contagem de Pontos de Função Avançado – 24 horas

- Curso Preparatório para a Certificação CFPS – CPM 4.3 (Emconstrução)

- Curso Básico de Análise de Pontos de Função (EaD) – 30 horas

- Curso de Contagem de Pontos de Função – Presencial – 32 horas

- Curso de Contagem de Pontos de Função Avançado – 24 horas

- Curso Preparatório para a Certificação CFPS – CPM 4.3 (Emconstrução)

Perguntas e Contato

Claudia Hazan

Tel: (21) 3507-7787Cel: (21) 9124-6579

Obrigado

Claudia Hazan

Tel: (21) 3507-7787Cel: (21) 9124-6579

“Sonhos se tornam realidade”

uso de metricas em contratos de fabrica de software roteiro de metricas do sisp 2.0 claudia hazan...

Documents

caderno sisp 2012

metricas, metricas, metricas

guia orientacao metricas

metricas para startups

relacoes metricas no triangulo retangulo

metricas de conteudo em cibermeios

metricas para profissionais criativos

aula 9 metricas

metricas de software

metricas para times Ágeis

consegi 2010 - tutorial estimativas de software claudia...

monitoramento e metricas no facebook

metricas para marketing de conteudo

metricas para midias sociais

metricas e monitoramento na web

e-business: estrategias e metricas

aula metricas intensivo digitalks

aula metricas avançado digitalks

metricas nas redes sociais

metricas nos da rede