Post on 12-Aug-2020
Aquisição SIGA Página 1 de 40
ANEXO 6
REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS PARA AUTOMATIZAÇÃO DA
GESTÃO AEROPORTUÁRIA
A contratada deve atender, no mínimo, aos seguintes requisitos:
1. CONECTORES
1.1. ADMINISTRAÇÃO
1.1.1. Existir uma interface para Deploy dos conectores.
1.2. ARQUITETURA
1.2.1. Fornecer conectores para diversas plataformas e recursos utilizados na
Infraero de forma a fornecer interoperabilidade com estes ambientes. Dentre
eles serão necessários conectores: LDAP, Banco de dados, Arquivos, WCF,
WebServices, COM, EJB;
1.2.2. Os adaptadores devem garantir toda a comunicação e tradução da informação
de forma automática, possibilitando que essa informação seja trabalhada
posteriormente pelo barramento;
1.2.3. Os adaptadores mencionados no item 1.2.1 devem ser fornecidos prontos
para utilização e sem a necessidade de construção ou adaptação do mesmo
para se comunicar com as tecnologias solicitadas;
1.2.4. Não utilizar codificação para configuração da comunicação, exposição e
manipulação de dados pelos conectores. Todas as configurações dos
adaptadores devem ser de forma gráfica e sem a necessidade de programação
de funcionalidades;
1.2.5. Possibilitar configurar alta disponibilidade, balanceamento de carga e
tolerância a falha dos conectores em ambiente de Deploy;
1.2.6. Os adaptadores devem promover a interação bilateral entre a aplicação e o
barramento, permitindo o acesso as diferentes operações que os aplicativos
ou tecnologia fornecerem. Quando possível os adaptadores devem fornecer
essas funcionalidades de forma síncrona e assíncrona.
1.3. DESENVOLVIMENTO
1.3.1. Possuir uma interface de customização para utilização dos conectores ou
integração nativa com a funcionalidade de desenvolvimento de processos de
integração;
Aquisição SIGA Página 2 de 40
1.3.2. Possuir interface de configuração contextualizada com os ambientes
utilizados, de forma a minimizar erros e aumentar a produtividade;
1.3.3. Efetuar testes com os conectores através da interface de desenvolvimento.
1.4. MONITORAÇÃO
1.4.1. Possuir métodos para monitoração dos conectores que permitam que
ferramentas de monitoração possam interagir através do protocolo SNMP;
1.4.2. Possuir métodos para visualização de logs e alertas dos conectores, de forma
a analisar problemas e eventos.
2. MENSAGERIA
2.1. ADMINISTRAÇÃO
2.1.1. Possuir interface para administração da solução, incluindo diversos comandos
para gerenciamento de filas, tópicos, trilha de auditoria e logs e outros
recursos;
2.1.2. Possuir comandos para listagem, exclusão, inclusão e outras tarefas para filas
e tópicos;
2.1.3. Suportar a definição de forma externa de parâmetros para
configuração/tuning de acordo com necessidades específicas do cliente.
2.2. ARQUITETURA
2.2.1. Possuir a opção de implementação em ambiente de tolerância a falhas, alta
disponibilidade e balanceamento de carga;
2.2.2. Possuir autenticação, autorização, garantia de integridade de mensagens entre
outros recursos;
2.2.3. Oferecer recursos de alta disponibilidade e tolerância a falhas;
2.2.4. Ser escalável horizontalmente e fornecer performance que suporte alto
volume de tráfego de mensagens;
2.2.5. Ter a capacidade de criar conexões e roteamento entre tópicos e filas;
2.2.6. Suportar o barramento de integração a fim de permitir a criação de um
modelo distribuído de arquitetura para a integração de sistemas e captura de
eventos;
2.2.7. Permitir o armazenamento de mensagens em bancos de dados relacionais;
2.2.8. Permitir persistir mensagens em arquivos ou em base de dados relacional;
2.2.9. Suportar a entrega de mensagens com garantia.
2.3. CONECTIVIDADE
2.3.1. Disponibilizar API’s prontas e exemplos para as plataformas Java, Java EE,
Microsoft .NET, C/C++;
2.3.2. Fornecer conexão transparente com o ambiente de integração.
2.4. PADRONIZAÇÃO
Aquisição SIGA Página 3 de 40
2.4.1. Suportar o padrão JMS e todas as especificações de um JMS provider;
2.4.2. Utilizar o padrão JMS e WCF (Windows Communication Foundation) para
suportar Web Services.
2.5. SEGURANÇA
2.5.1. Possuir recursos de segurança a níveis de autenticação de usuários e envio de
mensagens;
2.5.2. Utilizar o padrão LDAP para autenticação/controle de acesso;
2.5.3. Possuir mecanismos para rastreamento das mensagens;
2.5.4. Suportar canal SSL, com chave de criptografia mínima de 128 bits, em
conectividade cliente/servidor e servidor/servidor.
2.6. TRANSPORTE
2.6.1. Suportar a priorização de mensagens;
2.6.2. Suportar interações do tipo request/reply;
2.6.3. Suportar interações do tipo publish/subscribe;
2.6.4. Suportar mensagens síncronas e assíncronas;
2.6.5. Suportar o emprego de multicast;
2.6.6. Possuir suporte a transações XA e JTA;
2.6.7. Permitir o roteamento dinâmico de mensagens;
2.6.8. Possuir parâmetros de controle que definam duração, tamanho da mensagem,
políticas entre outros atributos;
2.6.9. Possuir formas automáticas de reenvio de mensagens;
2.6.10. Permitir a retransmissão de mensagens;
2.6.11. Permitir o roteamento de filas e tópicos para outras ferramentas que
implementem o padrão JMS;
3. ORQUESTRAÇÃO DE SERVIÇOS
3.1. ADMINISTRAÇÃO
3.1.1. Possuir interface para administração da solução, incluindo diversos comandos
para gerenciamento de filas, tópicos, trilha de auditoria e logs. e outros
recursos;
3.1.2. Permitir administração via interface Web;
3.1.3. Permitir via interface gráfica iniciar, parar e reiniciar o servidor;
3.1.4. Permitir a implantação (deploy) ou atualização de aplicações sem a
necessidade de reiniciar o servidor.
3.1.5. Possuir controle de acesso administrativo baseado em usuário e perfil.
Aquisição SIGA Página 4 de 40
3.2. CONECTIVIDADE
3.2.1. Suportar SOAP ;
3.2.2. Suportar SOAP sobre JMS para publicação e consumo de serviços;
3.2.3. Fornecer conexão transparente com o ambiente de integração;
3.2.4. Suportar SOAP sobre HTTP para publicação e consumo de serviços;
3.2.5. Possuir conectividade com componentes Java;
3.2.6. Possuir conectividade com componentes .NET;
3.2.7. Possuir integração nativa com o barramento de integração.
3.3. DESENVOLVIMENTO
3.3.1. Possuir interface integrada de desenvolvimento que permita editar projetos e
criar fluxos de mediação;
3.3.2. Permitir a criação de fluxos que permitam mediação de serviços podendo
agregar funcionalidades extras na mediação;
3.3.3. Permitir a criação de serviços compostos com base em outros serviços;
3.3.4. Possibilitar o enriquecimento de mensagem na composição de serviços;
3.3.5. Ter a possibilidade de rotear invocações entre múltiplos provedores de
serviços;
3.3.6. Permitir a propagação de contexto de segurança, para garantir que o contexto
correto chegue ao serviço provedor;
3.3.7. Persistir informações de log e auditoria de utilização dos serviços;
3.3.8. Rotear mensagens com base em seu conteúdo;
3.3.9. Utilizar-se do padrão SCA para construção e execução dos fluxos de
mediação;
3.3.10. Possuir roteamento de mensagens entre diferentes protocolos garantindo o
conteúdo da mensagem;
3.3.11. Possibilitar o mapeamento de informação entre estruturas de dados distintas;
3.3.12. Tratamento de exceção criação de fluxos de mediação e composição de
serviços;
3.3.13. Utilizar-se de XSLT e XPATH para trabalhar a informação durante as
transformações de dados;
3.3.14. Possuir editor de XSLT e XPATH para evitar codificação durante o
mapeamento de informação;
3.3.15. Permitir a criação de fluxos de mediação e composição sem a necessidade de
codificação em nenhuma linguagem.
Aquisição SIGA Página 5 de 40
4. BARRAMENTO DE INTEGRAÇÃO
4.1. ADMINISTRAÇÃO
4.1.1. Permitir administração via interface Web;
4.1.2. Permitir administração via linha de comandos;
4.1.3. Permitir via interface gráfica iniciar, parar e reiniciar o servidor;
4.1.4. Permitir a implantação (deploy) ou atualização de aplicações sem a
necessidade de reiniciar o servidor;
4.1.5. Possuir controle de acesso administrativo baseado em usuário e perfil;
4.1.6. Gerar relatórios estatísticos sobre o desempenho do sistema;
4.1.7. Suportar balanceamento de carga, tolerância a falha e alta disponibilidade
através de modelos horizontais e verticais.
4.2. CONECTIVIDADE
4.2.1. Suportar a integração com banco de dados Oracle 10g ou superior, Microsoft
SQL Server 2005 ou superior, Postgres, MySQL;
4.2.2. Suportar a integração com as aplicações PHP, JEE, .NET, C/C++ e VB;
4.2.3. Suportar a integração via e-mail, utilizando o protocolo SMTP/POP. Possuir
componentes prontos;
4.2.4. Possuir conectividade com aplicações que utilizam socket TCP/IP. Possuir
componentes prontos;
4.2.5. Suportar protocolo de transporte HTTP e HTTPS (HTTP com autenticação
SSL);
4.2.6. Permitir a conectividade com aplicações que utilizam especificação JMS 1.1.;
4.2.7. Permitir a conectividade com aplicações que utilizam CORBA;
4.2.8. Suportar as plataformas e os sistemas operacionais: Unix, Linux, Windows.
4.3. DESENVOLVIMENTO
4.3.1. Suportar a criação de projetos de forma organizada em pastas e diretórios;
4.3.2. Suportar formatos numéricos, texto, lógicos, data/hora entre outros;
4.3.3. Tratar lógicas de fluxo baseadas em condições;
4.3.4. Possuir funcionalidade de modelagem que seja intuitiva, fornecendo recursos
para desenvolvimento/modelagem dos processos de forma gráfica, sem
necessidade de codificação para criação de integrações. Essa interface
também deverá contemplar a depuração e teste dos artefatos criados;
4.3.5. Possuir funcionalidade de auxílio visual de possíveis erros de mapeamento
entre estruturas de dados;
4.3.6. Dispor de recursos gráficos de teste para executar passo a passo a aplicação
de integração, possibilitando a depuração de erros em tempo de
desenvolvimento na mesma interface de desenvolvimento;
4.3.7. Utilizar XPATH e XSLT para mapeamento entre estrutura de dados e
Aquisição SIGA Página 6 de 40
fornecer funções pré-definidas de manipulação de dados;
4.3.8. Permitir a geração de webservices relacionados a processos de integração;
4.3.9. Permitir a criação de esquemas XSD;
4.3.10. Permitir a configuração de atividades, serviços e objetos de forma
contextualizada, utilizando referências pertinentes a cada um desses itens;
4.3.11. Permitir a reutilização de fluxos ou a utilização de subfluxos de integração
que possam ser invocados de modo dinâmico ou estático durante o momento
de execução;
4.3.12. Suportar ferramentas de Controle de Versão de Terceiros como o TFS - Team
Foundation Server como controle de versão universal;
4.3.13. Possibilitar criar novas funções de manipulação de dados e agregar novas
funcionalidades a ferramenta.
4.4. INTEGRAÇÃO
4.4.1. Suportar a utilização de ambientes distintos de forma independente, tais como
desenvolvimento, testes e produção;
4.4.2. Suportar a recuperação automática de serviços ou processos de integração
quando ocorrerem falhas;
4.4.3. Permitir a emissão de eventos de negócio a serem consumidos por
ferramentas de monitoração da atividade de negócio (BAM);
4.4.4. Permitir o mapeamento de mensagens via interface gráfica, através do
método “arrastar-soltar” (drag and drop);
4.4.5. Suportar controle transacional com suporte XA quando acessar banco de
dados e mensageria;
4.4.6. Suportar mensagens em formato texto ou binário;
4.4.7. Permitir o tratamento de exceções em diferentes níveis de granularidade e
tipos dentro de um mesmo fluxo de integração;
4.4.8. Permitir sequenciamento de mensagens baseado em identificadores que
possam ser definidos em tempo de modelagem do processo;
4.4.9. Ter a visão das informações de um fluxo que aconteceram em etapas
anteriores do processo;
4.4.10. Trabalhar com tabelas e referência cruzada possibilitando o uso de múltiplas
chaves para efetuar o lookup de registros em diferentes sistemas com base em
uma chave;
4.4.11. Suportar o enriquecimento de mensagens a partir de deferentes fontes de
dados.
4.5. PADRÕES
4.5.1. XML (Extensible Markup Language);
4.5.2. XSL (Extensible Stylesheet Language);
4.5.3. XSLT (Extensible Stylesheet Language Transformations),;
4.5.4. XPATH (XML Path Language);
Aquisição SIGA Página 7 de 40
4.5.5. XSD (XML Schema Definition);
4.5.6. WSDL (Web Services Description Language);
4.5.7. WS-ReliableMessaging 1.0 e 1.1;
4.5.8. WS-Addressing;
4.5.9. SOAP via HTTP(s), JMS e MQ;
4.5.10. SOAP MTOM ( Message Transmission Optimization Mechanism);
4.5.11. SOAP com anexos (SOAP with attachments);
4.5.12. SOAP 1.1 e SOAP 1.2;
4.5.13. SWIFT;
4.5.14. EDI;
4.5.15. JSON;
4.5.16. JDBC/ODBC.
4.6. SEGURANÇA
4.6.1. Suportar o padrão WS-Security;
4.6.2. Suportar a autenticação de identidades e a validação de tokens de segurança
utilizando o padrão WS-TRUST 1.4;
4.6.3. Suportar autenticação básica via HTTP;
4.6.4. Suportar servidor LDAP v3 para autenticação e autorização de usuários;
4.6.5. Suportar Tokens de segurança no formato SAML e Kerberos;
4.6.6. Suportar a configuração e utilização de certificados digitais para a
configuração de SSL e para realizar a autenticação e assinatura de
mensagens;
4.6.7. Suportar Hashing MD5 (128bit hash value) e SHA-2(256bit ou 512bit hash
value);
4.6.8. Suportar criptografia simétrica usando Data Encryption Standard (DES) e
Triple DES (3DES).
5. GOVERNANÇA
5.1. GERAL
5.1.1. Permitir o acesso às ferramentas via autenticação/autorização via LDAP;
5.1.2. Permitir a verificação via logs, trilhas de auditoria e outros métodos de
eventos que ocorram nas ferramentas, visando diagnosticar erros e prevenção
de erros que possam ocorrer;
5.1.3. Deverá ter capacidade de notificar os potenciais consumidores após a
publicação de um serviço.
5.2. USABILIDADE
5.2.1. Possuir capacidade de localização e registro automático de serviços
Aquisição SIGA Página 8 de 40
publicados;
5.2.2. Fornecer funcionalidade para que os serviços construídos tenham seus
contratos publicados e visíveis para os possíveis clientes poderem acessá-los;
5.2.3. Possibilitar que serviços possam ser publicados através de: registros de
serviços, repositórios de metadados, subdiretórios, ou uma localização
qualquer conhecida;
5.2.4. Possuir funcionalidade para monitoração do ambiente, de forma a garantir a
disponibilidade dos componentes;
5.2.5. Ser orientada às necessidades das áreas de negócio e TI, garantindo o
cumprimento de SLA's pré-estabelecidos;
5.2.6. Possuir visualizações/dashboards intuitivos com diferentes gráficos, cores e
alertas de modo a fornecer uma compreensão ágil da situação.
5.3. POLÍTICAS DE SEGURANÇA
5.3.1. Trabalhar com o conceito de separação de lógica de serviço de políticas de
acesso;
5.3.2. Permitir a criação de políticas baseadas em papéis (Role Based);
5.3.3. Permitir que as visualizações na interface gráfica sejam diferentes para cada
papel de usuário;
5.3.4. Permitir que a política de segurança esteja integrada com a console de deploy
de serviços, podendo ser visualizadas as políticas e características dos
serviços;
5.3.5. Possibilitar que as políticas de segurança possuam recursos para
gerenciamento dos endpoints dos serviços e cumprimento de políticas;
5.3.6. Possibilitar que os serviços sejam listados na console administrativa com seus
respectivos status de atividade (online ou offline);
5.3.7. Possibilitar que os serviços de integração sejam gerenciados através de
funcionalidade que contemple a autenticação, autorização, criptografia e
auditoria dos serviços;
5.3.8. Permitir que sejam disponibilizados gráficos com logs e trilhas de auditoria
dos serviços;
5.3.9. Ser coberto o ciclo de aplicação de políticas desde o registro do serviço até a
implementação da política;
5.3.10. Possibilitar que as políticas de segurança interajam com registros de serviços
do padrão UDDI;
5.3.11. Possuir análise de impacto.
6. MONITORAÇÃO
6.1. ARQUITETURA
6.1.1. Fornecer funcionalidade de monitoração do ambiente que possua console a
ser utilizada pelas equipes de monitoramento e que permita a identificação e
Aquisição SIGA Página 9 de 40
antecipação de eventos que impactem a operação dos serviços;
6.1.2. Monitorar os elementos físicos (processadores, memória, disco, etc..) onde a
plataforma está hospedada;
6.1.3. Monitorar todos os componentes da solução com detalhe e permitindo
consumir informação sobre funcionamento e efetuar ações;
6.1.4. Utilizar recursos e padrões inteligentes para tratar eventos de forma
automática, através de tomadas de ação previamente configuradas;
6.1.5. Fornecer interfaces, API's ou SDK's que permitam estender a capacidade de
monitoramento dos componentes;
6.1.6. Integrar-se com ferramentas externas de monitoração, de forma que os
eventos sejam enviados para uma console de monitoração corporativa (NOC)
através de protocolo SNMP de modo bidirecional;
6.1.7. Oferecer métodos para investigação de problemas, que auxiliem a eliminação
de eventos recorrentes e antecipação a novos incidentes/problemas.
6.2. USABILIDADE
6.2.1. Permitir a definição de níveis de alerta para os itens monitorados;
6.2.2. Permitir a tomada de ações através de regras e ações customizadas;
6.2.3. Fornecer console gráfico para operação com alertas simples e intuitivos
como, por exemplo, por cores para um rápido entendimento pelas equipes de
monitoração;
6.2.4. Possuir métodos para organização de componentes em grupos dentro da
console de monitoração.
6.3. VISUALIZAÇÃO
6.3.1. Utilizar visualizações/dashboards intuitivos que possam ser customizados de
acordo com a necessidade do projeto;
6.3.2. Possibilitar que os eventos gerados na infraestrutura sejam visualizados
através da interface gráfica de forma detalhada, utilização de recursos como
filtros e interações do tipo marcação para determinar que os mesmos estão
sendo trabalhados;
6.3.3. Possuir interface para visualização de logs utilizando filtros;
6.3.4. Possuir métodos para gerenciamento de retenção e configuração de níveis de
logs.
7. VISIBILIDADE E CONTROLE
7.1. ARQUITETURA
7.1.1. Oferecer funcionalidade de visibilidade e controle com foco corporativo,
possibilitando a criação de análises e compartilhamento entre outros usuários
de negócio através da utilização de uma plataforma centralizada com recursos
de biblioteca de análises, segurança, integração com aplicações de terceiros,
recursos matemáticos/estatísticos, publicação em diferentes formatos de
Aquisição SIGA Página 10 de 40
arquivos e acesso em tempo real a fontes de dados;
7.1.2. Permitir a configuração de diretório LDAP para autenticação e autorização de
acesso baseado em usuários e grupos;
7.1.3. Trabalhar com os dados em memória, sem necessidade de criação de bases de
dados adicionais com replicação dos dados originais;
7.1.4. Permitir a utilização de mapas georeferenciados;
7.1.5. Permitir realizar a exportação das visões para outros formatos como HTML,
PPT, figuras entre outros;
7.1.6. Permitir a interação com os dados sem alteração nas fontes originais;
7.1.7. Suportar diferentes tipos de fontes de dados, dentre eles: Banco de dados,
arquivos, planilhas, banco de dados em memória.
7.2. DESENVOLVIMENTO
7.2.1. Fornecer uma biblioteca de funções matemáticas/estatísticas para
manipulação de dados, utilização de datas/períodos, interações lógicas,
manipulação de textos entre outras;
7.2.2. Permitir que os dados sejam atualizados em casos de alteração sem a
necessidade de reconfiguração das análises;
7.2.3. Ser flexível de forma que suporte análises simples e análises mais
sofisticadas, de forma intuitiva e voltada ao usuário final;
7.2.4. Permitir a criação de novas aplicações e integração com aplicações existentes
na Infraero através de mashups ou widgets Web;
7.2.5. Possibilitar a configuração de alertas baseados nos indicadores de negócio;
7.2.6. Possibilitar visões em tempo real dos indicadores de negócio. Podendo tempo
real significar informações em uma escala de tempo de segundos;
7.2.7. Cobrir tantos dados históricos quanto informações em tempo real;
7.2.8. Permitir visualizar a correlação de eventos entre vários itens;
7.2.9. Suportar diferentes formas de visualização de informação, suportando
Gráficos 3D e 2D: Pizza, Barras, Coluna, Linha, mapa de calor (Heat Map),
mapa georeferenciado e outros;
7.2.10. Efetuar o drill down dos dados até o registro gerador do fato;
7.2.11. Contemplar funções colaborativas como publicar uma visualização para
outros usuários replicando os mesmos filtros na análise;
7.2.12. Prover funcionalidade de monitoração de processos que seja capaz de
monitorar os fluxos de processos e eventos em execução e permita identificar
pontos de melhoria;
7.2.13. Suportar recursos de agregação automática, de forma a mostrar as análises
com os dados consolidados;
7.2.14. Permitir a inserção de recursos de navegação na análise como botões, caixas
de seleção, listas, filtros entre outros;
7.2.15. Possuir biblioteca de análises para uso compartilhado de usuários utilizando
recursos para organização e segurança das análises.
Aquisição SIGA Página 11 de 40
7.3. USABILIDADE
7.3.1. Possuir funcionalidade para que os dados ao serem carregados possam ser
manipulados para criação de novos campos, definição de valores calculados,
escopo de dados a serem utilizados, definição de formato de dados e outras
funcionalidades sem alteração nos dados das fontes originais;
7.3.2. Possuir facilidades na interface gráfica do tipo 'arrastar-soltar', filtros, zoom e
outras funcionalidades;
7.3.3. Ser acessada através de browser;
7.3.4. Possuir funcionalidade para que as visões possam apontar para novas fontes
de dados de forma dinâmica sem necessidade de alterações;
7.3.5. Permitir ao usuário final configurar suas próprias visões do processo e
indicadores sem a necessidade de codificação e sem a necessidade do
envolvimento da área de TI;
7.3.6. Possuir recursos de filtros que sejam aplicados de forma imediata.
8. CACHE
8.1. ADMINISTRAÇÃO
8.1.1. Ser uma plataforma escalável horizontalmente e verticalmente;
8.1.2. Fornecer interface para monitoração, oferecendo comandos, trilhas de
auditoria e relatórios.
8.2. ARQUITETURA
8.2.1. A solução deverá ser um grid de memória distribuído compartilhando a
informação entre os diferentes nós que compõem esse grid;
8.2.2. Ser independente do uso de uma JVM (Java Virtual Machine) para o
armazenamento da informação em memória com a finalidade de se evitar
latência e maior consumo de recursos no armazenamento da informação;
8.2.3. Ser escalável, tolerante a falhas e com alta disponibilidade para suportar a
solução.
8.2.4. Oferecer recursos de stream de informação onde o Cliente possa se conectar
e ficar recebendo a informação de forma passiva;
8.2.5. Possibilitar que o cliente possa interagir com o grid como um consumidor e
provedor de informação;
8.2.6. Possuir mecanismos de replicação automático que permitam definir qual será
o modelo de replicação a ser adotado;
8.2.7. Promover descobrimento automático dos outros nós sem a necessidade de
configuração;
8.2.8. Respeitar transações ACID (Atomicidade, Consistência, Isolamento e
Durabilidade);
Aquisição SIGA Página 12 de 40
8.2.9. Possuir operações básicas de take, put, get e update;
8.2.10. Armazenamento de objetos usando recursos que garantam a
interoperabilidade entre diferentes plataformas;
8.2.11. Garantir que as aplicações clientes acessem a ferramenta através de API's
fornecidas e documentadas, sendo as mesmas disponibilizadas em Java, .Net
e C;
8.2.12. Possibilitar a consulta de forma paralela e possuir um índice próprio;
8.2.13. Permitir que, caso seja necessário, a informação possa ser persistida em
disco.
9. GESTÃO DE REGRAS DE NEGÓCIO
9.1. ADMINISTRAÇÃO
9.1.1. Permitir que usuários administradores utilizem método de aprovação de
regras definidas por usuários de negócio;
9.1.2. Permitir que a interface de desenvolvimento gere o pacote para implantação
em produção.
9.2. ARQUITETURA
9.2.1. Integrar-se com outras ferramentas da solução como Processos de Negócio e
Integração;
9.2.2. Permitir o tratamento de condições de diversos tipos, através de parâmetros
recebidos;
9.2.3. Garantir que as condições utilizem funções, testes lógicos e manipulação de
dados;
9.2.4. Fornecer diversas funções para serem utilizadas na definição de regras;
9.2.5. Possibilitar que as regras sejam definidas externamente e importadas, além de
poderem também ser exportadas;
9.2.6. Garantir que existam métodos para validação de regras de negócio definidas
na interface de desenvolvimento como validação de sobreposição de regras,
loops infinitos, condições ausentes, etc;
9.2.7. Permitir o controle de acesso via LDAP.
10. CORRELAÇÃO DE EVENTOS
10.1. ADMINISTRAÇÃO
10.1.1. Permitir a alteração de propriedades de configuração para adaptação de
necessidades específicas de ambiente;
10.1.2. Disponibilizar recursos de administração via console linha de comando.
Aquisição SIGA Página 13 de 40
10.2. ARQUITETURA
10.2.1. A solução de correlação de eventos deverá implementar o conceito de CEP -
Processamento de Eventos Complexos;
10.2.2. Garantir que tenha a capacidade de captura de eventos nos ambientes de
Integração e Mensageria para a correlação de eventos e obtenção de padrões,
cenários e comportamentos;
10.2.3. Possuir recursos de tolerância a falhas;
10.2.4. Permitir que mudanças em projetos sejam inseridas sem necessidade de
paradas em ambiente de runtime;
10.2.5. Integrar-se à ferramenta de integração para definição de processos que
interajam com a ferramenta de correlação de eventos.
10.3. CONECTIVIDADE
10.3.1. Prover comunicação com tecnologias como JMS, HTTP, SOAP e TCP entre
diferentes plataformas.
10.4. DESENVOLVIMENTO
10.4.1. Garantir que as regras configuradas em ambiente de desenvolvimento sejam
acionadas em tempo real em ambiente de runtime;
10.4.2. Garantir que seja orientada a modelos, desta forma estabelecendo uma
linguagem padronizada para desenvolvimento e configuração;
10.4.3. Possuir a capacidade de identificação de padrões de comportamento de
eventos e tomada de ação;
10.4.4. Garantir que tenha a capacidade de, a partir de padrões identificados,
determinar previamente ações a serem tomadas;
10.4.5. Garantir que tenha a capacidade de definição de fontes de dados de eventos e
também de destinos para as ações correspondentes;
10.4.6. A ferramenta deve executar a transformação de dados.
10.4.7. Tratar eventos de diversas naturezas e características específicas, tratando
regras de exceções e temporais;
10.4.8. Possibilitar configurar modelos que utilizem atributos específicos a entidades,
de forma a se criar referências para manipulação de eventos;
10.4.9. Possibilitar a criação de relacionamentos entre os modelos gerados;
10.4.10. Permitir a criação de regras específicas para tratamento de eventos recebidos
através das conexões de origem;
10.4.11. Garantir que as regras utilizem diversos parâmetros como referências para
eventos de entrada, ações a serem tomadas e cenários condicionais para
execução;
10.4.12. Garantir que as regras passem por verificações antes da execução;
10.4.13. Garantir que as regras sejam criadas em interface gráfica, através de
utilização de linguagem intuitiva, orientada a verificações lógicas e
condicionais;
10.4.14. Permitir a criação de listagens que indiquem métricas/KPI's de classificação
Aquisição SIGA Página 14 de 40
de tendências, para serem utilizadas como bases para outros cenários;
10.4.15. Fornecer uma biblioteca de funções pré-definidas que possam manipular
situação lógica, contextual e de atribuição utilizadas nas regras;
10.4.16. Trabalhar com tipos de dados texto, numéricos, lógicos, data entre outros;
10.4.17. Possuir métodos para testes e debug de projetos;
10.4.18. Garantir que os projetos tenham métodos de validação e verificação de erros;
10.4.19. Garantir que os projetos sejam implementados em ambiente de runtime via
pacotes definidos na interface de desenvolvimento.
10.5. MONITORAÇÃO
10.5.1. Possuir capacidades de monitoração dos componentes da ferramenta;
10.5.2. Possuir recursos de auditoria, logs e relatórios para acompanhamento de
alertas e disponibilidade de componentes;
10.5.3. Permitir a utilização do padrão JMX para monitoração.
10.6. SEGURANÇA
10.6.1. Permitir a utilização de padrões como LDAP e JAAS para controle de acesso.
10.7. USABILIDADE
10.7.1. Possuir interface gráfica para modelagem de regras;
10.7.2. Garantir que a interface gráfica da solução de correlação de eventos seja
amigável ao usuário, fornecendo recursos como 'arrastar-soltar', ícones,
alertas de erros entre outros recursos;
10.7.3. Garantir que o mapeamento e a transformação de dados sejam efetuados via
interface gráfica, utilizando recursos como 'arrastar/soltar'.
10.8. VISIBILIDADE
10.8.1. Disponibilizar visões diferentes para definições de regras, dados de entrada e
modelos de negócio.
11. AUTOMATIZAÇÃO DE PROCESSOS
11.1. ARQUITETURA
11.1.1. Possuir um ambiente integrado com interface única para a definição,
modelagem, desenho, documentação, analise, geração de relatórios,
simulação e publicação de processos de negócios;
11.1.2. Arquitetura Cliente-Servidor com base de dados centralizada no servidor;
11.1.3. Permitir que os softwares sejam executados, operados e administrados por
meio de Web Browser, com acesso 100% WebBased a todas as
funcionalidades do sistema ou, alternativamente, que sejam compatíveis com
Linux Redhat 5 ou superior e Windows Server 2008 ou superior;
11.1.4. O ambiente integrado deve permitir que múltiplos usuários, de diversas áreas
da instituição, trabalhem simultaneamente, mantendo a integridade dos
Aquisição SIGA Página 15 de 40
fluxos. Para tal, a solução devera ser provida de funcionalidade que garanta a
integridade dos fluxos quando eles forem manipulados por mais de um
usuário simultaneamente;
11.1.5. A solução não deve apresentar qualquer limitação quanto a quantidade de
processos, atividades e sub-processos modelados. Inclusive, em relação a
quantidade de subniveis de fluxos, não deve haver nenhuma limitação. A
navegação entre os subniveis deve ser do tipo “drill down”;
11.1.6. Permitir simular processos de negócio com base em dados históricos, dados
de processos em execução e dados simulados;
11.1.7. Apresentar relatórios comparativos com os diversos cenários de simulação a
serem definidos pelos usuários;
11.1.8. Utilizar diversos parâmetros de interação como tempo, recursos monetários,
números de funcionários entre outros;
11.1.9. Utilizar mecanismos de alta disponibilidade, balanceamento de carga e
tolerância a falhas;
11.1.10. Integrar-se de forma nativa com os outros componentes da plataforma;
11.1.11. Não necessitar instalar plug-ins, controles ou applets para os usuários via
interface Web, com exceção a plug-ins padrões de mercado, por exemplo:
flash;
11.1.12. Permitir a coexistência de versões antigas com versões novas de processos;
11.1.13. Permitir a migração de versões antigas de processos para versões mais
recentes;
11.1.14. Oferecer atividades/tarefas aos usuários de forma dinâmica obedecendo a
critérios como posições exercidas na empresa, habilidades, definições
complexas, calendários/datas, distribuição/rodízio entre outros atributos de
forma automática e previamente configurada;
11.1.15. Possuir funcionalidade de rastrear os passos executados pelas atividades
através de console administrativa, de modo a identificar possíveis falhas,
gaps e cenários através de privilégios de administração;
11.1.16. Suportar, no mínimo, os seguintes padrões internacionais para modelagem de
processos: Business Process Modeling Notation (BPMN) e Oasis’ Business
Process Execution Language (BPEL).
11.2. DESENVOLVIMENTO
11.2.1. Possuir interfaces para desenvolvimento de processos, administração e
interface de usuário de forma separada;
11.2.2. Atender usuários de negócio e arquitetos de forma contextualizada separando
as responsabilidades de cada um para simplificar a visualização dos
processos;
11.2.3. Possuir ambiente de modelagem para desenho, visualização, atualização e
análise de processos e diagramas, que ofereça interface gráfica compatível
com operação por analista de negócios, detentor de conhecimento básico em
informática;
11.2.4. Refletir o organograma da empresa para a utilização dos papéis do
Aquisição SIGA Página 16 de 40
organograma no processo de negócio;
11.2.5. Permitir a criação de projetos de forma organizada em pastas/diretórios,
separando os tipos de artefatos e armazenamento no padrão BPMN e
armazenamento em XPDL;
11.2.6. Garantir que a interface de desenvolvimento/modelagem permita a
verificação de erros que impeçam a execução correta do processo de negócio;
11.2.7. Garantir a execução do processo sobre através da modelagem BPMN sem a
necessidade de conversão para BPEL, evitando complexidade de conversões
para executar o deploy;
11.2.8. Suportar diversos tipos de dados primitivos e complexos;
11.2.9. Permitir o mapeamento dos campos contidos nos formulários eletrônicos aos
metadados dos fluxos de trabalho e das atividades em que são utilizados, para
atribuição automática de valores quando da execução do processo;
11.2.10. Ter ferramental para a depuração do desenvolvimento (Debug);
11.2.11. Exportar a documentação dos processos de negócio em outros formatos
como, por exemplo, HTML;
11.2.12. Permitir a criação de fluxos de tela e associá-las a uma atividade manual do
processo de negócio. O objetivo deste fluxo de telas é permitir uma interação
mais complexa com o usuário, coletando informações em várias etapas para
possibilitar uma melhor experiência de uso.
11.3. FUNCIONALIDADES DO MÓDULO SERVIDOR E ADMINISTRAÇÃO
11.3.1. Permitir o credenciamento de perfis e grupos de usuários;
11.3.2. Permitir a associação de privilégios de acesso a determinado grupo da base
de dados;
11.3.3. Possibilidade de configurar o perfil dos usuários através de grupos ou
individualmente;
11.3.4. Permitir a associação de filtros e templates aos usuários;
11.3.5. Permitir configurar permissões de grupos de usuários garantindo que eles (os
usuários) tenham acesso apenas aos arquivos de sua área ou grupo de
processos;
11.3.6. Possuir autenticação de usuário via LDAP;
11.3.7. Efetuar o controle de acesso dos usuários as informações do repositório e
relatórios, de acordo com perfis e grupos de usuários, mantendo o registro e
controle das atualizações efetuadas pelos mesmos;
11.3.8. Possuir um repositório único baseado em banco de dados relacional que
permita a reutilização de informações e o uso compartilhado de objetos
componentes dos diagramas;
11.3.9. Os objetos no banco de dados devem possuir identificador universal que seja
único dentro de uma mesma base de dados, garantindo um identificador
único para um objeto;
11.3.10. Possuir funcionalidade para gestão dos mapas e objetos no repositório;
Aquisição SIGA Página 17 de 40
11.3.11. Possuir ferramenta de administração do repositório (alterar nome, criar novo
repositório, eliminar repositório, importar repositório e exportar repositório);
11.3.12. Possuir ferramenta para gestão do servidor;
11.3.13. Possibilitar a replicação manual do repositório;
11.3.14. Capacidade de backup e restore na ferramenta de modelagem.
11.4. FUNCIONALIDADES DO MÓDULO DE ANÁLISE E MODELAGEM DE
PROCESSOS
11.4.1. Efetuar a modelagem de processos em BPMN a partir de interface gráfica de
fácil entendimento, destacando atividades, insumos, produtos, indicadores e
regras de negocio;
11.4.2. Permitir visões múltiplas e integradas dos processos, desde o nível estratégico
(visão de macroprocessos) ate o nível operacional (descrição de atividades,
tarefas e procedimentos);
11.4.3. Permitir a criação de diagramas que representem a estrutura organizacional e
que contemplem as pessoas, funções, competências e conhecimentos que
compõem essa estrutura, além das associações entre esses elementos;
11.4.4. Possibilitar a modelagem de processos que incluam recursos da organização
– colaboradores, computadores, veículos ou eletricidade. Qualquer pessoa,
equipamento ou material usado para formar uma tarefa ou projeto que precise
ser representado e utilizado na modelagem de processo;
11.4.5. Possibilitar estruturar toda a organização dentro do negocio como um todo:
companhia, divisões e departamentos;
11.4.6. Permitir a validação do processo modelado através de interface gráfica
intuitiva, exibindo os resultados do diagrama avaliado. A validação do
processo significa a execução de analise automática e critica da modelagem,
quanto a semântica utilizada;
11.4.7. Possuir modelos de diagramas que representem: organização, glossário,
dados, processos, atividades e produtos/serviços;
11.4.8. Possuir funcionalidade que permita anexar arquivos e ou documentos
externos a objetos representados nos diagramas, no mínimo nos formatos
comuns de mercado para editores de texto, planilha de calculo e HTML,
permitindo também, a criação de links com programas executáveis em geral;
11.4.9. Possibilitar inserção de atributos aos objetos, em particular, os que se referem
a custos, tempos, volumes e recursos, significando a possibilidade de inserção
de informações livres para cada símbolo disposto no diagrama;
11.4.10. Permitir o link entre modelos (interfaces e subprocessos) de forma ilimitada;
11.4.11. Permitir a navegação entre os diagramas de diferentes processos e entre os
níveis de detalhamento do mesmo processo, a partir de links e ou conexões
na representação gráfica do mesmo;
11.4.12. Possuir recursos de editar, copiar, recortar, colar e localizar os objetos
modelados;
11.4.13. Possuir funcionalidade de reorganização gráfica e alinhamento automático de
objetos, inclusive com capacidade para visualização do modelo em formato
Aquisição SIGA Página 18 de 40
horizontal e vertical;
11.4.14. Permitir a modelagem e a visualização no formato de raias (swimlane) do
modelo do processo, representando cargos ou unidades organizacionais ou
classificações;
11.4.15. Possibilitar manter as definições da organização dentro de um projeto
(diretório ou pasta) para serem reutilizadas e revisadas conforme a evolução
da organização;
11.4.16. Possibilitar a modelagem estrutural através da construção de estruturas para
mostrar como os diferentes tipos de entidades do negocio interagem com
outros nos relacionamentos;
11.4.17. Permitir as seguintes análises estáticas de informações a partir do modelo:
11.4.17.1. Analise de funções de recursos para mostrar uma lista de recursos
e as funções de associações para cada recurso;
11.4.17.2. Analise da hierarquia de tipo para apresentar todas as ocorrências
de uma definição especificada da organização dentro de um
conjunto de definições da estrutura;
11.4.18. Proporcionar um ambiente de compartilhamento;
11.4.19. Permitir colaboração entre os usuários, em particular, para inclusão de
comentários, sugestões e anotações de usuários nos modelos;
11.4.20. Suportar exportação dos modelos ou produção de documentos em formatos
padrão de mercado (editores de texto, planilhas de calculo, HTML);
11.4.21. A partir de um fluxo de processo, permitir a geração de relatórios, como
manuais de procedimentos e normas, permitindo a definição do layout do
relatório final, bem como, a sequencia de impressão em relação às atividades
do processo;
11.4.22. Permitir correção semântica de modelagem exibindo os resultados na
interface gráfica do diagrama avaliado;
11.4.23. Possuir recurso da apresentação em tela cheia com possibilidade de desenho
livre no diagrama;
11.4.24. Permitir parametrização ou criação de simbologia de mapeamento e ou
modelagem, nomes de atributos e nome de diagramas, por meio de assistentes
(wizards);
11.4.25. Permitir a customização das fontes e documentos emitidos, de forma
automática pela ferramenta, por meio de templates;
11.4.26. Permitir utilização de templates para padronização de cores, e formatos dos
objetos do modelo;
11.4.27. Possuir pesquisas por objetos e atributos identificando suas ocorrências nos
processos mapeados e apresentar o resultado de forma gráfica e em relatórios;
11.4.28. Permitir criar consultas a partir de assistentes (wizards) e armazenar a
configuração da consulta para futuras utilizações;
11.4.29. Analise de funções de recursos para mostrar uma lista de recursos e as
funções de associações para cada recurso;
Aquisição SIGA Página 19 de 40
11.4.30. Analise da hierarquia de tipo para apresentar todas as ocorrências de uma
definição especificada da organização dentro de um conjunto de definições
da estrutura;
11.4.31. Possuir funcionalidade de conversão entre os diagramas, em particular, do
diagrama de processo para o diagrama de atividades UML;
11.4.32. Permitir, com base nas informações mapeadas, a criação de modelos do tipo
entidade e relacionamento;
11.4.33. Permitir a criação de modelos de apoio na modelagem de processos (ex.
Registro de riscos, sistemas, controles, etc.);
11.4.34. Permitir a associação entre os processos mapeados e suas atividades com
objetos de dados ou objetos de negocio;
11.4.35. Permitir a documentação dos processos e de suas atividades em nível de caso
de uso de sistemas, de modo a garantir a aderência do modelo de processo
com os modelos de sistemas existentes;
11.4.36. Possuir integração com outras ferramentas de modelagem de processos,
ferramentas CASE e de Workflow;
11.4.37. Permitir a importação e exportação dos processos modelados, em padrão
XML;
11.4.38. Fornecer o controle de versão dos processos modelados, guardando histórico
das atualizações, possibilitando a comparação entre modelos e provendo a
capacidade de recuperação de versões anteriores;
11.4.39. Permitir a organização e padronização da documentação de processos, de
forma a orientar e facilitar a obtenção de certificação de qualidade associada
aos processos;
11.4.40. Possuir um assistente para criação de relatórios customizados;
11.4.41. Possuir um conjunto de modelos de relatório que contemplem todos os tipos
de informação que possam ser documentadas;
11.4.42. Permitir a customização de relatórios e gráficos matriciais que permitam o
cruzamento de diversas visões: processos, organização, sistemas, documentos
e indicadores;
11.4.43. Permitir gravar os relatórios para serem acessados via WEB;
11.4.44. Possibilitar a criação de gráficos utilizando quaisquer atributos numéricos
atribuídos aos processos, em particular, tempos e custos;
11.4.45. Permitir o gerenciamento de sugestões de melhoria nos modelos
homologados;
11.4.46. Permitir comparações entre diagramas considerando objetos existentes,
atributos e relacionamentos apresentando as discrepâncias em tela ou
relatório;
11.4.47. Possuir filtros que permitam limitar a utilização da simbologia, diagramas,
objetos e atributos, por usuários ou grupo de usuários para a padronização
dos resultados;
11.4.48. Permitir a definição de ilimitados filtros metodológicos customizados pelo
Aquisição SIGA Página 20 de 40
usuário, que permitam a definição de grupos de objetos, modelos, formas e
atributos para a padronização dos resultados;
11.4.49. Possuir metodologia e filtros adequados para documentação de riscos
(operacionais e outros) orientados a processos, subprocessos ou atividades,
bem como objetos correlacionados (Gestor de Risco, Controle, etc.);
11.4.50. Permitir cópias de objetos em varias modalidades, em particular, copia que
permita que um usuário compartilhe o mesmo objeto em vários diagramas,
copia que permite que um usuário copie diagramas inteiros já desenhados
para aproveitar a estrutura do diagrama para criar um novo diagrama e a
copia que permita realizar copias fieis dos objetos e diagramas, preservando
as informações dos elementos originais;
11.4.51. Permitir a criação de cópias “variantes” de modelos de processos ou modelos
de apoio;
11.4.52. Permitir comparação entre cópias “variantes” de modelos de processos,
permitindo rotinas de comparação e “benchmark”;
11.4.53. Permitir a consolidação das informações de objetos que possuam o mesmo
nome na base de dados de processos, possibilitando a geração de um único
objeto para organização e otimização da base;
11.4.54. Possibilitar utilização de scripts para gestão e manutenção de atributos em
massa (mudanças globais na base);
11.4.55. Efetuar a modelagem em padrão BPEL a partir de interface gráfica intuitiva
de modo a permitir a modelagem de processos de integração de sistemas e
dados;
11.4.56. Os diagramas em padrão BPEL devem ser gerados automaticamente a partir
dos modelos de processos de negocio;
11.4.57. Permitir a importação de WSDL descrevendo o serviços no nível de negocio
afim de se construir um repositório de serviços que possam ser reutilizados
na modelagem BPEL;
11.4.58. Permitir a importação de XSD;
11.4.59. Permitir a identificação gráfica do serviço importado;
11.4.60. Permitir a associação de serviços nos fluxos de processos;
11.4.61. Permitir a exportação do fluxo em BPEL no padrão 1.1 ou superior.
11.5. FUNCIONALIDADES DO MÓDULO DE PUBLICAÇÃO WEB
11.5.1. O modulo de publicação WEB deve ser integrado ao modulo de analise e
modelagem de processos por meio de uma única interface;
11.5.2. Permitir a publicação na WEB dos processos modelados, inclusive com toda
a documentação existente;
11.5.3. Permitir a publicação dos processos de portal WEB navegável com
funcionalidades de navegação similar as disponíveis na ferramenta;
11.5.4. Permitir a atualização automática do conteúdo publicado na intranet e
internet;
11.5.5. Permitir imprimir os fluxos a partir da ferramenta;
Aquisição SIGA Página 21 de 40
11.5.6. Permitir divulgar os modelos na Intranet ou Internet com funcionalidades
semelhantes aquelas da versão cliente-servidor, em particular, a capacidade
de acessar os atributos.
11.5.7. Permitir que as interfaces de usuário final sejam disponibilizadas via Web e
dispositivos móveis;
11.5.8. Permitir que a interface de usuário apresente de forma organizada, as tarefas
atribuídas ao usuário, histórico de atividades e tarefas que podem ser
iniciadas de acordo com os privilégios estabelecidos;
11.5.9. Permitir que o usuário possa configurar as preferências de visualização na
interface de usuário final;
11.5.10. Possibilitar efetuar consultas a processos através de critérios inseridos;
11.5.11. Possibilitar a consulta ao histórico de um processo, obtendo entre outras
informações: data/horas, atividades executadas e usuários participantes.
12. GESTÃO DE RECURSOS AEROPORTUÁRIOS – RMS
13.1. REQUISITOS GERAIS
13.1.1. Ambiente multi-aeroporto: o sistema deve operar em uma única base de
dados com estrutura de multi-aeroporto;
13.1.2. Fornecer facilidades de interface com o usuário através do uso de ferramentas
gráficas (Diagrama de Gantt), visões aéreas e formulários específicos para a
entrada de dados de configuração do sistema, regras de alocação,
preferências, prioridades, restrições e sazonalidades;
13.1.3. Compartilhar as informações, de forma estruturada, entre os diversos
processos do sistema;
13.1.4. Possuir ferramentas para a manutenção das tabelas do sistema mediante os
níveis de acesso dos usuários, de modo que possam realizar inclusões,
alterações, exclusões e consultas;
13.1.5. Registrar em LOG todas as operações realizadas pelos usuários;
13.1.6. O idioma usado para interface ao usuário (formulários, texto de ajuda - help
on line, alertas de sistemas, relatórios) deve ser o português do Brasil;
13.1.7. Prover lista de pendências relacionadas à operação, com de geração de alertas
e envio automático de correspondência eletrônica;
13.1.8. Possuir ferramentas de rastreabilidade das alocações de recursos de forma
que a partir de uma informação macro possa chegar até o seu menor nível de
detalhamento (Drill-Down);
13.1.9. Apresentar as informações do sistema em tela e geração de relatórios em
mídia eletrônica;
13.1.10. Possuir ferramentas para a definição de perfis de operadores para a
segmentação das operações de alocação dos recursos;
13.1.11. Possuir ferramentas para a definição e armazenamento de filtros para a
criação de consultas, permitindo a reutilização posterior pelos usuários, sem
Aquisição SIGA Página 22 de 40
que haja a necessidade de alteração no código;
13.1.12. De forma geral, todas as consultas e visões devem ser disponibilizadas via
browser através da Web.
13.2. FACILIDADES DO OPERADOR
13.2.1. Os alocadores devem trabalhar independentemente sobre as telas de alocação
dos recursos aeroportuários (portões, posições de estacionamento, esteiras,
balcões de check-in, recursos móveis e demais recursos), sendo que as
mudanças feitas por um alocador devem ser refletidas aos outros;
13.2.2. O sistema deve considerar o Gráfico de Gantt como a ferramenta básica dos
operadores, com a representação dos recursos alocados em forma gráfica e
em tempo real, devendo haver disponibilidade de mudança de alocação com
interface amigável, utilizando funções de arrastar e largar (drag and drop);
13.2.3. Utilizar o calendário sazonal para criação dos planos de alocação de recursos;
13.2.4. Armazenar os planos de alocação para utilização futura;
13.2.5. Gerar imagens em planta que possibilitem mostrar as alocações dos recursos
nas diferentes áreas do aeroporto;
13.2.6. As funções do sistema devem ser selecionadas através de menus e as
acessadas mais frequentemente devem também ser selecionadas através de
atalhos;
13.2.7. Permitir o gerenciamento manual da alocação de recursos em tempo real de
acordo com a ocorrência de eventos (por exemplo: realocação de recursos
motivados por voos cancelados, voos atrasados, voos alternados, retorno à
posição de estacionamento, inoperância de recursos e outros);
13.2.8. Gerar cenários de planejamento do tipo "what if";
13.2.9. Possuir ferramentas para adicionar, excluir e editar regras do sistema;
13.2.10. Possuir ferramentas para adicionar, excluir e editar recursos aeroportuários,
suas capacidades e características;
13.2.11. Possuir ferramentas para adicionar, excluir e editar priorização e preferências
de atendimentos;
13.2.12. Possuir ferramentas para adicionar, excluir e editar a inoperância dos
recursos.
13.3. MODELOS DE ALOCAÇÃO DE RECURSOS
13.3.1. Planejamento e Simulação
13.3.1.1. Os dados referentes aos recursos utilizados deverão ser
disponibilizados para efeito de planejamento por período pré-
estabelecido, sendo que deverá ocorrer o armazenamento de todas
as alocações efetivamente realizadas durante o dia;
13.3.1.2. O operador pode efetuar o planejamento prévio da alocação dos
recursos e definir o período para o qual o plano será aplicado (por
exemplo: período sazonal, diário, semanal, mensal), tendo como
objetivo a identificação de gargalos e potenciais situações de
conflito, bem como servir de base para o módulo de operação
Aquisição SIGA Página 23 de 40
diária;
13.3.1.3. O sistema deve ser capaz de realizar uma alocação automática
tomando por base um conjunto de regras e restrições previamente
descritas e configuradas;
13.3.1.4. Os voos não alocados deverão ser alertados e apresentados de
forma destacada;
13.3.1.5. O sistema deve ser capaz de fazer a alocação automática para
qualquer período, abrangendo todos ou um subconjunto dos
recursos;
13.3.1.6. O sistema deve ser capaz de otimizar a alocação dos recursos,
apresentando sugestões de soluções possíveis em cada caso para
serem aceitas ou descartadas pelo alocador, bem como apresentar
opção de “solução ótima” para todos os recursos existentes; As
sugestões propostas deverão ser construídas e ordenadas com
base em parâmetros de regras de alocação de recursos;
13.3.1.7. O sistema deve ser capaz de simular cenários do tipo "What if",
como por exemplo a manutenção de recursos, aumento de
número de voos, eventos especiais e situações emergenciais,
novos recursos, sem causar impacto no banco de dados
operacional;
13.3.1.8. O sistema deve apresentar de um plano geral dos recursos
alocados no período corrente da operação ou períodos definidos
pelo usuário;
13.3.1.9. O sistema deve permitir ajustes manuais no plano de alocação
gerado, alertando o usuário quanto aos conflitos gerados ou
violação de regras e restrições.
13.3.2. Operação em Tempo Real
13.3.2.1. O planejamento do dia atual deve ser utilizado para permitir a
alocação dinâmica dos recursos;
13.3.2.2. O sistema deve operar em dois modos:
13.3.2.2.1. Modo automático: Todas as mudanças de alocação
são recomendadas pelo sistema para o operador,
sendo que estas alocações poderão ser confirmadas
ou não pelo operador;
13.3.2.2.2. Intervenção manual: Os operadores podem
manualmente realocar recursos;
13.3.2.3. O sistema deve trabalhar com as informações atualizadas do
banco de dados operacionais do aeroporto;
13.3.2.4. O sistema deve permitir a modificação em tempo real dos
parâmetros dos recursos, regras e restrições, refletindo
imediatamente na operação;
13.3.2.5. O sistema deve exibir a lista de pendências e permitir ao operador
realizar as ações necessárias de maneira manual ou automática;
Aquisição SIGA Página 24 de 40
13.3.2.6. O sistema em modo automático deve respeitar as intervenções
manuais realizadas pelo operador e, em caso de ocorrer algum
conflito, apresentar uma lista de pendências para tratamento.
13.3.3. Regras de Alocação
13.3.3.1. O sistema deve possuir um conjunto configurável de regras e
restrições globais de operação do Aeroporto;
13.3.3.2. O sistema deve possuir um conjunto configurável de regras e
restrições para cada tipo de recurso a ser alocado;
13.3.3.3. O sistema deve possuir um conjunto configurável de regras e
restrições para a definição de prioridade e preferências para
alocação;
13.3.3.4. O sistema deve disponibilizar a edição dos conjuntos de regras
aos usuários autorizados de tal maneira que possam sofrer
modificações (inserção de novas regras, alteração ou deleção das
existentes) sem a necessidade de gerar novos códigos-fonte;
13.3.3.5. O sistema deve aplicar as regras sobre a programação de voos
aprovados e registrar as alocações resultantes no banco de dados
operacionais do aeroporto;
13.3.3.6. O sistema deve aplicar as regras sobre a programação de voos
pendentes de aprovação e armazenar o planejamento das
alocações resultantes;
13.3.3.7. As regras devem respeitar os critérios de dependência de
utilização e restrições de um ou mais diferentes recursos;
13.3.3.8. As regras de alocação automática baseadas em prioridades devem
verificar a consistência das alocações realizadas manualmente,
disponibilizando uma lista de eventuais conflitos e gerando
sugestões de alocações que poderão ser aceitas parcial ou
totalmente;
13.3.3.9. As regras de alocação automática baseadas em restrições devem
verificar a consistência das alocações realizadas manualmente,
disponibilizando uma lista de eventuais conflitos e gerando
sugestões de alocações com as restrições aplicadas, obrigando a
escolha de uma das sugestões;
13.3.3.10. O sistema deve ser capaz de fazer a alocação automática para
qualquer período, abrangendo todos os recursos ou de um
subconjunto deles;
13.3.3.11. As restrições de recursos devem determinar se os voos podem ser
alocados para um determinado recurso, devendo incluir no
mínimo os seguintes itens:
13.3.3.11.1. Capacidade física dos recursos;
13.3.3.11.2. Por classe de voo
(doméstico/internacional/regional);
13.3.3.11.3. Por natureza de voos (passageiro/carga);
Aquisição SIGA Página 25 de 40
13.3.3.11.4. Por categoria de voo (regular/militar/aviação
geral/táxi aéreo);
13.3.3.11.5. Por origens e destinos específicos;
13.3.3.11.6. Ocupação de recursos adjacentes (ponta de asa);
13.3.3.11.7. Impedimento operacional;
13.3.3.12. As prioridades para alocação dos recursos devem incluir no
mínimo os seguintes itens:
13.3.3.12.1. Por companhias aéreas;
13.3.3.12.2. Por tipo de evento e situações especiais
(portadores com necessidades especiais);
13.3.3.12.3. Por voos específicos;
13.3.3.12.4. Por origens e destinos específicos;
13.3.3.13. A otimização deve levar em conta a capacidade máxima de cada
recurso aeroportuário, bem como ter por base parâmetros
operacionais configuráveis que utilize de forma balanceada os
recursos;
13.3.4. Formas de Visualização das Alocações dos Recursos:
13.3.4.1. Gráfico de Gantt
13.3.4.1.1. O Gráfico de Gantt deve ser a visão principal a ser
fornecido para todos os módulos de alocação de
recursos, representando a sua ocupação na linha do
tempo;
13.3.4.1.2. As alocações devem ser representadas por barras
horizontais e permitir o acesso à identificação do
voo que estiver ocupando o recurso;
13.3.4.1.3. Deve permitir representar a alocação por grupos de
recursos;
13.3.4.1.4. O tipo de voo deve ser destacado na barra do
Gráfico de Gantt: partidas, chegadas, reboques e
voos em trânsito;
13.3.4.1.5. As telas do Diagrama de Gantt representando cada
recurso (portões, posições de estacionamento,
esteiras, etc), devem mostrar todas as horas do dia
ou, através de um zoom, um período menor; As
informações deverão ser facilmente manipuláveis
pelo operador;
13.3.4.1.6. Os comprimentos de cada barra devem ser
determinados pelo período de tempo da alocação,
representar um recurso e utilizar a codificação de
cores para diferenciar o estado do recurso;
13.3.4.1.7. O Diagrama de Gantt deve conter área de
mensagem operacional do sistema;
Aquisição SIGA Página 26 de 40
13.3.4.1.8. Deve ser utilizado tanto para o planejamento
futuro como para em tempo real;
13.3.4.1.9. Em tempo real, a visualização deve mostrar todas
as alocações atuais;
13.3.4.1.10. O tempo deve ser representado na horizontal,
contendo a linha de tempo real na vertical, de
forma que os recursos alocados se movimentem
dinamicamente;
13.3.4.1.11. As facilidades de arrastar e soltar para alterações e
ajustes das alocações de recursos devem ser usados
para suporte na intervenção manual;
13.3.4.1.12. O período de tempo deve ser configurável no
mínimo de 15 em 15 minutos;
13.3.4.1.13. A identificação dos recursos deve ser mostrada na
vertical;
13.3.4.1.14. Em tempo real, o intervalo de tempo deve abranger
pelo menos o dia anterior, o dia atual e pelo menos
os próximos dois dias;
13.3.4.1.15. A visualização deve mostrar todos os voos com
recursos alocados e também todos os voos que, no
momento, não há alocação;
13.3.4.1.16. As informações principais para a identificação do
voo devem ser obrigatoriamente exibidas, podendo
ser configuradas a critério do operador;
13.3.4.1.17. Os dados adicionais de voo devem ser fornecidos
em janelas separadas;
13.3.4.1.18. O uso da cor nas barras de representação dos
recursos deve ser aplicado para indicar o seguinte
(se aplicável):
13.3.4.1.18.1. Confirmação da alocação / Não
confirmação da alocação;
13.3.4.1.18.2. Conflitos;
13.3.4.1.18.3. Voos cancelados;
13.3.4.1.18.4. Tipo de aeronave;
13.3.4.1.18.5. Companhia aérea;
13.3.4.1.19. O sistema deve permitir a impressão dos gráficos
de Gantt por períodos pré-definidos. O formato de
impressão deve ser configurável e ainda permitir
gerar arquivos em formato de imagem (PDF, GIF,
JPG, PNG e outros);
13.3.4.2. Exibições Aéreas
13.3.4.2.1. O sistema deve fornecer visão aérea das alocações
Aquisição SIGA Página 27 de 40
para todos os recursos em diferentes áreas do
aeroporto;
13.3.4.2.2. Os pontos de visão não precisam estar em escala,
mas deve estar disponível para todos os recursos;
13.3.4.2.3. A visão deve ser atualizada em um intervalo
configurável de no mínimo um minuto;
13.3.4.2.4. A visão deve mostrar todas as alocações correntes
e, por controle do cursor, os dados sobre o voo
atual deve ser exibido;
13.3.4.3. Janelas Adicionais
13.3.4.3.1. Em conjunto com o Gráfico de Gantt, o sistema
deve fornecer aos operadores, janelas específicas
para informar:
13.3.4.3.1.1. Conflitos atuais não resolvidos;
13.3.4.3.1.2. Todas as mudanças recentes de
alocação;
13.3.4.3.1.3. Recursos não alocados;
13.3.4.3.1.4. Log das ações do operador;
13.3.4.3.1.5. Alarmes atuais;
13.3.4.3.1.6. Voos alternados;
13.3.4.3.1.7. Voos extras;
13.3.4.3.1.8. Voos cancelados.
13.4. REQUISITOS TÉCNICOS
13.4.1. Ambiente multiusuário: o sistema deve operar de forma simultânea para
vários usuários e permitir o cadastro e controle de acessos, mediante senhas
de acesso, com diferentes perfis de usuário por aeroporto, atribuindo
permissões específicas para as funcionalidades do sistema, garantindo a
segurança de acesso de todas as suas operações;
13.4.2. As nomenclaturas e especificações dos campos devem atender aos padrões da
indústria aeroportuária (IATA / ICAO);
13.4.3. Ambiente do sistema deve estar baseado em arquitetura Web, sendo que a
interface gráfica do sistema deverá prover ao usuário meios de acionar
funções através de uso do mouse, touch-screen e teclas de atalho;
13.4.4. O sistema deve estar baseado em janelas;
13.4.5. O sistema deve utilizar um banco de dados relacional;
13.4.6. O sistema deve permitir a importação e exportação de dados gerados pelo
sistema em diversos formatos eletrônicos tais como: PDF, XLS, TXT, XML;
13.4.7. O sistema deve ser capaz de importar e exportar dados de/para outros
sistemas aeroportuários (operacionais, manutenção e financeiro) em tempo
real ou de acordo com a solicitação do usuário.
Aquisição SIGA Página 28 de 40
13.5. PLANEJAMENTO DE DISTRIBUIÇÃO E UTILIZAÇÃO EM TEMPO REAL
13.5.1. Geral
13.5.1.1. O sistema deve funcionar em dois modos básicos para a alocação
de recursos:
13.5.1.1.1. No modo de planejamento, onde o sistema pode
alocar recursos com antecedência ao dia de
operação, acessando o seu respectivo plano de voo
registrado no banco de dados operacionais do
aeroporto (AODB);
13.5.1.1.2. No modo em tempo real, onde o sistema visualiza
e gerencia os recursos no momento da operação do
voo em tempo real;
13.5.1.2. A lista de recursos será mantida no banco de dados operacionais
do aeroporto (AODB). O sistema deverá tomar como base a lista
de recursos registrados e mantidos no AODB;
13.5.2. Modo de Planejamento
13.5.2.1. O sistema deve ser capaz de preparar antecipadamente planos de
alocação para os diferentes recursos com base no plano de voos,
podendo ser construído para qualquer período dentro do
calendário;
13.5.2.2. O sistema deve permitir a gravação de um plano como uma
simulação de alocação de recursos e, em qualquer momento, ser
capaz de transformá-lo para uso efetivo;
13.5.2.3. O Sistema deve permitir que os planejadores alcance no mínimo
os seguintes objetivos básicos:
13.5.2.3.1. Maximizar o uso dos recursos;
13.5.2.3.2. Obter o melhor custo x benefício na alocação dos
recursos;
13.5.2.4. Cada plano deve conter as seguintes informações básicas:
13.5.2.4.1. Número de identificação;
13.5.2.4.2. A lista de recursos utilizados;
13.5.2.4.3. A lista de voos utilizados;
13.5.2.4.4. Identificação do operador;
13.5.2.4.5. A definição do período e critérios utilizados para a
criação do cenário planejado;
13.5.2.5. O sistema deve permitir ao operador criar o plano de alocação,
escolhendo todos os recursos ou grupo dos recursos disponíveis;
13.5.2.6. O sistema deve permitir ao operador criar o plano de alocação,
escolhendo todo ou parte do plano de voo, usando critério de
seleção: terminal, companhia aérea ou outros critérios;
Aquisição SIGA Página 29 de 40
13.5.2.7. O sistema deve permitir ao operador criar o plano de alocação,
escolhendo todo ou parte do conjunto de regras;
13.5.2.8. O sistema deve permitir ao operador criar cenários no modo
"what if";
13.5.2.9. O sistema deve permitir a visualização e o gerenciamento do
plano de alocação pelo Gráfico de Gantt;
13.5.2.10. O sistema deve indicar todos os voos não alocados para o
operador;
13.5.2.11. O sistema deve permitir o ajuste manual do plano através da
função de arrastar e soltar, respeitando o conjunto das regras;
13.5.2.12. O sistema deve considerar o intervalo mínimo de tempo de cada
recurso de acordo com a natureza da operação
(doméstico/internacional, embarque/desembarque, restrições);
13.5.2.13. Prover ferramentas que possibilitem esta configuração;
13.5.2.14. O sistema deve permitir ao operador de tornar qualquer recurso
fora de serviço por um período previsto;
13.5.3. Gestão de Recursos em Tempo Real
13.5.3.1. O sistema de gerenciamento de recursos em tempo real é a
principal ferramenta para o monitoramento dos recursos alocados
a partir das informações atualizadas e registradas no AODB;
13.5.3.2. O sistema deve prover as seguintes facilidades:
13.5.3.2.1. Geração automática do plano de alocação para o
dia corrente a partir do planejamento anteriormente
construído;
13.5.3.2.2. Na geração do plano de alocação do dia corrente, o
sistema deve verificar de forma automática as
mudanças no plano de voo do dia corrente e
apontar as discrepâncias para o operador;
13.5.3.2.3. Durante a operação do plano de alocação do dia
corrente, o sistema deve verificar e indicar em
tempo real e de forma automática as informações
registradas no AODB, tais como:
13.5.3.2.3.1. As atualizações dos voos em
operação;
13.5.3.2.3.2. As inoperâncias de qualquer
recurso;
13.5.3.2.4. O gráfico de Gantt deve ser atualizado
continuamente;
13.5.3.2.5. O sistema deve receber atualizações do AODB e
exibir todos os dados relevantes;
13.5.3.2.6. O sistema deve apresentar ao operador a lista dos
conflitos que podem acontecer;
Aquisição SIGA Página 30 de 40
13.5.3.2.7. O sistema deve sugerir mudanças no plano de
alocação para correção de conflitos que estarão
sujeitas à aprovação do operador;
13.5.3.2.8. Todas as atualizações na operação do plano de
alocação devem ser registradas no RMS e
repassadas para o AODB.
13.6. INTERFACE COM O BANCO DE DADOS OPERACIONAIS DO AEROPORTO
(AODB)
13.6.1. O RMS deve interagir com o AODB através das tecnologias disponíveis
(barramento, banco de dados, serviços e XML) para sincronizar os bancos de
dados;
13.6.2. O RMS e o AODB devem interagir, no mínimo, como segue:
13.6.2.1. O RMS deve se basear no plano de voo registrado no AODB;
13.6.2.2. O RMS deve se basear na configuração dos recursos
aeroportuários registrados no AODB;
13.6.2.3. O RMS deve registrar todos os resultados da aplicação do plano
de alocação no AODB;
13.6.2.4. O AODB deve transferir as informações atualizadas dos voos
para o RMS em tempo real (por exemplo: alocação manual,
movimentação de pátio, alterações de voo, quantidade de
passageiros e outros);
13.6.3. Permitir que os tipos de dados a serem transferidos em tempo real e de forma
geral contenham as seguintes informações (mas não se limitam a):
13.6.3.1. Os horários de voo (previstos, confirmados e efetivados);
13.6.3.2. Os cancelamentos, inclusões e alterações de voos;
13.6.3.3. As inclusões, alterações e indisponibilidade dos recursos
aeroportuários;
13.6.3.4. Recursos alocados;
13.6.4. Garantir a integridade das bases de dados do RMS e do AODB tanto na
operação em tempo real quanto na recuperação de falhas de comunicação e
outros.
13.7. MÓDULO DE REGISTRO (LOG)
13.7.1. O sistema deve registrar e manter o histórico do LOG de segurança de todas
as suas operações tanto automáticas como manuais para a alocação de
recursos;
13.7.2. O registro de segurança deve conter, no mínimo, as seguintes informações:
ID do usuário, data e hora da operação, controle do que foi alterado (antes da
alteração e após a alteração), tipo de ação realizada (inclusão, exclusão ou
alteração);
13.7.3. Possuir ferramentas de pesquisas do log e impressão de relatórios com essas
informações.
Aquisição SIGA Página 31 de 40
13.8. MÓDULO DE ESTATÍSTICA
13.8.1. O sistema deve ser capaz de fornecer estatísticas do sistema em termos de
utilização de todos os recursos aeroportuários;
13.8.2. Gerar a utilização do recurso ao longo de um período de tempo;
13.8.3. Gerar a utilização prevista e real;
13.8.4. Gerar o uso por natureza de voos (passageiro / carga);
13.8.5. Gerar o uso por classe de voo (doméstico / internacional / regional);
13.8.6. Gerar o uso por categoria de voo (regular / militar / aviação geral / táxi
aéreo);
13.8.7. Gerar o uso por Companhia Aérea;
13.8.8. Gerar o uso por classe de serviço de atendimento (check-in de passageiros);
13.8.9. Gerar os voos afetados;
13.8.10. Gerar os horários de início / fim do uso do recurso;
13.8.11. Gerar os períodos de interrupção dos recursos;
13.8.12. Gerar os períodos não alocados;
13.8.13. Gerar o percentual de disponibilidade total de cada recurso;
13.8.14. Gerar a utilização total para cada recurso;
13.8.15. Possuir ferramentas para a extração de relatórios configuráveis pelo usuário.
13.9. CONDIÇÕES ESPECIAIS PARA PLANEJAMENTO E OPERAÇÃO DA
ALOCAÇÃO DOS RECURSOS
13.9.1. Posição de Estacionamento e Pontes de Embarque e de Desembarque
13.9.1.1. O plano para alocação do recurso deve se basear no plano de
voos, na configuração do recurso, no plano de regras e nas
preferências definidas no RMS;
13.9.1.2. O sistema deve respeitar a capacidade de cada posição para
alocação do equipamento;
13.9.1.3. O sistema deve ter uma configuração para tratar as restrições de
posições adjacentes com base no seu mix de equipamentos;
13.9.1.4. O sistema deve favorecer a maior fluidez possível no embarque e
desembarque de passageiros;
13.9.1.5. O sistema deve considerar a disponibilidade de recursos móveis
para alocação em posições remotas (operação e estadia);
13.9.1.6. O sistema deve considerar, no mínimo, os critérios de alocação,
tais como:
13.9.1.6.1. Maior número de passageiros em ponte de
embarque/desembarque;
13.9.1.6.2. Preferência pelo maior tamanho de aeronave;
13.9.1.6.3. Preferência por voo internacional;
Aquisição SIGA Página 32 de 40
13.9.1.6.4. Preferência por voos no horário;
13.9.1.6.5. Preferência por voos na seguinte ordem: regulares,
não regulares, alternados e outros;
13.9.1.6.6. Preferência por voos na seguinte ordem: trânsito,
origem e destino;
13.9.2. Portão e Salas de Embarque e de Desembarque
13.9.2.1. O plano para alocação do recurso deve se basear no plano de
voos, na configuração do recurso, no plano de regras e nas
preferências definidas no RMS;
13.9.2.2. O sistema deve evitar o cruzamento do fluxo de passageiros nos
corredores de embarque e de desembarque (contra fluxo);
13.9.2.3. O sistema deve separar os portões e salas pela classe do voo,
evitando mistura de passageiros domésticos e internacionais;
13.9.2.4. O sistema deve, obrigatoriamente, direcionar o fluxo de
passageiros internacionais para as áreas de imigração/emigração.
13.9.3. Esteira de Bagagem
13.9.3.1. O plano para alocação do recurso deve se basear no plano de
voos, na configuração do recurso, no plano de regras e nas
preferências definidas no RMS;
13.9.3.2. O sistema deve separar as esteiras de bagagem pela classe do voo,
evitando mistura de passageiros domésticos e internacionais;
13.9.3.3. O sistema deve, obrigatoriamente, direcionar o fluxo de
passageiros internacionais para as áreas de imigração/emigração;
13.9.3.4. O sistema deve considerar a capacidade máxima de carga do
recurso.
13.9.4. Balcão de Check-in
13.9.4.1. O plano para alocação do recurso deve se basear no plano de
voos, na configuração do recurso, no plano de regras e nas
preferências definidas no RMS;
13.9.4.2. O sistema deve considerar as preferências de alocação definidas
pelas companhias aéreas para os balcões de uso dedicado;
13.9.4.3. O sistema deve permitir a alocação do balcão de acordo com a
solicitação da companhia aérea em tempo de operação.
13.9.5. Recursos Móveis
13.9.5.1. O plano para alocação do recurso deve se basear no plano de
voos, na configuração do recurso, no plano de regras e nas
preferências definidas no RMS;
13.9.5.2. O sistema deve considerar a capacidade de atendimento dos
recursos móveis, porém, se existir alguma indisponibilidade,
permitir que seja configurado se haverá restrição ou não da
alocação dos recursos fixos (posição, ponte, portão, etc);
Aquisição SIGA Página 33 de 40
13.9.5.3. O sistema deve considerar como móveis, os seguintes recursos:
13.9.5.3.1. Ônibus;
13.9.5.3.2. Escadas de embarque/desembarque;
13.9.5.3.3. Tratores (push back, bagagem, loader, ambulift,
outros);
13.9.5.3.4. Handling (comissaria, higienização, limpeza,
outros).
14. GESTÃO DE ALERTAS E NOTIFICAÇÕES
14.1. REQUISITOS GERAIS
14.1.1. Ser baseado em produto padrão de mercado que deverá permitir gerenciar as
ocorrências de forma integrada em tempo real e multicanal;
14.1.2. Ajudar no esclarecimento rápido e seguro da funcionalidade básica requerida,
facilitar a escalabilidade e a evolução do produto padronizado, tanto em
número de usuários como em alcance funcional nas futuras fases, e reportar
economias na manutenção do software;
14.1.3. Partir da base de um modelo de processos de gestão de ocorrências em tempo
real, já definido, onde unicamente se ajustarão os dados mestres e as listas de
valores necessárias para a adaptação do sistema ao ambiente dos 6 (seis)
centros da INFRAERO;
14.1.4. Permitir que o sistema de gestão de ocorrências:
14.1.4.1. Realize a análise, coordenação, verificação, e supervisão de
informações diversas em tempo real, em forma ocorrências e seus
processos associados;
14.1.4.2. Comunique, de forma unificada e homogênea, a seus
usuários/clientes e aos agentes externos;
14.1.4.3. Promova a melhoria contínua da qualidade do serviço prestado
aos usuários/clientes;
14.1.4.4. Integre os Planos de Contingência (Plano de Emergência, Plano
de Autoproteção, entre outros);
14.1.4.5. Ofereça cobertura global 24 x 365;
14.1.4.6. Previna a repetição de ocorrências;
14.1.4.7. Reduza o impacto das ocorrências;
14.1.4.8. Melhore a qualidade do serviço prestado;
14.1.4.9. Exerça uma gestão diferenciada de ocorrências, segundo
circunstâncias;
14.1.5. Oferecer um modelo de gestão para cobrir as necessidades básicas de gestão
da organização aeroportuária responsável pela manutenção das instalações e,
deverá servir ao intercâmbio de informação necessária para a integração com
outras unidades do aeroporto, orientado ao objetivo comum de produção do
Aquisição SIGA Página 34 de 40
próprio aeroporto;
14.1.6. Incluir o planejamento, o desenvolvimento, a integração e a implantação das
interfaces indicadas;
14.1.7. Cobrir algumas necessidades concretas da organização relativas a:
14.1.7.1. Necessidade de estar continuamente preparada para atender
ocorrências que se produzem em momentos inesperados e
aleatórios;
14.1.7.2. Ser dotado de uma capacidade de reação coordenada em situações
onde a informação seja recebida de maneira desordenada e
incompleta;
14.1.7.3. Necessidade de dar respostas altamente eficazes, para desativar
situações altamente críticas;
14.1.7.4. Desenvolver um processo de negócio com eficácia comprovada,
que será executado em um centro capaz de responder em tempo
hábil e sob coordenação eficiente;
14.1.8. Permitir que o modelo atenda as seguintes necessidades:
14.1.8.1. Tratar de forma diferenciada os diversos tipos de ocorrência;
14.1.8.2. Informar (listas estáticas) as ocorrências;
14.1.8.3. Distribuir de forma seletiva a informação a receptores internos e
externos;
14.1.8.4. Realimentar os Comitês de Segurança e Prevenção.
14.1.9. Considerar, por suas próprias especificações, dois modelos:
14.1.9.1. Modelo do Centro de Gestão da Rede de Aeroportuária da
INFRAERO;
14.1.9.2. Modelo de Centro de Gestão Aeroportuária, que deverá ser
definido em um aeroporto e replicado em outro, com os mesmos
processos e obviamente adaptando os dados mestres e listas de
valores.
14.1.10. Permitir que o produto de software que dê suporte à gestão de ocorrências
tenha sido objeto de, ao menos, uma implantação referencial, nos últimos três
anos, em um aeroporto internacional (no Brasil ou no Exterior);
OBS.: Entende-se por referencial o fato de, o mesmo, estar em produção
durante um mínimo de um ano;
14.1.11. Permitir que o produto padrão se alimente de informação gerada em seu
lugar de origem, mediante dados em tempo real introduzidos manualmente, e
outras fontes externas;
14.1.12. Permitir que o produto padrão gerencie a informação de forma centralizada,
permitindo a administração das relações com usuários/clientes de forma
eficiente;
14.1.13. Permitir que o produto padrão contenha um único repositório de informação
[Base de Dados (BD) única], com independência do número e natureza dos
canais de comunicações existentes;
Aquisição SIGA Página 35 de 40
14.1.14. Permitir a incorporação de novos canais, mantendo a configuração e a
estrutura iniciais;
14.1.15. Permitir que o tratamento das ocorrências seja único e homogêneo, com
independência do canal de comunicação utilizado;
14.1.16. Permitir que os canais de acesso direto à aplicação sejam páginas HTML
sobre canal web e correio eletrônico;
14.1.17. Permitir que a interface de usuário e a documentação do sistema de gestão de
Alertas e Notificações sejam entregues em português. No entanto, o produto
padrão será multilíngue e deverá estar disponível também em inglês;
14.1.18. Permitir que a interface de usuário seja intuitiva e com uma arquitetura
técnica que permita acessos com ótimos tempos de resposta;
14.1.19. Permitir que o usuário tenha disponível uma lista que mostre a informação
das interações (de entrada e saída) e suas tarefas pendentes, e que ajude a
coordenação entre os diferentes usuários;
14.1.20. Permitir que o produto padrão ofereça uma ótima capacidade de visualização,
com o máximo possível de informação em uma mesma tela, mantendo
critérios de usabilidade e rendimento (tempos de resposta, número reduzido
de cliques de mouse);
14.1.21. Permitir a criação de guias pelo usuário, sem programação, que orientem o
agente na resolução de ocorrências com base em um guia de perguntas e de
acordo com a tipificação da ocorrência;
14.1.22. Oferecer, sem programação, a possibilidade de busca de ocorrências em
tempo real por diferentes critérios, tais como: identificador, usuário/cliente,
origem, estado, tipo de solicitação, prioridade, usuário, agente que a criou ou
que a processa;
14.1.23. Oferecer a possibilidade de exportar a informação de listas estáticas a
distintos formatos de microinformática: Excel, Access, Word, Acrobat, etc;
14.1.24. Oferecer a possibilidade de armazenar a documentação em diversos formatos
de microinformática: Excel, Access, Word, Acrobat, etc., como arquivos
anexados;
14.1.25. Permitir a definição, sem programação, de quais campos deverão ser de
complementação obrigatória em cada tela e quais campos deverão ser
somente de visualização, em função do perfil do usuário;
14.1.26. Dispor de uma ajuda contextual em todas as telas. Assim mesmo, irá conter
guias de utilização personalizadas e adaptadas à INFRAERO para as
transações relevantes;
14.1.27. Disponibilizar aos usuários uma barra de difusão de mensagens em tempo
real, com personalização dos destinatários em função da categoria;
14.1.28. Permitir que todo usuário tenha acesso ao sistema, mediante código de acesso
de usuário e senha pessoal;
14.1.29. Permitir a definição, sem programação, dos perfis de acesso de cada usuário
que delimitem as operações autorizadas (consulta, alteração, criação, erro,
etc.);
Aquisição SIGA Página 36 de 40
14.1.30. Conter um registro de auditoria para manter aparente qualquer modificação
relevante realizada;
14.1.31. Permitir que em cada registro de auditoria seja armazenado o conteúdo
antigo, o conteúdo novo, a ação realizada (criação, alteração, erro), o registro
de dia e hora da ação e o usuário autor da mesma;
14.1.32. Permitir definir quais perfis de usuários poderão ter acesso à consulta de
registros de log;
14.1.33. Permitir a definição dos campos relevantes suscetíveis ao registro de
auditoria.
14.1.34. Contar com um modelo de dados pré-definido para o funcionamento básico,
com os objetos de dados mestres: usuários/clientes, contatos, inventário de
produtos/equipamentos;
14.1.35. Permitir a definição e validação das tipificações de ocorrências, de
categorizações por estados, subestados e grau de prioridade;
14.1.36. Permitir a definição das transições entre estados;
14.1.37. Permitir a definição de grau de urgência e de severidade, tipos de atuações,
localizações, unidades organizativas e usuários;
14.1.38. Permitir o registro, manual ou de forma automática, através das interfaces,
tanto de sua ocorrência como de sua verificação, para uma análise posterior
das ocorrências em tempo real;
14.1.39. Permitir que o registro da ocorrência seja único, com estrutura normalizada,
para facilitar seu tratamento, independentemente do canal por onde foi
criado;
14.1.40. Permitir, em função das autorizações dos usuários, a criação e a alteração de
uma ocorrência ou solicitação de serviço;
14.1.41. Receber informação de ocorrências através de canais e usuários autorizados;
14.1.42. Permitir que o sistema valide a informação recebida, de acordo com os
seguintes dados: dependência ou Agente originador, nível de
comprometimento, tipo de Ocorrência, Subsistema/Sistema/Serviço afetado,
data/hora de início, nome/telefone do comunicante e descrição breve da
ocorrência;
14.1.43. Permitir que sejam feitas validações nas tabelas;
14.1.44. Permitir que em cada recebimento de uma ocorrência perfeitamente
identificada, seja:
14.1.44.1. Armazenado automaticamente em um repositório único,
centralizado, todas as ocorrências criadas;
14.1.44.2. Apresentada nas posições configuradas através de alarmes
associados;
14.1.44.3. Notificado a usuários especiais, se for predefinido;
14.1.44.4. Gerado um número identificador único, como código de acesso
para facilitar sua posterior identificação e verificação;
14.1.45. Registrar, no mínimo, as seguintes informações:
Aquisição SIGA Página 37 de 40
14.1.45.1. Cliente ou origem;
14.1.45.2. Tipo ou categoria de Ocorrência;
14.1.45.3. Sistema, Serviço ou Equipamento afetado;
14.1.45.4. Data/Hora de início;
14.1.45.5. Nome/Telefone do comunicante;
14.1.45.6. Breve descrição da ocorrência e de todas as anotações oportunas
relacionadas ao tratamento da ocorrência: testes, alarmes,
comentários, etc. (em texto livre);
14.1.45.7. Contextualização do sucesso (isto é, incorporação de toda a
informação para facilitar a compreensão de sua magnitude), sua
localização, seu impacto (em texto livre);
14.1.45.8. Documentos anexos de qualquer tipo (documentos Word, fotos,
planos, vídeo, som, etc.).
14.1.46. Permitir que seja incorporadas as seguintes informações, no momento da
recepção:
14.1.46.1. Atribuição ao responsável pela coordenação e área funcional ou
departamentos oportunos;
14.1.46.2. Data/Hora de fechamento previsto;
14.1.46.3. Grau de prioridade e severidade;
14.1.46.4. Medidas adotadas;
14.1.46.5. Valoração do impacto.
14.1.47. Validar toda a informação acima indicada nas tabelas (listas de valores ou
dados mestres do produto padrão);
14.1.48. Existir processos de gestão de ocorrências carentes de informação e de
priorização;
14.1.49. Ser valorizado o fato de o processo de registro da ocorrência ou solicitação
ser o mais simples possível e que utilize o mínimo de telas;
14.1.50. Permitir o registro e a gerência, adequados à informação recolhida através de
qualquer contato com o usuário/cliente;
14.1.51. Permitir, em função da configuração, registrar e gerenciar uma reclamação a
uma ocorrência ou solicitação que já tenha sido criada, assim como, alterar
ou acrescentar informação a uma ocorrência ou solicitação já existente;
14.1.52. Permitir a classificação das ocorrências pelo nível de comprometimento;
14.1.53. Permitir agilidade no tratamento, diagnóstico e solução da ocorrência ou
solicitação de serviço, para sua resolução o mais breve possível;
14.1.54. Permitir que as ocorrências sejam atribuídas, por conseguinte, à pessoa que as
criou, sendo possível submetê-las manualmente. Permitir que as ocorrências
e as suas ações dependentes tenham um agente responsável por sua resolução
e seu acompanhamento;
14.1.55. Ser associadas às ocorrências, todas aquelas atividades e contatos realizados
com o usuário/cliente necessários para chegar à correta resolução das
Aquisição SIGA Página 38 de 40
mesmas;
14.1.56. Para garantir o sucesso e a rapidez da resolução, permitir que o produto
padrão contenha integração com uma base de dados de respostas e soluções
que facilitem a obtenção do diagnóstico adequado;
14.1.57. Permitir aos usuários autorizados o acesso direto aos dados necessários para
tratar uma ocorrência, segundo seu papel, permitindo busca no histórico
segundo critérios e autorizações;
14.1.58. Permitir acesso direto para consultar um conjunto de ocorrências anteriores
de um determinado usuário/cliente
14.1.59. Permitir o gerenciamento de filas de trabalho;
14.1.60. Permitir a estruturação e planejamento de atividades;
14.1.61. Permitir a criação manual de uma atividade ou de um grupo de atividades
para dar seguimento à atividade registrada ou à atividade planejada;
14.1.62. Permitir a criação de atividades internas para o usuário/cliente;
14.1.63. Permitir que em todas as atividades apareça um campo de descrição onde
deverá ser permitido descrever a finalidade desta atividade;
14.1.64. Permitir a reatribuição da solicitação à outra área funcional do aeroporto, a
outro responsável superior ou ao executivo de serviço;
14.1.65. Permitir, em função das autorizações aos usuários, a alteração de uma
ocorrência ou solicitação de serviço ou a inclusão de informação adicional
por parte do usuário/cliente;
14.1.66. Permitir a classificação das ocorrências de acordo com diferentes parâmetros;
14.1.67. Comunicar ao usuário/cliente sua resolução e disponibilizar informação da
ocorrência a todo o momento, uma vez resolvida à ocorrência. Também,
permitir consultar o processo de resolução através dos diferentes canais de
acesso, assim como o histórico de ocorrências por usuário/cliente;
14.1.68. Permitir o registro da solução aplicada;
14.1.69. Permitir que o sistema de Alertas e Notificações seja integrado com o sistema
de tempo real nos processos a serem mapeados;
14.1.70. Permitir que o produto padrão seja integrado com o servidor de correio
eletrônico, mediante um conector padrão para o envio e a recepção de
mensagens eletrônicas;
14.1.71. Permitir que o sistema de Alertas e Notificações seja integrado a um sistema
de gestão de documentos, mediante ambientes HTTP ou hiperlink;
14.1.72. Permitir que o sistema de Alertas e Notificações seja integrado ao sistema de
gestão de manutenção para alta/alteração/fechamento de ocorrências e
comunicações de mudança de estado;
14.1.73. Permitir que o sistema de Alertas e Notificações do Centro de Gestão da
Rede de Aeroportos da INFRAERO seja integrado com os sistemas de gestão
de ocorrências dos Centros de Gestão Aeroportuárias;
14.1.74. Permitir integrações com outros sistemas, mediante serviços web;
Aquisição SIGA Página 39 de 40
14.1.75. Conter conectores pré-fabricados para a integração com outros sistemas. Será
desejável a existência de conectores e interfaces já desenvolvidos para
integrações similares entre sistemas de igual tecnologia;
14.1.76. Mediante ação manual, permitir que as ocorrências incluídas estejam
disponíveis a todos os usuários que serão informados, mediante mensagens
de correio eletrônico, publicação na barra de mensagens do produto padrão
ou aviso na intranet;
14.1.77. Permitir, a partir de critérios estabelecidos e configuráveis, filtrar as
notificações de ocorrências a grupos de usuários;
14.1.78. Conter listas estáticas pré-definidas;
14.1.79. Permitir que os usuários com perfis adequados contenham listas estáticas, que
representem a informação de interesse para cada uma das áreas de sua
responsabilidade;
14.1.80. Permitir que os usuários tenham acesso às suas listas estáticas segundo seus
perfis e independentemente de sua localização física;
14.1.81. Permitir que as listas fixas incorporem gráficos que reflitam a informação
histórica e em tempo real;
14.1.82. Fornecer ferramentas de consulta, impressão e exportação a ferramentas de
microinformática, tanto da informação recebida e quanto da informação
processada para cada tipo de informação;
14.1.83. Permitir o filtro da informação apresentada nas listas;
14.1.84. Imprimir todas as janelas de apresentação de informação;
14.1.85. Realizar consultas sobre o estado de cada ocorrência, na Intranet da
INFRAERO ou através da web;
14.1.86. Enviar as listas estáticas, por correio eletrônico, aos responsáveis
interessados;
14.1.87. Permitir que os usuários possam definir suas próprias listas estáticas;
14.1.88. Permitir que a arquitetura do produto padrão siga um modelo de camadas;
14.1.89. Permitir que cada camada de software realize um diferente nível de abstração
e isole as diferentes camadas de software entre si;
14.1.90. Permitir que o produto padrão esteja baseado nos princípios de um software
aberto e deverá implementar algumas especificações suficientemente abertas
para as interfaces, serviços e formato de dados;
14.1.91. Características principais do software de gestão de ocorrências:
14.1.91.1. Portabilidade: Permitir que o produto padrão possa,
eventualmente, ser mudado de arquitetura tecnológica (base de
dados, sistema operacional, servidor web) sem que seja obrigado
a passar por uma redefinição funcional dos processos de negócio
já implementados;
14.1.91.2. Interoperabilidade: Permitir que o produto padrão tenha a
capacidade para ser integrado segundo os padrões atuais de
integração (serviços web, SOAP, UDDI, XML, CORBA, COM,
Aquisição SIGA Página 40 de 40
conectores J2EE, JCA) com os demais sistemas;
14.1.91.3. Escalabilidade: Permitir um crescimento em número de usuários,
número e natureza de canais e abrangência funcional, sem que
seja obrigado passar por uma reinstalação do produto padrão;
14.1.91.4. Modularidade: Permitir a implementação, de forma progressiva,
nos módulos necessários;
14.1.91.5. Integração: Conter um único repositório de informação, ao qual
seja disponibilizado acesso a todas as funcionalidades. Este
repositório de informação deverá ser atualizado em tempo real;
14.1.91.6. Configurabilidade: Ser suscetível à alteração em seu
funcionamento e definições em um ambiente declarativo, sem
necessidade de programação;
14.1.91.7. Evolutividade: Assegurar a evolução do produto mediante a
liberação de novas versões e a manutenção corretiva, frente a
erros de programa, tudo incluído dentro do conceito de
manutenção do fabricante.