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 05152023032200037
37
Nº 56, quarta-feira, 22 de março de 2023
ISSN 1677-7042
Seção 1
j) Implementação: processo que transforma requisitos, arquitetura e design, incluindo interfaces, em ações que criam um elemento ou componente de software de acordo com
as práticas de codificação previamente estabelecidas, usando técnicas, especialidades ou disciplinas de desenvolvimento de software. Esse processo resulta em um elemento software que
segue uma arquitetura e design estabelecidos.
k) Incremento de produto: versão de um produto que pode ser liberada no final de um período de tempo (timebox).
l) Metodologias ágeis: são um conjunto de práticas que visam a entrega rápida e de alta qualidade do produto ou serviço e que promovem um processo de gerenciamento de
projetos que incentiva a inspeção e adaptação frequente, beneficiando a eficiência e efetividade dos gestores públicos no controle da prestação dos serviços de TI, haja vista que o foco
passa a ser realmente nas atividades que entregam valor para as áreas de negócios.
m) Níveis mínimos de serviço: são regras objetivas e fixas que estipulam valores e/ou características mínimas de atendimento a uma meta a ser cumprida pela contratada na
prestação dos serviços.
n) Produto de Software ou Software: conjunto de programas, procedimentos, rotinas ou scripts, componentes, Application Programming Interface - API, webservices, incluindo
os dados e documentação associada.
o) Projeto ágil: projeto de desenvolvimento de software que utiliza abordagem de desenvolvimento ágil.
p) Proprietário/dono do produto (product owner): servidor e/ou representante da Contratante que compartilha a visão do produto, incluindo funcionalidades necessárias e
critérios de aceitação.
q) Qualidade de software: é a capacidade do software satisfazer as necessidades declaradas e implícitas das partes interessadas.
r) Release: distribuição/liberação de um incremento de produto para um cliente ou usuários. A quantidade de sprints por release deve ser definida previamente à execução dos
serviços.
s) Requisitos funcionais: conjunto de requisitos do usuário que descrevem o que o software deve fazer em termos de tarefas e serviços.
t) Requisitos não funcionais: conjunto de requisitos relacionados a como deve ser construído ou manutenido o software, como deve ser o desempenho em operação, aspectos
relacionados às tecnologias, à qualidade do software e ao ambiente tecnológico que suporta o software. Os requisitos não funcionais podem ser descritos como atributos de qualidade, de
desempenho, de segurança ou como uma restrição geral em um sistema. Não estão incluídos os aspectos relacionados às funções ou tarefas previstas no software.
u) Reunião diária: reunião diária curta, limitada a um período, usada para discutir o progresso, planos e quaisquer impedimentos com membros de um time ágil.
v) Software pronto para uso: é aquele software disponibilizado (pago ou não) com um conjunto de funcionalidades pré-concebidas, também conhecido como Ready to Use
Software Product (RUSP) ou comumente de "software de prateleira".
w) Roadmap ou Visão do produto: é um plano de ação de como um produto evoluirá ao longo do tempo. Esse plano apresenta uma linha do tempo com marcos de alto nível
para um ciclo de vida do produto, particularmente o cronograma para implantação de funcionalidades do produto, com vistas a orientar o progresso em direção a uma meta definida.
x) Softwares de atividades-meio: aqueles que são utilizados para apoio de atividades de gestão ou administração operacional, como, por exemplo, softwares de recursos humanos,
ponto eletrônico, portaria, biblioteca, gestão de patrimônio, controle de frotas, gestão eletrônica de documentos, e que não têm por objetivo o atendimento às áreas finalísticas para a
consecução de políticas públicas ou programas temáticos.
y) Sprint: consiste em um ciclo de iteração por um período de até 4 semanas, em que um conjunto acordado de histórias de usuário ou funcionalidades são projetadas,
desenvolvidas, testadas, aceitas e se tornam aptas para implantação.
z) Time/Equipe ágil: pequeno grupo multifuncional de pessoas (entre 3 a 10 membros) que colaboram no desenvolvimento de um produto, dentro de uma metodologia ágil.
aa) Timebox: período de tempo fixo, previamente estabelecido, durante o qual um indivíduo ou equipe trabalha constantemente para a conclusão de um objetivo acordado.
2.3 Escopo do modelo
2.3.1 São abrangidas por este modelo, as atividades de:
a) Desenvolvimento, manutenção ou sustentação de software, inclusive portais e aplicativos móveis, data warehouse, big data, Business Intelligence e Administração e Governança
de Dados;
b) Testes, mensuração, segurança e controle de qualidade de software;
c) Projeto, elicitação e análise de requisitos, design, arquitetura, codificação, prototipação, implementação, implantação, correção, adaptação, evolução, sustentação e inspeção
de software;
d) Projeto, modelagem e implantação de ambiente de banco de dados, automação de processos baseados em software e criação e atualização de design system e componentes
de interface e experiência do usuário (UX).
2.3.2 Não são abrangidos por este modelo:
a) Serviços de suporte e operação de infraestrutura de TIC;
b) Soluções comercializadas sob o modelo de Software as a Service (SaaS);
c) Soluções de software embarcadas em equipamentos e dispositivos;
d) Contratação de licenciamento ou subscrição de software pronto para uso (Software de prateleira).
3. BALIZADORES DO MODELO
3.1 O modelo está orientado a partir das seguintes bases:
a) Entrega de valor: atendimento às expectativas e necessidades dos usuários dos serviços públicos prestados pela Organização, os quais são apoiados por softwares que devem
estar em funcionamento com qualidade, segurança e usabilidade adequadas as suas finalidades;
b) Objetividade: adoção de métricas objetivas de aferição de qualidade e produtividade;
c) Qualidade: capacidade do produto de software em satisfazer necessidades declaradas e implícitas dos usuários para que estes alcancem seus objetivos específicos com eficácia,
eficiência, segurança e satisfação. A avaliação da qualidade deve ser um requisito necessário para se efetuar o pagamento pela prestação do serviço;
d) Segurança da informação: adoção de processos de desenvolvimento seguro de software;
e) Padronização: aderência às modalidades de remuneração previstas neste documento;
f) Foco no alcance a resultados: assegurar que o pagamento seja vinculado à entrega de produto de software com qualidade, por meio da aferição de métricas de software,
observando metas de produtividade, critérios de aceitação dos produtos e níveis mínimos de serviço previamente estabelecidos.
4. DIRETRIZES ESTRATÉGICAS
4.1 Da seleção do portfólio de produtos de software
4.1.1 Os softwares a serem desenvolvidos (projetos de novos softwares) devem estar alinhados ao Plano Diretor de Tecnologia da Informação e Comunicação do órgão.
4.1.2 Deve-se avaliar a existência de software pronto para uso (RUSP) que atenda a necessidade do sistema a ser desenvolvido, avaliando-se técnica e economicamente a
utilização do software pronto para uso, em detrimento do desenvolvimento de novo software.
4.1.2.1 Preliminarmente à apresentação de demanda por desenvolvimento de novo software, a área de negócio deve prospectar a existência de software pronto para uso (RUSP)
que atenda a sua necessidade.
4.1.2.2 A área de TI do órgão, em conjunto com a área de negócio demandante, deve avaliar técnica e economicamente a utilização do software pronto para uso, em detrimento
do desenvolvimento de novo software.
4.1.3 A avaliação de software pronto para uso (RUSP) quanto ao atendimento das necessidades de negócio deve ser realizada pela área de negócio do órgão ou entidade.
4.1.4 É vedada a utilização dos serviços contratados para o desenvolvimento de softwares de atividades de área meio, salvo nos casos em que o órgão ou entidade tenha obtido
autorização do órgão central do SISP ou do Órgão Central do respectivo sistema estruturador.
4.2 Da divisão do objeto
4.2.1 O órgão deve analisar, durante a fase de Planejamento da Contratação, a possibilidade de divisão do objeto em lotes. Para isso, podem ser utilizados critérios como: área
de negócio, volume de demandas, tecnologia ou outro critério que permita a definição clara dos limites de cada lote.
4.2.2 Para os casos em que a divisão do objeto é possível, deve-se analisar a viabilidade de contratação de mais de um fornecedor de serviços de desenvolvimento, manutenção
e sustentação de softwares, com vistas a mitigar riscos de indisponibilidade dos serviços ou dependência de fornecedor exclusivo.
4.2.2.1 Admite-se a contratação simultânea de mais de um fornecedor de serviços de desenvolvimento, manutenção e sustentação de software em lotes distintos, com vistas a
possibilitar a adjudicação para cada lote, em consonância com o definido no subitem 4.2.1. Para isso, deve-se assegurar durante o planejamento da contratação e a gestão do contrato a
não sobreposição da realização de atividades em um mesmo escopo de item de software, simultaneamente, conforme Acórdão TCU 2.362/2015-P.
4.2.2.2 A análise de que trata o caput deve considerar a capacidade de gestão e fiscalização de contratos do órgão.
4.3 Da gestão da capacidade
4.3.1 O órgão deve avaliar, durante a fase de Planejamento da Contratação, se dispõe de servidores com a qualificação necessária e em quantidade suficiente para a fiscalização
de todos os controles, acompanhamento processual e demais atividades necessárias à aferição das exigências contratuais. Caso não haja servidores suficientes, o órgão deve adotar medidas
de mitigação de riscos, a exemplo de:
4.3.1.1 Adequar o escopo a ser contratado à capacidade de fiscalização e gerenciamento dos projetos;
4.3.1.2 Estabelecer critérios de priorização de projetos de desenvolvimento de software. Por se tratar de alocação de investimentos e impactar diretamente a execução de ações
do Plano Diretor de Tecnologia da Informação e Comunicação, o Comitê de Governança Digital ou instância colegiada equivalente deve avaliar e aprovar tais critérios;
4.3.1.3 Promover ações para criação de capacidade de gerenciamento e fiscalização dos contratos de desenvolvimento, manutenção e sustentação de software, seja por meio de
aumento do quadro efetivo de servidores, seja por meio da contratação de serviços de apoio à fiscalização;
4.3.1.4 Automatizar os processos de gerenciamento das demandas de serviço, incluindo coleta e aferição de indicadores de nível de serviço, inspeção e controle de qualidade
das entregas, com vistas a assegurar maior eficiência e segurança na fiscalização e monitoramento do contrato.
4.3.2 A área de TI deve definir previamente sua capacidade de produção e gestão contratual, considerando os recursos disponíveis. Devem ser avaliados, por exemplo,
quantidades e perfis profissionais de fiscais de contrato, donos de produto e gerentes de projeto, bem como diretrizes e priorizações de negócio, ferramentas de gestão e automação
necessárias ou implantadas, processos de gerenciamento de demanda e controle de qualidade implantados, entre outros elementos que impactem a capacidade de gerenciamento e
fiscalização do volume de demandas de serviços de desenvolvimento, manutenção e sustentação de software.
4.3.3 Recomenda-se utilizar o histórico de demandas relacionadas ao desenvolvimento, manutenção e sustentação de software para aferir a capacidade de gerenciamento e
fiscalização. Caso não haja histórico no órgão, a área de TI deve realizar uma análise comparativa com outros órgãos que possuam características semelhantes e dar início ao registro de
demandas com o objetivo de construir sua própria base histórica.
4.3.4 O órgão deve assegurar a adequada capacitação de seus servidores para a fiscalização e gestão dos contratos e para o monitoramento da execução de atividades do seu
processo de desenvolvimento de software.
4.3.5 Deve-se promover o gerenciamento do backlog do produto e das iterações de um projeto ágil. Para isso, o órgão deve prover profissionais, preferencialmente servidores,
nos papéis de dono do produto e de gerente de projeto, no que couber. Caso o órgão não disponha de servidores em quantidade suficiente para atuar nesses papéis, admitem-se algumas
ações para assegurar a relação demanda/capacidade de equipe em patamares adequados, a exemplo de:
4.3.5.1 Contratação em separado de serviços de apoio a utilização/adoção de metodologias ágeis, gestão de serviços e/ou gestão de projetos.
4.3.5.2 Redução da quantidade e/ou volume de projetos para adequação da capacidade, desde que autorizado pelo Comitê de Governança Digital ou instância colegiada
equivalente.
4.3.5.3 Estabelecer processos de gerenciamento de demanda, preferencialmente, suportados por ferramentas de automação.
4.3.6 Recomenda-se avaliar a contratação de serviços técnicos especializados complementares aos contratos de desenvolvimento, manutenção e sustentação de softwares, a
exemplo de:
4.3.6.1 Serviços especializados de mensuração de software;
4.3.6.2 Serviços especializados de controle qualidade de software;
4.6.3.3 Serviços especializados de avaliação de segurança de software.
4.3.7 Caso seja necessária a contratação de serviços complementares, deve-se estabelecer condições no Termo de Referência com vistas a não permitir que a empresa contratada
para realizar os serviços de desenvolvimento, manutenção e sustentação de softwares seja a mesma contratada para a executar os serviços complementares, conforme preconizado no art.
4º da Instrução Normativa SGD/ME nº 94, de 23 de dezembro de 2022.
4.4 Do processo de desenvolvimento, manutenção e sustentação de software
4.4.1 Deve-se adotar um Processo de Desenvolvimento de Software segmentado em iterações curtas, entregas frequentes e projetos com escopos delimitados, referenciando-o
no instrumento convocatório, observando-se preferencialmente o processo de desenvolvimento de software do SISP.