1. Objeto e Descritivo Geral

1.1. Fornecimento de sistema informatizado para Central de Monitoramento de

atividades e eventos diversos, compreendendo os seguintes componentes:

Sistema de Central de Monitoramento; Sistema de Integração de Telefonia;

Sistema de Análise de Conteúdo de Vídeo; Ambiente de Desenvolvimento,

Homologação e Treinamento; Serviços de Consultoria; Serviços de

Treinamento e Transferência de Tecnologia; Serviços de Suporte e

Manutenção.

1.2. O Sistema de Central Monitoramento deverá dar suporte operacional e

estratégico ao monitoramento de ocorrências imprevistas ou planejadas até a

sua conclusão, por meio de workflows associados a procedimentos de

resposta; de análise estratégica de dados associados; e pela gestão de ativos e

de pessoal, possibilitando:

1.2.1. Visualização e Monitoramento de ocorrências;

1.2.2. Cadastro e Monitoramento dos Procedimentos de Resposta;

1.2.3. Geração de Alertas, Mensagens;

1.2.4. Intercâmbio de informações;

1.2.5. Integração com sensores, câmeras de vídeo e outras fontes de dados;

1.2.6. Monitoramento e endereçamento de mídias sociais;

1.2.7. Gestão de ativos e pessoal.

1.3. Deve suportar qualquer número de estações de operação cliente, limitado

apenas pelo hardware e pela largura de banda de comunicação.

1.4. Deve ser multi tenant, possibilitando o trabalho em conjunto de múltiplos

órgãos e permitindo hierarquização de centrais rodando sistema idêntico ou

integração com sistemas similares. Permitindo ainda a implantação dos

seguintes ambientes operacionais, localizados fisicamente nos limites

geográficos do Município de São Paulo:

1.4.1. Desenvolvimento;

1.4.2. Homologação;

1.4.3. Produção I;

1.4.4. Produção II (contingência, em load balance e failover);

1.4.5. Treinamento.

1.5. O Sistema de Central de Monitoramento subdivide-se em:

1.5.1. Módulo de Ocorrências

1.5.2. Módulo de Procedimentos Operacionais de Resposta;

1.5.3. Módulo de Atendimento e Despacho;

1.5.4. Módulo de Georeferenciamento;

1.5.5. Módulo de Visualização;

1.5.6. Módulo de Alarmes e Avisos;

1.5.7. Módulo de Estatísticas e Relatórios;

1.5.8. Módulo de Framework Web;

1.5.9. Módulo de Integração de Sistemas e Sensores;

1.5.10. Módulo de Mídias;

1.5.11. Módulo de Controle de Acesso;

1.5.12. Módulo de Vídeo Monitoramento;

1.5.13. Módulo de Auditoria e Logs;

1.5.14. Módulo de Backup e Versionamento

1.6. Os sistemas que constituem o objeto devem ser capazes de trabalhar de

forma redundante, em alta disponibilidade e em arquitetura tolerante a

falhas.

1.6.1. Em particular, deve ser possível a operação simultânea em modos load

balance e fail over com outro sistema idêntico de Central de Monitoramento,

permitindo a troca de uma central por outra em caso de falha de uma das

centrais.

1.7. Os sistemas e módulos devem ser escaláveis na horizontal (adição de novos

servidores e infraestrutura de hardware) e na vertical (aumento da

capacidade de processamento) para atender a uma demanda crescente.

1.8. Os sistemas devem ser instalados de forma a serem acessados em ambiente

centralizado web, nos servidores IIS ou Apache.

1.9. Todas as interfaces homem-máquina devem ser disponibilizadas na Língua

Portuguesa.

1.10. Os módulos devem possuir padrão homogêneo de interface gráfica em todos

os seus constituintes acessados via web.

1.11. O Sistema de Central de Monitoramento deve apresentar uma interface

customizável ao usuário, baseado num mapa geográfico do município, sobre

os quais são visualizados os eventos de interesse em tempo próximo ao real.

1.12. Cada sistema individual funciona como entidade autônoma e independente,

mas operando em conjunto integrado com os demais sistemas e módulos que

compõem a Central Integrada de Monitoramento.

1.13. Os sistemas devem ser compatíveis com servidores padrão x86 de 64bits,

devendo ser capazes de rodar em ambientes:

1.13.1. Microsoft Windows Server ou RedHat Linux Enterprise Server ou ou

CentOS em suas versões correntes.

1.13.2. Para armazenamento das informações referentes aos sistemas, deve ser

possível o uso de pelo menos um dos seguintes Sistemas Gerenciadores de

Banco de Dados, em suas versões mais correntes:

1.13.2.1. SQL Server

1.13.2.2. DB2

1.13.2.3. PostgreSQL

1.13.2.4. MySQL

1.14. O desenvolvimento de sistemas, módulos, interfaces e software customizado,

necessários à entrega do objeto contratado, será feito, preferencialmente nos

ambientes de programação HTML5, JEE, .NET e PHP, com scripting em

shell sh ou csh, Perl, VBS e BAT (prompt de comando do Windows). Stored

Procedures serão escritas conforme a linguagem SQL utilizada pelo

software de banco de dados.

1.14.1. O desenvolvimento em outras linguagens de programação só será permitido

mediante autorização prévia da CONTRATANTE.

1.15. O sistema deve ser capaz de utilizar banco de dados relacional padrão SQL

para armazenamento de dados, com suporte a objetos espaciais e geográficos

e funções GIS utilizando tais tipos de dados.

1.15.1. O acesso às bases de dados será provido pela CONTRATANTE.

1.15.2. Acesso indireto a bases externas será permitido a partir do Módulo de

Integração de Sistemas e Sensores.

1.16. A CONTRATADA se obriga a entregar toda a documentação pertinente ao

cumprimento dos entregáveis que são alvo desta contratação, incluindo o

projeto detalhado da solução; manuais de instalação, configuração e testes

integrados; documentação de apoio pertinente ao desenvolvimento; atas de

reunião; cronogramas; relatórios técnicos e outros documentos que se

fizerem necessários ou que forem solicitados.

1.17. As licenças fornecidas para a utilização do sistema devem ser definitivas,

com garantia de atualização durante o período de contratação, com cessão de

código-fonte, podendo a CONTRATANTE efetuar, a seu critério, múltiplas

instalações e efetuar alterações no mesmo, a seu critério e julgamento.

1.17.1. A cessão de código-fonte será válida apenas nos casos de scripts (SQL, shell,

web ou similares), onde não forem utilizados código-objeto compilado e

executado diretamente (isto é, sem interpretadores).

1.17.2. Caso sejam utilizadas bibliotecas externas ou de terceiros, a

CONTRATADA se obriga a fornecer até 15 (quinze) licenças necessárias

para a compilação, com a quantidade definida a critério da

CONTRATANTE.

1.18. Gerenciamento do Sistema de Central de Monitoramento

1.18.1. Os sistemas e módulos devem possuir gerenciamento centralizado com

interface web, permitindo a sua configuração e parametrização por um

operador a partir de um browser padrão web.

1.18.1.1. Os browsers suportados pelo sistema são o Microsoft Internet Explorer,

o Mozilla Firefox, o Google Chrome e o Chromium, em ambientes

Microsoft Windows, RedHat Linux Enterprise Server, SUSE Linux, Debian

Linux, Ubuntu e CentOS em suas versões correntes.

1.18.1.2. Os sistemas devem possuir capacidade para monitorar o desempenho, a

utilização de memória, CPU e uso de rede em tempo próximo ao real.

1.18.1.3. Os sistemas devem armazenar os dados relevantes à sua operação e

possuir a capacidade de emitir relatórios de uso de CPU, memória, rede,

tempos de resposta e disponibilidades totais e individuais de cada módulo.

1.18.2. Gerenciamento de falhas

1.18.3. Os sistemas informatizados devem possuir mecanismo de avaliação remota

do seu estado e do consumo de memória e CPU via mensagens e alertas do

tipo syslog e SNMP.

1.18.4. Também deve ser possível, via Módulo de Alarmes e Avisos, o envio de e-

mails e mensagens SMS mediante configuração prévia, dependendo das

características da falha e da sua criticidade.

1.18.4.1. O envio de SMS se dará via webservice de responsabilidade da

CONTRATANTE.

2. Módulo de Ocorrências

2.1. Efetua o cadastro de eventos e ocorrências, possibilitando o cadastro de

eventos esporádicos, agendados, habilitando as suas operações e

procedimentos operacionais de resposta associados.

2.2. O Módulo de Ocorrências deverá permitir a criação de registros de eventos a

serem gerenciados pela Central de Monitoramento, com informações

mínimas que o identifiquem, tais como descrição, localização, tipo e

gravidade do evento, fonte da informação do evento, situação, responsável

por sua resposta, data e hora do evento e outras informações pertinentes.

2.2.1. Estes eventos poderão ser criados automaticamente ou de forma pré-

agendada, através de integrações entre sistemas ou manualmente por um

operador.

2.2.2. Deve possuir inventário de ocorrências integrado, que possibilite o cadastro

de eventos programados, com início e término de eventos, riscos

relacionados, workflow com ações necessárias (via Módulo de

Procedimentos Operacionais de Resposta) e cadastro de recursos associados.

O módulo deve permitir, no mínimo, a inserção dos seguintes atributos:

2.2.2.1.Identificador da ocorrência (descritivo alfanumérico);

2.2.2.2.Nome da ocorrência;

2.2.2.3.Descritivo;

2.2.2.4.Data e hora de início;

2.2.2.5.Data e hora prevista para término;

2.2.2.6.Local da ocorrência;

2.2.2.7.Permitir a inclusão e visualização de arquivos associados de imagens e

vídeos.

2.3. Deve permitir a classificação de ocorrências a um ou mais tipos (ou classes)

previamente cadastrados.

2.4. Deve permitir atribuir valores de prioridade e importância às ocorrências de

forma automática ou manual, através de informações contidas nestes

registros no momento da criação/atualização.

2.5. Deve registrar informações sobre temporização das ocorrências em cada

status disponível no sistema, alimentando o Módulo de Alarmes e Avisos.

2.5.1. Permitir a criação manual de eventos, via formulário específico e

customizável apresentado na tela do operador .

2.5.1.1.Deve ser possível atribuir uma localização geográfica a uma evento das

seguintes formas:

2.5.1.1.1. Localização através de clique de mouse no mapa apresentado na tela do

Módulo de Visualização;

2.5.1.1.2. Entrada direta de latitude e longitude;

2.5.1.1.3. Endereço completo (logradouro e número);

2.5.1.1.4. Entrada direta de ponto de interesse, via cadastro prévio de tais pontos;

2.5.1.1.5. Cruzamento de logradouros;

2.5.1.1.6. Com uma distância pré-definida a partir de um ponto de interesse (por

exemplo: Marginal Tietê, a 500m da Ponte Casa Verde, sentido Ayrton

Senna).

2.5.1.2.Para cada ocorrência, deve ser possível atribuir um raio de interesse, na

forma de um buffer circular de raio definido pelo usuário em torno da

latitude/longitude fornecida pelo próprio usuário ou calculada pelo sistema.

2.5.1.3.

2.5.2. Permitir criação sem intervenção humana de eventos, acionada via Módulo

de Integração de Sistemas e Sensores por outros componentes da solução ou

sistemas externos que enviam dados do evento via serviços tais como web

services ou fila de mensagens.

2.6. Permitir atualização de dados associados do evento, bem como encerramento

do mesmo, gerando registro auditável de tais atualizações..

2.7. Permitir ao operador e demais módulos correlacionar dois eventos com base

na localização (distância entre eventos menor que valor parametrizado) e na

data e hora dos eventos (diferença de data e hora menor que valor

parametrizado).

2.8. Exibir lista de eventos em andamento (não encerrados) em painel de controle

para visualização do usuário;

2.9. Exibir eventos em andamento (não encerrados) no mapa parte do

componente Módulo de Georeferenciamento e exibido na tela do usuário via

Módulo de Visualização.

2.10. Permitir escalada de evento para incidente após análise manual feita pelo

usuário e permitir informar razão da escalada para incidente.

2.11. Deve permitir que cada ocorrência ou unidade possua status e atributos no

sistema, que serão definidos por informações cadastrais e localização no

mapa combinadas com registros realizados durante a vigência da ocorrência.

2.12. Deve permitir que cada ocorrência ou unidade possua um segundo nível de

status, manual ou automático, que indique a situação diferenciada desta

ocorrência.

2.13. Deve permitir que cada ocorrência possua um terceiro nível de status,

distinguindo fases de contatos internos e/ou externos.

2.14. Cada status alertará, via Módulo de Alarmes e Avisos, com prioridade ou

não, um ou mais usuários, identificados no Módulo de Controle de Acesso,

sobre a ação efetuada ou a necessidade de alguma nova ação: pendente,

acionar, acionada, reiterar, reiterada, cancelar, cancelada, consultar,

consultada, guinchado, ignorado, arquivar. Esta ação deverá prever o

cadastro de informações sobre o contato realizado.

2.15. Todas as informações inseridas manualmente deverão permitir que o usuário

realize a leitura no tempo que precisar, antes do primeiro salvamento. Após a

primeira gravação, todos os dados e alterações serão armazenados.

2.16. Deve possuir a capacidade de trabalhar de modo integrado a uma base de

dados cartográfica, via Módulo de Georeferenciamento;

2.17. Deve permitir o cadastro de limites de área para cada serviço, possibilitando

o uso de alarmes a unidades que se encontrarem fora destes limites (“cerca

eletrônica”).

2.18. Deve permitir, a usuários específicos, o registro de ocorrências com datas

retroativas para uso em pós-contingências (dados históricos).

2.19. Um ícone representativo da ocorrência deverá ser exibido no mapa via

Módulo de Visualização.

3. Módulo de Procedimentos Operacionais de Resposta

3.1. O Módulo de Procedimentos Operacionais de Resposta a incidentes deverá

permitir a execução e acompanhamento de procedimentos pré-definidos de

gestão e respostas a eventos que foram escalados para incidente no Módulo

de Ocorrências, através de um fluxo de trabalho com as atividades de

resposta descritas no procedimento pré-definido no cadastramento do

Procedimento Operacional de Resposta Associado.

3.1.1. Estes procedimentos de resposta a incidentes poderão ser criadas

automaticamente, isto é, sem intervenção manual, através de integrações via

Módulo de Integração de Sistemas e Sensores ou manualmente e gerenciadas

através de um painel de controle visual, por meio do Módulo de

Visualização.

3.2. O Módulo de Procedimentos Operacionais de Resposta deverá permitir que o

fluxo de trabalho de resposta a um incidente seja executado por meio de

acionamento pelo usuário; uma vez acionado, o fluxo de trabalho deverá

gerar de forma automática todas as atividades do fluxo de resposta descrito

no procedimento operacional de resposta pré-definido.

3.3. O Módulo de Procedimentos Operacionais de Resposta devepermitir a

criação manual de atividades de resposta pelo usuário, com dados mínimos

tais como descrição, data e hora, data e hora previstas para término e

responsável.

3.3.1. A atividade criada manualmente será direcionada para um outro usuário ou

instituição responsável por sua execução.

3.4. O Módulo de Procedimentos Operacionais de Resposta deverá executar a

atividade de forma automática permitindo estabelecer critérios tais como

condições para execução da atividade, nível de escalada para usuário

responsável e agendamento e programação da atividade entre outros

atributos, desde que previamente configurado.

3.5. O Módulo de Procedimentos Operacionais de Resposta deverá integrar-se ao

Módulo de Alarmes e Avisos para permitir envio de notificação de forma

automática.

3.6. O Módulo de Procedimentos Operacionais de Resposta deve permitir

visualizar a situação, o andamento e o status de cada atividade.

3.7. O Módulo de Procedimentos Operacionais de Resposta deve permitir

atualizar os dados de uma atividade de resposta bem como encerrar uma

atividade de resposta pelo usuário responsável pela execução da atividade

3.8. O Módulo de Procedimentos Operacionais de Resposta deve permitir a

definição precisa de pessoas de contato e processo de escalação.

3.9. O Módulo de Procedimentos Operacionais de Resposta deve possuir a

funcionalidade de registro do status de resolução do alerta e de evidenciar os

alertas pendentes de resolução, via Módulo de Alarmes e Avisos;

3.10. Deve possuir funcionalidade que permita a criação de workflows de forma

gráfica em ambiente web, controlado pelo Módulo de Visualização.

3.11. O cadastro de Procedimentos de Resposta deverá permitir a construção de

Procedimentos Operacionais Padrão monitoráveis, a serem construídos como

workflows com a inserção de:

3.11.1. Procedimentos Padrão de Operação, com a descrição das atividades;

3.11.2. Datas de fim e inicio das atividades;

3.11.3. Status das atividades;

3.11.4. Descrição de recursos a serem empregados nas atividades ;

3.11.5. Procedimentos Padrão de Operação;

3.11.6. Status do recurso, nível de serviço (ex. operante, reparo);

3.11.7. Contato responsável pelo recurso, via Módulo de Controle de Acesso;

3.11.8. Atributos do recurso;

3.11.9. Emails, números de telefones e informações de contatos que notifiquem o

progresso das atividades do workflow, a não execução de atividades ou a

necessidade de entrada manual de dados, via Módulo de Alarmes e Avisos.

3.12. A base de dados gerada pelo controle dos processos deverá estar disponível

para consultas que permitam avaliações da performance das ações

empreendidas, via Módulo de Estatísticas e Relatórios.

3.13. As atividades deverão estar disponíveis para acesso remoto através da web,

de maneira que os atores possam visualizar e interagir com suas respectivas

atividades.

3.14. Deverá ser possível iniciar as atividades / workflows tendo como base um

evento criado de forma manual através da interface ou via integração com

um sistema externo, via Módulo de Integração de Sistemas e Sensores.

3.15. Deverá contar com inventário básico de ativos, devendo integrar-se ao

Módulo de Controle de Ativos para um controle mais amplo e extenso.

3.16. O sistema deve contar com sistema gerenciador do fluxo de trabalho,

considerando a possibilidade de cadastro e gestão dos processos necessários

para o atendimento e acompanhamento de ocorrências.

3.17. Deve possibilitar aos usuários planejadores definir e associar formulários

múltiplos específicos com cada tipo de incidente e procedimentos.

3.18. Deve possuir mecanismo para associar arquivos anexos e associá-los com

tipos de incidente e procedimentos.

4. Módulo de Atendimento e Despacho

4.1. O sistema deverá possuir funcionalidades de atendimento às instituições,

registro, despacho e acompanhamento de ocorrências, considerando as

funcionalidades requisitadas para operações de monitoramento.

4.2. Deverá permitir a classificação das ocorrências atendidas de acordo com os

níveis de criticidade definidos pelo operador ou de forma automática,

permitindo ainda o registro e o acompanhamento das ocorrências em

andamento.

4.3. Deve prover o gerenciamento de chamadas de emergência, tanto no

atendimento da solicitação quanto no despacho de recursos.

4.4. Deve permitir o registro, despacho e acompanhamento de ocorrências

através das interfaces de atendimento e despacho.

4.5. Deve permitir a priorização dos atendimentos relacionados a cada tipo de

ocorrência.

4.6. Deve permitir definição do formato de um identificador alfanumérico que

será automaticamente designada aos registros de ocorrências.

4.7. Deve permitir calcular e registrar o tempo estimado de chegada de uma

unidade de campo até a ocorrência, gerando alertas via Módulo de Alarmes e

Avisos.

4.8. Deve permitir que as ocorrências sejam cadastradas com um código

identificador alfanumérico, possibilitando a correlação entre o identificador

da ocorrência e sua localidade de origem.

4.8.1. O número de caracteres e o formato do identificador deverá ser

customizável.

4.9. Deve permitir trabalhar com os seguintes dados de ocorrências:

4.9.1. Data da geração

4.9.2. Hora da geração;

4.9.3. Localização (endereço, bairro, cidade, estado, complemento);

4.9.4. Tipo da ocorrência;

4.9.5. Pessoas envolvidas (autor, vítima, testemunhas);

4.9.6. Existência de vítimas com necessidades de atendimento médico (quantidade

e breve descrição da gravidade das vítimas);

4.9.7. Identificação de veículos envolvidos (modelo, cor, placa, características

específicas);

4.9.8. Status da ocorrência (em andamento, finalizada, encerrada no local , etc);

4.9.9. Origem do chamado (Canal ou meio utilizado para identificação da

ocorrência);

4.9.10. Responsável pela ocorrência, incluindo nome, posto/graduação/cargo e

organização a que pertence;

4.9.11. Responsável pelo registro da ocorrência no sistema (nome, posto/graduação

ou cargo, instituição a que pertence);

4.9.12. Data do registro;

4.9.13. Horário do registro;

4.9.14. Histórico;

4.9.15. Providências adotadas, incluindo recursos despachados.

4.10. Deve possibilitar o envio simultâneo, via Modulo de Alertas, a todas as

instituições envolvidas, quando da necessidade de múltiplo emprego de

recursos.

4.11. Deve permitir o despacho das ocorrências ao órgão responsável pelo

atendimento, possibilitando o cumprimento das rotinas que exercidas

atualmente, receberá as anotações realizadas pelo atendimento, avaliará a

necessidade de envio de meios e acionará os meios adequados e necessários

para o local da ocorrência.

4.12. Deve permitir a visualização e acompanhamento das ocorrências em

andamento. O sistema deverá permitir o acompanhamento das ocorrências

em andamento por meio de diferentes formas de priorização considerando,

minimamente, sua criticidade, cronologia, região geográfica, organizações

atuantes e tipo. As ações decorrentes das tomadas de decisão também

deverão ser registradas e visualizadas.

4.13. Permitir ao usuário marcar ocorrências como sendo correlacionadas ou

diretamente associadas entre si.

4.14. Possuir mecanismos para permitir a identificação de registro de ocorrências

em duplicidade.

4.15. Possuir mecanismos que possibilitem a classificação manual e automática

das ocorrências conforme critérios e condições pré-definidas, de maneira a

definir quantitativamente a urgência e os impactos estimados.

4.16. Permitir a exibição automática de alertas com informações sobre criticidade

das ocorrências, data, horário e localização nos televisores LCD 16:9 e

monitores de vídeo 16:10 utilizados pela equipe de operações da Central de

Monitoramento, via Módulo de Visualização.

4.17. Possuir interface de monitoração que permita ao operador a realização de

filtros minimamente por status, criticidade, tipo de ocorrência, órgão e

pessoa responsável, data e horário da ocorrência, localização e informações

sobre veículos e pessoas envolvidos.

4.18. Permitir a consulta de informações sobre ocorrências finalizadas.

4.19. Permitir a atualização manual das ocorrências por parte de equipes de campo

4.20. Permitir o direcionamento manual de ações para as diferentes organizações

externas. Estas ações podem estar relacionadas a atividades de

monitoramento remoto, avaliação ou tratamento in loco e encerramento das

ocorrências.

4.21. Permitir o direcionamento automático de ações, de acordo com critérios pré-

definidos para ocorrências com características específicas. Estas ações

podem estar relacionadas ao direcionamento de chamadas telefônicas (via

Sistema de Telefonia) e o envio de mensagens eletrônicas para dispositivos

móveis ou embarcados (via Módulo de Alarmes e Avisos).

4.22. Deve se integrar ao Módulo de Estatísticas e Relatórios para inserir

automaticamente as ocorrências finalizadas nas bases de conhecimento da

Central de Monitoramento.

4.23. Permitir a seleção e direcionamento de ações de ocorrências por meio da

localização no mapa disponível via Módulo de Georeferenciamento e

mostrado no Módulo de Visualização e de ferramentas de

georeferenciamento.

4.24. Deve possibilitar o retorno das ligações das chamadas de ocorrências, via

integração com Sistema de Telefonia, através da interface gráfica.

4.25. Deve permitir o direcionamento automático de ocorrências correlacionadas,

de acordo com requisitos pré-definidos.

5. Módulo de Georeferenciamento

5.1. Módulo de Georreferenciamento deverá prover serviços de apresentação, e

publicaçãopublicação e apresentação de mapas e pontos de interesse, bem

como prover funções relacionadas à manipulação e edição de dados

espaciais.

5.2. Poderá se conectar a um map server disponível publicamente, ou a um

sistema de informações geográficas, conhecido como SIG (Sistema de

Informação Geográfica) no padrão de dados (Formato de armazenamento) e

sistemas (Software) existentes e em uso na CONTRATANTE.

5.3. Deverá ser disponibilizado o sistema de mapas com servidor de dados

geográficos interoperável, que possibilite, através de serviços web, o

intercâmbio e a transmissão de dados geográficos entre o sistema, seus

módulos internos e ambientes externos, mediante serviços providos pelo

Módulo de Integração de Sistemas e Sensores.

5.4. Visando facilitar a interoperabilidade, toda implementação será desenvolvida

baseada em especificações e padrões definidos pelo Open Geospatial

Consortium (OGC) incluindo, mas não se limitando, aos padrões de

comunicação e manutenção de dados geográficos WMS (Web Map Service

Interface Standard ) e WFS (Web Feature Service Interface Standard).

5.5. A solução deverá ser de alto desempenho e disponibilidade para acesso a um

banco de dados espacial com o objetivo de atender as necessidades vigentes

em Sistema de Informação Geográfica (SIG). A licença do SIG deverá

permitir a instalação para configuração de servidores em balanço (Farm)

para possibilitar alto desempenho e escalabilidade.

5.6. Deverá acomodar as seguintes feições gráficas básicas:

5.6.1. Segmento de Logradouro;

5.6.2. Numeração do Imóvel (Indicação de Face de Lote – Ponto de Mercado);

5.6.3. Bairros;

5.6.4. Acidente Geográfico;

5.6.5. Área Urbana (Mancha Urbana);

5.6.6. Localidade;

5.6.7. Edificação de Destaque;

5.6.8. Ponto Notável;

5.6.9. Ferrovia;

5.6.10. Hidrografia.

5.7. O serviço de apresentação e publicação de mapas da solução apresentada

preferencialmente deve ser compatível com SIGSIG os padrões e formatos

adotados pela CONTRATANTE.O módulo deve permitir a conexão com um

serviço público de fornecimento de mapas e imagens ortorretificadas

(Provenientes de satélite ou ortofotos), , e com a base de SIG de propriedade

da CONTRATANTE.

5.8. O módulo deve permitir a construção de mapa global para ver onde as

ocorrências estão localizadas e para controlar quais categorias de ocorrências

são mostradas.

5.8.1. Deve fornecer uma representação visual dos eventos em um mapa que

permita a identificação de padrões do local, conflitos e outros problemas

com informações provenientes de outros módulos e sistemas.

5.9. Deverá possuir duas interfaces interativas:

5.9.1. Mapa: Um mapa da região geográfica fornecendo informações sobre o local

do evento.

5.9.2. Filtro: Um formulário de entrada que permita selecionar quais categorias de

ocorrências serão mostradas no mapa.

5.10. O mapa deverá mostrar todos os eventos que são relevantes, usando os

valores de latitude e longitude especificados no registro de eventos para

mostrar a localização do evento no formulário na forma de um ícone ou

imagem determinada pelo usuário operador.

5.11. O mapa deverá ser atualizado conforme novas ocorrências são inseridas no

sistema, sujeitas a quaisquer filtros configurados para limitar as categorias

mostradas. Deverá ser possível exibir uma descrição do evento clicando no

marcador do evento no mapa. As categorias de evento exibidas no mapa

poderão ser alteradas com base na seleção de formulário de filtro.

5.12. Deverá ser possível focar na categoria do evento que se deseja analisar,

utilizando o filtro para ocultar as categorias de evento que não sejam

necessárias.

5.13. O mapa deverá responder para qualquer nova seleção de categoria enviada a

partir do formulário de filtro. Quando uma solicitação for enviada, a janela

do mapa deverá ser atualizada e apenas os locais de eventos da categoria

selecionada serão plotados no mapa e visualizados na tela do usuário por

intermédio do Módulo de Visualização.

5.14. Deverá ser possível focar nos eventos individuais que se deseja analisar

marcando caixas de seleção de eventos. Esses eventos serão, então,

destacados no mapa.

5.15. O mapa deverá representar o local de um evento com um dos seguintes tipos

de marcador:

5.15.1. Ícone: Identifica a localização de um evento no mapa com um ícone

exclusivo para cada categoria.

5.15.2. Polígono: Uma estrutura de tópicos no mapa da área associada a um evento.

5.16. O ícone e o nome da categoria deverão estar inclusos nos detalhes sobre a

ocorrência.

5.17. A plataforma integrada de Georreferenciamento deverá permitir ao Módulo

de Visualização as funcionalidades de interface de exploração de mapas:

aproximar (Zoom in), afastar (Zoom out) e centralizar no espaço disponível,

janela (Zoom window); arrastar, deslocar e rotacionar o mapa; uso de

unidades de medidas configuráveis; cálculo de distância lineares entre dois

ou mais pontos com apresentação da distância acumulada; cálculo de áreas

entre três ou mais pontos; mudança de unidade da escala do mapa; bússola;

lente de aumento; apresentação de coordenadas fornecidas de acordo com a

localização do cursor do mouse; símbolos que diferenciem eventos e

recursos / entidades representadas no mapa; capacidade de fazer anotações

no mapa incluindo pontos, retas, polígonos e suas respectivas legendas.

5.18. A solução deve ter funções que permitam o cálculo de rotas e permitir a

configuração de itinerários entre um ponto de origem e um ponto de destino,

entre um ponto de origem e vários pontos de destino, entre um ponto de

origem e um destino e vários pontos de passagem intermediários (Caixeiro

viajante).

5.19. A solução deve ter funções que permitam o cálculo de rotas com opção de

menor caminho, melhor caminho e caminho mais rápido.

5.20. A empresa contratada deverá executar serviços para adaptar a base de dados

oficial da CONTRATANTE para permitir a execução de operações de

roteamente e levantar as informações e cadastrar todas as informações

necessárias para o perfeito funcionamento do sistema, incluindo mão de

direção, conversões permitidas e proibidas, velocidade permitida, entre

outras características para executar este tipo de operação.

5.21. A solução deve disponibilizar funções de geocoding e geocoding reverso. As

ocorrências serão cadastradas sempre com um endereço válido (Nome do

logradouro e numeração exata ou aproximada) e o sistema deverá

georreferenciar este endereço (Por métodos de geocodificação ou Address

Match) e o sistema deverá transformar este endereço em uma coordenada

que será armazenada no formato longitude e latitude ou coordenadas planas

(E,N). Tratamento em relação a análise fonética deverão ser considerados,

para a localização de endereços digitados parcialmente ou grafia semelhante

ao real, assim como uma forma de correção e adição de nomenclatura oficial

e popular, diferenciação de logradouros homônimos entre outros recursos de

identificação e padronização automática de endereços.

5.22. Deve permitir a administração e gerenciamento de pontos de interesse

organizados por categorias.

5.23. Deve suportar múltiplos provedores SIG 2D e 3D (relevo de terreno,

superfície e modelos 3D de edificações, se disponíveis) simultaneamente.

5.24. Deve suportar camadas múltiplas de mapas.

5.25. Deve suportar navegar entre os múltiplos níveis de visualização.

5.26. Deve suportar o recurso de apresentar automaticamente as visualizações de

mapas ou localizações mais relevantes para o incidente.

5.27. Deve prover recurso para adicionar, via operador ou pelo provimento de

webservice, via Módulo de Integração um ponto notável ou de interesses,

como sensor ou múltiplos sensores ou grupo de sensores ao SIG, através do

posicionamento do cursor do mouse em cima do mapa, ou pela entrada direta

de coordenadas geodésicas.

5.28. Deve prover recurso para customizar ícones de sensores. Os ícones

representando sensores devem refletir visualmente o estado de cada sensor

ou grupo de sensores.

5.29. Deve prover recurso para rastrear o movimento de tecnologias baseadas em

localização, se tecnologicamente viável, (ex.: GPS, RFID, etc.),

apresentando visualmente o trajeto histórico de movimento.

5.30. Deve prover recurso para customizar a visibilidade de um mapa do SIG por

nível de zoom.

5.31. Deve ser integrável aos demais módulos e sistemas, de forma a possibiltar o

disparo, via Módulo de Integração, de ações e tarefas, ou ainda o consumo

de webservices.

5.32. Deve suportar o recurso de adicionar marcadores visuais ao SIG. Os

marcadores, imagem/ícone devem ser personalizáveis. Os marcadores devem

ter recursos de ativar automaticamente ações variadas.

5.33. Deve possuir recurso para definir restrições de autorização para a

administração do SIG como adicionar visualização, ícones, layers, etc.

5.34. Deve servir como centralizador de manipulação de informações

georeferenciadas entre todos os módulos e sistemas.

6. Módulo de Visualização

6.1. Deve ser compatível com o trabalho em desktops com duas telas, de modo a

possibilitar a melhor visualização e organização dos recursos disponíveis no

sistema.

6.2. Permitir que o usuário organize na sua tela as diversas janelas de trabalho,

pré-definidas no sistema, de acordo com seu uso e preferência, tanto na

estação de trabalho, como em tablet e smartphones.

6.3. O Módulo de Visualização deve permitir a inclusão manual e a captura

automática de informações que viabilizam a localização geográfica das

ocorrências, possibilitando a visualização destas informações na tela bem

como dos arquivos de gravação referentes a estas, possibilitando a geração

de um mapa especifico e a localização fácil das ocorrências.

6.4. O módulo, ao receber as informações relevantes de outros sistemas (por

exemplo, o Módulo de Ocorrências), ilustrará a ocorrência em um mapa

global permanentemente atualizado em tempo próximo ao real, de acordo

com uma legenda técnica padronizada, devendo ser descrita por código e

nível de risco.

6.5. Por meio de filtros predeterminados, o sistema deverá permitir ao operador

visualizar as câmeras de vídeo disponíveis na região, via Módulo de

Integração de Sistemas e Sensores, recursos disponíveis, viaturas mais

próximas de um incidente, hospitais, rotas para deslocamento

(estabelecimento e gerenciamento), entre outros. O sistema deverá permitir

que o operador selecione a câmera mais próxima e acione-a de forma a obter

a imagem do evento no momento em que ele se desenvolve.

6.6. O sistema integrador deve permitir a interação com o Módulo de

Georeferenciamento, de tal forma que qualquer elemento gráfico referente a

um item de interesse (tal como uma ocorrência, viatura, alerta ou dispositivo

de monitoramento) possa ser manipulado diretamente a partir do seu ícone

indicativo no mapa, através de um menu de contexto.

6.7. Deverá ser apresentável no mapa a posição dos elementos móveis

conhecidos, dentre eles, mas não restritos a: recursos de segurança e

relacionados, como viaturas policiais, bases móveis, viaturas dos bombeiros,

ambulâncias, helicópteros, terminais embarcados, pontos de interesse, entre

outros recursos com disponibilidade de informações de posicionamento.

6.7.1. O posicionamento geográfico poderá será obtido, por exemplo, a partir do

Módulo de Integração de Sistemas e Sensores.

6.8. A solução também deverá ser capaz de trabalhar com monitores operando

em resoluções de 16:9 ou 16:10, permitindo que qualquer tela de

acompanhamento de ocorrências, relatórios, indicadores ou informações do

Sistema da Central de Monitoramento possam ser disponibilizadas para

visualização em aparelhos de TV tela plana ou monitores de vídeo.

6.9. Deve oferecer os recursos de pan e zoom do mapa global onde as

ocorrências e pontos de interesse são visualizados.

6.10. Deve se integrar ao Módulo de Alarmes e Avisos para a visualização de

alertas por meio de ícones e talas de alto contraste e janelas modais.

6.11. A solução deve permitir a interação das operações dos diversos sistemas e

módulos integrados, permitindo ao operador a análise de informações

geradas pelos vários sistemas de forma única através de uma interface

homem-máquina padronizada e consistente.

6.12. Deverá permitir a visualização a partir de terminais móveis, tais como

smartphones, tablets e PDAs.

6.12.1. Os sistemas suporados para handhelds serão o iOS e o Android, em suas

versões mais correntes.

6.12.2. Os navegadores suportados serão, nesta ordem de preferência:

6.12.2.1. Aqueles fornecidos em conjunto com o sistema operacional (Safari,

Android Broser) ;

6.12.2.2. Google Chrome, como forma de padronização entre plataformas.

6.13. Permitir que os vários usuários do sistema controlem os conteúdos

disponíveis para visualização e operem os layouts nos diversos painéis de

visualização.

6.14. Deve ser possível a criação automática de layouts e presets de câmeras e

aplicativos, as operações de controle de janelas, o posicionamento e

redimensionamento dos conteúdos, o controle das entradas físicas de vídeo

dos displays e o controle remoto de estações conectadas ao sistema.

6.14.1. O acesso à ferramenta e os níveis de acesso às funcionalidades serão os

definidos pelo administrador/supervisor na ferramenta de gerenciamento, via

Módulo de Controle de Acesso.

6.15. Uma vez desencadeada uma situação de evento, deverá automaticamente

exibir o plano de ação pré-programada e deve atualizar automaticamente e

dinamicamente o plano de resposta baseado em novas informações ou

entradas pelo operador.

6.16. Deve prover ao operador, a qualquer hora, permissões apropriadas para ver a

lista de todos os eventos e situações correntes com os detalhes associados,

incluindo ações tomadas e pendentes; operador responsável; imagens de

vídeo relevantes, e plano de ações em andamento.

6.17. Deve pertmitir que usuários do tipo “coordenadores” possam replicar em sua

estação de trabalho a mesma tela visualizada por qualquer operador/usuário

sob sua coordenação.

6.18. Deve prover recurso para o usuário assumir a responsabilidade

(coordenação) pelo incidente após recebimento.

6.19. Deve prover recurso de criar um relatório com data/hora de todos os

procedimentos adotados no gerenciamento do incidente.

6.20. Deve fazer atualização dinâmica das prioridades operacionais de cada

usuário e suportar divisão balanceada de incidentes de acordo com a

evolução da situação.

6.21. Deve prover recurso de fazer atualização das propriedades do incidente,

realocar incidentes e adicionar tarefas agendadas automaticamente de acordo

com a demanda.

6.22. Deve prover recurso para escalar os incidentes que não foram gerenciados

dentro do tempo previsto.

6.23. Deve prover uma tela dedicada para gerenciamento de incidentes.

6.24. Deve permitir visualizar os incidentes relevantes por cada usuário

responsável.

6.25. Deve integrar-se ao Módulo de Controle de Acesso, de forma a possuir

recurso para filtrar quais incidentes podem ser vistos por quais operadores.

6.26. Deve prover um relatório integrado de incidentes que contém visualização de

todos os incidentes e que podem automaticamente classificar novos

incidentes de acordo com a severidade pré-definida e sequência de criação.

6.27. Deve prover recurso para alocar categoria (ou tipo de incidente) para os

incidentes, tanto automaticamente ou sob demanda e agrupar incidentes

dentro do log de incidentes por região, por responsável ou por categoria.

6.28. Deve permitir administradores definir a categoria padrão para quick launch

por operador como emergência médica, crime, acidente, etc.

6.29. Deve prover log de incidentes que possibilita acesso fácil a mapas e imagens

de vídeo relevantes, anexas e formulários por cada incidente.

6.30. Deve prover recurso para visualizar e editar formulários relacionados a

incidentes e tarefas. O formulário com todas as atualizações deve ser salvo e

acessível a qualquer hora.

6.31. Deve prover recurso para localizar incidentes que compartilham

características similares. Cada incidente similar com horário de criação,

horário de fechamento, sensores relacionados, criador e procedimentos

adotados devem ser visualizados.

6.32. Deve possuir recurso para visualizar as tarefas relevantes por cada incidente.

6.33. Deve possuir recurso para visualizar as tarefas relevantes por cada operador.

6.34. Deve prover recurso para adicionar, alocar e realocar tarefas em tempo real

para um usuário ou grupo de usuários.

6.35. Deve prover recurso para adicionar anexos no momento da criação da tarefa.

6.36. Deve prover recurso para adicionar comentários a incidentes, tanto no

formulário pré-definido como no formato texto livre.

6.37. Deve prover recurso para disparar automaticamente as ações quando a tarefa

é classificada como cancelada, falhada, realocada, etc.

6.38. Deve prover recurso para ocultar incidentes fechados dentro do log de

incidentes ativos ainda procurar por incidentes fechados de acordo com a

propriedade do filtro.

6.39. Deve prover recurso para criar incidentes pré-arquivados, para propósito de

relatório do incidente, e não aparecer no log de incidentes ativos.

6.40. Deve suportar recurso para procurar por incidentes ativos.

6.41. Deve mostrar popup de notificações quando o incidente é criado e escalado.

6.41.1. A cor do popup de notificações deve refletir a severidade do incidente.

6.42. Deve suportar recurso para filtrar o conteúdo do relatório de incidente e

gerar relatórios de acordo com a demanda ou automaticamente para qualquer

incidente a qualquer hora, no formato selecionado pelo operador.

6.43. Deve permitir aos usuários enviar pacotes de relatórios contendo

informações como formulários, vídeo clipe, snapshots, emails relacionados,

etc.

6.44. Deve requerer um comentário, sobre o encerramento do incidente, o qual

deve ser gravado e ser recuperável para análise posterior.

7. Módulo de Alarmes e Avisos

7.1. Deve permitir o envio de mensagens de texto através de email, mensagens

por popups e, torpedos SMS de forma automatizada e deve estar nativamente

integrado aos demais módulos da Central de Monitoramento.

7.1.1. Deve permitir a geração, localmente, no terminal do usuário, de alarmes

audíveis.

7.1.2. O webservice para envio de SMS será provido pela CONTRATANTE.

7.1.3. Deve ser capaz de endereçar mensagens destinadas a serviços de

monitoramento SNMP e syslog.

7.1.4. Deve ainda permitir integração ao Sistema de Integração de Telefonia para o

disparo de torpedos de voz.

7.2. Permitir a comunicação (chat) entre os usuários com mensagens pré-

formatadas ou livres, com visualização de histórico pelos usuários

envolvidos e pela supervisão.

7.3. O módulo deve ser baseado e integrado à interface web coordenada pelo

Módulo de Visualização.

7.4. Deverá dispor de interface de administração web.

7.5. Deve permitir a configuração do acesso de usuários e regras pelos

administradores da ferramenta, via Módulo de Controle de Acesso.

7.6. A solução deverá possuir funcionalidade de mensagens instantâneas (chat)

permita aos operadores do sistema a troca de informações em tempo real.

7.6.1. As mensagens instantâneas deverão poder ser acionadas de forma manual ou

de forma automática acionada por agente externo, via Módulo de Integração

de Sistemas e Sensores.

7.6.2. A solução deverá exibir dados de presença do usuário (ex. ativo, inativo).

7.6.3. A solução deverá permitir a troca de mensagens criptografadas utilizando

padrões de segurança de mercado (ex. HTTPS).

7.6.4. Deve ainda possibilitar a assinatura de mensagens e avisos utilizando

certificados digitais padrão ICP-Brasil.

7.6.5. Deve permitir o disparo de alarmes em sistemas informatizados remotos, via

Módulo de Integração de Sistemas e Sensores.

8. Módulo de Relatórios Operacionais

8.1. O módulo de Estatísticas e Relatórios deve se comunicar a uma base de

dados, permitindo o armazenamento e compartilhamento de todos os

elementos e informações trafegadas e tratadas na Central de Monitoramento,

por meio de uma plataforma web comum a todos os usuários.

8.2. Este módulo deve ser integrado a todos os demais módulos, permitindo o

acesso tabular às informações armazenadas, ajudando a compor análises

estatísticas e extração de relatórios com base nas hierarquias de vínculos,

correlações e dependências entre entidades e atributos de análise.

8.3. Deve possibilitar identificação e análise de vínculos entre bases, entre

registros disponíveis e a partir de inserção de palavras-chave de busca.

8.4. Deve permitir a identificação e análise de relacionamento entre entidades,

considerando quantidade de relacionamentos, repetições, conexões diretas e

indiretas entre entidades e atributos.

8.5. O sistema deverá fornecer relatórios consolidados e personalizados

considerando, minimamente, períodos de tempo, classificações de

criticidade, regiões geográficas, tipo, bem como índices/indicadores

(estatísticas) de eficiência, na resolução das ocorrências, dentre outros.

8.6. De posse dos dados extraídos, o sistema deve possibilitar a aplicação de

regras para a conversão, cálculos, correlações e análises de dados.

8.7. O sistema deverá possuir um gerador de estatísticas e relatórios de interesse,

a fim de ressaltar os principais índices.

8.8. O sistema também deve prover métodos para que sistemas, sem intervenção

manual, sejam capazes de acessar informações na forma de relatórios.

8.9. As integrações e relatórios não devem afetar o desempenho do sistema e das

interfaces utilizadas na operação.

8.10. O módulo deverá permitir a criação/modificação de indicadores de

performance e modelos de monitoramento, e deve conter pelo menos as

seguintes funcionalidades:

8.11. Possibilidade de uso de cores nos indicadores de desempenho.

8.12. Os indicadores de desempenho devem ser capazes de agregar informações

sobre recursos distintos de forma aninhada (status de veículos, que

compreende status de caminhões, ambulâncias) e de forma individual (status

de caminhões).

8.13. A visualização de tais indicadores de desempenho deve ser separada por

níveis de acesso, de maneira que determinados indicadores só possam ser

visualizados se devidamente autorizados, via integração com o Módulo de

Controle de Acesso.

8.14. Ser nativamente integrado aos demais módulos, permitindo, por exemplo, o

envio de alertas se um indicador atingir um valor crítico.

8.15. Permitir a criação de novos indicadores a serem monitorados.

8.16. Permitir o cálculo dos valores dos indicadores com base em medições ou

através de expressões baseadas nos indicadores existentes.

8.17. Deverá permitir a riação de relatórios com com diferentes tipos de gráficos

(coluna, pizza, barra, etc.)

8.18. Possuir interface para confecção de consultas e construção de análises e,

neste contexto, possuir linguagem de interação e desenvolvimento scripts

para manipulação, automação e análise de informações.

8.19. O sistema deve processar informações, aplicar regras predefinidas para

conversão de dados (ex: inteiro para float ou data para string), realizar

cálculos, e permitir ao usuário identificação de tendências para possibilitar a

análise e o direcionamento de ações para tratamento preventivo de possíveis

eventos.

8.20. Permitir a criação de regras de cálculos e análises que envolvam dados

oriundos de fontes distintas, desde que obedeçam às regras de perfis de

acesso aos dados integrados.

8.21. Realizar cálculos estatísticos e que incluam operações de máximo, mínimo,

porcentagem, média e soma, em relação a quaisquer dimensões de dados, em

qualquer métrica.

8.22. Possuir biblioteca de funções (lógica, conversão, financeiras, matemáticas,

analíticas, estatísticas, cadeias de caracteres e outras) para serem utilizadas

durante o processamento de regras pré-definidas ou em consultas e

relatórios.

8.22.1. Deverá se integrar ao Módulo de Georeferenciamento para permitir a

utilização de funções e a manipulação de dados geográficos.

8.23. Possibilitar o agendamento de execução e processamentos de dados.

8.24. Possuir base de informações padronizada e centralizada para armazenamento

dos dados processados.

8.25. Disponibilizar os resultados de processamentos já executados de forma que

permitam a realização de consultas sem a necessidade da execução de novos

processamentos.

8.26. Deverá apresentar relatórios de falhas ocorridas com os respectivos logs de

erro.

8.27. Deverá apresentar também um relatório com os erros de integração com os

demais sistemas, com interface de fácil compreensão, onde seja possível

identificar a falha ocorrida, a ocorrência e unidade operacional relacionada à

falha e o conteúdo da informação que estava sendo integrada.

8.28. Deverá propiciar a geração dos seguintes tipos de relatórios a serem

utilizados para o planejamento estratégico:

8.28.1. Estatísticas de Tipos de Ocorrência por região (ou Área de Atendimento);

8.28.2. Estatísticas de Ocorrências através do preenchimento gráfico das regiões dos

bairros ou das áreas de atendimento com cores diferenciando a quantidade de

Ocorrências.

8.29. Visualização das ocorrências no mapa georeferenciado, iluminando;.

8.30. Mapa termal georeferenciado indicando regiões com concentração de

ocorrências.

8.31. Deverá permitir e incorporar a preparação de relatórios gerenciais

alfanuméricos que permitam avaliar o desempenho de todas as atividades

sob a alçada da Central de Monitoramento, tais como:

8.31.1. Tipos de Ocorrências por dia da semana e horário da ocorrência;

8.31.2. Tipo e Quantidade de Ocorrências atendidas por Grupo de Despacho;

8.31.3. Relatório de Ocorrências: Número de Registro da Ocorrência, Tipo da

Ocorrência, Localidade, Área de Atendimento, Grupo de Despacho

designado, Unidades envolvidas no atendimento, data e horário do empenho

da unidade, data e horário da chegada ao local de cada uma das unidades,

data e horário do término da atividade ou ocorrência e nome dos agentes

presentes nas unidades;

8.31.4. Relatório do Controle de Tempo das Ocorrências: tipo e quantidade de

ocorrências, tempo médio de atendimento e tempo máximo de atendimento.

8.32. Toda informação deverá permitir ser exportada para diferentes formatos tais

como: Adobe portable document format (PDF), Rich-text format (RTF),

Microsoft Excel (XLS), comma separated values (CSV), Hypertext Markup

Language (html), PlainText.

9. Módulo de Framework Web

9.1. Deve possuir framework básico baseado em HTML5, sendo capaz de aceitar

a execução de código baseado em .NET ou JEE, via Módulo de Integração

de Sistemas e Sensores.

9.2. Deve estar integrado ao Módulo de Visualização, para permitir a

customização e ampliação das funcionalidades visuais do sistema.

9.3. Deve permitir nativamente o acesso de dados via web services de acordo

com padrões existentes de troca de mensagens como SOAP em protocolo

HTTP e HTTPS.

9.4. Deve ser integrado ao Módulo de Visualização, possibilitando o controle das

informações e variáveis a serem exibidas ao usuário, permitindo a extensão

das funcionalidades deste.

10. Módulo de Integração de Sistemas e Sensores

10.1. Permitir o envio de mensagens de dados a usuários de equipamentos

integrados, logados ou não, com textos pré-formatados, livres ou com base

em uma ocorrência selecionada, mantendo o histórico de textos e datas em

que as mensagens foram enviadas.

10.2. O sistema deve permitir a criação de canais para troca mensagens entre

órgãos, clientes e parceiros devidamente autorizados.

10.3. O sistema integrador deve dar suporte às operações da Central de

Monitoramento, permitindo a troca de informações e inteligência, seguindo o

fluxo definido nos Procedimentos de Resposta, devendo também dar suporte

à geração dos relatórios e informes do ritmo diário e promover a

interoperabilidade entre diferentes organizações a partir de uma estrutura

flexível e rápida de disseminação de informações.

10.4. Permitir o desenvolvimento de conectores de software para integração com

sistemas legados ou de organizações externas nas linguagens JEE ou .NET,

perfeitamente integradas aos demais módulos e, em especial ao Módulo de

Framework Web.

10.5. Deve permitir a integração do Sistema de Central de Monitoramento com

sistemas, interfaces e bases de dados externas, tais como:

10.5.1. Sistemas de georeferenciamento e map servers;

10.5.2. Bases de conhecimento nacionais e regionais;

10.5.3. Arquivos texto;

10.5.4. Arquivos XML;

10.5.5. Arquivos de imagens (JPG, TIFF/GeoTIFF, BMP, PNG);

10.5.6. Arquivos de áudio (.wav, .wma, .au);

10.5.7. Arquivos ESRI shape, KML, Google Earth, DWG, DGN, DXF e ESRI grid;

10.5.8. Acesso a Web Map Service, Web Feature Service, Geography Markup

Language;

10.5.9. Bancos de dados relacionais Oracle, SQL Server, Sybase, DB2, PostgreSQL

e MySQL;

10.5.10. Sistemas de dataware house;

10.5.11. Sistemas de BI;

10.5.12. Soluções de ETL;

10.5.13. Web services (POST/GET/REST/SOAP) em protocolos HTTP e HTTPS;

10.5.14. Planilhas eletrônicas (.xls, .xlsx, .ods) e documentos (.doc, .docx, .odf,

.pdf);

10.5.15. Sistema gerenciador de eventos;.

10.5.16. Bases de dados SQL acessíveis via OLEDB e ODBC;

10.5.17. Filas de mensagens;

10.5.18. Sockets IP com suporte a TLS/SSL;

10.5.19. Servidores FTP e SFTP;

10.6. As integrações acima podem ser feitas sob demanda, mediante o uso do

banco de horas de consultoria, conforme descrito no item 19.

10.7. Deve permitir capacidade de paralelismo e multiprocessamento, permitindo

a execução simultânea de fragmentos de código executável.

10.8. Deve permitir a captura automática e pré-agendada de informações em

sistemas externos.

10.9. O Módulo de Integração de Sistemas e Sensores deve possibilitar à Central

de Monitoramento a utilização de informações disponibilizadas, bem como

permitir o seu armazenamento para posterior análise, evitando registros

duplicados.

10.10. Possibilitar o versionamento de extrações e tratamento de dados, permitindo

a criação de históricos e a extração de relatórios via Módulo de Estatísticas e

Relatórios.

10.11. A solução deve permitir a interação das operações dos diversos sistemas

integrados, desta forma, permitindo ao operador a análise de informações

geradas pelos diversos sistemas de forma única.

10.12. Deve permitir integração com os Módulos de Georeferenciamento e demais

módulos, permitindo, por exemplo, a visualização pelo usuário ou operador

de câmeras de vídeo associadas a uma ocorrência.

10.13. Deve permitir a inclusão manual e a captura automática de informações que

viabilizam a identificação e a localização geográfica das ocorrências,

possibilitando a visualização destas informações pelo Módulo de

Visualização.

11. Módulo de Mídias

11.1. A solução deve possibilitar acesso para análise automática de fontes de

informações como sites pessoais, de instituições, de organizações, de redes

sociais, no mínimo para Twitter, Facebook, Youtube, Orkut, Google (Blogs,

Notícias e Alertas), Google+, Yahoo! Respostas, Reclame Aqui!, Blogs

(WordPress), feeds RSS e possibilitar a identificação de informações em

jornais eletrônicos, sítios de notícia e blogs.

11.1.1. A solução deve ser capaz de utilizar bibliotecas externas e específicas para

extração das informações na Internet, devendo, no entanto, prover uma

camada de abstração às chamadas de funções e métodos, de forma a permitir

a troca destas bibliotecas com um mínimo de esforço de programação.

11.1.2. Se utilizados, o fornecimento de bibliotecas e gateways externos serão de

responsabilidade da CONTRATADA.

11.2. A solução deve, minimamente, suportar Web 2.0, anonimidade,

normalização de datas e utilização de proxies.

11.3. A CONTRATADA deve prover a programação inicial dos sistemas de

coleta, que deve ser configurável pelos usuários.

11.4. A solução deve garantir o armazenamento do histórico dos termos e citações

monitorados automaticamente pelo sistema, por meio da manutenção de um

banco de dados interno, integrado ao Módulo de Estatísticas e Relatórios.

11.5. Serão monitorados, minimamente, os idiomas, português, inglês e espanhol.

11.6. A solução deve possibilitar a consulta de informações capturadas de forma

manual ou automática por filtros, considerando no mínimo: Assunto,

Público, Mídia, Data da publicação e Palavra-chave.

11.7. A solução deve gerar relatórios com os dados coletados no monitoramento a

qualquer tempo.

11.8. Os relatórios da Solução deverão trazer como resultados as informações

minimamente identificadas pelas categorias de filtro existentes.

11.9. Possibilitar na geração dos relatórios a especificação de período-base e o

assunto relativos aos eventos, problemas e situações ocorridas.

11.10. A solução deve utilizar metodologia de indexação de matérias, que permita

através de uma análise quantitativa e qualitativa, identificar os principais

focos abordados pela mídia.

11.11. Obter, dinamicamente , os assuntos e conteúdos e análises através do uso de

palavras–chave (tags).

11.12. Possibilitar o envio de informações em tempo real, via Módulo de Alarmes e

Avisos, para públicos pré-selecionados, ou através de página web

11.12.1. No caso de envio para página web, este poderá ser efetuado via serviços

FTP, webservices ou similares, através do uso do Módulo de Integração de

Sistemas e Sensores.

11.13. Em caso de falha na comunicação com algum dos provedores de

informações, a Solução de Monitoramento de Mídias deverá ser capaz de

retomar automaticamente a apresentação das informações quando elas

estiverem novamente disponíveis.

11.14. A solução deve disponibilizar respostas automáticas nas diferentes mídias e

redes sociais, para agir de forma rápida mediante postagens e demais tipos

informações identificadas. Tal recurso deve ser configurável.

11.15. A solução deve também permitir o recurso de postagem em múltiplas mídias

sociais, como o twitter e o Facebook.

11.16. A solução deve gerar relatórios com gráficos que permitam uma rápida

avaliação do volume de informações monitoradas, mídias identificadas,

assuntos, entre outros.

11.17. A solução deve disponibilizar o recurso de exportação de dados em diversos

formatos, como por exemplo: CSV, XLS,TXT, HTML, PDF, XML.

11.18. Deve existir um recurso para controle de conteúdo monitorado para inclusão,

alteração ou exclusão de assuntos, temas, palavras-chave, mídias,

informações monitoradas, entre outros. A inclusão ou a alteração de

palavras-chave e termos de clipping deve ser funcionalidade disponível, e as

alterações realizadas devem ser refletidas em tempo real nos mecanismos de

monitoração automática.

11.19. A solução deverá oferecer telas customizáveis, indicando de qual rede social,

site ou serviço de blog está sendo extraída a mensagem, possibilitando

identificar, se tecnicamente viável, o usuário que está publicando a

mensagem (post), de modo que caso o usuário não seja identificado, a

solução deve permitir o cadastramento do novo usuário a partir da mesma

tela de agente.

11.20. A solução deve estar pronta para extrair dados de mídias sociais, provendo

abrangência no acesso à informação online, extraindo fontes de dados como:

11.20.1. Twitter, Facebook e Linkedin a partir de suas APIs nativas;

11.20.2. Dados de outras redes sociais a partir de chamadas REST ou web

services que podem ser configurados diretamente na aplicação;

11.20.3. Dados de páginas web, como, por exemplo, o site “Reclame Aqui”, por

meio da leitura da estrutura HTTP para localização e extração dos dados que

são relevantes.

11.20.4. A extração de dados de mídias sociais pode ser feita de duas formas:

11.20.4.1. Através da configuração de usuário e senha de uma conta associada à

CONTRATANTE;

11.20.4.2. Através do uso de gateways ou similares para acesso às últimas

mensagens do site ou serviço, identificando aquelas de interesse da

CONTRATANTE, através de configuração ou parametrização de algoritmo

de análise de semântica.

11.21. A solução deve ainda suportar a definição das palavras-chave: as ferramentas

ou serviços devem possibilitar o cadastro de palavras a serem monitoradas

para captação das menções feitas por usuários Em um exemplo, pode-se

monitorar pelas publicações que envolvam termos como “PM”, “Bombeiro”,

“SAMU”, etc. O objetivo é dar foco e captar postagens que possibilitem uma

relação ou que sejam úteis para o envio de avisos, via Módulos de Alertas ou

mesmo a criação automática de eventos via Módulo de Ocorrências.

11.22. A solução deve prover componentes que desenvolvam a interpretação dos

textos a partir da sintaxe das frases, fazendo a segmentação das informações

extraídas, eliminando informações que não sejam do interesse da

organização/instituição, segmentando sobre qual produto ou serviço que a

informação diz respeito, identificando se é uma reclamação ou um elogio

entre outras análises. A flexibilidade da solução deverá permitir que ela se

adeque rapidamente a gírias e modismos que surgem online buscando

interpretar corretamente o que é dito sobre a organização.

12. Módulo de Controle de Acesso

12.1. O Módulo de Controle de Acesso é o responsável pelo cadastro de perfis de

usuários e clientes e suas credenciais de acesso ao Sistema da Central de

Monitoramento.

12.2. O módulo deverá prover serviços de controle de acesso ao sistema,

possibilitando a criação de diferentes perfis de usuário e de acesso,

controlando quais informações e as funcionalidades que cada usuário poderá

visualizar ou alterar.

12.3. Deve permitir integração com bases de usuários definidas armazenadas com

acesso provido pelos seguintes protocolos, componentes de software ou

serviços:

12.3.1. LDAP

12.3.2. Active Directory

12.3.3. Bases em SQL(em suas últimas versões correntes):

12.3.3.1. Oracle

12.3.4. IBM DB2

12.3.5. Microsoft SQL Server

12.3.6. Sybase

12.3.7. PostgreSQL

12.3.8. MySQL.

12.3.9. As senhas de acesso serão armazenadas em bases SQL, Active Directory ou

em ambiente LDAP na forma de hashs criptográficos sempre que forem

tecnologicamente possíveis.

12.3.10. A base de dados de autenticação deve ser multi tenant, habilitando

múltiplos órgãos com jurisdições próprias sobre seus usuários e perfis de

acesso.

12.4. O sistema deve prover uma configuração padrão de regras e direitos para

uma série de tipos de usuários variando desde o administrador do sistema até

usuários básicos.

12.5. O sistema deve prover um mecanismo de criar novos tipos de usuários e

atribuir direitos específicos e autoridades para os usuários novos criados.

12.6. O sistema deve prover um mecanismo para alterar os direitos associados aos

tipos de usuários.

12.7. O sistema deve prover um mecanismo para associar usuários específicos do

sistema com ou mais tipos de usuários.

12.8. Permitir definição de perfis de usuários com diferentes níveis de acesso ao

sistema: visualizador (apenas leitura), atendentes, despachadores,

supervisores e pessoal distribuído em campo com equipamentos móveis.

12.9. Permitir o registro da unidade no sistema, através do login do usuário, com

as características associadas.

12.10. Permitir listar e localizar usuários a partir de seu registro, nome completo ou

área de atualização, com indicação se está logado ou não, assim como as

informações sobre o equipamento remoto utilizado para acesso (ex: desktop,

ou mobile).

12.11. Deve permitir que administradores e supervisores especifiquem que

informações e ocorrências serão acessíveis e visualizadas pelos usuários

pertencentes às suas áreas de responsabilidade.

12.12. Deve permitir funcionalidades de bloqueio de acesso, expiração de senhas e

controle da sua complexidade, na forma de quantidade mínima de caracteres

que não sejam letras e números, quantidade mínima de letras maiúsculas e

minúsculas, e quantidade mínima de numerais que devem estar presentes na

senha de acesso.

12.13. Deve ser capaz de permitir a autenticação de usuários com base em

certificados digitais padrão ICP Brasil.

12.13.1. Os certificados serão fornecidos pela CONTRATANTE.

12.13.2. Deve ser capaz de assinar digitalmente as entradas de dados e as tomadas

de decisão.

12.14. Deve permitir o cadastro de clientes, usuários e parceiros como pontos de

contato para o envio de mensagens via módulos e sistemas de integração.

12.15. O sistema deve permitir integração com terceiros via Módulo de Integração

de Sistemas e Sensores.

13. Módulo de Auditoria e Logs

13.1. O Módulo de Auditoria e Logs será o repositório principal das informações

sobre acessos ao sistema , a delegação de responsabilidades e os dados de

desempenho e de operações de todo o conjunto.

13.2. Deve ser construído de forma a proteger os dados inseridos de qualquer

modificação.

13.3. Deve permitir a geração de relatórios básicos e a pesquisa por palavras-

chave e por usuários e sistemas, tanto na forma de remetentes como de

destinatários.

13.4. O acesso será definido pelo administrador, e, para tal, será integrado ao

Modulo de Controle de Acesso.

14. Módulo de Backup e Versionamento

14.1. Deve ser fornecido componente de software que permita o completo backup

e restore de todas as informações pertinentes ao funcionamento e ao

histórico de operações da Central de Monitoramento.

14.1.1. O backup das configurações do sistema (incluindo os dados referentes ao

controle de acesso) deve poder ser executado em filesystem (local ou remoto)

ou ainda utilizando o banco de dados SQL associado à solução.

14.1.1.1. No caso de backup remoto via filesystem, deve ser possível realizar

backups e restores via protocolos CIFS e NFS.

14.2. A solução deve permitir visualizar o histórico de backup, permitindo ao

operador efetuar o restore para o estado que o sistema se encontrava em

determinada data e hora.

14.3. A ferramenta de backup deve permitir realizar backups em modo

incremental e total,.

14.4. O backup deve incluir todas as ocorrências e todos os arquivos anexos, tais

como mensagens, imagens e vídeos.

14.5. Deve permitir o backup parcial de apenas determinadas informações e de

determinados módulos e sistemas.

14.6. Deve permitir o agendamento de backups e a restauração de dados de forma

automática

14.7. A solução deve armazenar todos os parâmetros de configuração do sistema,

atrelado a um controle de versionamento, de forma que seja possível a

restauração do software, dos dados e das configurações a um estado anterior,

previamente definido pelo usuário.

15. Módulo de Vídeo Monitoramento

15.1. Solução de sistema de vídeo segurança multiusuário e multi-site, devendo

suportar integrações com sistemas de gravação e visualização de câmeras IP,

codificadores de vídeo IP, desde que suportado pelo fabricante dos

equipamentos, via SDK ou funcionalidade específica para tal.

15.1.1. A integração deverá ser feita diretamente às câmeras de vídeo ou ainda

indiretamente, através de equipamentos tipo DVR ou NVR (já existentes)

compatível com o fabricante das câmeras de vídeo.

15.2. Deve suportar a integração com sistemas externos de detecção de

movimento.

15.3. Deve possuir gerenciamento centralizado em ambiente web, via integração

com Módulo de Visualização.

15.4. Deve permitir a visualização ao vivo de câmeras e reprodução com clientes

utilizando plataforma móbile (smartphones, tablets, PDAs) e desktops.

15.5. Deve permitir ao usuário a adição de câmeras, a configuração de vídeo e

gravação, ajuste de detecção de movimento e configuração do usuário.

15.6. Deve permitir a exibição de Janelas/Layouts: Trabalha com exibições

contendo até 10x10 câmeras (com otimização para sistemas com vídeo 4:3,

16:9 e 16:10), Hot spot, Matriz, sequencial, imagens estáticas e ativas, mapas

HTML, distribuídos em todos os monitores do computador.

15.7. Deve possobilitar o controle PTZ manual, presets e macros, bem como o

patrulhamento em patterns e o controle de limpadores.

15.8. Deve permitir o controle remoto de câmeras por meio de joystick e mesa

acoplada ao computador, bem como teclado e mouse.

15.9. Deve prover interface entre as câmeras remotas e o Módulo de Alarmes e

Avisos.

15.10. Deve ter suporte a recursos de áudio bidirecional.

15.11. Deve ser integrável a câmeras de vídeo com múltiplos live streams MPEG4 e

H.264 e arquivos de vídeo padrão MPEG4.

15.11.1. Deve permitir ao Módulo de Visualização a reprodução de vídeo

localmente com até 16 fontes de vídeo em sincronismo.

15.11.2. Linha de tempo de atividade com recurso de lupa.

15.11.3. Provas podem ser geradas com relatório impresso, imagem em JPEG,

filme AVI ou no formato de banco de dados nativo.

15.11.4. Exportação de gravações de áudio em formato WAV ou AVI.

15.11.5. Exportação de vídeo digital com zoom para visualizar área de interesse, e

para minimizar o tamanho do arquivo exportado.

15.11.6. Exportação de "CD de Evidência" contendo dados nativos e o

visualizador.

15.11.7. Opção de criptografia e senha de proteção para as gravações e os

arquivos exportados.

15.11.8. Capacidade de adicionar comentários às provas exportadas, também

criptografadas.

15.11.9. Opção para enviar provas de vídeo por e-mail.

15.12. Deve estar integrado ao Módulo de Controle de Acesso para autenticação de

usuários e acesso às informações e controle das câmeras.

15.13. Deve ser capaz de solicitar a visualização ao vivo em uma taxa de quadros

diferentes e em resolução mais baixa que as configurações de gravação.

15.14. Deve possibilitar aplicar configurações individuais ou em grupo para as

câmeras (presets, PTZ, algoritmos e taxas de compressão, bem como zonas

de detecção).

15.15. Deve ser capaz de trabalhar com equipamentos capazes de detecção de

movimento embutida, em tempo real, com sensibilidade completamente

ajustáveis e com zonas de exclusão.

15.16. Deve permitir configuração para ativar a gravação com velocidade de frames

superior quando é detectado movimento ou quando surge um evento,

notificando o alerta por e-mail ou SMS, via integração com Módulo de

Alarmes e Avisos.

15.17. Deve ser capaz visualizar imagens de vídeo provenientes de DVRs e /ou

NVRs sem a necessidade de encoders ou decoders adicionais.

15.18. Deve possibilitar recurso de selecionar uma localização no mapa e

automaticamente trazer fonte de vídeos de câmeras que tenham visibilidade

do ponto selecionado.

15.19. Deve prover uma indicação visual refletindo o estado da câmera, se ativa,

inativa, não operacional.

15.20. Deve possibilitar recurso de selecionar uma localização no mapa e

automaticamente trazer fonte de vídeos de câmeras que tenham visibilidade

do ponto selecionado.

15.21. Deve possuir recurso de visão panorâmica do ambiente abrindo todas as

câmeras ao redor de uma câmera numa única ação do operador.

15.22. Deve suportar o recurso de salvar e exportar clipes de vídeo de imagens ao

vivo ou gravados para distribuição e análise pós- eventos.

15.23. Deve possuir recurso de perseguição de vídeo, onde o operador pode

facilmente seguir objetos ou pessoas suspeitas movendo em tempo real,

abrindo câmeras adjacentes assim que o objeto ou pessoa sair da visão de

uma câmera.

16. Sistema de Análise de Conteúdo de Vídeo

16.1. O Sistema de Análise de Conteúdo de Vídeo deve receber as imagens das

câmeras e deverá fazer as tarefas de análise avançada e correlação

melhorando a eficiência do vídeo monitoramento com alarmes em tempo

real.

16.2. Estas tarefas devem incluir funções como identificação e indexação de

imagens, cores, objetos (pessoas, veículos, por exemplo) e velocidade.

16.3. A solução deverá realizar indexação de conteúdo de vídeo destinada a

permitir alertas em tempo real, bem como pesquisas mais rápidas e eficientes

de vídeo. A arquitetura deve ser aberta e deverá oferecer suporte a correlação

de dados provenientes de múltiplas fontes.

16.4. Não deve interferir na gravação de Vídeos pela Rede (Network Vídeo

Recorder), permitindo que sejam gravados os vídeos que passaram pela

análise de conteúdo.

16.5. Os dados de vídeo deverão ser indexados e poder ser utilizados para várias

aplicações.

16.6. Os dados de vídeo devem realizar detecção de danos, identificação de

pessoas e ajudar a lidar com requisitos de conformidade regulatória.

16.7. Deve ser capaz de pesquisar por data / hora, consultas ou alertas.

16.8. Deve permitir consultas baseadas em cor, porcentagem da cor, tamanho

objeto, tipo de objeto (carro ou pessoas), velocidade do objeto.

16.9. Permitir consultas compostas (por exemplo, todos os carros brancos no

centro da cidade desde 2 de janeiro).

16.10. Os padrões deverão ser abertos, permitindo a integração com outros sistemas

de TI, sensores e algoritmos e permitindo suportar o uso dos mesmos dados

por vários aplicativos.

16.11. Deverá ser controlado via web com as características abaixo:

16.11.1. Visualização de vídeo ao vivo ou reprodução de gravações para 1 a 16

câmeras simultaneamente do mesmo ou diferentes servidores.

16.11.2. Navegação de vídeo avançadas, incluindo reprodução lenta/rápida, salto

a data/hora e pesquisa de movimento no vídeo.

16.11.3. Exibições individuais podem ser definidas pelo usuário em vários

layouts: exibição ou reprodução de imagens da câmera de vários servidores

simultaneamente na mesma vista.

16.11.4. Vistas compartilhadas podem ser geridas centralmente, através do

servidor com permissão de administrador, identificado por integração ao

Módulo de Controle de Acesso.

16.11.5. Deve integrar-se ao Módulo de Visualização e ao Módulo de

Georeferenciamento para o display de mapas para navegação rápida entre

câmeras.

16.11.6. Visão geral das seqüências com movimento detectado e janela de

visualização.

16.11.7. Visão geral de eventos / alertas.

16.11.8. Controle de câmeras PTZ remotamente, usando também posições pré-

determinadas.

16.11.9. Controle remoto de PTZ por clique de mouse em ponto.

16.12. Deve monitorar sinais de vídeo digital em tempo quase real, observar os

padrões de comportamento, conteúdo e atividade na cena, desenvolver

modelos internos e memórias da cena dos comportamentos que ocorrem

dentro dela, com as seguintes características:

16.12.1. O sistema deve refinar continuamente o seu entendimento da cena de

vídeo e aperfeiçoar a precisão e a eficiência da detecção, rastreamento,

classificação e reconhecimento de comportamento anormal;

16.12.2. O sistema deve aprender padrões de comportamento dos objetos

observados dentro da cena;

16.12.3. O sistema deve prover usuários com um mecanismo para definir

comportamentos específicos na cena que nunca ou sempre devem ser

alertados;

16.13. Os comportamentos aprendidos pelo sistema na cena não devem ser

baseados em regras definidas por humanos ou expectativas de

comportamentos na cena.

16.14. O sistema deve decidir por ele mesmo como melhor classificar objetos

observados na cena.

16.15. O sistema deve otimizar estas classificações do objeto conforme o campo

particular de cada câmera usando o critério interno de seu sistema.

16.16. O sistema deve ajustar sua abordagem para classificação sem necessidade de

treinamento ou intervenção manual humana.

16.17. O sistema deve manter conjuntos independentes de memórias de

classificação e comportamento para cada campo de visão especifica de cada

câmera.

16.18. O sistema deve automaticamente reconhecer mudanças no campo de visão e

(sem intervenção humana) chavear para o conjunto apropriado de memórias

para este campo de visão em particular.

16.19. O sistema deve ser capaz de alertar atividade ou movimento não usual na

cena.

16.20. O sistema deve ser capaz de alertar interação não usual entre dois ou mais

objetos na cena.

16.21. O sistema deve ser capaz de alertar um trajeto não usual tomado pelo objeto

na cena.

16.22. O sistema deve gerenciar mudança no campo de visão para a câmera

automaticamente e independentemente, e deve reconhecer quando a cena foi

mudada sem intervenção ou reprogramação humana.

16.23. O sistema deve decompor a cena observada separando elementos da cena do

primeiro plano (ativos) e do segundo plano (inativos)

16.24. O sistema deve prover uma interface permitindo usuários especificar o nível

e tipo de alerta relevante para a visão da câmera escolhida.

16.25. O sistema deve incluir ferramenta forense para proporcionar meios de

investigar vídeos gravados recuperando relatórios de incidentes passados.

17. Sistema de Integração de Telefonia

17.1. Deve ser fornecido sistema de integração computador-telefonia, para origem

e recebimento de chamados.

17.2. Atender uma chamada telefônica de emergência utilizando diretamente o

posto de operador, sem a necessidade de um aparelho telefônico acima da

mesa.

17.3. Registrar os dados da chamada telefônica, criando uma ocorrência.

17.4. Permitir que o despachante acione a comunicação via sistema de telefonia

existente, diretamente pelo sistema, sem a utilização de nenhum

equipamento terminal ou rádio adicional, apenas utilizando o posto de

operador.

17.5. Efetue todo o acompanhamento da ocorrência, registrando todas as

informações relevantes, com os respectivos logs e gravações das

comunicações com as informações de data, hora, e ação executada.

17.6. Permitir que o operador escolha a forma de comunicação com os terminais

telefônicos em campo, podendo ser, no mínimo, através de head-sets,

microfones de mesa e pedaleira tipo PTT.

17.7. Deve permitir a construção de sistema de atendimento com reconhecimento

automático de voz de forma a sintetizar as chamadas permitindo que o

cidadão controle o diálogo direcionando para o órgão competente sem perder

a qualidade do atendimento.

17.8. Permite geração de relatórios de todas as interações, inclusive em tempo

real.

17.9. Gravação integrada com funcionalidade de pesquisa de gravações com

suporte a atributos de negócio.

17.10. Suporte aberto via CTI a PABX.

17.11. Capacidade de equalizar a distribuição de chamadas entre os atendentes de

um ou mais grupos de atendimento de forma automática, conforme a

disponibilidade dos atendentes.

17.12. Possuir sistema de anunciadores e/ou mensagens de fila de espera.

17.13. Permitir a inclusão de mensagem de espera aos cidadãos, informando que

todos os atendentes estão ocupados no momento e suas ligações ficarão

temporariamente em espera.

17.14. Permitir a realização de escuta passiva e ativa.

17.15. Permitir o bloqueio de ligações recebidas de telefonia móvel, celular e

telefonia móvel digital para os números DDG e/ou convencional. Os

critérios para bloqueio serão apresentados conforme necessidade da

CONTRATANTE.

17.16. Deve prover sistema de gravação digital de mensagens, registrar todas as

comunicações entre o público e os atendentes, entre estes e os

despachadores, em condições de serem recuperadas.

17.17. Disponibilizar relatórios on-line, com dados do momento (em tempo real),

bem como do histórico dos chamados e de cada grupo/skill de atendimento,

contendo no mínimo:

17.17.1. Permitir a exibição do status de cada atendente (pausa, indisponível,

entre outros disponíveis) e seus motivos (em treinamento, lanche, entre

outros disponíveis), bem como a possibilidade de exportar em arquivo o

histórico do status dos atendentes;

17.17.2. Quantidade de Posições de Atendimento necessárias nos dias úteis,

feriados, sábados e domingos, por turno de serviço, podendo ser ajustado a

qualquer instante do período de balizamento.

17.18. Quanto aos requisitos mínimos de níveis de serviço comuns entre o

atendimento telefônico de primeiro nível básico por acionamento e por

Posição de Atendimento: deverá alcançar a meta para cada indicador de

nível mínimo de serviço, conforme apresentado a seguir:

17.18.1. TME (Tempo Médio de Espera): Tempo Médio que um cidadão aguarda

na fila de espera antes da ligação ser atendida;

17.18.2. ILA (Índice de Ligações Abandonadas): Percentual de ligações

desligadas pelo cidadão antes de ser atendido. Ligações desligadas pelo

cidadão durante a mensagem de anúncio da URA (ou similar), é considerada

como desistência;

17.18.3. IDS (Índice de disponibilidade do Serviço): Percentual de

disponibilidade mensal, POR SERVIÇO, contemplando toda infraestrutura

da SPE para o atendimento telefônico 24 (vinte e quatro) horas dia / 07 (sete)

dias por semana;

17.18.4. TMD (Tempo máximo para despacho): Tempo Máximo para Despacho

de Incidentes;

17.18.5. IQA (Índice de Qualidade do Atendimento): Índice de avaliação da

qualidade do atendimento baseado nas gravações, escutas passiva e na

descrição do acionamento. Os critérios de avaliação são:

17.18.5.1. Cumprimento do script;

17.18.5.2. Cordialidade no atendimento;

17.18.5.3. Cada atendimento avaliado será considerado como: “EM

CONFORMIDADE”, de acordo com regras parametrizáveis pela

CONTRATANTE. Por exemplo, se os dois (02) critérios forem atendidos

adequadamente, ou como: “EM NÃO CONFORMIDADE”, caso um ou

mais critérios não sejam atendidos.

17.18.6. SFA (Percentual de Satisfação do Atendimento): Índice de avaliação do

usuário quanto a satisfação do atendimento prestado nos atendimentos

resolvidos em primeiro nível. Este indicador é aferido com base na resposta

do cidadão a-o final do atendimento;

17.18.7. GR (Gravações realizadas): Percentual de gravação dos atendimentos

telefônico.

17.19. O Sistema deve possuir recurso de comunicação capaz de enviar e-mail,

realizar ligações via sistema de telefonia VOIP SIP e enviar torpedos SMS e

de voz.

17.19.1. A integração será realizada por sistemas disponibilizados pela

CONTRATANTE, sob demanda e via banco de horas de consultoria,

conforme descrito no item 19.

17.20. Deve possuir recurso de rastreamento de mensagens que podem ser filtrados

por parâmetros como data/hora de criação, remetente, usuário ou status da

mensagem.

17.21. Deve suportar conexão telefone a telefone automaticamente ou por demanda

baseado em protocolo SIP.

17.22. Deve fornecer lista de números de telefone eletrônico com recurso de busca,

via integração ao Módulo de Controle de Acesso.

17.23. Deve suportar protocolo SIP, permitindo usuário fazer chamada externa SIP

do discador de telefone ou iniciar uma chamada SIP para um usuário

diretamente do mapa.

17.24. Deve possuir recurso integrado de intercomunicador.

18. Sistema de Controle de Ativos e de Pessoal

18.1. O sistema deve ter módulo integrado de gestão de ativos para inventário a

fim de rastrear a localização, bem como monitorar os ativos de uma

organização.

18.2. Deve possuir funcionalidade para gestão mínima de pessoal e equipes cujo

acionamento seja necessário como resposta a algum evento.

18.3. Deve possuir as seguintes funcionalidades básicas par a ativos:

18.3.1. Administração de todos os tipos de ativos;

18.3.2. Controle de número de série;

18.3.3. Informação se o ativo está disponível para uso imediato ou não;

18.3.4. Processo do tipo workflow para a disponibilidade de ativos;

18.3.5. Controle de alteração de registros de ativos;

18.3.6. Controle de ações corretivas e gestão de problemas;

18.3.7. Administração de incidentes;

18.3.8. Calibrações e manutenções corretivas e preventivas;

18.3.9. Controle de entrada e saída;

18.3.10. Controle do uso de insumos e descartáveis relacionados ao ativo;

18.3.11. Registro de responsáveis pela guarda, manutenção, gerência e

administração do ativo;

18.4. Deve possuir as seguintes funcionalidades para a gestão de pessoal:

18.4.1. Entrada e saída;

18.4.2. Gestão de disponibilidade (férias, descanso, afastamentos, via regras

definidas);

18.4.3. Construção de organogramas;

18.4.4. Skills, aptidões, conhecimentos e funções.

18.5. Deve permitir definição e manutenção de características das unidades

(equipe, viatura, tipo, equipamentos embarcados, etc.).

18.6. Deve permitir a criação de unidades sem equipamentos associados;

18.7. Possibilitar classificação dinâmica de unidades, de acordo com os itens

atribuídos, que definirão, inclusive, o formato de apresentação em mapas;

18.8. Permitir que os tipos de ocorrências estejam disponíveis através de cadastro

prévio através do Módulo de Ocorrências e do Módulo de Procedimentos

Operacionais de Resposta.

18.9. A solução deve possuir uma interface administrativa que possibilite realizar

uma carga inicial de todo o inventário de ativos e pessoal, fornecido pelas

organizações, a serem gerenciados pelo integrador, bem como elementos

georeferenciados estáticos.

18.10. A solução deverá permitir a criação de interfaces, via Módulo de

Visualização, para disponibilizar o acesso desses dados aos outros sistemas

integrantes Central de Monitoramento.

18.11. Além da posição geográfica também deverão ser fornecidas informações

complementares desses elementos, por exemplo: identificação, situação atual

(exemplo: disponível, em atendimento, inativo), entre outras.

18.12. As informações de elementos georeferenciados recebidas deverão ser

enviadas para o sistema para acesso aos demais módulos integrados.

18.13. A solução permitirá a gestão de recursos, com o devido cadastramento de

ativos (recursos) e possibilidade de cadastramento e acompanhamento de

pessoal alocado aos eventos;

18.14. Deve ser integrado ao Módulo de Alarmes e Avisos para que seja possível o

acompanhamento de eventos selecionados e visualização de agendas.

18.15. Deve ser possível a visualização da agenda do período (dia, semana, mês)

contendo os eventos cadastrados e os respectivos impactos na região onde

serão realizados os eventos, através do Modulo de Georeferenciamento;

18.15.1. Permitirá a análise de conflitos de agenda entre os eventos assim como

de participantes alocados em mais de um evento;

18.15.2. Deverá controlar a geração de escalas de trabalho, permitindo a geração

automática das escalas baseadas em critérios especificados sendo que as

escalas geradas deverão poder ser editadas manualmente e modificadas a

qualquer tempo até a data de início da escala.

18.16. A solução disponibilizará, para extração, relatórios gerenciais e analíticos

que contenham os dados de um determinado evento ou comparativos de um

ou mais eventos, incluindo gráficos

18.17. Deve ser multi tenant, habilitando o uso multi-site e em múltipla hierarquia;

19. Serviços de Consultoria (Banco de Horas)

19.1. Os serviços serão prestados pela empresa vencedora, contados a partir da

assinatura do contrato, compostos de:

19.1.1. Serviços de confecção do projeto de implantação, modelagem,

desenvolvimento, instalação e implantação da solução que deverão ser

executados em até 10 (dez) meses, compreendendo:

19.1.1.1. Confecção do Projeto de Implantação

19.1.1.2. Coordenação e suporte a estruturação física e lógica dos ambientes da

Central de Monitoramento

19.1.1.3. Modelagem dos processos de negócio

19.1.1.4. Modelagem de banco de dados Modelagem de banco de dados

Geográficos e carga de dados

19.1.1.5. Configuração de hardware e software da solução

19.1.1.6. Instalação e configuração do software

19.1.1.7. Testes e validação das integrações

19.1.1.8. Controle de qualidade dos dados

19.1.2. Go Live (data formal de início de utilização da solução de software

implantada em ambiente de produção de TI e de operação da

CONTRATANTE)

19.1.2.1. A CONTRATADA deverá prover odo o suporte e informações para a

execução das atividades técnicas necessárias à implantação da solução

completa em ambiente de produção e de suas integrações com outros

sistemas e para verificação do perfeito funcionamento de todos os módulos

no ambiente de operação da CONTRATANTE.

19.1.3. Serviço de Operação Assistida, executado por 2 meses, após a implantação

da solução em ambiente de produção (Go Live), no ambiente da

CONTRATANTE.

19.1.3.1. A CONTRATADA deverá elaborar um roteiro completo com os

procedimentos para atender a sustentabilidade do ambiente de Produção.

19.1.3.2. Este roteiro deverá ser executado em caso de falha de um servidor ou

defeito de software (por exemplo: roteiro para ativação do ambiente de

homologação em substituição ao da Produção, dentro das condições de

desempenho desse ambiente).

19.2. Os serviços serão contratados mediante a emissão de cronograma contendo a

estimativa de esforço a ser dispendido pela CONTRATADA.

19.3. Uma vez aprovado cronograma, a CONTRATANTE emitirá as ordens de

serviços que se fizerem pertinentes.

20. Serviços de Treinamento e Transferência de Tecnologia

20.1. A implantação da solução inclui as atividades de transferência de

conhecimento e disponibilização de documentação técnica e operacional

acerca das soluções, acessórios e procedimentos.

20.2. Disponibilização de transferência de conhecimento presencial relacionado à

operação cotidiana, ao suporte básico, à administração e à configuração das

soluções. Sendo necessária composição de transferência de conhecimento

específica para, no mínimo, 4 (quatro) grupos de até 30 (trinta) alunos,

conforme especificado:

20.2.1. Grupo Gestão, composto por colaboradores de administração e coordenação

da Central de Monitoramento, com pelo menos 4 (quatro) horas*aula,

contemplando:

20.2.1.1. Funcionalidades gerais de operação.

20.2.1.2. Visão geral de gestão de eventos e riscos.

20.2.1.3. Operação básica (informações de cadastros, ações e agenda, entre outros)

20.2.1.4. Cadastro de novos eventos, recursos, planos de ação, rotas, riscos,

pessoas;

20.2.1.5. Utilização de recursos de Workflow;

20.2.1.6. Integração com sistemas de georeferenciamento;

20.2.1.7. Extração de relatórios gerenciais e analíticos;

20.2.2. Grupo operacional, composto por colaboradores de operação cotidiana da

solução, de pelo menos 16 (dezesseis) horas*aula, contemplando:

20.2.2.1. Operação básica (informações de cadastros, ações e agenda, entre outros)

20.2.2.2. Cadastro de novos eventos, recursos, planos de ação, rotas, riscos,

pessoas;

20.2.2.3. Utilização de recursos de Workflow;

20.2.3. Grupo técnico e de manutenção, composto por colaboradores técnicos das

áreas de operações de TI e infraestrutura, com pelo menos 8 (oito)

horas*aula, contemplando:

20.2.3.1. Instalação e configuração do sistema e as ferramentas fornecidas.

20.2.3.2. Incluir e remover usuários e grupos.

20.2.3.3. Realizar tarefas de manutenção de suporte de primeiro nível

20.2.3.4. Utilização de funcionalidades de georeferenciamento

20.2.3.5. Detecção e correção de problemas

20.2.3.6. Tuning

20.2.4. Grupo de desenvolvimento, composto por colaboradores técnicos da área de

desenvolvimento de software e componentes integráveis à solução,

contemplando um mínimo de 40 (quarenta) horas*aula, com os seguintes

tópicos:

20.2.4.1. Introdução ao framework;

20.2.4.2. Modelo de dados;

20.2.4.3. Extensão de funcionalidades do framework de integração;

20.3. Deve ser previsto o fornecimento de documentação em Português Brasileiro

da solução e dos treinamentos, contemplando:

20.4. Manuais impressos e procedimentos de usuários;

20.5. Descritivo de funcionalidades,

20.6. Detalhamento de operações de sistema e indicativo de simbologias

utilizadas;

20.7. Desenhos dos componentes de hardware, software e redes de comunicação.

20.8. Documentos com a descrição dos processos internos da solução e estruturas

de dados relevantes;

20.9. Documentação das configurações contidas no pacote de software.

20.10. Documentação de especificações funcionais e desenvolvimentos adicionais.

20.11. Recursos de treinamento como e-Learnings, tutoriais e guias passo a passo;

20.12. Documentação de servidores, banco de dados, versões de produtos,

componentes lógicos e componentes de software;

20.13. Manuais e procedimentos de suporte;

20.14. Manuais e procedimentos técnicos e operacionais, em Português Brasileiro

20.15. ou em inglês, disponíveis em arquivos eletrônicos, contendo, pelo menos,

informações sobre procedimentos técnicos necessários, catálogo de

mensagens de sistema comuns e ações corretivas necessárias, catálogos de

funcionalidades, dicionário de dados, descritivo de interfaces, diagramas de

conexões, características técnicas e requerimentos legais.

21. Garantia, Suporte e Manutenção

21.1. O objeto deste Termo de Referência também contempla o suporte técnico e a

manutenção das soluções e sistemas fornecidos

21.2. Por todo o período de contrato, e até 12 meses após o fim do período de

operação assistida, a CONTRATADA deve prover suporte técnico

especializado, garantindo alta disponibilidade e desempenho das plataformas

tecnológicas em operação.

21.3. Deve atender prontamente correções e alertas derivados da ferramenta de

monitoração do ambiente tecnológico.

21.4. Deve proceder a atualização da base de conhecimento de suporte:

acompanhar a revisão e atualização dos procedimentos operacionais

(documentos), pesquisando novas soluções, analisando criticamente os

processos e propondo melhorias, solicitar procedimento aos fornecedores.

21.5. Deve interagir com fornecedores e parceiros para resolução, tratativa e

acompanhamento das soluções de incidentes e problemas.

21.6. A CONTRATADA é obrigada a reparar, corrigir, remover, reconstruir ou

substituir, às suas expensas, no total ou em parte, o objeto do contrato em

que se verificarem vícios, defeitos ou incorreções resultantes da execução ou

de materiais empregados.

21.7. A garantia inclui todas as ações de manutenção corretiva, com vistas a

garantir o total funcionamento da solução, a saber:

21.7.1. Defeitos de software;

21.7.2. Assistência na determinação de problemas;

21.7.3. Questões específicas de uso e instalação de curta duração para funções

documentadas;

21.7.4. Perguntas sobre compatibilidade de produtos e componentes de software;

21.7.5. Auxílio na interpretação de publicações oficiais da solução;

21.7.6. Pesquisas nos bancos de dados de problemas/soluções da solução.

21.8. Durante o período de garantia, a CONTRATADA deverá atender todo e

qualquer chamado, relacionado ao funcionamento da solução, que venha a

receber da CONTRATANTE, e resolver o problema no menor prazo

possível, a contar da abertura do chamado técnico,

21.9. O início do atendimento não poderá ultrapassar o prazo de 02 (duas) horas,

contado a partir da abertura do chamado pela CONTRATANTE.

21.10. Uma vez que a solução do problema tenha sido enviada pela

21.11. CONTRATADA e testada pela CONTRATANTE, estando esta e a

CONTRATADA em conformidade com o encerramento do chamado, os

especialistas da CONTRATADA finalizam o atendimento.

21.12. Caso o INEA não possa testar a solução no curto prazo, a CONTRATADA

deverá colocar o chamado em “stand-by” deixando-o disponível para

reabertura por um período de até 30 (trinta) dias em caso de dúvida futura.

21.13. A garantia deverá ser prestada, observando as seguintes condições:

21.13.1. Fornecimento e substituição de componentes que apresentarem defeitos,

identificados dentro das condições normais de operação ou que necessitarem

reposição em virtude da evolução de outros componentes da solução;

21.13.2. Os chamados de acionamento da garantia deverão ser abertos por meio

de central de abertura de chamados, a partir de número 0800 ou número local

do Município de São Paulo , com atendimento telefônico, de segunda a

sexta-feira, em horário comercial (das 09:00hs às 18:00hs), exceto feriados,

para qualquer tipo de dúvida ou problema, atendimento telefônico, vinte e

quatro horas por dia, sete dias por semana, para problemas críticos

considerados de Severidade 1 ou 2;

21.13.3. O momento da abertura do chamado deverá ser fornecido para a

CONTRATANTE um número único de identificação do chamado;

21.13.4. Os dados dos chamados, bem como das providências tomadas, devem ser

armazenados em sistema da CONTRATADA para controle de chamados.

Esse sistema deverá estar disponível ao acesso da CONTRATANTE e ter

capacidade de apresentar número do chamado, data e hora de abertura, nome

da pessoa que abriu e do técnico alocado, descrição dos problemas, bem

como dados das atividades executadas, data e hora de fechamento do

chamado e solução aplicada;

21.13.5. Iniciar o atendimento telefônico em até 2 (duas) horas, após a

comunicação do problema pela CONTRATANTE, que classificará os

problemas reportados de acordo com seu grau de severidade, segundo a

seguinte classificação:

21.13.5.1. Para os casos de severidade 1, se o suporte de nível 1 não conseguir

resolver o problema até três horas após a abertura do chamado, o chamado

deverá ser escalado e poderá chegar até a equipe de laboratório responsável

pelo produto.

21.13.6. Para os casos de severidade 2, se o suporte não conseguir resolver o

problema em até 6 (seis) horas após a abertura do chamado, este deverá ser

escalado e poderá chegar até a equipe de laboratório responsável pelo

produto.

21.14. A critério da CONTRATANTE, um chamado poderá ser escalado para nível

de severidade diferente do originalmente aberto e será considerado o nível de

serviço do novo nível, a partir do momento da escalação.

21.15. Com exceção de parada programada e acordada previamente com a

CONTRATANTE, de no máximo 12 (doze) horas, nenhuma manutenção

deverá acarretar indisponibilidade da solução.

21.16. Os chamados somente poderão ser fechados após autorização do gestor do

contrato.

21.17. Mensalmente, quando houver acionamento da garantia, a CONTRATADA

deverá encaminhar à CONTRATANTE relatório com todos os chamados de

manutenção abertos e fechados, contendo os detalhes de abertura e

fechamento do chamado e da solução aplicada.

21.18. A prestação dos serviços relacionados a suporte e manutenção durante o

período de garantia e respectivas condições de atendimento informadas neste

documento deve ser de responsabilidade da CONTRATADA.

22. Quantitativos, volumes e níveis de serviço (SLA)

22.1. Os dados aqui apresentados devem ser considerados como quantitativos

iniciais mínimos para instalação.

22.2. As licenças de software não devem possuir restrições para número de

usuários nem em número de servidores (ou de processadores).

Ambiente Número .de

usuários

Número de

usuários

simultâneos

Número de

ocorrências

por dia

SLA

mínimo do

ambiente

Desenvolvimento 100 10 500 97%

Homologação 50 5 100 97%

Produção I 1000 100 35.000 99%

Produção II

(redundância)

1000 100 35.000 99%

Treinamento 20 20 200 97%

Módulo Valor

Ocorrências

Procedimentos Operacionais de Resposta

Atendimento e Despacho

Georreferenciamento

Alarmes e Avisos

Estatísticas e Relatórios

Framework web

Integração de Sistemas e Sensores

Mídias

Controle de Acesso

Vídeo Monitoramento

Auditoria e Logs

Backup e versionamento

TOTAL

Sistema Unidade de

medida Quantidade Valor Unitário Valor Total

Sistema Controle

de Ativos e

Pessoal

- 1

Sistema de

Análise de

Conteúdo de

Vídeo

Streams de vídeo 300

Sistema de

Telefonia

Links E1 10

Serviços de

Consultoria

(banco de horas)

Horas de trabalho 8000

(oito mil)

Treinamento Turmas de 20

alunos

5 (cinco)

Transferência de

Tecnologia

Turmas de 5

alunos

2 (dois)

Operação

Assistida

Mês 3 (três)

Garantia, suporte

e manutenção

Mês 36

(trinta e seis)

23. Projeto e primeira implantação

23.1. A primeira implantação corresponde à instalação do objeto contratado e a

realização de integrações com sistemas pré-existentes, de posse ou de

responsabilidade da CONTRATANTE, ou ainda de seus parceiros.

23.1.1. A primeira implantação deverá ser realizada em prazo não superior a 90

(noventa) dias após a assinatura do contrato.

23.1.2. Os sistemas pré-existentes a serem integrados à Central de Monitoramento e

os requisitos da primeira implantação serão definidos em comum acordo

com a CONTRATANTE, de forma que os prazos sejam exeqüíveis.

23.1.3. A primeira implantação será realizada em ambiente disponibilizado pela

CONTRATANTE, na forma de:

23.1.3.1. Servidores físicos ou virtuais do tipo compatível com arquitetura 80x86;

23.1.3.2. Sistema operacional: Microsoft Windows Server, RedHat Linux ou

CentOS;

23.1.3.3. Bases de dados: SQL Server, Oracle, DB2, PostgreSQL ou MySQL;

23.1.3.3.1. As bases de dados serão disponibilizadas em duas formas: acesso a uma

instalação corporativa, ou instalações em hardware dedicado (a depender

dos critérios técnicos de capacidade e disponibilidade);

23.1.3.4. Área de armazenamento (storage).

23.1.3.4.1. O armazenamento será oferecido na forma de SAN via interfaces HBA

Fibre Channel em servidores dedicados ou NAS, nos protocolos CIFS e

NFS.

23.2. A CONTRATADA será responsável pela elaboração de Projeto de

Implantação, contemplando:

23.2.1. Cronograma geral e prazos para execução;

23.2.2. Cronograma detalhado (WBS) com indicação dos responsáveis pelas

atividades e respectivos prazos;

23.2.3. Requisitos de hardware, software básico (sistemas operacionais, servidores

web e banco de dados) e de comunicação;

23.2.4. Formalização dos prazos máximos para a entrega dos equipamentos, dos

serviços de banco de dados (por meio de servidores dedicados ou pelo acesso

a servidores corporativos) e das áreas de armazenamento;

23.2.5. Carga inicial do sistema e operações de transferência de dados ou de ETL

que se fizerem necessárias;

23.3. As atividades referentes à elaboração do planejamento da primeira

implantação fazem parte do escopo de contratação, incluindo:

23.3.1. Participação de reuniões;

23.3.2. Gestão de atividades;

23.3.3. Gestão de pessoas;

23.3.4. Desenvolvimento;

23.3.5. Administração de sistemas;

23.3.6. Instalação de software

23.3.7. Análise de requisitos;

23.4. A confecção do planejamento e a execução das atividades dele originadas

será sujeita à utilização do Banco de Horas contratado, podendo incluir aqui

as seguintes atividades:

23.4.1. Desenvolvimento;

23.4.2. Customização;

23.4.3. Instalação de software;

23.4.4. Sizing;

23.4.5. Otimização e tuning;

23.4.6. Carga e processamento de dados (ETL);

23.4.7. Gestão de projetos e de pessoas;

24. Papéis e Responsabilidades

24.1. No decorrer da execução deste contrato, cabe à CONTRATADA:

24.1.1. A elaboração e execução do Projeto de Implantação, contemplando:

24.1.1.1. A elaboração de cronograma de implantação e work breakdown structure

(WBS);

24.1.1.2. A elaboração de descritivo completo da arquitetura mínima necessária ao

Sistema, composta de hardware e software básico, para os ambientes de

desenvolvimento, homologação, produção I, produção II (contingência) e

treinamento;

24.1.1.3. A elaboração da documentação referente ao desenvolvimento, tais como

casos de uso; diagrama de classes; diagrama de chamadas; padrões de

nomenclatura de variáveis, funções, métodos e classes;

24.1.2. O Projeto de Implantação e a sua execução devem levar em consideração

fatores tais como:

24.1.2.1. A oferta ou a capacidade disponível de equipamentos, sistemas e

serviços no tempo de execução do Projeto;

24.1.2.2. O tempo para a aquisição de insumos que não estejam prontamente

disponíveis;

24.1.2.3. A minimização de custos de aquisição (tais como o software e hardware)

e de manutenção (por exemplo, energia e ar condicionado), visando uma

solução que apresente melhor economicidade;

24.1.2.4. O completo atendimento dos requisitos, dos níveis de serviço e da

volumetria mensurada ou definida;

24.1.3. A elaboração da documentação de instalação e uso do Sistema;

24.1.4. A carga inicial do Sistema da Central de Monitoramento

24.1.5. O fornecimento de assistência e consultaria para a implantação do Sistema;

24.1.6. O treinamento inicial de usuários e replicadores;

24.1.7. Assegurar a completa transferência de tecnologia utilizada no Sistema;

24.1.8. A cessão de direitos para a CONTRATANTE sobre o sofware desenvolvido,

permitindo a manutenção do mesmo por esta última;

24.2. A CONTRATANTE será responsável por:

24.2.1. Disponibilização da infraestrutura física, lógica e hardware

24.2.1.1. Cabeamento físico, switches, roteadores, links e conectividade;

24.2.1.2. Disponibilização e administração de servidores padrão x86, sua

instalação física e hospedagem;

24.2.1.3. Storage SAN, via HBA do tipo Fibre Channel;

24.2.1.4. Storage NAS, nos protocolos CIFS e NFS;

24.2.1.5. Ambiente de datacenter com infraestrutura de energia elétrica,

refrigeração (condicionamento de ar), segurança física, lógica e controle de

acesso;

24.2.1.6. Gestão da configuração e capacidade.

24.2.2. Software básico, composto por:

24.2.2.1. Sistema Operacional: Microsoft Windows Server, Linux (RHES ou

CentOS);

24.2.2.2. Servidores web: IIS em ambiente Windows e Apache em ambiente

Linux;

24.2.2.3. Bancos de Dados (SQL Server, Oracle, DB2, PostgreSQL, e MySQL)

24.2.3. Tarefas associadas ao Projeto de Implantação:

24.2.4. Consulta aos parceiros e clientes para o mapeamento das informações

referentes à criação do Projeto de Implantação;

24.2.5. Definição das integrações iniciais necessárias;

24.2.6. Disponibilizar os ambientes de desenvolvimento e homologação, segundo a

arquitetura aprovada definida no Projeto de Implantação e aprovada pela

própria CONTRATANTE.

24.2.7. Aprovação final do Projeto de Implantação;

25. Cronograma de Entrega

25.1. Deve ser seguido o seguinte cronograma-macro, com início na data de

assinatura do contrato.

25.1.1. Alterações podem ser feitas, se aprovadas pela CONTRATANTE.

Atividade Prazo (a partir da assinatura do

contrato)

Sizing – Projeto Piloto (Chuvas de Verão) 15 dias

Implantação – Projeto Piloto 90 dias

Treinamento 120 dias

Implantação Central 180 dias

ANEXO A

PROJETO PILOTO

PREFEITURA DO MUNICIPIO DE SÃO PAULO

SECRETARIA DE COORDENAÇÃO DAS SUBPREFEITURAS Coordenadoria Municipal de Defesa Civil -COMDEC

PLANO CHUVAS DE VERÃO –

PRINCIPIOS, FLUXOS E PROCEDIMENTOS – 1ª VERSÃO.

1. Introdução

No período do verão a ocorrência de eventos pluviométricos ganham maior

freqüência e são agravados, entre outros aspectos, pelas mudanças climáticas

e pelo próprio processo de estruturação das grandes cidades. Este quadro,

somado a ocorrência destes eventos, aumenta consideravelmente a

vulnerabilidade da Cidade de São Paulo aos riscos ambientais relacionados às

chuvas, como os escorregamentos e os alagamentos/enchentes, acarretando,

muitas vezes, em decorrência de extremos climáticos, transtornos a população.

Neste sentido, torna-se necessária a adoção de uma política pública que

priorize a implantação de um gerenciamento permanente baseado em dois

eixos de ação: prevenção e preparação. Como resposta a esta necessidade, a

Prefeitura do Município de São Paulo está estabelecendo um plano preventivo

para o gerenciamento de riscos associados ao período crítico de pluviosidade

na cidade denominado “Plano Preventivo Chuvas de Verão”.

Este plano, que tem com objetivo principal a redução ou a minimização dos

efeitos e consequências destes riscos sobre a população, é pautado pela

integração de todos os órgãos de administração pública; otimização de

recursos; definição de procedimentos, atribuições e responsabilidades; fluxos

de comunicação e informação pública, além de envolver a população na

operação do Plano, especialmente os moradores de áreas de risco de

escorregamentos e enchentes.

A Prefeitura entende que a implantação deste plano, que está dentro das

diretrizes na nova Política Nacional de Proteção e Defesa Civil (Lei Federal nº

1.2608/2012) irá fortalecer a cultura permanente do gerenciamento destes

riscos que é essencial para que a população tenha melhores condições para

enfrentar o período de chuvas deste próximo verão. A ação integrada, no

entanto, deve ser somada aos investimentos na infraestrutura da cidade,

através de obras de drenagem, canalização, serviços de conservação e

limpeza e outras intervenções não-estruturais (reflorestamento, ampliação de

áreas permeáveis, remoção de moradias em planícies de inundação, etc).

2 – Órgãos envolvidos

O Plano Chuvas de Verão procura envolver todos os órgãos da administração

municipal. Todavia alguns órgãos possuem uma ação mais direta com funções

e procedimentos definidos, onde relacionamos:

2.1 Órgãos da Administração Municipal

1. Secretária Municipal de Coordenação das Subprefeituras – SMSP –

através da Coordenadoria Municipal de Defesa Civil e o Centro de

Controle Integrado – CCOI, que possuem centrais de comunicação que

serão unificadas, e as Coordenadorias Distritais de Defesa Civil –

CODDECs., organizadas por subprefeituras e que possuem como canal

de comunicação as salas de estratégias ou salas de rádio;

2. Secretária Municipal de Segurança Urbana – SMSU através da Guarda

Civil Metropolitana – que possui uma central de comunicação – CETEL –

central 153;

3. Secretária Municipal de Infraestrutura Urbana e Obras – SIURB através

do Centro de Gerenciamento de Emergências – CGE., que é

responsável pelo monitoramento e disseminação de informações

relativas a situação meteorológica da cidade.

4. Secretária Municipal de Transportes – SMT – através da Companhia de

Engenharia de Tráfego que possui uma central de informações

5. Secretária Municipal de Assistência e Desenvolvimento Social – SMADS

– através da CAPPE – que é uma central de atendimento a

emergências;

6. Secretária Municipal da Saúde – SMS, através do CIEVS ( Centro de

Informações Estratégicas em Vigilância em Saúde); do Serviço Médico

de Urgência – SAMU – CENTRAL 192; Centro de Controle de Zoonoses

- CCZ .;

7. Secretária Executivo de Comunicação - SECOM;

2.2. – Órgãos da Administração Estadual

2.2.1 – Ação Direta a ocorrências

1. Corpo de Bombeiros – Central 193 – ação direta no atendimento a

emergências/ busca e salvamento

2. AES Eletropaulo – também possui uma central e tem interface nas

ocorrências relacionadas a queda de arvores;

2.2.2 – Ação suplementar e eventual a ocorrências

1. Companhia de Saneamento Básico no Estado de São Paulo – SABESP

atua em ocorrências que envolvam a rede de distribuição, com destaque

para adutoras;

2. Companhia de Gás de São Paulo - COMGÁS - atua em ocorrências que

envolvam a rede de distribuição, com destaque para a rede de

distribuição de gás natural;

3. Petrobrás Transportes S.A – TRANSPETRO - atua em ocorrências que

envolvam a rede de distribuição, com destaque para os dutos de

distribuição de combustíveis (gasolina diesel, GNV);

4. Companhia do Metropolitano de São Paulo – fluxo de informações sobre

a situação meteorológica e estado de criticidade na cidade para

balizamento de eventuais ações que envolvam o transporte;

3. Companhia de Trêns Metropolitanos – CPTM - fluxo de informações

sobre a situação meteorológica e estado de criticidade na cidade para

balizamento de eventuais ações que envolvam o transporte;

4. Empresa Metropolitana de Transportes Urbanos – EMTU - fluxo de

informações sobre a situação meteorológica e estado de criticidade na

cidade para balizamento de eventuais ações que envolvam o

transporte;

5. SOCICAM – Terminais Rodoviários do Tietê, Jabaquara e Barra Funda -

fluxo de informações sobre a situação meteorológica e estado de

criticidade na cidade para balizamento de eventuais ações que

envolvam o transporte;

6. Agência de Transporte no Estado de São Paulo – ARTESP - fluxo de

informações sobre a situação meteorológica e estado de criticidade na

cidade para balizamento de eventuais ações das concessionárias de

rodovias (Via Oeste; Ecovias; Autoban etc) com relação a situação de

circulação e ingresso de veículos via rodoviária na cidade de São Paulo;

3. CRITÉRIOS TECNICOS PARA DEFLAGRAÇÃO DOS ESTADOS DE

CRITICIDADE DO PLANO

O CGE tem como responsabilidade a previsão do tempo, monitoramento das

condições meteorológicas e pluviométricas e a indicação dos estados de

criticidade para escorregamentos, alagamentos e enchentes. Os estados de

criticidade, estarão vinculados á gravidade do risco, seguindo critérios técnicos,

previamente estabelecidos e estarão balizando todo o andamento do plano. A

partir daí todos os órgãos participantes do plano adotarão os procedimentos

correspondentes as suas funções e responsabilidades e que estão

apresentados nos conteúdos dos respectivos grupos temáticos.

Os estados de criticidade do PLANO PREVENTIVO CHUVAS DE VERÃO – e

os procedimentos correspondentes a serem adotados serão determinados pelo

índice pluviométrico, pela previsão meteorológica e pelos indicadores de

campo e serão decretados por Subprefeitura no caso de enchentes e

escorregamentos e, também, por Gerência de Engenharia de Trafego –

GET/CET no caso de enchentes. A partir daí o CGE analisa e indica os

estados de criticidade para os cenários relacionados a escorregamentos,

enchentes e alagamentos, sendo que em algumas situações será emitido um

pré-aviso de tempo severo. Este pré-aviso tem como objetivo fornecer aos

órgãos participantes do plano, dentro da antecedência possível e das

condições significativas de chuva, informações sobre a situação da cidade.

ALAGAMENTOS

OBSERVAÇÃO Todo o período de vigência do Plano.

ATENÇÃO Chuva com potencial de alagamento.

ALERTA Alagamentos generalizados intransitáveis e continuidade das chuvas.

ALERTA MÁXIMO Alagamentos generalizados intransitáveis, associados a extravasamento de rios e córregos, dimensão do evento supera a capacidade de atendimento do município gerando forte impacto nos sistemas de trânsito e transporte, necessitando do apoio de instituições federais e/ou estaduais.

INUNDAÇÕES

OBSERVAÇÃO Todo o período de vigência do Plano.

ATENÇÃO Chuva com potencial de transbordamento dos córregos ou rios e previsão de continuidade das chuvas nas cabeceiras.

ALERTA Transbordamento dos córregos e rios e continuidade das chuvas nas cabeceiras.

ALERTA MÁXIMO Transbordamentos de rios e córregos generalizados e a dimensão do evento supera a capacidade de atendimento do município, necessitando do apoio de instituições federais e/ou estaduais.

ESCORREGAMENTOS

OBSERVAÇÃO Todo o período de vigência do Plano.

ATENÇÃO Chuva acumulada de 50mm em 72 horas e previsão de continuidade das chuvas e necessidade de remoções.

ALERTA Escorregamentos generalizados com previsão de chuvas moderadas e fortes, necessidade de remoções.

ALERTA MÁXIMO Dimensão do evento supera a capacidade de atendimento do município, necessitando do apoio de instituições federais e/ou estaduais.

3.1 – FLUXOS PARA DECRETAÇÃO DOS ESTADOS DE CRITICIDADE

A indicação dos estados de criticidade relativos aos alagamentos, enchentes e

escorregamentos ficará sob a responsabilidade do CGE, sendo que a

decretação dos estados de criticidade respeitarão os seguintes prodedimentos:

3.1.1 ALAGAMENTOS

A decretação dos estados de criticidade relativos a alagamentos de vias, por

questões de agilidade e de informações de campo fornecidas pelos agentes da

Companhia de Engenharia de Tráfego – CET, ficará sob a responsabilidade do

Centro de Gerenciamento de Emergências – CGE que informará a Central de

Operações da Companhia de Engenharia de Tráfego – CET e os demais

órgãos participantes do plano;

3.1.2. ESCORREGAMENTOS E ENCHENTES

A decretação dos estados de criticidade relativos a escorregamentos e

enchentes, a partir da indicação do Centro de Gerenciamento de Emergências

–CGE ficará sob a responsabilidade da Coordenadoria Municipal de Defesa

Civil – COMDEC através do seu Centro de Comunicações – CECOM 199 que

deverá informar as respectivas Coordenadorias Distritais de Defesa Civil –

CODDECs das Subprefeituras e os demais órgãos participantes do presente

plano de acordo com as diretrizes e fluxos pré-estabelecidos.

4. FLUXOS DE ATENDIMENTO DE OCORRÊNCIAS POR PARTE

DAS COORDENADORIAS DISTRITAIS DE DEFESA CIVIL -

CODDECs

Nas Coordenadorias Distritais de Defesa Civil – CODDECs, organizadas por

subprefeituras, os fluxos de atendimento as respectivas ocorrências deverão

ser adequados as respectivas realidades, ressaltando que as ocorrências

também poderão ter sua entrada através das salas de rádio instaladas em cada

subprefeitura:

4.1 ENCHENTES

A partir da entrada de uma ocorrência relacionada a enchentes o CECOM 199

entra em contato com as respectivas subprefeituras (CODDECS) através das

salas de rádio ou de situação, dependendo da organização local e informa

todos os dados relativos a ocorrência para atendimento por parte do respectivo

CODDECs..

4.2

ESCORREGAMENTOS

. A partir da entrada de uma ocorrência relacionada a escorregamento o

CECOM 199 entra em contato com as respectivas subprefeituras (CODDECS)

através das salas de rádio ou de situação, dependendo da organização local e

informa todos os dados relativos a ocorrência para atendimento por parte do

respectivo CODDECs..

4.3 QUEDAS DE ÁRVORES

A partir da entrada de uma ocorrência relacionada à queda de arvores o

CECOM 199 entra em contato com as respectivas subprefeituras (CODDECS)

através das salas de rádio ou de situação, dependendo da organização local e

informa todos os dados relativos a ocorrência para atendimento por parte do

respectivo CODDECs..

5. REGISTRO E GERENCIAMENTO DAS OCORRÊNCIAS

Como o CECOM 199 da COMDEC não possui um sistema para registro e

gerenciamento de ocorrências No Plano Chuvas de Verão 2013-2014, a partir

de entendimentos que culminariam para que o CECOM 199 passasse a utilizar

o SGOC do CCOI, todas as informações referentes a ocorrências durante o

período de vigência do plano (01.11.13 a 15.04.14) deveriam ser

encaminhadas ao CCOI via SGOC que possui um processo para registro e

gerenciamento das ocorrências.

Todavia, a rotina de registro do CECOM 199 baseia-se em fichas de registro de

ocorrências, denominado de “Talão” que tem todo um processo manual, no

registro inicial e manual em um livro e posteriormente em uma ficha Word,

sendo que após atendimento por parte do CODDECs o mesmo devera

retornar ao CECOM 199 via fone para dar o que denominam

“baixa no talão”.

Como forma de organizar as informações o CECOM 199 criou um sistema de

planilhas excell que registram todas as informações relativas a ocorrências.

Como o processo de integração CECOM 199 – CCOI é uma realidade esta

rotina estará sendo readequada, inclusive com a integração dos CODDECs, e

será de extrema importância para a migração e adequação ao sistema que irá

se implantar.

São Paulo, 03 de setembro de 2014

Ronaldo M. Figueira

ANEXO B

HOMOLOGAÇÃO

1. HOMOLOGAÇÃO (QUALIFICAÇÃO TÉCNICA)

1.1. O envelope “número 1” também deverá possuir os seguintes documentos

para habilitação técnica:

1.1.1. Termo de Conformidade aos Requisitos Técnicos Obrigatórios, conforme

modelo do Anexo C, assinado por representante legal da proponente.

1.1.2. Atestado ou cópia autenticada de atestado de capacidade técnica, referentes a

Ordens de Serviço e/ou Contratos, atestando que foi executado o serviço de

forma satisfatória, emitido por pessoa jurídica de direito público ou privado,

do Brasil ou do exterior, em que a proponente tenha prestado serviço

compatível em características, quantidades e prazos ao serviço a ser

contratado, citando obrigatoriamente o dimensionamento da solução

implantada.

1.1.3. Relação dos componentes de software que comporão o Sistema da Central

de Monitoramento.

1.1.4. Declaração de Entrega dos Componentes do Sistema da Central de

Monitoramento, garantindo o fornecimento dos componentes de software

exigidos ou necessários ao seu adequado e correto funcionamento, inclusive

aqueles não compilados, encapsulados, inacessíveis ou proprietários,

relativos às funcionalidades do sistema computacional ofertado,

1.1.5. Declaração que está ciente que a CONTRATANTE é a detentora exclusiva

dos direitos de uso, divulgação e reprodução, por quaisquer meios, do

Sistema da Central de Monitoramento, objeto desta licitação.

1.1.6. Declaração de que entregará, total e irrestritamente, para a

CONTRATANTE, a documentação completa do sistema, tais como:

códigos-fonte, especificações funcionais internas, casos de uso, diagramas de

classe e de arquitetura, modelo de dados, dicionário de dados, manuais de

usuário e de produção, scripts de configuração e instalação do SGDB, scripts

de instalação e configuração dos servidores e quaisquer dados necessários à

completa absorção tecnológica do Sistema da Central de Monitoramento.

1.1.7. Declaração contendo os requisitos técnicos para a Homologação, que

deverão ser disponibilizados pela CONTRATANTE, limitados a:

1.1.7.1.Dez (dez) máquinas virtuais, acessíveis via Remote Desktop, VNC ou SSH

com as seguintes configurações:

1.1.7.1.1. Processador x86 64bits

1.1.7.1.2. Sistema Operacional: Linux (CentOS ou RHEL) ou Windows 2008

Server;

1.1.7.1.3. Storage: até 30 (trinta) GB de HD

1.1.7.1.4. Conectividade

1.1.7.1.4.1.Sistemas internos, via rede LAN

1.1.7.1.4.2.Internet;

1.1.7.1.4.3.Acesso a servidor SGBD SQL Server, MySQL, DB2 ou PostgreSQL

1.1.7.1.5. Estações clientes rodando Windows XP ou Windows 7 Professional,

clientes VNC, Remote Desktop e SSH.

1.1.8. Não farão parte dos limites definidos no item acima as máquinas virtuais que

hospedarão as soluções de software providas pela CONTRATANTE e que

serão alvo das integrações.

2. PROCESSO DE HOMOLOGAÇÃO.

2.1. O processo de homologação será aplicado à proponente vencedora do

certame, aquela que ofertou a solução melhor classificada, a fim de se

verificar se são atendidos os requisitos técnicos mínimos necessários à

implantação através de sua efetiva utilização

2.2. A avaliação será feita por técnicos designados pela Comissão de Licitação

em ambiente específico, nas dependências da CONTRATANTE e contará

apenas com o seu auxílio logístico, compreendendo:

2.2.1. Disponibilização de máquinas virtuais;

2.2.2. Software básico (Sistema Operacional);

2.2.3. Conectividade (internet e demais sistemas a serem integrados);

2.2.4. Banco de Dados (SQL Server, DB2, PostgreSQL ou MySQL);

2.3. Será considerada eliminada da licitação a proponente que, na qualificação

técnica, não atingir a totalidade dos objetivos de atendimento aos requisitos.

2.4. A instalação do Sistema da Central de Monitoramento e os módulos que o

compõem será executada pela proponente, sendo esta a única responsável

por esta tarefa.

2.5. A avaliação ocorrerá de acordo com o explicado a seguir.

2.5.1. A CONTRATANTE terá até 10 (dez) dias úteis para a preparação do

ambiente, com base na declaração definida no item 1.1.7 deste Anexo B.

2.5.1.1.O ambiente será disponibilizado, impreterivelmente, em horário comercial,

das 10:00 às 18:00, nos dias úteis.

2.5.2. Após a disponibilização do ambiente, a proponente terá até 15 (quinze) dias

úteis para realizar a instalação, configuração e integração dos sistemas, no

ambiente disponibilizado pela CONTRATANTE.

2.5.3. Representantes da proponente com conhecimento técnico sobre as

funcionalidades do sistema e conhecedores da avaliação em pauta deverão

obrigatoriamente estar presentes para o acompanhamento e auxílio na

avaliação.

2.5.4. Serão avaliados os requisitos obrigatórios descritos no item 3 a seguir. Caso

haja funcionalidades não atendidas na avaliação em pauta, estas constarão

em relatório elaborado pelos técnicos designados pela Comissão de

Licitação.

2.5.5. A proponente terá, então, 5 (cinco) dias úteis para implementar as

funcionalidades em desacordo, dispondo do mesmo ambiente

computacional.

2.5.6. Qualquer proponente ainda participante do processo licitatório poderá

indicar 1 (um) representante para o acompanhamento desta etapa,

formalizando a indicação através de Ofício enviado à Comissão Especial de

Licitação em até 10 dias corridos da data informada da homologação.

2.5.6.1.Os representantes indicados poderão acompanhar esta etapa, podendo se

manifestar quanto ao teste apenas na fase de recurso.

2.5.7. Caso não seja atendido algum requisito obrigatório, a proponente será

imediatamente excluída da licitação, sem prejuízo da aplicação das

penalidades cabíveis.

3. ESCOPO DA HOMOLOGAÇÃO

3.1. A PROPONENTE deverá efetuar, em ambiente computacional provido pela

CONTRATANTE, as seguintes integrações com os seguintes sistemas e

órgãos listados na tabela a seguir:

Órgão/Aplicação Integração

SMSP (SGOC) Acesso direto a banco de dados SGBD SQL

Server

CET Serviço web

PRODAM/Núcleo de

Geoprocessamento

GeoServer (WMS e WFS)

PRODAM/Núcleo de

Geoprocessamaneto

Stored procedure em SGBD Oracle

(Geocodificação)

SAC/156 Stored procedure SGBD SQL Server

Tweeter Post de updates via Tweeter API ou API

proprietária da proponente

Facebook Status update em página do Facebook, via

Facebook SDK ou API proprietária da

proponente

SMTP Server Envio automatizado de e-mail para endereços

cadastrados

Microsoft Office Gerar planilha automaticamente (arquivo

formato Microsoft Excel XLS ou similar)

3.2. Escopo da Homologação

3.2.1. Para a homologação, a PROPONENTE deverá criar de um aplicativo web,

utilizando a solução proposta de Central Integrada de Monitoramento,

implementando um fluxo de tratativa de resposta com características

similares à de uma “queda de árvore sobre fiação, com vítima/danos

estruturais”;

3.2.2. A proponente será a única responsável pela configuração do software

ofertado como solução para a Central de Monitoramento para o

procedimento de homologação aqui descrito.

3.2.3. O aplicativo deverá possuir perfis de acesso (login/logout ou similar), com

pelo menos três perfis distintos:

3.2.3.1.Administrador, com permissões de acesso às seguintes funcionalidades:

3.2.3.1.1. Configuração e cadastro de usuários da central de monitoramento;

3.2.3.1.2. Configuração e cadastro de grupos e permissões de acesso;

3.2.3.1.3. Configuração e cadastro de endereços de e-mail;

3.2.3.1.4. Configuração e cadastro de credenciais de acesso para contas de twitter e

facebook e

3.2.3.1.5. Configuração e cadastro de órgãos da PMSP, tarefas associadas e os

responsáveis por estas tarefas;

3.2.3.1.6. Extração de relatórios de ocorrências registradas pelo sistema da Central

de Monitoramento;

3.2.3.1.7. Criação de fluxo de atendimento (workflow) para tratativas de resposta;

3.2.3.2.Usuários (operadores) da central, com os seguintes privilégios:

3.2.3.2.1. Visualização em mapa georreferenciado das ocorrências de “quedas de

árvore” obtidas por integração a outros sistemas (CET e SAC/156);

3.2.3.2.2. Monitoramento do fluxo associado às ocorrências do tipo “quedas de

árvore”, e o estado das atividades associadas, informando:

3.2.3.2.2.1.Órgão e responsável pela atividade;

3.2.3.2.2.2.Estado ou percentual completado;

3.2.3.2.3. Cadastro manual de ocorrências de “quedas de árvore”, informando, no

mínimo os seguintes dados:

3.2.3.2.4. Raio, em metros, dentro do qual uma ocorrência similar tem alta

probabilidade de ser considerada em duplicidade;

3.2.3.2.4.1.Endereço aproximado da ocorrência (logradouro e número);

3.2.3.2.4.2.Ocorrência ou não de vítimas, seu número e descritivo de gravidade;

3.2.3.2.4.3.Presença ou não de danos estruturais;

3.2.3.2.4.4.Campo informando se o fluxo de acompanhamento das tratativas de

resposta associadas ao evento “queda de árvore” será acionado

imediatamente, não será iniciado ou se será agendado para uma data e

hora especificada pelo operador;

3.2.3.2.5. Geração de relatórios mostrando as ocorrências de “queda de árvores”

contemplando:

3.2.3.2.5.1.Data/hora da ocorrência

3.2.3.2.5.2.Posição geográfica aproximada (obtida via geocodificação integrada aos

sistemas de geoprocessamento)

3.2.3.2.5.3.Status do atendimento, com o órgão e responsável

3.2.4. O aplicativo deverá contemplar as seguintes integrações:

3.2.4.1.Geoprocessamento

3.2.4.1.1. GeoServer

3.2.4.1.2. Geocodificação

3.2.4.2.Facebook

3.2.4.2.1. Post de informações

3.2.4.3.Tweeter

3.2.4.3.1.1.Post de informações

3.2.4.4.Integração ao SGOC

3.2.4.4.1. Cadastramento de novas ocorrências;

3.2.4.4.2. Fechamento de ocorrências abertas;

3.2.4.5.Integração no sistema SAC/156;

3.2.4.5.1. Leitura automática para fins de monitoramento, com parametrização de

periodicidade definida pelo usuário;

3.2.4.6.Integração aos sistemas CET

3.2.4.6.1. Consumo de webservice para envio e recebimento de informações

relevantes

3.2.5. Para fins de homologação da ferramenta, o aplicativo criado e configurado

pela contratada deverá implementar um único fluxo (workflow)

contemplando três possíveis cenários, definidos pelo Processo-alvo: “Queda

de árvore com vítimas”, conforme mostrado no fluxo constante neste Anexo,

com requisitos descrito a seguir.

3.2.6. Cenário 1 (ocorrência detectada no SAC/156)

3.2.6.1.Identificar ocorrência de “queda de árvore” na base de dados SAC/156;

3.2.6.2.Postar automaticamente a ocorrência “queda de árvore”, endereço e hora da

abertura do chamado no Tweeter, via conta com usuário/senha pré-

cadastrado no sistema;

3.2.6.3.Postar automaticamente a ocorrência “queda de árvore”, endereço e hora da

abertura do chamado no Facebook, via conta com usuário/senha pré-

cadastrado no sistema;

3.2.6.4.Inserir automaticamente os dados da ocorrência na base de dados SGOC;

3.2.6.5.Enviar informações sobre a ocorrência ao sistema CET;

3.2.6.6.Se houver dano estrutural, enviar e-mail automaticamente para endereço pré-

configurado, com planilha no formato Excel contendo, em campos

específicos, o tipo de ocorrência, data/hora e logradouro;

3.2.6.7.Se houver vítima, enviar e-mail automaticamente para endereço pré-

configurado, com planilha no formato Excel contendo, em campos

específicos, o tipo de ocorrência, data/hora, logradouro e número de vítimas.

3.2.6.8.Inserir automaticamente a ocorrência na base de dados do sistema proposto

de central de monitoramento, com as informações identificadas:

3.2.6.8.1. Tipo de ocorrência (será sempre do tipo “queda de árvore”);

3.2.6.8.2. Data/hora da ocorrência;

3.2.6.8.3. Logradouro e número da ocorrência

3.2.6.8.4. Latitude e longitude (via geocodificação)

3.2.6.8.5. Data/hora de início do fluxo;

3.2.6.8.6. Status da ocorrência

3.2.6.8.6.1.Aberto

3.2.6.8.6.2.Em atendimento

3.2.6.8.6.3.Fechado

3.2.6.9.Atualizar constantemente o status da ocorrência (com temporização definida

pelo administrador) na base de dados da Central de Monitramento;

3.2.6.10. Gerar alertas visíveis aos usuários (operadores da Central) caso seja

ultrapassado o tempo-limite configurado para cada atividade no fluxo de

resposta;

3.2.6.11. Identificar as alterações de estado das atividades do fluxo de resposta;

3.2.6.12. Identificar o término das atividades do fluxo de resposta e providenciar,

automaticamente:

3.2.6.12.1. O “fechamento” da atividade criada na base do SGOC;

3.2.6.12.2. O “fechamento” da atividade criada na base da central de monitoramento

3.2.6.12.3. Post automático informando a solução do problema no Facebook

3.2.6.12.4. Post automático informando a solução do problema no Tweeter

3.2.7. Cenário 2 (ocorrência detectada via CET);

3.2.7.1.Identificar ocorrência de “queda de árvore” no webservice CET;

3.2.7.2.Postar automaticamente a ocorrência “queda de árvore”, endereço e hora da

abertura do chamado no Tweeter, via conta com usuário/senha pré-

cadastrado no sistema;

3.2.7.3.Postar automaticamente a ocorrência “queda de árvore”, endereço e hora da

abertura do chamado no Facebook, via conta com usuário/senha pré-

cadastrado no sistema;

3.2.7.4.Se houver dano estrutural, enviar e-mail automaticamente para endereço pré-

configurado, com planilha no formato Excel contendo, em campos

específicos, o tipo de ocorrência, data/hora e logradouro;

3.2.7.5.Se houver vítima, enviar e-mail automaticamente para endereço pré-

configurado, com planilha no formato Excel contendo, em campos

específicos, o tipo de ocorrência, data/hora, logradouro e número de vítimas.

3.2.7.6.Inserir automaticamente os dados da ocorrência na base de dados SGOC;

3.2.7.7.Inserir automaticamente a ocorrência na base de dados do sistema proposto

de central de monitoramento, com as informações identificadas:

3.2.7.7.1. Tipo de ocorrência (será sempre do tipo “queda de árvore”);

3.2.7.7.2. Data/hora da ocorrência;

3.2.7.7.3. Logradouro e número da ocorrência

3.2.7.7.4. Latitude e longitude (via geocodificação)

3.2.7.7.5. Data/hora de início do fluxo;

3.2.7.7.6. Status do fluxo

3.2.7.7.6.1.Aberto

3.2.7.7.6.2.Em atendimento

3.2.7.7.6.3.Fechado

3.2.7.8.Atualizar constantemente o status da ocorrência (com temporização definida

pelo administrador);

3.2.7.9.Gerar alertas visíveis aos usuários (operadores da Central) caso seja

ultrapassado o tempo-limite configurado para cada atividade no fluxo de

resposta;

3.2.7.10. Identificar as alterações de estado das atividades do fluxo de resposta;

3.2.7.11. Identificar o término das atividades do fluxo de resposta e providenciar,

automaticamente:

3.2.7.11.1. O “fechamento” da atividade criada na base do SGOC;

3.2.7.11.2. O “fechamento” da atividade criada na base da central de monitoramento

3.2.7.11.3. Post automático informando a solução do problema no Facebook

3.2.7.11.4. Post automático informando a solução do problema no Tweeter

3.2.8. Cenário 3 (identificação de duas ocorrências em possível duplicidade, uma

na CET, outra no SAC/156)

3.2.8.1.Identificar ocorrência de “queda de árvore” no webservice CET;

3.2.8.2.Postar automaticamente a ocorrência “queda de árvore”, endereço e hora da

abertura do chamado no Tweeter, via conta com usuário/senha pré-

cadastrado no sistema;

3.2.8.3.Identificar ocorrência de “queda de árvore” na base de dados SAC/156;

3.2.8.4.Postar automaticamente a ocorrência “queda de árvore”, endereço e hora da

abertura do chamado no Facebook, via conta com usuário/senha pré-

cadastrado no sistema;

3.2.8.5.Se houver dano estrutural, enviar e-mail automaticamente para endereço pré-

configurado, com planilha no formato Excel contendo, em campos

específicos, o tipo de ocorrência, data/hora e logradouro;

3.2.8.6.Se houver vítima, enviar e-mail automaticamente para endereço pré-

configurado, com planilha no formato Excel contendo, em campos

específicos, o tipo de ocorrência, data/hora, logradouro e número de vítimas.

3.2.8.7.Inserir automaticamente os dados da ocorrência na base de dados SGOC

3.2.8.8.Inserir automaticamente a ocorrência na base de dados do sistema proposto

de central de monitoramento, com as informações identificadas:

3.2.8.8.1. Tipo de ocorrência (será sempre do tipo “queda de árvore”);

3.2.8.8.2. Data/hora da ocorrência;

3.2.8.8.3. Logradouro e número da ocorrência

3.2.8.8.4. Latitude e longitude (via geocodificação)

3.2.8.8.5. Data/hora de início do fluxo;

3.2.8.8.6. Status do fluxo

3.2.8.8.6.1.Aberto

3.2.8.8.6.2.Em atendimento

3.2.8.8.6.3.Fechado

3.2.8.9.Informar, via alarme visual, aos operadores da central a entrada de uma

ocorrência similar a menos de 100m de outra similar, cadastrada a menos de

60 minutos.

3.2.8.9.1. O alarme visual deverá conter os seguintes dados:

3.2.8.9.1.1.Órgãos onde as ocorrências foram cadastradas (CET e SAC/156)

3.2.8.9.1.2.Logradouro das ocorrências;

3.2.8.9.1.3.Latitude e longitude aproximada;

3.2.8.9.1.4.Código identificador das ocorrências nas bases CET e SAC/156;

3.2.8.10. Alterar o ícone das ocorrências no mapa georreferenciado visualizado,

identificando a possível duplicidade de ocorrências;

3.2.8.11. Atualizar constantemente o status das duas ocorrências (CET e

SAC/156), com temporização definida pelo administrador;

3.2.8.12. Gerar alertas visíveis aos usuários (operadores da Central) caso seja

ultrapassado o tempo-limite configurado para cada atividade no fluxo de

resposta;

3.2.8.13. Identificar as alterações de estado das atividades do fluxo de resposta;

3.2.8.14. Identificar o término das atividades do fluxo de resposta e providenciar,

automaticamente:

3.2.8.14.1. O “fechamento” da atividade criada na base do SGOC;

3.2.8.14.2. O “fechamento” da atividade criada na base da central de monitoramento

3.2.8.14.3. Post automático informando a solução do problema no Facebook

3.2.8.14.4. Post automático informando a solução do problema no Tweeter

3.2.9. Cenário 4 (ocorrência cadastrada pelo operador da Central de

Monitoramento)

3.2.9.1.Usuário da central de monitoramento abre um chamado do tipo “queda de

árvore”

3.2.9.2.Inserir automaticamente os dados da ocorrência na base de dados SAC/156

3.2.9.3.Informar, via webservice CET, os dados da ocorrência do tipo “queda de

árvore”

3.2.9.4.Postar automaticamente a ocorrência “queda de árvore”, endereço e hora da

abertura do chamado no Tweeter, via conta com usuário/senha pré-

cadastrado no sistema;

3.2.9.5.Postar automaticamente a ocorrência “queda de árvore”, endereço e hora da

abertura do chamado no Facebook, via conta com usuário/senha pré-

cadastrado no sistema;

3.2.9.6.Inserir automaticamente os dados da ocorrência na base de dados SAC/156;

3.2.9.7.Inserir automaticamente os dados da ocorrência na base de dados SGOC

3.2.9.8.Se houver dano estrutural, enviar e-mail automaticamente para endereço pré-

configurado, com planilha no formato Excel contendo, em campos

específicos, o tipo de ocorrência, data/hora e logradouro;

3.2.9.9.Se houver vítima, enviar e-mail automaticamente para endereço pré-

configurado, com planilha no formato Excel contendo, em campos

específicos, o tipo de ocorrência, data/hora, logradouro e número de vítimas.

3.2.9.10. Inserir automaticamente a ocorrência na base de dados do sistema

proposto de central de monitoramento, com as informações identificadas:

3.2.9.10.1. Tipo de ocorrência (será sempre do tipo “queda de árvore”);

3.2.9.10.2. Data/hora da ocorrência;

3.2.9.10.3. Logradouro e número da ocorrência

3.2.9.10.4. Latitude e longitude (via geocodificação)

3.2.9.10.5. Data/hora de início do fluxo;

3.2.9.10.6. Status do fluxo

3.2.9.10.6.1. Aberto

3.2.9.10.6.2. Em atendimento

3.2.9.10.6.3. Fechado

3.2.9.11. Informar, via alarme visual, aos operadores da central a entrada de uma

ocorrência similar a menos de 100m (ou outro valor, configurável pelo

usuário na criação do fluxo de resposta da ocorrência do tipo “queda de

árvore”)de outra similar, cadastrada a menos de 60 minutos.

3.2.9.11.1. O alarme visual deverá conter os seguintes dados:

3.2.9.11.1.1. Órgãos onde as ocorrências foram cadastradas (CET e SAC/156)

3.2.9.11.1.2. Logradouro das ocorrências;

3.2.9.11.1.3. Latitude e longitude aproximada;

3.2.9.11.1.4. Código identificador das ocorrências nas bases CET e SAC/156;

3.2.9.12. Alterar o ícone das ocorrências no mapa georreferenciado visualizado,

identificando a possível duplicidade de ocorrências;

3.2.9.13. Atualizar constantemente o status das duas ocorrências (CET e

SAC/156), com temporização definida pelo administrador;

3.2.9.14. Gerar alertas visíveis aos usuários (operadores da Central) caso seja

ultrapassado o tempo-limite configurado para cada atividade no fluxo de

resposta;

3.2.9.15. Identificar as alterações de estado das atividades do fluxo de resposta;

3.2.9.16. Identificar o término das atividades do fluxo de resposta e providenciar,

automaticamente:

3.2.9.16.1. O “fechamento” da atividade criada na base do SGOC;

3.2.9.16.2. O “fechamento” da atividade criada na base da central de monitoramento

3.2.9.16.3. Post automático informando a solução do problema no Facebook

3.2.9.16.4. Post automático informando a solução do problema no Tweeter

3.3. Local da Homologação

3.3.1. A Homologação acontecerá nas dependências da CONTRATANTE, sita à

Av. Francisco Matarazzo, 1500 – Torre Los Angeles;

3.3.2. Será providenciado ambiente físico com características compatíveis às

solicitadas pela PROPONENTE;

3.3.3. A Homologação acontecerá no prazo de 5 (cinco) dias úteis, das 9:00 às

17:00, impreterivelmente.

3.3.4. À exceção de motivos de força maior e de falhas por parte da

CONTRATANTE, não haverá adiamento ou prorrogação de prazos.

3.3.4.1.A ocorrência de eventos que levem à prorrogação de prazos será analisada

pela CONTRATANTE, mediante solicitação formal da PROPONENTE.

3.4. ESPECIFICAÇÕES TÉCNICAS

3.4.1. Fluxo correspondente à tratativa “queda de árvore”

3.4.2. Modelo de Dados – SGOC

3.4.3. Especificações - CET

Especificações de acesso – Stored Procedure SAC/156

Nome da Procedure: p_sel_solicitacao_lista_detalhada_arvore_caida

Exemplo de execução:

p_sel_solicitacao_lista_detalhada_arvore_caida '2014-01-01', '2014-12-31'

Campo Tipo

Número_SAC int

Data_Cadastro datetime

Assunto varchar[70]

Especificação varchar[100]

Situação varchar[21]

Data_conclusão datetime

Pedido varchar[8000]

Resposta_Pedido varchar[8000]

Logradouro varchar[90]

Nro_Logradouro varchar[20]

Referencia_Logradouro varchar[127]

CEP varchar[8]

Setor_Quadra varchar[6]

Nome_Municipe varchar[40]

Fone_Municipe varchar[15]

Email_Municipe varchar[40]

Logradouro_Municipe varchar[40]

NroLogradouro_Municipe int

CEP_Municipe varchar[8]