Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
REQUISITOS PARA UM SISTEMA DE INFORMAES DE UMA EMPRESA DE PEQUENO PORTE GESTORA DE RECURSOS DE TERCEIROS
Trabalho de Formatura apresentado Escola Politcnica da Universidade de So Paulo para obteno do Diploma de Engenheiro de Produo
So Paulo 2006
REQUISITOS PARA UM SISTEMA DE INFORMAES DE UMA EMPRESA DE PEQUENO PORTE GESTORA DE RECURSOS DE TERCEIROS
Trabalho de Formatura apresentado Escola Politcnica da Universidade de So Paulo para obteno do Diploma de Engenheiro de Produo
So Paulo 2006
FICHA CATALOGRFICA
Momesso Jnior, Joo Batista Requisitos para um sistema de informaes de uma empresa de pequeno porte gestora de recursos de terceiros / J.B. Momesso Jnior. -- So Paulo, 2006. p. Trabalho de Formatura - Escola Politcnica da Universidade de So Paulo. Departamento de Engenharia de Produo. 1.Sistemas de informao gerencial I.Universidade de So Paulo. Escola Politcnica. Departamento de Engenharia de Produo II.t.
AGRADECIMENTOS
A Deus pelo dom da vida e por me guiar por ela. Aos meus pais pelos exemplos de vida, pela presena amiga, pelo amor incondicional, carinho, apoio, orientao e dedicao. minha irm por se fazer presente em todos os momentos, mesmo que a distncia no permitisse. Marlia pelos momentos inesquecveis, pelo amor e confiana em mim depositados. A toda minha famlia que, mesmo em Itapira, vibrou com cada passo desta conquista. Ao pessoal da Bresser pela valiosa ajuda neste trabalho. Aos amigos de repblica que tornaram os momentos em So Paulo mais agradveis e divertidos. Aos companheiros da Poli por tornar o aprendizado mais prazeroso. Ao pessoal do CAEP pela ajuda e amizade. Aos professores pelo esforo e dedicao. Ao professor Mauro pela valiosa orientao, pacincia, e imprescindveis recomendaes ao longo deste ano. A todos meus amigos de Jundia, que sempre me acompanharam.
RESUMO
O presente Trabalho de Formatura apresenta os requisitos de um Sistema de Informaes para uma empresa de pequeno porte que se dedica ao gerenciamento de recursos de terceiros. Este sistema deve possibilitar o registro, armazenamento e atualizaes das operaes relacionadas ao gerenciamento das carteiras dos diferentes fundos de investimentos da empresa. Os Requisitos so levantados segundo a Modelagem Orientada a Objetos com a utilizao da linguagem UML. Ao longo do trabalho apresentado o problema da consolidao das informaes referentes aos ativos dos fundos de investimentos dentro da empresa, buscando identificar suas causas e, posteriormente, propor os Requisitos capazes de resolver estes problemas. Estes Requisitos so divididos em trs diferentes partes, os funcionais, definidos atravs de casos de uso, os No Funcionais e os de Interface. No final do trabalho realizada a anlise desses Requisitos, confrontando os mesmos com os problemas previamente levantados. Palavra chave: Sistema de Informao Gerencial.
ABSTRACT
The purpose of this dissertation is to present the requirements of an information system for a small company which dedicates itself to asset management. This system should allow the register, storage and updating of operations related to portfolio management of different investment funds of the Company. The requirements are captured following the Object Oriented Modeling using the UML language. Throughout this dissertation, the information consolidation problem, related to the companys asset funds, is presented in order to identify its causes and, later, allow the proposition of requirements capable of solving the problem. These requirements are divided in three different groups, the Functional Requirements, the Non-Functional Requirements and Interface Requirements. At the end of the work, an analysis on the requirements is done, confronting these with the problems previously identified. Keyword: Managerial Information System.
LISTA DE FIGURAS
FIGURA 1: FIGURA 2: FIGURA 3: FIGURA 4: FIGURA 5: FIGURA 6: FIGURA 7: FIGURA 8: FIGURA 9: FIGURA 10: FIGURA 11: FIGURA 12: FIGURA 13: FIGURA 14: FIGURA 15: FIGURA 16: FIGURA 17: FIGURA 18: FIGURA 19: FIGURA 20: FIGURA 21: FIGURA 22: FIGURA 23: FIGURA 24: FIGURA 25: FIGURA 26: FIGURA 27: FIGURA 28: FIGURA 29: FIGURA 30: FIGURA 31: FIGURA 32: ORGANOGRAMA DA EMPRESA ........................................................................... 17 REQUISITOS NO FUNCIONAIS .......................................................................... 42 APRESENTAO DE UMA CLASSE ...................................................................... 47 EXEMPLO DE RELACIONAMENTO ENTRE AS CLASSES......................................... 50 DIAGRAMA DE CASO DE USO LOGIN.................................................................. 61 DIAGRAMA DE CASO DE USO CADASTRAR FUNDO............................................ 62 DIAGRAMA DE CASO DE USO CONSULTAR POSIO DE FUNDO ........................ 63 DIAGRAMA DE CASO DE USO CONSULTAR ATIVO ............................................. 64 DIAGRAMA DE CASO DE USO CONSULTAR AO.............................................. 65 DIAGRAMA DE CASO DE USO CONSULTAR CDB ............................................... 66 DIAGRAMA DE CASO DE USO CONSULTAR TTULO PBLICO ............................ 67 DIAGRAMA DE CASO DE USO CONSULTAR TTULO PRIVADO ............................ 68 DIAGRAMA DE CASO DE USO CONSULTAR ALUGUEL........................................ 69 DIAGRAMA DE CASO DE USO CONSULTAR PROVENTO ...................................... 70 DIAGRAMA DE CASO DE USO CONSULTAR CONTRATO FUTURO ....................... 71 DIAGRAMA DE CASO DE USO CONSULTAR CAIXA............................................. 72 DIAGRAMA DE CASO DE USO CADASTRAR ATIVO............................................. 73 DIAGRAMA DE CASO DE USO CADASTRAR AO ............................................. 74 DIAGRAMA DE CASO DE USO CADASTRAR CDB............................................... 75 DIAGRAMA DE CASO DE USO CADASTRAR TTULO PBLICO ............................ 76 DIAGRAMA DE CASO DE USO CADASTRAR TTULO PRIVADO ............................ 77 DIAGRAMA DE CASO DE USO CADASTRAR PROVENTO...................................... 78 DIAGRAMA DE CASO DE USO CADASTRAR CONTRATO FUTURO ....................... 79 DIAGRAMA DE CASO DE USO MOVIMENTAR ATIVO .......................................... 80 DIAGRAMA DE CASO DE USO CADASTRAR MOVIMENTAR AO ...................... 81 DIAGRAMA DE CASO DE USO MOVIMENTAR CDB ............................................ 82 DIAGRAMA DE CASO DE USO MOVIMENTAR TTULO PBLICO ......................... 83 DIAGRAMA DE CASO DE USO MOVIMENTAR TTULO PRIVADO ......................... 84 DIAGRAMA DE CASO DE USO MOVIMENTAR ALUGUEL..................................... 85 DIAGRAMA DE CASO DE USO MOVIMENTAR CONTRATO FUTURO .................... 86 DIAGRAMA DE CASO DE USO AJUSTAR CAIXA .................................................. 87 DIAGRAMA DE CASO DE USO ATUALIZAR CARTEIRA........................................ 88
FIGURA 33: FIGURA 34: FIGURA 35: FIGURA 36: FIGURA 37: FIGURA 38: FIGURA 39: FIGURA 40: FIGURA 41: FIGURA 42: FIGURA 43: FIGURA 44: FIGURA 45: FIGURA 46: FIGURA 47: FIGURA 48: FIGURA 49: FIGURA 50: FIGURA 51: FIGURA 52:
DIAGRAMA DE CASO DE USO ATUALIZAR BROADCAST .................................... 89 DIAGRAMA DE CASO DE USO ATUALIZAR BLOOMBERG.................................... 90 DIAGRAMA DE CASO DE USO ATUALIZAR MANUAL ......................................... 91 TELA INICIAL ..................................................................................................... 95 TELA SELECIONAR FUNDO............................................................................. 96 TELA ATIVOS POR FUNDO.............................................................................. 97 TELA: MOVIMENTAR AO........................................................................... 98 CLASSES CANDIDATAS ...................................................................................... 99 GENERALIZAO DE CLASSES ......................................................................... 100 CLASSE AO ................................................................................................. 101 CLASSE ALUGUEL DE AO ............................................................................ 103 CLASSE TTULO PBLICO ................................................................................ 105 CLASSE TTULO PRIVADO ............................................................................... 107 CLASSE CDB................................................................................................... 109 CLASSE CONTRATO FUTURO ........................................................................... 111 CLASSE PROVENTO ......................................................................................... 113 CLASSE CAIXA ................................................................................................ 115 CLASSE FUNDO ............................................................................................... 118 DIAGRAMA DE CLASSES E RELACIONAMENTOS ATIVOS ................................ 121 DIAGRAMA DE CLASSES E RELACIONAMENTOS CAIXA.................................. 123
LISTA DE TABELA
TABELA 1: CRTICAS AO SISTEMA DE INFORMAES ATUAL .................................................... 59
SUMRIO
INTRODUO..............................................................................14
1.3.1 O Estgio .............................................................................................................. 19 1.3.2 Fatores Crticos de Sucesso para a empresa......................................................... 19 1.3.2.1 O Sistema de Informaes como um fator crtico de sucesso...................... 21 1.3.3 Estrutura de Informtica....................................................................................... 22 1.3.4 Organizao das Informaes .............................................................................. 23 1.4 1.5 LEVANTAMENTO DE INFORMAES .......................................................................... 24 ALGUNS CONCEITOS IMPORTANTES ........................................................................... 25 REVISO BIBLIOGRFICA ........................................................28
2.2.1 Classificao dos Sistemas de Informaes ......................................................... 30 2.3.1 Modelagem Orientada a Objetos.......................................................................... 33 2.3.2 UML..................................................................................................................... 34 2.3.3 Modelo de Objetos ............................................................................................... 36 2.3.3.1 2.3.3.2 2.3.3.3 2.3.3.4 2.3.3.5 2.3.4.1 CAPTULO 3 3.1 3.2 Casos de Uso ................................................................................................ 36 Atores ........................................................................................................... 37 Diagramas de Casos de Uso......................................................................... 38 Captura de Requisitos .................................................................................. 38 Diagrama de classes ..................................................................................... 45 Diagrama de Seqncia................................................................................ 51 SITUAO ATUAL ......................................................................52
CAPTULO 4 4.1
APLICAO DO MODELO..........................................................60
4.1.1 Login .................................................................................................................... 61 4.1.2 Cadastrar Fundo ................................................................................................... 62 4.1.3 Consultar Posio de Fundo................................................................................. 63 4.1.4 Consultar Ativo .................................................................................................... 64 4.1.5 Consultar Ao..................................................................................................... 65 4.1.6 Consultar CDB ..................................................................................................... 66 4.1.7 Consultar Ttulo Pblico ...................................................................................... 67 4.1.8 Consultar Ttulo Privado ...................................................................................... 68 4.1.9 Consultar Aluguel ................................................................................................ 69 4.1.10 Consultar Provento............................................................................................... 70 4.1.11 Consultar Contrato Futuro.................................................................................... 71 4.1.12 Consultar Caixa.................................................................................................... 72 4.1.13 Cadastrar Ativo .................................................................................................... 73 4.1.14 Cadastrar Ao ..................................................................................................... 74 4.1.15 Cadastrar CDB ..................................................................................................... 75 4.1.16 Cadastrar Ttulo Pblico ...................................................................................... 76 4.1.17 Cadastrar Ttulo Privado ...................................................................................... 77 4.1.18 Cadastrar Provento ............................................................................................... 78 4.1.19 Cadastrar Contrato Futuro.................................................................................... 79 4.1.20 Movimentar Ativo................................................................................................ 80 4.1.21 Movimentar Ao................................................................................................. 81 4.1.22 Movimentar CDB................................................................................................. 82 4.1.23 Movimentar Ttulo Pblico .................................................................................. 83 4.1.24 Movimentar Ttulo Privado.................................................................................. 84 4.1.25 Movimentar Aluguel ............................................................................................ 85 4.1.26 Movimentar Contrato Futuro ............................................................................... 86 4.1.27 Ajustar Caixa........................................................................................................ 87 4.1.28 Atualizar Carteira ................................................................................................. 88 4.1.29 Atualizar Broadcast .............................................................................................. 89 4.1.30 Atualizar Bloomberg............................................................................................ 90 4.1.31 Atualizar Manual.................................................................................................. 91 4.2 REQUISITOS NO FUNCIONAIS .................................................................................. 92
4.3 4.4
4.4.1 Generalizao de classes semelhantes ................................................................. 99 4.4.2 Classes Refinadas............................................................................................... 100 4.4.2.1 4.4.2.2 4.4.2.3 4.4.2.4 4.4.2.5 4.4.2.6 4.4.2.7 4.4.2.8 4.4.2.9 Classe Ao ................................................................................................ 101 Classe Aluguel de Ao ............................................................................. 103 Classe Ttulo Pblico ................................................................................. 105 Classe Ttulo Privado ................................................................................. 107 Classe CDB ................................................................................................ 109 Classe Contrato Futuro............................................................................... 111 Classe Provento.......................................................................................... 113 Classe Caixa ............................................................................................... 115 Classe Fundo .............................................................................................. 118
4.4.3 Relacionamento entre as classes ........................................................................ 120 4.4.4 Diagrama de classes ........................................................................................... 120 CAPTULO 5 5.1 ANLISE E DISCUSSO ..........................................................125
CONCLUSO
BIBLIOGRAFIA ....................................................................................................131
14
CAPTULO 1
INTRODUO
15 confivel. Deste modo, foi identificado que a especificao e a construo de um novo Sistema de Informaes so de extrema importncia para o melhor desempenho dos Fundos de Investimentos e por conseqncia da empresa. Buscando atingir o objetivo de uma futura construo de um novo Sistema de Informaes, este trabalho de formatura versa sobre os requisitos deste Sistema de Informaes capaz de gerenciar os Fundos de Investimentos da Bresser Administrao de Recursos. O desenvolvimento do trabalho feito de maneira a inicialmente introduzir a Empresa, sua organizao, os papis de seus colaboradores. Em seguida apresentado o Mercado no qual a mesma est inserida, levando a serem levantados os fatores crticos de sucesso para a companhia. Aps este levantamento, situada a questo das Informaes, sua acessibilidade e importncia para a Empresa. Na seqncia realizada a discusso sobre os fundamentos tericos acerca do tema do trabalho. Esta discusso abarca a Modelagem Orientada a Objetos e a linguagem UML (Unified Modeling Language), utilizada para desenvolver e representar essa modelagem. No captulo seguinte so feitas uma sucinta apresentao e posterior anlise do Sistema de Informaes atual, possibilitando que no captulo subseqente seja iniciada a realizao da captura dos requisitos, segundo metodologia levantada, para o Sistema de Informaes a ser desenvolvido visando melhorar o sistema atual. Dando continuidade ao trabalho, so levantados os requisitos funcionais, no funcionais e de interface do sistema. Posteriormente realizada uma anlise desses requisitos levantados, ressaltando as caractersticas do novo sistema e culminando com a concluso do trabalho.
16
17
1.3 A Empresa
A Bresser Administrao de Recursos foi fundada em outubro de 2001 e se dedica administrao de recursos de terceiros por meio de fundos de investimentos. O portiflio de produtos da empresa composto por cinco desses fundos sendo dois deles locais, ou seja, sediados no Brasil e trs deles off-shore, ou seja, com sede fora do pas. A Bresser Administrao de Recursos, nesse setor, pode ser considerada uma empresa de pequeno porte, sendo que atualmente, administra, nesses cinco diferentes fundos, certa de 160 milhes de Reais, tendo como cotistas clientes corporativos bem como pessoas fsicas em geral. A estrutura da empresa bastante enxuta e hoje conta com trs scios, dois funcionrios e dois estagirios. Dada essa estrutura, alguns servios so terceirizados como o servio de limpeza, contabilidade e departamento jurdico. Os servios de Administrao dos Fundos e custdia dos mesmos so tambm terceirizados sendo as empresas Mellon Brasil e Ita responsveis respectivamente por essas reas.
O papel de cada um dos colaboradores da empresa (scios, funcionrios e estagirios) no rigidamente definido sendo que todos desenvolvem diversas funes dentro da empresa.
18 O scio fundador e principal scio da empresa responsvel por toda a gesto dos fundos. ele quem traa a estratgia da empresa, que se desdobra nas estratgias dos fundos de investimentos e quem em ltima instncia opta por quais operaes devem ser executadas e o momento em que as mesmas devem ocorrer. Cabe a ele tambm o papel de principal contato comercial da empresa, uma vez que sua ampla experincia no Mercado Financeiro e renome fazem com que muitos clientes institucionais ou pessoas fsicas sejam atrados a investir nos fundos de investimentos da empresa. Ao segundo scio, que no trabalho identificado como Analista Snior, cabe a anlise das conjunturas poltico-econmicas locais e mundiais, a anlise de alguns setores de empresas listadas na Bolsa de Valores de So Paulo (BOVESPA) e finalmente, a funo de coordenar toda parte operacional da empresa. O terceiro scio, que no trabalho identificado como Analista Jnior, responsvel basicamente por anlises de alguns setores de empresas listadas na BOVESPA. importante ressaltar que as anlises realizadas por ambos os Analistas constituem as principais ferramentas de apoio deciso do Gestor o que as tornam extremamente importante para a boa gesto dos fundos de investimentos da empresa. O Estagirio 2 tem como principal tarefa o suporte operacional. ele o responsvel pela boletagem das operaes de renda varivel e ndices, isto , ele que documenta as operaes de compra e venda de aes e de contratos futuros, sejam eles de dlar, ndice ou juros. Cabe a ele ainda fechar e conferir as carteiras dos fundos off-shore. Como funo de auxlio Gesto, o estagirio 2 responsvel pelo gerenciamento de riscos da carteira dos fundos de investimentos. O funcionrio 1 responsvel pelo fechamento e por conferir as carteiras dos fundos locais, por boletar as operaes de aluguis de aes e renda fixa. Cabe a ele tambm a administrao dos pagamentos da Empresa e o contato da empresa com as empresas Terceiras que so responsveis por algumas operaes terceirizadas da empresa como Contabilidade e Apoio na rea de Informtica.
19 O funcionrio 2, identificado no trabalho como Assistente, responsvel por assessorar o Gestor exercendo a funo de secretaria, gerenciando sua agenda. responsvel ainda por atender clientes.
1.3.1 O Estgio
O papel do autor na empresa como Estagirio 1 de apoio tanto ao Gestor como ao Analista Snior. So suas responsabilidades a elaborao de relatrios que exploram os fundos concorrentes bem como o Mercado de maneira geral. O autor executa as operaes relacionadas renda fixa (CDB, Ttulos Pblicos, Ttulos Privados etc), bem como operaes envolvendo Aluguis de Aes. Na parte de apoio operacional, so realizadas conciliaes que objetivam a eliminao de erros que eventualmente ocorrem nos controles da empresa. Apesar de a tarefa principal do estgio dentro da empresa no estar diretamente ligada ao sistema de informao a ser proposto, o bom funcionamento do mesmo vai permitir que as conciliaes ocorram em menor nmero e de maneira mais rpida, fazendo com que as atividades sejam mais produtivas e seja disponibilizado mais tempo do estgio para o desenvolvimento de tarefas que agreguem maior conhecimento que conferir dados em diferentes planilhas buscando encontrar o motivo de uma eventual diferena. Por outro lado, o desenvolvimento do modelo de requisitos representa um desafio de compreenso, reflexo e abstrao dos processos em uso na organizao, alm da aplicao de conhecimentos adquiridos no curso de Engenharia de Produo.
20 Performance. Em um cenrio otimista, as pessoas tendem a diversificar mais seus investimentos, ficando propensas a investir suas economias em investimentos de maiores riscos buscando maiores retornos. Como os fundos gerenciados pela Empresa possuem um risco maior que investimentos tradicionais de Renda Fixa tais como investimentos em CDB e Caderneta de Poupana, um horizonte otimista pode refletir em maiores aportes nos fundos. Por outro lado, num cenrio de maior volatilidade e incerteza, grande parte das pessoas tende a buscar fundos de investimentos que tenham uma menor exposio a oscilaes da Economia em geral, da Bolsa de Valores, enfim dos diversos componentes do Mercado Financeiro que compem, tradicionalmente, o portiflio de um fundo de investimentos em Renda Varivel. Por outro lado, o segmento do qual a Empresa faz parte caracterizado pelo grande nmero de empresas concorrentes e todos esses players se caracterizam pela grande capacidade tcnica o que torna o mercado muito competitivo. A escolha do investidor de aplicar seus recursos em um fundo ou em outro pode se dar de diversas maneiras, mas, sobretudo se d pelo desempenho histrico que os diversos fundos de investimentos apresentam. Deste modo, estar entre os melhores fundos do mercado muito importante para que um fundo consiga um maior nmero de investidores. Este melhor desempenho obtido por uma combinao de fatores, mas principalmente, por meio de uma boa gesto que por sua vez se d, obviamente, devido ao conhecimento do funcionamento do Mercado Financeiro e seu comportamento, mas tambm da possibilidade de utilizao das melhores ferramentas de apoio s decises, neste caso, as melhores informaes.
21
22
Hardware
A Bresser conta com nove computadores pessoais, conectados em uma LAN (Local Area Network), sendo um dos computadores utilizado como servidor de rede. Outro computador usado como servidor para acesso Internet. Neste computador est instalado um Firewall, que responsvel pela proteo da rede interna contra a entrada de intrusos. Os computadores tm configuraes diferentes. Dependendo do computador a velocidade do clock varia de 1300 Hz at 3 GHz, sendo que o tamanho da memria RAM vai de 256 MB a 2 GB.
Software
Todas as mquinas so equipadas com o Microsoft Windows 2000 e com o pacote Office 2002 da Microsoft, que inclui Microsoft Word, Microsoft Excel, Microsoft PowerPoint e Microsoft Access. Algumas mquinas so equipadas com o Broadcast, software da Agncia Estado que permite a visualizao das cotaes dos mais diferentes ativos financeiros em tempo real, bem como a leitura de notcias que so atualizadas constantemente. Existe, ainda, um software chamado Economtica que est instalado em todas as mquinas e que tem a funo de guardar todos os dados histricos dos ativos do Mercado Financeiro. Este software pode ser atualizado todos os dias, entretanto no disponibiliza as cotaes em tempo real. Adicionalmente, existe instalada uma estao que destinada ao uso do terminal Bloomberg, terminal este que, a exemplo do Broadcast, permite a visualizao em tempo real de cotaes de diversos ativos financeiros e prove notcias. Entretanto, o Bloomberg possui uma gama maior de funes
23 disponibilizando praticamente todas as informaes que abarcam o contexto do Mercado Financeiro e suas operaes.
24
25
26 Liquidao Financeira de Ttulos. Referncia do custo do dinheiro de um dia, negociado no mercado interbancrio. Dividendo: Valor distribudo aos acionistas como participao nos resultados da companhia. distribudo em dinheiro e seu valor proporcional quantidade de aes possudas pelo acionista. Fundo de Investimento: Entidade financeira, que pela emisso de ttulos de investimento prprio, denominado cota, concentra capitais de inmero investidores para aplicao em carteiras diversificadas de ttulos, valores mobilirios, instrumentos financeiros, derivativos, ou commodities negociadas em bolsas de mercadorias e futuros. Fundo de Investimento em Aes: Fundo de Investimento que possui como estratgia basicamente a alocao de recursos na compra e venda de aes. Fundo de Investimento Multimercado: Fundo de Investimento que busca retorno no longo prazo, possuindo como estratgia a alocao de parte dos recursos em Renda Fixa e parte dos recursos em Renda Varivel. FIDC - Fundo de Investimento em Direitos Creditrios: Tambm conhecidos como Fundo de Recebveis, so os direitos e ttulos representativos de crdito, originrios de operaes realizadas nos segmentos financeiro, comercial, industrial, imobilirio, de hipotecas, de arrendamento mercantil e de prestao de servios. Juros de capital prprio: Forma de remunerao ao acionista da empresa, originado pelo lucro retido em perodos anteriores.
27 Nessa categoria se encontram os Ttulos Pblicos e os Ttulos Privados tais como Debntures, FIDC e CDB. Renda Varivel: Tipo de aplicao na qual a rentabilidade no contratada e depende da cotao nos mercados organizados. Taxa de Administrao: Taxa cobrado pelo administrador do recurso para administrar fundos e clubes de investimentos. Est prevista no regulamento do Fundo ou do Clube. Taxa de Performance: Remunerao cobrada pelo administrador de carteira ou de fundo de investimento, em funo da performance da carteira. Normalmente cobrada sobre o que exceder determinado parmetro, fixado em norma legal, contrato de administrao ou regulamento do fundo.
28
CAPTULO 2
REVISO BIBLIOGRFICA
Este captulo apresenta uma reviso bibliogrfica envolvendo os principais temas que embasam o desenvolvimento da soluo proposta. Esta reviso, busca ser abrangente e composta por obras de relevncia cientfica, visando fornecer o embasamento terico para que posteriormente possa ser realizado o trabalho propriamente dito. Desta maneira a elaborao desta reviso bibliogrfica busca abarcar todos os conceitos que sero desenvolvidos e utilizados ao logo do trabalho de formatura, desde o conceito de Informao at o detalhamento do Modelo a ser utilizado.
2.1 A Informao
A partir da dcada 80 ocorreu uma grande massificao do uso de computadores por parte das pessoas. Esta difuso aliada ao rpido avano tecnolgico em todas as reas do conhecimento e a intensa globalizao fez com a informao se tornasse ainda mais importante do ponto de vista estratgico do que at ento. Deste modo, ser o detentor das informaes tornou-se possuir uma grande vantagem competitiva em relao a concorrentes ao ponto de hoje em dia, a informao ser considerada seno o mais importante, pelo menos um dos recursos cuja gesto e aproveitamento esto diretamente relacionados com o sucesso desejado (Moresi, 2000). Entretanto, deve-se atentar ao grau de relevncia das informaes, pois somente com informaes precisas e na hora certa, os administradores podem monitorar o progresso na direo de seus objetivos e transformar os planos em realidade (Stoner, Freeman, 1999). Portanto, antes de comear o aprofundamento no tema de Sistema de Informaes necessrio que sejam analisados os componentes que compem o mesmo. Mais diretamente, preciso, antes de analisar o Sistema de Informaes, ter uma idia clara do que seja uma informao. Segundo Dalfovo e Amorim (2000), informao o dado trabalhado que permite ao executivo tomar decises, enquanto dado qualquer elemento
29 identificado em sua forma bruta que por si s no conduz a uma compreenso de determinado fato ou situao. Stair (1998) segue na mesma linha e define dados como fatos em sua forma primria e informao como sendo um conjunto de fatos organizados de tal forma que adquirem valor adicional, alm do valor do fato em si. Deste modo a informao algo imensurvel dentro de uma organizao e seu valor est diretamente ligado maneira como ela ajuda os tomadores de decises a atingirem as metas da organizao. Neste contexto encaixa-se a definio adaptada de Alter (1996) que define Sistema de Informaes como sendo um conjunto integrado de recursos (humanos e tecnolgicos) cujo objetivo satisfazer adequadamente as necessidades de informao de uma organizao e os respectivos processos de negcios.
30
31 modificar dados armazenados num Sistema de Informaes. So Sistemas de Informaes bsicos, voltados para o nvel operacional da organizao; - Sistema de Automao de Escritrio (SAE): ajuda as pessoas a processarem documentos e fornece ferramentas que tornam o trabalho no escritrio mais eficiente e eficaz. Tambm pode definir a forma e o mtodo para executar as tarefas dirias e dificilmente afeta as informaes em si. Exemplos deste tipo de sistema so editores de texto, planilhas de clculo, softwares para correio eletrnico e outros; - Sistema de Informaes Gerencial (SIG): converte os dados de uma transao do SPT em informao para gerenciar a organizao e monitorar o desempenho da mesma. Ele enfatiza a monitorao do desempenho da empresa para efetuar as devidas comparaes com as suas metas. Este tipo de sistema orientado para a tomada de decises estruturadas, onde os dados so coletados internamente na organizao, baseando-se somente nos dados corporativos existentes e no fluxo de dados. A caracterstica dos Sistemas de Informaes gerenciais utilizar somente dados estruturados, que tambm so teis para o planejamento de metas estratgicas; - Sistemas Especialistas (SE): tornam o conhecimento de especialistas disponvel para outros e ajudam a resolver problemas de reas onde o conhecimento de especialistas necessrio. Eles podem guiar o processo de deciso e assegurar que os fatores chave sero considerados e tambm podem ajudar uma empresa a tomar decises consistentes. Um sistema especialista pode ser, por exemplo, um sistema no qual mdicos dizem os sintomas e so pesquisados em uma base de conhecimento os possveis diagnsticos. - Sistema de Apoio Deciso (SAD): ajuda as pessoas a tomarem decises, provendo informaes, padres ou ferramentas para anlise de informaes. Os maiores usurios so os analistas e gerentes. Um sistema de apoio deciso d apoio e assistncia em todos os aspectos da tomada de decises sobre um problema especfico. So sistemas voltados para administradores, tecnocratas especialistas, analistas e tomadores de deciso, sendo de acesso rpido, interativos e orientados para ao imediata;
32 - Sistema de Informaes para Executivos (SIE): fornece informaes aos executivos de uma forma rpida e acessvel, sem forar os mesmos a pedirem ajuda a especialistas em anlise de informaes. utilizado para estruturar o planejamento da organizao e o controle de processos, e pode eventualmente, tambm, ser utilizado para monitorar o desempenho da empresa. voltado para os administradores com pouco contato com Sistemas de Informaes automatizados. As caractersticas deste tipo de sistema consistem em combinar dados internos e externos, na utilizao de menus grficos, no acesso a banco de dados internos e externos e os dados so mostrados nos relatrios impressos de forma comprimida, existindo, portanto, informaes prontamente acessveis, de forma interativa. Entretanto, segundo Machado (1996), devido s mudanas pelas quais as organizaes passaram nos ltimos anos estas seis partes se transformaram em apenas duas, cabendo agora a seguinte diviso: - OLTP (On Line Transaction Processing) que englobaria os dois primeiros nveis do modelo de Alter (SPT e SAE) tendo como caracterstica principal a configurao para prover respostas rpidas a transaes individuais, uma vez que se trata de um sistema bastante dinmico no qual as informaes se alteram rapidamente. - OLAP (On Line Analytic Processing), que englobaria os demais nveis e tendo como caracterstica a no relevncia da velocidade das transaes, pois os Sistemas de Informaes baseados em OLAP podem armazenar os dados de forma esttica e so configurados e otimizados para suportarem complexas decises baseadas em dados histricos.
33
34 A viso contempornea no desenvolvimento de software adota uma perspectiva orientada a objetos. Nessa viso, o principal bloco de construo de todos os sistemas de software o objeto ou a classe. De maneira bastante simples, pode-se definir objeto como alguma coisa geralmente estruturada a partir do vocabulrio do espao do problema ou do espao da soluo. J uma classe seria a descrio de um conjunto de objetos comuns. Todo objeto tem uma identidade (podem lhes ser atribudos nomes ou diferenci-los dos demais objetos de alguma maneira), um estado (geralmente h dados a eles associados) e um comportamento (voc poder fazer algo com o objeto ou ele poder fazer algo com outros objetos). Ainda segundo os mesmos autores, o mtodo orientado a objetos para o desenvolvimento de software vem prevalecendo, pois conseguiu provar seu valor para construo de sistemas de todos os tipos de domnios de problemas, abrangendo todos os graus de tamanho e de complexidade. Soma-se a isso o fato de muitas linguagens, sistemas operacionais e ferramentas contemporneas serem, de alguma forma, orientados a objetos, corroborando com a idia de enxergar o mundo em termos de objetos.
2.3.2 UML
Diversas so as linguagens para elaborao da estrutura de projetos de software dentre as quais se pode ressaltar a Unified Modeling Language (UML). Criada em 1977, esta linguagem padro empregada para a visualizao, a especificao, a construo e a documentao de artefatos que faam uso de sistemas complexos de software. Apesar de a UML ser adequada para modelagem de uma gama muito grande de diferentes sistemas, abrangendo desde Sistemas de Informaes corporativos a serem distribudos aplicaes baseadas em Web at sistemas complexos embutidos de tempo real, no difcil compreender e usar a UML.
35 Visualizao Segundo Booch; Rumbaugh e Jacobson (2000), com a UML, busca-se que a documentao do processo de criao de um software seja padronizada fazendo com que seja facilitada a comunicao entre as pessoas e com que os modelos possam ser entendidos por outras pessoas que no tenham necessariamente acesso pessoa que idealizou a lgica do sistema. Por trs de cada smbolo empregado na notao UML existe uma semntica bem definida, sendo possvel, portanto, que um desenvolvedor possa usar UML para escrever seu modelo e qualquer outro desenvolvedor seja capaz de compreend-lo sem ambigidades. Especificao Especificar significa construir modelos precisos, sem ambigidades e completos. A UML atende a todas as decises importantes em termos de anlise, projeto e implementao, que devem ser tomadas para o desenvolvimento e implantao de sistemas complexos de software. Construo Os modelos baseados em UML podem ser diretamente conectados a vrias linguagens de programao tais como Java, C++, Visual Basic. Alm disso, a UML suficientemente expressiva e sem ambigidades para permitir a execuo direta dos modelos, a simulao de sistemas e a instrumentao de sistemas em execuo. Documentao A UML abrange a documentao da arquitetura do sistema e de todos os seus detalhes. A UML proporciona tambm uma linguagem para a expresso de requisitos e para a realizao de testes. Por fim, a UML oferece uma linguagem para a modelagem das atividades de planejamento do projeto e de gerenciamento de verses.
36
37
2.3.3.2 Atores
Utilizam-se os atores para modelar os usurios do produto. Cada ator representa uma classe de usurios. Assim, os atores modelam os papis e no as pessoas dos usurios. Segundo Paula Filho (2001), os atores podem ser identificados atravs dos seguintes critrios: - quem est interessado em certo requisito; - quem se beneficiar diretamente do produto; - que usar informao do produto; - quem fornecer informao ao produto; - quem remover informao do produto; - quem dar suporte e manuteno ao produto; - quais os recursos externos usados pelo produto; - quais os papis desempenhados por cada usurio; - quais os grupos de usurios que desempenham o mesmo papel; - quais os sistemas legados com os quais o produto deve interagir; - o tempo, quando Casos de Uso so disparados periodicamente, de forma automtica.
38
39 chamado de especificao funcional, deve ser preciso. Ele pode servir como um contrato entre o comprador do sistema e o desenvolvedor do software. Geralmente, os requisitos do usurio so escritos para profissionais que no tenham um conhecimento tcnico detalhado do Sistema, enquanto a especificao de requisitos de sistema deve ter como alvo os profissionais tcnicos de nvel superior e gerentes de projeto. Essa busca de requisitos deve ser uma tarefa conjunta do desenvolvedor do sistema e do cliente que passar a utiliz-lo, cabendo a este segundo, transmitir ao primeiro o desenho das interfaces dos usurios, bem como o escopo do Sistema. Segundo Paula Filho (2001), de maneira geral, nem desenvolvedores nem clientes ou usurios so qualificados para escrever por si ss a Especificao dos Requisitos do Software, porque: -os clientes nem sempre entendem os processos de desenvolvimento de software em grau suficiente para produzir uma especificao de requisitos de implementao vivel; -os desenvolvedores nem sempre entendem a rea de aplicao de forma suficiente para produzir uma especificao de requisitos satisfatria. Ambos os envolvidos devem trabalhar de maneira sincronizada, pois podem ocorrer grandes perdas e retrabalhos quando os clientes e usurios trazem novos requisitos em fases adiantadas do desenvolvimento do sistema. A necessidade de se estabelecer os requisitos de forma precisa crtica uma vez que o tamanho e a complexidade do software aumentam com a adio de novos requisitos. Os requisitos exercem influncia uns sobre os outros. Portanto, de extrema importncia que apenas os requisitos que realmente sejam relevantes estejam presentes. Os Requisitos de Sistema de Software so freqentemente divididos em dois tipos, os funcionais e os no funcionais, muito embora Paula Filho (2001) ainda acrescente um terceiro tipo, os requisitos de interface.
40
Requisitos Funcionais
Segundo Sommerville (1993), os requisitos funcionais so declaraes que o sistema deve fornecer, como o sistema deve reagir a entradas e como deve se comportar em determinadas situaes. Em alguns casos, os requisitos funcionais podem tambm explicitamente declarar o que o sistema no deve fazer. Eles definem a funcionalidade desejada do software. O termo funo usado no sentido genrico de operao que pode ser realizada pelo sistema, seja atravs de comandos dos usurios, ou pela ocorrncia de eventos internos ou externos ao sistema. A especificao de um requisito funcional deve determinar o que se espera que o software faa, sem a preocupao de como ele faz. importante diferenciar a atividade de especificar requisitos da atividade de especificao que ocorre durante o design do software. No design do software deve-se tomar a deciso de quais as funes o sistema efetivamente ter para satisfazer aquilo que os usurios querem. Quando expressos como requisitos de usurio, eles normalmente so descritos de modo geral, mas os requisitos funcionais de sistema descrevem a funo de sistema detalhadamente, suas entradas e sadas, excees etc. Deve-se tomar cuidado para que os requisitos sejam especificados com clareza para que seja diminuda a chance de ocorrer alguma ambigidade levando a algum problema de engenharia de software. Alm disso, a especificao de requisitos funcionais de um sistema deve ser completa e consistente. Por especificao completa, entende-se que os requisitos devam cobrir todas as funes solicitadas pelo usurio e por consistentes, entende-se que os requisitos no devam apresentar definies contraditrias. Entretanto, no fcil para sistemas grandes e complexos garantir essa completeza e consistncia, por isso necessrio que seja feita uma anlise profunda que vise aprimorar estes requisitos por meio da melhoria contnua.
41
Requisitos No Funcionais
Requisitos no funcionais, como o prprio nome diz, so aqueles requisitos que no dizem respeito diretamente s funes especficas fornecidas pelo Sistema. So as qualidades globais de um software, que podem estar relacionadas a propriedades de sistema emergentes, como confiabilidade, tempo de resposta e espao em disco. Os requisitos no funcionais podem dizer respeito no a uma caracterstica individual do sistema e sim ao sistema como um todo. Deste modo, o descumprimento de um requisito no funcional pode tornar todo o sistema intil (Sommerville, 2003). Estes requisitos surgem da situao de contorno que vive o cliente como restries de oramento, polticas organizacionais, necessidade de interoperabilidade com outros sistemas de software ou hardware ou mesmo devido a fatores externos como regulamentos de segurana e legislao sobre privacidade. Segundo Sommerville (2003), os requisitos no funcionais podem ser classificados, de acordo com sua procedncia, em trs categorias: -Requisitos de produtos. So os requisitos que especificam o comportamento do produto. Entre os exemplos esto os requisitos de desempenho sobre com que a rapidez o sistema deve operar e quanta memria ele requer, os requisitos de confiabilidade, que estabelecem a taxa aceitvel de falhas, os requisitos de portabilidade e os requisitos de facilidade de uso. -Requisitos organizacionais. So procedentes de polticas e procedimentos nas organizaes do cliente e do desenvolvedor. Entre os exemplos esto os padres de processo que devem ser utilizados, os requisitos de implementao, como linguagem de programao ou o mtodo de projeto utilizado e os requisitos de fornecimento, que especificam quando o produto e seus documentos devem ser entregues.
42 -Requisitos externos. Esse amplo tpico abrange todos os requisitos procedentes de fatores externos ao sistema e a seu processo de desenvolvimento. Dentre eles destacam-se os requisitos de interoperabilidade, que definem como o sistema interage com sistemas em outras organizaes, os requisitos legais, que devem ser seguidos para assegurar que o sistema opera de acordo com a lei, e os requisitos ticos. Os requisitos ticos so definidos em um sistema para garantir que este ser aceitvel para seus usurios e o pblico em geral Na figura 2 apresentada a classificao dos diferentes tipos de requisitos no funcionais que podem surgir.
Requisitos no funcionais
Requisitos do produto
Requisitos organizacionais
Requisitos externos
Requisitos de eficincia
Requisitos de confiablidade
Requisitos de portabilidade
Requisitos de interoperabilidade
Requisitos ticos
Requisitos de entrega
Requisitos de implementao
Requisitos de padres
Requisitos legais
Requisitos de desempenho
Requisitos de espao
Requisitos de privacidade
Requisitos de segurana
Muitas vezes os requisitos no funcionais so descritos de maneira informal, de maneira controversa e so difceis de validar. possa chegar mais facilmente ao objetivo de cumpri-los. Outra questo a que se deve atentar que freqentemente existem conflitos entre dois ou mais requisitos no funcionais, uma vez que em diversas situaes exige-se que o sistema execute suas operaes sob condies mutuamente Entretanto, de extrema importncia que se busquem mtricas para quantificar os requisitos para que se
43 excludentes como, por exemplo, que o sistema realize todas as operaes em 1 segundo e que o sistema seja desenvolvido numa plataforma mais lenta. Desta maneira, pode-se dizer que os requisitos no funcionais devem ser analisados cuidadosamente para que no seja cometido nenhum excesso quanto definio do mesmo.
Requisitos de Interface
Segundo Paula Filho (2001), os requisitos de interface podem ser divididos em dois tipos, as interfaces genricas e as interfaces grficas do usurio. As interfaces genricas levantam, de forma detalhada, todos os requisitos referentes a entradas e sadas do produto. No s incluem arquivos de trabalho usados apenas pelo produto, as interfaces externas, mas tambm qualquer tipo de dados partilhados com outros produtos e componentes de sistema. Assim, se uma interface externa, ela faz parte do problema, e, portanto deve fazer parte dos requisitos. Neste requisito indicam-se o contedo e o formato dos seguintes elementos de cada interface, quando aplicveis: -Fonte de entrada; -Destino de sada; -Relacionamentos com outras interfaces; -Formato. J na interface grfica do usurio so levantadas questes referentes a requisitos de produtos tais como formatos de dados e comando. Outros detalhes, como formatos de telas e janelas, so aspectos de desenho da interface do usurio. De qualquer forma, recomendada, quando do levantamento dos requisitos, a elaborao de esboos grficos de interface, j que esses esboos ajudam a identificar mais claramente os requisitos, e muitas vezes resultam naturalmente de atividades de prototipagem usadas para realizar a engenharia de requisitos. Ao se
44 incluir estes esboos se subentende que estes representam sugestes, cabendo o desenho definitivo ser dado dentro do fluxo de Desenho. Ainda segundo Paula Filho (2001), estes esboo podem ser apresentados das mais diferentes formas: -Desenhos a mo livre em papel; -Layouts alfanumricos grosseiros, feitos com um editor de texto; -Layouts feitos com um editor de pginas da Web; -Desenhos feitos com uma ferramenta de desenho tcnico; -Telas desenhadas em um ambiente de desenvolvimento rpido; -Telas desenhadas no ambiente definitivo de implementao. Os campos e comando includos em cada interface de usurio (desenhos e layouts) devem representar requisitos de captura e exibio de informao. Durante a etapa de Fluxo de Desenho, eles podero ser substitudos por solues com funcionamento equivalentes.
45
Classes
Classes de objetos so os blocos de construo mais importantes de um sistema orientado a objetos. Uma classe de objetos uma descrio de um conjunto de objetos que compartilham os mesmos atributos, operaes, relacionamentos e semntica. Neste trabalho, como em muitos outros, a palavra classe utilizada no lugar de classe de objeto. Segundo Paula Filho (2001), as classes podem ser identificadas pela anlise do fluxo dos Casos de Uso. Esta anlise se d, entre outras maneiras, utilizando-se o seguinte critrio: -Identificar as entidades tangveis e papis que essas desempenham; -Identificar objetos que so necessrios para contemplar os Casos de Uso; -Identificar as responsabilidades, o conhecimento e as aes providas por cada classe;
46 -Listar as classes que colaboram para o cumprimento das responsabilidades. Ao seguir este critrio, as responsabilidades identificadas representam o conhecimento e as aes que possibilitam s classes cumprir seus papis nos Casos de Uso. As colaboraes representam outras classes que colaboram para o cumprimento das responsabilidades das classes j descobertas. Depois de identificadas as classes, estas devero ser especificadas de maneira a apresentar os uma definio clara e concisa, o uma relao de responsabilidades, as operaes necessrias para o cumprimento dessas responsabilidades, atributos necessrios para cumprimento dessas responsabilidades e o relacionamento entre as classes colaboradoras.
Atributos
Atributos representam propriedades dos itens que esto sendo modelados. Todos os objetos de uma mesma classe compartilham os mesmos atributos. Um atributo uma abstrao do tipo de dados ou estados que os objetos da classe podem abranger.
Operaes
Uma operao a implementao de um servio que pode ser solicitado por algum objeto de classe para modificar o comportamento. Em outras palavras, uma operao uma abstrao de algo que pode ser feito com um objeto e que compartilhado por todos os objetos dessa classe. Uma classe pode ter qualquer nmero de operaes.
Representao na UML
Para representar as classes, os seus atributos e suas operaes na UML, utiliza-se construir um retngulo que dividido em trs partes. Na primeira parte,
47 colocado o nome da classe em questo. Num segundo compartimento, so colocados os atributos e finalmente na terceira diviso, so escritas as operaes. A figura 3, a seguir, traz um exemplo de uma classe.
Dependncia
Uma dependncia um relacionamento de utilizao, determinando as modificaes na especificao de um item, mas no necessariamente o inverso. A dependncia representada graficamente, na UML, como linhas tracejadas apontando o item do qual o outro depende. As dependncias so usadas sempre que se quer indicar algum item dependendo de outro.
48 Freqentemente, as dependncias so usadas no contexto das classes para mostrar que uma classe usa outra como argumento na assinatura de uma operao. Esse , essencialmente, um relacionamento de utilizao, j que se a classe utilizada for modificada, a operao da outra classe pode ser afetada, pois a classe utilizada pode agora apresentar uma interface ou comportamento diferente.
Generalizao
Uma generalizao um relacionamento entre itens gerais (chamados superclasses ou classe-me) e tipos mais especficos desses itens (chamados subclasses ou classes-filhas). Freqentemente, as generalizaes so chamadas relacionamentos um tipo de: um item. Neste caso, as subclasses herdam as propriedades da me, principalmente seus atributos e operaes. Uma classe pode ter zero, uma ou mais classes-me. Uma classe que no tenha uma classe-me (superior), mas tenha uma ou mais classes-filha chamada classe-raiz ou classe de base. Uma classe que no tem classes-filha chamada classe-folha. Uma classe que tem exatamente uma nica classe-me identificada como usando uma nica herana; uma classe com mais de uma classe-me identificada como usando heranas mltiplas.
Associao
Uma associao um relacionamento estrutural que especifica objetos de um item conectados a objetos de outro item. A partir de uma associao conectando duas classes, possvel navegar do objeto de uma classe at o objeto de outra classe e vice-versa. Caso deseje-se indicar que um objeto de uma determinada classe cria vnculos com outros objetos desta mesma classe, utiliza-se a notao de duas extremidades do crculo de uma associao remetendo mesma classe. As associaes binrias so aquelas que estabelecem uma ligao exata entre duas classes. J as associaes dirias, que no so muito comuns, estabelecem ligaes entre mais de duas classes.
49 Na UML as associaes so representadas como uma linha slida conectando uma classe mesma classe ou a classes distintas e so usadas sempre que se deseja exibir relacionamentos estruturais. Alm dessa forma bsica, existem quatro tipos de aprimoramentos que podem ser aplicados s associaes.
Nome
Uma associao pode ter um nome que ser utilizado para descrever a natureza do relacionamento. Utiliza-se, ainda, um tringulo de indicao ao lado do nome para indicar como deve ser lido o nome de uma associao.
Papel
Ao participar de uma associao, cada classe assume um papel dentro desse relacionamento, desse modo o papel pode estar explicitado junto classe que o assume dentro da associao.
Multiplicidade
Em diversas situaes ao modelar, importante determinar a quantidade de objetos que podem ser conectados pela instncia de uma associao. Entende-se por multiplicidade do papel esta quantidade e pode ser escrita como uma expresso equivalente a um intervalo de valores ou a um valor explcito. Ao determinar a multiplicidade em uma das extremidades de uma associao, est se especificando que, para cada objeto da classe encontrada na extremidade oposta, deve haver a mesma quantidade de objetos na prxima extremidade. Multiplicidade pode ser apresentada em diversas formar, um (1), zero ou um (0..1), zero ou muitos (0..*) ou um ou mais (1..*). Pode-se, ainda, determinar o nmero exato da multiplicidade, quatro (4), por exemplo.
50
Agregao
Uma associao pura entre duas classes denota o relacionamento estrutural entre pares, significando que essas duas classes esto conceitualmente num mesmo nvel, no havendo distino de importncia entre elas. Entretanto, existem situaes em que necessria a representao todo/parte, no qual uma classe representa um item maior (o todo), formado por itens menores (as partes). Neste relacionamento do tipo tem - um, tem-se que um objeto do todo contm os objetos das partes. A figura 4 mostra um exemplo dos diferentes tipos de relacionamentos existentes.
51
52
CAPTULO 3
SITUAO ATUAL
Este captulo tem como objetivo apresentar a situao do atual Sistema de Informaes da empresa referente ao controle das carteiras dos fundos de investimentos. apresentado com alguns detalhes o funcionamento deste sistema bem como a relao entre seus diversos componentes. Na seqncia feita uma anlise deste Sistema buscando levantar as suas principais crticas para que estas falhas possam ser corrigidas no Sistema a ser proposto.
53 Estes arquivos de controle so bastante parecidos entre si, sendo que s se diferem pelas operaes que so efetuadas em cada um deles. Por exemplo, um fundo multimercado tem algumas planilhas sobre renda fixa que no so encontradas em um fundo de Aes, uma vez que por regulamentao estes no podem aplicar em determinados ttulos financeiros. No entanto, estas pequenas variaes no prejudicam o entendimento e padronizao dos diversos arquivos de controle de carteira. Estes arquivos de controle da carteira so constitudos por diversas planilhas sendo que cada qual exerce uma funo especfica para o sistema. So essas as seguintes planilhas: Planilha Resumo Ligada s demais planilhas que constituem o arquivo, esta planilha tem por objetivo ser o Resumo da Carteira e apresentar os valores financeiros de todos os itens que impactam no valor da cota do Fundo, ou seja, o valor financeiro das aes, dos ttulos pblicos e privados, de contas a pagar e contas a receber. Planilha Conta Corrente Tem poder objetivo consolidar todo fluxo de caixa de cada um dos dias e assim enviar para a Planilha Resumo o montante financeiro que deve sair ou entrar no caixa do fundo naquele dia. Planilha Carteira de Aes Esta planilha consolida as diferentes aes que esto na carteira do fundo, sendo prprias ou emprestadas. Existe ainda um vnculo com o Arquivo Preos que garante que seja calculado o valor financeiro das aes e este dado enviado para a Planilha Resumo. Trata-se de uma planilha passiva. Planilha Emprstimo de Aes Nessa planilha apresentada a carteira consolidada das aes que esto sendo operadas de forma vendida (short). A exemplo da Planilha Carteira de Aes, nessa planilha existe um vnculo com o Arquivo Preos que possibilita o clculo do valor financeiro da soma dessas aes que enviado para a Planilha Resumo. Trata-se de uma planilha passiva.
54 Planilha Aes Nessa planilha apresentada a carteira de aes prprias, ou seja, as aes em custdia sem contar as aes que eventualmente estejam emprestadas. De fato, esta planilha passiva ao apresentar a situao prpria da carteira, mostra a necessidade de aluguel, a qual explorada em outro arquivo chamado Aluguis com o qual existe um vnculo. Planilha Movimentao Nesta planilha so colocadas manualmente as compras e vendas de aes de cada dia. Isto faz com que ocorra a atualizao da Planilha Carteira de Aes, da Planilha Emprstimos de Aes e da Planilha Aes. Planilha CDB Esta planilha consolida todas as operaes de CDB em vigncia na Carteira do Fundo. Fornece a data de vencimento de cada um dos CDBs bem como seu valor financeiro que atualizado automaticamente a cada dia com o auxilio da Planilha Cotaes. A soma do valor financeira dos CDBs enviada para a Planilha Resumo. Trata-se de uma planilha passiva Planilha Movimentaes CDB Esta planilha responsvel pelo cadastramento manual de cada um dos CDBs bem como a movimentao (resgate) que ocorre para cada um desses ttulos privados. Planilha Debntures Planilha anloga Planilha CDB, entretanto, como as operaes envolvendo debntures so bastante raras, o cadastro das diferentes debntures realizado nessa mesma planilha. A soma do valor financeiro de todas as debntures enviada para a Planilha Resumo. Planilha Cotaes Nessa Planilha so digitados os valores de alguns dados que so essenciais para o clculo da cota dos Fundos, como o valor da cota no dia anterior, valor do patrimnio do dia anterior, valor do CDI. Este ltimo valor serve de base para o clculo do valor de CDBs e Debntures. J o valor da cota anterior enviado para a Planilha Resumo e usado para o clculo da variao da cota no dia. Planilha Emprstimos de Aes Passivo Nessa planilha calculado o valor do aluguel a ser pago ou recebido por um aluguel tomado ou cedido. O valor financeiro da soma das obrigaes a pagar e a receber enviado para a Planilha Resumo.
55 Planilha Aplicaes-Resgates Nessa planilha so colocados os valores financeiros das aplicaes e seus respectivos dias de ocorrncia. Desta maneira a planilha consegue calcular o dia em que ocorre a cotizao da aplicao ou resgate e o dia em que se dar a contraparte financeira, ou seja, o dia em que ser efetuado o pagamento do resgate. Como resposta dessa planilha, temos o envio do valor financeiro para a Planilha Conta Corrente e para a Planilha Quantidade de Cotas. Planilha Quantidade de Cotas Esta uma planilha passiva que trabalha com duas entradas para o clculo da variao da quantidade de cotas: a variao financeira, vinda da Planilha Aplicaes-Resgates e o valor da cota proveniente da Planilha Cotaes. Planilha Juros de Capital Prprio Dividendos Nessa planilha so colocados os valores dos proventos provisionados (juros de capital prprio ou dividendos) de cada uma das Aes no dia em que as mesmas se tornam Ex, ou seja, quando as empresas anunciam que iro pagar juros de capital prprio ou dividendos, e esses valores so retirados assim que o dia provisionado de pagamento chega. Esta planilha envia o valor financeiro da soma desses proventos para a Planilha Resumo. Planilha Compra Aes Esta mais uma planilha passiva que tem por objetivo organizar os dias em que as aes negociadas deixaro ou entraro em custdia e por contrapartida o dinheiro da venda ou compra venda das mesmas entrar no caixa do fundo. O valor financeiro dessas aes enviado para a Planilha Resumo para a seo de contas a pagar / receber e tambm para a Planilha Conta Corrente. Para o controle de aluguis de aes atualmente utilizado um sistema nico que consolidam todos os cinco fundos em um s arquivo o Arquivo Aluguis. O Arquivo Aluguis composto por uma srie de planilhas que sero descritas a seguir: Planilha Movimentaes Aluguis Nesta planilha so registrados, manualmente, todos os dados referentes a operaes de aluguel, tais como o papel alugado, a data de partida, a data de vencimento, a quantidade alugada, o fundo
56 para o qual esse aluguel foi tomado, a corretora com a qual foi fechado este aluguel e a taxa a ser paga. tambm necessrio o registro de quando o aluguel devolvido. Planilha Posio por Fundos Esta planilha passiva responsvel por consolidar as informaes vindas de planilha Controle Aes do Arquivo Controle de cada um dos fundos, bem como as informaes vindas da Planilha Movimentaes Aluguis do prprio arquivo. Como resultado possvel, por meio de uma consulta, saber qual a necessidade de novos aluguis ou qual a sobra de aluguis que existem nas diferentes carteiras. Planilha Prximos Vencimentos Por meio dessa planilha possvel que sejam visualizados os vencimentos dos diversos aluguis de cada um dos fundos, listados por ordem de vencimento, para que a pessoa responsvel no deixe de renovar ou devolver o aluguel no momento de seu vencimento. Todas as movimentaes que ocorrem nos fundos so registradas no Arquivo Movimentaes. Este um arquivo bastante simples compostos por diversas planilhas, sendo que cada uma delas representa cada um dos dias. Desse modo todas as operaes que ocorrem em determinado dia devem ser colocadas em uma rea previamente determinada da planilha para que quando for utilizado o Arquivo Movimentaes Resumo do dia, esta possa ler os dados de maneira correta. O Arquivo Movimentaes Resumo do dia composto por diversas planilhas e cada uma delas representa um fundo. Existe uma seleo, que ocorre via uma macro de repetio, que faz com que em cada uma dessas planilhas sejam colocadas as movimentaes de compra e venda de Aes ou Contratos Futuros. Esta separao por fundos simplifica o fechamento das carteiras uma vez que as informaes referentes s Aes so posteriormente copiadas na planilha Movimentaes do Arquivo Controle de Carteira de cada um dos fundos e as informaes referentes aos contratos futuros so copiados na planilha Movimentaes BM&F do Arquivo Controle BM&F que explicado na seqncia.
57 Para realizar o gerenciamento das informaes referentes aos contratos futuros utilizado, atualmente um arquivo chamado Controle BM&F. Este arquivo composto por uma srie de planilhas: Planilha Movimentaes Futuros Essa planilha responsvel por registrar toda a movimentao existente nos cinco fundos no que se refere aos contratos futuros, caso haja uma venda ou compra de um ou mais contratos. Planilha Cotaes Essa planilha recebe diariamente o valor de mercado de cada um dos contratos futuros. a base de informao que utilizada nas Planilhas Controle de Contratos. Planilhas Controle de Contrato Essas so diversas planilhas que de forma passiva controlam a quantidade de contratos e o valor financeiro dos mesmos em cada um dos fundos. Existe uma planilha desse tipo para cada tipo de contrato futuro e para cada data de vencimento. Planilha Contratos Consolidados Essa planilha passiva consolida os dados financeiros existentes nas Planilhas Controle de Contrato e apresenta o valor financeiro alocado em contratos futuros para cada um dos Fundos. Esses valores so vinculados com o Arquivo Controle de Carteira de cada um dos fundos na Planilha Resumo.
58 Os vnculos entre os diversos arquivos que permitem que muitos dados sejam replicados sem que para isso haja a necessidade de uma nova digitao, devem estar sempre atualizados. No entanto, por diversas vezes um usurio de um arquivo no sabe se o arquivo ao qual o mesmo est vinculado foi atualizado e nessas situaes podem ocorrer dois tipos de problemas: - O usurio acredita que os dados estejam atualizados e continua a usar seu arquivo podendo estar trabalhando sobre uma base no correta; - O usurio abre o arquivo ao qual o seu est vinculado, verifica se os dados esto atualizados e caso no estejam, os atualizam. Caso os dados estejam atualizados, o usurio fechar o arquivo e continuar a trabalhar no qual estava trabalhando. Nesse caso, o usurio ter perdido um tempo realizando uma atividade que no agregou ao seu trabalho. O sistema bastante pesado sendo que em diversas situaes os computadores, mesmo sendo de ponta em relao tecnologia, levam vrios minutos para realizar os clculos internos da planilha. Existe, ainda, grande retrabalho no momento das atualizaes das carteiras. Primeiro porque diversas operaes ocorrem para diferentes fundos todos os dias e no atual sistema h de se atualizar cada um dos fundos de maneira individualizada. Assim, como cada fundo tem seu prprio banco de dados, necessrio sejam abertas inmeras planilhas para realizar tarefas anlogas em fundos diferentes. Alm disso, alguns dados tm de ser colocados repetidas vezes em planilhas diferentes, uma vez que para minimizar o uso de vnculos e evitar os problemas mencionados acima, em muitos lugares, especialmente para dado pontuais, necessrio a digitao de um valor. Toda vez que solicitado do sistema uma resposta para a qual o mesmo no tenha sido estritamente planejado para prover, no possvel a obteno desses dados sem que antes no sejam realizadas diversas operaes. Em outras palavras, toda vez que solicitado algo diferente do normal do sistema, necessrio trabalhar os dados convencionais de modo a chegar resposta esperada. Sucintamente, pode-se dizer que o sistema no tem grande flexibilidade.
59 Como o sistema atualizado por diversas pessoas sendo que para todas as principais funes todos os usurios podem editar os dados, por diversas vezes ocorre confuso sobre quem deve editar determinado dado. Por todos os motivos citados acima, o sistema no possui grande confiabilidade, o que reflete na credibilidade, fazendo com que por inmeras vezes seja necessrio que o usurio confira os dados com os relatrios fornecidos pelas empresas que prestam servio de administrao e custdia dos fundos. Desta maneira, as principais crticas ao Sistema de Informaes atual podem ser resumidas na seguinte tabela:
Tabela 1: Crticas ao Sistema de Informaes Atual
Crticas ao Sistema de Informaes Atual - Aceitao de dados falhos -Necessidade de atualizaes de vnculos entre diversas planilhas -Demora na execuo das tarefas -Replicao de trabalhos anlogos -Falta de flexibilidade -Atribuio confusa de responsabilidades -Baixa confiabilidade
60
CAPTULO 4
APLICAO DO MODELO
Aps ter sido levantado e discutido o problema que este Trabalho de Formatura visa abordar, ter sido feita a fundamentao terica bem como a apresentao do modelo a ser utilizado, apresentado o sistema atual de informao e sua anlise. Cabe agora a aplicao do modelo para que sejam capturados os requisitos do novo Sistema de Informaes atravs da aplicao do modelo descrito em captulos anteriores.
61
4.1.1 Login
Este Caso de Uso descreve o processo de login do usurio no sistema, isto , quando o usurio recebe a permisso para acessar e alterar o sistema. Diagrama contextual:
Fluxo de eventos: 1) O usurio aciona o sistema; 2) O sistema mostra a tela Login; 3) O usurio digita sua senha; 4) O sistema verifica a informao; 5) O sistema libera a permisso ao usurio; 6) O sistema exibe a tela com as opes permitidas; 7) O Caso de Uso se encerra.
62
Cadastrar Fundo
Usurio
Figura 6: Diagrama de Caso de Uso Cadastrar Fundo (elaborado pelo autor)
Fluxo de eventos: 1) O usurio seleciona Cadastrar Fundo; 2) O sistema mostra a tela de cadastro; 3) O usurio preenche os campos necessrios; 4) O usurio clica em salvar; 5) O sistema verifica as informaes e realiza o cadastro; 6) O usurio seleciona sair; 7) O Caso de Uso termina.
63
Figura 7: Diagrama de Caso de Uso Consultar Posio de Fundo (elaborado pelo autor)
Fluxo de eventos: 1) O usurio seleciona a opo Consultar Posio de Fundo; 2) O sistema mostra uma tela com as opes de fundo; 3) O usurio escolhe o fundo que lhe interessar; 4) O sistema mostra uma relao com as posies do fundo selecionado nos mais diversos ativos financeiros; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
64
Fluxo de eventos: 1) O usurio seleciona a opo Consultar Ativo; 2) O sistema mostra uma tela com as opes de classes de Ativos; 3) O usurio escolhe a classe de Ativos que lhe interessar e inicia-se o prximo Caso de Uso; 4) O Caso de Uso inicial termina.
65
4.1.5 Consultar Ao
Este Caso de Uso ocorre quando o usurio deseja ver a posio de uma determinada ao em todos os fundos simultaneamente, isto importante na medida em que geralmente os diferentes fundos mantm posio nos mesmos papis, alterando basicamente a alocao dos mesmos dentro da carteira. Diagrama contextual:
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Consultar Ao; 2) O sistema retorna a tela Escolha a Ao; 3) O usurio escolhe a Ao; 4) O sistema devolve a posio na Ao escolhida para os diversos fundos; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
66
Figura 10: Diagrama de Caso de Uso Consultar CDB (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Consultar CDB; 2) O sistema retorna a tela Escolha o Emissor; 3) O usurio escolhe o Emissor; 4) O sistema devolve a posio em CDB de um determinado Emissor para os diversos fundos; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
67
Figura 11: Diagrama de Caso de Uso Consultar Ttulo Pblico (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Consultar Ttulo Pblico; 2) O sistema retorna a tela Escolha o Ttulo Pblico 3) O usurio escolhe o Ttulo Pblico; 4) O sistema devolve a posio em um determinado Ttulo Pblico para os diversos fundos; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
68
Figura 12: Diagrama de Caso de Uso Consultar Ttulo Privado (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Consultar Ttulo Privado; 2) O sistema retorna a tela Escolha o Ttulo Privado; 3) O usurio escolhe o Ttulo Privado; 4) O sistema devolve a posio em um determinado Ttulo Privado para os diversos fundos; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
69
Figura 13: Diagrama de Caso de Uso Consultar Aluguel (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Consultar Aluguel; 2) O sistema retorna a tela Escolha a Ao; 3) O usurio escolhe a Ao; 4) O sistema devolve a posio alugada em uma determinada ao para cada um dos fundos; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
70
Figura 14: Diagrama de Caso de Uso Consultar Provento (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Consultar Provento; 2) O sistema devolve a posio de proventos provisionados para cada um dos fundos; 3) O usurio seleciona sair; 4) O Caso de Uso termina.
71
Figura 15: Diagrama de Caso de Uso Consultar Contrato Futuro (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Consultar Contrato Futuro; 2) O sistema retorna a tela Escolha o Contrato Futuro; 3) O usurio escolhe o Contrato Futuro; 4) O sistema devolve a posio do Contrato Futuro escolhido para cada um dos fundos; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
72
Figura 16: Diagrama de Caso de Uso Consultar Caixa (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Consultar Caixa; 2) O sistema devolve a posio do Caixa, bem como o fluxo financeiro do dia para cada um dos fundos; 3) O usurio seleciona sair; 4) O Caso de Uso termina.
73
Figura 17: Diagrama de Caso de Uso Cadastrar Ativo (elaborado pelo autor)
Fluxo de eventos: 1) O usurio seleciona a opo Cadastrar Ativo; 2) O sistema mostra uma tela com as opes de classes de Ativos; 3) O usurio escolhe a classe de Ativos que lhe interessar e inicia-se o prximo Caso de Uso; 4) O Caso de Uso inicial termina.
74
4.1.14 Cadastrar Ao
Quando uma nova empresa lana suas aes no Mercado Financeiro necessrio que essa ao seja registrada no sistema para que assim, se houver algum dia uma compra ou venda de ao, a carteira j ter a mesma registrada no havendo, portanto, a chance de ocorrer nenhum problema por falta de documentao. Diagrama contextual:
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Cadastrar Ao; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a esta nova ao com as informaes referentes ao Ticker, lote e empresa; 4) O sistema cadastra esta nova ao; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
75
Figura 19: Diagrama de Caso de Uso Cadastrar CDB (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Cadastrar CDB; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a este novo CDB com as informaes referentes Data de Vencimento, Data de Emisso, Emissor, Taxa de Remunerao; 4) O sistema cadastra este novo CDB; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
76
Figura 20: Diagrama de Caso de Uso Cadastrar Ttulo Pblico (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Cadastrar Ttulo Pblico; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a este novo Ttulo Pbico com as informaes referentes Data de Vencimento, Data de Emisso, Indexador, Fluxo de Pagamento; 4) O sistema cadastra este novo Ttulo Pblico; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
77
Figura 21: Diagrama de Caso de Uso Cadastrar Ttulo Privado (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Cadastrar Ttulo Privado; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a este novo Ttulo Privado com as informaes referentes Data de Vencimento, Data de Emisso, Indexador, Fluxo de Pagamento e Preo de Compra; 4) O sistema cadastra este novo Ttulo Privado; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
78
Figura 22: Diagrama de Caso de Uso Cadastrar Provento (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Cadastrar Provento; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a este novo Provento com as informaes referentes Ao, Data de Pagamento e Valor a ser pago por ao; 4) O sistema cadastra este novo Provento; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
79
Figura 23: Diagrama de Caso de Uso Cadastrar Contrato Futuro (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Cadastrar Contrato Futuro; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a este novo Contrato Futuro com as informaes referentes ao Tipo (Dlar, ndice, Taxa de Juros), Data de Vencimento e Cdigo; 4) O sistema cadastra este novo Contrato Futuro; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
80
Figura 24: Diagrama de Caso de Uso Movimentar Ativo (elaborado pelo autor)
Fluxo de eventos: 1) O usurio seleciona a opo Movimentar Ativo; 2) O sistema mostra uma tela com as opes de classes de Ativos; 3) O usurio escolhe a classe de Ativos que lhe interessar e inicia-se o prximo Caso de Uso; 4) O Caso de Uso inicial termina.
81
4.1.21 Movimentar Ao
Toda vez que ocorre a compra e venda de aes por parte do Gestor as informaes referentes a essa compra ou venda devem ser processada e posteriormente colocadas no sistema para que haja o controle de cada uma das carteiras. Fazem parte deste controle a determinao da entrada ou sada do dinheiro da conta do Fundo e o controle da entrada ou sada das aes da custdia do Fundo. Diagrama contextual:
Figura 25: Diagrama de Caso de Uso Cadastrar Movimentar Ao (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Movimentar Ao; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a esta movimentao, colocando o Ticker da Ao, a quantidade negociada, o preo, o fundo no qual deve ser alocada esta ao e se foi uma compra ou venda; 4) O sistema registra esta movimentao; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
82
Figura 26: Diagrama de Caso de Uso Movimentar CDB (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Movimentar CDB; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a esta movimentao, colocando o cdigo do CDB e a quantidade movimentada; 4) O sistema registra esta movimentao; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
83
Figura 27: Diagrama de Caso de Uso Movimentar Ttulo Pblico (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Movimentar Ttulo Pbico; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a esta movimentao, colocando o nome do ttulo, o vencimento, a quantidade movimentada e o fundo do qual o ttulo faz parte; 4) O sistema registra esta movimentao; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
84
Figura 28: Diagrama de Caso de Uso Movimentar Ttulo Privado (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Movimentar Ttulo Privado; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a esta movimentao, colocando o nome do ttulo, a quantidade movimentada e o fundo do qual o ttulo faz parte; 4) O sistema registra esta movimentao; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
85
Figura 29: Diagrama de Caso de Uso Movimentar Aluguel (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Movimentar Aluguel; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a esta movimentao, colocando o nome da Ao, a quantidade alugada, taxa de aluguel, data de vencimento e o fundo do para o qual foi alugada esta ao; 4) O sistema registra esta movimentao; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
86
Figura 30: Diagrama de Caso de Uso Movimentar Contrato Futuro (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Movimentar Contrato Futuro; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a esta movimentao, colocando o nome do contrato, a quantidade contratada e o fundo para qual foi comprado ou vendido este contrato; 4) O sistema registra esta movimentao; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
87
Figura 31: Diagrama de Caso de Uso Ajustar Caixa (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Ajustar Caixa; 2) O sistema retorna a tela Preencha os campos; 3) O usurio preenche os campos referentes a este ajuste colocando o valor financeiro do ajuste e o fundo no qual o mesmo deve ser feito; 4) O sistema registra este ajuste; 5) O usurio seleciona sair; 6) O Caso de Uso termina.
88
Figura 32: Diagrama de Caso de Uso Atualizar Carteira (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Atualizar Carteira; 2) O sistema mostra uma tela com as opes de Atualizaes; 3) O usurio escolhe a opo de Atualizao que lhe interessar e inicia-se o prximo Caso de Uso; 4) O Caso de Uso inicial termina.
89
Figura 33: Diagrama de Caso de Uso Atualizar Broadcast (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Atualizar Broadcast; 2) O sistema busca no Broadcast informaes sobre cotao de aes e contratos futuros; 3) O usurio seleciona sair; 4) O Caso de Uso termina.
90
Figura 34: Diagrama de Caso de Uso Atualizar Bloomberg (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Atualizar Bloomberg; 2) O sistema busca no Bloomberg informaes sobre cotao de ttulos privados e pblicos; 3) O usurio seleciona sair; 4) O Caso de Uso termina.
91
Figura 35: Diagrama de Caso de Uso Atualizar Manual (elaborado pelo autor)
Fluxo de eventos: 1) O Caso de Uso se inicia quando o usurio seleciona Atualizar Manual; 2) O sistema apresenta os dados para atualizao manual; 3) O usurio promove as atualizaes; 4) O usurio seleciona sair; 5) O Caso de Uso termina.
92
93 ser conseguida pelo estabelecimento de regras para validao de um dado, quando este colocado no sistema. Requisitos organizacionais: -Entrega: A entrega dos documentos deve ocorrer em tempo real, isto , toda vez que um usurio atualizar o sistema, este deve estar apto a fornecer as informaes totalmente atualizadas, sem que para isto seja necessrio o processamento demorado das informaes. -Implementao: Aps serem realizados todos os testes que comprovem o bom funcionamento do Sistema de Informaes a ser desenvolvido, o mesmo deve ser implementado de maneira rpida sem que haja a oportunidade da existncia de dois sistemas funcionando em paralelo, o novo e o atual. Isto devido ao fato de existirem muitas informaes colocadas no sistema cotidianamente e de maneira fracionada, o que faria com que fatalmente alguma dessas informaes no fosse replicada para um dos dois sistemas, comprometendo no s o funcionamento deste que no a recebeu, mas tambm a confiabilidade do outro. -Padres: esperado que o sistema entregue relatrios em documentos compatveis com a famlia de produtos Office da Microsoft, isto porque diversos relatrios devero ser exportados para programas desta famlia. Requisitos externos: -Interoperabilidade: necessrio para o bom funcionamento do sistema que o mesmo tenha uma grande interoperabilidade com os softwares de cotao em tempo real Bloomberg e Broadcast, bem como o software Economtica. Sem esta interoperabilidade impossvel o bom funcionamento do sistema j que necessria a atualizao peridica dos diversos entes do sistema. -Privacidade: Cada um dos usurios do sistema dever possuir uma senha particular e intransfervel para acesso ao sistema. Deste modo, cada um dos usurios poder acessar de maneira individual e independente o sistema.
94 -Segurana: muito importante que o sistema esteja a prova de rackers ou qualquer tipo de invasores que tentem acessar o sistema sem autorizao. A atual configurao da Rede de computadores da Bresser j possibilita a proteo contra invasores, entretanto, o sistema dever contar com senhas que possibilitaro acesso somente aos usurios cadastrados.
95 Deve-se destacar que so apresentados apenas esboos de algumas das diversas Telas do Sistema de Informaes a ser elaborado. Estes esboos tm o objetivo de apresentar o padro a ser seguido, no tendo como objetivo restringir o real design do Sistema. A figura 36 mostra um esboo de como deve ser a primeira tela do sistema. Nela pode-se observar que o usurio tem a opo de consultar ou cadastrar um Fundo, consultar, cadastrar ou movimentar algum Ativo.
importante notar que com esta tela, o usurio tem a possibilidade de acessar as mais diversas funcionalidades do Sistema de uma maneira rpida e direta.
96 O segundo esboo de layout apresentado na figura 37 refere-se tela Selecionar Fundo. Esta tela acessada quando o usurio na Tela inicial seleciona a opo Consultar Fundo. Por meio desta tela oferecida ao usurio a opo de acessar algum dos fundos previamente cadastrados no Sistema.
97 A figura 38 apresenta o esboo de layout da tela Ativos por Fundo. Por meio desta tela, o usurio tem acesso aos mais diversos ativos que compem um fundo de investimento. So apresentadas as posies nesses ativos bem como seus valores financeiros equivalentes. Assim, o usurio pode observar o fundo de investimento de maneira consolidada.
98 Quando o usurio desejar cadastrar operaes de compra ou venda de um dos mais diversos ativos, este pode cadastrar todas estas movimentaes, separadas por classes de ativos, de maneira consolidada. Desta forma, o sistema busca atender o requisito da no replicao de tarefas anlogas. Na Figura 39 apresentado o esboo da Tela Movimentar Ao. Pode-se notar que com a utilizao dos campos propostos, podem ser realizadas as operaes de compra e venda de Aes para os diversos Fundos.
99
Estas classes candidatas so levantadas buscando apresentar somente as que possuem alguma relevncia para o sistema, ou seja, aquelas que estejam ligadas diretamente ao domnio do problema da anlise.
100
101
4.4.2.1 Classe Ao
A Classe Ao foi criada, pois se trata de um dos principais investimentos existente no Mercado Financeiro. Sua presena chave em um Fundo de Investimento Multimercado e, obviamente, em um Fundo de Investimento de Aes. A Classe Ao apresentada na figura 42.
Cada Ao possui diversos atributos que permitem diferenci-las uma das outras: -Ticker: Cada ao possui um Ticker diferente, isto , um cdigo que permite a associao desta ao com a classe de ao da empresa; -Lote: Cada diferente ao possui um Lote padro diferente pelo qual ela negociada. Atualmente, este valor de Lote pode ser 1 ou 1000; -Cotao: o valor de mercado de um lote de determinada ao em um determinado momento; -Cotao dia anterior: o valor de mercado de um lote de determinada ao no dia anterior. til para o clculo do ganho ou perda financeira que est acontecendo em determinado momento em relao ao dia anterior; -Quantidade Comprada: Quantidade de uma determinada ao que o fundo possui como saldo; -Quantidade Alugada: Quantidade de uma determinada ao que o fundo alugou de um terceiro;
102 -Fundo: cada ao est alocada em um fundo. Dentro da Classe Ao existem as seguintes operaes: -Movimentao: Nessa operao so realizadas a compra e a venda de determinada ao. Para tanto, necessrio que se indique o Ticker da ao, a quantidade comprada ou vendida e o Fundo no qual ocorreu a movimentao; -Editar Ao: Esta operao realizada para cadastrar uma nova ao, para excluir uma ao ou mesmo alterar algum dado como Ticker ou Lote; -Atualizar Cotao: Esta Operao utilizada para que as aes tenham suas cotaes atualizadas e desta maneira se chegue ao valor da posio de uma determinada ao em um determinado momento para um determinado fundo.
103
Cada Aluguel de Ao tomado possui diversos atributos: -Ao: Indica qual foi a ao alugada; -Quantidade: Indica quantas aes foram alugadas; -Fundo: Indica para qual fundo foi alugada a ao; -Vencimento: Indica o vencimento da ao alugada; -Taxa: Indica qual foi a taxa acordada no momento do aluguel da ao; -Contraparte: Indica a corretora com a qual foi fechado o aluguel; -Observao: Espao reservado para que, se necessrio, indicar alguma observao referente ao aluguel. As operaes referentes Classe Aluguel de Ao so as seguintes:
104 -Alugar Ao: Corresponde ao ato de fechar uma operao de tomada de aluguel de ao e document-la no sistema. Digitam-se todos os dados referentes a esta operao, cadastrando-a; -Doar Ao: Corresponde ao ato de fechar uma operao de doao de ao e document-la no sistema. Digitam-se todos os dados referentes a esta operao, cadastrando-a; -Liquidar Aluguel: Corresponde ao ato de encerrar um aluguel de tomada de ao antecipadamente. Digitam-se os dados referentes a esta operao, confirmando-a posteriormente.
105
Para o sistema, os Ttulos Pblicos possuem uma srie de atributos cabendo ressaltar os seguintes: -Fundo: Corresponde ao Fundo do qual o ttulo faz parte do portiflio; -Data da Emisso: Corresponde Data de Emisso do Ttulo; -Tipo: Corresponde especificao do Tipo de Ttulo Pblico, por exemplo, se um ttulo pr-fixado, atrelado ao dlar ou a algum ndice de inflao como IPCA ou IGPM; -Data do Vencimento: Corresponde data de Vencimento do Ttulo. Esta data de vencimento pode variar muito de um ttulo para outro; -Cotao: Corresponde ao valor de mercado do Ttulo em determinado momento. Tambm conhecido como PU (preo unitrio); -Quantidade: Corresponde quantidade comprada de um determinado ttulo. Existem algumas operaes correspondentes Classe Ttulo Pblico:
106 -Movimentar Ttulo: Esta operao visa registrar a compra ou venda de um ttulo previamente cadastrado. So digitados todos os dados referentes a essa operao tais como Fundo, Tipo, Quantidade, confirmando-a na seqncia; -Editar Ttulo: Com esta operao pode-se editar um ttulo, alterando algum dado, cadastrando algum novo ttulo ou mesmo retirando do sistema um ttulo j vendido. -Atualizar Cotao: Corresponde a atualizar a cotao do ttulo para que seja expresso o atual valor de mercado do mesmo.
107
Para o sistema, os Ttulos Privados possuem uma srie de atributos cabendo ressaltar os seguintes: -Data do Vencimento: Corresponde data de Vencimento do Ttulo. Pode variar muito de um ttulo para outro; -Fundo: Corresponde ao Fundo no qual est alocado determinado ttulo; -Tipo: Os ttulos privados, excetuando-se os CDBs, com maior relevncia para o Sistema so basicamente de dois tipos Debntures e FIDCs. Este atributo corresponde definio de qual tipo de ttulo esse; -Cotao: Corresponde ao valor de mercado do Ttulo em determinado momento. Tambm conhecido como PU (preo unitrio); -Quantidade: Corresponde quantidade comprada de um determinado ttulo; -Emissor: Corresponde Empresa que emitiu o ttulo que est sendo analisado;
108 -Data da Emisso: Corresponde data que o ttulo em questo foi emitido. As operaes da Classe Ttulo Privado so as seguintes: -Movimentar Ttulo: Esta operao visa registrar a compra ou venda de um ttulo previamente cadastrado. So digitados todos os dados referentes a essa operao tais como Fundo, Tipo, Quantidade, confirmando-a na seqncia; -Editar Ttulo: Com esta operao pode-se editar um ttulo, alterando algum dado, cadastrando algum novo ttulo ou mesmo retirando do sistema um ttulo j vendido; -Atualizar Cotao: Corresponde a atualizar a cotao do ttulo para que seja expresso o atual valor de mercado do mesmo.
109
CDB,
apesar
de
ter
uma
estrutura
bastante
padronizada,
independentemente da instituio que o emite, possui diversos atributos que os diferenciam: -Tipo: Corresponde ao tipo do CDB. Podem ser de liquidez diria, quando se pode resgatar a qualquer dia, ou com prazo fixo, quando s pode se resgatado no seu vencimento. Podem ainda ser pr-fixados, quando se negocia uma taxa fixa no momento da compra do CDB ou ps-fixados quando seu rendimento atrelado taxa DI. Tradicionalmente tem-se optado por CDBs ps-fixados com liquidez diria; -Vencimento: Corresponde ao Vencimento do CDB; -Cotao: Corresponde a precificao do CDB em um determinado dia;
110 -Taxa: Corresponde ou a uma porcentagem da taxa de DI, no caso de um CDB ps-fixado ou a um retorno absoluto no caso de CDBs pr-fixados; -Emisso: Corresponde ao dia que o CDB foi emitido; -Quantidade: Corresponde quantidade de um determinado CDB; -Fundo: Corresponde ao Fundo no qual o CDB est alocado; -Emissor: Corresponde Instituio, geralmente um banco, que emitiu o determinado CDB; Apesar dos diversos atributos, os CDBs possuem poucas operaes relacionadas a eles. So elas: -Editar CDB: Toda vez que ocorre a compra de um determinado CDB, alguns dados devem ser registrados tais como: data de emisso, data de vencimento, taxa, emissor, quantidade, fundo e caracterstica; -Movimentar: Esta operao corresponde compra ou venda de um CDB previamente cadastrado.
111
Os contratos Futuros possuem uma srie de atributos. So eles: -Tipo: Trata-se do tipo de contrato futuro que representado. Os Fundos Administrados pela Bresser, operao como os seguintes tipos de contratos futuros: Dlar, ndice Ibovespa, e taxa de Juros; -Vencimento: Corresponde data de vencimento do contrato, isto , a data que ocorrer a liquidao do compromisso;
112 -Cotao: Trata-se da cotao do contrato futuro em questo em um determinado momento; -Quantidade: Corresponde quantidade comprada ou vendida de um determinado contrato futuro; -Fundo: Corresponde ao Fundo no qual est alocado um determinado contrato futuro; As operaes existentes para um Contrato Futuro so as seguintes: -Cadastrar Contrato: Esta operao visa o cadastro de um novo Contrato Futuro com todos os seus atributos; -Movimentar Contrato: Esta operao corresponde a toda operao de compra ou venda de um determinado Contrato Futuro; -Atualizar Cotao: Esta operao tem como objetivo atualizar a cotao dos Contratos Futuros.
113
Estes proventos possuem os seguintes atributos: -Tipo: Corresponde a duas classificaes: Dividendos ou Juros sobre Capital Prprio; -Provento Provisionados: Corresponde aos valores de proventos previamente provisionados; -Ao: Corresponde Ao que provisionou o Provendo; -Valor: Corresponde ao valor financeiro provisionado por cada ao; -Data de Pagamento: Corresponde data que dever ser pago o Provendo; -Fundo: Corresponde ao Fundo no qual est provisionado um determinado Provento. A esta classe est associada a seguinte operao:
114 -Provisionar Provento: Corresponde ao ato de provisionar um Provento, colocando no sistema as informaes referentes a ele, tais como, tipo, ao, valor e fundo.
115
Esta classe possui diversos atributos que sero relacionados na seqncia: -Fundo: Corresponde ao Fundo do qual o Caixa faz parte; -Movimentao Financeira de Ao: Corresponde ao valor financeiro que entra ou sai do caixa do fundo quando ocorre, respectivamente, a venda ou a compra de aes; -Movimentao Financeira de CDB: Corresponde ao valor financeiro que entra ou sai do caixa do fundo quando corre, respectivamente, a venda (resgate) ou a compra (aplicao) de um CDB. Ocorre ainda a entrada de dinheiro se o CDB vencer; -Movimentao Financeira de Ttulo Pblico: Corresponde ao valor financeiro que entra ou sai do caixa do fundo quando corre, respectivamente, a venda ou a
116 compra de um Ttulo Pblico. Ocorre ainda a entrada de dinheiro caso um Ttulo Pblico vena ou pague um Cupom; -Movimentao Financeira de Ttulo Privado: Corresponde ao valor financeiro que entra ou sai do caixa do fundo quando corre, respectivamente, a venda ou a compra de um Ttulo Privado. Ocorre ainda a entrada de dinheiro caso um Ttulo Privado vena ou pague um Cupom; -Movimentao Financeira Aluguel: Corresponde ao valor financeiro que entra ou sai do caixa do fundo. O dinheiro entra no caixa quando ocorre o vencimento ou liquidao antecipada de um aluguel doado. O dinheiro sai do caixa quando ocorre o vencimento ou liquidao antecipada de um aluguel tomado; -Movimentao Financeira de Contratos Futuros: Esta movimentao financeira ocorre pelo ajuste dirio. Este ajuste calculado com base no valor de mercado do contrato Futuro. Caso o fundo esteja comprado em um determinado contrato e este contrato se valorizar, o fundo ter direito a receber a diferena entre esta valorizao e o valor do dia anterior. Caso contrrio, o fundo dever pagar esta diferena; -Movimentao Financeira de Proventos: Esta movimentao financeira positiva caso tenha sido provisonado um provento de uma ao na qual o fundo estava comprado. O valor ser negativo caso contrrio; -Movimentao Financeira de Taxa de Administrao: Esta uma taxa anual que no entanto cobrada mensalmente e corresponde a uma porcentagem do Patrimnio do Fundo; -Movimentao Financeira de Taxa de Performance: Esta taxa pode ser paga semestralmente, entretanto somente se o fundo tiver um desempenho melhor que um parmetro previamente fixado; -Movimentao Financeira de Taxas: Sobre o fundo incidem diversas taxas, como a taxa de custdia, a taxa CBLC entre outras. So pagas mensalmente;
117 -Movimentao Financeira de Aplicaes e Resgate: Outra forma bastante comum de entrada e sada de recursos do caixa por meio de aplicaes e resgates; -Ajustes: Para alguma entrada ou sada que no estiver previamente provisionada, utiliza-se a opo Ajuste para que possa documentar a entrada ou sada de recursos financeiros. Mesmo com diversos atributos, a Classe Caixa possui apenas uma operao, uma vez que as demais so atualizadas automaticamente: -Ajustar caixa: Esta operao visa tornar possvel a documentao de um ajuste no previamente determinado.
118
-Fundo: Corresponde ao fundo que se quer determinar a carteira -Aes: Corresponde s aes que um fundo possui; -CDB: Corresponde aos CDBs que um fundo possui em carteira; -Ttulos Pblicos: Corresponde aos Ttulos Pblicos que um fundo possui em carteira; -Ttulos Privado: Corresponde aos Ttulos Privados que um fundo possui em carteira; -Contas a Pagar: Corresponde s contas que o fundo tem a pagar; -Contas a Receber: Corresponde s contas que o fundo tem a Receber; -Contratos Futuros: Corresponde aos contratos de Futuro que o Fundo tem em carteira; -Aluguel: Corresponde aos aluguis que o Fundo tem doado ou tomado;
120
121
122 O diagrama de classe com nfase nos Ativos dos Fundos permite que possam ser observadas as relaes entre as mais diversas classes do modelo e a Classe Fundo. As relaes que existem so basicamente de associao, mais precisamente de agregao, uma vez que todas as classes, com exceo da Classe Caixa, so componentes da Classe Fundo. Este fato notado facilmente, j que ao longo de todo trabalho procura-se mostrar que os fundos de investimentos so compostos por diversos ativos financeiros. A multiplicidade destes relacionamentos de agregao (1) no lado da Classe Fundo e (0...*) no outro lado da associao. Isto ocorre porque diversos ativos das variadas classes podem estar associadas a um Fundo individualmente. O relacionamento entre a Classe Caixa e a Classe Fundo uma associao simples com multiplicidade (1) e (1), j que a cada fundo est associado apenas um caixa. As Classes Provento e Aluguel de Ao possuem um relacionamento de dependncia entre elas e a Classe Ao, j que qualquer alterao que ocorrer na Classe Ao influencia as Classes Provento e Aluguel de Ao. Ocorre ainda a generalizao das Classes Juros sobre Capital Prprio e Dividendo na Classe Provento, uma vez que as duas classes-filhas possuem propriedades muito semelhantes no cabendo, portanto a diviso. Deste modo, utilizada a Classe-me Provento toda vez que necessrio fazer referncia s classes-filhas.
123
124 O diagrama de classes com nfase nos componentes do Caixa, permite que possam ser observadas as relaes de associaes entre as diversas classes do modelo e a Classe Caixa. Esta associao de multiplicidade (1) do lado da Classe Caixa e de multiplicidade (0...1) do lado das demais classes. Esta multiplicidade explicada pelo fato dessas diversas classes poderem alterar a Classe Caixa na medida em que pode existir um fluxo financeiro dirio decorrente das movimentaes nos ativos dessas classes. Por outro lado, estes fluxos financeiros no ocorrem necessariamente todos os dias e sempre esto associados ao caixa de um dos fundos de investimentos. Mais uma vez pode-se notar a associao entre as Classes Caixa e Fundo que denota que cada um dos objetos da Classe Caixa est associada a um dos objetos da Classe Fundo.
125
CAPTULO 5
ANLISE E DISCUSSO
Aps o desenvolvimento do modelo de requisitos realizado no captulo anterior, neste captulo realizada a anlise e discusso dessa aplicao.
126 Sistemas de Informaes Atual e o proposto para que possa ser dimensionada a contribuio deste Trabalho de Formatura. - Aceitao de dados falhos. Contrariamente ao que ocorre atualmente, o novo Sistema de Informaes dever possuir filtros nos campos de preenchimento de dados nos quais s sero aceitos dados vlidos. Por exemplo, quando se for cadastrar uma nova ao, ser necessrio que o campo referente ao novo Ticker seja preenchido inicialmente por 4 letras seguidas por 1 ou 2 dgitos de nmero, como ocorre nas aes PETR4 ou UBBR11. - Necessidade de atualizaes de vnculos entre diversas planilhas. Como o novo sistema no trabalha com planilhas, obviamente no necessrio o vnculo entre elas. De qualquer forma, quando este item foi levantado, se referia ao fato de diferentes partes do sistema serem atualizadas de maneira separada, fazendo com que o usurio no soubesse o que estava atualizado e o que no estava. O novo sistema permitir a atualizao rpida e fcil, garantindo que todo o sistema esteja atualizado, j que as operaes so colocadas em tempo real. - Demora na execuo de tarefa. Foi levantado como requisito no funcional do novo sistema que o mesmo no deva demorar mais de cinco segundos na execuo de qualquer tarefa. Apesar de no ter sido realizada nenhuma pesquisa para saber qual a melhor plataforma para o desenvolvimento, acredita-se que como no h nenhuma operao com alto grau de complexidade, este requisito no encontrar maiores dificuldades para ser atendido. - Replicao de trabalhos anlogos. A replicao de trabalhos anlogos no mais vai ocorrer no novo sistema. Esta falha do atual modelo foi corrigida possibilitando que trabalhos anlogos sejam feitos de uma s vez. Isto quer dizer que quando ocorrer uma compra ou venda de Aes, por exemplo, para diferentes fundos, no mais haver a necessidade de
127 colocar estes dados em 5 planilhas diferentes, podendo toda esta movimentao ser colocada em uma nica tela do novo sistema. - Falta de flexibilidade. A falta de flexibilidade do sistema atual corrigida no novo Sistema. Este novo sistema possibilitar a visualizao dos diversos componentes de um fundo de investimento de duas maneiras. Na primeira maneira ser apresentado o Fundo consolidado, com todos seus componentes, na segunda ser possvel observar um mesmo ativo para os diferentes fundos. A primeira maneira interessante para ter uma noo geral da alocao dos ativos dentro de um fundo, enquanto a segunda maneira permite observar como se comporta um determinado ativo nos diferentes fundos. - Atribuio confusa de responsabilidade. Como o novo sistema ser de fcil atualizao, no haver a necessidade de grande concentrao de esforo para realizar esta tarefa. Assim, esta tarefa poder ser realizada somente por uma pessoa, que ficar responsvel por toda a atualizao, acabando com a confusa atribuio de responsabilidades. Entretanto, apesar desta confuso ser decorrente da complexidade do sistema atual, a atribuio de responsabilidades muito mais uma questo organizacional da empresa do que relacionada diretamente ao sistema. - Baixa confiabilidade A baixa confiabilidade do sistema atual uma conseqncia das demais caractersticas. Como o sistema manipulado por vrias pessoas de maneira confusa, com aceitao de dado falho, exigindo atualizaes constantes de vnculos e realizao de repetidas tarefas anlogas, a ocorrncia de falhas freqente. Uma vez que cada um dos problemas citados resolvido separadamente, certo que o novo sistema ter uma confiabilidade maior que o atual. Cabe ressaltar que apesar de nenhum sistema estar completamente imune a falhas, a especificao dos requisitos do novo sistema foi realizada de maneira a minimizar estes erros e falhas.
128 Alm dos problemas levantados inicialmente, a elaborao do modelo de requisitos para o novo sistema permitiu que fossem adicionadas ao sistema caractersticas que inicialmente no eram vistas como falhas, mas que poderiam vir a ser. Por exemplo, com as exigncias de usabilidade especificadas, o novo sistema passar a ser mais fcil de ser manipulado, no exigindo profundos conhecimentos de nenhum software. Outra nova caracterstica ser a segurana, com a utilizao de senhas personalizadas para proteger o sistema de invases de intrusos.
129
CONCLUSO
Neste captulo feita a concluso do Trabalho de Formatura apresentado, buscando-se ressaltar os principais pontos discutidos. Este trabalho tratou dos Requisitos para modelagem de um Sistema de Informaes Gerencial de controle de carteiras de fundos de investimentos para a Bresser, uma empresa de pequeno porte que se dedica ao gerenciamento de recursos de terceiros. Este Sistema de Informaes permite registro, armazenamento e atualizaes das operaes relacionadas ao gerenciamento dos Fundos de Investimentos. No Mercado Financeiro, principalmente no setor de gesto de fundos de investimentos, a concorrncia muito acirrada e qualquer diferencial pode se tornar decisivo para o sucesso de uma empresa. A gesto de fundos de investimentos feita basicamente atravs de decises tomadas com base em anlises. Estas anlises so feitas por meio do processamento de informaes. Desta maneira, ter um Sistema de Informaes capaz de atender s necessidades do gestor fundamental para o bom desempenho dos Fundos de Investimento e por conseqncia da Empresa. A importncia deste Sistema consiste em possibilitar que as informaes acerca desses fundos estejam disponveis e atualizadas a qualquer momento, podendo ser acessadas por diversos usurios. A confiabilidade do sistema vital e por isso mereceu grande destaque ao longo deste Trabalho. O desenvolvimento deste novo sistema permite ainda que os usurios consigam realizar as funes do sistema de maneira rpida e eficiente, podendo direcionar seus esforos em atividades que possam trazer maiores benefcios para a empresa. Neste trabalho foi possvel utilizar parte dos conhecimentos adquiridos durante o curso de Engenharia de Produo. Entre esses conhecimentos, pode ser citada a viso sistmica: a utilizao de diferentes modelos permitiu que as questes fossem analisadas primeiramente sob uma tica local, e posteriormente, com a
130 utilizao da viso sistmica, pde ser observada a influncia dessas questes locais no todo, culminando na realizao do trabalho. Tambm os conhecimentos relativos a Sistema de Informaes, anlise de processos, identificao e resoluo de problemas e gesto de projetos tiveram grande contribuio. A metodologia orientada a objetos aplicada na resoluo do problema mostrou-se consistente e aderente questo levantada. Utilizando-se a linguagem UML, a funcionalidade dessa metodologia permitiu que os diagramas fossem realizados de maneira fcil, com um encadeamento lgico, o que acabou permitindo que fosse atingido o objetivo proposto. Cabe ressaltar que at o pleno funcionamento do novo Sistema de Informaes h ainda todo um trabalho a ser desenvolvido, uma vez que no faz parte do escopo deste Trabalho de Formatura as etapas de criao de uma arquitetura e implementao do novo sistema. Para estas etapas finais a Bresser tem a inteno de contratar uma empresa especializada na prestao deste servio, que siga os requisitos levantados nesse Trabalho e apresente uma proposta vivel tcnico e financeiramente para a realizao desta tarefa.
131
BIBLIOGRAFIA
ALTER, S; Information systems: a management perspective. 2 Edio Menlo Park. CA: Benjamin & Cummings, 1996. BLINDER, F. V. Sistemas de apoio deciso. So Paulo: Editora rica, 1994. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML Guia do usurio. Editora Campus, 2000. BUCKINGHAM, R.; HIRSCHEIM; R.; LAND, F.; TULLY, C. Information Systems Curriculum: A basis for course design. Information Systems Education: Recommendations and Implementation, Cambridge University Press, 1987. DALFOVO, O.; AMORIM, S. N. Quem tem informao mais competitivo. Blumenau: Acadmica, 2000. OBRIEN, J. Sistema de Informaes para apoio deciso gerencial. In: Sistema de Informaes e as decises gerenciais na era da Internet. So Paulo: Ed. Saraiva, 2001. PAULA FILHO, W. Engenharia de software. Editora LTC, 2001. MORESI, E. Delineando o valor do Sistema de Informaes de uma organizao. Ci. Inf., jan./abr. 2000. RUDGE, L., org. Dicionrio de termos financeiros. Santander Banespa, 2003. RUMBAUGH, J.; et al. Modelagem e projetos baseados em objetos. Editora Campus, 1994. SOMMERVILLE, I. Engenharia de Software. Editora Addison Wesley, 2003.
132 STAIR, R. Princpios de Sistema de Informaes: Uma abordagem gerencial. Rio de Janeiro : LTC, 1998. STONER, J. FREEMAN, R. Administrao. Rio de Janeiro : Editora LTC, 1999.