Portaria nº 378, de 03/09/2026

PORTARIA Nº 378, DE 03 DE SETEMBRO DE 2026

Regulamenta a Metodologia de Desenvolvimento de Sistemas no âmbito da Secretaria de Estado de Educação do Distrito Federal e estabelece diretrizes para o desenvolvimento, a manutenção, homologação e implantação de soluções de software e dá outras providências.

O SECRETÁRIO DE ESTADO DE EDUCAÇÃO DO DISTRITO FEDERAL, no uso das atribuições que lhe confere o inciso I do parágrafo único do artigo 105 da Lei Orgânica do Distrito Federal, em atenção à Metodologia de Desenvolvimento de Sistemas, aprovada pela Decisão nº 18/2025 – SEE/GAB/CIG, ao Plano de Gerenciamento de Mudanças em Tecnologia da Informação, aprovado pela Decisão nº 10/2026 – SEE/GAB/CIG, e à Norma de Segurança da Informação e Comunicação, instituída por meio da Resolução – SEE/GAB/CIG nº 05, de 17 de março de 2026, resolve:

TÍTULO I — CAPÍTULO ÚNICO

DAS DISPOSIÇÕES PRELIMINARES

Art. 1º Regulamentar a aplicação da Metodologia de Desenvolvimento de Sistemas (MDS), aprovada pela Decisão nº 18/2025 - SEE/GAB/CIG, no âmbito da Secretaria de Estado de Educação do Distrito Federal (SEEDF), destinada a padronizar os serviços técnicos relativos aos softwares operacionalizados pela Subsecretaria de Operações em Tecnologia da Informação e Comunicação (Subtic), compreendendo as demandas de desenvolvimento, sustentação, evolução, implantação, manutenção, operação, descomissionamento ou outras soluções de software desenvolvidas ou mantidas sob responsabilidade dessa Subsecretaria.

Art. 2º O processo de solicitação, gestão e todo ciclo de vida de desenvolvimento de software será pautado na MDS, na Norma de Segurança da Informação e Comunicação (Nosic) e nas disposições desta Portaria, para padronizar o fluxo de atendimento das demandas das áreas à Subtic, desde o recebimento da demanda até a entrega final e a sustentação do produto, e promover transparência, celeridade, impessoalidade e responsabilização nos processos de desenvolvimento de softwares da SEEDF.

Art. 3º Para fins desta norma, considera-se:

I - ajuste: correção ou adequação pontual em solução existente;

II - aplicação: conjunto coeso de dados e procedimentos automatizados que suportam um objetivo de negócio, podendo consistir em um ou mais componentes, módulos ou subsistemas;

III - aplicações móveis: softwares especificamente desenvolvidos ou adaptados para execução em dispositivos portáteis, como smartphones e tablets, observando requisitos de segurança e usabilidade específicos para mobilidade;

IV - área demandante: área de negócio da SEEDF demandante da solução de software, responsável pela formalização da necessidade, validação dos requisitos e homologação das entregas;

V - área técnica: unidade técnica da estrutura da Subtic responsável pela demanda;

VI - automação de processos: utilização de tecnologia para executar tarefas repetitivas e fluxos de trabalho, com vistas à redução de intervenção manual, minimização de erros e aumento da eficiência operacional;

VII - backlog do produto: lista priorizada de todos os requisitos (funcionais e não funcionais), funções, tecnologias, melhorias e correções de defeitos que constituem as mudanças que serão efetuadas no produto;

VIII - backlog institucional: repositório central e dinâmico que consolida as demandas de software da SEEDF após análise de admissibilidade, servindo como a lista priorizada de requisitos e funcionalidades a serem implementados pelo Time Ágil, em estrito alinhamento ao planejamento estratégico e ao Plano Diretor de Tecnologia da Informação (PDTI);

IX - evolução funcional: atividades de ampliação, alteração ou aperfeiçoamento de funcionalidades, regras de negócio, fluxos operacionais ou integrações em sistemas existentes, visando agregar novo valor ao produto;

X - integrações: estabelecimento de interfaces e canais de comunicação, preferencialmente via Application Programming Interfaces (APIs), que permitam a troca automatizada de dados e a interoperabilidade entre diferentes ativos de informação;

XI - manutenção adaptativa: adequações sistêmicas necessárias para compatibilizar o software com mudanças no ambiente tecnológico, tais como atualizações de infraestrutura, sistemas operacionais, arquitetura corporativa ou novas políticas de segurança da informação;

XII - manutenção corretiva: conjunto de intervenções técnicas destinadas a eliminar comportamentos do software que divergem de suas especificações originais ou que causem interrupções inesperadas e incidentes em ambiente de produção;

XIII - novo sistema: solução tecnológica inédita, desenvolvida para atender demanda institucional ainda não contemplada pelos sistemas existentes;

XIV - Ordem de Serviço (OS): documento padronizado que autoriza o início da execução da demanda solicitada, após definição do escopo e aprovação dos requisitos;

XV - Ordem de Serviço de Sustentação (OSS): documento padronizado para formalização das demandas de serviços Técnicos de Sustentação de Software;

XVI - padrões de governo: requisitos normativos ou técnicos que devem ser cumpridos pela SEEDF no desenvolvimento e na implantação de sistemas no âmbito do Distrito Federal, como os de acessibilidade, segurança da informação, padrões web e de interoperabilidade;

XVII - painéis gerenciais: instrumentos de visualização de dados, como dashboards analíticos e ferramentas de Business Intelligence (BI), destinados a subsidiar o monitoramento de indicadores e a tomada de decisão estratégica;

XVIII - Product Owner (PO) - Dono do Produto: servidor lotado nas áreas de negócio, representante da área demandante da solução de software, designado por autoridade competente e apoiado pelo Time Ágil;

XIX - roadmap: plano de ação que contempla o planejamento, especificação e implementação dos objetivos de negócio e histórias de usuário contidas nos releases, a serem distribuídas nos ciclos de desenvolvimento (sprints);

XX - soluções baseadas em Inteligência Artificial (IA): sistemas e algoritmos capazes de realizar tarefas que exijam processamento cognitivo, análise preditiva, automação inteligente ou tomada de decisão automatizada;

XXI - sprint: ciclo de trabalho da metodologia ágil adotada para planejamento, desenvolvimento, validação e entrega incremental das funcionalidades;

XXII - Time Ágil: equipe técnica (servidores ou contratados) responsável por codificação, testes unitários e documentação técnica;

XXIII - usuário: usuário final ou um agente de software que usará os serviços e/ou produtos de tecnologia da informação desenvolvidos.

TÍTULO II — DO CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE

CAPÍTULO I — DA SOLICITAÇÃO DE NOVAS DEMANDAS

Art. 4º Compete à Subtic exercer a gestão do ciclo de vida das soluções de software, compreendendo recebimento, triagem, análise técnica, classificação, análise de viabilidade, priorização, encaminhamento para o desenvolvimento, homologação, implantação e sustentação.

Art. 5º O processo de solicitação de desenvolvimento de soluções de software será formalizado exclusivamente via Processo no Sistema Eletrônico de Informações (SEI), devendo conter, obrigatoriamente:

I - descrição clara da necessidade e justificativa;

II - undamentação legal e alinhamento ao PDTI e/ou objetivos estratégicos;

III - benefícios esperados, impactos e riscos previstos;

IV - indicação formal do Product Owner (PO) pela unidade demandante e respectivo substituto;

V - assinatura da autoridade competente máxima da área demandante.

Art. 6º Uma vez recebida a solicitação por meio do SEI, as demandas de solução de software serão cadastradas em ferramenta institucional de gestão de ciclo de vida de software e classificadas nas seguintes categorias:

I - arquitetura e desenho: elaboração do desenho da arquitetura, contemplando a topologia de rede, integração com o provedor de identidade oficial da SEEDF e matriz de controle de acesso fundamentada no princípio do menor privilégio, especialmente para ambientes com restrições operacionais severas;

II - automatização: utilização de tecnologia para executar tarefas repetitivas e fluxos de trabalho (workflows), visando à redução de erros humanos e ao aumento da eficiência operacional;

III - Business Intelligence (BI): construção e manutenção de painéis gerenciais, dashboards analíticos e instrumentos de visualização de dados destinados a subsidiar a tomada de decisão estratégica;

IV - correção: intervenção técnica emergencial ou planejada destinada a eliminar comportamentos do software que divergem de suas especificações originais ou que causem interrupções inesperadas (incidentes);

V - evolução: atividade de ampliação, alteração ou aperfeiçoamento de funcionalidade, regra de negócio ou fluxo operacional em sistema já existente, visando agregar novo valor institucional ao produto;

VI - integração: estabelecimento de interfaces de comunicação e interoperabilidade entre diferentes ativos de informação, preferencialmente via Application Programming Interfaces (APIs), para assegurar a troca automatizada de dados;

VII - Inteligência Artificial (IA): desenvolvimento ou implementação de algoritmos e modelos capazes de realizar processamento cognitivo, análise preditiva ou automação inteligente de tarefas;

VIII - modernização tecnológica: atividades de atualização de arquitetura, frameworks, linguagens de programação ou migração de infraestrutura de sistemas legados para garantir segurança, escalabilidade e sustentabilidade tecnológica;

IX - novo sistema: criação de solução tecnológica inédita destinada a atender demanda institucional ainda não contemplada pelos sistemas existentes, seguindo integralmente o Processo de Desenvolvimento Ágil (PDA);

X - projeto estratégico: iniciativa de alta complexidade e impacto institucional, explicitamente vinculada aos objetivos do PDTI e à Estratégia de Transformação Digital da Secretaria;

XI - sustentação: conjunto de atividades contínuas voltadas a garantir a disponibilidade, o suporte técnico de terceiro nível e a integridade de sistemas em ambiente de produção até sua descontinuação.

§ 1º A ferramenta institucional de gestão de ciclo de vida de software conterá todos os artefatos, atividades e etapas da demanda de software previstas na MDS, constituindo-se de ferramenta oficial de gestão pela área técnica e acompanhamento pela área demandante.

§ 2º As informações registradas na ferramenta de gestão de ciclo de vida de software constituirão o histórico oficial da execução da demanda, servindo de base para auditorias, indicadores de desempenho, gestão do conhecimento e acompanhamento da governança de tecnologia da informação.

§ 3º A comunicação entre as áreas demandante e técnica deverá ser realizada exclusivamente por canais oficiais de comunicação institucional adotados pela SEEDF, sendo vedado o uso de canais pessoais ou informais pela área requisitante para a solicitação de demandas ou tomada de decisões que alterem o projeto, podendo esta utilizar-se de reuniões agendadas previamente com a área técnica para deliberar sobre tais assuntos, que serão registrados em ata no Processo SEI e assinados por ambas as áreas para que produzam efeitos.

CAPÍTULO II — DA ANÁLISE DE ADMISSIBILIDADE E DA PRIORIZAÇÃO

Art. 7º Recebido o Processo pela área de desenvolvimento de sistemas, a equipe técnica da Subtic agendará reunião com a área demandante para compreender a necessidade apresentada, definir o escopo do projeto, avaliar a viabilidade técnica e operacional da demanda, identificar impactos, dependências e restrições, e analisar a execução da demanda em relação às demais existentes na fila de desenvolvimento, observados os critérios de prioridade institucional, complexidade, criticidade e tamanho do escopo.

Art. 8º Realizada a reunião inicial, a equipe técnica elaborará a análise de viabilidade técnica e estratégica, emitindo o respectivo parecer de admissibilidade para o prosseguimento da demanda.

Parágrafo único. O parecer de admissibilidade permitirá a inclusão da demanda no Backlog Institucional e será fundamentado nos seguintes critérios:

I - aderência ao PDTI: verificação do alinhamento da solicitação com as metas, ações e cronogramas estabelecidos no Plano Diretor de Tecnologia da Informação vigente na SEEDF;

II - aderência ao planejamento estratégico: avaliação quanto ao suporte que a solução tecnológica conferirá aos objetivos finalísticos da Secretaria e à Estratégia de Transformação Digital;

III - existência de solução semelhante: análise do portfólio de sistemas da SEEDF e de outros órgãos para identificar ferramentas que já atendam, total ou parcialmente, à necessidade apresentada, visando evitar a fragmentação e duplicidade funcional;

IV - possibilidade de parametrização: estudo da viabilidade de configurar funcionalidades ou módulos já existentes em sistemas corporativos para absorver a nova demanda sem a necessidade de desenvolvimento de código inédito;

V - reutilização de sistemas existentes: avaliação técnica sobre o aproveitamento de componentes de software, bases de dados, APIs e arquiteturas já homologadas pela SEEDF, visando à padronização e à economia de recursos;

VI - viabilidade técnica: diagnóstico realizado pela equipe técnica sobre a compatibilidade da demanda com os padrões tecnológicos, linguagens de programação e frameworks estabelecidos na MDS;

VII - utilização preferencial dos cadastros corporativos oficiais da SEEDF, evitando duplicidade de bases de dados e promovendo a padronização das informações institucionais;

VIII - impacto financeiro: análise da relação custo-benefício e estimativa de gastos com implementação, licenciamento de softwares e manutenção futura, observando-se a adequação orçamentária e financeira ao Plano Plurianual (PPA) e Lei Orçamentária Anual (LOA);

IX - impacto operacional: mensuração das alterações nos fluxos de trabalho da unidade demandante, necessidade de capacitação de servidores e ganhos de eficiência pedagógica ou administrativa;

X - riscos: identificação de ameaças técnicas, prazos exíguos ou resistências institucionais que possam comprometer a execução do projeto, classificadas conforme matriz de probabilidade e severidade;

XI - segurança: garantia da aplicação dos preceitos de Security by Design, assegurando a proteção contra vulnerabilidades críticas e conformidade com a Nosic desde a fase de iniciação;

XII - infraestrutura: avaliação da capacidade instalada de processamento, armazenamento em nuvem ou local, conectividade e rede lógica estruturada necessária para a sustentação e disponibilidade da solução.

Art. 9º Uma vez admitida a demanda, a área técnica responsável emitirá matriz de priorização das demandas para apreciação do Comitê Interno de Governança (CIG) da SEEDF quanto à priorização na fila de desenvolvimento de software da Secretaria, observados os seguintes aspectos:

I - obrigação legal: refere-se a demandas impositivas decorrentes de leis, decretos, decisões judiciais ou determinações de órgãos de controle que estabeleçam prazos peremptórios para cumprimento;

II - calendário escolar: critério que avalia a criticidade da solução em relação aos marcos temporais do ano letivo, priorizando ferramentas indispensáveis à realização de matrículas, avaliações e registros acadêmicos;

III - impacto institucional: mensura o grau de alinhamento da demanda aos objetivos estratégicos da Secretaria e às metas definidas no PDTI, com vistas à geração de valor público;

IV - número de usuários: critério quantitativo que analisa a amplitude do benefício gerado, priorizando soluções que atendam a grandes parcelas da comunidade escolar ou administrativa;

V - risco operacional: avalia a probabilidade e o impacto de falhas que possam comprometer a continuidade das atividades administrativas ou pedagógicas da Secretaria, fundamentado no princípio da resiliência institucional;

VI - impacto financeiro: considera a relação entre o custo de implementação e os benefícios esperados, incluindo a potencial redução de despesas operacionais e a observância à disponibilidade orçamentária no PPA e na LOA;

VII - segurança da informação: prioriza o tratamento de vulnerabilidades críticas e a implementação de controles que garantam a Confidencialidade, Integridade, Disponibilidade e Autenticidade (Cida) dos ativos informacionais;

VIII - disponibilidade da equipe: análise da capacidade técnica e da carga de trabalho do Time Ágil e da equipe técnica da Subtic para o atendimento da demanda sem prejuízo a projetos estratégicos em curso;

IX - complexidade: avalia o nível de dificuldade técnica, a necessidade de integrações com sistemas legados e a extensão do esforço de desenvolvimento e testes necessários para a entrega do incremento de software.

Art. 10. Definida a priorização da demanda pelo CIG da SEEDF, a área técnica submeterá o projeto para desenvolvimento interno ou por meio de fábrica de software contratada do órgão, conforme a análise dos critérios verificados nos artigos 8º e 9º desta Portaria.

CAPÍTULO III — DO DESENVOLVIMENTO

Art. 11. O desenvolvimento de softwares de que trata esta Portaria observará integralmente a MDS da SEEDF.

Art. 12. O início das atividades técnicas de desenvolvimento se dará com a elaboração do Documento de Visão do Produto (DVP), a definição do Roadmap e a assinatura da Ordem de Serviço pelas áreas técnica e demandante.

Art. 13. A entrega do projeto poderá ser dividida em ciclos de sprints a serem definidos pela área técnica na fase de planejamento, variando conforme a complexidade da demanda, a prioridade institucional, a criticidade do serviço e a dimensão do escopo do produto.

Art. 14. Cada sprint compreenderá, conforme o caso:

I - planejamento: fase inicial, destinada à definição do escopo da iteração, refinamento das histórias de usuário e estimativa de esforço pela equipe técnica;

II - execução do desenvolvimento: implementação das funcionalidades pactuadas no Backlog, orientada por reuniões de alinhamento e pelos princípios de Security by Design e codificação segura;

III - validação e homologação das entregas: processo conduzido pelo Product Owner para verificação da aderência do incremento às regras de negócio e aos critérios de aceitação estabelecidos na "Definição de Pronto";

IV - testes: garantia da qualidade por meio da execução de testes unitários, funcionais e automatizados, de regressão e de performance, assegurando a integridade e a resiliência da solução.

V - atualização documental: manutenção contínua de artefatos essenciais, incluindo o Documento de Visão do Produto (DVP), a Lista de Requisitos, o modelo de dados e o versionamento do código em repositório institucional;

VI - preparação para implantação: atividades finais que precedem a promoção ao ambiente de produção, englobando a elaboração do plano de reversão (rollback), manual do usuário e autorização da Subtic para efetivo funcionamento.

Art. 15. Concluído o ciclo de sprint do projeto pela área técnica, será solicitada validação, aprovação e assinatura da entrega à área demandante por meio da ferramenta de gerenciamento do ciclo de vida de desenvolvimento de software, registrando-se a aprovação eletrônica do Product Owner representante da área.

§ 1º O servidor designado como Product Owner deverá manifestar-se quanto ao aceite ou à rejeição fundamentada das entregas, parciais ou finais, no prazo de até cinco dias úteis, contados da data de sua disponibilização para validação.

§ 2º A assinatura do Termo de Aceite da entrega de cada sprint pela área demandante é condição obrigatória para o início da fase seguinte.

§ 3º A ausência de manifestação do Product Owner no prazo estabelecido será registrada no processo administrativo e na ferramenta corporativa de gerenciamento da demanda, suspendendo a execução das atividades subsequentes que dependam da validação da entrega.

§ 4º Persistindo a ausência de manifestação por período superior a dez dias, a Subtic comunicará formalmente o fato à autoridade máxima da unidade demandante, sobrestando os prazos de desenvolvimento estabelecidos para a área técnica até a regularização da pendência pela área demandante.

§ 5º A paralisação do projeto decorrente da ausência de validação ou da falta de manifestação da área demandante implicará o replanejamento do cronograma, com revisão das prioridades e da previsão de entrega da solução, observada a disponibilidade da equipe técnica.

§ 6º A recorrência de atrasos ou de omissões na validação das entregas poderá ser submetida ao CIG para conhecimento, deliberação e adoção das medidas de governança que entender pertinentes.

§ 7º Persistindo a ausência de manifestação da área demandante por período superior a trinta dias corridos, contado da disponibilização da entrega para validação, a Subtic encaminhará relatório circunstanciado à Corregedoria da SEEDF e à autoridade máxima da unidade demandante, contendo o histórico das notificações, dos prazos concedidos, das providências adotadas e dos impactos decorrentes da paralisação do projeto, para conhecimento e adoção das providências administrativas que entenderem cabíveis.

§ 8º No caso de rejeição da entrega, esta deverá ser motivada, contendo a descrição objetiva das não conformidades identificadas, vedada a recusa genérica ou desacompanhada de justificativa técnica ou negocial.

§ 9º Os apontamentos indicados na rejeição da entrega da sprint serão analisados pela área técnica, que poderá promover ajustes ou apresentar justificativa fundamentada de conformidade com os requisitos definidos, no caso de manutenção o conteúdo entregue.

§ 10. Realizados os ajustes pela área técnica, será solicitada nova assinatura da entrega à área demandante.

Art. 16. Quando necessário, poderá ser instaurado Processo específico no SEI destinado à formalização de acompanhamento, validação e registro das entregas realizadas.

Art. 17. O desenvolvimento considerará a metodologia de Ciclo de Vida de Desenvolvimento de Software (Software Development Life Cycle), com segregação de ambientes (desenvolvimento, homologação e produção), e a proteção de segredos em cofres corporativos, sendo vedada a inclusão de credenciais diretamente no código-fonte.

CAPÍTULO IV — DA SUSTENTAÇÃO

Art. 18. O processo de sustentação de software compreende o conjunto de atividades realizadas desde a entrada em produção até a descontinuação ou substituição do sistema, observando as seguintes categorias:

I - atendimento de incidentes: processo formal e tempestivo de detecção, registro, análise e resposta a eventos adversos que comprometam ou ameacem a confidencialidade, integridade, disponibilidade e autenticidade dos ativos de informação, ou que resultem na interrupção ou degradação da qualidade do serviço de Tecnologia da Informação (TI);

II - manutenção adaptativa: adequações sistêmicas necessárias para compatibilizar o software com mudanças no ambiente tecnológico, tais como atualizações de infraestrutura, sistemas operacionais, arquitetura corporativa ou novas políticas de segurança da informação;

III - manutenção corretiva: intervenções técnicas emergenciais ou planejadas destinadas a eliminar comportamentos do software que divergem das especificações originais ou que causem interrupções inesperadas e erros sistêmicos em ambiente de produção, visando restaurar a integridade funcional e a estabilidade da solução;

IV - manutenção evolutiva: atividades de ampliação, alteração ou aperfeiçoamento de funcionalidades, regras de negócio, fluxos operacionais ou integrações em sistemas existentes, destinadas a agregar valor institucional, elevar o nível de serviço ou atender a novas demandas de negócio identificadas após a implantação; e

V - suporte técnico: prestação de assistência especializada de terceiro nível voltada ao esclarecimento de dúvidas sobre a implementação de requisitos, orientação sobre procedimentos operacionais e gestão de dados, bem como o apoio à identificação e isolamento de falhas que, embora não caracterizem erro de codificação, impactem o uso efetivo da solução tecnológica.

CAPÍTULO V — DAS MUDANÇAS EM TECNOLOGIA DA INFORMAÇÃO

Art. 19. As demandas que impliquem em mudanças estruturantes e/ou que acarretem indisponibilidade nos serviços, sistemas, infraestrutura, ativos ou outras soluções de TI da SEEDF deverão observar integralmente as diretrizes do Plano de Gerenciamento de Mudanças em Tecnologia da Informação (Pgmud), com vistas a assegurar a rastreabilidade, segurança e continuidade dos serviços.

§ 1º O Comitê de Controle de Mudanças é a instância tático-decisória responsável por avaliar, priorizar e deliberar sobre a aprovação das mudanças previstas no caput deste artigo.

§ 2º Para fins de tratamento e aprovação, as mudanças serão classificadas nas seguintes categorias:

I - mudança normal: alteração planejada, de complexidade variável, que requer análise de impacto detalhada, avaliação de riscos e aprovação formal do Comitê de Controle de Mudanças para execução em janela de manutenção definida;

II - mudança padrão: alteração recorrente, de baixo risco e impacto conhecido, previamente documentada e autorizada pelo Comitê de Controle de Mudanças em catálogo próprio, podendo ser executada via Procedimento Operacional Padrão (POP) sem necessidade de nova avaliação individual;

III - mudança emergencial: alteração não planejada, necessária para restaurar serviços essenciais ou mitigar risco imediato e elevado, autorizada por fluxo emergencial simplificado e submetida à análise posterior do Comitê de Controle de Mudanças com relatório pós-implementação obrigatório.

§ 3º Nenhuma mudança de natureza normal ou emergencial poderá ser implementada sem a elaboração e validação de um Plano de Reversão (Rollback), que detalhe os procedimentos para restauração do estado anterior em caso de insucesso.

§ 4º Quando a mudança implicar em aquisição, contratação, renovação ou evolução de solução tecnológica contratada, deverão ser observados os procedimentos de planejamento da contratação previstos na Lei nº 14.133, de 2021, na Instrução Normativa SGD/ME nº 94, de 23 de dezembro de 2022, no que couber, e nos normativos internos da SEEDF.

CAPÍTULO VI — DA HOMOLOGAÇÃO

Art. 20. A fase de homologação constitui a etapa de experimentação detalhada e validação do incremento de software, visando assegurar que o produto atende aos requisitos pactuados antes de sua promoção ao ambiente de produção.

Art. 21. Os novos sistemas, as evoluções, melhorias e demais implementações em sistemas existentes somente poderão ser publicados em ambiente de produção após a conclusão das seguintes etapas:

I - conclusão dos testes previstos na Metodologia de Desenvolvimento de Sistemas;

II - homologação técnica;

III - homologação funcional pela área demandante.

§ 1º Os testes, como garantia intrínseca de qualidade, devem contemplar obrigatoriamente:

I - unitários: validam o comportamento das menores unidades de código, sob responsabilidade dos desenvolvedores;

II - funcionais e automatizados: asseguram a conformidade operacional conforme os critérios de aceitação;

III - de regressão: garantem que novos incrementos não afetem funcionalidades existentes;

IV - de performance: avaliam carga e estabilidade antes da liberação final.

§ 2º A homologação técnica compreende a validação, por parte da Subtic, do cumprimento dos padrões de arquitetura, segurança e qualidade estabelecidos na MDS e na Nosic, incluindo a verificação de código-fonte e infraestrutura.

§ 3º A homologação funcional consiste na verificação realizada pelo Product Owner e pela área de negócio da aderência da solução às regras de negócio, fluxos operacionais e necessidades institucionais descritas nas histórias de usuário.

Art. 22. Os critérios de aceite observarão as verificações de aceitabilidade do Anexo VI desta Portaria, composta pelos seguintes requisitos mínimos:

I - disponibilização do código-fonte em repositório GIT institucional;

II - execução de testes unitários e funcionais com os respectivos relatórios de resultados;

III - scripts de banco de dados atualizados;

IV - Dicionário de Dados atualizado, contendo descrição dos campos, domínio dos dados, regras de negócio, origem das informações e responsáveis pelos dados;

V - manual do usuário digital e documentação técnica atualizada;

VI - treinamento da área demandante pela equipe técnica;

VII - conformidade com os requisitos de segurança, incluindo testes de vulnerabilidade (SAST/DAST).

Art. 23. O registro documental da homologação será formalizado por meio dos seguintes artefatos, autuados no Processo SEI da demanda:

I - Lista de Requisitos Concluídos (LRC), assinada pelo Product Owner e pelo representante técnico;

II - Termo de Notificação de Publicação para Homologação (TNPH);

III - Relatório de Homologação do Plano de Trabalho (RHPT), para serviços sob regime de horas técnicas.

Art. 24. São responsabilidades no processo de homologação:

I - da área demandante: realizar os testes funcionais nos prazos estabelecidos e indicar formalmente a aceitação ou rejeição da entrega;

II - do Product Owner: deliberar sobre a aceitação dos incrementos de software, validar a Visão do Produto e assinar a LRC;

III - da equipe técnica: prestar suporte à homologação, corrigir defeitos identificados e garantir o versionamento de todos os entregáveis;

IV - da Subtic: exercer a homologação técnica, validar a conformidade com as normas de segurança e autorizar a implantação em produção.

Art. 25. Após a homologação da solução, a Subtic poderá determinar a realização de piloto operacional, quando a natureza, a criticidade, o impacto institucional ou a abrangência da solução justificarem a validação em ambiente de produção controlado.

§ 1º A pilotagem tem por finalidade validar o comportamento da solução em ambiente real de operação, permitindo a identificação de eventuais ajustes antes da disponibilização para toda a rede.

§ 2º O período de pilotagem será definido pela Subtic em conjunto com a área demandante, observado o grau de complexidade da solução.

§ 3º Durante a pilotagem poderão ser executadas correções, ajustes de configuração e pequenas evoluções indispensáveis ao pleno funcionamento da solução, desde que não alterem o escopo originalmente homologado.

§ 4º Encerrada a pilotagem, a área demandante emitirá manifestação quanto à estabilidade e aderência da solução aos requisitos aprovados, autorizando sua implantação definitiva ou indicando as adequações necessárias.

Art. 26. A implantação definitiva em ambiente de produção dependerá, cumulativamente:

I - da conclusão da homologação técnica e funcional;

II - da conclusão satisfatória da fase de pilotagem, quando aplicável;

III - da aprovação da mudança, na forma prevista no Pgmud;

IV - da autorização da Subtic.

CAPÍTULO VII — DA IMPLANTAÇÃO

Art. 27. Os softwares desenvolvidos no âmbito da SEEDF somente serão implantados em ambiente de produção após o cumprimento integral das seguintes etapas e requisitos:

I - homologação funcional e técnica;

II - execução e aprovação de testes;

III - atualização da documentação técnica e de usuário;

IV - treinamento da área demandante pela equipe técnica;

V - elaboração e validação de plano de reversão (rollback);

VI - autorização formal da Subtic.

Art. 28. A documentação necessária para a implantação da solução deverá assegurar a rastreabilidade, manutenção, sustentação e adequada utilização pelos usuários, compreendendo, no mínimo:

I - o Documento de Visão do Produto (DVP) e a Lista de Requisitos (LR), devidamente atualizados;

II - o Manual Técnico da Solução, elaborado pela equipe técnica responsável pelo desenvolvimento, contendo, no mínimo, a arquitetura da solução, diagrama dos componentes, padrões adotados, modelo de dados, integrações, APIs, configurações de infraestrutura, procedimentos de implantação, dependências, requisitos técnicos e demais informações necessárias à sustentação e evolução do sistema;

III - o Manual do Usuário, elaborado pela área demandante, sob a coordenação do Product Owner, em linguagem clara e acessível, contendo orientações para utilização da solução, fluxos operacionais, regras de negócio, perguntas frequentes, exemplos de utilização e, sempre que pertinente, capturas de tela e demais recursos que facilitem a capacitação dos usuários finais;

IV - os artefatos técnicos atualizados, incluindo, quando aplicáveis, o Modelo Entidade-Relacionamento (MER), o dicionário de dados, diagramas de arquitetura, documentação das APIs e demais documentos técnicos previstos na MDS;

V - o versionamento integral do código-fonte, scripts, artefatos de infraestrutura e demais componentes da solução em repositório institucional de controle de versões (GIT);

VI - documentação das APIs e serviços de integração utilizados pela solução, observando padrão institucional definido pela Subtic;

VII - especificação dos mecanismos de integração com o ambiente corporativo de dados (Data Warehouse), quando a solução produzir informações estratégicas ou destinadas a painéis gerenciais;

VIII - os ativos de dados produzidos deverão possuir metadados padronizados que permitam sua identificação, interpretação, reutilização e compartilhamento institucional;

IX - os indicadores disponibilizados pela solução deverão possuir definição metodológica, fórmula de cálculo, periodicidade de atualização e responsável institucional.

Art. 29. O plano de reversão (rollback), em conformidade com o Pgmud, constitui documento obrigatório para mudanças de média e alta criticidade e deve:

I - definir o ponto exato de restauração (backup ou versão anterior);

II - detalhar o procedimento passo a passo para a reversão imediata em caso de insucesso na implantação;

III - estabelecer critérios claros para acionamento, como falha técnica crítica ou indisponibilidade imprevista.

Art. 30. A autorização da Subtic constitui a etapa final do processo de desenvolvimento, que exige:

I - a assinatura da Ordem de Serviço e dos documentos de entrega da sprint pela área demandante;

II - o atesto técnico favorável emitido pela área técnica competente;

III - a confirmação, pela área de infraestrutura e segurança, de que a solução não compromete a estabilidade ou a integridade do ecossistema tecnológico da SEEDF.

Art. 31. Defeitos identificados serão classificados como Impeditivos (bloqueiam a operação) ou Não Impeditivos, orientando a priorização da correção e o aceite técnico.

TÍTULO III — DAS RESPONSABILIDADES

CAPÍTULO I — DA ÁREA DEMANDANTE E DO PRODUCT OWNER

Art. 32. Compete à área demandante, na qualidade de unidade responsável pela formalização da necessidade e validação do negócio:

I - formalizar a demanda via Processo no SEI, apresentando descrição clara da necessidade, justificativa e benefícios esperados;

II - designar formalmente o Product Owner, seu correspondente substituto, bem como demais representantes para participação nas reuniões de escopo e levantamento;

III - fornecer insumos sobre o domínio de negócio, regras operacionais e requisitos funcionais;

IV - analisar e aprovar os requisitos levantados pela equipe técnica;

V - autorizar o início do desenvolvimento por meio da assinatura da Ordem de Serviço;

VI - participar ativamente das homologações e assinar os documentos de entrega de cada Sprint nos prazos estabelecidos;

VII - validar as funcionalidades implementadas e apoiar a atualização de manuais de usuário.

Art. 33. Compete ao Product Owner, representante da área demandante no processo de desenvolvimento:

I - possuir pleno conhecimento das necessidades institucionais e objetivos estratégicos relacionados ao sistema;

II - organizar e priorizar o backlog do produto de acordo com o valor de negócio;

III - contribuir com a definição da Visão do Produto e planejar o Roadmap de entregas e Releases;

IV - estar disponível para esclarecer dúvidas da equipe de desenvolvimento e refinar histórias de usuário;

V - participar das reuniões de demonstração e decidir sobre a aceitação ou rejeição dos incrementos entregues;

VI - definir os critérios de aceite para cada item do backlog;

VII - realizar a validação formal com a assinatura de todos os entregáveis ao término de cada ciclo;

VIII - exercer as atribuições mediante designação formal realizada pela autoridade competente da unidade demandante.

§ 1º A indicação do Product Owner será de competência do superior hierárquico da unidade demandante, que deverá designar servidor com conhecimento técnico e funcional do processo de negócio, com disponibilidade para acompanhar as atividades de desenvolvimento, validação e homologação da solução.

§ 2º A unidade demandante deverá comunicar formalmente à Subtic a designação, substituição ou impedimento do Product Owner, garantindo a continuidade do acompanhamento do projeto e evitando a interrupção do ciclo de desenvolvimento.

CAPÍTULO II — DA SUBSECRETARIA DE OPERAÇÕES EM TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO

Art. 34. Compete à Subsecretaria de Operações em Tecnologia da Informação e Comunicação:

I - exercer a coordenação geral e supervisão técnica dos serviços de desenvolvimento e manutenção de sistemas;

II - nomear um líder de projeto e um líder técnico para acompanhar as etapas de desenvolvimento;

III - estabelecer diretrizes normativas, padrões de documentação e arquitetura tecnológica;

IV - definir a duração das sprints e o cronograma de reuniões rituais de cada projeto;

V - avaliar tecnicamente a viabilidade, segurança e interoperabilidade de soluções externas antes de sua recepção por aquisição ou doação;

VI - definição de padrões de dados, regras de negócio, indicadores, metadados e critérios de qualidade da informação, quando se tratarem de dados educacionais;

VII - gerir a infraestrutura necessária para a publicação dos sistemas em ambiente de produção;

VIII - dirimir casos omissos relativos à interpretação das normas de desenvolvimento.

CAPÍTULO III — DA EQUIPE TÉCNICA DE DESENVOLVIMENTO

Art. 35. Compete à equipe técnica responsável pelo desenvolvimento:

I - participar integralmente dos eventos do scrum, abrangendo o planejamento, as reuniões diárias, as revisões e as retrospectivas;

II - manter a documentação técnica e os modelos de dados continuamente atualizados;

III - garantir a entrega de incrementos de software que atendam integralmente aos critérios de aceitação técnica e de segurança da informação.

Parágrafo único. No âmbito da equipe técnica, a distribuição das atribuições específicas observará a seguinte divisão de competências:

I - ao scrum master: facilitar o processo ágil, mitigar impedimentos e zelar pela estrita observância à MDS;

II - ao analista de requisitos: produzir o Documento de Visão do Produto (DVP), modelar processos e documentar o backlog;

III - aos desenvolvedores: codificar as funcionalidades segundo os padrões de código limpo, seguro e acessível.

TÍTULO IV — DAS SOLUÇÕES TECNOLÓGICAS EXTERNAS E DA PROPRIEDADE INTELECTUAL

CAPÍTULO I — DAS SOLUÇÕES TECNOLÓGICAS EXTERNAS

Art. 36. Para os fins desta Portaria, consideram-se soluções tecnológicas externas aquelas desenvolvidas, fornecidas, adquiridas, contratadas ou disponibilizadas por terceiros, cuja utilização implique conexão, integração ou processamento de informações no ambiente tecnológico da SEEDF, compreendendo, entre outras:

I - sistemas de informação, aplicações web e aplicativos móveis;

II - soluções baseadas em IA, incluindo modelos generativos e assistentes virtuais;

III - plataformas de Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS) e soluções Low-Code/No-Code;

IV - ferramentas de Business Intelligence (BI), dashboards, plataformas analíticas e soluções de visualização de dados;

V - interfaces de programação de aplicações (APIs), serviços de integração e quaisquer mecanismos de interoperabilidade com sistemas externos;

VI - soluções de controle de acesso físico, incluindo catracas eletrônicas, controladores de acesso, leitores biométricos, leitores de cartões, reconhecimento facial e equipamentos congêneres conectados à infraestrutura tecnológica da SEEDF;

VII - sistemas de monitoramento eletrônico, videomonitoramento, câmeras IP, gravadores de vídeo em rede (NVR), servidores de gerenciamento de imagens e quaisquer serviços ou equipamentos de integração de câmeras conectados à rede corporativa da SEEDF;

VIII - dispositivos da Internet das Coisas (IoT), sensores, controladores, equipamentos inteligentes e quaisquer outros ativos tecnológicos conectados à rede de dados da Secretaria;

IX - qualquer outro equipamento, serviço ou solução tecnológica que demande acesso à infraestrutura de rede, aos sistemas corporativos, aos serviços digitais ou às bases de dados da SEEDF.

Art. 37. A recepção e autorização de uso de soluções externas, sejam elas oriundas de aquisição ou doação, ficam condicionadas à emissão de atesto técnico favorável da Subtic, que avaliará requisitos de infraestrutura, interoperabilidade, suporte e conformidade com a Nosic.

Art. 38. A solicitação de autorização de uso de soluções tecnológicas externas deverá ser encaminhada à Subtic por meio de preenchimento de Formulário de Autorização de Uso de Solução Tecnológica Externa, que avaliará tecnicamente segundo os seguintes critérios de aceitação:

I - segurança da informação e privacidade: conformidade com a Nosic/SEEDF e com a Lei Geral de Proteção de Dados Pessoais (LGPD);

II - viabilidade técnica e operacional: análise da compatibilidade com a infraestrutura de TIC e rede lógica da SEEDF;

III - interoperabilidade: capacidade de integração com o ecossistema tecnológico e bases de dados existentes;

IV - utilização prioritária de bases corporativas oficiais como fonte de dados para painéis gerenciais e soluções de Business Intelligence (BI), vedada a criação de bases paralelas sem justificativa técnica;

V - quando a solução envolver dados educacionais, deverá observar os padrões de dados institucionais estabelecidos pela SEEDF;

VI - acessibilidade: aderência aos padrões de acessibilidade digital estabelecidos nas legislações vigentes;

VII - continuidade e suporte: avaliação da capacidade de suporte técnico, manutenção e disponibilidade do serviço;

VIII - alinhamento estratégico: aderência ao PDTI e ao planejamento estratégico institucional;

IX - segurança cibernética: quando aplicável, submissão da solução tecnológica à instância central de Tecnologia da Informação e Comunicação do Governo do Distrito Federal para realização de testes de segurança, análise de vulnerabilidades, testes de intrusão (Penetration Test – Pentest) ou outros procedimentos de validação de segurança cibernética, como condição para sua implantação em ambiente de produção, observado o normativo vigente.

Parágrafo único. A Subtic poderá emitir catálogo de soluções tecnológicas externas previamente autorizadas, que dispensará a solicitação de autorização de uso das soluções nele previstas.

Art. 39. É expressamente vedada a utilização de soluções não homologadas que tratem ou armazenem dados institucionais, sob pena de responsabilização administrativa.

Art. 40. Soluções externas que envolvam o tratamento de dados pessoais sensíveis ou de crianças e adolescentes exigirão, adicionalmente, o parecer do Encarregado de Proteção de Dados (DPO) da SEEDF.

CAPÍTULO II — DA PROPRIEDADE INTELECTUAL

Art. 41. Pertencem exclusivamente à SEEDF os direitos relativos às soluções tecnológicas desenvolvidas e elaboradas por seus servidores, estagiários ou por empresas contratadas, durante a vigência de vínculo, ou ainda, que decorra da própria natureza dos encargos concernentes a esses vínculos.

Parágrafo único. As empresas contratadas ou os servidores designados para desenvolvimento serão expressamente responsabilizados quanto à manutenção de sigilo absoluto sobre quaisquer dados, informações, códigos-fonte e artefatos, contidos em quaisquer documentos e em quaisquer mídias, de que venham a desenvolver ou ter conhecimento durante a execução dos trabalhos, não podendo, sob qualquer pretexto, divulgar, reproduzir, comercializar ou utilizar, sob pena de lei, independentemente da classificação de sigilo conferida pela SEEDF, tais informações.

Art. 42. No caso de desenvolvimento realizado por empresas contratadas (Fábrica de Software), a transferência de tecnologia e a cessão definitiva de direitos patrimoniais ocorrerão de forma automática e integral, sendo obrigatória a entrega à Subtic da documentação completa, em especial:

I - código-fonte integral, devidamente comentado e versionado em repositório institucional (GIT);

II - memorial descritivo e especificações funcionais internas;

III - diagramas, modelos de dados (MER/MLD) e fluxogramas de processos;

IV - manuais de usuário e de configuração técnica atualizados.

Parágrafo único. O correto versionamento do código-fonte e o depósito da documentação técnica completa nos repositórios oficiais mantidos pela SEEDF constituem condição indispensável para a aceitação definitiva da entrega e o consequente faturamento da demanda.

Art. 43. A proteção da propriedade intelectual abrange as medidas de segurança cibernética destinadas a evitar o vazamento de segredos de negócio e ativos tecnológicos, observando-se:

I - a vedação expressa à inclusão de credenciais, chaves ou segredos diretamente no código-fonte ou repositórios (hardcoded credentials);

II - a utilização de cofres corporativos (vaults) para a gestão de chaves e segredos de aplicação;

III - o controle rigoroso de acesso aos ambientes de desenvolvimento e homologação, restrito a perfis formalmente autorizados;

IV - manutenção de trilhas de auditoria das alterações realizadas nos dados institucionais e nas operações críticas executadas pelos usuários.

Art. 44. Nos contratos com terceiros que envolvam o desenvolvimento de soluções críticas, deverão ser previstas cláusulas de reversibilidade e "Plano de Saída" (Exit Plan), assegurando que, ao término da relação contratual, ocorra a devolução integral ou eliminação certificada de dados e ativos informacionais, sob supervisão da Subtic.

TÍTULO V — CAPÍTULO ÚNICO

DAS DISPOSIÇÕES FINAIS

Art. 45. Fica expressamente vedada a implantação, disponibilização ou utilização de qualquer sistema, funcionalidade, melhoria ou evolução desenvolvida nos termos do Título II desta Portaria, em ambiente de produção, sem o cumprimento integral dos ritos de homologação e a autorização formal da autoridade competente da Subtic.

Art. 46. O atendimento das demandas de desenvolvimento e sustentação observará, de forma concomitante:

I - a capacidade operacional e técnica das equipes;

II - a disponibilidade orçamentária e contratual vigente;

III - o posicionamento na fila de desenvolvimento, respeitada a prioridade institucional;

IV - a complexidade técnica e a dimensão do escopo da solicitação.

Art. 47. Eventuais alterações de escopo ocorridas durante a execução do projeto poderão implicar a suspensão temporária, a reavaliação de prazos e o replanejamento das entregas, devendo tais decisões ser obrigatoriamente registradas no Processo SEI da demanda.

Art. 48. Os sistemas desenvolvidos deverão, sempre que possível, possibilitar a extração estruturada de informações destinadas ao Portal de Dados Abertos e demais iniciativas de transparência ativa da SEEDF, observadas as restrições legais.

Art. 49. Compete à Subtic a gestão e a atualização contínua da MDS, cujas revisões de mérito deverão ser submetidas ao CIG da SEEDF para homologação.

Art. 50. Os casos omissos ou as dúvidas interpretativas decorrentes desta Portaria serão dirimidos pela Subtic, que poderá, para tal fim:

I - expedir normas complementares, circulares e manuais de orientação;

II - solicitar à unidade competente a disponibilização de informações adicionais ou evidências técnicas por meio eletrônico.

Art. 51. Integram esta Portaria os Anexos I a IX, cujos formulários e modelos são de utilização compulsória pelas áreas demandantes e técnicas para o cumprimento da MDS.

§ 1º Os formulários e modelos referidos no caput e suas atualizações pela Subtic serão disponibilizados em meio eletrônico no site da SEEDF e/ou via documento padronizado do SEI.

§ 2º A inobservância dos modelos padronizados constantes dos Anexos implicará a devolução do expediente à unidade de origem para as devidas adequações.

Art. 52. O descumprimento das normas e diretrizes estabelecidas nesta Portaria poderá ensejar a apuração de responsabilidade, nos termos da legislação aplicável.

Art. 53. Esta Portaria entra em vigor na data de sua publicação.

THIAGO MELLO PEIXOTO DA SILVEIRA

ANEXO I — Formulário de Solicitação de Soluções de Software

1. IDENTIFICAÇÃO DA UNIDADE DEMANDANTE

Unidade Administrativa: _________________________________________________

Gestor Responsável: ____________________________ Matrícula: ____________

Processo SEI nº: _______________________________________________________

Indicação do Product Owner (PO): ________________________________________

(Servidor a ser formalmente designado para gestão do negócio e priorização do backlog).2. CLASSIFICAÇÃO DA DEMANDA

Assinale a categoria da solicitação, conforme definições da MDS e PGMUD:[ ] Novo Sistema: Criação de solução inédita.

[ ] Evolução Funcional: Ampliação ou alteração de funcionalidade existente.

[ ] Sustentação/Correção: Manutenção corretiva ou atendimento de incidentes.

[ ] Integração/BI/IA/Automação: Painéis gerenciais, APIs ou inteligência artificial.

[ ] Mudança em Ambiente de Produção: Alteração em infraestrutura, serviços ou ativos de TI já publicados (requer preenchimento da Seção 6 – PGMUD).

3. FUNDAMENTAÇÃO E ALINHAMENTO ESTRATÉGICO

Diagnóstico do Problema: (Síntese da lacuna operacional ou oportunidade a ser aproveitada).

Justificativa Institucional: (Base legal, metas SMART e interesse público).

Aderência ao PDTI 2025-2026: (Indicar o Eixo Estratégico ou Meta vinculada).

Aderência ao Planejamento Estratégico: (Indicar o Objetivo Estratégico da SEEDF).

4. DESCRIÇÃO DA SOLUÇÃO E REQUISITOS

Escopo Preliminar:

Descrição das principais funcionalidades e visão macro do produto.

Público-Alvo e Estimativa de Usuários:

(Comunidade escolar ou administrativa)

Sistemas Impactados/Integrações:

(Listar sistemas que serão afetados)

Segurança e Privacidade (NOSIC/LGPD):

[ ] Tratamento de dados sensíveis ou de crianças/adolescentes (requer parecer do DPO)

[ ] Necessidade de autenticação multifator (MFA)

[ ] Classificação da Informação: [ ] Pública [ ] Uso Interno [ ] Confidencial [ ] Sigilosa.

5. ANÁLISE DE IMPACTO FINANCEIRO E OPERACIONALEstimativa de Custo:

(Aquisição, licenciamento ou horas técnicas previstas)

Disponibilidade Orçamentária:

(Indicação de fonte de recurso ou PPA/LOA)

Ganhos de Eficiência:

(Redução de custos operacionais ou melhoria pedagógica)

6. SOLICITAÇÃO DE MUDANÇAS (APLICÁVEL PARA AMBIENTE DE PRODUÇÃO – PGMUD)

Tipo de Mudança: [ ] Normal [ ] Padrão [ ] Emergencial

Matriz de Criticidade: [ ] Baixa [ ] Média [ ] Alta [ ] CríticaPlano de Reversão (Rollback):

(Obrigatório para criticidade média, alta ou crítica)

Ponto de Restauração:

(Backup ou versão anterior)

Procedimento de Reversão:

(Passo a passo sucinto)

Critério de Acionamento:

(Falha técnica ou indisponibilidade imprevista)

ANEXO II — Matriz de Priorização das Demandas

1. FINALIDADE

A Matriz de Priorização tem como objetivo classificar as demandas de soluções de software (novos sistemas, evoluções ou mudanças em produção) de forma objetiva, garantindo transparência institucional e racionalização dos recursos de TIC.

2. CRITÉRIOS DE AVALIAÇÃO E PESOS PONDERADOS

Cada critério de priorização deverá ser pontuado de 0 a 5, conforme a seguinte escala:

Nota 0: não atende ao critério.

Nota 1: atende parcialmente, sem impacto significativo.

Nota 2: atende de forma básica, sem grande relevância.

Nota 3: atende de maneira moderada, com impacto relevante.

Nota 4: atende amplamente, trazendo benefícios claros.

Nota 5: atende totalmente, sendo essencial para a estratégia da SEEDF.

A pontuação final da demanda será o resultado da soma das notas atribuídas aos critérios, multiplicadas pelos respectivos pesos definidos no Plano Diretor de Tecnologia da Informação (PDTI) vigente, conforme a fórmula:

Pontuação Final = ∑ (Nota do Critério × Peso do Critério em decimal)

MATRIZ DE PRIORIZAÇÃO DAS DEMANDAS

Critério de Priorização

Descrição e Abrangência

Nota

Peso (%)

Pontuação Final

(Nota x Peso)

Alinhamento Estratégico

Aderência ao PDTI, Planejamento Estratégico e obrigações legais (leis, decretos, decisões judiciais).

[ ] Nota 0

[ ] Nota 1

[ ] Nota 2

[ ] Nota 3

[ ] Nota 4

[ ] Nota 5

25%

Impacto no Ensino e Gestão

Benefícios à comunidade escolar (calendário escolar, matrículas, registros) e número de usuários afetados.

[ ] Nota 0

[ ] Nota 1

[ ] Nota 2

[ ] Nota 3

[ ] Nota 4

[ ] Nota 5

20%

Viabilidade Técnica

Compatibilidade com infraestrutura, MDS, arquitetura de sistemas e facilidade de integração.

[ ] Nota 0

[ ] Nota 1

[ ] Nota 2

[ ] Nota 3

[ ] Nota 4

[ ] Nota 5

15%

Segurança e Conformidade

Tratamento de vulnerabilidades críticas, conformidade com a NOSIC e exigências da LGPD.

[ ] Nota 0

[ ] Nota 1

[ ] Nota 2

[ ] Nota 3

[ ] Nota 4

[ ] Nota 5

10%

Urgência e Criticidade

Projetos emergenciais (PGMUD) ou essenciais para a continuidade dos serviços administrativos e pedagógicos.

[ ] Nota 0

[ ] Nota 1

[ ] Nota 2

[ ] Nota 3

[ ] Nota 4

[ ] Nota 5

10%

Dependência Técnica

Soluções que são pré-requisito para outros projetos estratégicos ou reduzem o risco operacional.

[ ] Nota 0

[ ] Nota 1

[ ] Nota 2

[ ] Nota 3

[ ] Nota 4

[ ] Nota 5

10%

Inovação e Modernização

Introdução de tecnologias avançadas (IA, BI) e atualização de sistemas legados para sustentabilidade.

[ ] Nota 0

[ ] Nota 1

[ ] Nota 2

[ ] Nota 3

[ ] Nota 4

[ ] Nota 5

10%

3. INTERPRETAÇÃO DOS RESULTADOS E POSICIONAMENTO NO BACKLOG

Com base na pontuação final obtida, a Subtic posicionará a demanda no Backlog Institucional conforme os seguintes intervalos:

Pontuação > 4,0 (Prioridade Alta): projetos altamente estratégicos; inclusão imediata no topo da fila de planejamento e execução de sprints.

Pontuação entre 3,0 e 4,0 (Prioridade Média): projetos moderadamente prioritários; execução condicionada à disponibilidade orçamentária e operacional das equipes técnicas.

Pontuação < 3,0 (Prioridade Baixa): demandas que devem ser reavaliadas, adiadas ou mantidas em fila de espera prolongada.

4. MONITORAMENTO E REVISÃO

As decisões de priorização baseadas nesta matriz serão avaliadas periodicamente pelo Comitê Interno de Governança (CIG) para garantir ajustes estratégicos conforme novas demandas surjam.

ANEXO III — Critérios de Admissibilidade de Soluções de Software

1. FINALIDADE

A Análise de Admissibilidade visa filtrar, validar e autorizar demandas de desenvolvimento, evolução ou mudanças em sistemas, garantindo que os recursos de TIC sejam aplicados em soluções viáveis, seguras e alinhadas ao interesse público e ao planejamento estratégico da SEEDF.

2. CRITÉRIOS DE ADMISSIBILIDADE TÉCNICA E ESTRATÉGICA

Para que uma solicitação seja admitida, a Subtic avaliará os seguintes itens, conforme as diretrizes institucionais:

I. Alinhamento Estratégico e Normativo:

[ ] Aderência ao PDTI e Planejamento Estratégico: verificação se a demanda suporta os eixos estratégicos e as metas de modernização tecnológica da Secretaria.

[ ] Obrigação Legal: priorização de demandas decorrentes de leis, decisões judiciais ou determinações de órgãos de controle com prazos peremptórios.

[ ] Interesse Público e Eficiência: avaliação da geração de valor para a comunidade escolar e racionalização de recursos.

II. Economicidade e Sustentabilidade:

[ ] Existência de Solução Semelhante: análise do portfólio para evitar duplicidade funcional e fragmentação de sistemas.

[ ] Reuso e Parametrização: avaliação da possibilidade de aproveitar componentes existentes ou configurar módulos atuais (SaaS/Low-Code) em vez de iniciar desenvolvimento inédito.

[ ] Impacto Financeiro: verificação de disponibilidade orçamentária no PPA e LOA, além da análise de custo-benefício em todo o ciclo de vida da solução.

III. Viabilidade Técnica e de Infraestrutura:

[ ] Compatibilidade com a MDS: aderência aos padrões tecnológicos, linguagens de programação e frameworks homologados pela Subtic.

[ ] Capacidade de Infraestrutura: avaliação da disponibilidade de processamento, armazenamento, rede lógica e conectividade necessária.

[ ] Interoperabilidade: capacidade da solução de integrar-se nativamente via APIs ao ecossistema tecnológico da SEEDF.

IV. Segurança da Informação e Privacidade (Nosic/LGPD):

[ ] Security by Design: incorporação de requisitos de segurança desde a fase de iniciação, incluindo análise de vulnerabilidades.

[ ] Conformidade com a LGPD: análise do tratamento de dados pessoais, minimização de coleta e necessidade de Relatório de Impacto à Proteção de Dados (RIPD).

[ ] Gestão de Riscos: identificação de ameaças técnicas ou operacionais que possam comprometer a confidencialidade, integridade, disponibilidade e autenticidade (Cida).

V. Capacidade Operacional e de Suporte:

[ ] Disponibilidade da Equipe: análise da carga de trabalho do Time Ágil para assegurar que a nova demanda não prejudique projetos estratégicos em curso.

[ ] Capacidade de Sustentação: avaliação da viabilidade de suporte técnico de 3º nível e manutenção futura pela Subtic ou contratada.

3. RITOS DE ADMISSIBILIDADE PARA MUDANÇAS (PGMUD)

Para solicitações de mudança em sistemas produtivos (Mudanças Normais ou Emergenciais), a admissibilidade exige adicionalmente:

[ ] Plano de Implementação: detalhamento técnico das etapas de alteração.

[ ] Plano de Reversão (Rollback): procedimento testado para restauração do estado anterior em caso de falha.

[ ] Aprovação pelo Comitê de Controle de Mudanças: manifestação favorável para itens de média e alta criticidade.

4. RESULTADO DA ANÁLISE

A admissibilidade resultará em um parecer técnico da Subtic fundamentado em uma das seguintes decisões:

[ ] Favorável: demanda admitida e posicionada na fila de priorização do Backlog Institucional.

[ ] Favorável com Ressalvas: demanda admitida condicionada a ajustes de escopo, segurança ou arquitetura.

[ ] Desfavorável: demanda rejeitada por inviabilidade técnica, ausência de alinhamento estratégico, risco excessivo ou existência de solução duplicada.

ANEXO IV — Modelo do Documento de Visão do Produto

O Documento de Visão do Produto (DVP) é instrumento de alinhamento estratégico e técnico entre a unidade requisitante e a área de TIC da SEEDF, consolidando os fundamentos, premissas e objetivos do projeto proposto. Este artefato integra os elementos de planejamento institucional de TIC, em conformidade com a IN SGD/ME nº 94/2022, o Plano Diretor de Tecnologia da Informação 2025–2026 e a Estratégia de Transformação Digital da SEEDF.

HISTÓRICO DE REVISÕES

Descrição da Revisão	Versão	Data	Autor da Alteração
Versão inicial do documento	1.0	[DD/MM/AAAA]	[Nome completo]

Responsável pela Aprovação Técnica: [Nome, unidade de lotação, cargo funcional]

1. INFORMAÇÕES GERAIS DO PROJETO

- Nome do Projeto: [Título técnico da iniciativa de TI]

- Unidade Técnica Responsável: [Ex.: SUBTIC/DIMOD/GEPGD – SEEDF]

- Unidade Requisitante (Cliente Interno): [Órgão/Setor demandante dentro da estrutura da SEEDF]

2. ENVOLVIDOS – PARTES INTERESSADAS

NOME COMPLETO	CARGO E ÓRGÃO DE LOTAÇÃO	E-MAIL INSTITUCIONAL
[Nome]	[Cargo] – [Unidade / Secretaria]	[nome@edu.se.df.gov.br]

3. ORIGEM DA DEMANDA OU PROBLEMA

Descrição objetiva do cenário atual que originou a solicitação, contemplando lacunas operacionais, necessidades institucionais não atendidas ou gargalos técnicos identificados no processo de trabalho.

4. SOLUÇÃO PROPOSTA

Resumo técnico da abordagem a ser implementada: funcionalidades previstas, escopo da solução, integração com sistemas legados, uso de metodologias, plataformas ou linguagens específicas, e alinhamento à estratégia digital da SEEDF.

5. BENEFÍCIOS ESPERADOS

Elenco dos ganhos institucionais esperados, tais como: automação de processos, melhoria da experiência do usuário, incremento na rastreabilidade das ações, redução de retrabalho, maior controle gerencial, aderência à LGPD, entre outros.

6. MACROVISÃO DA SOLUÇÃO

Apresentação em nível conceitual das camadas de negócio envolvidas, possíveis fluxos operacionais, interfaces com usuários internos e externos e artefatos de alto nível que ilustram o comportamento sistêmico esperado.

7. SISTEMAS IMPACTADOS

SISTEMA / PLATAFORMA	TIPO DE IMPACTO IDENTIFICADO
[Nome do sistema]	[Alteração de integração, uso de base de dados comum, dependência lógica etc.]

8. PRINCIPAIS ENTREGAS (DELIVERABLES)

Lista estruturada dos produtos esperados no âmbito do projeto, contendo, por exemplo: protótipos navegáveis, APIs, painéis de indicadores, repositórios versionados, relatórios de homologação, manuais de uso, evidências de capacitação, entre outros.

9. RISCOS POTENCIAIS

Relacionar os riscos técnicos, operacionais ou institucionais que podem comprometer os resultados do projeto. Exemplo: dependência de integrações externas, escassez de recursos humanos, mudança de legislação, resistência de usuários, etc.

10. PREMISSAS OPERACIONAIS

Apresentação de hipóteses consideradas válidas para o desenvolvimento da solução. Exemplo: disponibilidade de equipe técnica, estabilidade da infraestrutura de TIC, acesso a sistemas externos, alinhamento com cronogramas de outras iniciativas em curso.

11. RESTRIÇÕES IDENTIFICADAS

Descrição de limitações técnicas, legais, orçamentárias ou organizacionais que influenciam o planejamento ou a execução do projeto. Exemplo: restrições contratuais, vedação de uso de determinados frameworks, limitações na interoperabilidade com sistemas legados.

ANEXO V — Modelo de Ordem de Serviço para Desenvolvimento de Software

Abertura do projeto e autorização para início do desenvolvimento com Scrum

FINALIDADEEsta OS inicia o projeto, define a visão do produto, os responsáveis, o backlog e as tasks iniciais. Ela não registra entrega realizada, medição, glosa, recebimento ou autorização de pagamento. Em projeto executado por fábrica de software, os dados contratuais abaixo servem apenas para vinculação e controle.

1

IDENTIFICAÇÃO DA ABERTURA

OS Nº[NNN/AAAA]	EMISSÃO[dd/mm/aaaa]	PROCESSO SEI[Número]	PRIORIDADE / CRITICIDADE[Nível e justificativa]
SISTEMA / PRODUTO[Nome]	PROJETO / ÉPICO[Nome/ID]	ÁREA DEMANDANTE[Unidade]	SOLICITANTE[Nome, cargo e matrícula]
EXECUÇÃO( ) Interna ( ) Fábrica de software	TIPO( ) Novo produto ( ) Evolução ( ) Correção	DOCUMENTO DE DEMANDA[DOD/DFD/chamado]	PDTIC / PROJETO[Referência]
CONTRATO / LOTE / ITEM[Referência ou N/A]	CONTRATADA / CNPJ[Dados ou N/A]	PREPOSTO[Nome e contato ou N/A]	CLASSIFICAÇÃO DA INFORMAÇÃO[Pública/Restrita/Sigilosa]

2

PAPÉIS E EQUIPE DO PROJETO

AGENTE	PAPEL	NOME / UNIDADE E CONTATO	RESPONSABILIDADE NA ABERTURA
Product Owner (PO)	Responsável de Negócio	[Servidor, unidade, contato e matrícula]	Definir o Product Goal, priorizar o backlog, esclarecer requisitos e validar critérios de aceitação.
Autoridade de TIC	Governança	[Nome e unidade]	Autorizar a abertura e assegurar aderência ao fluxo, à arquitetura e aos padrões institucionais.
Scrum Master	Facilitador	[Nome e contato]	Facilitar os eventos, dar transparência ao trabalho e apoiar a remoção de impedimentos.
Líder técnico	Arquitetura	[Nome e contato]	Orientar solução, arquitetura, integrações, segurança, qualidade e padrões técnicos.
Equipe de desenvolvimento	Execução	[Equipe, integrantes e canal]	Refinar, estimar e executar histórias e tasks; testar, documentar e demonstrar incrementos.
Áreas técnicas	Suporte	[Nomes, unidades e contatos]	Apoiar requisitos, testes, dados, integrações e validação das necessidades.
Gestor / Preposto	Representação operacional da contratada	[Nomes e contatos ou N/A]	Coordenar o acionamento contratual e a disponibilização da equipe, sem substituir papéis públicos.

3

VISÃO DO PRODUTO E ESCOPO INICIAL

PROBLEMA OU OPORTUNIDADE[Descreva a necessidade que motivou a abertura do projeto.]

PRODUCT GOAL / RESULTADO ESPERADO[Declare o objetivo de longo prazo do produto em linguagem clara e verificável.]

USUÁRIOS/ BENEFICIÁRIOS[Público-alvo]

VALOR ESPERADO[Benefício institucional]

INDICADOR DE SUCESSO[Indicador e fórmula]

META / PRAZO[Valor e data]

ESCOPO INICIAL[Funcionalidades, processos e resultados inicialmente incluídos.]

FORA DO ESCOPO[Exclusões conhecidas e limites desta abertura.]

4

CONFIGURAÇÃO SCRUM E CONDIÇÕES DE INÍCIO

PRODUCT BACKLOG[Link e versão inicial]	FERRAMENTA DE GESTÃO[Nome/projeto]	REPOSITÓRIO DE CÓDIGO[URL/projeto]	DOCUMENTAÇÃO / EVIDÊNCIAS[Local oficial]
INÍCIO PREVISTO[dd/mm/aaaa]	PRIMEIRA SPRINT[Número e período]	DURAÇÃO DA SPRINT[Semanas]	DISPONIBILIDADE DA EQUIPE[Capacidade inicial]
SPRINT PLANNING[Data/canal]	DAILY SCRUM[Horário/canal]	SPRINT REVIEW[Data/canal]	RETROSPECTIVE[Data/canal]
DEFINITION OF READY — DOR[Link/versão]	DEFINITION OF DONE — DOD[Link/versão]	PADRÕES TÉCNICOS[Guia/versão]	CANAL DE COMUNICAÇÃO[Canal oficial]
PLATAFORMA / STACK[Tecnologias]	AMBIENTES[Dev/Teste/Homologação]	INTEGRAÇÕES[Sistemas/APIs]	DADOS DE TESTE / ACESSOS[Disponibilidade]

ITEM DE VERIFICAÇÃO	CONFIRMADO	EVIDÊNCIA / OBSERVAÇÃO
Product Goal, escopo inicial e critérios de sucesso definidos	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Product Owner, Scrum Master e equipe identificados e disponíveis	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Backlog inicial priorizado, compreensível e estimável	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Critérios de aceitação, DoR e DoD definidos ou referenciados	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Ambientes, acessos, dados e integrações mínimas disponíveis	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Requisitos iniciais de segurança, privacidade, acessibilidade e arquitetura avaliados	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]

5

BACKLOG INICIAL

ID	ITEM DO PRODUCT BACKLOG	CRITÉRIO DE ACEITAÇÃO	PRIORIDADE	ESTIMATIVA	DEPENDÊNCIA
[PB-01]	[História, requisito ou resultado]	[Critério objetivo e testável]	[Prioridade]	[Estimativa inicial]	[Dependência]
[PB-01]	[História, requisito ou resultado]	[Critério objetivo e testável]	[Prioridade]	[Estimativa inicial]	[Dependência]
[PB-01]	[História, requisito ou resultado]	[Critério objetivo e testável]	[Prioridade]	[Estimativa inicial]	[Dependência]
[PB-01]	[História, requisito ou resultado]	[Critério objetivo e testável]	[Prioridade]	[Estimativa inicial]	[Dependência]
[PB-01]	[História, requisito ou resultado]	[Critério objetivo e testável]	[Prioridade]	[Estimativa inicial]	[Dependência]
[PB-01]	[História, requisito ou resultado]	[Critério objetivo e testável]	[Prioridade]	[Estimativa inicial]	[Dependência]

REFINAMENTOO backlog inicial poderá ser detalhado e repriorizado pelo Product Owner durante o projeto, preservados o Product Goal, o escopo autorizado e os limites contratuais aplicáveis.

6

TASKS INICIAIS

TASK	ITEM	DESCRIÇÃO / ENTREGA ESPERADA	RESPONSÁVEL	ESTIMATIVA	DEPENDÊNCIA	STATUS
[TK-01]	[PB-01]	[Task e entrega/resultado esperado]	[Responsável]	[h/pontos]	[Dependência]	[A fazer]
[TK-01]	[PB-01]	[Task e entrega/resultado esperado]	[Responsável]	[h/pontos]	[Dependência]	[A fazer]
[TK-01]	[PB-01]	[Task e entrega/resultado esperado]	[Responsável]	[h/pontos]	[Dependência]	[A fazer]
[TK-01]	[PB-01]	[Task e entrega/resultado esperado]	[Responsável]	[h/pontos]	[Dependência]	[A fazer]
[TK-01]	[PB-01]	[Task e entrega/resultado esperado]	[Responsável]	[h/pontos]	[Dependência]	[A fazer]
[TK-01]	[PB-01]	[Task e entrega/resultado esperado]	[Responsável]	[h/pontos]	[Dependência]	[A fazer]
[TK-01]	[PB-01]	[Task e entrega/resultado esperado]	[Responsável]	[h/pontos]	[Dependência]	[A fazer]
[TK-01]	[PB-01]	[Task e entrega/resultado esperado]	[Responsável]	[h/pontos]	[Dependência]	[A fazer]

GESTÃO DAS TASKSAs tasks detalham o trabalho técnico necessário aos itens do backlog e devem ser mantidas na ferramenta oficial. Atualizações operacionais de responsável, estimativa ou status não exigem nova OS; alterações do objetivo, escopo ou limite contratual exigem avaliação formal.

7

PLANO DE INÍCIO, RISCOS E AUTORIZAÇÃO

MARCO	PRAZO / DATA	RESPONSÁVEL	REGISTRO
Kick-off / abertura	[Data]	[Responsável]	[Ata/SEI]
Refinamento inicial	[Data/período]	[PO/equipe]	[Backlog]
Sprint Planning	[Data]	[Scrum Team]	[Sprint Backlog]
Início da primeira Sprint	[Data]	[Equipe]	[Ferramenta]
Primeira Sprint Review	[Data]	[PO/equipe]	[Registro]

EVENTO	IMPACTO / AVALIAÇÃO	RESPOSTA	RESPONSÁVEL	PRAZO / STATUS
[Risco, dependência ou impedimento]	[Impacto / nível]	[Resposta]	[Responsável]	[Prazo/status]
[Risco, dependência ou impedimento]	[Impacto / nível]	[Resposta]	[Responsável]	[Prazo/status]
[Risco, dependência ou impedimento]	[Impacto / nível]	[Resposta]	[Responsável]	[Prazo/status]

EFEITO DA AUTORIZAÇÃO

A assinatura autoriza a abertura do projeto e o início das atividades registradas no backlog e nas tasks, formalizando o compromisso da área demandante de fornecer os insumos necessários, esclarecer requisitos, participar das validações e decidir tempestivamente sobre a continuidade da demanda.

Caso solicite a suspensão, o cancelamento ou a alteração substancial da demanda após a mobilização da equipe, a área demandante deverá formalizar e justificar a decisão no processo e participar da avaliação dos impactos sobre o escopo, o cronograma, a capacidade alocada, os artefatos produzidos e os serviços já executados. Quando houver contrato de fábrica de software, o tratamento dos trabalhos realizados e de seus efeitos contratuais observará as evidências, os critérios de medição, o instrumento contratual e a atuação da gestão e fiscalização do contrato.

Esta autorização não constitui homologação, recebimento, ateste, medição ou autorização de pagamento.

SIGNATÁRIO	FINALIDADE	IDENTIFICAÇÃO E ASSINATURA
Solicitante / área demandante	Confirma a necessidade e as informações da demanda.	Nome / matrícula ou CPF: [Preencher]Data: [dd/mm/aaaa] • Assinatura eletrônica: [SEI]
Product Owner / Responsável de Negócio	Valida Product Goal, escopo e backlog inicial.	Nome / matrícula ou CPF: [Preencher]Data: [dd/mm/aaaa] • Assinatura eletrônica: [SEI]
Autoridade / responsável da TIC	Autoriza a abertura e o início do projeto.	Nome / matrícula ou CPF: [Preencher]Data: [dd/mm/aaaa] • Assinatura eletrônica: [SEI]

ANEXO VI — Termo de Homologação e Aceite Funcional

Sprint, release, incremento ou entrega de desenvolvimento de software

EFEITO DESTE TERMO

Registra a decisão funcional do Product Owner/área demandante sobre o resultado demonstrado e testado. Em contratação, não substitui o Termo de Recebimento Provisório, o Termo de Recebimento Definitivo, a medição, a avaliação de níveis de serviço ou a autorização de faturamento; tampouco afasta garantia, responsabilidade por vícios ou dever de correção.

1

IDENTIFICAÇÃO

TERMO Nº[NNN/AAAA]	OS Nº[NNN/AAAA]	PROCESSO SEI[Número]	DATA DA HOMOLOGAÇÃO[dd/mm/aaaa]
SISTEMA / PRODUTO[Nome]	MÓDULO[Nome]	RELEASE / VERSÃO[Versão/build/tag]	SPRINT(S)[Número(s)]
PERÍODO EXECUTADO[Início a fim]	ENTREGA PARA HOMOLOGAÇÃO[Data/hora]	AMBIENTE[Homologação/Outro]	REPOSITÓRIO / EVIDÊNCIAS[Link]
CONTRATO Nº[Número ou N/A]	CONTRATADA[Razão social ou N/A]	PREPOSTO[Nome ou N/A]	MÉTRICA / COMPETÊNCIA[Unidade e período]

2

PARTICIPANTES E RESPONSÁVEIS

PAPEL	NOME / UNIDADE	PARTICIPAÇÃO / RESPONSABILIDADE	REGISTRO
Product Owner/Responsável de Negócio	[Servidor/unidade]	Decisão sobre atendimento funcional e prioridade de pendências.	[Contato/matrícula]
Área técnica de testes	[Nome ou N/A]	Planejar e executar os testes; verificar o atendimento aos critérios de aceitação; registrar evidências, resultados e não conformidades; e recomendar a aprovação ou a correção da entrega.	[Matrícula]
Área técnica de requisitos/negócios	[Nome ou N/A]	Elicitar, analisar e documentar requisitos; assegurar sua rastreabilidade com os critérios de aceitação e as entregas; e prestar subsídios técnicos à homologação e ao recebimento contratual.	[Matrícula]

3

RESUMO DA ENTREGA

META DA SPRINT / RESULTADO ESPERADO[Transcrever a meta da OS e o resultado de negócio esperado.]

RESULTADO APRESENTADO[Descrever sucintamente o incremento, release e valor gerado.]

ITENS PLANEJADOS[Qtd.]	ITENS ENTREGUES[Qtd.]	ITENS ACEITOS[Qtd.]	ITENS PENDENTES / REJEITADOS[Qtd.]
MÉTRICA ESTIMADA[Qtd./unidade]	MÉTRICA MEDIDA[Qtd./unidade]	INDICADORES APURADOS[Documento/link]	VERSÃO IMPLANTÁVEL( ) Sim ( ) Não

4

AVALIAÇÃO DOS ITENS DO BACKLOG

ID	RESULTADO / CRITÉRIO DE ACEITAÇÃO	ENTREGUE / EVIDÊNCIA	SITUAÇÃO	OBSERVAÇÕES
[ID]	[Resultado/critério previsto]	[Entrega e evidência]	( ) Integral( ) Parcial( ) Rejeitado	[Observação/pendência]
[ID]	[Resultado/critério previsto]	[Entrega e evidência]	( ) Integral( ) Parcial( ) Rejeitado	[Observação/pendência]
[ID]	[Resultado/critério previsto]	[Entrega e evidência]	( ) Integral( ) Parcial( ) Rejeitado	[Observação/pendência]
[ID]	[Resultado/critério previsto]	[Entrega e evidência]	( ) Integral( ) Parcial( ) Rejeitado	[Observação/pendência]
[ID]	[Resultado/critério previsto]	[Entrega e evidência]	( ) Integral( ) Parcial( ) Rejeitado	[Observação/pendência]
[ID]	[Resultado/critério previsto]	[Entrega e evidência]	( ) Integral( ) Parcial( ) Rejeitado	[Observação/pendência]
[ID]	[Resultado/critério previsto]	[Entrega e evidência]	( ) Integral( ) Parcial( ) Rejeitado	[Observação/pendência]
[ID]	[Resultado/critério previsto]	[Entrega e evidência]	( ) Integral( ) Parcial( ) Rejeitado	[Observação/pendência]

5

VERIFICAÇÕES FUNCIONAIS E DE QUALIDADE

ITEM DE VERIFICAÇÃO	SITUAÇÃO	EVIDÊNCIA / OBSERVAÇÃO
Meta da sprint/release atingida e escopo demonstrado	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Critérios de aceitação funcionais atendidos	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Regras de negócio e permissões de acesso validadas	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Fluxos principais, alternativos e mensagens de erro testados	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Testes automatizados, regressão e integração executados	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Código-fonte, scripts e versão entregues no repositório institucional	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Qualidade de código e vulnerabilidades dentro dos limites definidos	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Desempenho, capacidade e disponibilidade verificados quando exigidos	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Privacidade, proteção de dados e trilhas de auditoria verificadas	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Acessibilidade e experiência do usuário verificadas quando aplicáveis	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Documentação de usuário, técnica, API e release atualizada	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Procedimentos de implantação, rollback e monitoramento testados	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Transferência de conhecimento realizada quando prevista	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]
Definition of Done e níveis mínimos de serviço atendidos	( ) Sim ( ) Não ( ) N/A	[Link, documento, relatório ou justificativa]

6

NÃO CONFORMIDADES, RESSALVAS E PENDÊNCIAS

ID	SEVERIDADE	DESCRIÇÃO/ EVIDÊNCIA	RESPONSÁVEL	PRAZO	TRATAMENTO	STATUS
[NC-01]	( ) Impeditiva( ) Significativa( ) Menor	[Descrição objetiva e evidência]	[Responsável]	[Prazo]	[Correção/reteste/backlog]	[Status]
[NC-01]	( ) Impeditiva( ) Significativa( ) Menor	[Descrição objetiva e evidência]	[Responsável]	[Prazo]	[Correção/reteste/backlog]	[Status]
[NC-01]	( ) Impeditiva( ) Significativa( ) Menor	[Descrição objetiva e evidência]	[Responsável]	[Prazo]	[Correção/reteste/backlog]	[Status]
[NC-01]	( ) Impeditiva( ) Significativa( ) Menor	[Descrição objetiva e evidência]	[Responsável]	[Prazo]	[Correção/reteste/backlog]	[Status]
[NC-01]	( ) Impeditiva( ) Significativa( ) Menor	[Descrição objetiva e evidência]	[Responsável]	[Prazo]	[Correção/reteste/backlog]	[Status]
[NC-01]	( ) Impeditiva( ) Significativa( ) Menor	[Descrição objetiva e evidência]	[Responsável]	[Prazo]	[Correção/reteste/backlog]	[Status]

CLASSIFICAÇÃO SUGERIDAImpeditiva: inviabiliza uso, segurança, legalidade ou objetivo principal.

Significativa: afeta critério relevante, mas admite aceite parcial expressamente motivado.

Menor: não impede o resultado e pode ser tratada no prazo acordado, sem prejuízo das obrigações e critérios contratuais.

7

RESULTADO DA HOMOLOGAÇÃO

( )	HOMOLOGADO E ACEITO INTEGRALMENTE — todos os critérios funcionais aplicáveis foram atendidos.
( )	HOMOLOGADO COM RESSALVAS / ACEITE PARCIAL — somente para pendências não impeditivas, discriminadas neste termo e com prazo de tratamento.
( )	NÃO HOMOLOGADO / REJEITADO — o resultado não atende aos critérios indicados; deverá ser corrigido e submetido a nova homologação.
( )	HOMOLOGAÇÃO SUSPENSA — faltam ambiente, dados, evidências ou condições de teste; não há decisão de aceite até o saneamento.

FUNDAMENTAÇÃO DA DECISÃO[Indique testes, evidências, critérios atendidos/não atendidos e razão do aceite integral, parcial, rejeição ou suspensão.]

CONDIÇÕES E LIMITES DO ACEITE PARCIAL[Enumere itens aceitos, itens excluídos, prazo, responsável, novo teste e efeito operacional. Preencher N/A se não houver aceite parcial.]

PRAZO FINAL PARA CORREÇÕES[dd/mm/aaaa ou N/A]

DATA DO RETESTE[dd/mm/aaaa ou N/A]

VERSÃO PARA RETESTE[Build/tag ou N/A]

RISCO RESIDUAL ACEITO POR[Autoridade ou N/A]

8

ENCAMINHAMENTOS

AÇÃO	RESPONSÁVEL	PRAZO / DATA	REGISTRO / EVIDÊNCIA	SITUAÇÃO
Correção de pendências	[Responsável]	[Prazo]	[OS/backlog/registro]	[Status]
Novo ciclo de testes	[Responsável]	[Data]	[Plano/evidência]	[Status]
Implantação/ publicação	[Responsável]	[Janela]	[Mudança/release]	[Status]
Monitoramento pós-implantação	[Responsável]	[Período]	[Painel/alertas]	[Status]
Recebimento provisório — se contratado	[Fiscal]	[Prazo]	[TRP/SEI]	[Status]
Recebimento definitivo — se contratado	[Gestor/comissão]	[Prazo]	[TRD/SEI]	[Status]

9

DECLARAÇÃO

DECLARAÇÃO DA ÁREA DEMANDANTE

Declaro que o incremento identificado neste termo foi avaliado segundo os critérios de aceitação da OS e as evidências registradas. A decisão funcional indicada limita-se aos itens expressamente avaliados, não abrange vícios ocultos, não exonera deveres de garantia/correção e, em execução contratual, não substitui os atos de fiscalização, medição, recebimento provisório, recebimento definitivo ou autorização de faturamento.

10

ASSINATURAS

SIGNATÁRIO	FINALIDADE	IDENTIFICAÇÃO E ASSINATURA
Product Owner / Responsável de Negócio	Decide e fundamenta a homologação e o aceite funcional.	Nome / matrícula ou CPF: [Preencher]Data: [dd/mm/aaaa] • Assinatura eletrônica: [SEI]
Responsável da área demandante	Ratifica, quando exigido pelo fluxo, a aderência à necessidade.	Nome / matrícula ou CPF: [Preencher]Data: [dd/mm/aaaa] • Assinatura eletrônica: [SEI]
Fiscal requisitante — se aplicável	Registra avaliação da necessidade, qualidade e critérios de aceitação.	Nome / matrícula ou CPF: [Preencher]Data: [dd/mm/aaaa] • Assinatura eletrônica: [SEI]
Fiscal técnico — ciência	Toma ciência para subsidiar avaliação técnica e recebimento provisório.	Nome / matrícula ou CPF: [Preencher]Data: [dd/mm/aaaa] • Assinatura eletrônica: [SEI]
Gestor do contrato — ciência	Recebe o termo para coordenação dos atos contratuais subsequentes.	Nome / matrícula ou CPF: [Preencher]Data: [dd/mm/aaaa] • Assinatura eletrônica: [SEI]
Scrum Master / líder técnico — ciência	Registra demonstração, evidências e encaminhamentos técnicos.	Nome / matrícula ou CPF: [Preencher]Data: [dd/mm/aaaa] • Assinatura eletrônica: [SEI]
Preposto da contratada — ciência	Recebe o resultado e as pendências, sem quitação ou alteração contratual.	Nome / matrícula ou CPF: [Preencher]Data: [dd/mm/aaaa] • Assinatura eletrônica: [SEI]

APLICAÇÃONa execução interna, marque como “N/A” os blocos do fiscal, gestor e preposto que não existirem. As assinaturas devem seguir o fluxo e a competência definidos na portaria e, quando houver contrato, no ato de designação da gestão e fiscalização.

ANEXO VII — Checklist para Implantação em Produção

1. IDENTIFICAÇÃO DA DEMANDA

Projeto/Sistema: __________________________ Versão/Release: ___________

Processo SEI nº: __________________________ Ordem de Serviço nº: ________

Tipo de Mudança (PGMUD): [ ] Normal [ ] Padrão [ ] Emergencial.

2. GOVERNANÇA E FORMALIZAÇÃO (PDTI / MINUTA DE PORTARIA)

[ ] Aderência ao PDTI e Planejamento Estratégico validada.

[ ] Ordem de Serviço (OS) devidamente assinada pela área demandante.

[ ] Termo de Notificação de Publicação para Homologação (TNPH) autuado.

[ ] Lista de Requisitos Concluídos (LRC) assinada pelo Product Owner (PO).

3. REQUISITOS TÉCNICOS E DOCUMENTAIS (MDS)

[ ] Documento de Visão do Produto (DVP) e Backlog atualizados.

[ ] Modelo Entidade-Relacionamento (MER) e Dicionário de Dados atualizados.

[ ] Manual do Usuário Digital com capturas de tela e linguagem acessível.

[ ] Scripts de Banco de Dados validados para produção.

[ ] Script de Atendimento e Suporte (SAS) atualizado para o Service Desk.

[ ] Código-fonte integral versionado em repositório GIT institucional.

4. SEGURANÇA DA INFORMAÇÃO E PRIVACIDADE (NOSIC)

[ ] Segregação de ambientes (Desenvolvimento, Homologação e Produção) verificada.

[ ] Execução de testes de segurança estáticos (SAST) e dinâmicos (DAST) sem achados críticos.

[ ] Verificação de inexistência de credenciais expostas no código (Hardcoded Secrets).

[ ] Segredos, chaves e tokens armazenados em cofre corporativo (Vault).

[ ] Implementação de Autenticação Multifator (MFA) para perfis administrativos e sensíveis.

[ ] Análise de conformidade com a LGPD e minimização de dados pessoais.

5. GESTÃO DE MUDANÇAS E RESILIÊNCIA (PGMUD)

[ ] Janela de manutenção definida visando minimizar impacto no calendário escolar.

[ ] Plano de Reversão (Rollback) detalhado e testado, contendo:

[ ] Procedimento passo a passo para reversão imediata.

[ ] Critérios claros de acionamento (falha técnica ou indisponibilidade).

[ ] Ponto exato de restauração (backup/snapshot/versão anterior).

[ ] Plano de backup e recuperação de dados operacionais validado.

[ ] Mudança devidamente registrada no sistema de ITSM da SEEDF.

6. QUALIDADE E VALIDAÇÃO FINAL

[ ] Testes Unitários e Funcionais executados com 100% de sucesso.

[ ] Testes de Regressão e Performance realizados para o release.

[ ] Inexistência de defeitos de natureza "Impeditiva".

[ ] Base de Dados de Gerenciamento de Configuração (CMDB) pronta para atualização.

ANEXO VIII — Matriz RACI de Papéis e Responsabilidades

1. LEGENDA DA MATRIZ

R (Responsible/Responsável): quem efetivamente executa a tarefa ou constrói o artefato.

A (Accountable/Aprovador): quem possui a autoridade final, assina a entrega e responde pelo resultado (apenas um por tarefa).

C (Consulted/Consultado): quem fornece insumos técnicos ou de negócio necessários para a execução.

I (Informed/Informado): quem deve ser comunicado sobre a decisão ou conclusão da tarefa.

2. DESCRIÇÃO SINTÉTICA DOS PAPÉIS

I. Comitê Interno de Governança (CIG/SEEDF): Instância máxima de deliberação estratégica; aprova o PDTI e prioridades de alto impacto.

II. Comitê de Controle de Mudanças (CCB): Instância tático-decisória; autoriza mudanças em ambiente produtivo avaliando riscos e janelas de manutenção.

III. SUBTIC (Área Técnica): Coordena os serviços de TIC, define padrões arquiteturais e exerce a homologação técnica definitiva.

IV. Gestor de Segurança (GSI) e Encarregado (DPO): Garantem o Security by Design e o cumprimento da LGPD; validam requisitos de privacidade e resposta a incidentes.

V. Product Owner (PO): Representante da área de negócio; detém a autoridade sobre o valor do produto e a priorização do Backlog.

VI. Time Ágil (Desenvolvimento): Equipe técnica (servidores ou contratados) responsável pela codificação, testes unitários e documentação técnica.

VII. Gestor de Mudanças: Responsável pela coordenação do fluxo do PGMUD, garantindo o registro e a rastreabilidade das alterações.

3. MATRIZ DE RESPONSABILIDADES POR MACROPROCESSO

Macroprocesso / Atividade	CIG	CCB	SUBTIC	GSI / DPO	Product Owner (PO)	Time Ágil (Dev)	Gestor de Mudanças
Aprovação do PDTI e Metas	A	I	R	C	I	I	I
Análise de Admissibilidade	I	I	A	C	R	C	I
Priorização Institucional	A	C	R	I	C	I	I
Elicitação de Requisitos (DVP/Backlog)	I	I	I	C	A	R	I
Desenvolvimento de Software (Sprints)	I	I	I	I	C	R	I
Homologação Funcional (LRC)	I	I	I	I	A/R	C	I
Homologação Técnica e Segurança	I	I	A	R	I	I	C
Análise de Impacto/Risco LGPD	I	I	C	A/R	C	I	I
Autorização de Mudança (PGMUD)	I	A	C	C	I	I	R
Implantação em Produção	I	I	A	I	I	R	C
Sustentação e Suporte N3	I	I	A	I	C	R	I
Gestão de Incidentes de Segurança	I	I	C	A/R	I	R	I

4. DIRETRIZES DE CONFORMIDADE

Segregação de Funções: As atividades de aprovação, execução e auditoria não poderão ser desempenhadas pela mesma pessoa ou área, visando mitigar fraudes e erros.

Formalização: Todas as atribuições de responsabilidade "A" e "R" devem ser evidenciadas mediante assinatura eletrônica no Sistema Eletrônico de Informações (SEI).

ANEXO IX — Formulário de Autorização de Uso de Solução Tecnológica Externa

1. Unidade Solicitante:

2. Gestor Solicitante

Nome:

Matrícula:

E-mail Institucional:

Ramal/Telefone:

3. Nome da Solução / Software:

4. Nome do Fornecedor:

5. Tipo de Licenciamento

[ ] Gratuito / Freemium

[ ] Software Livre / Open-Source (Licença: _________)

[ ] Proprietário / Comercial (Necessita aquisição/assinatura)

[ ] Doação / Acordo de Cooperação Técnica

6. Modelo de Implantação

[ ] SaaS / Nuvem do Fornecedor (Web)

[ ] On-Premise (Servidores internos da SEEDF)

[ ] Desktop (Instalação local nas estações da SEEDF)

[ ] Aplicativo Móvel (Android / iOS)

7. Justificativa da Demanda

(Descrever a necessidade institucional)

8. Categorias de Dados Tratados pela Solução

(Marcar os itens aplicáveis)

[ ] Dados cadastrais de servidores (Nome, matrícula, lotação, e-mail institucional etc)

Especificar:

[ ] Dados cadastrais de estudantes/pais/responsáveis (Nome, CPF, data de nascimento, filiação, endereço etc.)

Especificar:

[ ] Dados pessoais sensíveis (Saúde, biometria, etc.)

Especificar:

[ ] Informações financeiras / orçamentárias da SEEDF

Especificar:

[ ] Outras informações. Especificar:

9. Localização dos Servidores / Dados

[ ] Servidores no Brasil

[ ] Servidores no exterior (Transferência Internacional)

[ ] Região não especificada

10. Integração com Sistemas Internos

[ ] Não integrado (Uso isolado)

[ ] Sim, necessita de integração

Se sim, especificar sistemas e tipo de conexão (API, Banco de Dados etc.).

11. Autenticação e Gestão de Acessos

[ ] Login/Senha nativo da ferramenta

[ ] SSO / Provedor de Identidade Institucional

[ ] Sem necessidade de autenticação

[ ] Outro. Especificar:

12. Requisitos de Infraestrutura Interna

[ ] Não demanda recursos da rede ou de ativos de TI da SEEDF

[ ] Demanda suporte de infraestrutura tecnológica da SEEDF. Especificar:

Este texto não substitui o publicado no DODF nº 166, seção 1, 2 e 3 de 08/09/2026 p. 7, col. 1