Aluno: Adriano Lopes PereiraNúmero USP: 2957488 Supervisor: Prof. Dr. Arnaldo Mandel
Como tema do trabalho de formatura, optei por estágio supervisionado na
Spectrum Engenharia.
Sobre a empresa:
A Spectrum Engenharia é uma empresa especializada em soluções utilizando tecnologias
orientadas a objetos (J2EE), gestão de projetos, dentre outras atividades.
A Spectrum iniciou suas atividades atuais em 1989, como uma empresa voltada para
aplicações de Inteligência Artificial.
Seus fundadores, Edson Fregni e Josef Manasterski, ambos formados em engenharia
elétrica pela Escola Politécnica da USP, foram também os fundadores, em 1975, da Scopus
Tecnologia, uma empresa que se destaca no cenário nacional pela liderança e inovação
tecnológica.
A Spectrum sempre se dedicou à aplicação de novas tecnologias de informação na
solução de problemas e na exploração de oportunidades no ambiente empresarial. As
soluções baseadas em sistemas especialistas evoluíram para sistemas distribuídos
de forma geral, e mais recentemente para a adoção de desenvolvimento baseado em
componentes e as novas tecnologias voltadas para a Internet.
A empresa Conta hoje com um grupo de mais de 50 profissionais da informática
dedicados ao desenvolvimento de produtos com alto padrão de qualidade. Atendendo,
assim, às mais altas exigências do mercado, e priorizando a total satisfação de seus
clientes.
Descrição do projeto:
O sistema de faturamento é parte do sistema de back office em desenvolvimento
pela Spectrum Engenharia para a Carlson Wagonlit Travel (CWT), agência de viagens
pertencente ao grupo ACCOR e com foco no mercado corporativo de viagens.
O desenvolvimento sob encomenda de um novo sistema de back office para a CWT se
faz necessário pelas seguintes razões:
O sistema atualmente em produção funciona numa plataforma tecnologicamente
obsoleta (CLIPPER), não componentizada, e inadequada para lidar com o volume de dados
e facilidade de evolução que a empresa necessita;
A oferta de softwares de back office para agências de turismo de
grande porte é nula, pois o mercado de turismo é muito fragmentado. O que não torna
o desenvolvimento fácil quando se trata de encontrar padrões comuns a todas as
empresas atuantes nessa área.
Há inúmeras peculiaridades nos processos de negócio dessas agências de turismo que
tornam tais softwares muito específicos;
A CWT tem expandido agressivamente suas atividades no mercado brasileiro, por meio
de aquisições, tornando a WEB o ambiente adequado para o funcionamento de seu softwares de
back office.
A CWT optou pela plataforma JAVA como padrão para as aplicações desenvolvidas
para a companhia, contando com a consultoria da Spectrum Engenharia, definiu-se pelo J2EE
e pelo servidor de aplicações J2EEWebLogic da
BEA como sendo o ambiente de produção e utilização do produto
final.
O sistema funcionará em ambiente WEB, na EXTRANET da CWT, que hoje contempla 150
pontos de venda espalhados e tem se expandido muito rapidamente.
O sistema foi projetado em camadas:
Uma camada de apresentação, implementada em JSP;
Uma camada de controle e interface entre o ambiente WEB e os componentes
Enterprise JavaBeans, que rodam no servidor de aplicações. Tal camada foi
implementada usando-se Servlets;
Uma camada de lógica de negócio, implementada com componentes Enterprise
JavaBeans do tipo Stateless Session Beans;
Uma camada de persistência dos dados implementada com componentes Enterprise
JavaBeans do tipo Entity Beans.
O sistema é conceitualmente muito simples. A partir da informação contida em
Vouchers eletrônicos (reservas de hotéis, locações de carros, dentre outras
despesas do funcionário em viagem), e respeitando as definições de perfis comerciais dos
clientes são geradas, em bases de dados, e posteriormente impressas as faturas, notas
fiscais, boletos bancários para pagamento e outros documentos. Bem como documentos
eletrônicos, como faturas eletrônicas e registros que fazem interface com o sistema
ERP (Enterprise Resource Planning) da CWT.
Como a solução proposta para o sistema utiliza thin clients (terminais) via web, a
implantação do sistema em qualquer ponto que disponha de acesso à INTERNET pode ser
feita sem necessidade de instalação local. Da mesma forma, qualquer evolução do sistema
estará também imediatamente disponível a todos os clientes, sem necessidade de nenhuma
atualização local do software.
Esses fatores, combinados com a facilidade de navegação inerente ao ambiente web,
permitirão à Carlson Wagonlit disseminar rapidamente o sistema tanto ao longo dos atuais
pontos de venda ou administrativos do grupo CWT quanto permitir que
novas empresas eventualmente incorporadas à Carlson Wagonlit Travel possam rapidamente se
integrar às soluções de software desta.
O desenvolvimento componentizado e orientado a objetos foi elaborado de forma a
permitir que uma provável evolução do sistema se dê de maneira mais natural, fazendo
com que o trauma gerado pelas mudanças nos processos de negócio realizados pelo software
seja minimizado. Se possível eliminado.
Entretanto, o conjunto de regras de negócio é muito amplo, e estas em diversas
situações são muito complexas. Por conta disso, a captura de requisitos exigiu grande
esforço, bem como o projeto inicial, implementações e não menos importante a fase de testes
e homologação do software entregue ao cliente.
Atividades realizadas:
Quando eu entrei para a equipe, não havia muita coisas funcionando no projeto, ou seja,
havia muito código escrito, códigos bons, claro, mas que não estavam totalmente
integrados entre si (na minha opinião um dos erros mais graves do projeto), já que pela
forma escolhida para o desenvolvimento (isso na fase de modelagem do sistema, creio eu)
os componentes ficaram extremamente dependentes uns dos outros, ou seja, havia muita
comunicação e delegação de tarefas entre as diversas partes, muito além do necessário.
Caso uma dessas partes falhasse de forma anormal, poderia causar erros diversos em todo
o sistema. Sendo que, na maioria das vezes, não era nada fácil rastrear e solucionar
tais erros.
Essa foi uma das maiores dificuldades para que eu me adaptasse ao sistema, e era também
uma dificuldade para toda a equipe na hora de solucionar um erro "novo"
encontrado. Isso era notório, ou seja, sempre que um erro era detectado, o esforço feito
para resolvê-lo era tremendo.
Assim sendo, o software não podia ser testado como um todo. Não antes de todos os módulos
estarem prontos e funcionais. Apenas partes individuais eram testadas, e pelos próprios
desenvolvedores.
Como no inicio do estágio eu não conhecia a plataforma J2EE usada no
desenvolvimento, fiquei estudando a teoria por detrás dela. E também olhando alguns
códigos já feitos. Isso durante as primeiras semanas de trabalho.
Depois do período de adaptação, comecei a programar alguns JSP´s para completar as
páginas HTML que formavam as interfaces do sistema com os usuários finais.
Tais páginas se comunicavam com os respectivos Servlets através de código JAVA colocado
dentro delas. Comecei também a ajudar na busca e solução dos erros desses Servlets.
Os Servlets faziam uma primeira validação dos dados fornecidos pelo
usuário, ou seja, verificavam se os valores passados eram coerentes com o que se esperava, por exemplo, uma string onde era esperada uma string, ou então uma data
válida (dentro do intervalo esperado e na formatação adotada dd/mm/aaaa -
dia/mês/ano).
Após essa primeira validação os dados eram passados a um
Session Bean que por sua vez fazia uma segunda validação, só que agora um
pouco mais rígida, ou seja, verificava na base de dados se poderíamos, num futuro muito
próximo, gravar tais valores ou se havia algum problema desde já detectado. Um dos
vários problemas que poderiam vir a acontecer nesse momento seria, por exemplo numa
geração de faturas, o número da fatura gerada já existir na base de dados. O que
impossibilitaria a gravação dessa fatura na base.
Caso tal fatura fosse gravada, isso causaria duplicação dos valores de algum
campo importante ou mesmo uma chave dalguma das muitas tabelas na base de dados.
Finalmente, se o Session Bean validasse tais dados, estes seriam passados para o
Entity Bean correspondente, que por sua vez faria uma última validação garantindo
a consistência antes de persistir tais dados na base.
Tantas camadas de validação eram usadas para primeiro, garantir que os dados chegariam
coerentes e corretos à base, depois diminuir ao máximo o tempo gasto para descobrir um
possível problema com esses dados. Todas essas validações poderiam ser feitas apenas nos
Entity Beans usados, mas se o usuário digitar uma string no lugar de um inteiro,
por exemplo, só descobriríamos isso ao tentar gravar a fatura na base, ou seja, depois de
fazer com que o usuário perdesse tempo preenchendo vários campos com dados e aguardando
os resultados nas interfaces subsequentes às entradas de dados. E principalmente haveria
uma sobrecarga de testes para validações nos Entity Beans, o que deixaria o sistema
muito mais pesado do que o necessário.
No uso de várias camadas de validação, deve-se tomar o cuidado de não ficar repetindo os
mesmos testes em todas as validações, o que tornaria o sistema muito mais lento que o
necessário. Haja visto que os dados já passaram por algum filtro, logo não é necessário
repetir os mesmos teste novamente. Exceto em situações muito especiais, nas quais seria
necessária uma nova validação.
Quando, em alguma dessas validações, ocorria algum problema, era lançada uma exceção
correspondente ao erro. Essa exceção era "levantada" até chegar ao JSP correspondente e
ser exibida ao usuário, na forma de uma mensagem amigável (ou nem tanto) informando-o
sobre o ocorrido, indicando a causa e uma possível solução para o problema.
Depois de algum tempo eu já estava me sentindo bem mais à vontade com as estruturas usadas,
padrões adotados para a codificação e principalmente com o projeto em si. Mas, infelizmente
para alguns, a equipe passou por uma mudança necessária e nada agradável.
Antes todos éramos desenvolvedores, como já mencionado, cada um testava o seu próprio
código, não existia uma equipe de testes. O que, do ponto de vista de Engenharia de
Software, não é uma prática muito aconselhável.
Assim sendo, foi montada uma equipe com a função de aplicar testes no sistema e reportar os
erros encontrados. Alguns dos desenvolvedores foram "transferidos" de cargo.
A equipe toda era composta pelas seguintes pessoas:
Adriano Lopes Pereira
Alexandre Guimarães
Alexei Znamensky
Daniella Oliveira
Darci Filho
Edmundo Barbosa (gerente do projeto)
Fábio Incecco
Fábio Kimura (entrou no final do projeto)
Roberto Carvalho
Roberto Barra
Rodrigo Júdice
Sebastião Alessandro
Depois da divisão as equipes ficaram da seguinte forma:
Desenvolvedores: Todos, menos Adriano Lopes Pereira
"Testadores": Adriano Lopes Pereira
Ou seja, alguém tinha que ficar com a pior parte, quem melhor do que o desenvolvedor que
sabia o suficiente do projeto e, de quebra, era o menos ligado aos códigos já escritos?
Foi o que aconteceu, fui transferido para a parte de testes.
Precisei elaborar vários tipos de testes e passar a aplicá-los freqüentemente ao sistema.
Reportando todos os erros encontrados aos responsáveis por cada parte problemática.
Cobrando destes uma solução no menor tempo possível, levando em conta a gravidade do
erro para traçar tal prazo, ou seja, problemas menos importantes tais como erros de
apresentação dos dados, problemas na formatação das tabelas, dados sendo exibidos mais
de uma vez nas tabelas apresentadas aos usuários, erros causados por inconsistências na
base de dados (veja bem, erros causados por inconsistências, não erros causadores destas)
obviamente tinham uma prioridade muito menor do que aqueles vitais ao funcionamento do
sistema. Ou seja, sempre que uma exceção era lançada, a solução desse
problema deveria ser quase que imediata, ou o mais breve possível. E cabia ao responsável
pelos testes garantir que tal erro realmente havia sido corrigido e, que no futuro não
voltaria a ocorrer.
Mas isso aconteceu muitas vezes, ou seja, aquilo que havia sido testado e que estava
funcionado perfeitamente a algum tempo atrás, de repente não mais funcionava.
O motivo disso devia ser encontrado e precisava ser corrigido o mais rápido possível.
Esses, definitivamente, eram os problemas mais chatos (nem sempre os mais difíceis) a
serem abordados, pois ninguém gosta de receber uma mensagem indicando um erro naquilo
que a pouco havia sido anunciado como finalizado e funcionando. Felizmente isso não chegou
a afetar profundamente a equipe.
Esse período como único componente da equipe de testes durou bem mais do que qualquer
um gostaria, ou seja, a sobrecarga de trabalho foi grande pois, como dito, o
sistema não estava nada bem quando os testes começaram. Ou seja, havia muitos erros,
muitos erros mesmo.
Com o passar do tempo a poeira foi baixando e as coisas começavam a funcionar como o
esperado, e o trabalho foi tornando-se mais humano.
A base do sistema, ou melhor, toda a interação com o usuário é feita através de interfaces
WEB, não era possível o uso de scripts automáticos para a execução
dos testes, mesmo esses sendo repetitivos, chegando ao extremo de serem refeitos três vezes
ao dia e falharem em todas as três vezes. A cada vez um motivo diferente.
Não sei dizer ao certo quantos roteiros diferentes de testes foram elaborados e
muito menos quantas vezes foram aplicados ao sistema. Mas uma coisa é certa, somavam mais
de 150 (cento e cinqüenta) roteiros distintos entre si que deviam ser aplicados com o mínimo
intervalo de tempo possível entre cada teste do sistema. Gastava-se, no máximo, dois dias
para executar todos os roteiros e reportar as falhas encontradas aos desenvolvedores.
Além da aplicação dos testes, era fundamental uma boa metodologia para manter o controle
sobre o que já tinha sido testado, o que estava sendo testado a cada momento, qual a
política de testes adotada e, principalmente, uma metodologia eficiente para manter o
controle sobre o que já tinha sido corrigido e precisava sofrer uma nova bateria de
testes, além das habituais e o que definitivamente estava funcionando e pronto.
Essa metodologia não me foi passada, eu mesmo tive que pensar e montar uma que se
adequasse. Pude aperfeiçoar com o passar do tempo essas metodologias e as críticas que recebia
dos desenvolvedores junto com as experiências frustradas daquilo que não funcionava como
imaginei ao elaborar cada metodologia, me fizeram crescer muito e solidificar alguns conceitos
aprendidos na sala de aula. As alterações sofridas nos processos foram inúmeras, e não eram as
mesmas para todos os testes, ou seja, havia conjuntos de testes que seguiam parâmetros
diferentes entre si. O que dificultou o amadurecimento dessas metodologias e dos respectivos
relatórios de testes.
A forma pela qual os erros eram reportados aos desenvolvedores foi outra tarefa nada
simples, pois mesmo nunca tendo trabalho numa equipe de testes antes, estando acostumado
apenas aos testes de desenvolvedor, foi preciso montar um padrão para reportar tais
erros pois não me foi passado um padrão para isso, foi necessária a formulação de tal
metodologia, a qual pude aprimorar à medida que eram recebidos retornos dos
desenvolvedores dizendo se estava ou não clara a forma pela qual o erro fora encontrado e
como eles deveriam proceder para reproduzir aquele estado do sistema. Isso não foi nada
simples como aparentava ser. A língua escrita, principalmente quando se precisa ser
breve e conciso naquilo que se escreve, permite interpretações diversas dependendo de como
se lê um determinado texto. O que pode causar inconvenientes e mal entendidos entre as pessoas.
Nem sempre o que é claro para aquele que escreveu é claro para aqueles que lêem.
Depois de muito trabalho. De ter feito e refeito os testes muitas vezes, o sistema
finalmente ficou estável, pouquíssimas partes apresentavam problemas, e mais raros
ainda eram os erros graves que surgiam, na grande maioria das vezes eram erros simples.
Tais como formatação ou apresentação dos resultados, erros nas mensagens exibidas aos
usuários ou outros tipos de erros nada graves, mas que precisavam ser resolvidos
antes de entregar o projeto ao cliente.
A partir desse ponto, havia outra preocupação, a montagem do manual do usuário.
De início, cada desenvolvedor ficou responsável por fazer o manual relativo àquilo
que fez. Mas como o tempo era curto, e não estavam sendo encontrados tantos erros no
sistema, eu dispunha de tempo e poderia sofrer uma nova alocação, continuei responsável
pelos testes, mas agora também pela construção de partes do manual.
Essa foi a pior parte de todas, eu precisei escrever, coisa que nunca foi uma de minhas
paixões. Durante os testes eu pelo menos mantinha um contado freqüente com os
desenvolvedores e com os códigos que por eles estavam sendo escritos, também era minha
atribuição garantir que os erros encontrados, antes mesmo de reportá-los, não ocorriam
por inconsistências na base de dados. Nesse caso, os procedimentos deveriam ser outros,
havia uma pessoa inteiramente responsável por alterações na base de dados.
Pontos positivos e negativos do estágio:
Quando fui contratado pela Spectrum Engenharia, a proposta era a montagem de um grupo
de profissionais capacitados para o desenvolvimento de softwares na plataforma
UNIX, principalmente GNU/Linux.
Mas ao chegar lá, como o referido grupo ainda não estava completo e, principalmente, por
não haver projetos contratados nessa área, fui alocado para o grupo de desenvolvimento em
J2EE, que no momento estava com déficit de pessoal.
Essa idéia me agradou muito pois poderia colocar em prática muito do que eu havia
estudado na faculdade com relação a Orientação a Objetos e modelagem de sistemas.
Também o fato de trabalhar em uma equipe relativamente grande, onde cada um conhece um
pedaço do sistema, poucos são aqueles que conhecem o sistema como um todo, e principalmente
trabalhar com quem não se conhece, não se tem intimidade suficiente para receber ou fazer
críticas. Isso tudo seria uma experiência nova e intrigante.
Mas infelizmente não tive a oportunidade de ajudar na modelagem do projeto, pois tudo
já havia sido feito antes que eu entrasse para a equipe. Só que o modelo não foi muito
bem preparado, ou seja, havia falhas graves no projeto.
Não sei ao certo as razões e nem vêm ao caso discuti-las aqui, mas o fato é que o
projeto tinha muitas falhas. Não foi feita uma análise de requisitos confiável, o modelo
da base de dados era cheio de problemas, talvez porque não éramos os únicos a usá-lo ou
mesmo por falhas na modelagem, ou até mesmo por um misto dos dois. O fato é que toda e
qualquer alteração nesse modelo deveria ser discutida com as outras equipes envolvidas.
Por esses motivos e alguns outros, o modelo não era simples de se usar e não muito adequado
às nossas verdadeiras necessidades.
Mas, definitivamente o que mais me deixou triste foi o fato de ter sido alocado para a
equipe de testes, o que dificultou o aperfeiçoamento de meus conhecimentos em
J2EE. Mas por outro lado, esse fato me permitiu aprender muito sobre metodologias
e políticas a serem seguidas para se testar um sistema em desenvolvimento, bons modos de
se reportar erros encontrados, como manter um controle do que se fez e o que se deve fazer
a cada momento.
O fato de não ter recebido nenhum plano de testes já feito, de ter sido o responsável
pela elaboração, tanto do plano quanto dos próprios testes sem ter alguém mais experiente
como coordenador me obrigou a um amadurecimento muito rápido quanto a esses aspectos, eu
não poderia errar com freqüência, e quando errava, era o único responsável pelo erro,
tendo que arcar com os custos, ou seja, com horas de trabalho pesado para, além de dar
conta dos testes programados para aquela data, corrigir o que havia errado numa data
anterior sem prejudicar o andamento do projeto, ou com o mínimo de prejuízo possível.
Na Spectrum tive a oportunidade de tomar mais contato com ferramentas muito usadas no
mercado de trabalho. Tais como Microsoft SQL server, ERWin, OptimizeIT,
Visual Cafe, Visual SouceSafe, Enterprise Arquitect, dentre outros.
Com isso pude notar que a adaptação a essas ferramentas é muito rápida, muito mais
rápida e indolor do que pensava. havia antes preocupações a esse respeito, como por exemplo
se conseguiria aprendem em tempo hábil a usar uma ferramenta desconhecida até então. Tais
preocupações não mais existem, não depois desse estágio.
Desafios encontrados:
Acredito que o maior de todos os desafios que encontrei na Spectrum não foi o fato de ter
que me adaptar rápido a tarefas que nunca tinha feito antes, mas sim o fato de ter que
escrever relatórios de uma forma que outras pessoas pudessem ler bem rápido e com uma
compreensão suficientemente boa, ou seja, sem interpretações erradas.
Definitivamente isso não foi fácil. No começo os relatórios escritos não eram nada bons,
mas acho que ao final do projeto, consegui aprender algo, pelo menos as pessoas não mais
reclamavam de meus relatórios. Espero que não pelo fato de terem se acostumado a eles,
mas sim porque estes estavam realmente melhores.
Matérias importantes:
Para mim, as matérias mais importantes foram as de lógica de programação, tais como
MAC122, MAC323, MAC211 (nessas duas últimas foi onde comecei a
conhecer e a gostar de JAVA). MAC426 por me ensinar a apreciar um bom modelo de
base de dados.MAC448 pelo aprendizado em programação cliente-servidor.
E principalmente MAC332, onde aprendi (ou deveria ter aprendido) muito daquilo
que usei durante o projeto CWT001.
Agradecimentos:
Gostaria de agradecer a alguns amigos que me ajudaram durante o estágio respondendo
às minhas dúvidas, indicando fontes de pesquisa e estudo ou mesmo encontrando os erros
cometidos durante a redação deste texto. Erros esses que não foram poucos, diga-se de
passagem.
São esses (em ordem alfabética):
Fábio Kimura
Fábio Pará D'Incecco
Flávio Luiz Coutinho
Roberto Pires de Carvalho
A todos esses, o meu muito obrigado por tudo. Principalmente pela amizade e paciência.