Upload
lenguyet
View
213
Download
0
Embed Size (px)
Citation preview
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
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
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.
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]