projeto básico aquisição de solução multicanal susis/geneg

Projeto Básico Aquisição de Solução Multicanal

SUSIS/GENEGJULHO/2011

Projeto Básico SUSIS/GENEG 2011/003 1

Sumário 1 OBJETO......................................................................................................................4

1.1 AQUISIÇÃO DA SOLUÇÃO DE MULTICANAL...............................................................4 1.2 TRANSFERÊNCIA DE TECNOLOGIA DA SOLUÇÃO ADQUIRIDA E ADAPTADA AO NEGÓCIO BRB...........................................................................................................................4 1.3 SERVIÇOS OPERACIONAIS DE PRODUÇÃO E DE SUPORTE DA SOLUÇÃO DE MULTICANAL NO AMBIENTE BRB ......................................................................................................4

2 FASES DA EXECUÇÃO DO CONTRATO.............................................................................5 2.1 PRIMEIRA FASE ....................................................................................................5 2.2 SEGUNDA FASE ....................................................................................................5 2.3 TERCEIRA FASE ....................................................................................................5 2.4 QUARTA FASE ......................................................................................................5

3 PANORAMA DA AUTOMAÇÃO BANCÁRIA E CANAIS DE ATENDIMENTO.................................6 3.1 CANAIS DE ATENDIMENTO.....................................................................................6 3.2 AUTORIZADOR DE TRANSAÇÕES.............................................................................7 3.3 SISTEMAS DE INFRAESTRUTURA.............................................................................7

4 PROBLEMAS ATUALMENTE ENFRENTADOS.......................................................................7 4.1 OBSOLESCÊNCIA TECNOLÓGICA.............................................................................7 4.2 DESENVOLVIMENTO DE DEMANDAS.........................................................................8 4.3 DESCENTRALIZAÇÃO DE REGRAS............................................................................8 4.4 ESCASSEZ DE DOCUMENTAÇÃO .............................................................................8

5 SOLUÇÃO PROPOSTA....................................................................................................8 5.1 CEN - CENTRALIZADOR e AUTORIZADOR................................................................8 5.2 ATUALIZAÇÃO TECNOLÓGICA.................................................................................9 5.3 GAB – MÓDULO GERAL DE GERENCIAMENTO DA AUTOMAÇÃO BANCÁRIA....................9 5.4 CANAIS DE ATENDIMENTO.....................................................................................9 5.5 DOCUMENTAÇÃO ..................................................................................................9

6 DESCONTINUIDADE DE SISTEMAS...............................................................................10 7 ESPECIFICAÇÃO TÉCNICA...........................................................................................10

7.1 Requisitos Gerais:................................................................................................10 7.2 CAIXA AGÊNCIA E CORRESPONDENTES..................................................................12 7.3 IBK – INTERNET BANKING (PESSOA FÍSICA E JURÍDICA) E TELEBANCO....................13 7.4 MBK – MOBILE BANKING......................................................................................15 7.5 MPY – MOBILE PAYMENT.......................................................................................15 7.6 MSM – MOBILE SMART MESSAGE..........................................................................16 7.7 AUB – SISTEMA DE AUTOMAÇÃO BANCÁRIA – ATENDIMENTO, GERÊNCIA E RETAGUARDA............................................................................................................16 7.8 AAT - AUTOATENDIMENTO....................................................................................16 7.9 REX – REDES EXTERNAS......................................................................................17 7.10 REC – REDES CONVENIADAS..............................................................................17 7.11 SAT – SISTEMA DE AGENDAMENTO DE TRANSAÇÕES.............................................17 7.12 FLT – FLUXO DE TEDs.........................................................................................18 7.13 MMC – MONITOR DO MULTICANAL.......................................................................18 7.14 CON – CONCILIAÇÂO.........................................................................................19 7.15 SIA – SISTEMAS DE INFRAESTRUTURA DA AUTOMAÇÃO BANCÁRIA.........................19 7.16 BASE DE DADOS................................................................................................19 7.17 PROCESSADOR DE DÉBITOS E CRÉDITOS.............................................................19

8 ADAPTAÇÃO DA SOLUÇÃO AO NEGÓCIO BRB.................................................................22 8.1 Obrigações da CONTRATADA.................................................................................22

...........................................................................................................................22 8.2 TREINAMENTOS...................................................................................................23

9 REMUNERAÇÃO .........................................................................................................23 9.1 PERCENTUAL DE REMUNERAÇÃO PARA PROJETOS COM PONTOS DE FUNÇÃO..............24


10 PADRÕES DE SEGURANÇA.........................................................................................25 11 CONECTIVIDADE......................................................................................................26 12 ANEXOS..................................................................................................................27

12.1 Anexo 1 – Relação de Funcionalidades..................................................................27 12.2 Anexo 2 – Sistemas e Serviços Descontinuados:....................................................28 12.3 Anexo 3 – Arquivos do Método de Acesso.............................................................29 12.4 Anexo 4 – Relação das funcionalidades previstas para o Mobile Banking...................31 12.5 Anexo 5 – Relação das funcionalidades previstas para o GPW..................................31

13 GLOSSÁRIO.............................................................................................................32


PROJETO BÁSICO SUSIS/GENEG 2011/003 Brasília, 13 de julho de 2011

Assunto : PROJETO BÁSICO MULTICANAL

Este projeto tem por objetivo principal subsidiar a avaliação da atual estrutura da automação bancária, destacando suas fragilidades, além de propor a adoção de uma nova solução, mais robusta e com novas tecnologias, de forma a alinhar os Sistemas que a compõem à visão de negócio com maior agilidade e menor custo, visando atender os preceitos da missão do Banco de “Oferecer atendimento com excelência e soluções financeiras inovadoras, contribuindo para o desenvolvimento socioeconômico do DF e regiões de influência”, permitindo atingir sua visão que é “Ser reconhecida como a melhor instituição financeira do DF e regiões de influência”, com respeito aos valores de foco no cliente, responsabilidade social, comprometimento, ética, solidez, valorização dos colaboradores e empreendedorismo.

1 OBJETO

O objeto do Edital será a aquisição de Sistema Multicanal para tratamento de transações financeiras, abrangendo desde o CEN – centralizador e autorizador até os canais de Internet Banking (Portal de Serviços Bancários) e Telebanco, Caixa (agência e correspondente), Atendimento/retaguarda, Mobile Banking, Mobile Payment e Mobile Smart Message além de outros serviços que serão descritos neste projeto básico.

1.1 AQUISIÇÃO DA SOLUÇÃO DE MULTICANAL

Consiste na aquisição de solução Multicanal com cessão de uso permanente, sendo item integrante da aquisição a Transferência de Tecnologia de Produção e Desenvolvimento, com entrega dos programas fontes, bibliotecas, documentos e outras atividades descritas neste Projeto Básico.

1.2 TRANSFERÊNCIA DE TECNOLOGIA DA SOLUÇÃO ADQUIRIDA E ADAPTADA AO NEGÓCIO BRB

Consiste no fornecimento de todos os subsídios para que as equipes técnicas da Área de Tecnologia do BRB obtenham os conhecimentos necessários ao perfeito entendimento da solução de Multicanal – arquitetura, dados, objetos, funções e construção da solução, estando capacitados ao final do contrato a Manter e Produzir o descrito.

1.3 SERVIÇOS OPERACIONAIS DE PRODUÇÃO E DE SUPORTE DA SOLUÇÃO DE MULTICANAL NO AMBIENTE BRB

Consiste na produção da solução de Multicanal adaptada ao Negócio BRB em ambiente interno do BRB na cidade de Brasília, DF, e será feita pela equipe de produção da CONTRATADA, de acordo com o definido no quadro abaixo, que deverão manter a solução em operação permanente 24h X 7 dias/semana X 365 dias/ano durante o período de vigência do contrato, incluindo dias úteis, fins de semana e feriados, mantendo a solução operacional conforme Acordo de Nível de Serviço a ser firmado.

Serão delimitados a seguir alguns parâmetros que irão compor o Acordo de Nível de Serviço – ANS (do inglês, SLA). Esses indicadores contar-se-ão a partir do momento do acionamento por parte do banco.

Tabela de Impacto x Tempo de SoluçãoImpacto Tempo de Solução Descrição1 1 hora consecutiva Serviço indisponível


2 2 horas consecutivas Serviço impactado, funcionando com graves restrições

3 6 horas úteis Serviço impactado, funcionando com pequenas restrições

4 20 horas úteis Outros tipos de incidentes/requisições, mudanças padrão e dúvidas

5 30 dias consecutivos Requisições de mudanças (RDM)

O enquadramento da gravidade do impacto é prerrogativa exclusiva e incontestável do Banco.

A CONTRATADA deverá prestar o suporte técnico da solução por telefone e e-mail, durante a vigência do contrato em horário comercial. Se ficar constatada a necessidade por parte do CONTRATANTE, o suporte técnico poderá ser requisitado para fora do horário de expediente bancário, inclusive nos finais de semana e feriados, em regime de sobreaviso, sem custos adicionais ao contratado.

2 FASES DA EXECUÇÃO DO CONTRATO

2.1 PRIMEIRA FASE

Prazo limite de até 6 meses contados da data de assinatura do contrato para a entrega dos seguintes serviços, módulos e canais:

• CEN – Centralizador (M)• GAB – Módulo geral de gerenciamento do multicanal (M)• MMC – Monitor do multicanal (M)• IBK – Internet Banking e Telebanco (C)• MBK – Mobile Banking ©• SIA – Sistema de infraestrutura da automação bancária

2.2 SEGUNDA FASE Prazo limite de até 12 meses contados da data de assinatura do contrato para a entrega dos seguintes serviços, módulos e canais:

• CIX – Caixa Agência e Correspondente (C)• AUB – Sistema de automação bancária (C)• AAT – Autoatendimento (S)• REX – Redes Externas (S)• REC – Redes Conveniadas (S)• CON – Conciliação (M)

2.3 TERCEIRA FASE Prazo limite de até 18 meses contados da data de assinatura do contrato para a entrega dos seguintes serviços, módulos e canais:

• SAT – Sistema de Agendamento de transações (M)• FLX – Fluxo de TEDs (M)

2.4 QUARTA FASE Prazo limite de até 24 meses contados da data de assinatura do contrato para a entrega dos seguintes serviços, módulos e canais:

• MPY – Mobile Payment (C)• MSM – Mobile Smart Message (C)

Obs: Para que cada módulo/canal seja considerado entregue todos os requisitos gerais e específicos que se enquadram para o referido módulo devem ter sido atendidos além do


desenvolvimento das funcionalidades previstas para aquele módulo/canal conforme anexo 1.

(M) – Módulo com o cadastramento das funcionalidades descritas neste documento.(C) – Canal (S) – Somente o cadastramento das funcionalidades no CEN.

O BRB não exige que a solução Multicanal da empresa possua módulos específicos para o atendimento das necessidades descritas neste projeto básico.

3 PANORAMA DA AUTOMAÇÃO BANCÁRIA E CANAIS DE ATENDIMENTO

A atual estrutura da automação bancária, de forma simplificada, é composta dos seguintes itens: 3.1 CANAIS DE ATENDIMENTO

São sistemas transacionais, de interfaceamento com clientes, sejam eles internos ou externos. Possuem característica principal de prover serviços que, posteriormente, se integrarão com os sistemas de grande porte (legado). Os atuais canais de atendimento da automação bancária são:

BRB BANKNET

Sistema de Internet Banking desenvolvido no início do ano de 2003, que permite a realização de transações de transferência eletrônica para contas do BRB, TEDs, DOCs, agendamentos e pagamentos de títulos, agendamentos e pagamentos de arrecadações públicas e de concessionárias, manutenção de contratos de débito automático, consulta de extratos e recibos, aplicações financeiras, empréstimos, cadastramento e utilização dos serviços do DDA, entre outros, que serão melhor detalhados no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES.Este canal foi desenvolvido na linguagem Java, utilizando-se do framework proprietário iWorkPlace, fornecido pela empresa Infonet. Possui também um Módulo Administrativo que permite o gerenciamento e controle do Banknet e Aplicativo CRBRB, por meio de auditorias, controle de usuários, parametrização de transações, dentre outros.

APLICATIVO CRBRB

Aplicativo desenvolvido em Delphi em 2003, que é responsável por trocar bilhetes entre a estrutura tecnológica da Call Center do BRB com o Mainframe, utilizando os recursos da Unidade de Resposta Audível – URA e o Gateway EAP e que, com base no bilhete enviado, recebido e confirmado, proverá a abertura de funcionalidades no web-browser a ele acoplado. Tais funcionalidades são uma adaptação do Internet Banking para viabilizar o funcionamento do BRB Telebanco, preservando portanto quase todos os recursos do BRB Banknet, além de compartilhar sua base de informações.

ABA-VÍDEO

Sistema desenvolvido em Delphi na década de 90, utilizado por empregados do Banco, estagiários e prestadores de serviço autorizados, destinado a operações dos setores de atendimento e retaguarda, que possui recursos para investimentos, lançamentos financeiros extra-caixa, transferências eletrônicas, manutenção de cadastro de contas autorizadas para emissão de TED/Doc, Ordens Bancárias, relatórios diversos, manutenção de cadastro do DDA, dentre outras informadas no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES.

ATB-CAIXA

É um canal de atendimento desenvolvido na década de 2000, utilizando Delphi, que tem por finalidade permitir aos caixas das agências efetuarem transações financeiras quando


demandados por algum cliente. Destacam-se as transações de saque, depósito, saldo, Doc e TED, sendo as demais detalhadas no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES. Possui um diferencial quando tratamos do conceito de Supertransação, que permite a um operador iniciar vários recebimentos de documentos diversos, gerando ao final um único recebimento de valores, seja ele através de dinheiro, liquidação de cheque ou débito autorizado, de forma a poupar substancialmente o tempo do cliente e também do operador.

ATC-CORRESPONDENTE

Similar e originário do ATB - Caixa, que evoluiu com distinção de algumas regras, de forma a atender às especificidades do seu público alvo, que são os usuários dos Correspondentes não-bancários.

AUTO ATENDIMENTO

Canal de atendimento eletrônico redesenvolvido em 2009, que atualmente está sob o Contrato de outsourcing celebrado pelo BRB com a empresa Perto, tanto de sistema quanto de hardware e que permite ao cliente efetuar várias operações de consulta, como extratos, saldos, recibos e também transações financeiras, como saque, transferência, agendamentos, e pagamentos diversos, além de serviços ofertados pelo BRB em conjunto com seus parceiros CEB, Caesb, TJDFT, Cartão BRB e Sefaz. Detalhes sobre as transações estão disponíveis no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES. Possui também rotina de conciliação. As regras de negócio estão atualmente no sistema ABX, de controle do BRB.

REDES EXTERNAS

São canais eletrônicos de atendimento, onde transitam transações das bandeiras Visa e Mastercard/Maestro, além de transações em redes compartilhadas, como Banco 24h, RVA e Banco do Brasil. A execução dos serviços disponibilizados nessas redes é assegurada por um sistema centralizador desenvolvido na linguagem Java, denominado HRX. Possui também rotina de conciliação.

3.2 AUTORIZADOR DE TRANSAÇÕES

Atualmente composto por um único sistema, denominado ABX, desenvolvido na década de 2000, com o propósito de ser um proxy entre os demais sistemas, além de conter, inicialmente, as regras negociais para o canal autoatendimento. Com o passar do tempo, evoluiu-se o conceito inicial, expandindo o gerenciamento das regras de forma a permitir que outros canais utilizem-se de sua estrutura.

3.3 SISTEMAS DE INFRAESTRUTURA

Suite de aplicativos criados em momentos diferentes, entre a década de 80 e a de 2000, com finalidades diversas, tecnologias e arquiteturas diferentes e que, em alguns casos, conflitam nos serviços ofertados. São aplicativos responsáveis por carregar em uma base de arquivos indexados com os dados das contas, produtos, tabelas de parâmetros e clientes do banco, além de manipular tais informações sob demanda dos canais ou sistemas com os quais a automação bancária se integra. As informações armazenadas por estes aplicativos são persistidas através do conceito de Método de Acesso a Arquivos, tecnologia em estágio avançado de obsolescência, pois foi implantada no BRB no final da década de 80. 4 PROBLEMAS ATUALMENTE ENFRENTADOS

4.1 OBSOLESCÊNCIA TECNOLÓGICA

Os sistemas da automação bancária passam por vários estágios de obsolescência, desde sua linguagem, passando por sua arquitetura, até sua infraestrutura.


A defasagem tecnológica prejudica a integração desses sistemas com novas ferramentas, além de por vezes inviabilizar o desenvolvimento de novos serviços ou produtos, devido à incompatibilidade com novos recursos tecnológicos. A principal consequência dessa defasagem é o elevado tempo requerido para o desenvolvimento de novas demandas e para a realização de manutenções nas demandas já implantadas.

4.2 DESENVOLVIMENTO DE DEMANDAS

O desenvolvimento de demandas é prejudicado pela defasagem tecnológica, à medida que a grande diversidade de arquiteturas, linguagens e padrões adotados exige que os recursos humanos sejam especialistas naquele assunto, dificultando a mineração de novos profissionais para atuar nessas demandas, sem a necessidade de prévio treinamento. Esse treinamento, haja vista a falta de documentação que será abordada posteriormente, exige disponibilidade de outros recursos humanos que detém o conhecimento de forma tácita, tanto técnico quanto negocialmente, prejudicando o andamento dos trabalhos.

4.3 DESCENTRALIZAÇÃO DE REGRASAtualmente cada canal de atendimento possui suas regras de negócio, que por vezes são desnecessariamente replicadas, em alguns casos conflitantes, dificultando a rastreabilidade do processo, prejudicando substancialmente o gerenciamento, compatibilização e alteração dessas regras em tempo hábil, de forma a atender a necessidade do negócio.

Com a descentralização, tornam-se necessários mais recursos especialistas para o atendimento de uma mesma demanda, além de acréscimo no tempo e, por consequência, no custo. Ademais, o gerenciamento do atendimento dessas alterações em cada canal tem sua complexidade aumentada, dadas as diferentes prioridades e peculiaridades desses canais. Na atual conjuntura o quadro de recursos humanos, tanto do Núcleo quanto da Coordenação são insuficientes para darem vazão às demandas prioritárias que fazem parte do atual e crescente backlog da automação bancária.

4.4 ESCASSEZ DE DOCUMENTAÇÃO

A escassez ou quase nula documentação torna os processos não gerenciáveis por parte dos gestores negociais e prejudica as manutenções, os rastreamentos das regras vigentes e dos pontos correlatos a cada uma delas, haja vista a necessidade de um trabalho de engenharia reversa para cada manutenção, o que pode gerar incorreta ou incompleta interpretação das regras, aumentando o risco de impactos quando de sua publicação em ambiente de produção, gerando retrabalho, prejuízos financeiros mensuráveis e de imagem para a Instituição. 5 SOLUÇÃO PROPOSTA

A solução proposta tem por objetivo resolver os principais problemas enfrentados e justificados neste documento, atendendo as premissas descritas a seguir, sendo uma solução que não tenha custo atrelado ao quantitativo de transações, devendo ser contratada sob modalidade de licença de uso perpétua, com entrega dos fontes ao Banco, através da completa transferência de tecnologia, podendo este a qualquer tempo proceder as alterações que lhe forem convenientes, sem necessidade de prévia autorização, podendo inclusive ser feita por outra equipe diversa da CONTRATADA, sem que isto caracterize descumprimento contratual.

5.1 CEN - CENTRALIZADOR e AUTORIZADOR

Criar um ponto único para processamento transacional, o qual chamaremos de CEN - Centralizador, que também deverá permitir cadastramento das regras de negócio a serem utilizadas pelos canais, que permita reutilização e padronização de processos de negócio, agilizando atendimento das demandas e permitindo ao gestor participar interativamente do processo, desde a fase de concepção até a fase de implantação, permitindo também que ele


faça alterações nos processos já existentes, sem a necessidade de intervenção técnica. Visa também manter a consistência das regras negociais em todos os canais, evitando que cada canal tenha um comportamento diferenciado para o mesmo processo. Para atendimento desta necessidade, propõe-se a utilização de BPM.

Exemplo de reutilização de processos:

Processo A: SaqueSubprocesso: Validar cartãoSubprocesso: Autenticar senhaSubprocesso: Debitar Conta

Processo B: ExtratoSubprocesso: Validar cartão (subprocesso reutilizado)Subprocesso: Autenticar senha (subprocesso reutilizado)Subprocesso: Emitir Extrato

5.2 ATUALIZAÇÃO TECNOLÓGICA

Prover arquitetura padronizada, utilizando-se de conceitos mais modernos, como orientação a serviço (SOA), amparada por frameworks de mercado, linguagem mais moderna, recursos que permitam escalabilidade, maior interoperabilidade e portabilidade com menor esforço possível.

5.3 GAB – MÓDULO GERAL DE GERENCIAMENTO DA AUTOMAÇÃO BANCÁRIA

Será um conjunto de aplicações que conterão todas as tarefas de parametrização e auditoria da solução proposta, tanto a nível macro quanto aos parâmetros individualizados por canal. Deverá também possuir a base de perfis por sistema/canal e seus respectivos usuários autorizados.

5.4 CANAIS DE ATENDIMENTO

Deverão atuar como interface entre cliente/usuário e os demais sistemas do Banco. Cada canal deverá, no momento do acionamento de uma transação ou de um processo, buscar as regras no CEN para montagem da tela, tais como campos e seus tipos, validações de preenchimento em tela, informações a serem apresentadas, leiaute (estilo a ser utilizado, disposição dos itens na tela, etc). Ao submeter a transação, deverá ser feita a comunicação com o CEN, que validará as informações com base no cadastramento previamente realizado e autorizará ou não a efetivação da operação.

Os canais deverão, também, permitir gerenciamento de conteúdo de forma interativa, utilizando-se, para tanto, do recurso gerenciador de conteúdo.

5.5 DOCUMENTAÇÃO

Deverá ser armazenada através de um software GED, integrado ao processo de desenvolvimento, permitindo armazenamento de documentação originária dos códigos fontes e geradas através de mecanismos automatizados disponíveis nas ferramentas a serem utilizadas, além de documentos adicionais que não são gerados de forma automatizada. Deverá também possuir integração com o BPM, gerando também a documentação negocial.

Deverão ser utilizados artefatos previstos na linguagem UML, em sua versão mais recente. Espera-se o fornecimento de, no mínimo, os seguintes artefatos, quando aplicáveis: Documento de Visão, Diagrama de Caso de Uso, Especificação de Caso de Uso, Diagrama de Sequência, Diagrama de Atividade, Diagrama de Estado, Diagrama de Colaboração e Roteiro de Homologação. Adicionalmente podem ser solicitados quaisquer artefatos previstos na Metodologia de Manutenção e Desenvolvimento de Software adotada pelo Banco, estando quaisquer documentos sujeitos à aprovação do BRB.


6 DESCONTINUIDADE DE SISTEMAS

Com a nova solução haverá a descontinuidade de diversos sistemas e serviços, que serão detalhados no Anexo 2 – Sistemas e Serviços Descontinuados.

7 ESPECIFICAÇÃO TÉCNICA

Objetiva prover informações detalhadas sobre as especificações técnicas gerais e suas peculiaridades para cada componente da solução.

7.1 Requisitos Gerais:

Não haver tarifação atrelada ao número de transações.Os aplicativos devem ser desenvolvidos totalmente em linguagem Java 6 ou superior.Utilizar arquitetura multicamada orientada a serviço (SOA).Todos os canais que fazem parte da solução de multicanal e o centralizador devem possuir formas distintas de acesso, seja por login de rede, seja por usuário e senha, ou de outras formas a serem detalhadas nos canais além de possuir opções gerais de administração dos canais e customização do CEN. Essa solução poderá ser apresentada através de Portal.Permitir desenvolvimento, teste, homologação e implantação em produção, de forma individual dos processos de negócio. Os aplicativos devem permitir a segregação dos ambientes, a critério do BRB, sendo possíveis os ambientes de Produção, Homologação, Desenvolvimento e Simulação.Permitir que o usuário parametrize os processos de negócio no CEN através do BPM, permitindo também a implantação de manutenções nos processos de negócio nos ambientes citados no item 4, a qualquer tempo, sem a interrupção do serviço.Permitir que os aplicativos sejam instalados em qualquer equipamento servidor, independente do número de processadores, sem variação de custo.Os códigos-fonte devem ser mantidos no ambiente do Banco, utilizando-se do repositório Subversion, fornecido pelo Banco.De acordo com as características do canal requisitante, o CEN devolverá a resposta (relatório, mensagem, recibos, etc) indicando através de metadados como o canal deverá se comportar.Cabe à CONTRATADA executar os projetos visuais e de navegabilidade especificados neste projeto básico, de acordo com a linha de estética e marketing definida pelo Banco.Todas consultas devem suportar critérios de filtragem e ordenação pelos campos exibidos, tanto na requisição inicial quanto na filtragem e na ordenação em tela. Deve também possuir recurso para impressão, exportação em formatos PDF, TXT, OFC, OFX e gráficos, quando possível.A solução deverá suportar 3.000 (três mil) requisições por segundo.O tempo de resposta às requisições feitas não deve ultrapassar 1 segundo, considerando o tempo gasto internamente para o processamento na nova solução, seja ela canal, CEN ou banco de dados. Suportar os padrões Febraban CNAB 240 e ISO8583.O CEN deverá possuir mecanismos que permitam dotar os canais de informações para que em tempo de execução, possam exibir informações adicionais pré-cadastradas para cada metadado, que auxiliem o usuário no preenchimento e interpretação de cada campo, utilizando-se para tanto textos explicativos em formato a ser definido pelo Banco.Em qualquer canal o campo que estiver com o foco, bem como os campos obrigatórios deverão possuir estilo diferenciado, a ser carregado na inicialização da transação, com base em consulta ao CEN.


Os canais deverão carregar as máscaras dos campos e aplicá-las, de acordo com o metadado cadastrado no CEN.Quando possível, utilizar-se de hints e metáforas.Atender ao requisito de portabilidade, sendo compatível com os sistemas operacionais Windows 2003, 2008 ou superior e Linux.Permitir alteração, no menor esforço e quando possível de forma interativa, da disposição dos itens em tela (menus, botões, campos, etc).Permitir a publicação de campanhas de forma individualizada por canal e em múltiplos canais simultaneamente, utilizando se possível recurso de gerenciamento de conteúdo. Permitir também que as campanhas sejam direcionadas por perfis de clientes.Quando for aplicação de interface web, esta deverá ser compatível com os browsers Internet Explorer 6, Firefox 3, Safari 4, Opera 10 e Chrome 5, além de suas versões posteriores.Utilizar padrões Java Blueprint e Javasoft, devemdo ser utilizada ferramenta automatizada para validação quanto aos requisitos do Javasoft.Manter documentação de código através de Javadoc.Utilizar prototipação, quando possível.Possuir ferramenta free, integrada ou não à solução, que permita o gerenciamento de bugs.Fazer utilização de Portlet Container open-source que atenda aos padrões JSR 286 e especificação WSRP 2.0.Quanto a aplicação web, deverá ser implementado utilizando a framework Struts 2 ou JSF, que propiciará diversas vantagens, com destaque para o fato de ser um framework baseado em ações, opção de utilizar configuração via XML e anotações (tecnologia annotations), ações baseadas em POJO, que permitem maior facilidade ao testar, integração com Spring, SiteMesh e Tiles, bibliotecas baseadas em temas e tags em AJAX, possibilidade de criar taglibs próprias, atende ao modelo MVC/MVC-2, que separa claramente camada de visão das demais camadas. Utilizar o framework de persistência Hibernate, que permite o mapeamento objeto-relacional, através de configurações em XML e/ou Annotations, permitindo a persistência dos objetos em banco de dados, de forma transparente para a aplicação, bastando apenas as configurações específicas e os drivers para cada banco, atendendo, por exemplo, o banco Oracle (na versão 10g, que é utilizado no BRB), banco IBM-DB2, entre outros. A independência entre aplicação e banco de dados é vantajosa, por exemplo, caso a Instituição opte pela troca do fornecedor do SGBD, auxiliando também em caso de atualização da versão do banco de dados, cujo upgrade será menos traumático. O Hibernate é o arcabouço de persistência melhor conceituado no mercado, de uso livre e que implementa JPA, com diversos profissionais capacitados, além de ampla documentação.Utilizar Jboss Seam.Permitir a integração com pelo menos três frameworks de mercado para utilização de Ajax, sendo ao menos duas sob licença free.Disponibilizar recursos para web-chat, podendo ser ativado em qualquer canal a qualquer tempo, conforme necessidade do Banco.Possuir um único ponto central de comunicação, que suporte protocolo TCP/IP, com os padrões ABX (proprietário do BRB) e JSON (mantido pelo JSON.org) e mensagens posicionais para comunicação com alta plataforma. Para essas mensagens posicionais deve-se possuir uma base com metadados, de forma a permitir a criação e/ou alteração do conjunto de mensagens a ser utilizado. Permitir tráfego de mensagens nos padrões já descritos, XML e arquivos texto, utilizando comunicação por web-service. Esse ponto unificado deverá também suprir funções de gateway que permita o tráfego de mensagens entre diversos sistemas, de forma parametrizável, inclusive em ambiente DMZ, além de validar se a mensagem trafegada atende ao padrão definido no protocolo por ela utilizada, sendo possível também a monitoração do tráfego em tempo real e também com séries históricas, que deverão ser acessadas e mantidas através do MMC, sistema de monitoração que será tratado adiante.


O CEN deverá ser capaz de tratar um processo utilizado por mais de um canal, de forma a atender as especificidades de cada canal, não devendo replicar processos e sim tratar as exceções como parte do fluxo.Ser compatível com arquitetura de barramento 32 e 64 bits.Toda a solução de canais deverá possuir contingenciamento, que funcione também em cluster, com recursos de balanceamento de carga, permitindo o controle da carga de cada servidor que faça parte do nó e também a migração das instâncias de um servidor ao outro, quando um destes for desabilitado. Deverá ser possível disponibilizar o CEN em várias instâncias de um mesmo servidor ou em servidores diferentes.Garantir a integridade e consistência das transações executadas, efetuando automaticamente o estorno/rollback da transação com falha.Deverá possuir recurso de espelhamento de base.Possuir base centralizada de recibos de transações.Prover a migração dos recibos atualmente existentes em bases de dados diferenciadas para a nova base centralizada.Possuir controle de duplicidade no dia para pagamentos e recebimento de cheques.Possuir controle de transações, perfis e limites por canal, perfil e PA.Possuir controle de valores acumulados por conta, perfil, canal, transação e usuário, permitindo limites diferenciados inclusive com base em horários.Controlar a execução das transações por horário, que deve ser diferenciado por canal e ou PA.Todas as transações deverão estar preparadas para execução em lote, de forma que o gestor defina a habilitação ou não das transações em lote com base na transação, canal e perfil de usuário, podendo ser processos diferentes.Permitir transações com um débito para vários créditos e um crédito para vários débitos, de forma parametrizável no processo.Todos os canais e o CEN deverão gravar todos eventos de acionamento de transações, tempo de resposta, mensagem de erro ou sucesso, armazenamento da tela da transação, mensagens saintes e entrantes, conclusão da transação, informação sobre transação abortada pelo usuário, abortada pelo sistema por falha genérica ou regra de negócio. Todos os parâmetros da auditoria serão definidos pelo Banco.A auditoria deverá ser uma transação do CEN que será disponibilizada nos canais definidos pelo banco e para os perfis também definidos.A nova solução deverá permitir tratamento de diferentes fuso-horários.Permitir a utilização de e-commerce.Permitir transações de pagamento online originários de e-commerce de empresas parceiras, com vistas a prover pagamento de compras on-line feitas pelo cliente, com débito em conta ou ainda contratando uma linha de empréstimo pré-aprovado a ser definida pelo Banco.Permitir a autenticação através de certificados digitais emitidos pela ICP-Brasil.

7.2 CAIXA AGÊNCIA E CORRESPONDENTES

Deverá funcionar em ambiente web.Deverá possuir interface com padrão definido pelo Banco, que permita acesso a quaisquer das funcionalidades em, no máximo, três teclas ou cliques.Permitir acesso a qualquer serviço ou transação através do teclado numérico, usando de atalhos simplificados, parametrizáveis pelo gestor.


Disponibilizar as transações mais utilizadas com acesso em uma tecla, através de atalhos com teclas especiais (F7, F8, etc), parametrizáveis, podendo ser feito inclusive com junção de teclas, a critério do gestor. Deverá também possuir menu com todas as funcionalidades, em formato a ser definido pelo Banco.A comunicação com os periféricos do caixa deve seguir o padrão de API específica dos equipamentos utilizados pelo BRB, podendo inclusive coexistir mais de um padrão para um mesmo periférico.Implementar todas as funcionalidades especificadas para os canais Caixa e Correspondente no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES deste documento.Implementar Bobina Eletrônica com recursos de: navegação, localização de transações, zoom, impressão, uso do mouse, duplo clique para consulta ou estorno da transação, uso de paginação. Permitir exportação automatizada da bobina para formato TXT, de forma a ser carregada por outros sistemas. A bobina bem como os recursos de localização deverão ser providos pelo CEN, devendo estar no canal apenas os recursos de impressão, zoom, exportação e outros de interação direta com o usuário.Possuir calculadora com, no mínimo, as operações de soma, subtração, multiplicação, divisão, percentual, memória (limpar, somar, subtrair, recuperar), zerar calculadora, copiar e colar, com registro das operações na bobina eletrônica.Permitir, no momento de um recebimento qualquer, quando a forma de pagamento for dinheiro e/ou cheque, informar separadamente cada quantidade de cada cédula ou cheque e valor em moedas, devendo tal recebimento ser contabilizado e registrado na bobina eletrônica, tal qual um cálculo feito pela calculadora, sendo porém uma informação cuja obrigatoriedade seja manipulável por parâmetro pelo gestor. Deve, também, armazenar essas informações junto à transação, permitindo consulta a qualquer tempo.Implementar log de falha de acesso aos periféricos, devendo estar disponível para consultas através do aplicativo de monitoração.Criar um módulo Supervisor Remoto de Transações, que permita a autorização de transações pendentes, seu bloqueio e desbloqueio, de forma remota.Todas as ações devem ser gravadas para auditoria.

7.3 IBK – INTERNET BANKING (PESSOA FÍSICA E JURÍDICA) E TELEBANCO

Deverá possuir cadastramento por CPF, de forma a permitir a operação de múltiplas contas.O login deverá ser iniciado através da página inicial do BRB, que passará o CPF por parâmetro para o canal, que deverá exibir as iniciais do nome do cliente na tela, juntamente ao Teclado Virtual do BRB, onde será informada a senha para o prosseguimento do login.As transações deverão ser autorizadas mediante uso do dispositivo de segurança utilizado pelo Banco denominado Token, quando assim estiver definido no processo de negócio.Deverá permitir a customização da página inicial pelo usuário.Deverão ser exibidas apenas as funcionalidades à qual aquele usuário tem permissão de acesso, tomando como base o perfil da conta e do tipo de usuário.Após o login o usuário deverá visualizar os saldos de suas contas e os lançamentos futuros em formato de abas. Deverá existir uma opção para que o usuário selecione a conta que deseja operar e, só então, os menus devem ser carregados. O usuário poderá a qualquer tempo alterar a conta a ser operada, sem a necessidade de efetuar login novamente.Além do tipo de usuário titular, deverá existir outro que chamaremos de sub-usuário, que é um terceiro não titular da conta, cujas permissões de acesso são definidas pelo titular, sendo permitidas no máximo as mesmas opções do titular.Quando uma transação for feita por um sub-usuário, o CEN deverá gravar a transação como pendente.


Quando uma conta for não-solidária as transações só poderão ser concluídas após a anuência de um número mínimo de titulares com a permissão para a confirmação (sócios gerente, por exemplo), sendo estes titulares definidos no cadastramento da conta no IBK, não podendo ser em número inferior a 2.As transações pendentes não poderão ser autorizadas por sub-usuário, devendo ser autorizadas por usuário diferente do que a incluiu, até o horário limite para aquela transação no mesmo dia. Se não autorizadas em tempo hábil, estas serão descartadas, mas deverão ser disponibilizadas para consulta, com status que indique sua não-realização por falta da autorização.Ao acessar a conta, caso existam transações pendentes de aprovação, deverá ser sinalizado para o cliente.Deverá existir um indicador por vinculação cliente/conta que indique se aquela ordem poderá executar transações financeiras.A disposição dos itens em tela (menus, banners, etc) devem ter fácil alteração, sem necessidade de intervenção técnica.Permitir a criação de enquetes personalizadas por tipo de cliente ou geral, com data de início e fim.

Toda e qualquer tarefa administrativa a ser realizada para funcionamento desse canal deverá ser feita dentro do Portal.Deverá existir um módulo de comunicação através de mensagens, que permita ao Banco o envio de mala-direta geral, por perfil ou ainda o envio de mensagens individualizadas, sejam elas originadas pelo gerente da agência, pelo gestor do canal ou ainda pela área de marketing. Permitir também que o cliente inicie a comunicação, enviando a mensagem para avaliação da Central de Relacionamento, que dará o atendimento inicial, podendo encerrá-la ou encaminhá-la para outras áreas, que visualizarão e poderão dar prosseguimento a sendo para tanto necessária a criação de um workflow.Possibilitar integração com a ferramenta de web-chat da DirectTalk.Possibilitar integração com diversos simuladores (empréstimos, seguros, etc).Possibilitar integração ao sistema de Ouvidoria e SAC, permitindo ao próprio cliente a geração de ocorrências.Permitir a veiculação de avisos para diferentes perfis e também avisos gerais.Deverá gravar todos os passos feitos pelo usuário como forma de auditoria, permitindo a busca dos detalhes da interação de cada evento entre o usuário e o sistema.Permitir o encadeamento de processos. Ex.: Insuficiência de saldos durante uma transação deve-se permitir, a critério do gestor, que haja encadeamento com determinada transação de empréstimo, de forma parametrizável.O Módulo Administrativo deverá possuir as funcionalidades de cadastramento de usuários do próprio Módulo, cadastramento de contas/ordens autorizadas a movimentar, cadastramento de usuários do Telebanco (Aplicativo CRBRB), cadastramento de telefones autorizados, Token, SMS e contas pré-autorizadas para envio de TED/Doc. Possuirá também transações para consultas diversas como extratos, e saldos e recibos, inclusive gerados nos diversos canais, auditoria, busca de contas com filtros diversos, relatórios gerenciais, entre outros previstos para o canal Módulo Administrativo do Banknet no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES.


O Aplicativo CR será responsável por fazer a interface entre a chamada telefônica repassada pela URA/EAP e o operador, permitindo a este que faça transações financeiras ou não para aquele cliente já autenticado. Esse aplicativo já existe atualmente e é desenvolvido em Delphi e basicamente fará a escuta de determinada porta de comunicação à espera de um bilhete vindo do EAP. Após o recebimento desse bilhete o Aplicativo oferecerá ao operador a possibilidade de acatá-lo ou não. Se acatado, tal Aplicativo fará uma chamada ao Internet Banking, que possuirá interface e código de canal diferenciados quando a origem for o Aplicativo CR, já quando ocorrer a finalização da ligação na URA, a requisição do EAP deverá ser aceita e automaticamente realizará a desconexão do aplicativo do operador. Possuirá também transações com fluxos diferentes, tratáveis em nível de CEN, além de formas diferenciadas de autenticação e autorização de transações. Deve possibilitar a integração junto ao Sistema de Atendimento Virtual – SAV da Central de Relacionamento, a fim de que o operador possa efetuar registro de solicitações do cliente autenticado.Deverá permitir a leitura de código de barras por meio de leitoras CMC7.Todas as ações devem ser gravadas para auditoria.Implementar todas as funcionalidades especificadas para os canais Banknet, Telebanco e Módulo Administrativo do Banknet no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES deste documento e GPW no Anexo 5 – Relação de Funcionalidades do GPW.

7.4 MBK – MOBILE BANKING

Interface gráfica intuitiva e amigável. Solução que não tenha dependência da operadora ou que passe pela mesma de forma transparente para o BRB.Deverá permitir o login através de CPF e a mesma senha do Internet Banking. Suportar autenticação através do cadastro do aparelho e/ou número do celular origem.

Todas as informações devem trafegar de forma segura, com padrão de criptografia a ser definido pelo Banco. Todas as transações, à exceção das consultas, deverão ser confirmadas com utilização da senha do cartão bancário. Deverá possuir ampla cobertura aos diversos aparelhos comercializados no mercado nacional. Deverá funcionar pelo menos nos sistemas iPhone, Windows Mobile, Symbian, BlackBerry, Palm OS, Pocket e Android, em suas versões mais recentes, mantendo compatibilidade com suas versões anteriores, exceto se o suporte e atualização tenham sido descontinuados pelo mantenedor do sistema operacional. Deverá suportar também as plataformas Brew, J2ME e Wap (1.0 e 2.0).Deverá dar suporte a dispositivos GSM e CDMA.Prover acesso via browser do aparelho (wap), sem a necessidade de instalação de software.Implantar todas as funcionalidades especificadas no Anexo 4. Relação de Funcionalidades do Mobile Banking.Todas as ações devem ser gravadas para auditoria.

7.5 MPY – MOBILE PAYMENT

Interface gráfica intuitiva e amigável.Solução que não tenha dependência da operadora ou que passe pela mesma de forma transparente para o BRB.Permitir efetuar operações financeiras de pagamento através do dispositivo móvel, dispensando o uso de cartões.Permitir transações remotas ou por proximidade (tecnologia NFC – Near Field Communication).


Suportar autenticação através do cadastro do aparelho e/ou número do celular de origem.Todas as informações devem trafegar de forma segura, com padrão de criptografia a ser definido pelo Banco.Permitir a customização de transações permitidas, bloqueadas e valores máximo, tanto de forma global, por perfil, quanto por cliente.Deverá funcionar pelo menos nos sistemas IOS (iPhone, iPad, iPod e iPod Touch), Windows Mobile (Pocket), Symbian, BlackBerry, Safari, Palm OS e Android, em suas versões mais recentes, mantendo compatibilidade com suas versões anteriores, exceto se o suporte e atualização tenham sido descontinuados pelo mantenedor do sistema operacional. Deverá suportar também as plataformas Brew, J2ME e Wap (1.0 e 2.0), e versões superiores.Deverá dar suporte a dispositivos GSM, CDMA e GPRS.Prover acesso via browser do aparelho (wap), sem a necessidade de instalação de software.Deverá suportar transações a débito em conta (on-line) ou a crédito para lançamento em fatura de cartão.O aplicativo de pagamento móvel deve ser amigável com o cliente leigo. O usuário deve ter também a capacidade de personalizar o aplicativo de acordo com a sua conveniência. Todas as ações devem ser gravadas para auditoria.

7.6 MSM – MOBILE SMART MESSAGE

Permitir transações de consulta e financeiras através de comandos previamente definidos pelo Banco enviados por SMS.Autenticação através de registro do aparelho e/ou número do telefone.Permitir a customização de transações permitidas, bloqueadas e valores máximo, tanto de forma global, por perfil, quanto por cliente.Todas as ações devem ser gravadas para auditoria.

7.7 AUB – SISTEMA DE AUTOMAÇÃO BANCÁRIA – ATENDIMENTO, GERÊNCIA E RETAGUARDA

Deverá possuir login através de usuário logado na rede, sendo autenticado de forma integrada ao sistema gerenciador de acessos (SGA).Deverá implementar as transações do Anexo 1 - RELAÇÃO DE FUNCIONALIDADES definidas para o canal Vídeo, com suas regras definidas no CEN.Deverá implementar, por meio do CEN, mecanismos de controle de alçadas, autorização de transações por parte de supervisor. Todas as ações devem ser gravadas para auditoria.

7.8 AAT - AUTOATENDIMENTO

Implementar a parte servidor das transações previstas para o canal Autoatendimento no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES.Tratar as mensagens ISO8583 vindas da ATM conforme manual de mensagens ISO utilizada pelo Banco.Para as operações do autoatendimento não serão utilizados metadados e nem repassado comportamento do processo para o canal, visto que as operações são tratadas pela própria empresa fornecedora do outsourcing.Todas as ações devem ser gravadas para auditoria.

7.9 REX – REDES EXTERNAS


Desenvolver as transações das redes externas descritas abaixo conforme manual específico de cada rede.

• Visa;• Mastercard;• Banco24horas e Rede Compartilhada – Tecban;• Compartilhamento do Banco do Brasil;• Fidelity.

7.10 REC – REDES CONVENIADAS

Desenvolver interface de comunicação com os serviços descritos no Anexo 1 - RELAÇÃO DE FUNCIONALIDADES com as seguintes redes conveniadas:

• Sefaz• Ceb• Caesb• TJDFT• DI2S

7.11 SAT – SISTEMA DE AGENDAMENTO DE TRANSAÇÕES

Aplicativo back-end com capacidade de agendar as transações efetuadas nos canais quando o cliente informa uma data maior que a data corrente.Possuir reconhecimento quando a data for final de semana e/ou feriado nacional ou local, de acordo com o calendário estabelecido pelo BRB.Disponibilizar consulta de transações agendadas, pagas e canceladas.Deverá ser um módulo do CEN, devendo disponibilizar manipulação das informações para inserção, atualização, exclusão e consulta através da mesma forma que o CEN proverá para as demais funcionalidades, ou seja, utilizando-se de metadados, com processos definidos por BPM.Permitir integração com os sistemas back-end para efetivar a transação na data pré-agendada.Permitir agendamentos múltiplos, associados a um lote ou não.Permitir a parametrização dos horários de integração com os sistemas de back-end, por canal, transação, agência da conta e agência origem, permitindo também a inicialização da rotina de forma manual a qualquer tempo.As transações deverão ser processadas com base na parametrização citada no item anterior, permitindo também repescagem até o horário limite para a transação. Em caso de transação em lotes, o horário a ser seguido também deverá ser o parametrizado para a repescagem, porém levando em consideração a transação cujo horário é o menor dentre as que compõe o lote.Permitir para agendamento em lote que seja informado horário da execução, sendo que caso seja informado, esse lote não entrará na rotina de repescagem.Somente poderão ser cancelados os agendamentos, tanto individuais quanto em lotes, cujos status estejam como “agendado”.Agendamentos já efetivados poderão ser estornados por solicitação do cliente desde que sejam documentos passíveis de estorno. Para lotes, permitir-se-á o estorno completo ou individual daqueles lançamentos.

Integrar com o Provisionador de Saldos, de forma a deixar o saldo aprovisionado na conta do cliente para garantia da efetivação da transação, desde que não seja agendamento em lote com horário pré-definido, cuja responsabilidade quanto aos saldos será do cliente.Os agendamentos realizados deverão gerar seus recibos na base única de recibos do CEN.

7.12 FLT – FLUXO DE TEDs


Integrar com o sistema de mensageria do SPB (MSG), através de biblioteca própria do MSG.Deverá ser capaz de trabalhar com máquina de “status”, de forma a tratar cada requisição individualmente, permitindo mensagens diferenciadas para cada uma, tanto para TEDs enviadas como recebidas.Deverá permitir o tratamento de confirmação de envio de TED’s.Deverá permitir a integração com o CEN de forma a possibilitar a validação de informações e também efetivação da transação financeira, no caso de TED recebida ou busca de TEDs a enviar para processamento.Deverá permitir o acatamento de mensagens vindas do MSG sem que ocorra travamento da fila, ou seja, mesmo que a mensagem seja inválida, esta deverá ser acatada pelo FLT, que possuirá um serviço que validará a mensagem e prosseguirá com o tratamento.Deverá permitir o armazenamento versionado do Catálogo de Mensagens do SPB, em forma de metadados armazenados no CEN. Deverá permitir a criação de nova versão do catálogo de forma interativa por parte do gestor, podendo reaproveitar mensagens, criar novas ou alterar outras, com o menor esforço possível. Permitir a consulta de mensagens para versões anteriores do Catálogo.Criar-se um módulo de gestão, integrado ao MMC, que permita monitorar o envio e recebimento de mensagens. Esse módulo deverá permitir consultas unitárias e totalizadas, por período, canal, conta, status, mensagem ou outros filtros definidos pelo Banco. O módulo gestor deverá permitir a alteração de informações da mensagem, de forma a permitir o reprocessamento daquelas que tenham sido recebidas com alguma inconsistência.Deverá ser permitida a alteração da disponibilidade do canal de TEDs, seja para envio ou para recebimento, de forma interativa, a nível de canal, perfil de cliente, PA, horário e data.Deverá permitir a geração manual de TEDs através do módulo gestor.Permitir a geração periódica ou eventual de relatórios em tela ou geração de arquivos para integração com outros sistemas, em formato a ser definido pelo Banco.

7.13 MMC – MONITOR DO MULTICANAL

Deverá monitorar a disponibilidade de todos os canais, sistema SIA, CEN, GAB, serviços, barramento de comunicação. Permitir o cadastramento de novos serviços a serem monitorados de forma parametrizável.Monitorar o volume transacional em tempo real por canal, CEN, volume de mensagens no barramento, por terminal, armazenando as informações em base de dados a ser definida pelo Banco, exibindo-as em forma numérica e gráficos, além de gerar alertas em tela, por e-mail e SMS (integrando ao sistema de envios de SMS), com base em métricas parametrizáveis de forma a identificar queda elevada no movimento e índice acima do esperado no número de erros. Deverá permitir a consulta por data e horário, filtrando ou não por canal, conta, cartão, resposta do sistema e transação.

Deverá possuir interface web, utilizando os preceitos já definidos nos itens gerais.Monitorar os programas de alta plataforma que integram com a automação bancária, exibindo status de habilitação, fila e número de mensagens, classificando-os em ativo, em fila, fila crítica ou desabilitado, gerando alertas tais quais previstos no item 2.Possuir integração com o sistema SGA, armazenando informações de acessos e consultas, permitindo sua auditoria.

7.14 CON – CONCILIAÇÂO


O CON deverá ser capaz de realizar conciliações tais como Visa, Master, Tecban, Autoatendimento modelo outsourcing, Compartilhamento BB, conforme regras definidas por essas redes, devendo cada conciliação gerar informações em tempo real da situação de cada arquivo, devendo ser possível ao gestor ter visibilidade macro, porém com possibilidade de aumentar a granularidade do detalhe a ser observado. Deverá, também, possuir integração com o MMC, de forma a alarmar qualquer inconformidade. Deverá ser criado também no CON um Módulo Gestor para o Compartilhamento BB, integrado à rotina de conciliação desta rede, de forma a permitir ao gestor a realização de contestação de transações, bem como o acatamento de contestações realizadas por aquele Banco. Deve ser possível estender esse módulo gestor para as outras redes, se necessário.

7.15 SIA – SISTEMAS DE INFRAESTRUTURA DA AUTOMAÇÃO BANCÁRIA

7.16 BASE DE DADOS

Criar e manter base de dados de dados financeiros e de consulta/cadastro que serão utilizados para a autorização de transações. Essa base de dados será gerenciada única e exclusivamente pelo CEN. Ou seja, somente processos do CEN poderá executar inserção, alteração, exclusão e consulta neste banco de dados.O modelo de dados deverá ser criado e normalizado a partir de layout dos arquivos .TXT utilizados atualmente pelo BRB. A lista de arquivos que serão carregados para banco de dados está presente no anexo 4 deste documento.O modelo de dados deverá ser validado pela área de administração de dados do BRB.Os arquivos .TXT são gerados pelos sistemas legados e disponibilizados quase que diariamente para a automação bancária. Obedecendo essa regra deverá ser criado um mecanismo de carga destes arquivos, não normalizados, para o ambiente de banco de dados, normalizado.O processo de carga deve ser inserido no MMC – Monitor do Multicanal.Praticamente todas as transações da automação bancária geram log. Esse log deve ser armazenado em tabela própria no mesmo banco de dados do SIA.Criar um serviço responsável por realizar a subida on-line dos logs do banco de dados do SIA para a alta plataforma obedecendo layout de comunicação definido pelo BRB.Criar um processo no CEN que permita o atual Método de Acesso da automação bancária realizar todas as suas operações atualizando essa base de dados. Dessa forma, o Método de Acesso será apenas um roteador das transações dos atuais canais da automação bancária permitindo a migração da estrutura antiga para a solução de Multicanal.

7.17 PROCESSADOR DE DÉBITOS E CRÉDITOS


Criar um processador responsável por receber arquivos financeiros dos sistemas legados e processá-los diretamente na base de dados do SIA. Esses arquivos são em formato .TXT.O processador deve utilizar layout definido pelo BRB.Os arquivos recebidos em diretório específico deverão ser carregados no banco de dados do SIA. Após carregar o arquivo no banco de dados uma procedure deverá buscar os registros não processados e atualizar a tabela financeira do MAC.Gerar arquivo retorno obedecendo layout estabelecido pelo BRB.Todos os status dos arquivos e de cada registro deste arquivo devem ser registrados no MMC. Esse processo abrange desde a disponibilização do arquivo em diretório específico, passando pela importação do arquivo para banco de dados, pelo processamento dos registros, até a geração e envio do arquivo retorno para o sistema legado. O processador deve ser capaz de processar vários arquivos simultaneamente.O processador deve ser capaz de processar milhares de registros em poucos minutos permitindo assim que o BRB possa trabalhar com créditos e débitos quase que on-line. Assim sendo o serviço que carregará os arquivos em banco de dados deverá ser capaz que realizar a carga de um arquivo com, por exemplo, 100.000 registros, em menos de 10 minutos. Após carregar esses registros o outro processo que atualizará o arquivo financeiro deverá ser capaz de processar todos esses registros nos mesmos 10 minutos. O terceiro e último processo responsável pela geração do arquivo retorno terá, no máximo, mais 10 minutos para concluir a geração e envio deste arquivo. Com isso, o tempo total de processamento de um arquivo com 100.000 registros será de 30 minutos.O processador deverá funcionar em 24X7.O processador não poderá permitir que o processamento de um arquivo seja iniciado em D0 e concluído em D+1.



Desenho da solução Multicanal

IBKInternet

Banking eTelebanco

CIXCaixa e

Correspondente

MBKMobileBanking

AUBSistema deAutomação

Bancária

MPYMobile

Payment

MSMMobileSmart

Message

BARRAMENTO

GABMódulo

deGerenciamento

CENCentralizador

EAutorizador

CONConciliação

SATSistema

DeAgendamentos

FLXFluxo

DeTEDs

MMC – Monitor do Multicanal

SIA – Sistema de Infraestrutura da automação

BARRAMENTO

LEGADOBAIXA

PLATAFORMA

LEGADOALTA

PLATAFORMA

AATAuto

Atendimento

REXRedes

Externas

RECRedes

Conveniadas

8 ADAPTAÇÃO DA SOLUÇÃO AO NEGÓCIO BRB

A emissão do termo de aceite será dada por módulo entregue e ocorrerá, em até 05 (cinco) dias úteis, após a homologação do referido módulo adaptado às características e serviços descritos nos itens deste Projeto Básico.Auxiliar o BRB na validação dos dados, desempenhando as atividades necessárias de detecção de erros tanto nas bases recebidas como nos programas de migração.Construir os programas de migração conversores de logs, arquivos, base de dados, e demais arquivos de houverem, quando necessário, da atual solução de automação bancária do BRB para o modelo de dados proposto pela Contratada e validado pela área de Tecnologia do BRB.Preparar os testes da solução de Multicanal com as equipes de homologação de processos do BRB.Executar as atividades de escrever, corrigir, compilar, testar em seu ambiente, e encaminhar para a homologação os softaware integrantes da Solução utilizando o link de comunicação disponibilizado pelo BRB, que conecta o ambiente de desenvolvimento da contratada ao ambiente de desenvolvimento BRB, para envio dos serviços executados da Solução de Multicanal adaptado ao Negócio BRB.Obs: Esse link de comunicação ficará ativo até 1 mês após a implantação do último pacote de módulos, canais e serviços.Desenvolvimento/Manutenção durante a fase de adaptação da Solução de Multicanal (sob demanda).A transferência de Tecnologia ocorrerá durante todo o período de vigência do contrato.

8.1 Obrigações da CONTRATADA

Realizar e cumprir acordo de nível de serviço entre as partes para a Transferência da Tecnologia durante a execução das fases do Contrato.Realizar reuniões técnicas e/ou gerencias de Ponto de Controle, mensalmente, ou quando houver necessidade e prestar esclarecimentos às equipes do BRB sobre questões relativas a documentação e a implementação da solução – Adquirida e Adaptada.Formatar e fornecer o conteúdo da Transferência de Tecnologia utilizando os instrumentos conceituais descritos na tabela abaixo.

ANÁLISE ORIENTADA A OBJETOa) Modelo de Entidade e Relacionamento - Dadosb) Dicionário de Dadosc) Diagrama de Classesd) Diagrama de Casos de Usoe) Casos de Uso do Projeto f) Diagrama de Sequênciag) Ambiente de Hardware e Software

CÓDIGOS FONTEa) Camada de Apresentaçãob) Camada de Aplicação – descrevendo o objetivo da aplicação e arquivos utilizadosc) Camada de Dados

MANUAL DE PRODUÇÃOa) Fluxos de produçãob) Especificação básica das rotinas operacionais

MANUAL DE USUÁRIOa) Apresentação resumida do sistemab) Modelo de Preenchimento dos documentos e arquivos para processamentoc) Tratamento e resultado gerado em cada uma das fases do sistema d) Descrição de rotinas por ambiente


e) Relatórios do sistemaf) Informação de Central de Atendimento ao Clienteg) Tabela de apoio (parâmetros do sistema)

Instalar a solução do Multicanal Adaptada nos ambientes de Desenvolvimento, Homologação de Processos e de Produção do BRB.

8.2 TREINAMENTOS

Os treinamentos ocorrerão, na cidade de Brasília, somente após o aceite formal do BRB sobre a solução do Multicanal adaptado.

Deverá ser ofertado, sem ônus adicional à CONTRATANTE, treinamento para capacitação inicial de até 30 (trinta) pessoas sobre a instalação, utilização e adaptação do produto para as aplicações alvo, a ser realizado em datas e horários a serem definidos pelo CONTRATANTE, em suas dependências, em número de turmas a ser definido pelo CONTRATANTE, sendo mínimo de 5 (cinco) participantes e no máximo a capacidade de lotação da dependência que o CONTRATANTE designar para tal treinamento ou, a critério da CONTRATADA, limitar o número máximo de participantes de forma a manter a qualidade do treinamento. Esse treinamento deverá ser ministrado até 20 dias antes da entrega final do primeiro pacote.

Poderá ser requisitado pelo CONTRATANTE por até 4 (quatro) vezes durante a vigência do contrato, desde que com aviso prévio de 60 (sessenta) dias e também sem ônus ao CONTRATANTE, treinamento de outras pessoas, em turmas de no mínimo 5 (cinco) participantes e no máximo a capacidade de lotação da dependência que o CONTRATANTE designar para tal treinamento, limitadas cumulativamente à outras solicitações ao total de 20 (vinte) pessoas, não sendo cumulativo entretanto ao treinamento inicial de até 30 (trinta) pessoas.

O CONTRATANTE poderá, a seu critério, acatar sugestões da CONTRATADA para alteração no local, data, horário e capacidade das turmas do treinamento, desde que respeitado o número máximo de pessoas previsto para o treinamento durante a vigência do contrato. É prerrogativa do CONTRATANTE, por sua exclusiva conveniência, determinar que esses treinamentos sejam realizados em local e com recursos a serem oferecidos pela CONTRATADA.

9 REMUNERAÇÃO

A remuneração será por fase do projeto e ocorrerá 20 dias após a implantação da fase. Essa remuneração será composta da seguinte forma:

Remuneração: (custo do módulo/canal adaptado) + (custo do desenvolvimento das funcionalidades do canal previstas no anexo 1)

O custo do módulo/canal a engloba a adaptação de todos os requisitos gerais e específicos descrito neste projeto básico para o referido módulo/canal, com exceção das funcionalidades descritas no anexo 1. O preço do módulo/canal será fixo.

A construção das funcionalidades daquele módulo/canal constantes no anexo 1 será feita pela equipe técnica da CONTRATADA. A remuneração neste caso se dará através da contagem de PONTOS DE FUNÇÃO conforme regras definidas no item 9.1 deste projeto básico.


Aquisição Módulo/Canal Adaptado

Funcionalidades (Ponto de Função)

PRIMEIRA FASECEN – Centralizador Sim NãoGAB – Módulo geral de gerenciamento do multicanal

Sim Não

MMC – Monitor do multicanal Sim SimIBK – Internet Banking e Telebanco Sim SimMBK – Mobile Banking Sim SimSIA – Sistemas de infraestrutura da automação bancária

Não Sim

SEGUNDA FASECIX – Caixa Agência e Correspondente Sim SimAUB – Sistema de automação bancária Sim SimAAT – Autoatendimento Não SimREX – Redes Externas Não SimREC – Redes Conveniadas Não SimCON - Conciliação Sim NãoTERCEIRA FASESAT – Sistema de Agendamento de transações

Sim Sim

FLX – Fluxo de TEDs Sim SimQUARTA FASEMPY – Mobile Payment Sim SimMSM – Mobile Smart Message Sim Sim

9.1 PERCENTUAL DE REMUNERAÇÃO PARA PROJETOS COM PONTOS DE FUNÇÃO.

O custo do ponto de função será um dos fatores determinantes para a escolha da empresa vencedora do certame.

Conforme sinalizado no item 4.4 os atuais sistemas de automação bancária não possuem uma documentação que permita uma estimativa de pontos de função necessários para a construção das funcionalidades no centralizador e adequação do canal para estas funcionalidades.

Como critério para estimar a quantidade de pontos de função será adotar a mesma quantidade prevista no contrato de prestação de serviços DIRAD/DESEG-2011/005 que trata da manutenção dos sistemas de automação bancária e de escritório.

Nesse contrato são previstos 4.200 pontos de função para um período de 12 meses.

Para a solução de multicanal será adotada a seguinte escala:

FASE DURAÇÃO DA FASE QTD. PONTOS DE FUNÇÃOPRIMEIRA FASE 6 MESES 2100SEGUNDA FASE 6 MESES 1050TERCEIRA FASE 6 MESES 525QUARTA FASE 6 MESES 260

Como a solução multicanal prevê o reutilização de processos então a tendência é que as outras fases utilizem uma quantidade menor de pontos de função para a implementação das funcionalidades.

A contagem de Pontos de Função será efetuada no repasse dos serviços (Contagem Estimativa) e na conclusão dos serviços (Contagem Final) pela Contratada, cabendo ao BRB efetuar a validação dessas contagens. Esses serviços ou funcionalidades estão descritos no anexo 1.


A contagem de Pontos de Função será baseada na metodologia descrita no Manual de Praticas e Contagens (Counting Practices Manual Release 4.2), publicado pelo IFPUG (International Function Point Users Group), em 2005 ou a que for vigente a época da contratação.

A especificação de requisitos é de obrigação exclusiva da CONTRATADA. Essa especificação será realizada através de entrevistas e reuniões com os gestores de negócio do BRB e com a equipe técnica da área de informática do BRB.

A contagem estimativa de Pontos de Função será efetuada pela Contratada após a captura dos requisitos junto ao BRB. A contagem estimativa, poderá ser feita de acordo com as técnicas de contagem estimativa definidas pela NESMA - Netherlands Software Metrics Users Association, a critério da Contratada desde que ela informe a metodologia utilizada em cada caso.

Caso ocorram alterações sobre os requisitos do sistema, objeto dos serviços de mensuração, no período de execução desses serviços, ficará caracterizada mudança de escopo, devendo ser reavaliada a dimensão dos serviços para efeito do faturamento.

A distribuição percentual de Pontos de Função por fase do processo de desenvolvimento de aplicativos adotada pelo BRB e apresentada na tabela abaixo.

Fases % de DistribuiçãoDefinição do Sistema 3%Especificação de Requisitos 13%Elaboração do Modelo Lógico 11%Elaboração do Projeto Detalhado 28%Construção 34%Integração e Homologação 7%Implantação 4%

Caso haja divergências iguais ou superiores a 5% entre o BRB e a Contratada em relação as contagens de pontos de função do serviço efetuado, representantes do BRB e da Contratada deverão se reunir para resolver as divergências. Caso as divergências sejam inferiores a 5%, prevalecerá a contagem arbitrada pelo BRB.

A Contratada após fazer a contagem detalhada, disponibilizará o resultado em conjunto com a documentação dos fatores que embasaram a contagem. A critério do BRB pode ser solicitada a Contratada documentação adicional para a validação da contagem.

No caso de haver alteração de escopo, após a estimativa, deve ser gerado um documento contendo dados que registrem a alteração de escopo e uma avaliação comparativa da precificação antes e depois da alteração, enfatizando o impacto decorrente da alteração.

Todos e quaisquer produtos desenvolvidos pela Contratada para a execução dos serviços objeto deste projeto básico, serão de propriedade do BRB, incluindo-se arquivos em meio magnético, códigos fonte, códigos executáveis, documentação e outros gerados no contexto dos serviços.

O desenvolvimento das funcionalidades devem cumprir os prazos previstos no item 2.

Para o desenvolvimento das funcionalidades a CONTRATADA deverá gerar os artefatos previstos no item 5.5.

10 PADRÕES DE SEGURANÇA

Os empregados da CONTRATADA terão acesso ao ambiente BRB, respeitados os padrões de


Controle de Acesso Lógico e Sistemas Computacionais.

11 CONECTIVIDADE

Será disponibilizada para e empresa CONTRATADA a conectividade ao ambiente de Desenvolvimento do BRB que processará a solução de Multicanal, no sites de contingência localizados no SIG – Setor de Indústrias Gráfica e no SCN – Setor Comercial Norte.

O acesso será feito pela Extranet do BRB e da CONTRATADA, com todos os recursos tecnológicos inerentes a esse tipo de ambiente (DMZ), considerado altamente critico, como exemplo: Filtros em roteadores, uso de Firewall, Software de detecção de intrusão, Antivírus, Serviços de FTP segregados, onde haverá a autenticação dos empregados da empresa CONTRATADA.

Pode ser necessária a utilização de recursos de NAT (Network Adress Translation) no ambiente da empresa que se autenticará na Extranet, a critério do BRB.

Após a autenticação ma Extranet do BRB, a empresa terá acesso aos sistemas de acordo com a necessidade dos serviços.

A conectividade detalhada neste item será utilizada pela empresa CONTRATADA para transmitir ao BRB os códigos fonte das Adaptações, Desenvolvimento e Manutenções efetuadas.


12 ANEXOS 12.1 Anexo 1 – Relação de Funcionalidades


12.2 Anexo 2 – Sistemas e Serviços Descontinuados:

• ABA e AbaAdmin: Aplicativo de Vídeo utilizado em Pontos de Atendimento e Áreas da Direção Geral relacionadas com rotinas operacionais e seu Módulo Administrador.

• ABX: Autorizador utilizado pelo autoatendimento e para outras funcionalidades de outros canais eletrônicos.

• APB: Utilizado para envio e recebimento de TED’s, através das diversas mensagens previstas no SPB.

• ATB: Aplicativo de Caixa – Agências e Pabs.• ATC: Aplicativo de Caixa – Correspondentes não Bancários.• BKT/TLB: Internet Banking e BRB Telebanco.• Gateway ABX: Gateway para envio das requisições ao ABX.• Gateway CBR: Gateway para comunicação com os sistemas CBR, CHM e APS.• Gateway SadsXP: Utilizado para comunicação com sistemas do BRB02 em plataforma

intermediária – Entre o Mainframe e Baixa Plataforma.• Gateway Sefaz: Utilizado na comunicação do ABX com a Sefaz para informações sobre

IPTU e IPVA.• Gateway Redes Externas: Em ambiente DMZ interagindo com o HRX para redes externas

e autoatendimento.• Gateway URA: Utilizado na comunicação da URA com o ABX.• GPW: Gerenciador de Pagamentos WEB para Pessoa Jurídica.• HRX: Utilizado para redes externas e conciliações.• PRJ Monitor/MON: Utilizado na monitoração da automação bancária.• PTL: Portal utilizado para gerenciamento do Internet Banking.• Serviço de Busca em Traces: Utilizado para consulta aos traces gerados pelo ABX.• Roteador TCP: Utilizado para roteamento de mensagens entre ABX e CEB.• SIA – Sistema de Infraestrutura da automação bancária e Método de Acesso.


12.3 Anexo 3 – Arquivos do Método de Acesso

Tabela Descrição

• AGE Tabela de agências• ARU cadastro de arrecadações unificado• ASB Bancos Interligados à ASBACE - Rede Verde/Amarela• BNF Arquivo Financeiro de INSS• BNS Arquivo de controle de movimentações em conta para sincronismo com o arquivo

de carga do BNF. Delta do BNF• CCA Arquivo financeiro de Contas Corrente e Contas Investimento• CCS Arquivo de controle de movimentações em conta para sincronismo com o arquivo

de carga do CCA. Delta do CCA• CDA Cadastro de empresas conveniadas para débito automático• CDG Cadastro de códigos de transação• CEC Cadastro das características dos produtos. Não é utilizado mais• CHS Cadastro de cheques sustados• CLT Cadastro de clientes• CNT Cadastro de contas• CRG Arquivo de controle da carga dos arquivos• CTM Cadastro de cartões magnéticos• CTS Arquivo de controle de movimentações em conta para sincronismo com o arquivo

de carga do CTM. Delta do CTM.• DET Arquivo utilizado para guardar dados do Detran nas consultas de débitos• DRF Arquivo de cadastro de empresas para recebimento de DARFs• DPS Arquivo de Cadastro do Ponto de Atendimento. Possui apenas as agências de cada

SuperAgência. Equivale às agências cadastradas no LSTPTASUPER.ini• FAP Saldo de fundos de aplicação• FCC Faixa de códigos de clientes e faixa de depósitos• FER Cadastro de feriados locais e nacionais• FFA Cadastro de fundos de aplicação• FIN Cadastro da finalidade da conta. Utilizado para impressão de nome diferente do

cliente em folhas de cheques• FXD Faixas de depósito de produtos• GCO Cadastro de gerentes de contas• GPS Cadastro dos códigos de pagamento permitidos para GPS• IDC Cadastro de identificadores de conta. Utilizado para Depósito Judicial pelo APB em

consulta ao ABX• INE Índices econômicos• LOG Logs do movimento diário da automação• LOX Logs do movimento diário da automação. Apenas transações utilizadas para

relatórios e/ou extrações• LPA Cadastro de limites de pré-aprovado• LPD Logs de pendência de transações de destino• LPO Logs de pendencias na origem• MON Logs utilizado para a Monitoração da Automação• NIF Arquivo de controle da última Agência utilizada• OPS Cadastro de operadores• PPA Arquivo financeiro de conta poupança• PPS Arquivo de controle de movimentações em conta para sincronismo com o arquivo

de carga do PPA. Delta do PPA• PRM Arquivo de parâmetros dos sistemas da automação• PRO Arquivo de cadastro de profissões• RCC Arquivo de relacionamento entre conta corrente e código do cliente• ORG Cadastro de órgãos pagadores


• TCP Cadastro de tipos de contas• TPC Cadastro das praças de compensação• TSI Arquivo de relacionamento entre a praça de compensação e o Sirc• SRV Cadastro dos trancodes de mensagens


12.4 Anexo 4 – Relação das funcionalidades previstas para o Mobile Banking

MOBILE BANKING

• Saldo de Conta Corrente• Saldo de Poupança• Saldo de Poupança Integrada• Extrato de Conta Corrente• Extrato de Poupança• Extrato de Poupança Integrada • Extrato de Cheques Compensados• Extrato de Lançamentos Futuros• DDA – Título Eletrônico• Títulos do BRB• Títulos de Outros Bancos• Tarifas Públicas/Privadas e Impostos• Fatura de Cartão BRB (pelo número do cartão)• Cancelamento de pagamento no dia• Cancelamento de agendamentos• Transferência entre contas do BRB• Aplicação em fundos de investimento• Resgate parcial em fundos de investimento• Resgate total em fundos de investimento• Cancelamento de aplicação/resgate

12.5 Anexo 5 – Relação das funcionalidades previstas para o GPW

• GPW• Abertura de conta salário• Pagamento de salário em lote• Pagamento de fornecedores• Folha de pagamento por arquivo• TED em lote• Pagamento de títulos em lote• Pagamento de títulos on-line• Crédito Consignado• Contracheque no Auto Atendimento


13 GLOSSÁRIO

Acordo de níveis de serviços – ANSSão acordos firmados para identificar a performance dos serviços, por meio de indicadores mensuráveis e procedimentos de execução de atividades entre as partes.Agência OrigemAgência onde foi realizada a transação.AgendamentoLançamento financeiro para data futura.AjaxAcrônimo em língua inglesa de Asynchronous Javascript and XML, que é o uso metodológico das tecnologias Javascript e XML, para tornar as páginas web mais interativas com o usuário, utilizando-se de requisições assíncronas de informações ao servidor, ou seja, sem a necessidade de submeter a página por completo, o que provê ganhos substanciais em performance dentre outros itens favoráveis.Ambiente de DesenvolvimentoAmbiente de desenvolvimento e implementação de regras de negócio, para validação dos serviços solicitados.Ambiente de HomologaçãoAmbiente de testes e validação dos serviços solicitados, para posterior disponibilização em ambiente de produção, utilizando massa de testes gerada pelo Gestor.Ambiente de ProduçãoAmbiente onde se encontram as bases de produção e onde são executados os programas de sistemas batch e on-line já homologados e aceitos.Análise de Pontos de FunçãoMétodo padrão para mensuração de desenvolvimento de software, do ponto de vista do usuário. (IFPUG – International Function Point Users Group).AnnotationsRecurso da Plataforma Java desenvolvido a partir de sua versão 1.5, que permite o uso de metadado ao longo do código para posterior interpretação por um compilador, para então executar uma tarefa pré-definida. Evita, em muitos casos, a criação de arquivos XML de configuração, que dificultam a compreensão e manutenibilidade do sistema. Ajuda também na automatização de algumas tarefas, como o mapeamento de persistência com o banco de dados e a geração de web-services.APIApplication Programming Interface (ou Interface de Programação de Aplicações) é um conjunto de rotinas e padrões estabelecidos por um software ou hardware, para a utilização de suas funcionalidades por programas aplicativos, de forma a não necessitar envolvimento em detalhes de implementação de software, além de otimizar o prazo, evitando redesenvolvimento de soluções.Aplicativo CRAplicativo desenvolvido em Delphi que consiste em interface de comunicação socket do lado cliente, que fica aguardando requisições vindas do EAP. Essas requisições informam sobre o atendimento de um novo cliente e, se acatado pelo operador, gerarão o acesso a um endereço web dentro de um dos web-browsers do Aplicativo. Permite também a simulação de recebimento de bilhetes.ATMSigla inglêsa para designar Automatic Teller Machine, que nada mais é que um caixa eletrônico.BacklogÉ utilizado para designar uma lista de espera para ações, em geral demandas ou atividades, com prioridades definidas.Banco do BrasilInstituição financeira brasileira com a qual o BRB mantém acordo para compartilhamento de rede de ATM’s.Banco24horasRede de ATM’s mantida pela empresa Tecban que é compartilhada por diversas instituições bancárias.


Barramento de ServiçosNome utilizado para designar onde os canais serão conectados para acesso a funcionalidades ou roteamento de mensagens. É por onde passarão todas as requisições da nova solução.Barramento 32 e 64 bitsRefere-se à dimensão dos registradores internos de um processador, que irá definir com quantos bits por vez esse processador trabalhará. Atualmente utilizam-se 32 e 64 bits.BB Ver Banco do Brasil.BPMGerenciamento do Processo de Negócio (em inglês Business Process Management). É um conceito que reúne gestão de negócios e tecnologia da informação, com foco na otimização do resultado da organização, por meio da melhoria dos processos de negócio, através de métodos, técnicas e ferramentas que permitam analisar e modelar o processo de negócio, tendo reflexo imediato em ambiente tecnológico. As ferramentas que permitem a customização dos processos sem intervenção em códigos fontes, são denominadas de sistema de gestão de processos de negócio (BPMS).BugErro no funcionamento comum de um software, causando discrepâncias no objetivo ou impossibilidade de realização da ação desejada.CaesbCompanhia de saneamento ambiental do Distrito Federal. Empresa pública com a qual o BRB mantém parceria para prestação de serviços, atualmente no autoatendimento.ContainerEm programação, traduz-se como um objeto que contém outros objetos, podendo estes serem incluídos ou removidos dinamicamente.CanalNomenclatura utilizada para designar canais de atendimento, que são os meios de interação com o cliente, seja por intermédio de um operador autorizado pelo Banco, ou seja de forma eletrônica.Cartão BRBEmpresa de cartões do grupo conglomerado BRB.CEBCompanhia Energética de Brasília. Empresa pública a qual o BRB mantém parceria para prestação de serviços, atualmente no autoatendimento.CieloEmpresa brasileira (antiga Visanet) responsável pela captura e transmissão de transações com cartões de crédito e débito.ClienteAquele que se relaciona com o banco de qualquer forma, seja como correntista, poupador, beneficiário INSS ou beneficiário de programas sociais, por meio da utilização de serviços como agendamentos, pagamentos, depósitos ou serviços de entidades parceiras.ClusterÉ um conjunto de computadores que utiliza um sistema operacional configurado de forma especial a trabalhar como um sistema distribuído. Em nosso contexto, trata-se de dois tipos, a saber: Cluster de alta disponibilidade: permite a permanência do sistema ativo por longos períodos de tempo e em plena condição de uso. Cluster de balanceamento de carga: tem função de controlar a distribuição equilibrada do processamento.CNAB240A sigla CNAB provem de Centro Nacional de Automação Bancária (atual Ceneaban), que é um núcleo da Febraban responsável por padronizar normas e leiautes das cobranças eletrônicas. O CNAB240 é um padrão para intercâmbio de informações entre bancos e empresas.Código FonteCódigo original de um aplicativo desenvolvido utilizado para geração e atualização das versões do mesmo.ContaÉ um produto oferecido pela instituição financeira que pode ser de vários tipos, sendo os mais comuns conta corrente e poupança.


DelphiIDE fornecida pela empresa Embarcadero (antiga CodeGear, Inprise ou Borland) para desenvolvimento na linguagem (Object) Pascal.DI2SNome fantasia da Empresa Data Interchange Information Solutions, detentora da Tecnologia de veiculação de Torpedos e Mensagens, contratada pelo BRB para o envio de mensagens de e-mail e SMS por demanda.DMZDeMillitarized Zone ou “zona desmilitarizada”. A DMZ é uma rede situada entre uma rede confiável e uma não confiável, com função de manter todos os serviços que possuem acesso externo separados da rede local, limitando assim o potencial de dano em caso de comprometimento de algum destes serviços por um invasor.DirectTalkEmpresa contratada pelo BRB para fornecimento de solução de web-chat, que permite o contato de clientes de um determinado perfil, com atendentes e gerentes do BRB, por meio de chat.EAPComponente lógico da Unidade de Resposta Audível – URA, classificado como Gateway, responsável pela validação das informações do cliente nos Sistemas do BRB, para o direcionamento das ligações entrantes para determinada cabine, contendo as informações financeiras e cadastrais do cliente.EstornoCancelamento de uma ação.EnfileiramentoQuando há requisições a um sistema ou programa, que gera gargalhos no tratamento dessas requisições.FidelityEmpresa que administra a função de crédito dos cartões do banco, além de ser responsável pela geração do plástico.FilaDenomina-se fila a quantidade de requisições a aguardar tratamento.Fila CríticaChamamos fila crítica quando um enfileiramento toma grandes proporções.FrameworkTambém referenciadas na literatura como arcabouço. É um conjunto de classes implementadas em uma linguagem específica, usadas para auxiliar o desenvolvimento do software.FreewareÉ qualquer programa de computador, cuja utilização não implica o pagamento de licenças de uso ou royalties para seus idealizadores.GatewayPonto intermediário em uma comunicação geralmente destinado a interligar redes, separar domínios ou traduzir protocolos. Também chamado de porta de ligação. GEDGerenciador Eletrônico de Documentos. Software utilizado para gestão eletrônica de documentos, que prevê a geração, controle, armazenamento, compartilhamento e recuperação de informações existentes em documentos, de forma ágil e segura, sendo possível a geração de workflow, para controle do fluxo desses documentos.GestorUsuário ou área do banco responsável pela gestão técnica, funcional ou negocial do sistema ou produto.HibernateFramework open source de mapeamento objeto-relacional para linguagem Java, que facilita o mapeamento dos atributos entre uma base tradicional de dados relacionais e o modelo objeto de uma aplicação, através de arquivos de configuração XML ou Annotations. O Hibernate implementa JPA.HintsDicas rápidas que aparecem ao passar o cursor do mouse sobre determinado item.HSM


Host Security Module. Fabricado na França e Fornecido pela empresa Thales-esecurity, é um Módulo de segurança baseado em hardware, para redes de intercâmbio que é utilizado pelo BRB e várias outras instituições no Brasil e no Mundo (Visa, Master, Amex, etc). É fisicamente seguro, possui processador criptográfico (DES, 3DES e RSA). É dirigido a aplicação, com suporte a várias funções padrão, além de possuir várias opções de conectividade com o Host. No Brasil a Empresa fabricante e fornecedora é representada pela Empresa First Tech, que fornece, configura e presta suporte técnico e operacional.IBM-DB2Banco de dados relacional mantido pela empresa IBM.ISO8583Padrão ISO para troca de mensagens.iWorkPlaceFramework adquirido pelo Banco e mantido pela empresa Infonet, para o desenvolvimento e funcionamento do atual Internet Banking.JavaLinguagem de programação orientada a objeto desenvolvida na década de 90 pela empresa Sun Microsystems. JavaBeanÉ um POJO que segue definições rígidas de estrutura (construtor default sem argumentos, atributos privados ou protegidos e métodos que seguem o padrão getters e setters para seus atributos).JavaBluePrintsÉ um guia de melhores práticas e padrões da Sun Microsystems, para desenvolvimento na Plataforma Java.JavaDocÉ um gerador de documentação criado pela Sun Microsystems, utilizado para documentar o código fonte, com resultado extraído para HTML.JavaSoftPadrão de codificação para a linguagem Java.JbossSeamFramework criado pela JBoss/Red Hat para aumentar a produtividade de aplicações Java que usam principalmente JSF e EJB 3.JPAJava Persistence API. É uma API padrão do Java para persistência que deve ser implantada por frameworks que queiram seguir o padrão.JSFJavaServer Faces é um framework open source que adota do modelo MVC para o desenvolvimento de aplicações web de forma visual, ou seja, arrastando e soltando componentes na tela e definindo suas propriedades. É considerada por muitos a última palavra em termos de desenvolvimento para web em Java.JsonJavaScript Object Notation. É um formato leve para intercâmbio de dados que vem ganhando espaço frente ao XML, dada sua melhor otimização e facilidade de uso. Se utilizado em conjunto com Ajax, traz grandes ganhos de performance. Pode, porém, ser utilizado para outras comunicações entre sistemas, também apresentando ganhos.JSR 286Especificação Java para desenvolvimento de portlets.Leiaute - “Layout”Distribuição física de elementos num determinado espaço.LibrasLíngua Brasileira de Sinais é uma linguagem gestual usada pela maioria dos deficientes auditivos. Não é apenas a gestualização da língua portuguesa e sim uma língua à parte, composta de fonologia, morfologia, sintaxe e semântica, regulamentada no Brasil por legislação própria.LoginPalavra inglesa utilizada para descrever o ato de acessar um sistema. Utilizado também para designar o nome de usuário para acesso ao sistema.


LotesConjunto de registros a serem processados.Master/Mastercard/MaestroRede de cartões de débito e de crédito operados pela empresa Mastercard.MetáforasImagens que fazem a ligação entre palavras e seus significados, de forma a torná-los mais claros e visíveis. Ex.: E-mail simboliza-se com o desenho de uma carta, enquanto uma busca simboliza-se com uma lupa.Mobile PaymentEngloba todo tipo de operação que envolva um dispositivo móvel para iniciar, ativar ou confirmar um pagamento. Os dispositivos móveis mais comuns são os telefones celulares, mas aqueles que já são usuários de smartphones e PDAs têm sido os primeiros a usar esse meio de pagamento.MVCModel- view-controller. Padrão de arquitetura de software que visa separar a lógica de negócio da lógica de apresentação.MVC-2Idem ao MVC, com a diferença de que o MVC-2 possui um único controller responsável por redirecionar as requisições.OFCOpen Financial Connectivity - formato para arquivo de conciliação financeira utilizado pelo Software Microsoft Office Money. É considerado obsoleto e foi substituído pelo formato OFX.OFXOpen Financial Exchange - formato aberto para troca de informações financeiras para permitir a conciliação financeira. OracleEmpresa fornecedora do banco de dados relacional de mesmo nome.OutsourcingModalidade de contratação de prestação de serviços especializados para realização das chamadas atividades meio, que consiste no fornecimento de todos os itens da solução (Software Básico, Software Aplicativo e Equipamentos) pela contratada.PDFPortable Document Format. É um formato aberto de arquivo desenvolvido pela Adobe Systems, para representar documentos de maneira independente do aplicativo, hardware ou sistema operacional, de forma inviolável.POJOPlain Old Java Objects são objetos Java que seguem um desenho simplificado.PASigla de Ponto de Atendimento, que no BRB define de forma genérica uma Agência ou Posto de Atendimento Bancário – PAB. PertoEmpresa atual fornecedora da solução de Autoatendimento disponibilizado pelo BRB a seus clientes. Composta por ATMs, Software Básico, Software Aplicativo e equipamentos denominados ATM. Ponto de FunçãoUnidade de medida de sistemas que quantifica as funcionalidades proporcionadas aos usuários, independente de aspectos de implementação.Provisionador de SaldosServiço que permite aos sistemas legados informarem à automação bancária, da necessidade de bloqueio de determinado valor do saldo do cliente, na véspera de crédito de salário, para permitir débitos em sua conta, garantindo liquidação de operações contratadas. ProxyÉ um software de controle de dados que atende às requisições, repassando os dados do cliente à frente.RedeshopRede adquirida pela Mastercard, que passou a operar como Mastercard Maestro, após sua unificação à Maestro.


RollBackAção de desfazer as mudanças efetuadas em um Banco de Dados, por um processo de atualização que não tenha sido concluído, devolvendo a esse banco de dados o status quo de antes do início desse processo. SefazSecretaria de Fazenda do Distrito Federal. Órgão ao qual o BRB é vinculado e mantém convênio para o oferecimento de serviços, como por exemplo a consulta de IPTU e IPVA para pagamento.SGASistema Gerenciador de Acesso, utilizado no BRB para gerenciar usuários e perfis, que processa por meio de requisições que devolvem a permissão ou não, para acesso a determinado sistema.SMSShort Message Service. É um serviço de envio de mensagens curtas, destinado para recebimento em aparelhos celulares. É utilizado pelo BRB, entre outros usos, para aviso sobre movimentação financeira em conta.SOAService Oriented Architecture. Pode ser traduzido como Arquitetura Orientada a Serviços, e é um estilo de arquitetura de software, cujo princípio fundamental prega que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços, frequentemente disponibilizados em um barramento de serviços (enterprise service bus, em inglês) que disponibiliza as interfaces ou contratos, acessíveis por web-service ou outra forma de comunicação entre sistemas.SpringÉ uma framework open source, que define que o container se encarrega de “instanciar” classes de uma aplicação Java, definindo suas interdependências através de configuração em XML, Annotations ou inferências do framework. Possui arquitetura baseada em POJO e interfaces, fornecendo aos POJOs características de segurança e controle de transações.Struts 2Framework open source que é uma evolução do framework Webwork, onde do original Struts praticamente herdou-se só o nome. Utiliza o padrão MVC-2, é facilmente integrável a outros frameworks para persistência, controle transacional e para camada de visão (utilizando Ajax). É uma alternativa ao JSF.SubusuárioUtilizado para descrever um usuário autorizado a consultar ou pré-gerar transações em uma conta através de um canal, mesmo que não seja um cliente vinculado à conta.SubversionTambém conhecido por SVN é um repositório para controle de versões.TaglibDefine uma biblioteca a ser utilizada necessitando apenas chamar a partir de um prefixo.TecbanEmpresa mantenedora do Banco24horas e Rede Compartilhada.Teclado VirtualApplet Java utilizado para digitação de senha em ambiente web nos portais do BRB.TJDFTTribunal de Justiça do Distrito Federal e Territórios. Órgão do Poder Judiciário ao qual o BRB mantém acordo para consulta processual através de canal eletrônico.TilesSolução para organização, padronização e estruturação da navegação e leiaute das páginas de um site. Originou-se no framework Struts, mas pode ser utilizado por outros frameworks.TitularÉ aquele que faz parte das ordens de uma conta, autorizado a movimentá-la.Transferência de TecnologiaContrato em que se transfere o conhecimento industrial. Este pode ser conceituado como o saber imprescindível à produção de um bem destinado à comercialização. As cláusulas de tal contrato eram impostas pelo Instituto Nacional de Propriedade Industrial (INPI), mas com a resolução no. 20-91, do próprio INPI ficam as partes contratantes liberadas para a forma contratual que melhor lhes convier, exigindo-se apenas a averbação do contrato no próprio INPI, para efeitos fiscais. São modalidades de transferência de tecnologia:


a) licença de uso de privilégio industrial (exploração de patente)b) licença de uso de registro industrial (uso de marca)c) fornecimento de tecnologiad) prestação de serviço de assistência técnica e científica

No contexto deste contrato está sendo utilizada a modalidade: “c” Fornecimento de Tecnologia

TokenCódigo randômico enviado para e-mail ou celular pré-cadastrado e liberado, de forma a permitir ao cliente a autorização de uma transação financeira.TXTArquivo magnético no formato de texto.UMLUnified Modeling Language. É uma linguagem de modelagem não proprietária que permite que os desenvolvedores visualizem os produtos de seu trabalho em artefatos padronizados.URAUnidade de Resposta Audível.UsuárioUtilizado para denominar o usuário de uma aplicação. VisaBandeira de cartões detentora da Cielo.XMLeXtensible Markup Language. É utilizado para escrever diversos tipos de dados, com propósito principal de facilidade de compartilhamento de informações através de redes de comunicação.WSRP 2.0Web Services for Remote Portlet. É uma especificação aberta que define a forma para interação entre serviços web que oferecem portlets. Pode ser utilizada junto à JSR 268.WorklfowFluxo de Trabalho. É a sequência de passos necessários para que se possa atingir a automação de processos de negócio, de acordo com um conjunto de regras definidas, permitindo que possam ser transferidos de uma pessoa ou área à outra, por meio de regras pré-definidas.


projeto básico aquisição de solução multicanal susis/geneg

Documents