Esta monografia é sobre minha experiência de estágio na consultoria RiskOffice a partir do ano de 1999. Irei relatar as principais e mais interessantes atividades que realizei durante estes anos. Além disso, irei incluir na monografia, um trabalho que desenvolvi durante o 2º semestre de 2004 que é o sistema de simulação para ALM (Asset-Liability Management).

Todas as atividades que realizei no estágio têm relação direta com aquilo que aprendi no curso de Ciências da Computação do IME. Na monografia vou relatar as atividades de desenvolvimento de programas, modelagem de banco de dados e análise de sistemas.

Foram diversas as tarefas de desenvolvimento que tive durante o estágio no RiskOffice, porém, na monografia irei detalhar apenas três projetos que estive envolvido (relatórios de risco, relatórios de performance de fundos e Simulação ALM). Escolhi esses três trabalhos, pois foram neles que obtive o maior aprendizado e contato com diferentes ferramentas e tecnologias.

Na parte de modelagem de banco de dados irei falar sobre a experiência em modelar e otimizar um banco de dados desde o início e que possui atualmente uma grande utilização dentro do escritório.

Por fim, na parte de análise de sistemas irei falar sobre os desafios que eu tive estudando o código de outros programadores para encontrar maneiras de otimizar o tempo de certas aplicações.

A monografia está dividida em três tópicos (1.3 desenvolvimento de programas, 1.4 modelagem de banco de dados e 1.5 análise de sistemas) e cada um possui sub-tópicos com um texto comentando cada atividade. Como o tema de cada tópico são diferentes, as possíveis referências estão indicadas no final de cada sub-tópico para eventual consulta.

1.2 Empresa: RiskOffice

O RiskOffice é uma consultoria financeira que tem como principais clientes entidades de previdência privada, distribuidores de fundos de investimento e bancos.

A criação do RiskOffice foi objeto de Convênio assinado em 03 de maio de 1999 entre a ABRAPP e a FIPECAFI – Fundação Instituto de Pesquisas Contábeis, Atuariais e Financeiras, órgão de apoio institucional do Departamento de Contabilidade e Atuária da Faculdade de Economia, Administração e Contabilidade da Universidade de São Paulo, com apoio da RP&R.

A FIPECAFI tem entre seus objetivos a extensão de serviços à comunidade, tendo acumulado excepcional experiência na realização de dezenas de projetos para instituições públicas e privadas, nas áreas de contabilidade, finanças e atuária.

A RP&R – Rocca, Prandini & Rabbat, Financial Services – é empresa de consultoria especializada na prestação de serviços financeiros, com equipe de alta qualificação acadêmica e larga experiência no treinamento, desenvolvimento, implantação e consultoria de sistemas de gestão de riscos e carteiras de investimento. Esta equipe participa de programas de ensino e pesquisa em cooperação com a FIPECAFI.

Como resultado dessa parceria, o RiskOffice conta com a participação de professores e profissionais da FEA – Faculdade de Economia, Administração e Contabilidade, IME – Instituto de Matemática e Estatística e da Politécnica, instituições da Universidade de São Paulo.

A equipe de informática, inicialmente com um programador e um administrador de rede, é atualmente formada por seis programadores, um administrador de rede e é gerenciada pelo Roberto Masaishi, graduado e mestrando pelo IME. Em 1999 o quadro de funcionários era composto por seis pessoas, atualmente esse número está por volta de cinqüenta pessoas.

1.3 Modelagem de banco de dados

1.3.1 Início

O banco de dados do RiskOffice só foi modelado no final do ano de 2000. No início, todos os dados eram armazenados em planilhas eletrônicas e pequenos banco de dados espalhados pela rede.

Nessa época cada usuário criava uma planilha no Excel com os dados e resultados de sua análise. Esse método foi bastante utilizado pela maneira fácil de se colocar dados numa planilha, não sendo necessário criar uma interface (aplicativo) para colocar os dados num banco de dados e também não exige conhecimento de SQL, pois não as tabelas não são um banco de dados.

O fato dos dados serem armazenados em planilhas eletrônicas gerava três grandes problemas:

1. Consultas limitadas: No Excel não é possível gerar consultas elaboradas. As consultas eram limitadas, equivalentes a simples SELECT’s do SQL. Além disso, as consultas eram lentas, pois o Excel não é uma ferramenta para armazenamento de dados.

2. Consistência: No Excel os usuários não tinham a disciplina de respeitar o tipo do campo. Por exemplo, se foi criado uma coluna do tipo “Valor de Aplicação Mínima do Fundo” que é do tipo numérico, algumas vezes o campo era preenchido com “Não Há”, quando poderia-se criar um código “-1” (um negativo) para cadastrar esses registros.

3. Redundância: Existiam informações duplicadas na rede. Por exemplo, havia diversas séries histórias do preço dólar espalhados pela rede. Ou então, chegou a existir diversas listas de feriados sendo que algumas diferentes das outras.

Com o tempo, o número de clientes foi aumentando e começou a surgir problemas com essa distribuição de dados pelo escritório. Além de existir o risco de se gerar alguma análise com dados incorretos, pois não havia uma base de dados oficial que fosse, portanto, confiável.

Além disso, começou a existir uma grande necessidade de se criar um controle cadastral dos clientes para melhorar o fluxo de dados. Pois antes os estudos eram gerados para um único cliente e com o tempo esse relatórios passaram a ser criados para diferentes clientes, sendo que o formato e os cálculos eram os mesmos, apenas os dados de análise mudavam.

Então seria melhor criar rotinas que lessem os dados do cliente e atualizasse os dados do relatório, mas para isso foi preciso uma base de dados padrão. Com essa base de dados foi possível automatizar a geração dos relatórios. Ficando para o analista somente a responsabilidade de alimentar os dados do cliente dentro do banco de dados.

1.3.2 Desenvolvimento

Como estive no escritório desde o início, sabia como era o fluxo de dados do RiskOffice, o funcionamento de cada área (setor) e os problemas de gerenciamento de dados que existiam.

Levantei todos os dados que precisávamos, organizei esses dados em tabelas e modelei um rascunho de banco de dados chamado RO97. Em seguida, sentei com o responsável de cada área para discutir se o fluxo de dados funcionava bem e passei o modelo para o Access 97. O próximo passo foi desenvolver ferramentas para povoar e utilizar os dados do banco, mas nessa época a equipe já contava com três programadores para isso.

Infelizmente, modelei o RO97 quando estava no final do primeiro ano do curso do BCC. Teria feito um trabalho melhor se tivesse construído o banco de dados após cursar MAC0426 - Sistemas de Bancos de Dados (5o semestre) e MAC0439 - Laboratório de Bancos de Dados (8o semestre). Algumas alterações foram feitas no RO97 após eu entender o modelo relacional.

Veja no anexo 3.2 o relacionamento físico do RO97.

1.3.3 Manutenção

Hoje o RO97 se encontra em plena produção (veja o Anexo 3.1). E além do RO97 tivemos que criar algumas outras tabelas e outros bancos de dados auxiliares para o escritório. Os novos bancos de dados estão sendo criados em MySQL que tem se mostrado um gerenciador de banco de dados muito eficiente e robusto.

A próxima etapa é migrar o RO97 para o MySQL. Existe um bom conversor para isso, o DBTools Manager Professional. Só não conseguimos migrar ainda, pois existe um grande problema com o diferente tratamento das datas entre o Access e MySQL.

Por exemplo, essas duas consultas são equivalentes no Access:

1) SELECT * FROM planos WHERE data = 38200 (data juliana)

2) SELECT * FROM planos WHERE data = #2004-08-01#

E, infelizmente, utilizei em muitas páginas web e programas o formato Juliano para campos do tipo time/date nas pesquisas de SQL. E o MySQL só reconhece a segunda sintaxe. E revisar o código-fonte será algo demorado e estamos estudando como isso vai ser feito. Provavelmente, migrando-se as tabelas aos poucos, quando estiver bem mapeado o uso delas pelos aplicativos.

Referências

· Abraham Silberschatz, Henry F. Korth e S. Sudarshan, Sistema de Banco de Dados (Terceira Edição), Makron Books, 1999.

· Site do MySQL - http://www.mysql.com

· DBTools Manager Professional - http://www.dbtools.com.br

1.4 Análise de Sistema

Durante esse período de estágio, uma das atividades mais interessantes foi analisar o código-fonte de outros programadores para tentar otimizar o código.

Muitas vezes a baixa de performance de uma aplicação ocorria por pequenos descuidos que ocorriam durante o desenvolvimento de algum projeto com um prazo curto de entrega. No entanto, no longo prazo os usuários reclamavam da demora do programa.

Exerci várias atividades de análise de sistema no meu estágio. Os dois exemplos que escolhi para citar na minha monografia foram os que tiveram maior impacto na performance de tempo.

1.4.1 Matriz de Performance de Rentabilidade

A matriz de performance de rentabilidade é um relatório em MS-Excel que mostra a rentabilidade de um fundo de investimento em vários períodos.

O universo de fundos analisados pelo RiskOffice é de 1400 fundos.

Em sua primeira versão, o programa gerava uma matriz de performance em 8 segundos. O que é um bom tempo considerando o número de consultas e formatação do relatório. Mas para 1400 fundos, o tempo total de processamento era de 3 horas.

O programa é simples, tem poucas linhas de código, sendo que a maioria das linhas faz operações simples, mas operações lerdas. Principalmente na parte de formatação do relatório. Os comandos para pintar as linhas e formatas as células são muito demorados.

Descobri isso colocando vários checkpoints medindo o tempo de execução de cada trecho do programa. E a parte mais demorada era a parte da formatação. Então, idéia foi criar uma planilha modelo, que já estivesse formatada, sendo preciso apenas preencher os valores. Essa planilha pré-formatada é chamada de template.

Usando a idéia do template, o tempo por relatório caiu para 2,5 segundos. O que resulta num tempo de processamento de uma hora. Desses 2,5 segundos quase dois segundos é o tempo que o Excel leva para salvar o arquivo. Então, cheguei num ponto que otimizar o código não melhoraria muito o tempo total do processo e, por outro lado, o tempo final foi bastante animador para os usuários.

Essa matriz de performance de rentabilidade não é mais gerada pelo RiskOffice. Ela foi substituída por outros relatórios e indicadores. No entanto, a idéia do template foi utilizada em várias outras macros que ainda são rodadas no escritório.

1.4.2 Páginas WEB – SQL & ASP VB Script

Este exemplo de estudo de performance ocorreu num código que estava em produção desde o começo de 2002, mas só começou a apresentar problemas de lentidão no final do mesmo ano.

Isso ocorreu porque as tabelas acessadas pelo código em ASP estavam inicialmente vazias e mesmo com os problemas nas pesquisas SQL, o banco de dados conseguia retornar os resultados com um tempo imperceptível ao usuário.

Com o tempo a demora passou a ser de poucos segundos, mas logo o tempo da execução da página passou a ser de quinze segundos para depois estourar em algo em torno de dois minutos. O problema tinha um comportamento polinomial em relação ao tamanho das tabelas. O que tornou o uso da página web inviável para uma parte do sistema que era fundamental (envio das composições do cliente).

Não tenho documentado a modificação feita na época, mas o problema ocorria em alguns “SELECT” que não possuíam a seleção em suas consultas. A seleção era feita fora do gerenciador de banco de dados.

· Exemplo de seleção sendo feita no código em ASP:

Set oRs = oPerf.Execute("SELECT * FROM planos")

Do Until oRs.EOF

        If oRs("cod_cliente") = cod_cliente Then
            'faz alguma coisa
        End If

oRs.MoveNext

Loop

· Exemplo de seleção sendo feita no SQL:

Set oRs = oPerf.Execute("SELECT * FROM planos WHERE cod_cliente='" + cod_cliente + "'")

Do Until oRs.EOF

'faz alguma coisa

oRs.MoveNext

Loop

O resultado dos dois trechos apresentados é o mesmo, mas quando a seleção é feita por SQL, o tamanho do resultado da busca é menor. Então o fluxo de dados entre o gerenciador de banco de dados e o servidor web é conseqüentemente menor.

Vale comentar que o tempo realmente piorou para minutos quando uma das tabelas tinha aproximadamente uns 20,000 registros. E a indexação dessa tabela não melhorou em nada os problemas, o que era esperado, já que a busca retornava todos os resultados e não valia a pena indexar o banco de dados com esse comportamento.

1.5 Desenvolvimento

Algo peculiar nos códigos programados pelo RiskOffice é que nem sempre houve uma preocupação grande na completude (certificado que o programa rodará até o final, sem travar) dos programas desenvolvidos.

Como o usuário final sempre estava ao nosso alcance, quando o programa parava, poderíamos rapidamente ir até o usuário e depurar o problema. Algo que seria mais complicado se o usuário estivesse distante ou até mesmo fosse desconhecido. Essa característica é muito importante no desenvolvimento de sistemas comerciais, porém, nem tanto para ferramentas a serem usadas internamente.

Por outro lado sempre houve uma preocupação com a correção e consistência dos dados. As planilhas de validação sempre foram criadas em processos numéricos, pois como os códigos geravam resultados para relatórios financeiros, não podíamos deixar um valor errado ser exposto ao cliente.

Em nenhum projeto utilizei alguma tecnologia de ponta ou muito diferente das utilizadas pelo mercado. Basicamente utilizei o Visual Basic em 90% das aplicações. Sendo que para rotinas numéricas eram criadas DLL em Visual C++. Apenas na simulação do ALM, utilizei o Visual C++ por ser um projeto de alto processamento computacional e pela modelagem exigir orientação a objetos.

1.5.1 Relatório de Risco

O relatório de risco é o principal produto do escritório. Este relatório é um estudo do risco que uma carteira de ativos contém. O relatório de risco da consultoria RiskOffice é o mais completo do mercado, pois não calcula apenas o risco de um fundo de investimento, como mostra um relatório detalhando o risco do cliente.

O processo de geração do relatório pode ser dividido em três partes: “Tratamento de Dados”, “Cálculo de Risco”, “Geração de Relatórios”.

A parte de cálculo de risco é feito por um sistema externo ao escritório, o Maps. A minha participação foi nas partes de “Tratamento de Dados” e “Geração de Relatórios”.

Tratamento de Dados

A parte de tratamento de dados consiste em gerar arquivos textos de entrada para o sistema Maps. Esses arquivos devem conter as informações dos ativos de um fundo ou da carteira de investimento do cliente.

As informações dos ativos vêm de diversos bancos. Apesar de existir um padrão para o envio dessas informações (XML-Anbid), os sistemas de alguns bancos ainda geravam alguns arquivos com erros que são tratados pelo escritório.

Por causa desses defeitos, a leitura do XML é feita com um parser que programei - desenvolvido em Visual Basic mesmo. Esse parser não atende a todas as especificações do XML padrão, mas foi programado exclusivamente para a leitura do XML-Anbid e tem um monte de tratamentos de erros encontrados nos arquivos XML recebidos pelo RiskOffice.

A parte de tratamento de dados não consiste apenas em converter os dados para o padrão Maps. Nessa parte também criei verificadores (checkers) de dados para garantir que os dados enviados estão consistentes. Foram programados também utilitários que ajudam o analista compor (ponderar) uma carteira de fundos, pois o cliente sempre tem aplicações em mais de um fundo, então ele precisa saber o seu risco total e ponderado de sua carteira.

Geração de Relatórios

O sistema Maps exporta alguns arquivos textos com os resultados do cálculo de risco. A parte de geração de relatório consiste em pegar os dados desses arquivos e montar um relatório em MS-EXCEL e armazenar as informações num banco de dados.

Os relatórios são todos apresentados em arquivos do Excel. A geração e formatação do relatório foi toda desenvolvida em VBA (Visual Basic for Applications). A macro que gera o relatório tem aproximadamente 10,000 linhas de códigos. Para um sistema são poucas linhas de código, mas para uma macro é bastante.

Além dos dados que o Maps exporta, a macro em VBA consulta:

1. Algumas informações que o sistema Maps não possui em seu banco de dados (ex: composição do Ibovespa)

2. Outros dados que o sistema Maps começou a calcular em suas atualizações, mas que não são exportados para o arquivo de saída. Esses dados são pegos pela API (application program interface) do Maps.

Os dados armazenados em banco de dados são utilizados em outros relatórios que ficam disponíveis no site do RiskOffice. Com os dados armazenados em banco de dados é possível ter uma série histórica da evolução do risco da carteira do cliente.

1.5.2 Relatórios de Performance de Fundos

O relatório de performance de fundos mostra ao cliente o desempenho de um fundo de investimento. Para isso o relatório contém indicadores como rentabilidade, volatilidade, índice de sucesso e sharpe e gráficos que dão uma visão de como anda a performance de um fundo de investimento.

Gráficos das lâminas de performance de fundo

A primeira versão do relatório de performance de fundos era gerado por um software externo ao escritório (SmartFund). Inicialmente esse processo levava cinco dias úteis para se completar. E tinha como principal obstáculo a interação com o usuário, pois era preciso configurar muitos parâmetros para gerar as lâminas, ou seja, muitos botões eram pressionados. Além desse processo ser bastante entediante para o usuário, as configurações exigiam muita atenção do usuário.

A primeira solução que tive foi criar um script que automaticamente configurasse o programa para cada lâmina gerada. Com esse script preparado, podíamos deixar o programa rodando o final de semana inteiro para termos o resultado bruto no início da próxima semana. Assim, o tempo de geração dos relatórios caiu para dois dias úteis.

O script foi desenvolvido usando uma ferramenta que considerei bastante poderosa chamada Macro Scheduler. O seu script é baseado em eventos e tem na sua linguagem de programação comandos de controle (for, if, loop, goto, etc), comandos que retornam o estado da tela (janelas abertas, cor de um determinado pixel, etc) e comandos que enviam eventos para a janela (enviar uma tecla, abrir um programa, copiar um arquivo, clicar com o botão esquerdo do mouse, etc).

Abaixo um exemplo de script do Macro Scheduler:

//Make sure favorites window is closed
Let>WW_TIMEOUT=30
CapsOff
SetFocus>Display Smart
Wait>0.3

//Tab to target button and activate it
Tab*22
Wait>0.2
Press Enter
Wait>0.2

//Move mouse to location of bottom left corner of "Done"
MouseMove>23,733
Wait>0.2
LDown

No entanto essa solução durou por apenas um ano e alguns meses por dois motivos: (1) ocasionalmente o programa ou o Windows retornava um evento que o script não estava aguardando, portanto, o programa ficava travado nesse ponto. E a manutenção do script era trabalhosa. (2) começou a haver uma exigência que os relatórios ficassem prontos assim que os dados estivessem disponíveis. Os dados eram divulgados na sexta, no entanto, o programa ficava rodando no final de semana e o resultado final só estava disponível na quarta-feira.

A idéia, no início, era fazer um relatório on-line, mas tivemos que mostrar que pelo número de cálculos que eram necessários para gerar os gráficos tornava a idéia inviável para uma aplicação em tempo real.

Partimos então para a idéia de ter um banco de dados com os dados pré-calculados. Assim a página web apenas exibiria os dados já calculados. Portanto, a montagem da lâmina seria em tempo real de visualização.

O problema seria gerar os gráficos on-line, pois o ASP não tem extensões nativas para gerar gráficos. A primeira tentativa foi criar applets em Java para exibir os resultados, mas os gráficos ficaram feios comparados aos do SmartFund e a página pesada para o lado do navegador.

A ferramenta que solucionou o problema com os gráficos foi o TeeChart ActiveX. Ele é um OCX (OLE Control Extension) bastante flexível que gera diversos tipos de gráficos. E a iteração dele com o banco de dados foi simples.

Com isso substituímos o processo pelo Smart por um processo interno, muito mais customizado e rápido para as necessidades do RiskOffice.

Referências

· Macro Scheduler (mjtnet) –

http://www.mjtnet.com

· TeeChart ActiveX (Steema Software S.L.) - http://www.steema.com/products/teechart/ax/overview.html

1.5.3 Simulação ALM

Vou citar a simulação de ALM (asset and liability management) na monografia, por ser a tarefa de desenvolvimento mais interessante e com melhores resultados que realizei este ano.

O objetivo do projeto foi desenvolver um sistema que pudesse simular o passivo de uma instituição qualquer. Os clientes são fundos de previdência privada e , futuramente, seguradoras. O passivo destas instituições é o fluxo de caixa que eles estarão pagando aos seus participantes nos anos a decorrer.

O fluxo de caixa varia de acordo com duas variáveis principais que são o comportamento da população e as regras de pagamento de cada instituição. Então o objetivo do sistema é projetar o comportamento de uma população para daqui uns cem anos e observar o fluxo de caixa da instituição de acordo com as regras de pagamento.

O desafio em desenvolver o sistema não parece ser muito complicado. E realmente, modelar o sistema para um único cliente não é difícil. A dificuldade está em desenvolver um sistema que funcionasse para vários clientes. Como cada fundo de previdência possui um regulamento diferente, não seria viável ter uma versão diferente do programa para cada cliente.

A pessoa que estudou e elaborou o sistema foi o Gustavo Mello. O sistema dele tem vários pontos muito interessantes.

Na parte de desenvolvimento do simulador, o grande insight do Gustavo foi perceber que a simulação da população é igual para todos os clientes, pois todo mundo morre, tem filhos etc com uma certa regra bem definida.

O que varia para cada instituição é o regulamento dela. Então, o objetivo foi encapsular as regras de fluxo de caixa e criar um objeto chamado regulamento que tivesse uma interface padrão. Assim para cada novo cliente, só precisaríamos mudar a programação das interfaces de um único objeto.

Com o objeto regulamento já programado e com os dados populacionais da instituição já preparados, os inputs do programa são apenas o ano inicial, ano final e número de simulações. O resultado é armazenado em banco de dados e esses dados servirão para os analistas de passivo montarem o relatório. Veja no anexo 3.1 as saídas gráficas (barras de distribuição – candle boxs) das simulações do ALM.

Referências

A modelagem do Gustavo Mello foi baseada no artigo “An Object-Oriented Design for Dynamic Simulation Models” - Stephen J. Strommen (North America Actuarial Journal, Volume 1, Number 3).

Detalhes Técnicos

Utilizei o Visual C++ 6.0 para programar a DLL (Dynamic Link Library) que simulava o ALM. A interface com o usuário foi desenvolvida em Visual Basic 6.0.

1.6 Conclusão

Durante o estágio realizei tarefas bem distintas com ênfase em computação. Isso aconteceu por três motivos principais. (1) Estive por um bom tempo no RiskOffice (2) O escritório começou com uma área de informática pequena (3) tive interesse em todas as atividades.

A monografia não consegue se aprofundar em nenhum assunto em específico, mas mesmo assim não consegue listar todas as atividades que exerci em meu estágio.

Por exemplo, gostaria de citar um programa que fiz para o escritório que gerava uma análise diária publicada na Gazeta Mercantil. Decidi não citar esse trabalho por não ter nada de curioso, a não ser pelas contingências do projeto, por ser uma análise de publicação diária.

2. Parte Subjetiva

2.1. Considerações

Durante o meu estágio tive vários desafios a serem suplantados. Dentro desses desafios incluem além de questões tecnológicas, questões de prazo e interação com uma equipe de trabalho.

Como eu já citei, tudo que desenvolvi ou modelei no escritório foi para uso interno, portanto, eu não tive “clientes” externos, com raras exceções. Isso ajudou o progresso dos projetos porque as discussões não exigiam muitas formalidades. Em compensação, o feedback de algo que não estava funcionando era imediato.

Apesar de ter crescido muito, o RiskOffice ainda pode ser considerado uma pequena consultoria. A equipe de programação é pequena e não tive problemas de relacionamento com os membros da equipe. Muito pelo contrário, aprendi muitas coisas com meus companheiros de serviço. E devo agradecer ao coordenador da área, Roberto Masaishi, que criou um ótimo ambiente de trabalho.

Uma grande recompensa que tive no estágio foi olhar para uma sala e ver vinte pessoas com algo desenvolvido por você na tela do computador. Uma experiência muito interessante.

As grandes frustrações que tive no estágio ocorreram sempre que o meu universo acadêmico entrava em confronto com o meu dia-a-dia no RiskOffice. Como trabalhei durante todo o meu curso do BCC, foi difícil conciliar ambos. Todas as vezes que tentei sair do escritório foram por falta de tempo para me dedicar ao IME ou quando o trabalho estava desinteressante e havia algo no IME que me chamava mais à atenção. Felizmente, os meus coordenadores sempre foram flexíveis e contornaram a situação para que eu tivesse condições de levar o estágio e o curso do BCC juntos.

2.2 O curso do BCC e o estágio

O curso do BCC foi de extrema importância no meu estágio e no início da minha carreira profissional. E certamente aquilo que eu aprendi no BCC ainda me ajudará durante minha carreira, pois o curso de BCC do IME é teórico. E como cansamos de ouvir durante o curso, o importante não é conhecer a sintaxe de um comando de tal linguagem, mas o que está por trás daquilo tudo.

Não cheguei a usar muito daquilo que aprendi nas disciplinas que cursei. Por exemplo: não utilizei nenhuma estrutura de dados complicada nos códigos que desenvolvi no meu estágio. No máximo uma tabela de hash e uma busca binária. Como também não utilizei nada de grafos, exceto talvez árvores binárias que são grafos bem específicos. E provar a corretude de um programa, menos ainda. Entretanto, esses conceitos me ajudaram a entender idéias que solucionaram problemas práticos ou ter confiança que aquilo que eu estava desenvolvendo estava correto e eficiente.

Outras disciplinas teóricas como Cálculo I (MAT0111), Álgebra Linear (MAT0139) e Probabilidade e Estatística I (MAE0121) me foram úteis no estágio quando eu precisei entender algumas fórmulas e métodos a serem implementados. Essas fórmulas e métodos eram retirados muitas vezes de livros de finanças.

Agora, as disciplinas mais importantes devido à natureza do meu estágio foram: Princípios de Desenvolvimento de Algoritmos (MAC0122) e Sistemas de Bancos de Dados (MAC0426).

Naturalmente tive que cursas algumas disciplinas que não me ajudaram em meu estágio. Por exemplo, Álgebra II (MAT0213) faz parte da grade curricular por ser uma matéria que ensina o rigor matemático em uma demonstração e para o aluno conhecer algumas estruturas básicas de álgebra. Mas o curso se prende em tantos detalhes que pelo menos eu tive muita dificuldade em reconhecer o que eu precisava realmente entender de Álgebra II.

2.3 Conclusão

Tenho como objetivo dar ênfase em minha carreira como analista de sistemas. Em meu estágio tive a oportunidade de experimentar algumas áreas que um aluno do BCC está preparado para assumir. Sinto falta de ter tido experiência como “pesquisador”. Talvez terei algum contato com isso em uma pós-graduação.

Por outro lado, não gostei da experiência de ser apenas programador. Não é muito excitante apenas digitar trechos de código para um sistema que já está modelado e bem especificado. É uma impressão de se estar passando a limpo idéias de outras pessoas. Como também não é interessante programar apenas “janelinhas” para um programa.

No estágio sempre gostei de desafios e encarar missões, desde que não fossem absurdas. Não ter uma resposta instantânea para um problema sempre me fez ir dormir buscando uma solução. E é isso que eu atualmente quero fazer. Sem dúvida alguma o BCC me ajudou a definir esse perfil de carreira.

Por fim, assim que eu me formar pretendo estudar e fazer cursos para aprimorar os meus conhecimentos técnicos. Cursos bem específicos de algumas tecnologias. Pois como ouvi muitas vezes no BCC: quanto maior o seu “arsenal”, mais fácil solucionar um problema.

Depois de ter cursado três anos de engenharia elétrica e desistido do curso e, em seguida, ter cursado a graduação do BCC, tenho certeza que fiz a escolha certa. Posso ter demorado a encontrar o curso ideal para mim, mas estou feliz pela escolha. Que não foi um apenas um curso, mas uma diferença em minha vida.