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 05152023032200046
46
Nº 56, quarta-feira, 22 de março de 2023
ISSN 1677-7042
Seção 1
. Líder Técnico de Desenvolvimento
Atua na organização da entrega contínua dos produtos de software, conduzindo os times de desenvolvedores na aplicação das melhores práticas e
técnicas de codificação, observando os padrões de projetos de software e metas a serem alcançadas na execução das sprints.
. Analista
de
Negócios/Requisitos
(Junior, Pleno e Sênior)
Atua na identificação, definição e documentação de processos de negócios e de requisitos de software a serem implementados. O analista de
negócio busca assegurar uma ligação consistente entre as equipes de negócios e a equipe de desenvolvedores, facilitando a comunicação e
auxiliando no aprofundamento do domínio do negócio objeto da implementação.
.
Atua, também, na propositura de funcionalidades e na organização das informações, no comportamento e fluxo do processo da aplicação
satisfazendo as necessidades de negócio declaradas e não declaradas.
. Analista de BI
(Junior, Pleno e
Sênior)
Atua na modelagem de repositórios de dados de apoio à tomada de decisão, da implementação de processos de extração, transformação e carga
de dados, no projeto e implementação de aplicações de automação e inteligência artificial, no processamento de dados massivos, na análise da
qualidade de dados, na criação e evolução de painéis de business intelligence.
. Administrador de Dados
(Pleno e
Sênior)
Atua na garantia da qualidade das estruturas dos metadados das soluções alinhadas aos padrões de arquitetura de dados da organização, apoia na
organização da informação corporativa objeto das aplicações em desenvolvimento, na garantia da integração e na aplicação das melhores práticas
de administração de dados corporativos.
. Scrum Master
Atua na facilitação do processo de desenvolvimento ágil de software, orientando as equipes de desenvolvimento, acompanhando, identificando e
eliminando impedimentos e promovendo o uso de padrões e melhores práticas ágeis. O scrum master busca garantir o bom funcionamento de
processos e atividades ágeis e é responsável por liderar reuniões previstas no processo de desenvolvimento.
. Gerente de projetos de tecnologia da
informação
Atua na organização das atividades dos times, no monitoramento e solução de conflitos, no apoio à tomada de decisão técnica, na aplicação das
melhores práticas de gerenciamento de projetos para assegurar a entrega de uma ou mais soluções em conjunto.
. Analista de UX/UI
Atua na criação de soluções tecnológicas para melhorar a experiência do usuário de um produto ou serviço de software. Atua também na definição
das características de interface com o usuário (design), de modo a garantir usabilidade e disposição da informação no meio de comunicação.
ANEXO III
LISTA EXEMPLIFICATIVA DE ATIVIDADES INCLUÍDAS NO SERVIÇO DE SUSTENTAÇÃO POR PAGAMENTO FIXO MENSAL
1. O serviço de sustentação de software corresponde ao conjunto de atividades necessárias para manter a disponibilidade, estabilidade e desempenho do software em produção,
dentro dos níveis de serviço estabelecidos pelo órgão ou entidade.
2. O presente anexo apresenta lista exemplificativa de atividades a serem incluídas em serviços de sustentação para a modalidade de remuneração baseada em valor fixo
mensal:
2.1. Manutenção corretiva: Consiste na eliminação de comportamentos do software que diferem de suas especificações ou que provoquem a interrupção inesperada de seu
funcionamento;
2.2. Manutenção adaptativa de pequeno porte: São exigíveis, a título de sustentação e consequentemente sem provocar acréscimo ao pagamento fixo, até uma adaptação não-
disruptiva (de pequeno porte) do ambiente computacional a cada ano. Considera-se adaptação de pequeno porte aquela cujo objetivo encontra-se em uma das hipóteses abaixo:
2.2.1. Atualização de versão de navegadores internet;
2.2.2. Atualização de versão de servidor de aplicação;
2.2.3. Atualização de versão de servidor de banco de dados;
2.2.4. Atualização de versão de linguagem de programação;
2.2.5. Atualização de versões de frameworks e/ou bibliotecas.
2.3. Manutenção cosmética localizada: consiste em alteração de interface de usuário que não implique alteração das regras de negócio e que seja realizada de forma localizada,
isto é, pela intervenção em um único arquivo ou em um pequeno conjunto de arquivos. Tal manutenção pode ser exemplificada da forma que se segue:
2.3.1. Fontes de letra, cores, logotipos, mudanças de botões, alteração na posição de campos e texto na tela;
2.3.2. Mudanças de texto em mensagens do sistema, título de um relatório ou labels de uma tela de consulta;
2.3.3. Mudanças de texto estático em e-mail enviado pelo sistema;
2.3.4. Adição ou reestruturação de menus de navegação estáticos;
2.3.5. Adição ou reestruturação de Ajuda (help estático);
2.3.6. Criação, alteração ou exclusão de páginas estáticas.
2.4. Apurações especiais: Consiste na preparação de roteiros de execução em linguagem SQL, ou outra adequada ao caso, destinados às extrações de dados não cobertas pelos
relatórios do sistema, à correção de inconsistências nos dados mantidos pelo sistema e não realizáveis por meio das interfaces de usuário disponíveis (ou cujo volume inviabilize a sua
execução de forma manual), ou à inserção de dados não automatizada no sistema;
2.5. Diagnóstico: Apoio à identificação e isolamento de falhas e problemas em potencial na execução do software;
2.6. Suporte técnico: Prestação de esclarecimentos quanto à forma como foram implementados requisitos de sistema, procedimentos requeridos ao seu correto funcionamento
ou aos dados mantidos por ele;
2.7. Análise de viabilidade: verificação de viabilidade de desenvolvimento para soluções propostas ou problemas e oportunidades de melhoria apresentados;
2.8. Homologação assistida: apoio nos procedimentos de homologação, incluindo configuração de parâmetros, saneamento de dúvidas, depuração de problemas e apoio à equipe
de infraestrutura;
2.9. Atendimento:
2.9.1. Participação em reuniões com usuários ou áreas de negócio, além de discussões técnicas e/ou alinhamento de processos e técnicas com áreas correlatas tais como
infraestrutura e projetos;
2.9.2. Execução de quaisquer procedimentos operacionais rotineiramente requeridos por sistema em função de suas regras de negócio ou forma de construção;
2.9.3. Outras atividades correlatas à sustentação.
ANEXO IV
EXEMPLO DE COMPOSIÇÃO E ALOCAÇÃO DE TIMES
1. Independente da modalidade adotada, deve-se especificar a formação da equipe que executará os serviços de desenvolvimento e manutenção de software, incluindo a
identificação de perfis compatíveis com a natureza e especificidade do ambiente tecnológico da organização.
2. O presente anexo dispõe sobre diretrizes para composição e alocação de profissionais aos times ágeis, a saber:
2.1. Os times ágeis deverão ser declarados no início do projeto e eventuais trocas de profissionais deverão ser comunicadas à contratada.
2.2. A organização deve prever que projetos que sofrerem desligamento/mudança de integrantes de times ágeis e subsequente insucesso total ou parcial na aceitação de sprints
estarão sujeitos a aferição de indicadores de nível mínimo de serviço, a exemplo do Indicador de desmobilização de equipe (IDE) - descrito no Anexo I - capaz de monitorar e incentivar
a manutenção dos membros das equipes durante a execução das sprints.
2.3. Deve-se prever que a violação das regras estabelecidas pela organização ensejará aplicação de sanções, conforme critérios de nível de serviço previamente estabelecidos.
2.4. O risco de ociosidade da capacidade de trabalho alocada instalada em situações de baixa demanda deve ser mapeado.
2.5. Deve-se prever, conforme tabela exemplificativa a seguir:
a) A composição mínima dos times, incluindo a identificação dos perfis profissionais e quantidades;
b) Regras para compartilhamento/alocação dos profissionais, obedecendo limites pré-estabelecidos.
. Perfis Profissionais
Quantidade
Compartilhamento / Alocação
. Scrum Master
1
Até 3 projetos
. Desenvolvedor Pleno
2
Não pode ser compartilhado entre projetos
. Desenvolvedor Sênior
1
Não pode ser compartilhado entre projetos
. Arquiteto Sênior
1
Até 3 projetos
. Analista de Negócios/Requisitos Sênior
1
Até 2 projetos
. Administrador/Projetista de Dados Sênior
1
Até 5 projetos
. Analista de Testes/Qualidade Sênior
1
Até 5 projetos
ANEXO V
EXEMPLO DE DEFINIÇÃO DE PRONTO (CHECKLIST DE ADMISSÃO DO PRODUTO)
1. O presente anexo apresenta exemplos de critérios para admissão de um produto.
2. Esses critérios devem ser observados quando um produto é enviado para homologação por parte da contratada, para admissão à implantação em ambiente de
homologação.
3. A Definição de Pronto é uma descrição formal do estado do incremento, quando ele atende aos níveis de serviço exigidos para o produto; todo o time ágil deve estar em
conformidade com a definição de pronto.
4. A organização deve estabelecer critérios sem os quais o produto é rejeitado de imediato.
5. Para admissibilidade do produto: a organização deve estabelecer critérios objetivos para aceitação dos produtos e serviços prestados, a exemplo:
a) Código-fonte submetido ao controle de versões da contratada;
b) Existência de testes unitários e do Relatório de Testes;
c) Existência de scripts de banco de dados com dicionário de dados embutido nos metadados (ausência apenas quando não houver mudança no modelo de dados);
d) Existência de arquivo para geração de Build (ex: Arquivo de projeto Maven);
e) Disponibilização de processos prontos para execução na ferramenta de CI/CD adotada, juntamente com a entrega e configuração de containers configurados pela ferramenta
orquestração adotada;
f) Existência de Manual de Implantação, conforme modelo disponível no PDS;
g) Existência de Manual do Usuário, conforme modelo disponível no PDS.
6. Para aceitação da demanda: após realizar a inspeção do produto quanto à sua admissibilidade, a contratada deverá:
a) Executar testes funcionais automatizados que tenham sido solicitados e, consequentemente, verificar se estão corretamente implementados ou mesmo se existem, além de
observar os resultados da execução;
b) Executar testes unitários ou verificar relatórios de execução destes que possam envolver porções críticas do produto;
c) Realizar alguns testes funcionais, pelo menos nos principais fluxos do produto entregue.
7. Após a realização dos testes, a organização deve proceder a uma das ações a seguir:
a) Rejeição: caso sejam percebidos defeitos de natureza impeditiva em alguma história implementada ou não tenha coberto o escopo planejado de tal forma que a entrega não
seja passível de aceitação;
b) Aceitação parcial: caso a demanda possua alguns defeitos significativos de natureza não-impeditiva ou não tenha coberto o escopo planejado de tal forma que ainda seja
passível de aceitação;
c) Aceitação integral: caso a demanda esteja em nível de qualidade tal que não sejam percebidos defeitos significativos, bem como envolva cumprimento do escopo
planejado.