TERMO DE REFERÊNCIA - Prefeitura · configurações, serviços, processos e negócios; 1.1.1.2. Este componente é responsável, ainda, pela normalização dos ... métricas de performance

DIT/GIE TR CAPACIDADE E APM Página 1 de 33

TERMO DE REFERÊNCIA Objeto Aquisição de soluções de software de Gestão e Planejamento de Capacidade e Gerenciamento de Desempenho de Aplicações (Application Performance Management - APM) para todo o ambiente físico, virtual e de armazenamento (SAN, NAS e Mainframe), contemplando Licenças de Uso, Instalação, Configuração e Migração de dados, Operação Assistida (hands-on), Treinamento e Manutenção e Suporte Técnico 24x7.

Tabela de Itens Item Características Quantidade

1 Solução de Software de Gestão e Planejamento de Capacidade

1.1 Requisitos do(s) componente(s) da solução -

1.2 Licenças de uso contemplando o cenário descrito no item “Ambiente Atual PRODAM”

De acordo com “Ambiente Atual

Prodam”

1.3 Serviços de Instalação, Configuração e Migração de dados

1

1.4 Operação Assistida (Hands-on) – 90 dias

1.5 Treinamento 7

1.6 Manutenção e Suporte Técnico 24x7 – 36 meses 1

2 Solução de Software de Gerenciamento de Desempenho de Aplicações (Application Performance Management - APM)

2.1 Requisitos do(s) componente(s) da solução -

2.2 Licenças de uso contemplando o cenário descrito no item “Ambiente Atual PRODAM”

De acordo com “Ambiente Atual

Prodam”

2.3 Serviços de Instalação, Configuração e Migração de dados

1

2.4 Operação Assistida (Hands-on) – 90 dias 1

2.5 Treinamento 12

2.6 Manutenção e Suporte Técnico 24x7 – 36 meses 1

Ambiente Atual Prodam Este item tem por objetivo apresentar o atual ambiente de recursos da PRODAM, a saber:

� Ambiente de Baixa Plataforma: − Servidores Físicos: 505;


− Processadores Físicos: 1330; − Máquinas Virtuais: 1.040; − Servidores de aplicação: 230 − Storage SAN: Fujitsu Modelo DX8400; − Storage NAS: Net App Modelo FAS2020 e EMC Modelo EMC-

VNX5400.

� Ambiente de Alta Plataforma (Mainframe): − IBM z/OS Z10 modelo 2098-O02 (2 CP’s / 120 GB Memória Total /

Storage de 36,70 TB)

1 Solução de Software de Gestão e Planejamento de Capacidade

1.1. Requisitos do(s) componente(s) da solução

1.1.1. Repositório Central Automatizado para Capacidade (Banco de Dados de Capacidade)

1.1.1.1. A solução deve fornecer componente responsável por prover um repositório central automatizado para capacidade (Banco de Dados de Capacidade), garantindo a administração do processo de coleta e armazenando das métricas de desempenho, dados de configurações, serviços, processos e negócios;

1.1.1.2. Este componente é responsável, ainda, pela normalização dos dados de capacidade, garantindo assim que independentemente da fonte de dados utilizada exista a equivalência das métricas coletadas, não importando o seu formato de registro original;

1.1.1.3. A solução deverá suportar como base de dados ao menos um dos gerenciadores abaixo:

1.1.1.3.1. Oracle 11.2 (64-bit) nas versões Enterprise Edition ou Standard Edition ou superior;

1.1.1.3.2. MS Sql Server 2014 ou superior; 1.1.1.3.3. My Sql 5.6 ou superior; 1.1.1.3.4. Postgresql 9.2 ou superior;

1.1.1.4. A solução deverá contemplar licenças de gerenciador de banco de dados, conforme item acima, para 5 usuários simultâneos;

1.1.1.5. A solução que for utilizada e possuir a feature “Partioning Support”, deverá habilitá-la;

1.1.1.6. A solução deverá suportar execução do servidor de aplicação responsável pela operação/manutenção do BDC (Banco de Dados de Capacidade) em plataformas Windows Server 2008 (64bit), Windows Server 2008 R2, Windows Server 2012 (com GUI), Windows Server 2012 R2 (com GUI) ou versão superior, Red Hat Enterprise Linux ES 5.4 a 5.7, Red Hat Enterprise Linux ES 6.2 e Red Hat Emterprise Linux 7;

1.1.1.7. A solução deverá suportar a instalação do servidor de aplicação em plataforma de virtualização VMware ESX 5.x e ESXi 6.x;


1.1.1.8. A solução deverá ser capaz de coletar dados de performance obtidos através de tecnologias específicas para tal fim, já existentes no ambiente, não demandando a instalação de agente específico nos servidores para a obtenção de tais métricas (deverá ser “agentless”);

1.1.1.9. A solução deverá ser capaz de coletar, nativamente, métricas de performance de servidores físicos e virtuais através da importação de dados;

1.1.1.10. A solução deverá ser capaz de coletar métricas de performance do ambiente de virtualização VMware (clusters, hosts e máquinas virtuais) através da conexão com VMware vCenter nas versões 5.x e 6.x;

1.1.1.11. Referente à configuração administrativa do vCenter, deverá:

1.1.1.11.1. Permitir a coleta dos dados obtidos pelo vCenter diariamente (dados coletados pelo vCenter em intervalos de 5 minutos) e semanalmente (dados coletados pelo vCenter em intervalos de 30 minutos);

1.1.1.11.2. Quanto às métricas, deverá suportar aquelas coletadas em Level 1, Level 2 e Level 3;

1.1.1.11.3. Deverá possuir mecanismo que permita, alternativamente, a coleta destes dados através da vSphere API.

1.1.1.12. A solução deverá ser capaz de coletar métricas de performance de servidores através da importação de dados obtidos pelo BMC Performance Analyser for Servers (também conhecido como Patrol Perform/Predict), dados estes gerados via utilitário print udr;

1.1.1.13. A solução deverá ser capaz de obter as informações das métricas de performance coletadas através do Microsoft Performance Monitor;

1.1.1.14. A solução deverá ser capaz de coletar as informações das métricas de performance obtidas através do UNIX SAR em plataformas HP-UX, IBM z/OS, Linux e Sun Solaris;

1.1.1.15. A solução deverá ser capaz de coletar, automática e nativamente, as métricas sobre CPU, discos, rede, processos, transações e workloads, além de dados de configuração coletados de aplicações baseadas em JVM e .NET pela solução de Gerenciamento de Desempenho de Aplicações (APM) descrita neste Termo de Referência, item 2;

1.1.1.16. A solução deverá possuir mecanismo que permita coletar as métricas de performance via ST03 do SAP R/3 versões 4.6 e 4.7 e do SAP NetWeaver 7.x. As seguintes métricas ST03 deverão ser coletadas:

1.1.1.16.1. APPLICATION_STATISTIC (diária, por tipo de task, tcode e usuário);

1.1.1.16.2. TIME_STATISTIC (horária, por tipo de task e tcode); 1.1.1.16.3. TASKTYPE_STATISTIC (horária, por tipo de task); 1.1.1.16.4. TASKTYPE_SUMMARY (diária, por tipo de task); 1.1.1.16.5. RFC_CLIENT_DEST_STATISTIC; 1.1.1.16.6. RFC_SERVER_DEST_STATISTIC;


1.1.1.16.7. MEMORY_STATISTIC. 1.1.1.17. A solução deverá ser capaz de coletar métricas de

performance e dados de configuração de servidores através da importação de dados obtidos pelo Microsoft System Center Operations Manager (SCOM) 2012 R2 ou superior, tanto para a plataforma física quanto para a virtual (HyperV);

1.1.1.18. A solução deverá possuir mecanismo que permita a coleta de métricas de equipamentos de armazenamento (NetApp, EMC, Fujitsu, IBM Mainframe) sobre throughput, IOPS, latência, queue lenght, system-level CPU e armazenamento para os seus diversos componentes, tais como aggregates, volumes, LUN, discos e portas fiber channel;

1.1.1.19. A solução deverá possuir mecanismo que permita a coleta e armazenamento de dados diversos (a saber, métricas “não TI”, tais como consumo de energia, uso de espaço físico, métricas associadas a planos de negócios, métricas financeiras, etc) em seu banco de dados;

1.1.1.20. A solução deverá permitir o uso de métricas de performance de servidores obtidos a partir de arquivos simples, tais como planilhas excel e arquivos texto (CSV);

1.1.1.21. A solução deverá ser capaz de coletar informações em repositórios externos baseados em Microsoft SQL-Server;

1.1.1.22. A solução deverá ser capaz de coletar informações em repositórios externos baseados em Oracle;

1.1.1.23. A solução deverá ser capaz de coletar informações em repositórios externos baseados em Sybase;

1.1.1.24. A solução deverá prover um SDK, de forma a permitir a inclusão dos dados de métricas de performance obtidos por mecanismos/ferramentas outros/as, independente de fornecedor ou plataforma, no repositório central da solução;

1.1.1.25. A solução deverá centralizar a informação em um BDC (Banco de Dados de Capacidade);

1.1.1.26. A solução deverá normalizar os dados obtidos a partir das diversas fontes aqui solicitadas, permitindo desta forma utilizar o conjunto das métricas armazenadas no BDC (Banco de Dados de Capacidade) independente de sua origem;

1.1.1.27. A solução deverá prover mecanismo que permita ao administrador da solução definir o período de retenção dos dados “crus” (raw data) no banco de dados de capacidade;

1.1.1.28. A solução deverá efetuar a carga de todas as métricas coletadas (independente do tipo de métrica e/ou fonte de dados) em duas fases: uma primeira fase de “staging”, onde o analista de capacidade poderá validar o processo de carga criado - e uma segunda fase de “migração” definitiva dos dados para o banco de dados de capacidade. Somente após esta segunda fase os dados deverão estar efetivamente disponíveis para uso pela solução;

1.1.1.29. A solução deverá possuir mecanismo que permita ao administrador definir agendamentos automáticos (schedules) para as duas fases descritas acima, o “staging” e a “migração”


dos dados coletados. Ainda, este mecanismo deverá permitir a execução de tais tarefas de forma periódica, sendo que a solução deverá permitir ao administrador definir tal periodicidade;

1.1.1.30. A solução deverá possuir log para registro dos processos de “staging” e “migração”;

1.1.1.31. A solução deverá possuir mecanismo que permita ao administrador definir o período de retenção das logs de “staging” e “migração”;

1.1.1.32. A solução deverá permitir o agrupamento de várias entidades (tais como servidores, VMs, clusters, workloads, transações, hosts, etc);

1.1.1.33. A solução deverá permitir que tais agrupamentos sejam organizados em camada única (flat) ou em estrutura hierárquica, sendo que uma determinada entidade poderá pertencer a múltiplos grupos lógicos. (exemplo: o “Servidor A” pode pertencer aos grupos Servidores_Windows_2008, Aplicação_Web e Brasil > São Paulo > Campinas);

1.1.1.34. A solução deverá possuir mecanismo que possibilite exportar os dados existentes no banco de dados de capacidade em formato CSV e XLS;

1.1.1.35. A solução deverá possuir mecanismo de agregação ou sumarização (doravante denominado “rollup”) dos dados “crus” (raw data) de forma a possibilitar uma maior velocidade na obtenção de resultados nos relatórios de análise;

1.1.1.36. A solução deverá permitir a definição do período de retenção dos dados gerados por este processo de “rollup”;

1.1.1.37. De forma a evitar perda de dados relevantes para os estudos de Capacidade, a solução deverá trabalhar com o conceito de percentil para execução deste processo de agregação, suportando ao menos os seguintes tipos de “rollup”: 90 percentil, 95 percentil, Valor Máximo, Valor Mínimo e Média Ponderada;

1.1.1.38. Deverá ainda permitir a habilitação de outros tipos de “rollup” neste processo de agregação, tais como outros valores de percentil e/ou Desvio Padrão;

1.1.1.39. Independente do tipo de “rollup”, a solução deverá possibilitar que estes ocorram obedecendo a um padrão de tempo diário (por dia) e/ou horário (por hora).

1.1.2. Interface Web para visualização de dados e emissão de relatórios

1.1.2.1. A solução deverá fornecer interface web responsável por permitir a visualização dos dados de desempenho históricos e atuais armazenados no Banco de Dados de Capacidade, para todo o ambiente gerenciado ou por agrupamentos de componentes;

1.1.2.2. A solução deverá permitir a visualização de dados de desempenho e configuração armazenados no Banco de Dados


de Capacidade em diversos formatos e relatórios, de forma a permitir o efetivo gerenciamento de capacidade da infraestrutura, das aplicações e dos equipamentos, a partir da combinação de diferentes tipos de dados para análise em um só lugar;

1.1.2.3. A solução deverá possibilitar o agrupamento dos elementos gerenciados de acordo com necessidades de apresentação diversas, tais como secretaria, localização, serviço atendido, tipo da plataforma, e outros;

1.1.2.4. A solução deverá prover análise que contemple o uso de “planning percentile”, de forma a facilitar referida análise bem como a interpretação dos dados históricos em avaliação;

1.1.2.5. A solução deverá gerar gráficos com relatórios de utilização dos componentes como um todo, bem como por agrupamento previamente definido pelo administrador da solução;

1.1.2.6. A solução deverá permitir incluir/excluir a visão de curva de tendência para os dados apresentados nos relatórios de utilização;

1.1.2.7. A solução deverá gerar gráficos com relatórios de otimização dos componentes como um todo, bem como por agrupamento previamente definido pelo administrador da solução;

1.1.2.8. A solução deverá possibilitar a execução de “drill-down” a partir do gráfico de utilização dos componentes, de forma a possibilitar a identificação do consumo histórico de recursos por componente;

1.1.2.9. A solução deverá possibilitar a execução de “drill-down” a partir do gráfico de otimização dos componentes, de forma a possibilitar a identificação do consumo histórico de recursos por componente;

1.1.2.10. O relatório de otimização deverá apresentar os consumos por faixa de uso, permitindo assim que o administrador da solução tenha um mapa gráfico completo do ambiente em relação aos recursos sub-utilizados, com utilização dentro do esperado, com utilização acima do esperado e também super-utilização);

1.1.2.11. A solução deverá apresentar, quando da execução do drill-down neste relatório de otimização, os recursos que estão dentro de cada faixa de utilização, inclusive com filtro que permita ver todos os componentes ou somente aqueles que estejam dentro de determinada condição (por exemplo, ver somente os sub-utilizados);

1.1.2.12. A solução deverá possuir estas faixas de uso já configuradas de acordo com boas práticas observadas no mercado, todavia deverá também permitir que sejam feitos ajustes nestas faixas de utilização – possibilitando assim que a tecnologia seja adequada à realidade do ambiente CONTRATANTE;

1.1.2.13. A solução deverá possuir mecanismo nativo que possibilite a visualização dos componentes gerenciados de acordo com focos específicos de análise, incluindo ao menos: servidores, capacidade, "planning percentile”, médias e picos;


1.1.2.14. A solução deverá possuir mecanismo para geração de relatórios com acesso via web browser;

1.1.2.15. A solução deverá permitir a criação de dashboards, agrupando em uma única interface diferentes relatórios;

1.1.2.16. A geração dos dashboards deve valer-se de mecanismo do tipo “arrastar e soltar” para sua criação;

1.1.2.17. A solução deverá permitir ao administrador da solução definir diversos perfis de usuários, bem como quais os dashboards que cada perfil terá acesso;

1.1.2.18. Este componente deverá suportar execução em plataformas Windows Server 2008 (64bit) ou Windows Server 2008 R2;

1.1.2.19. A solução deverá prover, ao menos, os seguintes tipos de relatórios:

1.1.2.19.1. Relatórios de Inventário: 1.1.2.19.1.1. Alocação de vRAM em Cluster VM vs. RAM

Instalada; 1.1.2.19.1.2. Lista de Frames AIX; 1.1.2.19.1.3. Alocação de Cores em Frames AIX; 1.1.2.19.1.4. Lista de LPARs AIX; 1.1.2.19.1.5. Lista de Pools AIX; 1.1.2.19.1.6. Lista de Servidores Físicos; 1.1.2.19.1.7. Lista de Clusters VMware ESX; 1.1.2.19.1.8. Lista de Hosts VMware ESX; 1.1.2.19.1.9. Lista de Máquinas Virtuais VMware; 1.1.2.19.1.10. Lista dos Grupos de Aplicações; 1.1.2.19.1.11. Host VM RAM: Alocação; 1.1.2.19.1.12. Lista de Processos por Host; 1.1.2.19.1.13. Performance de Transações; 1.1.2.19.1.14. Data Center vCenter; 1.1.2.19.1.15. Administração da Ferramenta: Sumário de

Utilização das Tablespaces; 1.1.2.19.1.16. Administração da Ferramenta: Detalhes das

Tablespaces; 1.1.2.19.1.17. Administração da Ferramenta: Relatório de

Migração de Dados; 1.1.2.19.1.18. Administração da Ferramenta: Relatório de

GAPs na Carga de Dados; 1.1.2.19.1.19. Administração da Ferramenta: Relatório de

Performance da Migração de Dados; 1.1.2.19.1.20. Administração da Ferramenta: Relatório de

Status do Processo de Rollup.

1.1.2.19.2. Relatórios de Exceção: 1.1.2.19.2.1. Maiores Consumidores de CPU (para LPARs

AIX); 1.1.2.19.2.2. Menores Consumidores de CPU (para LPARs

AIX); 1.1.2.19.2.3. Maiores Consumidores de CPU (para Hosts ESX); 1.1.2.19.2.4. Menores Consumidores de CPU (para Hosts

ESX);


1.1.2.19.2.5. Maiores Consumidores de CPU (para Servidores Físicos);

1.1.2.19.2.6. Menores Consumidores de CPU (para Servidores Físicos);

1.1.2.19.2.7. Maiores Consumidores de CPU (para Máquinas Virtuais);

1.1.2.19.2.8. Menores Consumidores de CPU (para Máquinas Virtuais);

1.1.2.19.2.9. Maiores Consumidores de CPU (para Cluster); 1.1.2.19.2.10. Menores Consumidores de CPU (para

Cluster); 1.1.2.19.2.11. Maiores Consumidores de Memória (para

LPARs AIX); 1.1.2.19.2.12. Menores Consumidores de Memória (para

LPARs AIX); 1.1.2.19.2.13. Maiores Consumidores de Memória (para

Máquinas Virtuais); 1.1.2.19.2.14. Menores Consumidores de Memória (para

Máquinas Virtuais); 1.1.2.19.2.15. Maiores Consumidores de Memória (para

Hosts ESX); 1.1.2.19.2.16. Menores Consumidores de Memória (para

Hosts ESX); 1.1.2.19.2.17. Maiores Consumidores de Memória (para

Servidores Físicos); 1.1.2.19.2.18. Menores Consumidores de Memória (para

Servidores Físicos); 1.1.2.19.2.19. Mapa de Calor (Heatmap) mensal para

consumo de CPU para grupos de servidores; 1.1.2.19.2.20. Mapa de Calor (Heatmap) mensal para

consumo de Memória para grupos de servidores.

1.1.2.19.3. Relatório de Tendências: 1.1.2.19.3.1. Tendência de Utilização – AIX; 1.1.2.19.3.2. Tendência de Utilização – Servidores Físicos; 1.1.2.19.3.3. Tendência de Utilização – Hosts VMware ESX; 1.1.2.19.3.4. Tendência de Utilização – Máquinas Virtuais

VMware.

1.1.2.19.4. Relatórios para Detecção de Baseline: 1.1.2.19.4.1. Dia de Pico – Servidores AIX; 1.1.2.19.4.2. Dia de Pico – Servidores ESX; 1.1.2.19.4.3. Dia de Pico – Servidores Físicos; 1.1.2.19.4.4. Dia de Pico – Máquinas Virtuais; 1.1.2.19.4.5. Hora de Pico – Servidores AIX: 1.1.2.19.4.6. Hora de Pico – Servidores ESX; 1.1.2.19.4.7. Hora de Pico – Servidores Físicos; 1.1.2.19.4.8. Hora de Pico – Máquinas Virtuais; 1.1.2.19.4.9. Pico em Três Horas – Servidores AIX; 1.1.2.19.4.10. Pico em Três Horas – Servidores ESX;


1.1.2.19.4.11. Pico em Três Horas – Servidores Físicos; 1.1.2.19.4.12. Pico em Três Horas – Máquinas Virtuais

1.1.2.19.5. Relatórios - Nível de Sistemas: 1.1.2.19.5.1. Lista de Serviços por Servidor; 1.1.2.19.5.2. Sumário de Utilização de Hosts; 1.1.2.19.5.3. Tendência de Utilização de CPU; 1.1.2.19.5.4. Tendência de Utilização de Memória; 1.1.2.19.5.5. Utilização de CPU por Host e VM; 1.1.2.19.5.6. Utilização de CPU (% Utilizado); 1.1.2.19.5.7. CPU - Tamanho de Fila (Queue Length); 1.1.2.19.5.8. CPU - Tamanho de Fila (Queue Length) –

Utilização; 1.1.2.19.5.9. Utilização de Memória por Host e VM; 1.1.2.19.5.10. Utilização de Disco por Host e VM; 1.1.2.19.5.11. Utilização de Rede por Host e VM; 1.1.2.19.5.12. “Read Byte Rate” de Disco por Host; 1.1.2.19.5.13. “Write Byte Rate” de Disco por Host; 1.1.2.19.5.14. Storage (GB) Utilizado por Host e VM; 1.1.2.19.5.15. Utilização Percentual de Storage por Host; 1.1.2.19.5.16. CPU Ready; 1.1.2.19.5.17. “Ballooning” de Memória; 1.1.2.19.5.18. Swap de Memória; 1.1.2.19.5.19. Overhead de Memória.

1.1.2.19.6. Relatórios de Correlação e Workload:

1.1.2.19.6.1. Lista de Serviços para Servidores; 1.1.2.19.6.2. Lista de Serviços – Sinalizadores; 1.1.2.19.6.3. Lista de Serviços – Correlação Agregada; 1.1.2.19.6.4. Lista de Serviços – Correlação Individual; 1.1.2.19.6.5. Performance de Transações.

1.1.2.19.7. Relatórios de Storage – Nível de Datastore VMware:

1.1.2.19.7.1. Menor Latência do Datastore por VM; 1.1.2.19.7.2. Maior Latência do Datastore por VM; 1.1.2.19.7.3. Menor Utilização do Datastore (% de Utilização); 1.1.2.19.7.4. Maior Utilização do Datastore (% de Utilização); 1.1.2.19.7.5. Menor Utilização do Datastore (por Cluster); 1.1.2.19.7.6. Maior Utilização do Datastore (por Cluster); 1.1.2.19.7.7. Menor Utilização das VMs por Datastore (% de

Utilização); 1.1.2.19.7.8. Alocação do Datastore; 1.1.2.19.7.9. Capacidade do Datastore e VMs; 1.1.2.19.7.10. Latência do Datastore por VM; 1.1.2.19.7.11. Performance do Datastore – Todas as VMs; 1.1.2.19.7.12. Tendências do Datastore; 1.1.2.19.7.13. Tendências do Datastore por VM; 1.1.2.19.7.14. Utilização do Datastore; 1.1.2.19.7.15. Utilização do Datastore por VM; 1.1.2.19.7.16. Utilização do Datastore por Cluster;


1.1.2.19.7.17. Utilização do Datastore por Cluster (Total).

1.1.2.19.8. Relatórios de Uso e Risco para Plataforma VMware: 1.1.2.19.8.1. Capacidade de CPU do Cluster por VM; 1.1.2.19.8.2. Capacidade de Memória do Cluster por VM; 1.1.2.19.8.3. Estado Atual de Uso do Cluster; 1.1.2.19.8.4. Estado de Uso do Cluster Pós

Redimensionamento Proposto; 1.1.2.19.8.5. Relatório de “Sizing” de VM – Para Todos os

Clusters; 1.1.2.19.8.6. Relatório de “Sizing” de VM – Por Cluster; 1.1.2.19.8.7. Tendência de Uso do Cluster (CPU e Memória); 1.1.2.19.8.8. Sumário de Utilização do Cluster; 1.1.2.19.8.9. Sumário de Utilização do Host ESX; 1.1.2.19.8.10. Relatório de “Top CPU Ready” – Para todas

as VMs; 1.1.2.19.8.11. Relatório de “Top CPU Ready” – Por Host; 1.1.2.19.8.12. Relatório de “Top CPU Ready” – Por Cluster; 1.1.2.19.8.13. Relatório de Risco – Maiores Consumidores

de CPU e Memória; 1.1.2.19.8.14. Relatório de Desperdício – Menores

Consumidores de CPU e Memória.

1.1.2.20. A solução deverá também possuir conjunto de relatórios específicos associados a ferramenta de APM (Application Performance Manager) com, no mínimo, os seguintes tipos de relatórios:

1.1.2.20.1. Relatório de “Headroom” por Aplicação; 1.1.2.20.2. Relatórios de Aplicação:

1.1.2.20.2.1. Relatório de “Breakdown” por Aplicação; 1.1.2.20.2.2. Relatório de Lista de Aplicações.

1.1.2.20.3. Relatórios de Correlação de Capacidade; 1.1.2.20.4. Relatórios de Carga de Trabalho para o Capacity

Manager (por VM, por Aplicação); 1.1.2.20.5. Relatório de Configuração de “Heap”; 1.1.2.20.6. Relatórios de Horários de Pico:

1.1.2.20.6.1. Hora de Pico; 1.1.2.20.6.2. Pico em três horas.

1.1.2.20.7. Relatório de Tempos de Resposta e Throughtput; 1.1.2.20.8. Relatório dos Maiores Processos; 1.1.2.20.9. Gráfico de Replay de Transações; 1.1.2.20.10. Relatório de Apresentação do Sumário de

Transações; 1.1.2.20.11. Relatórios de Utilização:

1.1.2.20.11.1. Correlação de Carga de Trabalho; 1.1.2.20.11.2. Mensagem do Coeficiente de Correlação da

Carga de Trabalho. 1.1.2.20.12. Lista de Cargas de Trabalho por Host; 1.1.2.20.13. Histogramas de Throughput das Cargas de Trabalho.


1.1.2.21. A solução deverá possibilitar também a criação de novos relatórios, de forma a permitir o uso dos dados existentes no banco de dados de capacidade da maneira mais apropriada ao atendimento das necessidades de análise;

1.1.2.22. A solução deverá permitir a criação de relatórios que possibilitem a análise de correlação entre métricas de infraestrutura e métricas de negócios;

1.1.2.23. A solução deverá permitir que sejam efetuadas alterações na aparência da interface web;

1.1.2.24. A solução deverá permitir que os parâmetros de limites (thresholds) utilizados nos relatórios sejam alterados/redefinidos de acordo com a necessidade do ambiente;

1.1.2.25. A solução deverá trabalhar com faixas de limites (thresholds) que permitam uma adequada interpretação dos dados.

1.1.3. Análise de Desempenho Futuro

1.1.3.1. A solução deverá fornecer componente para análise de desempenho futuro (forecast) que permite a construção de modelos de ambiente com a infraestrutura computacional utilizada para atender as demandas de negócio, considerando os dados armazenados no Banco de Dados de Capacidade;

1.1.3.2. Estes modelos deverão ser utilizados para estimar crescimentos futuros, bem como para executar as seguintes tarefas:

1.1.3.2.1. Proporcionar o planejamento de capacidade contínua para sistemas de produção;

1.1.3.2.2. Visualizar utilização dos recursos e desempenho passado, corrente e futuro;

1.1.3.2.3. Identificar os tempos de respostas para aplicações; 1.1.3.2.4. Identificar problemas na utilização dos recursos.

1.1.3.3. A solução deverá fornecer um sistema de modelagem, com capacidade de modelagem analítica;

1.1.3.4. O sistema de modelagem deverá possuir integração com o BDC (Banco de Dados de Capacidade), de forma a utilizar as informações ali armazenadas para as modelagens analíticas;

1.1.3.5. A aplicação cliente responsável pela modelagem deverá suportar instalação em plataforma Windows 7 (32bit ou 64bit);

1.1.3.6. A solução deverá permitir o uso de tempos de resposta calibrados/aferidos, possibilitando assim a definição do tempo de resposta para um determinado baseline a partir de dados coletados através de ferramentas específicas de medição e/ou monitoração, ou mesmo logs de aplicativos. Este valor deverá ser utilizado como ponto de ajuste de calibração nas modelagens, referente aos tempos de resposta em intervalos futuros;

1.1.3.7. A solução deverá permitir, como critério para tempos de resposta, o uso da taxa de chegada (arrival rate) como “baselines” em um determinado intervalo de tempo em situações onde não for


possível definir-se o tempo de resposta calibrado. Poderão ser usadas informações de taxas de chegada coletadas em logs ou através de ferramentas de monitoração relacionadas a contagem de usuários, transações ou mesmo funções específicas (como por exemplo: “lê” e “escreve”). Ainda, os intervalos de tempo deverão permitir que se configure a taxa de chegada por segundo, minuto ou hora;

1.1.3.8. A solução deverá permitir, caso não seja possível definir os tempos de resposta de forma calibrada ou através de taxas de chegada, que se defina um tempo de resposta em relação à carga de trabalho como sendo um múltiplo do tempo de resposta do “baseline”. Neste caso, o resultado esperado será a quantidade de vezes que um determinado tempo de resposta será superior (em situações de crescimento) ao tempo de resposta determinado no “baseline”;

1.1.3.9. A solução deverá permitir que se estabeleçam requerimentos de tempos de resposta, de forma a determinar um objetivo limite em relação aos tempos de resposta aceitáveis para determinado modelo;

1.1.3.10. A solução deverá fornecer software de modelagem que suporte (mas não limitado a) servidores que executem sistema operacional HP-UX, IBM z/OS, Linux (RedHat, SuSE, Alpha), Windows Server (2000, 2003, 2008, 2012), SUN Solaris;

1.1.3.11. A solução deverá fornecer software de modelagem que possibilite a execução de análises de capacidade em ambiente Mainframe IBM;

1.1.3.12. Deverá possuir biblioteca de modelos de hardware (HML – Hardware Model Library) compatível com as definições mantidas pela Standard Performance Evaluation Corporation (http://www.spec.org);

1.1.3.13. Deverá implementar também, nas definições dos modelos de hardware, fatores de escalabilidade e linearidade – permitindo assim uma maior acuracidade nas simulações executadas utilizando tais modelos de hardware;

1.1.3.14. Deverá permitir considerar, na configuração do hardware, a habilitação ou não do parâmetro de multithreading;

1.1.3.15. Deverá implementar, a partir da biblioteca de modelos de hardware, uma unidade de medida que indique a capacidade de processamento dos servidores da plataforma distribuída – contemplando a capacidade máxima do equipamento e a capacidade atual, de acordo com as configurações existentes;

1.1.3.16. Esta biblioteca de modelos de hardware deverá, para a plataforma Mainframe, ser compatível com o indicador MIPS;

1.1.3.17. Deverá possuir uma biblioteca de modelos de componentes que permita o uso de diversos VMMs (Virtual Machine Monitor) nas simulações relacionadas a ambientes virtuais, contemplando: VMware ESX 3.0, 3.5, 4.0, 4.1, 5.0, 5.1 e 5.5; Microsoft Hyper-V, Hyper-V R2 e Hyper-V 2012; Integrity VM; Logical Domains; RHEL KVM 5 e 6; RHEL Xen 5; Xen Server;


vPars Monitor; Oracle VM Server 3; Power5, Power6 e Power7 VMMs; z/OS V1R9, V1R11 e V1R13 VMMs;

1.1.3.18. Deverá possuir biblioteca de modelos de hardware que suporte plataformas com foco em implementação de infraestrutura para Cloud, contemplando Cisco UCS, FlexPod UCS e VCE Vblock;

1.1.3.19. Deverá possuir biblioteca de modelos de hardware que suporte ambientes de Cloud pública, contemplando Amazon EC2, Microsoft Azure, Rackspace, Savvis e Terremark vCloud;

1.1.3.20. A solução deverá prover mecanismo para atualização periódica do hardware de servidores constantes da biblioteca de modelos de hardware;

1.1.3.21. A solução deverá permitir a simulação de cenários considerando alterações de carga de trabalho no ambiente previamente definido;

1.1.3.22. A solução deverá ser capaz de simular o crescimento vertical (adição de componentes ao servidor ou reposição por um hardware mais potente) e horizontal (adicionando novos servidores à plataforma existente);

1.1.3.23. A solução deverá ser capaz de simular cenários do tipo P2V, ou seja, a virtualização de servidores físicos;

1.1.3.24. A solução deverá ser capaz de simular cenários do tipo V2P, ou seja, a migração de servidores virtualizados para servidores físicos;

1.1.3.25. A solução deverá ser capaz de simular cenários do tipo V2V, ou seja, a migração de uma plataforma de virtualização para outra plataforma de virtualização;

1.1.3.26. A solução deverá ser capaz de simular cenários do tipo P2P, ou seja, a migração de uma plataforma física para outra plataforma física;

1.1.3.27. A solução deverá ser capaz de simular cenários do tipo P2C, ou seja, a migração de uma plataforma física para ambiente em cloud;

1.1.3.28. A solução deverá ser capaz de simular cenários do tipo V2C, ou seja, a migração de servidores virtualizados para ambiente em cloud;

1.1.3.29. A solução deverá ser capaz de simular a consolidação de servidores;

1.1.3.30. A solução deverá ser capaz de simular mudanças na configuração de servidores, mudanças estas que podem ser relacionadas a alterações de hardware (inclusão/exclusão de memória e/ou processadores), alterações de modelos de equipamentos de mesmo fabricante ou então de outros fabricantes;

1.1.3.31. A solução deverá permitir também, na simulação de mudanças de configuração para servidores virtuais, a alteração de parâmetros relacionados ao ambiente virtual – tais como parâmetros de alocação exclusiva de recursos e “capping” de memória e CPU;


1.1.3.32. A solução deverá permitir simulações que possibilitem a análise de possíveis migrações entre plataformas: CISC x CISC; RISC x RISC; CISC x RISC; RISC x CISC;

1.1.3.33. A solução deverá permitir a simulação de aumento contínuo da carga de trabalho dos servidores de um determinado cenário;

1.1.3.34. A solução deverá permitir a simulação de aumentos variáveis/sazonais da carga de trabalho dos servidores de um determinado cenário;

1.1.3.35. A solução deverá ser capaz de modelar cenários com uso de dados coletados automaticamente de aplicações baseadas em JVM e .NET pela solução de Gerenciamento de Desempenho de Aplicações (APM) descrita neste Termo de Referência, item 2, de forma a possibilitar simulações de mudanças nos workloads destas aplicações;

1.1.3.36. A solução deverá permitir que tais modelagens para as cargas de trabalho das aplicações possam ser executadas de forma total ou individual, por aplicação, possibilitando desta forma estudar taxas de crescimento independentes para cada aplicação;

1.1.3.37. A solução deverá ser capaz de reassinalar a carga de uma determinada aplicação específica (com dados oriundos de ferramenta APM, descrita neste Termo de Referência, item 2) para outro servidor, possibilitando assim a execução de estudos de comportamento do ambiente frente às diversas possíveis mudanças que possam vir a ocorrer;

1.1.3.38. A solução deverá permitir a definição do intervalo de baseline, possibilitando assim usar os dados históricos mais adequados nas simulações a serem executadas;

1.1.3.39. A solução deverá permitir a definição do intervalo de forecast desejado (em semanas, meses ou trimestres), possibilitando assim avaliar cada cenário simulado de acordo com o período futuro necessário;

1.1.3.40. A solução deverá permitir que sejam criadas modelagens a partir dos dados de baseline (possibilitando assim a comparação entre diversos cenários criados paralelamente) e também após uma modelagem prévia, permitindo também a criação de cadeia de cenários;

1.1.3.41. A solução deverá permitir que todos os possíveis cenários de simulação sejam exercitados usando a infraestrutura real existente, bem como usando servidores hipotéticos (não existentes na infraestrutura);

1.1.3.42. A solução deverá permitir que seja definida também infraestrutura hipotética de virtualização (Cluster - balanceado ou não balanceado - e Hosts), para posterior uso nos cenários de simulação a serem exercitados;

1.1.3.43. A solução deverá prover “wizards” que possibilitem uma fácil e rápida geração de cenários de simulação;

1.1.3.44. A solução deverá salvar os cenários de simulações criados, permitindo assim seu uso posterior quando necessário.


1.2. Licenças de uso contemplando o cenário descrito no item “Ambiente Atual PRODAM”

1.2.1. O licenciamento de uso do(s) software(s) componente(s) da solução deverá permitir a ativação da solução no ambiente da contratante, respeitando as seguintes condições:

1.2.1.1. As licenças de uso fornecidas referem-se ao direito de uso perpétuo do(s) programa(s) que compõem a solução;

1.2.1.2. O número total de licenças deverá ser definido pela CONTRATADA, de acordo com políticas de licenciamento da empresa fornecedora da solução, com base no ambiente da Contratante e números expressos no item “Ambiente Atual Prodam”;

1.2.1.3. A Documentação do Licenciamento e Direito de Uso do Software, envolvido na solução, deve ser fornecida pelo fabricante, garantindo à CONTRATANTE o suporte técnico e atualização do software durante todo o prazo contratado.

1.3. Serviços de Instalação, Configuração e Migração de dados

1.3.1. Toda e qualquer instalação e configuração da solução é de responsabilidade da CONTRATADA e deve ser iniciado em até 30 dias após a assinatura do contrato;

1.3.2. A CONTRATADA deve garantir que os dados históricos e atuais de capacidade da solução atual instalada em ambiente CONTRATANTE esteja disponível na solução adquirida.

1.4. Operação Assistida (hands-on) 1.4.1. A CONTRATADA deverá manter profissional capacitado no(s) produto(s)

componente(s) da solução por um período mínimo de 90 (noventa) dias, de segunda a sexta-feira das 8:00h às 17:00h (ou a critério, negociado entre as partes) no ambiente da contratante no intuito de atuar na customização, operacionalização (hands-on) e suporte inicial da solução;

1.4.2. Um analista da CONTRATANTE acompanhará o profissional da CONTRATADA durante o período de operação assistida;

1.4.3. A operação assistida será iniciada somente após a finalização da instalação da solução em ambiente da Contratante;

1.4.4. A CONTRATANTE emitirá Termo de Aceite para fins de comprovação após completados 60 (sessenta) dias de operação assistida.

1.5. Treinamento

1.5.1. A CONTRATADA deverá oferecer treinamento oficial da solução implantada, no prazo de até 30 (trinta) dias corridos a contar da data de emissão do Termo de Aceite, com o mínimo de 40 (quarenta) horas de


duração de cada produto/modulo que compõe a solução, para o mínimo de 7 (sete) funcionários da CONTRATANTE (divididos em 2 turmas, agendadas em datas distintas a critério da CONTRATANTE);

1.5.2. O treinamento deve ser realizado em dias úteis, dentro do Município de São Paulo;

1.5.3. Deverá ser fornecido material impresso ou digital no idioma português ou inglês;

1.5.4. Ao final do treinamento, os participantes deverão receber certificado de conclusão;

1.5.5. O treinamento deverá ser ministrado por instrutores certificados pela empresa fornecedora da solução, englobando, pelo menos, os seguintes aspectos:

1.5.5.1. Introdução ao software (conceitos, componentes e arquitetura);

1.5.5.2. Planejamento de uso (requisitos de ambiente para instalação);

1.5.5.3. Instalação e configuração do produto; 1.5.5.4. Customização e gerenciamento; 1.5.5.5. Utilização, entendimento, operação.

1.6. Manutenção e Suporte Técnico 24x7

1.6.1. A Manutenção refere-se à continuidade operacional do(s) software(s)

que compõe(m) a solução adquirida dentro do período de 36 (trinta e seis) meses contados a partir da data de emissão do Termo de Aceite, abrangendo todas as atividades de manutenção e suporte requeridas;

1.6.2. Entende-se como suporte o atendimento, pela CONTRATADA, quanto a informações sobre uso e funcionalidades do produto, sem custos adicionais para a CONTRATANTE e sem limite de horas. Inclui também as atividades consultivas para orientação à contratante quanto às providências necessárias à possível utilização, em juízo, das evidências detectadas através do software;

1.6.3. O atendimento para suporte e manutenção será feito pela CONTRATADA no regime 24 x 7 x 365, inclusive nas dependências da contratante quando necessário;

1.6.4. Os chamados para suporte e manutenção serão realizados através de telefone ou correio eletrônico e deverão ser atendidos pela CONTRATADA em até 3 (três) horas após o recebimento da solicitação. Uma solução de contorno ou solução definitiva deve ser dada/aplicada em até 8 (oito) horas;

1.6.5. Toda intervenção na solução, na atualização de versão e adequações das funcionalidades durante o período de contrato, deverão ser realizadas sem quaisquer ônus para CONTRATANTE, independentemente do serviço executado;

1.6.6. Em caso de atualização decorrente de necessidade de correção dos produtos e atualizações de versões, quando disponibilizadas pela empresa fornecedora do software, cabe à CONTRATADA:

1.6.7. Identificar e interpretar os defeitos apresentados pelo software;


1.6.8. Transmitir por escrito, à empresa fabricante do(s) software(s), todas as informações relativas aos problemas encontrados no mesmo, quando estes não puderem ser resolvidas pela CONTRATADA;

1.6.9. Transmitir por escrito, à CONTRATANTE todas as informações e providências tomadas pela empresa fabricante do(s) software(s), no sentido de:

1.6.10. Determinar uma solução de contorno para defeito apresentado; 1.6.11. Determinar como e quando será feita a correção definitiva do

defeito apresentado. 1.6.12. Dentro do período de vigência do Contrato: 1.6.13. Realizar as manutenções necessárias e solicitadas para que o

ambiente esteja atualizado; 1.6.14. Entregar à CONTRATANTE o meio magnético ou senha de

download e a documentação atualizados das novas versões que venham a ser liberadas pelo fornecedor para correções de erros que afetem o seu funcionamento normal, ou que possuam melhorias de performance e novas funcionalidades;

1.6.15. Proceder à instalação e configuração necessárias.

2. Solução de Software de Gerenciamento de Desempenho de Aplicações (Application Performance Management - APM)

2.1. Requisitos do(s) componente(s) da solução

2.1.1. Requisitos Gerais de Gerenciamento de Aplicações

2.1.1.1. Monitorar e incluir a visão de desempenho e disponibilidade dos serviços que sustentam a aplicação JEE, tais como: servidores de aplicação, servidores WEB e conexão backend (Oracle, PostgreSQL, Web Services, EJB, RMI, JMS);

2.1.1.2. Compatibilidade total com a especificação Java 2 SDK, Standard Edition 1.5 e superiores;

2.1.1.3. Monitorar aplicações desenvolvidas na plataforma JEE e possuir total compatibilidade com a especificação Java 2 SDK, Standard Edition 1.5 e superiores;

2.1.1.4. A solução deve permitir a monitoração de extensões lambda do JDK 1.8;

2.1.1.5. Deve ter capacidade de monitorar qualquer aplicação Microsoft .NET para Windows e aplicações executadas no container IIS;

2.1.1.6. Possuir total compatibilidade com a especificação Microsoft .NET framework V2.0 e superiores suportadas pelo fabricante;

2.1.1.7. Monitorar aplicações desenvolvidas na plataforma PHP, framework 5.4 e 5.5;

2.1.1.8. 1.8 Ser compatível com as diferentes implementações da JVM (Oracle, IBM e OpenJDK);


2.1.1.9. Deve ser independente do container e contemplar, pelo menos, todos os abaixo descritos:

2.1.1.9.1. Sun Glassfish 2.1.1.9.2. Oracle Application Server 2.1.1.9.3. Tomcat 2.1.1.9.4. Jboss 2.1.1.9.5. Weblogic 2.1.1.9.6. Websphere Application Server"

2.1.1.10. Monitorar aplicações instaladas nos containers em quaisquer das plataformas eversões Java_SE: X-86 com JVM 1.5, RISC com JVM 1.5 e superiores;

2.1.1.11. Não utilizar da interface de monitoramento JVMPI dado seu excessivo consumode recursos de CPU e seus efeitos sobre a performance das JVMs e também pelo fato de tal interface estar descontinuada a partir da versão JavaSE – 1.5;

2.1.1.12. Monitorar, de forma automática (plug-and-play), todos os componentes padrão da arquitetura JEE sem a necessidade de qualquer customização adicional;

2.1.1.13. Suportar extração de dados via JMX (JSR 3: JavaTM Management Extensions(JMXTM) Specification) e mBeans;

2.1.1.14. Coletar indicadores de consumo de memória da JVM; 2.1.1.15. Coletar indicadores de consumo de CPU do servidor de

aplicação; 2.1.1.16. Coletar indicadores de consumo de CPU do processo

Java; 2.1.1.17. Coletar indicadores de tempo médio individualizado da

execução dos componentes padrão da arquitetura JEE (Servlets, JSP, JSF, EJB, Métodos das ClassesJava, JDBC, Queries, JTA, JMS, JNDI, etc);

2.1.1.18. Coletar indicadores de número de sessões em tempo real;

2.1.1.19. Capturar erros e exceções em qualquer ponto da aplicação, em tempo real, e fornecer dados, também em tempo real, que permitam aos administradores identificar o tipo de erro e o ponto exato da transação onde o mesmo ocorreu;

2.1.1.20. Monitorar recursos de infraestrutura do servidor de aplicação (utilização e disponibilidade de thread e connection pools, memória, CPU) correlacionando os dados coletados com os dados da aplicação monitorada, em mesma escala de tempo;

2.1.1.21. Monitorar a interação entre a aplicação e serviços de mensageria (ex: JMS),quanto à disponibilidade e tempos de resposta dos serviços;

2.1.1.22. Monitorar serviços de acesso ao banco de dados, utilizado pelas aplicações, quanto ao teor das clásulas SQL (select, commit, update e insert) encaminhadas ao


banco de dados, seu processamento e disponibilidade, quando utilizadas pelas aplicações;

2.1.1.23. Ao monitorar os serviços de acesso ao banco, no mínimo, deve ser mostrado a query executada e seu tempo de execução;

2.1.1.24. Monitorar o tempo total gasto para processamento do conjunto de dados obtidos por uma query junto ao banco de dados;

2.1.1.25. Monitorar o comportamento da utilização de memória pelo servidor de aplicaçãoJEE, bem como o processo de gerenciamento de memória denominado GarbageCollection;

2.1.1.26. Fornecer dados em tempo real sobre o comportamento das diversas áreas de memória da JVM (EX: Eden, Tenured, Permanent e Old), incluindo a especificação do Java 1.8;

2.1.1.27. Monitorar volume de objetos instanciados em memória, sejam eles tanto do tipo “collections” quanto do tipo “não collections”, e também os utilizados pela aplicação para conexões a banco de dados;

2.1.1.28. Monitorar em tempo real e histórico a execução da aplicação e correlacionar métricas obtidas em diferentes períodos definidos pelo usuário;

2.1.1.29. Permitir o rastreamento das transações entre JVMs que estejam no mesmo servidor ou em servidores distintos;

2.1.1.30. Ter a capacidade de correlacionar a performance percebida pelos usuários da aplicação com as camadas da infraestrutura que a suportam, apresentando em uma única tela a performance do pool de servidores, rede e front end, para rápida identificação do domínio da falha;

2.1.1.31. Apresentar mapa automático (console de serviços) da arquitetura da aplicação monitorada evidenciando os componentes da aplicação Java (instâncias), os backends ao qual ela se conecta (bancos de dados, Web Services, conexões socket com outros sistemas), e as transações que consomem determinada infraestrutura de aplicações;

2.1.1.32. Mostrar para cada transação escolhida na interface o mapa de relacionamento atualizado, informando quais backends participam daquela transação;

2.1.1.33. Para cada método, permitir identificar a contribuição para os métodos caller e para a transação da qual faz parte;

2.1.1.34. Apresentar informações de transações mostrando a tempo gasto em cada camada de aplicação sendo invocada;

2.1.1.35. Dentre as métricas coletadas referentes às páginas web que complementam as métricas de experiência do usuário, devem ser informados, quando disponíveis: o tempo médio de construção de objetos DOM (javascript); o tempo médio de carga total da página - de quando o


browser faz a primeira requisição da página até o recebimento de todo o conteúdo;

2.1.1.36. Não deve existir limite na quantidade de transações de negócios que podem ser monitoradas. A solução deve permitir o cadastro de a monitoração de quantas transações forem necessárias;

2.1.1.37. A solução deve monitorar arquiteturas SOA em diversos frameworks e servidores de aplicação e deve mostrar um mapa de dependência entre os serviços, consumidores, hosts;

2.1.1.38. A solução não deve se ater somente a monitorar os itens básicos e frameworks padrão. Deve ser possível estender as capacidades de monitoração e criar métricas específicas conforme a necessidade de cada aplicação. Por exemplo, pode existir a necessidade de se criar uma métricas exclusiva para uma classe construída em nossa fábrica de software.

2.1.2. Requisitos gerais

2.1.2.1. Monitorar aplicações com base na instrumentalização no

nível da JVM e para tanto utilizar a tecnologia “Bytecode Instrumentation” para monitoramento das classes emétodos das aplicações sejam estes apresentados na forma dos componentes-padrão da arquitetura JEE (JSP, JSF, Servlets, EJB, EJB3, JNDI, XML, JDBC, JCA, JTA), sejam estes componentes apresentados na forma de classes de negócio especializadas (POJO– Plain Old Java Objects);

2.1.2.2. Monitorar a performance das aplicações com baixo incremento de consumo nos servidores monitorados, via tecnologia de Bytecode Instrumentation, dentre outras funcionalidades;

2.1.2.3. Permitir a configuração de limites (thresholds) para qualquer dos itens e também para agrupamentos de itens monitorados;

2.1.2.4. Associar ações aos limites (thresholds) configurados: notificação automática por e-mail, alerta na tela do usuário de monitoramento;

2.1.2.5. Deve ser possível a configuração de janelas de manutenção, que é a definição de datas e horários quando os itens estarão propositalmente indisponíveis, situações nas quais a solução não deverá gerar alertas.

2.1.2.6. Fornecer recurso para a exportação das informações coletadas pela solução para os formatos tradicionais de intercâmbio de arquivos entre aplicações, pelo menos para um formato padrão a seguir: CSV, JSON ou XML;

2.1.2.7. Fornecer acesso aos recursos do produto via interface web (compatibilidade, no mínimo, com versões de browsers Internet Explorer e/ou Firefox;


2.1.2.8. Gerar relatórios e disponibilizar gráficos via interface web (análise em tempo de execução) a qualquer momento e também a partir de base histórica;

2.1.2.9. Monitorar o tempo de resposta das transações apresentando os tempos parciais por classes e métodos;

2.1.2.10. Coletar indicadores de erros na aplicação por determinado intervalo de tempo;

2.1.2.11. Possibilitar a análise de indicadores em determinado intervalo de tempo;

2.1.2.12. Capaz de apresentar as métricas descritas (indicadores) de forma individualizada para cada uma das instâncias monitoradas;

2.1.2.13. Permitir a configuração do número de transações executadas a serem monitoradas;

2.1.2.14. Agrupar métricas de várias instâncias de uma aplicação em uma visão consolidada das múltiplas instâncias, além da apresentação individualizada por instância monitorada;

2.1.2.15. Permitir o agrupamento de métricas similares de qualquer dos componentes da aplicação em um gráfico único permitindo ainda sua ordenação e seleção dos top “n";

2.1.2.16. Permitir o aumento de visibilidade sobre a performance da aplicação e o correlacionamento de métricas de uma JVM isolada quanto de uma visão consolidada das JVMs permitindo assim visão efetiva da performance da aplicação;

2.1.2.17. Coletar informações de performance (tempo de resposta, erros, número de execuções) em tempo real e apresentar em forma gráfica em intervalos configuráveis, com granularidade de, no mínimo, 1 minuto;

2.1.2.18. Gerar uma linha de base estatística para cada aplicação monitorada que deverá representar o comportamento habitual estatístico da aplicação;

2.1.2.19. Gerar alertas identificando a camada da aplicação (apresentação, back-ends e recursos) onde o desvio foi identificado, o comportamento esperado e o comportamento apresentado sempre que a aplicação apresentar comportamento diferente daquele esperado pela linha de base;

2.1.2.20. Calcular a linha de base estatística com base na hora do dia e dia da semana;

2.1.2.21. Possibilitar a extração de informações, através de relatórios, personalizadas e de forma interativa, sem necessidade de uso de outros produtos para esta atividade;

2.1.2.22. Permitir que as telas de apresentação das métricas (dashboards) sejam facilmente personalizáveis pelos próprios usuários de acordo com sua necessidade, sem a intervenção de pessoal técnico especializado e também sem a necessidade de desenvolvimento de código ou utilização de API’s;


2.1.2.23. Os alarmes de serviços devem resultar da condição de um ou mais itens de configuração combinados impactarem a qualidade ou nível do risco associado ao serviço;

2.1.2.24. Permitir a definição de política para aquele modelo de serviço que determinará como um alarme em um item de configuração impactará outros itens de configuração e os serviços;

2.1.2.25. Possuir uma interface de relatórios, que permita a geração, sob demanda ou agendada, de relatórios históricos, inclusive para impressão, para os serviços gerenciados, contendo relatórios como:

2.1.2.25.1. sumário de serviços - mostrar um sumário da saúde de um serviço e a lista de paradas em um período;

2.1.2.25.2. top 10 ICs (backends) que degradem serviços – mostrar os 10 itens que geraram downtime de serviços;

2.1.2.25.3. disponibilidade de serviço – mostrar a disponibilidade para um dado serviço em um período;

2.1.2.25.4. saúde de serviço – mostrar a saúde para um dado serviço em um período;

2.1.2.25.5. qualidade de serviço - mostrar a qualidade para um dado serviço em um período;

2.1.2.25.6. top 10 serviços com alto risco – mostrar os 10 serviços que durante mais tempo tiveram com risco;

2.1.2.25.7. top 10 serviços com baixa qualidade – mostrar os 10 serviços que durante mais tempo tiveram baixa qualidade;

2.1.2.25.8. top 10 serviços com ICs degradados - mostrar os 10 itens de configuração com maior downtime de serviço.

2.1.2.26. Deve prover métricas referentes a carga de páginas web facilitando a identificação de gargalos - rede, browser, servidor de aplicação;

2.1.2.27. No que diz respeito a monitoração de páginas web, solução deve permitir a agregação de métricas por grupos de URL;

2.1.2.28. Com o objetivo de acelerar o tempo de desenvolvimento a solução devem prover painéis pré-construídos com as métricas referentes a carga de páginas web;

2.1.2.29. A solução deve possuir a capacidade de descobrir e instrumentar métodos de forma automática enriquecendo e facilitando a investigação problemas;

2.1.2.30. Considerando a funcionalidade de instrumentação automática de métodos, a solução deve permitir a configuração do escopo e abrangência da descoberta;

2.1.2.31. Uma vez executada uma instrumentação automática a aplicação deve prover forma de exportar as descobertas


para uma posterior utilização em outros componentes similares;

2.1.2.32. A solução deve conter funcionalidades para detecção de erros através de análises estatísticas e detecção de anomalias e padrões;

2.1.2.33. A detecção automática de anomalias deve permitir, durante a investigação do problema, a filtragem dos componentes participantes da transação;

2.1.2.34. A solução deve possuir a capacidade de mostrar,quando existentes, transações oriundas de applicativos móveis indicando o sistema operacional utilizado;

2.1.2.35. Deve ser possível monitorar aplicações de big data, entre elas, MongoDB e Hadoop;

2.1.2.36. Monitorar em tempo de execução e detectar mudanças ocorridas na aplicação (arquivos do tipo .class, .java, .jar, .ear, .xml, .properties, etc.) e correlacioná-las com a performance da aplicação;

2.1.2.37. Deverá prover funcionalidade de comparação diferencial entre versões de arquivos da aplicação, baseados em formato texto, cuja alteração tenha sido detectada pela solução;

2.1.2.38. Deve identificar qual tipo de alteração foi implementada bem como a data e horário onde a mesma ocorreu.

2.1.3. Arquitetura da solução de monitoramento

2.1.3.1. Não necessitar realizar modificações ou alterações dos códigos fontes das aplicações monitoradas;

2.1.3.2. Não requerer a inserção de scripts no código fonte da aplicação monitorada, com exceção do monitoramento da camada web;

2.1.3.3. Preservar os dados históricos na mudança de versão da solução de monitoramento, inclusive as baselines, sendo esses visualizados na nova versão;

2.1.3.4. Monitoramento da aplicação iniciado de forma automática juntamente com a inicialização do servidor de aplicações;

2.1.3.5. No caso de utilização de banco de dados próprio, as licenças necessárias serão de responsabilidade da CONTRATADA;

2.1.3.6. O processamento de dados para consolidação da base, assim como para geração de relatórios e consultas, não deverá ocorrer nos servidores monitorados e sim em um servidor de gerenciamento específico para esse fim;

2.1.3.7. Servidor de gerenciamento compatível com os sistemas operacionais Windows e Linux (nas distribuições RHEL, Suse e Oracle Linux);

2.1.3.8. Deverá ser compatível com os sistemas de virtualização VMware, Hyper-V, Xene RHEV;


2.1.3.9. Não apresentar incremento no consumo de CPU do ambiente monitorado superior a 5% (cinco por cento) com coleta incluindo monitoração até nível de método no servidor de aplicação JAVA, e sem a ocorrência de perdas de dados coletados, com margem de tolerância de consumo de CPU de, no máximo, 7% (sete por cento);

2.1.3.10. Possibilitar a pesquisa de erros em bases históricas sem a necessidade de leitura de arquivos de log externos à solução;

2.1.3.11. Armazenar 100% (cem por cento) dos dados coletados, em base histórica pelo período de 2 (dois) anos;

2.1.3.12. Processar os dados para consolidação da base, assim como para geração de relatórios e consultas, fora dos servidores monitorados. Usar um servidor de gerenciamento específico para esse fim;

2.1.3.13. É obrigatório que a solução seja escalável permitindo a monitoração de mais de 4000 servidores de aplicação, sem degradação de performance.

2.1.4. Integração com outras soluções

2.1.4.1. A solução deve permitir monitoração de servidores sharepoint nas versões 2007, 2010 - rodando em Windows versões suportadas pelo sharepoint 2013 - Windows 2012R;

2.1.4.2. A solução deve permitir monitoração de servidores de mensageria IBM MQ nas seguintes versões V6.0.x, v7.0 , v7.1, v7.5 - WebSphereMQ Queue Manager;

2.1.4.3. A solução deve permitir monitoração de servidores IBM Websphere Message Broker nas seguintes versões v7.0 ,v8.0;

2.1.4.4. Ao monitorar o IBM MQ no mínimo as seguintes informação devem ser providas:

2.1.4.4.1. Métricas de Canal - Channel Indoubt Status,Aggregated Channel Instance Counts,Channel Name,Channel Type,Cluster Name,Max Message Length,Queue Manager Name;

2.1.4.4.2. Métricas de Queue - Creation Date,Default Priority,Max Message Length,Max Queue Depth.

2.1.4.5. Deve permitir a coleta de informações dos servidores web

: Apache, IIS e IBM HTTP Server (IHS): 2.1.4.5.1. Apache 2.0, 2.2, 2.4; 2.1.4.5.2. Microsoft IIS 6.0, 7.0; 2.1.4.5.3. IBM HTTP Server (IHS) 7.0, 8.5.

2.1.4.6. Ao monitorar os servidores web Apache ou IBM, as informações abaixo quando publicadas devem ser informadas:

2.1.4.6.1. Disponibilidade;


2.1.4.6.2. Status; 2.1.4.6.3. Bytes Transferidos por intervalo de tempo; 2.1.4.6.4. Requisições por Intervalo; 2.1.4.6.5. Número de ocupados; 2.1.4.6.6. Número de disponíveis.

2.1.4.7. A solução deve possuir API REST documentada; 2.1.4.8. Com a solução deve ser possível monitorar bancos de

dados Oracle nas versões Oracle 9i, Oracle 10g, Oracle 11g (até R2), Oracle 11g R2 PS2/PS3, Oracle 12c;

2.1.4.9. Ao monitorar os bancos de dados Oracle citados acima, no mínimo a seguintes recursos devem ser observados:

2.1.4.9.1. Disponibilidade; 2.1.4.9.2. Número de deadlocks; 2.1.4.9.3. Número de full table scans; 2.1.4.9.4. Quantidade de waits e switchs nos arquivos Redo

Log; 2.1.4.9.5. Quantidades de taxas de get e wait em segmentos

de rollback; 2.1.4.9.6. Tamanho do Buffer SGA - System Global Area; 2.1.4.9.7. Taxa de sort em memória e disco; 2.1.4.9.8. Quantidade de read/write nas table spaces.

2.1.4.10. Deve ser possível monitorar arquiteturas as plataformas

abaixo: 2.1.4.10.1. Oracle Service Bus (OSB); 2.1.4.10.2. TIBCO BusinessWorks; 2.1.4.10.3. TIBCO Enterprise Message Service; 2.1.4.10.4. WebMethods Broker; 2.1.4.10.5. WebMethods Integration Server; 2.1.4.10.6. IBM WebSphere Process Server (WPS); 2.1.4.10.7. IBM WebSphere Enterprise Service Bus (WESB).

2.1.5. Requisitos Específicos para o monitoramento da Experiência do Usuário Final através de transações HTTP/HTTPS reais

2.1.5.1. Oferecer uma monitoração sem agentes baseada na

captura e decodificação de pacotes de rede, não intrusiva;

2.1.5.2. Possuir rotina de Exportação e Importação das configurações dos coletores;

2.1.5.3. Oferecer funcionalidade para replicar as configurações feitas em um coletor para os demais coletores existentes no ambiente, reduzindo assim o esforço de gerenciamento da solução;

2.1.5.4. Possuir capacidade de executar Backup e Restore de dados;

2.1.5.5. Permitir o cadastramento e configuração de chaves privadas para monitoração do tráfego HTTPS;


2.1.5.6. Permitir a completa e total proteção às informações de identificação dos usuários (ex.: usuário/senha), através do cadastramento e armazenamento de parâmetros http/https que são sensíveis à segurança;

2.1.5.7. Possuir funcionalidade de gravação das transações cuja estrutura HTTP(assinatura) possa ser capturada e promovida aos status de transação monitorada pela solução;

2.1.5.8. A gravação e o armazenamento da estrutura de uma nova transação não devem requerer nenhum tipo de programação ou configuração avançada, devendo estar disponível na interface gráfica;

2.1.5.9. Monitorar todas as transações reais que trafegam na rede e que estão configuradas para serem monitoradas pela solução;

2.1.5.10. Verificar se uma transação ou requisição HTTP ou HTTPS foi atendida do ponto de vista do usuário final, dentro dos parâmetros configurados;

2.1.5.11. Permitir a definição, para cada transação cadastrada, dos componentes desta transação (.gif, .jpeg, .css, etc), da sua obrigatoriedade na resposta para caracterização de sucesso na transação;

2.1.5.12. Permitir a definição, para cada transação cadastrada, de limites (thresholds) pelos quais os defeitos serão caracterizados;

2.1.5.13. Permitir a definição, para cada transação cadastrada, dos tipos de erros de execução possíveis. Ex.: HTTP 203 - Erro de Comunicação, HTTP 401 - Acesso não autorizado, etc;

2.1.5.14. Permitir a definição, para cada transação cadastrada, dos níveis de serviço acordados para a mesma;

2.1.5.15. Monitorar 100% das transações HTTP e HTTPS reais dos usuários, não sendo permitida monitoração baseada em amostragem;

2.1.5.16. Fornecer as seguintes informações para cada transação monitorada:

2.1.5.16.1. Data e Hora 2.1.5.16.2. Endereço IP da aplicação cliente (ex. Navegador) 2.1.5.16.3. Endereço IP e porta do servidor web (HTTP

Server) 2.1.5.16.4. Endereço IP do servidor de aplicação 2.1.5.16.5. Nome do Request Handler (ex. ActionServlet) da

transação 2.1.5.16.6. Tempo de resposta da transação

(Requisição/Resposta HTTP) 2.1.5.16.7. Tipo de defeito detectado 2.1.5.16.8. Condição de defeito (threshold) 2.1.5.16.9. Valor real observado 2.1.5.16.10. Tamanho (kB) 2.1.5.16.11. Throughput (kB/s)


2.1.5.16.12. Tempo até primeira resposta (s) 2.1.5.16.13. Parâmetros HTTP"

2.1.5.17. Capacidade de mostrar como a taxa de sucesso de uma

transação, o tempo médio, e a contagem de transações mudaram durante um período de tempo específico, como por exemplo, hoje em comparação com ontem;

2.1.5.18. Análise da performance das aplicações por grupo de usuários finais.

2.1.5.19. Monitoração baseada em incidentes na experiência do usuário permitindo a priorização pela criticidade da transação, dos usuários e impacto ao negócio;

2.1.5.20. Forte integração com a análise de causa raiz, permitindo conectar imediatamente um problema na experiência do usuário com o componente da aplicação que está causando a degradação, como por exemplo comando SQL, chamada WebServices, programa no mainframe, EJB, etc. Esta correlação deve ser feita transação a transação de tal maneira a obter uma visão fim-a-fim;

2.1.5.21. Permitir a análise de problemas através do conceito de pareto onde 20% das transações resultam em 80% dos problemas;

2.1.5.22. Permitir a definição de acordos de níveis de serviço onde um processo de negócio tenha percentuais associados para a quantidade de transações que completaram com sucesso e a quantidade de transações que completaram dentro de um tempo estabelecido;

2.1.5.23. Em hipótese alguma a aplicação deve enviar dados para fora do Brasil. A solução deve ser entregue no modelo ON Premise, ou seja, com todos os servidores instalados em um datacenter dentro do Brasil.

2.1.6. Requisitos Específicos para o monitoramento de Ambientes SOA (Service Oriented Architecture)

2.1.6.1. Monitorar pelo menos os seguintes ESBs (Enterprise

Service Bus): 2.1.6.1.1. Oracle Service Bus 3.0 (também conhecido como

AquaLogic Service Bus 3.0); 2.1.6.1.2. Oracle Service Bus 10.3, 11.1.1.3, 11.1.1.4,

11.1.1.5, 11.1.1.7; 2.1.6.1.3. WebSphere Process Server/ESB 7.0, ESB 7.5.1,

8.0.

2.1.6.2. Monitorar detalhes intrínsecos ao Oracle ESB e apresentar painéis com no mínimo as seguintes métricas:

2.1.6.2.1. Proxy Services; 2.1.6.2.2. Business Services; 2.1.6.2.3. Pipeline;


2.1.6.2.4. XQueries; 2.1.6.2.5. Transports; 2.1.6.2.6. UDDI.

2.1.6.3. Monitorar detalhes intrínsecos ao WebSphere ESB e

Websphere Process Server (WPS) e apresentar painéis com no mínimo as seguintes métricas:

2.1.6.3.1. Business Processes; 2.1.6.3.2. Business State Machines; 2.1.6.3.3. Business Rules; 2.1.6.3.4. Java Components; 2.1.6.3.5. Mediation Flows; 2.1.6.3.6. Mediation Primitives; 2.1.6.3.7. Human Tasks; 2.1.6.3.8. Selectors; 2.1.6.3.9. Interface Maps; 2.1.6.3.10. Adapters; 2.1.6.3.11. BO Maps; 2.1.6.3.12. Relationships; 2.1.6.3.13. Selectors; 2.1.6.3.14. WPS Faults.

2.1.6.4. Permitir o rastreamento de transações entre processos,

de tal maneira a capturar uma transação que seja iniciada no WebLogic Portal, passe pelo ESB e chegue ao Aqualogic Data Services. O mecanismo de rastreamento deve ser genérico a ponto de permitir que chamadas a quaisquer WebServices sejam passíveis de correlacionamento, não importando a origem ou o destino;

2.1.6.5. Permitir-se-á que o mecanismo de rastreamento insira identificadores de correlação nas mensagens SOAP trafegadas entre os processos, no entanto o mecanismo deverá prover opções de onde esse identificador será inserido, como por exemplo:

2.1.6.5.1. Na própria mensagem SOAP (no cabeçalho da mensagem) ou;

2.1.6.5.2. No cabeçalho da mensagem HTTP que encapsula a mensagem SOAP.

2.1.6.6. O mecanismo de rastreamento deverá suportar mensagens SOAP v 1.1.

2.1.6.7. O mecanismo de rastreamento deverá ser próprio da ferramenta de monitoramento, não requerendo a criação de código customizado tanto para a inserção do identificador de correlação quanto para a identificação dos Web Services, exceto em casos que a pilha WebServices não for suportada;

2.1.6.8. Monitorar cada execução de Web Service detalhando o namespace ao qual pertence bem como a operação


invocada. Isto deverá ser feito tanto para Web Services produzidos quanto para Web Services consumidos;

2.1.6.9. Apresentar painéis de monitoramento dos Web Services contendo gráficos Top-N com o tempo médio dos Web Services produzidos e consumidos pelas aplicações;

2.1.6.10. Cada Web Service monitorado deverá produzir, no mínimo, as seguintes métricas:

2.1.6.10.1. Tempo Médio de Resposta; 2.1.6.10.2. Quantidade de execuções por intervalo; 2.1.6.10.3. Concorrência; 2.1.6.10.4. Exceções na camada SOAP; 2.1.6.10.5. Exceções na camada Java; 2.1.6.10.6. Execuções “congeladas”.

2.1.6.11. Monitorar exceções de negócio geradas pela camada SOAP como, por exemplo, “parâmetros inválidos na mensagem”;

2.1.6.12. Monitorar o tempo de resposta médio e a quantidade de execuções do processamento (parsing) de mensagens XML através de XQueries;

2.1.6.13. O monitoramento do ambiente SOA deverá abranger 100% das transações e deverá estar habilitado todo o tempo. O monitoramento baseado em amostragem ou execução de transações simuladas não será aceito;

2.1.6.14. A solução deverá apresentar acréscimo de consumo de CPU de até 5% sobre o ambiente SOA monitorado, admitindo-se uma tolerância de 40% sobre este valor (total máximo admitido de 7%).

2.2. Licenças de uso contemplando o cenário descrito no item “Ambiente

Atual PRODAM”

2.2.1. O licenciamento de uso do(s) software(s) componente(s) da solução deverá permitir a ativação da solução no ambiente da contratante, respeitando as seguintes condições:

2.2.1.1. As licenças de uso fornecidas referem-se ao direito de uso perpétuo do(s) programa(s) que compõem a solução;

2.2.1.2. O número total de licenças deverá ser definido pela CONTRATADA, de acordo com políticas de licenciamento da empresa fornecedora da solução, com base no ambiente da Contratante e números expressos no item “Ambiente Atual Prodam”;

2.2.1.3. A Documentação do Licenciamento e Direito de Uso do Software, envolvido na solução, deve ser fornecida pelo fabricante, garantindo à CONTRATANTE o suporte técnico e atualização do software durante todo o prazo contratado.


2.3. Serviços de Instalação, Configuração e Migração de dados

2.3.1. Toda e qualquer instalação e configuração da solução é de responsabilidade da CONTRATADA e deve ser iniciado em até 30 dias após a assinatura do contrato;

2.3.2. A CONTRATADA deve garantir que os dados históricos e atuais de capacidade da solução atual instalada em ambiente CONTRATANTE esteja disponível na solução adquirida.

2.4. Operação Assistida (hands-on) 2.4.1. A CONTRATADA deverá manter profissional capacitado no(s) produto(s)

componente(s) da solução por um período mínimo de 90 (noventa) dias, de segunda a sexta-feira das 8:00h às 17:00h (ou a critério, negociado entre as partes) no ambiente da contratante no intuito de atuar na customização, operacionalização (hands-on) e suporte inicial da solução;

2.4.2. Um analista da CONTRATANTE acompanhará o profissional da CONTRATADA durante o período de operação assistida;

2.4.3. A operação assistida será iniciada somente após a finalização da instalação da solução em ambiente da Contratante;

2.4.4. A CONTRATANTE emitirá Termo de Aceite para fins de comprovação após completados 60 (sessenta) dias de operação assistida.

2.5. Treinamento

2.5.1. A CONTRATADA deverá oferecer treinamento oficial da solução implantada, no prazo de até 30 (trinta) dias corridos a contar da data de emissão do Termo de Aceite, com o mínimo de 40 (quarenta) horas de duração de cada produto/modulo que compõe a solução, para o mínimo de 12 (doze) funcionários da CONTRATANTE (divididos em 2 turmas, agendadas em datas distintas a critério da CONTRATANTE);

2.5.2. O treinamento deve ser realizado em dias úteis, dentro do Município de São Paulo;

2.5.3. Deverá ser fornecido material impresso ou digital no idioma português ou inglês;

2.5.4. Ao final do treinamento, os participantes deverão receber certificado de conclusão;

2.5.5. O treinamento deverá ser ministrado por instrutores certificados pela empresa fornecedora da solução, englobando, pelo menos, os seguintes aspectos:

2.5.5.1. Introdução ao software (conceitos, componentes e arquitetura);

2.5.5.2. Planejamento de uso (requisitos de ambiente para instalação);

2.5.5.3. Instalação e configuração do produto na infraestrutura Prodam;

2.5.5.4. Customização e gerenciamento;


2.5.5.5. Utilização, entendimento, operação.

2.6. Manutenção e Suporte Técnico 24x7 2.6.1. A Manutenção refere-se à continuidade operacional do(s) software(s)

que compõe(m) a solução adquirida dentro do período de 36 (trinta e seis) meses contados a partir da data de emissão do Termo de Aceite, abrangendo todas as atividades de manutenção e suporte requeridas;

2.6.2. Entende-se como suporte o atendimento, pela CONTRATADA, quanto a informações sobre uso e funcionalidades do produto, sem custos adicionais para a CONTRATANTE e sem limite de horas. Inclui também as atividades consultivas para orientação à contratante quanto às providências necessárias à possível utilização, em juízo, das evidências detectadas através do software;

2.6.3. O atendimento para suporte e manutenção será feito pela CONTRATADA no regime 24 x 7 x 365, inclusive nas dependências da contratante quando necessário;

2.6.4. Os chamados para suporte e manutenção serão realizados através de telefone ou correio eletrônico e deverão ser atendidos pela CONTRATADA em até 3 (três) horas após o recebimento da solicitação. Uma solução de contorno ou solução definitiva deve ser dada/aplicada em até 8 (oito) horas;

2.6.5. Toda intervenção na solução, na atualização de versão e adequações das funcionalidades durante o período de contrato, deverão ser realizadas sem quaisquer ônus para CONTRATANTE, independentemente do serviço executado;

2.6.6. Em caso de atualização decorrente de necessidade de correção dos produtos e atualizações de versões, quando disponibilizadas pela empresa fornecedora do software, cabe à CONTRATADA:

2.6.7. Identificar e interpretar os defeitos apresentados pelo software; 2.6.8. Transmitir por escrito, à empresa fabricante do(s) software(s), todas as

informações relativas aos problemas encontrados no mesmo, quando estes não puderem ser resolvidas pela CONTRATADA;

2.6.9. Transmitir por escrito, à CONTRATANTE todas as informações e providências tomadas pela empresa fabricante do(s) software(s), no sentido de:

2.6.10. Determinar uma solução de contorno para defeito apresentado; 2.6.11. Determinar como e quando será feita a correção definitiva do

defeito apresentado. 2.6.12. Dentro do período de vigência do Contrato: 2.6.13. Realizar as manutenções necessárias e solicitadas para que o

ambiente esteja atualizado; 2.6.14. Entregar à CONTRATANTE o meio magnético ou senha de

download e a documentação atualizados das novas versões que venham a ser liberadas pelo fornecedor para correções de erros que afetem o seu funcionamento normal, ou que possuam melhorias de performance e novas funcionalidades;

2.6.15. Proceder à instalação e configuração necessárias.


3. Confidencialidade 3.1. A CONTRATADA deverá zelar pelo sigilo de quaisquer informações

referentes à estrutura, sistemas, usuários, contribuintes, topologia, e ao modo de funcionamento e tratamento das informações da CONTRATANTE, durante e após fim do contrato, salvo se houver autorização expressa para divulgação.

4. Condições de Faturamento 4.1. O valor será faturado mensalmente e o encaminhamento da Nota Fiscal

de Serviço deverá ser realizado através de Solicitação de Pagamento, até o 5º (quinto) dia útil do mês subsequente ao da efetiva prestação dos serviços.

5. Proposta para Condições de Pagamento 5.1. A Nota Fiscal de Serviços deverá ser emitida e encaminhada à

CONTRATANTE, através do setor de Expediente; 5.2. Após o recebimento da Nota Fiscal de Serviços, a CONTRATANTE

disporá de até 05 (cinco) dias úteis para emissão do Termo de Aceite, aprovando os serviços prestados;

5.3. Além de cumprir todas as legislações atinentes à sua constituição e aos serviços prestados, a CONTRATADA deverá apresentar, a cada pedido de pagamento que efetue, juntamente com a Nota Fiscal de Serviços, todos os documentos que comprovem a regularidade fiscal da empresa, apresentadas no início desta contratação, no original ou cópia com os respectivos originais para comprovação de autenticidade;

5.4. O pagamento será realizado por intermédio de crédito em conta corrente ou por outra modalidade que possa vir a ser determinada pela Gerência Financeira (GFI), em 30 (trinta) dias corridos a contar da data de emissão do Termo de Aceite;

5.5. A CONTRATANTE promoverá, previamente a qualquer desembolso em benefício da CONTRATADA, a verificação no site http://www3.prefeitura.sp.gov.br/candin/ de qualquer pendência no Cadastro Informativo Municipal (CADIN) da Prefeitura do Município de São Paulo, sendo que se for verificada a existência de registro no CADIN em nome da CONTRATADA, incidirão as disposições do artigo 3º da Lei Municipal n.º 14.094, de 06 de dezembro de 2005, suspendendo-se o pagamento enquanto perdurar o registro, ressalvadas a hipótese prevista no artigo 9º do Decreto Municipal n.º 47.096, de 21 de março de 2006;

5.6. Caso a Nota Fiscal/Fatura contenha divergências com relação ao estabelecido no Instrumento Contratual, a CONTRATANTE ficará obrigada a comunicar a empresa CONTRATADA, formalmente, o motivo da não aprovação no prazo de 05 (cinco) dias úteis. A devolução da Nota Fiscal/Fatura, devidamente, regularizada pela CONTRATANTE, deverá ser efetuada em até 05 (cinco) dias úteis da data de comunicação formal pela CONTRATADA;

5.7. Em caso de atraso de pagamento dos valores devidos à CONTRATADA, mediante requerimento formalizado por esta, incidirão juros moratórios calculados utilizando-se o índice oficial de remuneração básica da


caderneta de poupança e de juros simples no mesmo percentual de juros incidentes sobre a caderneta de poupança, para fins de compensação da mora (TR + 0,5% “pro-rata tempore”), observando-se para tanto, o período correspondente à data prevista para o pagamento e aquela data em que o pagamento efetivamente ocorreu.

6. Considerações Gerais 6.1. As soluções que compõem o objeto deste Termo de Referência podem

ser ofertadas através de 1 (uma/um) ou mais ferramentas/softwares, desde que atendam aos requisitos exigidos;

6.2. Todos os recursos de software e mão-de-obra necessários para a prestação dos serviços objeto deste edital (mídia de instalação, manuais, licenças de uso, treinamento, e outros se necessários) serão fornecidos pela CONTRATADA, devendo ser instalados na sede da CONTRATANTE (Av. Francisco Matarazzo,1500 – 14º andar - Barra Funda – SP), toda a solução será mantida e configurada pela CONTRATADA pelo tempo contratado.

7. Critérios técnicos de julgamento/Documentos de habilitação técnica 7.1. Apresentar atestado de capacidade técnica, passado em papel timbrado,

por entidade pública ou privada, que comprove o correto cumprimento de obrigações e serviços, pertinentes e compatíveis com o objeto do TR, devidamente datado assinado e com identificação do atestante.

São Paulo, 14 de Outubro de 2015. Gilson Santos Chagas Gerência de Estratégia e Desenho do Serviço (GIE)

Documents

TERMO DE REFERÊNCIA - Prefeitura · configurações, serviços, processos e negócios; 1.1.1.2. Este componente é responsável, ainda, pela normalização dos ... métricas de performance