O PRESIDENTE DO COMITÊ DE GOVERNANÇA DIGITAL - CGD, designado pela Portaria nº 260/2021/GR/UNILA, no exercício de suas atribuições;
CONSIDERANDO a Norma Brasileira ABNT NBR ISO/IEC 12207:2009, que estabelece uma estrutura comum para os processos de ciclo de vida e de desenvolvimento de software;
CONSIDERANDO o Acórdão Nº 1233/2012 - TCU - Plenário, que estabelece a obrigatoriedade de formalização de processo de software, observando as boas práticas sobre o tema;
CONSIDERANDO a Norma Brasileira ABNT NBR ISO/IEC 27002:2013, que define o código de práticas para controles de segurança da informação;
CONSIDERANDO os princípios da governança de Tecnologia da Informação e Comunicação - TIC, expressos na Portaria nº 778/ME/SEDGGD/SGD, de 4 de abril de 2019;
CONSIDERANDO as diretrizes de desenvolvimento de sistemas seguros estabelecidos na Política de Segurança da Informação da UNILA (Resolução nº 3/2022/CGIRC), resolve:

Art. 1º. Definir o processo de desenvolvimento de software e estabelecer os critérios para registro, avaliação, priorização e seleção de demandas.
 
CAPÍTULO I
DAS DISPOSIÇÕES GERAIS
 
Art. 2º. Para os fins desta normativa, considera-se:
I - SIG: conjunto de sistemas de gestão de atividades administrativas, acadêmicas, de recursos humanos, eventos, eleições, entre outros, denominados SIG-UFRN;
II - roadmap: visão estratégica do produto com informações que indiquem os recursos que deverão compor as versões futuras do sistema;
II - scrum: framework ágil utilizado para a gestão do desenvolvimento de software a partir de uma abordagem iterativa e incremental, para entregar valor com frequência, reduzindo os riscos do projeto;
III - user stories: definição geral sobre um recurso de software escrita a partir da perspectiva do usuário;
IV - backlog de produto: a lista de requisitos (user stories) que compreendem o escopo do projeto, na ordem que serão desenvolvidos e entregues;
V - sprint: um período, geralmente de duas semanas, durante o qual um incremento potencialmente utilizável do software é desenvolvido;
VI - backlog da sprint: a lista de requisitos (user stories) selecionadas para desenvolvimento e entrega ao final da sprint.
VII - área técnica: a Divisão de Sistemas, unidade subordinada à Coordenadoria de Tecnologia da Informação, a quem cabe a execução do processo de software da Universidade.

Art. 3º. O processo de software da UNILA contempla as seguintes etapas:
I - registro e avaliação;
II - seleção e aprovação;
III - desenvolvimento e manutenção.
 
CAPÍTULO II
DO PROCESSO DE SOFTWARE
 
Seção I
Do registro e avaliação
 
Art. 4º. As solicitações de mudança, desenvolvimento ou implantação de software deverão ser:
I - cadastradas em formulário eletrônico próprio;
II - aprovadas pelo gestor da macrounidade administrativa competente.
Parágrafo único: A submissão deverá ser feita no período de março a outubro do ano anterior à necessidade de uso da funcionalidade e/ou sistema.

Art. 5º As propostas de normativos, resoluções e decisões de instâncias superiores da Universidade, que impactem em mudança no Sistema Integrado de Gestão ou demandem desenvolvimento de sistemas, deverão passar por deliberação do Comitê de Governança Digital. 
Parágrafo único: Se aprovadas, deverão ser registradas pela área de negócio responsável, a quem cabe definir os requisitos, acompanhar o desenvolvimento e homologar a solução.

Art. 6º. Encerrado o prazo previsto no art. 4º, §1º, a área técnica, com apoio da área requisitante, fará a consolidação e ranqueamento, avaliando-as de acordo com os critérios de priorização estabelecidos no ANEXO I.
 
Seção II
Da seleção e aprovação
 
Art. 7º. As demandas serão selecionadas até o limite da capacidade de execução, observados os critérios de seleção e a ordem de prioridade estabelecida, divididas proporcionalmente para o atendimento das demandas:
I - das áreas finalísticas;
II - das demais unidades administrativas;
III - de manutenção e evolução tecnológica do sistema.
Parágrafo único: Terão prioridade em detrimento de outras solicitações, as demandas impositivas, vinculadas a normativos legais, e aquelas que estejam associadas ao tratamento de risco institucional.

Art. 8º São critérios de seleção:
I - não prejudicar a compatibilidade e trazer riscos a futuras atualizações do sistema;
II - estar relacionada a processos e regras de negócio consolidadas;
III - ser viável em termos técnicos, de tempo e de esforço;
IV - demonstrar as condições de produzir os efeitos positivos esperados;
V -  não estar prevista no roadmap dos sistemas SIG-UFRN.

Art. 9º. As demandas não selecionadas, que recebam parecer negativo da equipe técnica, serão encerradas e comunicadas à área requisitante.
Parágrafo único. A área requisitante poderá submeter a demanda para apreciação do Comitê de Governança Digital ou adequá-la para ser avaliada no calendário seguinte.

Art. 10º. As demandas selecionadas serão encaminhadas para aprovação do Comitê de Governança Digital, na primeira reunião ordinária do ano. O Comitê poderá alterar a ordem, incluir ou remover demanda pré-selecionada, avaliados os impedimentos técnicos.

Art. 11. Até o início da etapa de desenvolvimento, o gestor da macrounidade requisitante poderá propor a substituição de demanda aprovada por outra(s) que tenha(m) passado pelo processo de avaliação e atenda(m) aos critérios de seleção.

Art. 12. As demandas aprovadas e eventualmente não executadas, deverão passar novamente pelo processo de avaliação e ranqueamento no calendário seguinte, nos termos do art. 5º.

Art. 13. A Coordenadoria de Tecnologia da Informação poderá aceitar demandas submetidas intempestivamente, desde que atendam pelo menos um dos requisitos:
a) tenham prazo legal determinado;
b) atendam a demandas de órgãos de controle;
c) estejam associadas ao tratamento de riscos institucionais ou de segurança da informação;
d) estejam impedindo a execução de processo crítico da Universidade;
e) tenham sido aprovadas pelo Gabinete da Reitoria.
Parágrafo único. A ordem de execução da demanda deverá considerar a criticidade das solicitações já aprovadas.
 
Seção III
Do desenvolvimento e manutenção
 
Art. 14. A etapa de desenvolvimento seguirá a metodologia SCRUM e deverá contemplar as seguintes fases e atividades:
I - elaboração de user stories: lista com a totalidade de requisitos e necessidades de negócio descritos pelos envolvidos; 
II -  construção do product backlog: lista ordenada em termos de prioridade, valor e complexidade, de acordo com a expectativa dos envolvidos;
III - planejamento e execução da sprint: ciclos de iterações para planejamento e execução de uma fração dos requisitos selecionados a partir do product backlog;
IV - revisão e retrospectiva: entrega dos requisitos desenvolvidos durante a sprint, apresentação dos resultados ao responsável da área de negócio e identificação de ajustes, necessidades de mudança ou melhoria.
§1. A etapa de desenvolvimento deverá ser acompanhada por um representante da área requisitante, com capacidade de decisão sobre os requisitos da solução.
§2. O planejamento da sprint deverá ser disponibilizado em sistema eletrônico para acompanhamento e monitoramento pelo representante da área requisitante.
§3. Ao final da sprint ou do projeto, deverá ser feito o registro de aceitação pelo requisitante.
§4. Mudanças significativas nos requisitos, que impactem em retrabalho ou estejam além do escopo inicial da solicitação, ou nas definições do projeto e disponibilidade de recursos necessários, poderão ocasionar a suspensão da demanda e a revisão de sua prioridade.

Art. 15. Para cada projeto de desenvolvimento, avaliada a complexidade da solução, deverão ser especificados os seguintes requisitos:
I - de sistemas de informação;
II - de segurança da informação;
III - de privacidade;
IV - de interoperabilidade;
V - de usabilidade e acessibilidade.
§1. Serão utilizadas preferencialmente técnicas de design thinking para elicitação de requisitos, compreendendo fases de imersão, ideação, prototipação e desenvolvimento.
§2. Os artefatos elaborados deverão conter as assinaturas do representante da área requisitante e do integrante técnico responsável.
§3. A critério da equipe técnica, poderão ser dispensados os artefatos, cuja ausência não represente risco ao projeto.

Art. 16. A execução de solicitações de desenvolvimento deverão ser precedidas de:
I - avaliação de soluções existentes no mercado;
II - avaliação de risco sobre dependência tecnológica;
III - avaliação de risco sobre a sustentação e manutenção do sistema.

Art. 17. Deverão ser levados em consideração os padrões de interoperabilidade e desenvolvimento de software seguro, estabelecidos para os integrantes do Sistema de Administração dos Recursos de Tecnologia da Informação do Poder Executivo Federal (Sisp), incluindo e não se limitando a:
I - manter restritos os dados em ambientes de desenvolvimento e testes, preferencialmente anonimizados e com acesso controlado;
II - realizar testes de funcionalidade e de segurança durante o desenvolvimento.

Art. 18. Deverão ser mantidas atualizadas a documentação dos sistemas e registradas em base de conhecimento as informações relevantes relacionadas a implantação, parametrização e configuração.

Art. 19. A etapa de manutenção é classificada em:
I - manutenção corretiva: aquela que visa corrigir um comportamento anormal do sistema, que não esteja em conformidade com os requisitos de funcionamento estabelecidos durante o seu desenvolvimento.
II - manutenção adaptativa: aquela que visa adicionar ou modificar um recurso ou funcionalidade em um sistema existente.
§1. Manutenções corretivas deverão ser registradas na central de serviços de tecnologia da informação, na forma de incidente.
§2. Manutenções adaptativas deverão seguir o processo de software estabelecido nesta norma.
§3. Serão realizadas atualizações periódicas nos sistemas SIG de modo a manter a compatibilidade do sistema e a incorporar os recursos desenvolvidos pela Rede de Cooperação do SIG-UFRN.

Art. 20. Toda e qualquer intervenção no código-fonte do sistema deverá manter o registro e rastreabilidade da(o):
I - solicitação, incidente ou problema que originou a necessidade de intervenção;
II - área e servidor requisitante;
III - técnico responsável;
IV - data e hora;
V - o conteúdo e o histórico das modificações realizadas.

Art. 21. Deverão ser adotados mecanismos de segregação de funções para implantação de modificações de sistemas em ambientes de produção, de modo que obrigações e responsabilidades estejam sistematicamente atribuídas a um certo número de servidores, para assegurar a realização de revisões e avaliações efetivas.
 
CAPÍTULO III
DAS DISPOSIÇÕES FINAIS E TRANSITÓRIAS
 
Art. 22. Os casos omissos relacionados a questões técnicas serão decididos pela Coordenadoria de Tecnologia da Informação - CTIC e demais casos encaminhados ao Comitê de Governança Digital.

Art. 23. Esta Resolução entra em vigor no dia 3 de outubro de 2022.

ANEXO I: CRITÉRIOS DE PRIORIZAÇÃO DE PROJETOS DE DESENVOLVIMENTO DE SISTEMAS