O Pró-Reitor de Tecnologia da Informação e Comunicação, nomeado pela portaria nº 804 de 25 de julho de 2022, no uso de suas atribuições legais e regimentais e,

CONSIDERANDO a Política de Governança de Tecnologia da Informação e Comunicação (PGTIC), aprovado por meio da Resolução Consuni nº 70 de 06 de julho de 2022, que estabelece nos seus capítulos VI e VII as políticas e diretrizes para a gestão de projetos e de serviços de Tecnologia da Informação e Comunicação na Universidade Federal do Tocantins.

CONSIDERANDO o Plano Estratégico de Tecnologia da Informação e Comunicação 2014-2022, que estabelece na diretriz 6.2.2.3. a implantação dos processos padronizados de desenvolvimento de softwares.

CONSIDERANDO o Plano Diretor de Tecnologia da Informação e Comunicação - 2015-2022 aprovado pela Resolução Consuni Nº 53 de 28 de dezembro de 2022, que elenca como princípio o desenvolvimento, a padronização, a normalização, a integração dos serviços de produção e disseminação de informações, de forma desconcentrada e descentralizada, bem como a necessidade de aprimoramento do desenvolvimento de software.

CONSIDERANDO o Plano de Transformação Digital 2022/2025 aprovado pelo Comitê de Governança Digital - CGD que dispõe da previsão de projetos e serviços digitais a serem planejados, desenvolvidos e mantidos pela Universidade Federal do Tocantins.

CONSIDERANDO o Guia de Projetos de Softwares Com Práticas de Métodos Ágeis para o Sistema de Administração dos Recursos de Tecnologia da Informação (SISP).

ESTABELECE:

 

TÍTULO I

DAS DISPOSIÇÕES PRELIMINARES

 

Art. 1º Esta normativa estabelece orientações sobre os procedimentos e metodologias adotadas para o desenvolvimento e manutenção de softwares no âmbito da Pró-Reitoria de Tecnologia da Informação e Comunicação (Protic).

§ 1º No que couber, aplica-se às demais unidades administrativas que possuam equipes de desenvolvimento de software.

§ 2º Não é escopo desta normativa regulamentar o desenvolvimento de software para atender projetos:

a) fomentados por agência;

b) de estágio obrigatório;

c) de trabalhos de conclusão de curso;

d) em dissertações e teses.

§ 3º As restrições aplicam-se mesmo que exista algum servidor da UFT participando nos projetos elencados no § 2º.

§ 4º Projetos oriundos de outras fontes não elencadas nesta normativa devem ter regulamentação própria.

 

CAPÍTULO I

DO PROCESSO DE DESENVOLVIMENTO

 

Art. 2º O processo de desenvolvimento software é um conjunto estruturado de atividades organizadas, com o objetivo de definir, desenvolver, testar e manter um software, de forma que o processo possa ser repetido durante todo o processo de produção de software.

Art. 3º O processo de desenvolvimento tem como objetivo:

a) satisfazer as diretrizes e normas sugeridas pela Administração Pública Federal;

b) padronizar e normatizar processo de desenvolvimento de software;

c) ser adequada à realidade da Protic e que possa suprir as necessidades demandadas pela administração;

d) trazer mais agilidade no desenvolvimento de software;

e) garantir a qualidade e maior disponibilidade das informações produzidas tanto no processo de desenvolvimento, quanto pelos softwares implementados.

Art. 4º O processo deve ser baseado em um conjunto de práticas relacionadas às metodologias ágeis visando prover sistemas de alto valor para a comunidade acadêmica em um curto espaço de tempo.

 

CAPÍTULO II

PROJETOS DE SOFTWARE

 

Art. 5º Os projetos de software são um serviço disponibilizado pela Pró-Reitoria de Tecnologia da Informação e Comunicação - Protic para atender as atividades de ensino, pesquisa, extensão e gestão da Universidade Federal do Tocantins.

Parágrafo único. A aprovação de projetos de software é realizada pelo Comitê de Governança Digital - CGD a partir de parecer emitido pela Pró-Reitoria de Tecnologia da Informação e Comunicação - Protic.

Art. 6º No âmbito desta normativa os projetos serão agrupados nas seguintes etapas:

I - planejamento - etapa responsável por receber a demanda, analisar a viabilidade técnica da solução e especificar os requisitos necessários para atingimento dos objetivos almejados;

II - desenvolvimento - etapa de planejamento de tecnologias a serem adotadas, codificação, testes, homologação, entrega do software implementado, documentação de sistema e de usuário.

III - manutenção, finalização e suporte - etapa após o desenvolvimento e entrega da solução responsável por realizar os treinamentos com os usuários e receber demandas de problemas ou alterações no software.

Parágrafo único. A etapa de desenvolvimento deve ser realizada de forma iterativa e incremental, com entregas parciais contínuas.

Art. 7º São classificados os projetos da seguinte forma:

I - novo desenvolvimento - um novo software ou solução a ser desenvolvido integralmente ou reconstruído a partir de um sistema legado;

II - customização e implantação - utilização de um sistema de informação já existente, dispensando a necessidade de construção de novo software;

III - manutenção evolutiva - são demandas de evolução de soluções já entregues e que já estejam em produção.

Parágrafo único. Não é escopo desta normativa a customização e implantação de sistema de informação já existente.

Art. 8º Todos os processos do software, desde a solicitação à entrega, devem ser realizados e registrados no Sistema Eletrônico de Informação - SEI, através de processo público, exceto os documentos que possam comprometer a segurança da informação da Universidade.

 

 

TÍTULO II

DO PROCESSO DE SOFTWARE

 

CAPÍTULO I

PLANEJAMENTO

 

Seção I

Da Oficialização de Demanda

 

 

Art. 9º As solicitações de desenvolvimento de software devem ser iniciadas pela unidade solicitante, através de processo eletrônico digital com o preenchimento do Documento de Oficialização de Demanda (DOD).

Parágrafo único. O DOD é de inteira responsabilidade do solicitante e deve conter informações claras e detalhadas da demanda, necessárias para que a equipe técnica de desenvolvimento de sistemas consiga avaliar a viabilidade, complexidade, custo para a equipe de desenvolvimento e também para a instituição.

Art. 10. São artefatos de saída desta etapa o Documento de Oficialização de Demanda (DOD) e demais documentos do solicitante que auxilie o entendimento da solução proposta.

Art. 11. Após o recebimento do Documento de Oficialização de Demanda (DOD) a Pró-reitoria de Tecnologia da Informação e Comunicação tem até 90 dias para a emissão de parecer de viabilidade técnica da solução proposta.

 

Seção II

Viabilidade Técnica e Econômica da Solução

 

Art. 12. O parecer de viabilidade técnica é o documento necessário para que a gestão de TIC da universidade avalie a necessidade e prioridade de desenvolvimento de software na instituição.

Art. 13. O parecer deve considerar os seguintes aspectos:

a) processo definido e discutido com os setores envolvidos na solução;

b) existência de outros softwares no mercado ou na própria instituição que atenda a solicitação;

c) compatibilidade com as demais ferramentas existentes na universidade;

d) requisitos funcionais e não funcionais exigidos na solicitação;

e) tempo necessário para o desenvolvimento da solução;

f) estimativa de investimento para implantação da solução.

Parágrafo único. A estimativa de investimento deve considerar o aporte de recursos humanos, financeiros e tecnológicos.

Art. 14. Caso o parecer de viabilidade técnica seja favorável ao desenvolvimento da solução, encaminha-se ao Comitê de Governança Digital (CGD) para inclusão no rol de prioridades.

Art. 15. Caso o parecer de viabilidade técnica seja contrário ao desenvolvimento da solução, encaminha-se ao solicitante para ciência e arquivamento do processo.

Parágrafo Único. Caso a unidade solicitante deseje recorrer do parecer técnico recebido, a justificativa sobre a necessidade do desenvolvimento deve ser encaminhada ao CGD.

Art. 16. São artefatos necessários na etapa de análise e viabilidade técnica:

I - entrada: Documento de Oficialização de Demanda (DOD);

II - saída: Parecer de Viabilidade Técnica de Desenvolvimento (PVT).

 

Seção III

Da Especificação de Requisitos

 

Art. 17. A Pró-reitoria de Tecnologia da Informação e Comunicação - Protic deve solicitar a emissão de portaria de constituição da comissão para análise e elucidação de requisitos da solução proposta.

§ 1º A portaria deve conter o prazo máximo de 90 dias para apresentação dos artefatos da etapa de especificação de requisitos.

§ 2º A portaria pode ser prorrogada por mais 30 dias, após a justificativa do líder do projeto.

Art. 18. São de responsabilidade da comissão de análise e elucidação de requisitos:

a) participar das reuniões com a unidade solicitante e envolvidos na solução proposta;

b) identificar funcionalidades que priorizem a melhoria de processos institucionais;

c) propor funcionalidades que atenda aos objetivos propostos;

d) construir o Documento de Especificação de Requisitos (DES);

e) discutir e realizar o aceite das funcionalidades descritas no Documento de Especificação de Requisitos (DES);

f) construir, discutir e aprovar o Protótipo de Média Fidelidade.

Art. 19. A Comissão deve ser constituída por:

I - um líder do projeto - servidor lotado na Pró-reitoria de Tecnologia da Informação e Comunicação (Protic) com formação na área de análise e/ou desenvolvimento de sistemas;

II - até três integrantes da unidade solicitante;

III - um membro impactado pela solução, como convidado, desde que não integre o rol de colaboradores da unidade solicitante.

Parágrafo único. Opcionalmente, pode ser incluído mais servidores da área de análise e/ou desenvolvimento de sistemas, de forma a auxiliar as atividades do líder do projeto.

Art. 20. O líder de projeto na etapa de especificação de requisitos é responsável por:

a) relacionar-se com os demais membros da equipe;

b) oferecer soluções para conflito; demandar aos demais membros a realização de tarefas; e

c) entregar os produtos de cada etapa.

Parágrafo único. Na ausência do líder do projeto, cabe ao Coordenador da Área relacionada ao projeto indicar um novo responsável.

Art. 21. São obrigatórios na especificação de requisitos os seguintes itens:

a) identificação dos stakeholders (usuários do sistema);

b) a responsabilidade de cada unidade envolvida na solução;

c) objetivos almejados com a solução;

d) escopo do que será desenvolvido lista de funcionalidades agrupadas em categorias e/ou prioridades;

e) lista de indicadores a serem gerados pelo sistema; os serviços e funções que o sistema deve prover;

f) as limitações sobre as quais o sistema deve operar;

g) definições de outros sistemas com os quais o sistema deve integrar;

h) limitações no processo usado para desenvolver o sistema;

i) descrições sobre o hardware e plataformas no qual o sistema executará.

Art. 22. Após a especificação dos requisitos pela comissão, o solicitante deve realizar o aceite das funcionalidades descritas no Documento de Especificação de Requisitos (DES).

Art. 23. Caso a codificação da solução não seja iniciada em até 6 meses após o aceite das funcionalidades, cabe à Diretoria de Soluções Digitais (DSD) avaliar a necessidade de uma nova análise ou a viabilidade da solução no momento.

Art. 24. São artefatos necessários na etapa de especificação de requisitos:

I - entrada: Documento de Oficialização de Demanda (DOD) e o Parecer de Viabilidade Técnica (PVT);

II - intermediária: Portaria de designação dos membros da Comissão de Análise e Elucidação;

III - saída: Documento de Especificação de Requisitos (DES), Aceite do Documento de Especificação de Requisitos por parte do solicitante e Protótipo de Média Fidelidade.

Parágrafo único. Compreende-se como protótipo de média fidelidade de software o desenho das telas do sistema com o objetivo de priorização e hierarquia de informações, fluxo de navegação, simulação de fluxo simples e validação da arquitetura de informação e interação com o usuário.

 

CAPÍTULO II

DESENVOLVIMENTO

 

Art. 25. Para o início da etapa de definição de tecnologias e codificação é necessário o despacho da Diretoria de Soluções Digitais (DSD) autorizando a nova etapa e designando a equipe técnica responsável pelo desenvolvimento da solução proposta.

Art. 26. São obrigatórios no despacho:

a) a indicação do líder do projeto para esta etapa;

b) a definição e atribuição da equipe técnica de desenvolvimento;

c) o prazo máximo para entrega do produto mínimo viável;

d) as tecnologias a serem adotadas.

Parágrafo único. É obrigatório a participação do líder da etapa de especificação de requisitos como membro da equipe técnica de desenvolvimento.

Art. 27. É obrigatório em todas as etapas do desenvolvimento o registro de ocorrências que impeçam ou atrasem o andamento do projeto.

§ 1º É de responsabilidade do coordenador de área o registro da ocorrência no processo eletrônico do projeto.

§ 2º O registro deve acontecer de forma periódica e deve ser concluído com a etapa de finalização do projeto.

§ 3º São obrigatórios no registro da ocorrência as seguintes informações:

a) breve descrição;

b) data da ocorrência;

c) número da solicitação de atendimento;

d) colaborador responsável;

e) tempo estimado para solução do problema;

f) tempo gasto com solução do problema;

g) impacto no projeto: tempo, recursos humanos, escopo ou qualidade.

 

Seção I

Especificação e Design da Solução

 

Art. 28. A etapa de planejamento do desenvolvimento da solução é o momento em que a equipe técnica define a linguagem de programação, framework, componentes de software, banco de dados e demais itens necessários para a solução.

Parágrafo único. A etapa de especificação e design possui o prazo máximo de 30 dias para apresentação do documento de especificação da solução ao solicitante.

Art. 29. A especificação da solução deve conter:

a) a linguagem de programação escolhida;

b) o framework a ser adotado;

c) os módulos a serem entregues;

d) a data limite do produto mínimo viável;

e) as funcionalidades que não serão desenvolvidas;

f) o cronograma de implantação das demais etapas.

Parágrafo único. Compreende-se como produto mínimo viável o conjunto de funcionalidades que juntas conseguem entregar valor ao solicitante de forma a atender minimamente aos objetivos propostos na solicitação.

Art. 30. São artefatos necessários na etapa de especificação e design da solução:

I - entrada: Despacho de Autorização, Documento de Especificação de Requisitos (DES) e Protótipo de Média Fidelidade;

II - saída: Documento de Arquitetura de Software (DAS), Diagrama de Entidade de Relacionamento (DER) preliminar e Lista de funcionalidades a serem desenvolvidas.

 

Seção II

Desenvolvimento e Codificação

 

Art. 31. Momento em que a equipe técnica de desenvolvimento realiza a codificação do software para atender aos requisitos elencados nas etapas anteriores.

Parágrafo único. É fortemente recomendado a colaboração do solicitante ou parte interessada nesta etapa do projeto.

Art. 32. Na etapa de desenvolvimento e codificação o líder do projeto é responsável por:

a) conduzir as reuniões de planejamento, revisão e encerramento para cada entrega realizada;

b) reportar qualquer impedimento que impossibilite a execução do projeto;

c) manter atualizado a lista de funcionalidades a serem desenvolvidas;

d) manter atualizado o gráfico de evolução das funcionalidades desenvolvidas.

Parágrafo único. As entregas nesta etapa devem ser realizadas na forma de corridas rápidas ou arrancadas, denominadas Sprints.

Art. 33. Deve ser utilizado pela equipe de desenvolvimento algum Sistema de Controle de Versão (SCV) para os códigos fontes do projeto de desenvolvimento.

Art. 34. O SCV deve ter suporte a ramificações, na forma de branches, a ser utilizado pelos desenvolvedores da seguinte forma:

I - feature/<nome da funcionalidade>: utilizado para a criação de uma nova funcionalidade do sistema;

II - develop: integração de funcionalidades desenvolvidas; release: todas as funcionalidades do sistema estão prontas para serem homologadas;

III - main: quando as funcionalidades estão homologadas e vão para produção;

IV - hotfix/<funcionalidade corrigida>: correção de problemas após o sistema estar em produção.

Art. 35. São artefatos necessários na etapa de codificação da solução:

I - entrada: Lista de funcionalidades a serem desenvolvidas, Documento de Arquitetura de Software (DAS), Diagrama de Entidade de Relacionamento (DER) e Checklist de testes realizados;

II - Intermediário: Lista de Funcionalidades a serem desenvolvidas (atualizada) e gráfico de evolução das funcionalidades;

III - saída: Documento de Entrega de Funcionalidade.

 

Seção III

Testes

 

Art. 36. Etapa responsável por exaurir todas as possibilidades de uso da solução, bem como avaliar a sua usabilidade.

§ 1º A equipe técnica de testes deve identificar possíveis erros, bugs e/ou defeitos na solução e pode contar com o auxílio dos usuários do sistema.

§ 2º Deve verificar se suas interfaces são intuitivas para os usuários, ou se enfrentam alguma dificuldade para utilização da aplicação.

Art. 37. É vedada a participação nesta etapa de desenvolvedores que realizaram a codificação de alguma funcionalidade.

Parágrafo único. Cabe à Diretoria de Soluções Digitais (DSD) especificar até 2 (dois) servidores para a etapa de testes.

Art. 38. Podem ser convidados servidores e/ou alunos impactados pela solução para realização de testes, onde os analistas de requisitos farão anotações sobre as dificuldades percebidas pelos usuários para posterior encaminhamento para correções.

Art. 39. Após os testes realizados, a listagem deve ser encaminhada à equipe de desenvolvimento para análise e correções.

Art. 40. São artefatos necessários na etapa de testes:

I - entrada: Documento de Especificação de Requisitos (DES) e Documento de Entrega de Funcionalidade;

II - saída: Checklist de testes realizados.

 

Seção IV

Homologação

 

Art. 41. A etapa de homologação é responsável por avaliar se a solução entregue está de acordo com as funcionalidades solicitadas pela unidade solicitante.

Parágrafo único. O membro do projeto na etapa de especificação de requisitos deve conduzir a análise dos testes no ambiente homologação junto ao solicitante.

Art. 42. A área solicitante tem até 20 dias úteis para finalizar a validação no ambiente de homologação.

Parágrafo único. Caso o aceite da etapa de homologação das funcionalidades desenvolvidas não aconteça no prazo, o coordenador da área do projeto deve solicitar à Diretoria a finalização do projeto e desmobilização da equipe de desenvolvimento.

Art. 43. São artefatos necessários na etapa de homologação:

I - entrada: Documento de Especificação de Requisitos (DES) e Documento de Entrega de Funcionalidades;

II - saída: Documento de Aceitação de Requisitos.

 

Seção V

Entrega

 

Art. 44. As entregas de software devem ser iterativas e incrementais, no prazo máximo de 15 dias úteis a partir da entrega do produto mínimo viável.

Art. 45. O tempo de entrega do produto mínimo viável não pode ultrapassar 90 dias corridos, contados a partir da data de início definida no despacho de autorização na etapa de desenvolvimento.

Art. 46. São artefatos necessários na etapa de entrega:

I - entrada: Documento de Aceitação de Requisitos;

II - saída: Nenhuma.

 

Seção VI

Documentação de Usuário

 

Art. 47. É de responsabilidade da unidade solicitante a criação de manuais, orientações e demais instrumentos que forem necessários para que os usuários possam compreender e utilizar a solução desenvolvida.

Parágrafo único. A equipe técnica envolvida na análise de requisitos deve orientar a melhor forma de apresentação dos materiais de apoio à utilização do software.

Art. 48. São artefatos necessários na etapa de entrega:

I - entrada: Documento de Especificação de Requisitos (DES), Documento de Aceitação de Requisitos;

II - saída: Materiais de apoio.

 

CAPÍTULO III

MANUTENÇÃO, FINALIZAÇÃO E SUPORTE

 

Art. 49. São objetivos da manutenção de software reparar defeitos encontrados na solução desenvolvida, que por algum motivo não foram detectados em etapas anteriores ou evolução da solução.

Art. 50. A manutenção de software é classificada em:

I - adaptativa - visa adaptar o software a uma nova realidade ou novo ambiente externo, normalmente imposto por normativas externas à instituição;

II - corretiva - é utilizada para eliminar falhas encontradas no ambiente de produção, seja por defeito em funcionalidades ou correções emergenciais que impedem a sua utilização;

III - evolutiva - alterações que visam agregar valor à solução desenvolvida, adicionando novas funcionalidades e melhorias solicitadas pelos usuários;

III - preventiva - ocorre quando o software é modificado para melhorar características de confiabilidade e manutenibilidade futuras.

§ 1º No caso de manutenção adaptativa ou evolutiva o processo deve iniciar novamente pela etapa de Oficialização de Demanda com o Documento de Oficialização de Demanda (DOD).

§ 2º Caso a manutenção seja preventiva, deve ser iniciada pela coordenação de área responsável pela solução, na forma Termo de Abertura de Projeto, constando os seguintes itens:

a) justificativa;

b) objetivo geral e específicos;

c) produtos e principais requisitos;

d) marcos;

e) premissas;

f) equipe e responsabilidades;

g) restrições;

h) riscos.

 

Seção I

Finalização

 

Art. 51. A solução é considerada finalizada quando o projeto atinge completamente os objetivos propostos.

§ 1º A Pró-reitoria de Tecnologia da Informação e Comunicação (Protic) pode desmobilizar as equipes de desenvolvimento alocados em projetos de softwares finalizados, mesmo que todas as funcionalidades elencadas para o projeto não sejam finalizadas, desde que seja autorizado pelo CGD.

§ 2º As funcionalidades descritas no Documento de Especificação de Requisitos (DES) que não puderam ser desenvolvidas devem ser elencadas em um novo processo eletrônico, de responsabilidade da unidade solicitante.

Art. 52. O processo eletrônico que deu início ao projeto deve ser finalizado com o despacho da Diretoria de Soluções Digitais (DSD) elencando os motivos da finalização do projeto.

Art. 53. Os líderes dos projetos na etapa de planejamento e desenvolvimento são responsáveis por anexar em repositório institucional todos os artefatos gerados no projeto.

Parágrafo único. Por questões de segurança, o Diagrama de Entidade de Relacionamento (DER) e outros artefatos que contenham alguma estruturação, configuração ou credenciais de acesso não podem ser inseridos no processo eletrônico digital.

Art. 54. São artefatos necessários na etapa de finalização:

I - entrada: Documento de Especificação de Requisitos (DES);

II - saída: Documento de Finalização de Projeto e Documento de Especificação de Diretório em Repositório Institucional, Documento de Registro de Ocorrências no Projeto e todos os artefatos gerados.

Seção II

Manutenção Corretiva

 

Art. 55. A manutenção corretiva é utilizada sempre quando detectado algum problema na solução desenvolvida e deve ser realizada através de solicitação de atendimento, em software específico, pela unidade solicitante.

Art. 56. Após o recebimento da solicitação, a equipe técnica tem até 3 dias úteis para responder a solicitação.

§ 1º Após a análise da solicitação, caso seja necessário desenvolver nova funcionalidade, o responsável pelo atendimento deve detalhar a necessidade ao solicitante e devolver a solicitação.

§ 2º Após a análise da solicitação, caso seja detectado defeito em alguma funcionalidade, o responsável pelo atendimento deve detalhar a situação e estimar o tempo necessário para sanar o problema apresentado.

Seção III

Suporte

 

Art. 57. A equipe de suporte às ferramentas desenvolvidas e mantidas pela Pró-Reitoria de Tecnologia da Informação e Comunicação (Protic) deve ser realizada pela Central de Atendimento e Serviços de TI instituída pela Pró-Reitoria. Parágrafo Único. Cabe à Protic, em normativa própria, instituir os membros, responsabilidades e formas de atendimento estabelecidas no caput.

Art. 58. Os níveis de atendimento em relação às soluções desenvolvidas são:

I - nível 1 (N1): é a porta de entrada das solicitações de atendimento, onde o problema é identificado e realizada as seguintes ações:

a) atender;

b) registrar;

c) qualificar;

d) priorizar;

e) resolver; ou

f) encaminhar.

II - nível 2 (N2): atendimento de média complexidade caracterizado pela experiência da equipe no assunto, ou, quando o Nível I não consegue resolver o problema;

III - nível 3 (N3): atendimento de alta complexidade com especialistas técnicos para resolução de bugs ou questões que a aplicação não realiza.

Art. 59. Os atendimentos realizados em cada nível são de responsabilidade de:

I - nível 1 (N1) - colaboradores da unidade solicitante, conforme disposto no Documento de Oficialização de Demanda (DOD);

II - nível 2 (N2) - colaboradores da Central de Atendimento e Serviços da Pró-Reitoria de Tecnologia da Informação e Comunicação (Protic);

III - nível 3 (N3) - colaboradores responsáveis pela etapa de desenvolvimento ou análise de requisitos da Pró-Reitoria de Tecnologia da Informação e Comunicação (Protic).

Parágrafo único. O nível 3 deve estabelecer um protocolo de atendimento que minimize a chegada de solicitações ao seu nível, de forma que os problemas sejam solucionados em nível inferior.

Art. 60. É obrigatório na aplicação desenvolvida a opção “Sobre” com as seguintes informações:

a) nome completo da solução, sem siglas ou acrônimos;

b) nome e sigla da unidade responsável pelo software;

c) fone ou e-mail para contato;

d) objetivos gerais e específicos da solução;

e) formas de atendimento em cada um dos três níveis;

f) informações do processo eletrônico que originou a demanda, com o seu endereço de acesso.

Parágrafo único. A aplicação deve permitir que a unidade solicitante realize alterações nesta opção, sempre que necessário, sem necessidade da equipe de desenvolvimento.

 

TÍTULO III

MÉTRICAS E TRANSPARÊNCIA

 

CAPÍTULO I

MÉTRICAS DE SOFTWARE

 

 

Art. 61. Métrica de software é a mensuração através de indicadores quantitativos de tamanho e complexidade da solução, de forma a desempenhar um papel importante na melhoria da qualidade do processo de desenvolvimento de software.

Art. 62. É adotada no âmbito desta normativa a mensuração de software utilizando pontos de histórias de usuário.

Parágrafo único. O limite para cada funcionalidade a ser executada deve ser de 20 pontos.

Art. 63. Serão adotados como pontos de desempenho nos projeto de software os seguintes indicadores:

I - tempo médio de entrega de software - considera o início da etapa de codificação e o término da etapa de entrega;

II - taxa de sucesso da Sprint - relação entre pontos planejados e executados;

III - mudança na Sprint - relação entre pontos resolvidos e não planejados.

Art. 64. A Pró-reitoria de Tecnologia da Informação e Comunicação (Protic) deve adotar ferramenta de software para realizar a mensuração dos indicadores elencados no art. 63.

Parágrafo único. Enquanto a Pró-reitoria não adotar a ferramenta de mensuração dos indicadores, a medição deve ser realizada em planilhas eletrônicas com tabelas e gráficos.

 

CAPÍTULO II

TRANSPARÊNCIA

 

Art. 65. A Pró-reitoria de Tecnologia da Informação e Comunicação (Protic) deve apresentar a lista dos projetos em execução, planejados e não finalizados no Portal da UFT.

§ 1º A lista deve conter o nome dos servidores alocados no projeto, a carga horária e a função de cada um deles.

§ 2º Para cada projeto, deve conter o número do processo do SEI para consulta.

 

TÍTULO IV

DISPOSIÇÕES FINAIS E TRANSITÓRIAS

 

 

Art. 66. Esta normativa passa a vigorar a partir da data de publicação.

Art. 67. Os projetos que não iniciaram a etapa de desenvolvimento tem até 90 dias para ajustar o projeto à instrução normativa.

Art. 68. As etapas de entrega, documentação de usuário, suporte e manutenção corretiva são obrigatórias aos projetos que já iniciaram o desenvolvimento da solução na data de publicação desta normativa.

Art. 69. Fica proibido a disponibilização de qualquer solução para a comunidade acadêmica sem a adequação das etapas constantes nesta normativa.

Art. 70. Os documentos e formulários apresentados nesta instrução normativa devem ser inseridos no Sistema Eletrônico de Informações (SEI).

Art. 71. A normativa deve ser revista no prazo máximo de 12 meses após a sua publicação, podendo ser atualizada caso seja necessário.

Art. 72. Os casos omissos serão resolvidos pela Diretoria de Soluções Digitais e coordenações de cada área.

 

 

 

 

 

Palmas, 13 de fevereiro de 2023.

 

Ary Henrique Morais de Oliveira

Pró-Reitor de Tecnologia da Informação e Comunicação