DOU 22/03/2023 - Diário Oficial da União - Brasil

                            Documento assinado digitalmente conforme MP nº 2.200-2 de 24/08/2001,
que institui a Infraestrutura de Chaves Públicas Brasileira - ICP-Brasil.
Este documento pode ser verificado no endereço eletrônico
http://www.in.gov.br/autenticidade.html, pelo código 05152023032200039
39
Nº 56, quarta-feira, 22 de março de 2023
ISSN 1677-7042
Seção 1
5.2.1.12 Na aplicação da modalidade de horas de serviço técnico, o valor estimado da contratação é obtido por meio do produto entre o valor da hora de serviço, aplicado a
um perfil de referência, e a quantidade horas estimadas, considerando aplicação dos fatores de ajuste previamente definidos de acordo com o perfil profissional necessário, a execução de
cada serviço.
5.2.1.13 A estimativa da quantidade de horas deve ser calculada conforme diretrizes constantes do Roteiro de Métricas de Software do SISP.
5.2.1.14 O objeto da contratação deverá ser dividido em itens aferidos por meio de Pontos de função por tecnologia predominante e item aferido por HST, conforme quadro
exemplificativo:
. Grupo
Item
Descrição
Métrica
Custo unitário
(A)
Quantidade Máxima
(B)
Valor total
(C) = A x B
. 1
1
Serviços de Desenvolvimento e manutenção de Software -
Python
Ponto de Função
.
2
Serviços de Desenvolvimento e manutenção de Software - Java
Ponto de Função
.
3
Serviços Complementares de Desenvolvimento e manutenção de
Software
Hora de serviço Técnico - Perfil
de referência Desenvolvedor
Junior
5.2.2 Mecanismos de gestão
5.2.2.1 A execução dos serviços está condicionada à emissão de ordem de serviço, contendo no mínimo o objetivo da OS, a descrição do que deve ser executado, os
produtos/resultados a serem entregues, o prazo de atendimento e os requisitos não funcionais a exemplo (critérios mínimos de desempenho operacional da solução, critérios de segurança
da informação, critérios de identidade visual e usabilidade).
5.2.2.2 A identificação dos requisitos funcionais na Ordem de Serviço pode ser realizada por meio de apontamento a roteiros, guias de codificação e outros padrões estabelecidos
pela Contratante e previstos no instrumento convocatório.
5.2.2.3 Devem ser descritas regras de composição e alocação de times ou equipes, conforme diretrizes previstas no Anexo IV deste documento.
5.2.2.4 Caso o órgão não possua servidor capacitado na métrica de análise por pontos de função, deve-se avaliar a contratação de serviços especializados de métricas de software,
ou previsão de contratação de profissional de métricas, assegurando-se que:
a) o serviço de métricas não seja realizado pela mesma empresa que executou os serviços de desenvolvimento de software;
b) os profissionais de métricas possuam as qualificações necessárias para assegurar a verificação adequada da contagem;
c) o serviço de métricas não seja remunerado exclusivamente pela quantidade de pontos de função contados;
d) o serviço de métricas possua metas de produtividade e indicadores de qualidade previamente definidos.
5.2.3 Dimensionamento
5.2.3.1 O dimensionamento do volume a ser contratado, em termos de pontos de função, deve se pautar em bases históricas mantidas pelo órgão ou em técnicas de estimativa
de contagem de pontos de função (contagem indicativa, estimativa, detalhada ou simplificada - SFP).
5.2.3.2 A memória de cálculo que justificará o volume a ser contratado deve integrar os estudos técnicos preliminares.
5.2.3.3 Para se estimar a quantidade total de HST a ser contratada, deve-se primeiramente estimar a demanda esperada para as atividades constantes no catálogo, baseando-
se em histórico recente, caso exista, e projeções para o período de vigência do contrato.
5.2.3.4 Para cada atividade do catálogo, a remuneração associada deve levar em consideração o esforço necessário e os perfis profissionais envolvidos na sua execução. Cada um
desses perfis deve ter seu custo unitário de hora expresso como uma fração da hora de um perfil escolhido como referência, permitindo que todas as atividades tenham sua remuneração
correspondente a um múltiplo da hora desse perfil de referência, equivalente à HST.
5.2.3.5 A partir da estimativa da demanda por atividade e da construção do catálogo, o valor estimado da contratação pode ser obtido por meio do produto entre o valor
estimado da HST e a quantidade de HST a ser contratada.
5.2.4 Forma de pagamento
5.2.4.1 O pagamento será feito por produto de software implementado conforme critérios de aceitação definidos e aferição de níveis mínimos de serviço, aferidos a cada sprint
aceita, adotando-se preferencialmente a métrica Ponto de Função Simples (Simple Function Point - SFP) sobre as funcionalidades efetivamente implementadas.
5.2.4.2 Para comportar a dinâmica ágil de forma a incorporar as mudanças entre as sprints, admite-se a aplicação de um fator ágil a ser definido no Termo de Referência seguindo
as diretrizes constantes do roteiro de métricas do SISP, não sendo superior a 30%.
5.2.4.3 A adoção do fator ágil consiste na substituição da contabilização de exclusões e alterações de processos elementares entre as sprints de uma mesma release pela aplicação
de um percentual sobre o tamanho contabilizado da release. A quantidade de sprints de uma release deve ser definida no TR.
5.2.4.4 A aplicação do fator ágil é adequada para processos em que há necessidade de grande volume de reconstruções entre sprints de uma mesma release.
5.2.4.5 O pagamento por horas de serviço técnico deve ser baseado em catálogo, previamente estabelecido no Termo de Referência, conforme diretrizes constantes do Roteiro
de métricas de software do SISP.
5.2.5 Mecanismos de controle
5.2.5.1 Deve-se manter registro estruturado das contagens de pontos de função, de forma a possibilitar o controle de baselines de contagens por sistema e de fronteiras de
aplicações, com vistas a mitigar o risco de contagem duplicada, recomendando-se o uso de ferramentas especializadas para a manutenção e atualização da baseline.
5.2.5.2 Deve-se estabelecer, de forma clara, para fins de mensuração de pontos de função, as fronteiras das aplicações, considerando que:
a) A correta identificação da fronteira de uma aplicação é fundamental para o emprego consistente da métrica de análise de pontos de função, evitando-se contagens
superdimensionadas ou subdimensionadas.
b) O posicionamento incorreto da fronteira pode alterar a perspectiva da medição de uma visão lógica (visão funcional) para uma visão física.
c) As principais consequências da não definição de fronteiras das aplicações são a contagem duplicada de transações e arquivos de dados, a contagem incorreta de funções de
transferência de dados e dificuldade na contagem de arquivos.
d) Uma fronteira de aplicação não pode ser subdivida por contextos gerenciais de desenvolvimento, por exemplo, interno e externo ao órgão, ou baseada em diferenças de
plataformas ou tecnologias.
5.2.5.3 Deve-se estabelecer processo de atualização da baseline durante a evolução do sistema.
5.3 Remuneração por sprints
5.3.1 Conceito da modalidade
5.3.1.1 A modalidade de remuneração por sprint baseia-se no pagamento por sprint executada.
5.3.1.2 Considera-se uma sprint executada, quando o produto entregue ao final da sprint corresponde ao conjunto de itens acordados no planejamento da sprint.
5.3.1.3 A premissa para adoção dessa modalidade é possuir um Processo de Desenvolvimento de Software definido e baseado em métodos ágeis, com especificação de critérios
para aceitação e rejeição de sprints.
5.3.1.4 A modalidade admite prever diferentes tipos de sprints, que podem variar em função da composição mínima do time (quantidade e perfis) e do tipo de tecnologia
(linguagens e ambientes como web ou aplicativos móveis).
5.3.1.5 Para cada tipo de sprint, o valor a ser remunerado por sprint deve variar conforme sua capacidade de execução, devendo ser calculado a partir da composição de equipe
mínima definida para o projeto e da duração da sprint (timebox).
5.3.1.6 A capacidade alocada para um determinado tipo de sprint deve ser atribuída por meio de uma unidade de medida como, por exemplo, Hora de Serviço Técnico -
HST.
5.3.1.7 Para calcular a capacidade total alocada a um tipo de sprint, deve-se definir a composição da equipe que atuará no projeto e atribuir a cada perfil a sua capacidade diária
em função da unidade de medida escolhida, a exemplo de:
.
Sprint Tipo A
Sprint Tipo B
. Composição da equipe
1 SM (5 HST/dia)
1 DEV_SR (8 HST/dia)
1 DEV_PL (7 HST/dia)
Total = 20 HST/dia
1 SM (5 HST/dia)
1 DEV_SR (8 HST/dia)
2 DEV_PL (14 HST/dia)
Total = 27 HST/dia
. Timebox
15 dias
15 dias
. Capacidade alocada por Sprint
= 300 HST (15d * 20 HST)
= 405 HST (15d * 27 HST)
5.3.2 Mecanismos de gestão
5.3.2.1 O processo de desenvolvimento de software deverá prever uma fase inicial para o planejamento do projeto, que envolve a captura da visão do usuário, definição do
escopo macro do projeto e das principais funcionalidades do produto a ser desenvolvido (backlog do produto).
5.3.2.2 A execução dos serviços está condicionada à emissão de ordem de serviço, contendo no mínimo: o objetivo da OS, a composição do time ágil (perfil, quantidade e taxa
de alocação), os produtos/resultados a serem entregues e o prazo de atendimento.
5.3.2.3 Cada tipo de sprint deve estar associada a entrega de resultados aferidos por meio de métricas de tamanho de software previstas na seção 12.
5.3.2.4 É vedada a previsão de sprints restritas a fases específicas do ciclo de desenvolvimento ou que caracterizem meros pontos de controle ou paradas artificiais para reportar
a situação ou o andamento do projeto.
5.3.3 Dimensionamento
5.3.3.1 O dimensionamento do volume a ser contratado deve partir de uma estimativa para a quantidade máxima de sprints a ser executada em 12 meses, que está diretamente
relacionada à capacidade de gestão de projetos de desenvolvimento de software pelo órgão. Para isso, devem ser utilizados dados recentes relativos à quantidade de projetos dessa natureza
já executados pelo órgão, considerando ainda a necessidade de eventual incremento na capacidade de gestão de projetos do órgão projetada para um período de 60 meses, para comportar
o atendimento às necessidades negociais e objetivos estratégicos do órgão.
5.3.3.2 A partir da estimativa da demanda por sprints de projetos de desenvolvimento de software, o valor estimado da contratação pode ser obtido por meio do produto entre
o valor estimado por sprint e a quantidade de sprints a ser contratada.
5.3.3.3 A memória de cálculo que evidencie o roadmap do produto e a estimativa da quantidade de sprints relacionadas deve integrar os estudos técnicos preliminares.
5.3.4 Forma de pagamento
5.3.4.1 O pagamento deve ser um valor fixo por sprint executada, que pode variar por tipo de sprint, associado a níveis mínimos de serviço e vinculado a metas de
produtividade.
5.3.4.2 Deve-se implementar mecanismo progressivo de glosas no caso da rejeição da sprint, sem prejuízo da aplicação de sanções pelo inadimplemento dos serviços, a depender
das condições previstas no termo de referência, associado ao grau de rejeição do backlog da sprint ou a descumprimento reiterado das metas definidas inicialmente para a execução das
sprints.
5.3.5 Mecanismos de controle
5.3.5.1 Recomenda-se implantar ferramenta de gestão de projetos ágeis que permita calcular os níveis de serviço de forma automática.
5.3.5.2 Deve-se evitar o início de projetos ágeis sem o correspondente planejamento do produto a ser desenvolvido.
5.3.5.3 Deve-se definir critérios objetivos para aceitação ou rejeição de sprints, conforme exemplo constante do Anexo V.
5.3.5.4 O planejamento do projeto ágil, em especial quanto ao escopo e quantidade de sprints, deve ser aprovado pela Contratante.
5.3.5.5 As histórias de usuário devem ser padronizadas mediante templates.
5.3.5.6 Devem-se prever mecanismos, baseados em indicadores e glosas, que evitem que o trabalho incompleto realizado em uma sprint seja, com frequência, carreado para a
sprint seguinte.
5.4 Remuneração por alocação de profissionais de TI vinculada a resultado
5.4.1 Conceito da modalidade

                            

Fechar