Pontos de Função x Agile x Roteiro de Métricas do SISP

Posted on Posted in Metodologia Ágil, pontos de função, Rotéiro de Métricas SISP

A contratação pública de desenvolvimento de software tem que ser balizada por uma métrica objetiva. É um princípio legal disposto na Instrução Normativa 04/2010 SLTI/MPOG em seu Art.25 inciso II.

II – encaminhamento formal de Ordens de Serviço ou de Fornecimento de Bens pelo Gestor do Contrato ao preposto da contratada, que conterão no mínimo:
b) o volume de serviços a serem realizados ou a quantidade de bens a serem fornecidos segundo as métricas definidas em contrato;

 Mas desconheço dispositivo legal que relate a obrigatoriedade de usar Pontos de Função (PF) para medir software. Podemos usar qualquer outra métrica, ou uma customização de uma existente, desde que seja objetiva e clara. E ponto de função é objetivo ou há a subjetividade do analista de métricas em considerar se é um ALI ou apenas um TR? Ai já é outro assunto (subjetividade na contagem de PF) que trataremos em outro post.

Neste post, gostaria de relatar um risco alto para quem usa metodologia ágil – ou metodologia iterativa incremental – com pontos de função nos moldes do roteiro do SISP Versão 1 ou Versão 2.

O Roteiro de Métricas do SISP, em sua versão 1.0, relatava um percentual de ajuste de 50% a 100% (pag. 14) para uma alteração que se enquadrava no conceito Projeto de Melhoria. Ver Tabela 1.0 abaixo.

Conceito de Projeto de Melhoria: O Projeto de Melhoria (enhancement), também denominado de projeto de melhoria funcional ou manutenção evolutiva, está associado às mudanças em requisitos funcionais da aplicação, ou seja, à inclusão de novas funcionalidades, alteração ou exclusão de funcionalidades em aplicações implantadas. (Roteiro de Métricas do SISP versão 1.0, página 13).


FI = Fator de Impacto Condição
50% Melhoria de um sistema desenvolvido pela própria empresa.
75% Melhoria de um sistema desenvolvido por outra empresa, mas com documentação atualizada.
100% Melhoria de um sistema desenvolvido por outra empresa sem documentação atualizada.

Tabela 1 – Fator de Impacto da versão 1.0

Se você usa o Roteiro de Métricas do SISP versão 1.0 então vai a primeira dica:

Relate em seu TR que a documentação de seu software, como insumo para projetos de melhoria, é apenas o código-fonte

Nesse caso, a documentação sempre estará atualizada. E sabemos que código-fonte bem feito é a melhor documentação para um desenvolvedor.

O novo Roteiro de Métricas do SISP, versão 2.0, agora relata, para o mesmo projeto de melhoria, um percentual de 50% a 90% (pag. 9).

Note que o percentual máximo reduziu de 100% para 90%, mas a condição de um percentual maior agora não é mais o fato de TER OU NÃO TER uma documentação atualizada e sim REDOCUMENTAR OU NÃO a funcionalidade nova. Ver Tabela 2.0.

FI = Fator de Impacto Condição
50% Melhoria de um sistema desenvolvido pela própria empresa.
75% Melhoria de um sistema desenvolvido por outra empresa, SEM NECESSIDADE DE REDOCUMENTAÇÃO.
90% Melhoria de um sistema desenvolvido por outra empresa COM NECESSIDADE DE REDOCUMENTAÇÃO.

Tabela 2 – Fator de Impacto da versão 2.0

Agora me respondam: Se você usa documentação de software (imagine apenas o manual do usuário) , quando é que ao fazer uma melhoria não precisaremos redocumentar? ( o conceito de melhoria para o roteiro é inclusão, alteração ou exclusão de requisito funcional).

Ou seja, sempre que incluímos, alteramos ou excluímos um requisito funcional teremos redocumentação.

“Ah, mas o roteiro fala que 90% é somente quando a melhoria é feita em sistemas não desenvolvidos ou mantidos pela contratada”.
E agora, melhorou? Quase nada, pois sabemos que a cada licitação provavelmente muda-se a empresa.

“Então será bom para Administração Pública a mesma empresa sempre ganhar o pregão, pois assim o Fator de Impacto fica sempre em 50%”.

O Roteiro levar a esse pensamento, mas prefiro alterar o roteiro de métricas no meu Termo de Referência (TR) e atribuir sempre um valor fixo X a correr o risco de minhas manutenções serem até 40% mais caro só porque a empresa mudou.

Se seu órgão não tem pessoas especializadas em métricas e não tem um Roteiro de Métricas então use o do SISP, mas fixe o percentual de alteração em 50% ou menos em seu TR.

 

Qual a relação disso com Agile?

O problema é que em metodologias ágeis ou interativas incrementais com iterações curtas, pode-se ter o problema de certa funcionalidade ser dividida em diversas iterações (sprints) e a empresa “considerar” o incremento da funcionalidade como uma melhoria dela. Eu já passei por isso.

 

História baseada em fatos reais:

Temos um cadastro de funcionários que contém mais de 60 informações e foi dividido em 5 abas apenas por desejo do dono do produto. Há apenas 1 botão “Salvar” e ao clicar nele TODAS as informações são gravadas (acabei de relatar que é um ALI só, mas de complexidade alta – 15 PF).

A empresa, ao esmiuçar essa estória de usuário, sugere quebrá-la em 3 sprints e ir validando com o dono do produto. Este acha bacana a ideia e aceita. Ao final da primeira iteração, a empresa entrega 3 abas funcionando perfeitamente e com 5 transações (todas complexas).
Nesse momento, a empresa cobra 46 PF divididos em:

  • ALI – ALTA – 15PF
  • 4 x EE – ALTA – 24PF
  • 1 x SE – ALTA – 7PF

O órgão paga, pois tudo está 100%.

Na próxima iteração a empresa entrega apenas mais uma aba funcionando. A quantidade de ALI e transações continua a mesma. O total de pontos de função também, mas a empresa cobra 23PF referente a 50% dos 46PF.

Justificativa da contratada:

“Na inclusão de novo requisitos funcionais (nova aba), foi necessário alterar código, banco de dados e testar novamente toda a funcionalidade entregue na interação anterior – testes de regressão. Por entendermos essa alteração se enquadra em uma melhoria, segundo Roteiro do SISP, solicitamos pagamento de 50% da funcionalidade.”

E o mês seguinte ela cobra de novo mais 23PF para 5º e última aba.

Resultado: paga-se 92 PF por uma funcionalidade de tamanho 46PF.

E agora? Foi uma melhoria ou apenas um incremento de uma história de usuário muito grande (épico) que decidimos quebrar em sprints? A empresa foi desonesta ou o gestor público é que deixou brecha?

Alguém pode falar: “Mas foi a empresa que sugeriu a quebra em 3 sprints”. Ok, mas se fosse o órgão que tivesse sugerido porque não teria condições de validar tudo em uma só Sprint? A culpa seria do órgão e teríamos que pagar os 92PF?

São muitos questionamentos e para não passar pelo que passei, vai outra dica: deixe claro em seu TR que

Incrementos de uma funcionalidade dividida em interações não serão considerados como Alteração, Refatoração, Correção ou Melhoria. Consequentemente, não serão remunerados.

Ou

Uma funcionalidade dividida em iterações só será remunerada na última iteração quando toda ela for validada.

Para não ter que provar de novo que focinho de porco não é tomada, redijo em todos meus TR o real conceito de Melhoria, Correção, Alteração e Refatoraçao e fixo o percentual para qualquer hipótese (documentação ou não) é 50%.

by Herbert Parente

11 thoughts on “Pontos de Função x Agile x Roteiro de Métricas do SISP

  1. Srs., a maioria dessas questões (relação contratada X contratante) envolvendo APF, parte da resistência de ambas as partes em deixar o modelo antigo de contratação: HH ou Posto de trabalho.
    A APF desde o início tem o objetivo único de tratar uma das dimensões envolvidas nas contratações, que é o tamanho funcional. O Roteiro do SISP tem procurado complementar as lacunas no que o CPM não trata.
    Hoje existem no mercado Empresas especializadas em Métricas de Software, com experiência nos diversos cenários apresentados que surgem nas contratações. Concordo com o comentário de que não basta “encher” o TR de referências a métodos, práticas e roteiros, sem, contudo, procurar prever e detalhar os cenários que efetivamente ocorrerão na execução dos contratos.
    Minha recomendação aos Órgãos que ainda não tem pessoal especialista disponível, que faça uma contratação prévia de uma dessas Empresas, para elaboração desse detalhamento; pode ser aproveitada essa contratação e dimensionado de forma mais efetiva o volume a ser contratado. Hoje a maioria dos Órgãos ainda não têm a dimensão de seu parque instalado de softwares (baseline dos legados), fazendo estimativas de contratação de forma empírica.

    Quanto à questão das contagens de PF quando se utiliza métodos ágeis no desenvolvimento, o mesmo cenário descrito no Blog pode ser tratado de várias formas:
    “Temos um cadastro de funcionários que contém mais de 60 informações e foi dividido em 5 abas APENAS POR DESEJO DO DONO DO PRODUTO. Há apenas 1 botão “Salvar” e ao clicar nele TODAS as informações são gravadas (acabei de relatar que é um ALI só, mas de complexidade alta – 15 PF).”
    A divisão em 3 SPRINTs foi provavelmente a melhor alternativa para AMBOS, contratada e contratante, em função dos comentários seguintes.
    O que não faz que a segunda SPRINT seja, do ponto de vista da APF, um “Projeto de Melhoria” da primeira SPRINT. Trata-se do mesmo “Projeto de Desenvolvimento”, visto que o “cadastro de funcionários que contém mais de 60 informações” já está previsto como requisito desde o início do projeto. Nesse caso, a FORMA de PAGAMENTO é que tem que contemplar o fracionamento. O total a ser PAGO é de 46 PF, que pode ser dividido em entregas parciais até o final do projeto.
    Diferentemente, se o cenário fosse de uma mudança no cadastro (não prevista originalmente) nas primeiras SPRINTs e identificada, por exemplo, na quarta SPRINT. Nesse caso seria necessário a mudança de escopo, e o “Projeto de Melhoria” estaria justificado, cabendo nesse caso a aplicação de deflatores, redocumentação, e outros mecanismos, alguns já previstos no Roteiro do SISP.

    1. Perfeito Abrantes, já trabalhei com vcs e foi um trabalho sério. O que relatei no exemplo foi um caso que “aproveitaram” uma possível brecha de interpretação para faturar mais usando como justificativa o Ágil. Logo, existem empresas boas e parceiras (ganha-ganha) como empresas que ficam no jogo de gato e rato com o órgão e todos perdem.

  2. Só escalrecendo o conceito de redocumentação do texto original, mencionando o Roteiro SISP 2.0.
    A redocumentação não é a atualização de documentação, nem a elaboração da documentação do projeto de melhoria. A redocumentação ocorre quando a funcionalidade não possui documentação e a contratante tem interesse que a contratada além do projeto de melhoria, documente a funcionalidade em questão.
    Em tempo, convido a todos para o CONSEGI: http://www.consegi.gov.br
    O evento é gratuito.
    Estarei apresentando uma oficina sobre o Roteiro SISP em 13/08. É necessária a inscrição no CONSEGI e na Oficina.

    Att.
    Claudia Hazan

    1. O roteiro do SISP versão 2.0 descreve na página 14 nas 2 últimas linhas “em função de que a mesma não existe ou está desatualizada deve ser considerado FI = 90% (ou seja, adicionar 15% como fator de redocumentação)“.

  3. Hebert, se possível, vc poderia disponibilizar o TR que há as melhorias que vc citou no post?

    Grato.

  4. Olá Herbert,

    Primeiramente, parabéns pelo Blog e pelo propósito deste que, acima de tudo, vai facilitar (no sentido de fazer o papel de facilitador) a integração dos profissionais de TI do Goveno, para o Governo… esta galera estava precisando :))

    Eu concordo com vc na questão que se poderia usar qualquer outra técnica de métrica de software, mas APF é o que era (e é) até então. É só uma questão de saber como utilizar e/ou como aplicar a grandeza de tamanho funcional (PF) na gestão de projetos de desenvolvimento e manutenção de software – como seria em qualquer outra técnica.

    Eu vejo o SISP fazendo este papel; o “como” contar PF, o CPM, do IFPUG, ditou. O “o quer fazer e/ou como aplicar” o PF contato, ou não (IMN) o SISP é um dos caras que dita. No mercado privado, cada organização tem seu guia de contagem próprio (tudo bem que às vezes na base do ctrl+C/ctrl+V da concorrente, mas blz!)… sendo o equivalente ao tratamento que vcs, aqui no Governo, fazem nos TR.

    No seu relato eu identifiquei um ponto de atenção, que segue;

    “Temos um cadastro de funcionários que contém mais de 60 informações e foi dividido em 5 abas apenas por desejo do dono do produto. ****** ****** ****** Há apenas 1 botão “Salvar” e ao clicar nele TODAS as informações são gravadas…”…

    Ou seja, para cadastrar um funcionário vence-se 5 abas com 60 dados e pah!, botão “Salvar” e ok? A inclusão dos dados do cadastro de funcionário foi feita?

    Se sim, nesta especificação, estamos falando de um processo de inclusão de dados, ok?

    Enfim, por que 4 EE?

    Ou, outra dúvida; 3 abas e 5 transações. Não eram 5 abas somente para o processo de inclusão? (Por conta do “botão salvar” da sua especificação…)…

    Enfim 2, de qualquer forma, CONSIDERO, concordando plenamente em 101% com vc, a questão do tratamento do incremento de uma funcionalidade dividida em iterações de SUMA importância. Como o TR deve tratar isto? Isto deve ficar bem claro pela Contratante.

    *** Sobre APF ***

    De acordo com o CPM, do IFPUG, o Tamanho Funcional do Projeto de Desenvolvimento é a medida da funcionalidade oferecida aos usuários pela PRIMEIRA release do software, conforme medida pela contagem de pontos de função do projeto de desenvolvimento.

    Ou seja, em tempo de projeto de desenvolvimento identifica-se as funcionalidades desenvolvidas que atendem os requisitos de processo elementar da APF e conta-se em condições de projeto de desenvolvimento. Ponto!

    Não tem sentido, em TEMPO de projeto de desenvolvimento, tratar (contar, remunerar) 3 abas, de 5, de um jeito e as outras 2 RESTANTES, de outro. Para Métricas tudo é ainda desenvolvimento.

    #abreparentese

    Para a APF, uma funcionalidade será convertiva em um processo elementar quando esta atender os seguintes requisitos:

    1 – constitui uma transação completa – tem entrada (estímulo) para um processamento, o processamento em si e respectivo resultado. Neste caso, dados do Cadastro de Funcionários gravados em um depósito de dados mantidos pela aplicação.

    2 – é autocontida – o processamento da inclusão é suficiente para o resultado esperado…

    3 – deixa o negócio da aplicação contada em um estado consistente – o sistema executou o processamento e a aplicação não ficou pendurada dependendo de uma ação seguinte do usuário para ser concluída.

    4 – é significativa para o usuário – é significativa para que o processo de negócio seja concluído.

    #fechaparentese

    Para a APF não importa em quantas abas o processo de inclusão do Cadastro de Funcionário este será concluído (aqui, apenas para introdução da consideração seguinte) e nem em quantas iterações o seu desenvolvimento vai rolar.

    É isto! Espero ter ajudado.

  5. Eu concordo com o que foi colocado aqui, porém fico com algumas dúvidas. (fique claro que concordo contigo porém essas moedas tem dois lados)

    A empresa realmente teve que testar, validar, produzir documentação para aquela funcionalidade, como fica o lado dela que de fato teve um custo de 120% a 150% por conta da quebra em sprints?

    O código-fonte ser considerado como documentação é um pouco pesado. Concordo que ler um código bem escrito ajuda bastante no entendimento da lógica mas não te entendi muito bem. Honestamente um CDU bem feito é bem melhor.

    Eu empresa dar manutenção em um software que eu fiz e nao tem documentação, ao é problema meu, mas acho inconcebível por exemplo assumir responsabilidade de manutenção em um software legado tendo como documentação o código fonte dele.

    Você também vai precisar de uma equipe muito mais bem preparada para fazer a auditoria de qualidade do código produzido.

    Eu tento olhar sempre pros dois lados e gostaria que se você tivesse a paciência e o tempo explicasse melhor esta questão.

    De resto eu tenho um pouco de vergonha alhei quando vejo licitações que as pessoas apenas citam 300 metodologias, roteiro do SISP, e-mag, e-arq, e-ping e não fazem a menor noção do que tem lá. Estes guias são legais para muitas coisas, porém não são a solução mágica para contratação pública e fico feliz de ver teus posts e apresentações.

    1. Boa tarde Matheus, excelente suas colocações e seguem minhas respostas.

      como fica o lado da empresa que de fato teve um custo de 120% a 150% por conta da quebra em sprints?
      – A quebra em sprints é para ser benéfica e não onerosa para as duas partes. A quebra de sprints também pode ser opcional, caso a empresa tenha capacidade produtiva de fazer tudo em uma única sprint. E o custo de retestar as funcionalidades quebradas em sprints tem que está mensurado no valor do ponto de função quando a empresa dá o lance no pregão. Ou seja, se a empresa ao analisar o edital ou na visita técnica (que inclusive pouca gente faz) ver que existe essa possibilidade e esse ônus, ela tem que mensurar no hora do lance no pregão e não com majoração de percentuais depois do contrato assinado.

      O código-fonte ser considerado como documentação é um pouco pesado.
      – Concordo com vc e estava esperando comentarem isso. Realmente é pesado, mas é a realidade de muitos órgão. Logo, o Gestor Público de TI deve explicitar isso (que não há documentação e só código) no edital, a empresa deve fazer a visita técnica para analisar a conjectura e mensurar corretamente o valor do PF no lance pregão. O custo te que ser medido na pesquisa de mercado e no planejamento da contratação e as licitantes devem ter ciência do REAL custo antes de entrar no pregão…o custo não pode ser majorado na execução contratual.

      acho inconcebível por exemplo assumir responsabilidade de manutenção em um software legado tendo como documentação o código fonte dele
      – É por isso que o pregão é livre para participar quem quiser. A empresa não é obrigada a aceitar essa condição, mas se ela entra na licitação (ou esse lote específico) é porque ela sabia da realidade, ou deveria saber. Concordo que há diversos editais omissos que não relatam a realidade e depois que a empresa assina o contrato é que se depara com o problema. Nesse caso, existe o erro do Gestor Público em falta de clareza do edital e a empresa pode se recusar a executar um serviço não previsto.

      Você também vai precisar de uma equipe muito mais bem preparada para fazer a auditoria de qualidade do código produzido.
      – Isso sempre foi uma necessidade do órgão que “compra” código-fonte para dar manutenção depois. Com ou sem documentação auxiliar o código-fonte sempre foi o principal artefato entregue e sempre exigiu uma fiscalização/auditoria de qualidade. O que muita vezes os órgão público não têm.

      OBS: Não defendo a ausência completa de documentos. Defendo a redução deles e que não receba documento sem software.

      1. Olá Hebert, concordo com você na questão central da sua resposta que pelo que entendi é “A empresa tem fazer o dever de casa” mas sabemos que esta não é a realidade das empresas kamikazes de Brasília.

        Na verdade o Brasil todo como cultura, não costuma ser um bom planejador e por mais que concorde com essa sua visão de “apertar” a contratada seja interessante, acho que o efeito pode ser mais benéfico quando ambos se encontram no meio do caminho.

        Vejo que a coisa mais nociva da TI em Brasília é justamente fruto desse “ódio” entre órgão publico e contratada. A maior parte do tempo é gasto em brigas, usando contrato como escudos de ambos os lados, e o serviço prestado é quem sofre.

        Veja que não discordo de você, apenas acho que um esforço para “facilitar” a vida do outro lado pode ser mais benéfico. Eu particularmente não entraria em uma licitação sua NUNCA, provavelmente por saber dos riscos envolvidos colocaria um custo por PF mais elevado e ficaria de fora.

        Te alerto para este ponto, pois em quase todas as empresas que trabalhei em Brasília a lógica sempre foi. “Foda-se, vamos ganhar isso a qualquer custo e depois a gente dá um jeito”Ninguém faz esse trabalho de dever de casa direito. O comercial dessas empresas não entende patavinas de desenvolvimento.

        Portanto acredito que esta estratégica muito endurecida fará que você passe mais tempo brigando com contratadas ao invés de atrair as boas empresas modernas e pequenas que não tem tanto $$Cacife$$.

        Eu acho que antes de qualquer órgão pensar em contratar ele deveria ter um bom diagnóstico da sua situação. Eu vejo contratos que citam deliberadamente todos os roteiros possíveis , mas não possuem quais são os entregáveis que devem ser entregues ou o processo de trabalho que deve ser seguido.

        1. “… O comercial dessas empresas não entende patavinas de desenvolvimento.”… bingo!

          E muito inocente a Contratante tentando ser esperta em contratar o menor custo por PF sabendo que tal custo mal cobre o cafezinho da galera no mês! Ambos os lados saberiam desta conta.

          Se os escritórios de projetos explorassem mais e melhor a ferramenta de estimativa de projetos, sofria-se menos, ao preço certo.

          Meio que óbvio, mas o desejo de elucidar foi maior 🙂

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *