1. conectores -...

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;


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.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


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.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.


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.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.


4. BARRAMENTO DE INTEGRAÇÃ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.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


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);


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


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


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


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.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.


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.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);


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.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.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.


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.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


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


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.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


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;


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


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;


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


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;


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


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


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;


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;


restrições para cada tipo de recurso a ser alocado;


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);


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;


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


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.


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;


escolhendo todo ou parte do plano de voo, usando critério de

seleção: terminal, companhia aérea ou outros critérios;



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;


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.


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;


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.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.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.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.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);


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


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;


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.);


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:


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


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;


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,


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.

1. conectores -...

Documents