MAC 499 – Trabalho de Formatura Supervisionado

 

Aluna: Daniella Rios Sales

Supervisor: prof. Kunio Okuda

 

  1. Introdução 

2.   Natureza da organização e da atividade

  1. Definição/especificação do problema ou sistema principal de trabalho

3.1 Pontos de integração

3.2 Estrutura de hospedagem

3.3 Escalabilidade

            3.4 Eficiência  

            3.5 Segurança

            3.6 Comunicação

            3.7 Flexibilidade para Integração e customização

3.8 Principais Características

4.   Forma de organização da equipe de trabalho e atribuição de responsabilidades

  1. Estimativa inicial de prazos e do andamento do projeto
  2. Desafios e frustrações encontrados
  3. Ferramentas e técnicas utilizadas
  4. Diferenças notadas entre a forma de cooperação com colegas do Bacharelado em Ciência da Computação nas tarefas em grupo das disciplinas e a forma de trabalho conjunto da empresa
  5. Lista das disciplinas cursadas no Bacharelado em Ciência da Computação mais relevantes para o estágio
  6. Bibliografia utilizada ou básica para a área de atuação em que se insere o estágio
  7. Passos que tomaria para aprimorar os conhecimentos técnicos/metodológicos/ comerciais/científicos para a atividade

 

 

 

  1. Introdução

Nessa introdução farei um pequeno resumo sobre o meu primeiro estágio, em uma empresa de consultoria financeira. Explicarei o que me levou a mudar completamente de área de atuação.

1.1 A empresa

A Prandini, Rabbat & Associates é uma empresa especializada em soluções para risk-management, precificação e hedging de derivativos, asset allocation e risco de crédito. Presta serviços para as grandes instituições financeiras do país.

A PR&A desenvolve e implementa  soluções nas áreas de finanças, otimização, estatística e computação de modo a fazer face às demandas mais atuais do mercado.

1.2 O estágio

            Nos três meses e meio em que estagiei na PR&A (de fevereiro/2000 a maio/2000), participei do desenvolvimento de dois projetos.   

            O primeiro foi um software apenas para utilização interna (da própria empresa), mais precisamente da área de economia. Este programa necessitava de cálculos muito simples e de uma interface amigável e, por isso, foi desenvolvido totalmente em Delphi. Havia um banco de dados também bem simples, onde era possível armazenar fundos de aplicação financeira e suas características, como o "benchmark" a que ele estava associado, sua taxa de administração e de performance, etc. Era também possível armazenar as cotas diárias dos fundos e "benchmarks" cadastrados. Essas "alimentações" eram feitas a partir de arquivos no formato .xls, de modo a facilitar o trabalho dos economistas.

            De posse desses dados e de acordo com a necessidade do usuário, o programa realizava diversos cálculos que eram apresentados aos usuários em planilhas (permitindo que fossem salvos em formato .xls), e possibilitava a criação de três diferentes tipos de gráficos.

Este projeto teve a duração de aproximadamente cinco semanas, visto que um dos objetivos de sua realização foi a aprendizagem e familiarização do ambiente Delphi.

Já o segundo projeto foi mais amplo e complicado. Devido ao grande número de cálculos e sua complexidade, chegou-se à conclusão que deveria ser desenvolvida uma DLL em Visual C que realizasse todos esses cálculos. Depois que tivéssemos essa DLL, seria feita então a interface em Delphi.

O projeto foi dividido em duas partes: a primeira era uma simulação do Gap Atuarial em bancos (na área de previdência social) e a segunda parte era um problema de otimização do valor ativo do sistema. Durante quatro semanas estive desenvolvendo e testando a DLL para a primeira parte do projeto (simulação). Apesar de, a princípio, as dificuldades não parecerem muitas, tive alguns problemas com a velocidade dessa DLL, uma vez que eram realizadas, em média, dez mil simulações. Após muitos testes, o problema foi solucionado com a ajuda de professores que trabalhavam na PR&A.

Então, durante as outras seis semanas, novamente com a ajuda de professores, resolvemos o problema da otimização. Foi feita uma DLL que realizava os cálculos preliminares, ou seja, modelava o problema e devolvia suas restrições em forma de vetores e matrizes. Para resolver a otimização em si, foi utilizado o programa Gams (programa que resolve problemas lineares e não lineares).

        Além disso, apenas para efeito de testes, teve que ser desenvolvido um módulo em VBA (uma vez que os testes eram feitos a partir do Excel) que, com os valores devolvidos pela DLL, preparava o arquivo .gms, utilizado pelo GAMS.

        Devido às várias modificações do modelo econômico feito pelos responsáveis do projeto (a equipe econômica), o desenvolvimento dessa fase do projeto teve um atraso de duas semanas do inicialmente previsto, o que acarretou uma finalização apressada e impossibilitando a realização de todos os testes necessários. Houve então alguns problemas durante a apresentação dessas DLL´s ao cliente, que tiveram de ser resolvidos posteriormente.

            1.3 Frustrações

O meu interesse pelo mercado financeiro foi o principal fator que me fez começar o estágio na PR&A. Sempre achei que essa seria a área em que iria trabalhar depois de formada. Acreditava que estagiar nessa área me possibilitaria um maior aprendizado, considerando-se que teria de trabalhar em conjunto com profissionais de diversas áreas, principalmente economistas e estatísticos. Além disso, por não ser uma empresa especializada em informática, acreditava que uma equipe relativamente pequena nessa área implicaria numa integração maior ao projeto como um todo. Porém, foi um pouco decepcionante. Para a realização desse tipo de projeto, é necessária uma forte integração entre profissionais de todas as áreas envolvidas, o que é muito difícil de se conseguir. Por mais de uma vez houve modificação no modelo econômico durante o desenvolvimento do projeto, o que implicou na necessidade de recomeçar toda a programação. No entanto, os prazos raramente eram adiados, nos impossibilitando de realizar todos os testes necessários.

Acredito que esse tenha sido o principal motivo que me incentivou a procurar um estágio em outra área.

 

 

2. Natureza da organização e da atividade

A cada dia o número de usuários conectados à Internet cresce de forma expressiva e conseqüentemente o tempo que eles permanecem conectados também aumenta. Esta situação fez com que as empresas refletissem se o atendimento on-line que fornecem hoje realmente é eficiente e de qualidade. A necessidade de uma ferramenta que permitisse a um Web Center oferecer atendimento a clientes e suporte a vendas on-line, além de reduzir os custos de atendimento tornou-se evidente.

Ao perceber isso, a Ox Tech Internet desenvolveu um sistema para atender essas necessidades. Percebendo o grande potencial que o sistema possuía em relação a todos os outros meios de comunicação com clientes existentes, tomou-se a decisão de criar uma nova empresa dedicada exclusivamente ao Direct Talk e ao desenvolvimento de tecnologias para comunicação via Internet.

Em maio de 2000 a Direct Talk do Brasil Ltda. é fundada e inicia suas atividades na comercialização do sistema e no desenvolvimento de novas versões e recursos. Parte dos profissionais da Ox Tech Internet migraram para a Direct Talk formando uma equipe  para desenvolver tecnologias voltada  para comunicação via Internet.

A Direct Talk tem como principal parceiro a e-platform (www.e-platform.com.br), empresa incubadora de novos negócios em Internet que visa desenvolver empreendimentos em estágio inicial relacionados à Web. A e-Platform atualmente conta com sócios de peso: o Unibanco e o Brasil Warrant Venture Capital, do Grupo Moreira Salles, e o empresário Marcos de Moraes, vice-presidente do ZipNet.

 

 

3. Definição/Especificação do problema ou sistema principal de trabalho

O Direct Talk foi projetado para atender as exigências de flexibilidade, segurança e performance exigidas no atendimento real-time. Sua arquitetura simples é flexível permite fácil customização e a integração a outros sistemas.

 

Esquema geral

 

O sistema pode ser dividido nas seguintes partes:

 

 

O Servidor

O servidor realiza toda a troca de informações entre os usuários e os operadores. Tanto o usuário quanto os operadores se comunicam diretamente com o servidor, que armazena e distribui todas as informações.

O servidor é dividido em duas áreas principais:

- a aplicação, que recebe as informações e faz a comunicação com o banco de dados.

- o banco de dados, que realiza as operações e armazena os dados recebidos.

 

A aplicação roda sobre Windows NT e é uma DLL desenvolvida em Delphi. Funciona como um módulo adicional do IIS, executado via ISAPI. O gerenciador de banco de dados utilizado é o SQL Server 7.0, que armazena as informações e realiza uma parte grande do processamento via Stored Procedures.

 

Usuários

Os usuários acessam o sistema utilizando um browser comum. O sistema não utiliza nenhuma tecnologia que restrinja o acesso a algum tipo de browser, apenas HTML. O acesso pode ser feito por HTTP ou HTTPS. A primeira chamada é enviada a uma aplicação de Load Balance, que redireciona o atendimento para o servidor é responsável pelo atendimento.


 


Operador


Os operadores utilizam um programa local para realizar o atendimento. Este programa se comunica com o servidor utilizando HTTP.  Com este programa o operador consegue atender os usuários, criar as frases prontas para agilizar a resposta, limitar o número de diálogos simultâneos, etc.

 

 


Supervisor

Todo o atendimento fica armazenado no banco de dados. Existe uma ferramenta, exclusiva para os supervisores do atendimento, que permite que sejam realizadas diversas consultas a estes dados. O supervisor pode pesquisar e ver diálogos realizados, cadastrar operadores e consultar diversas informações do sistema.

 


 

 


Além das estatísticas, o supervisor pode cadastrar novos operadores, pesquisar diálogos realizados e ajustar outros parâmetros de configuração do sistema.

 

3.1  Pontos de integração

 

O Direct Talk está preparado para trocar dados com outros sistemas em quatro pontos principais:

 

  - Recebimento de dados através da interface do usuário

 

Funcionamento

 


No momento em que é iniciado um diálogo é possível enviar dados diretamente para o Direct Talk, a partir do site da empresa. Os dados são enviados via GET ou POST diretamente na chamada da tela de chat, podendo ser criptografados e enviados via SSL, para garantir um alto grau de segurança.

 


Possibilidades

Os dados enviados podem ser mostrados para o operador e utilizados para o supervisor realizar buscas, montar relatórios ou servir de campo de identificação para ligar as informações do cliente com outras informações armazenadas em sistemas da empresa.

Alguns exemplos de utilização: o envio automático do nome (quando o usuário já se identificou no site, ele não precisa se identificar novamente), número de cliente, número de conta/agência, produtos no carrinho, valor da compra em andamento.

 
  – Exportação dos dados a partir do módulo do Supervisor
 
Funcionamento

É possível exportar dados do atendimento e de pesquisas nos seguintes formatos de arquivo:

- CSV – formato de arquivo texto facilmente utilizável por programas como Excel e Access. Bastante simples para ser importado por outros sistemas.

- XML – padrão de mercado para troca de informações, este formato permite que os dados sejam trocados de forma estruturada e utilizados por outros sistemas.

 


 

 


Possibilidades
Os dados retirados do sistema podem ser utilizados para gerar relatórios específicos, enviar mala direta direcionada a um determinado público ou para armazenar os dados do atendimento juntamente com demais dados dos clientes em sistemas de CRM.

 

 – Software do Operador

 

Funcionamento

O programa de atendimento utilizado pelo operador pode se comunicar com outras aplicações para trocar informações em tempo real. Esta comunicação é feita através de um módulo de integração, que pode ser adaptado para se comunicar com diversos sistemas.

 

 

Diversas situações acionam o módulo integrador. Por exemplo:

- quando é finalizado um diálogo, é acionado um evento que envia todos os dados do atendimento realizado (operador, horários, frases trocadas, dados do usuário). Estes dados podem ser comunicados a um sistema de CRM, por exemplo.

- quando o operador pede o histórico do usuário, é acionado um evento que pode disparar uma outra consulta para ser mostrar dados adicionais para o operador, como uma lista das últimas compras feitas pelo usuário ou o seu saldo com a empresa.

- sempre que o operador se loga e desloga ou recebe um atendimento são gerados eventos, que podem comunicar o estado do operador a outros sistemas.

 

Possibilidades

Este tipo de integração permite que todos os dados do atendimento sejam armazenados em tempo real em sistemas de controle da empresa. Permite também que os operadores possam ter acesso a dados de outros sistemas na mesma interface do atendimento.

Por trocar dados através do software do operador é possível realizar uma forte integração com outros sistemas mantendo o modelo ASP, isto é, utilizando a estrutura de servidores da Direct Talk.

 

 - Servidor

 

Funcionamento

 

O servidor também pode ser integrado a outros sistemas com o objetivo de controlar o fluxo de chamadas em conjunto com outros dispositivos, como DACs e CTIs. Neste caso podem ser tomadas duas abordagens:

1 – A aplicação do servidor (1) pode ser customizada para rotear as mensagens baseado em dados de outros sistemas.

 

2 – Pode ser criada uma nova aplicação (2) que passa a ser a responsável pela distribuição de todas as chamadas. Esta aplicação pode trocar dados com outros sistemas e definir a melhor opção de roteamento. A aplicação original (1) continua responsável por todas as outras funções, menos por decidir para qual operador o usuário será direcionado.

 

 

 

 
Possibilidades

Este tipo de integração permite uma integração maior com sistemas de distribuição de chamadas, como DACs ou CTIs. É possível direcionar chamadas de voz e chat de forma a maximizar a produtividade dos operadores.

Para fazer esta integração, é necessário que o servidor esteja instalado diretamente na estrutura do cliente.

3.2 Estrutura de hospedagem

 

O sistema pode ser utilizado de duas formas distintas: utilizando os servidores e a estrutura da Direct Talk ou instalando o sistema em servidores da sua empresa.

Toda estrutura de servidores da Direct Talk está hospedada diretamente pela Embratel, na unidade da Lapa. Os servidores estão ligados em um link de 10Mb/s diretamente ao backbone da Embratel, garantindo máxima confiabilidade e mínimo tempo de resposta do sistema.

Esta estrutura tem como objetivo disponibilizar um altíssimo grau de confiabilidade e velocidade para os nossos clientes.

 

3.3  Escalabilidade

O sistema foi planejado para manter um alto nível de performance, tanto na plataforma de implementação quanto na otimização das consultas ao banco de dados. Além disso, sua capacidade poderá ser expandida de diversas formas:

 


I - Expansão dos servidores que realizam o processamento:

No primeiro acesso, feito somente para realizar um redirecionamento, é possível redirecionar tanto os usuários como os operadores para diferentes servidores, criando um cluster de servidores para processar as chamadas de um site, ou reservar servidores distintos para sites diferentes.

 

II - Expansão total do sistema:

Além disso, todo o sistema pode ser implantado em servidores distintos, para sites diferentes. O sistema acima poderia estar contido em provedores diferentes, com bancos de dados distintos para cada site.

 

3.4 Eficiência

 

Tempo de resposta

A aplicação que roda no servidor foi desenvolvida em Delphi, e funciona como um módulo do IIS chamado via ISAPI. Esta tecnologia garante alta performance e baixo tempo de resposta, em contraponto a outras tecnologias de script que são interpretadas e demandam maior processamento e tempo para gerar os mesmos resultados.

 

Banda

O tráfego de dados na rede é muito reduzido (tanto do lado dos operadores quanto dos usuários). Por utilizar um programa local, os operadores somente enviam e recebem as informações necessárias, de forma otimizada e sem comprometer a banda. Além disso, toda operação do programa e configuração de mensagens é feita localmente. Os usuários só realizam um refresh das mensagens quando necessário – se não houver mensagem somente uma minúscula página em um frame escondido é recarregada periodicamente.

 

3.5 Segurança

Toda a comunicação entre o operador e a aplicação é criptografada e assinada. A identificação do usuário (cookie) também é criptografada, datada e relacionada ao IP. Todas as páginas enviadas para o usuário podem ser enviadas utilizando-se SSL, impedindo a ação de invasores interessados em acessar diálogos ou fingir ser outro usuário.

A opção por implementar a aplicação utilizando o próprio IIS sem implementar um novo servidor reduz a preocupação com ataques diretos, como o de bombardeamento de pacotes, e dificulta a ação de pessoas interessadas em derrubar o serviço.

 

3.6 Comunicação

            Toda a comunicação entre o servidor e o usuário é feita via HTTP (ou HTTPS). Isto significa que não deve haver nenhum conflito com proxies ou firewalls corporativos.

O operador também utiliza somente HTTP para se comunicar. Isto também simplifica o processo de instalação (não necessitando modificar nenhuma configuração da rede) e aumenta a compatibilidade com redes locais.

 

3.7 Flexibilidade para Integração e customização

Há uma equipe de integração e customização que adapta essa solução às necessidades dos clientes. Diversas funcionalidades podem ser acrescentadas ou adaptadas.

Do lado do usuário, a geração das páginas funciona baseada em Templates. Cada site poderá ter a interface com o usuário totalmente personalizada, inclusive enviando dados para o sistema, como identificação do usuário (se ele já se logou), número da compra, produtos que estão no carrinho.

Para se integrar facilmente a outros sistemas, o Direct Talk está preparado para trocar dados em três pontos principais:

 
·        Módulo Supervisor: É possível pegar dados do atendimento em formato CSV ou XML, tornando simples a importação ou o processamento dos dados por outras aplicações.
·        Operador: O operador se comunica com um módulo integrador, que poderá transferir dados entre outras aplicações, para atualizar os dados em tempo real. Outras aplicações poderão utilizar funções do operador, via OLE, permitindo uma forte integração e possibilitando ainda manter o modelo ASP.

·        Servidor: O servidor também pode ser adaptado para trabalhar em conjunto com outros sistemas, como DACs, CTIs ou sistemas de CRM. Esta adaptação permite que sistemas externos controlem o fluxo dos usuários e a ocupação dos operadores.

 

3.8 Principais Características

As principais características do Direct Talk  são:

·        Atendimento Simultâneo – Os operadores podem a ate 6 clientes simultaneamente, podendo também controlar o numero de usuários com quem deseja manter conversação.

·        Administração de tempo de conversa - através de contador e barra de tempo os operadores podem se orientar sobre o tempo que cada usuário espera uma resposta.

·        Envio de imagens, links e arquivos - o operador pode enviar links, imagens e outros arquivos que possam auxiliar na comunicação.

·        Frases Prontas para Operadores - Questões freqüentes podem ser formatadas e inseridas ao sistema para agilizar o atendimento.

·        Histórico do Atendimento - Todos os atendimentos entre operadores e clientes são arquivados para consultas imediatas e relatórios futuros.

·        Envio de páginas para usuários - “Push Pages” - Os operadores podem abrir páginas web na estação do cliente.

·        Alarme para Operadores - Os operadores são alertados através de uma mensagem sonora e visual quando um novo cliente se conecta ou envia uma nova pergunta.

·        Transferência de Diálogos - Os operadores podem transferir seus diálogos para outros operadores durante a sessão de chat e também pode conversar reservadamente tanto com seu supervisor quanto com outro operador.

Além disso, há o módulo supervisor, que está disponibilizado via web para que o gerente/supervisor do site possa ter controle total do atendimento em seu site. O módulo supervisor oferece:

·        relatórios detalhados sobre os atendimentos;

·        diversas estatísticas sobre esses atendimentos;

·        possibilita a pesquisa do perfil dos usuários do chat;

·        permite o monitoramento dos atendimentos e a administração da equipe de operadores.

 

 

4. Forma de organização da equipe de trabalho e atribuição das responsabilidades

            Comecei a estagiar na Direct Talk em junho de 2000, quando a empresa ainda estava sendo montada, separando-se da Ox Tech. Já havia uma primeira versão do sistema pronta e a equipe comercial (que na época contava com apenas quatro pessoas) estava definindo as táticas de venda do produto. A equipe técnica era formada por cinco pessoas (todos alunos do IME), além de um dos sócios, Alexandre Bernardoni,  recém formado pelo BCC no IME.

            Existiam algumas pendências no sistema que precisavam ser solucionadas antes que o software começasse a funcionar em clientes. As mais urgentes eram:

-         a criação do módulo supervisor, que ainda não existia, mas as pressões da área comercial nesse sentido eram cada vez maiores; 

-         conserto de alguns “bugs” que o sistema ainda apresentava, o que tornava inviável sua instalação nos clientes;

-         a necessidade de reformulação da base de dados, que não guardava todos os dados necessários para a realização de pesquisas e estatísticas sobre os atendimentos realizados. Isso implicaria em varias modificações no sistema.

O módulo supervisor dependia totalmente da base de dados. Era necessário termos a base de dados definida até mesmo para sabermos o que poderia ou não ser feito. Por isso, a princípio toda a equipe técnica trabalhou junta para a definição da nova base de dados, uma vez que isso era necessário para podermos começar a solucionar todos os outros problemas. 

Depois disso, de acordo com as experiências anteriores e preferências de cada um dos 6 integrantes da equipe técnica, foram definidas as funções e prioridades de cada um. Eu fiquei encarregada da criação do módulo supervisor.

Nessa época a equipe comercial estava começando a venda do produto, e por isso não tínhamos nenhum contato com possíveis clientes. Mais tarde, quando o software começou a funcionar em diversos clientes foi necessária a realocação  de um integrante da equipe técnica que ficasse exclusivamente na área de suporte, atendendo problemas em clientes e ate mesmo participando de reuniões quando o cliente queria explicações mais específicas, que a equipe comercial não estava capacitada para explicar.

Desde outubro, quando a terceira versão do sistema (e do módulo supervisor) foi finalizada, comecei a integrar a equipe que faz a integração do sistema com as necessidades específicas de cada cliente. A partir de então tenho contato direto com clientes.

 

5. Estimativa inicial de prazos e do andamento do projeto

            Devido ao contrato entre a empresa e os investidores, as vendas do produto deveriam começar imediatamente. Portanto começamos o projeto com o prazo já “estourado”. A área comercial estimou um prazo de um mês para que o software começasse a funcionar nos primeiros clientes, então decidimos que começaríamos a trabalhar para que essas pendências estivessem resolvidas antes disso, ou seja, em um mês.

            Porém, o módulo supervisor ainda não estava bem definido. Deveria ser uma área de administração do atendimento do site, onde um supervisor pudesse cadastrar e alterar dados dos operadores (como nome, senha, horário de serviço, etc.), arrumar as configurações do atendimento (como a frase inicial a ser mostrada para o usuário, tempo que um usuário pode ficar conectado sem conversar antes que seja “derrubado” pelo sistema). O supervisor também deveria ser capaz de monitorar o atendimento, visualizando  diálogos, fazendo buscas (por data, por operador, por usuário, por palavra no dialogo), vendo tabelas com os diálogos em andamento, com os operadores conectados no  momento. Além disso, algumas estatísticas deveriam ser mostradas em forma de gráfico e tabelas.

            Foram então realizadas diversas reuniões entre a equipe comercial, eu e o Alexandre (sócio da empresa e integrante da equipe técnica), onde pudemos decidir quais eram os principais dados a serem disponibilizados, alem dos relatórios mais importantes. Durante essas reuniões foi decidida também a interface do supervisor. Assim, após aproximadamente uma semana de discussão, tínhamos uma primeira idéia do módulo supervisor, que deveria ser começado imediatamente.

            Com o tempo, as estimativas de prazos foram sendo feitas com mais cuidado, baseada em um cuidadoso planejamento e sem a interferência da equipe comercial. Já na equipe de integração, tenho contato direto com clientes e os projetos raramente são entregues fora do prazo.

 

6. Desafios e frustrações encontrados

No início do desenvolvimento do supervisor, a principal dificuldade encontrada foi a falta de uma documentação geral mais consistente sobre o sistema. A única documentação existente era os comentários de código e algumas definições do funcionamento do sistema. Não havia nenhuma referência sobre a base de dados. Durante as duas primeiras semanas, grande parte do tempo foi gasto no entendimento do banco de dados. Mais tarde foi tomada a decisão de que um de nós, de preferência alguém que estava desde o começo do desenvolvimento do sistema, parasse o que estava fazendo e documentasse tudo o que já havia sido feito.

            Além disso, tendo um contato maior com possíveis clientes, a área comercial começou a pedir novos gráficos e tabelas, modificando também alguns que já haviam sido previamente definidos. Isso acontecia constantemente e atrapalhava bastante o andamento do projeto. Porém, com o sistema já em teste nos primeiros clientes, ficou decidido que iríamos disponibilizar a primeira versão do módulo supervisor somente com aqueles dados e estatísticas que já estavam sendo feitos. A primeira versão do módulo supervisor ficou pronta cinco semanas após a sua definição e o início da implementação.

            Depois disso, foram feitas várias modificações pedidas pela equipe comercial. Foram inseridos novos gráficos e tabelas de comparações. Além disso, o supervisor tinha que estar sempre sendo atualizado de acordo com as modificações que eram feitas no módulo operador.

            O principal problema encontrado durante esse período de desenvolvimento aconteceu por falta de comunicação entre as equipes de desenvolvimento. Devido à implementação de novas funcionalidades no módulo operador, a base de dados foi modificada consideravelmente para que pudesse atender novos requisitos. Só ficamos sabendo das alterações depois de feitas e tínhamos um prazo muito curto para adaptar todo o supervisor antes do lançamento da nova versão. A área comercial não queria que a nova versão começasse a funcionar sem o módulo supervisor e isso atrasou o lançamento dessa nova versão.

            Em outubro foi lançada a terceira versão do sistema e as equipes começaram a ser realocadas devido ao início do desenvolvimento de um outro produto. Desde então saí da equipe de desenvolvimento do supervisor para integrar a equipe de  integração. Nessa época precisei ler toda a documentação já preparada e pude perceber que está sendo tomado um cuidado muito maior com a documentação do sistema. 

            Além disso, quando comecei o desenvolvimento do supervisor, não havia nenhuma especificação do projeto, do que realmente precisava ser feito. Tudo foi decidido em reuniões e anotado em rascunhos, o que dificultou bastante o desenvolvimento. Agora, em contato direto com clientes, tomamos cuidado para que as especificações sejam bem claras, tanto para nós quanto para os clientes e para equipe comercial. Isso ajuda também na definição dos prazos.   

           

 

7. Ferramentas e técnicas utilizadas

Havia a necessidade de nos preocuparmos com a segurança e sigilo dos dados de nossos clientes. O supervisor de cada site deveria ser capaz de ver somente as informações do atendimento do seu site. Portanto, ao entrar na área do supervisor seria necessária a autenticação de senha. Já tínhamos um algoritmo de criptografia que era utilizado para a autenticação de senha no módulo operador. Foram feitas apenas algumas modificações para criar uma  DLL que atendesse os requisitos do módulo supervisor. Essa DLL foi criada em Delphi, mesma linguagem utilizada no módulo operador.

 Para a coleta de todos os dados necessários foram criadas diversas Stored Procedures no SQL Server (banco de dados que era utilizado pelo sistema), uma vez que todos os dados eram guardados no banco de dados pelo módulo supervisor. Foi possível aproveitar diversas Procedures que já eram utilizadas pelo operador. 

Para a realização dos cálculos e disponibilização dos resultados (em forma de gráficos e tabelas de dados) via web foi utilizado ASP, HTML e JavaScript.

Desde que comecei a trabalhar com a integração do sistema, utilizo principalmente Delphi. Algumas vezes são necessárias algumas modificações  diferentes, e então utilizo ASP, JavaScript e HTML.

 

 

8. Diferenças notadas entre a forma de cooperação com colegas do BCC nas tarefas em grupo das disciplinas e a forma de trabalho conjunto na empresa

            Como já foi dito anteriormente, toda a equipe técnica da Direct Talk é formada por alunos do IME, o que sem dúvida facilitou muito o trabalho em grupo. Mesmo assim, a diferença entre o estágio e os trabalhos em grupo para a faculdade foi bastante acentuada. A maior delas é que  no estágio há uma individualidade muito maior que em trabalhos para a faculdade. Na faculdade nos importamos muito mais com o resultado final, afinal o objetivo maior é a nota, que depende do trabalho inteiro. No estágio, embora continue sendo importante o resultado final, podemos “fugir” da pressão ao terminarmos nossa parte.   

            Além disso, na maior parte do tempo em que estagiei na Direct Talk trabalhei sozinha. Isso se devia ao fato de a empresa ser de pequeno porte e, principalmente, ao pequeno número de funcionários na equipe técnica. Dificilmente programávamos utilizando as mesmas ferramentas. Apenas o planejamento de uma nova versão ou alguma grande alteração no sistema era feito em grupo e, depois de pronto, só voltávamos a nos reunir para quando havia a necessidade de modificação na base de dados, uma vez que qualquer pequena alteração influenciava no trabalho de todos.

 

9. Lista das disciplinas cursadas no BCC mais relevantes para o estagio

 

-         Sistemas de Banco de Dados: foi muito importante para a modelagem da base de dados.

-         Estrutura de Dados: o sistema usa diferentes estruturas de dados. A matéria foi fundamental na hora de decidirmos essas estruturas.

-         Programação Concorrente: durante todo o desenvolvimento do projeto, procurou-se levar em conta os problemas de concorrência. Utilizamos também vários conceitos vistos durante o curso.

-         Redes: por ser uma empresa voltada para o desenvolvimento de produtos para a internet, a matéria foi bem importante. Facilitou muito o entendimento de processos.

-         Engenharia de Software: apesar de acreditar que só muita pratica para realmente aprender engenharia de software, a matéria nos da uma boa introdução. Acho que deveria haver uma maior ênfase na parte de testes.

 

 

10. Bibliografia utilizada durante o estagio

 

-         Sistema de Banco de Dados   –   Henry F. Korth e Abraham Silberschatz                                                         McGraw Hill, Inc.

-         Transact-SQL Programming   –   Kevin Kline, Lev Gould & Andrew Zanevisk                                                                     O’Reilly

-         Professional ASP Techniques for Webmasters   –   Alex Homer                                                                               Wrox Press

-         ASP - Manual de referência rápida  –  A. Keyton Weissinger                                                                                 O'Reilly

-         JavaScript - The Definitive Guide   –  David Flanagan                                                                                               O'Reilly

 

11. Passos que tomaria para aprimorar os conhecimentos técnicos/metodológicos/ comerciais/científicos para a atividade

            Acho que não só nessa área, e muito importante haver uma divisão entre equipe comercial, técnica e de marketing. E claro que uma integração entre todas as áreas sempre tem que haver, mas há certos limites que precisam ser respeitados. Acredito que todos devem participar de reuniões para definições de prazos e projetos, mas acredito que depois disso nenhuma das equipes deve interferir no trabalho da outra. Durante todo o desenvolvimento do projeto, as equipe comercial e de marketing faziam diversas alterações no sistema, desde o layout ate seus gráficos e tabelas. Isso atrapalha e atrasa o andamento do projeto. Acho que uma vez definido, o sistema só deveria sofrer mudanças em reuniões e de comum acordo de todas as equipes.

            Alem disso, a manutenção constante de uma documentação consistente e imprescindível. Hoje em dia isso já e feito na nossa equipe e passou a facilitar as coisas para novos desenvolvedores.

            Outro problema continua sendo a definição de prazo: devido aos pequenos prazos estabelecidos, quase nunca há tempo para a realização de testes, o que faz com que o sistema seja comercializados com alguns “bugs”.