O Projeto

 

Home

Parte técnica:O Projeto J/XFS A Empresa Bibliografia

Parte subjetiva:O Curso do BCC BCC x Estágio Desafios Considerações

 

 
 

 

O Projeto

INTRODUÇÃO   |  CRONOGRAMA  |  TREINAMENTO  |  MINHA PARTE NO PROJETO  

 FERRAMENTAS  |  TÉCNICAS  |  AMBIENTE DE TRABALHO E METODOLOGIA   

 
 
 
 
bullet
A Diebold Procomp é uma empresa que produz Hardware e Software para diversas áreas do mercado, em particular para o setor de automação bancária.
 
Os dispositivos físicos são desenvolvidos pelo setor de Engenharia da empresa, que fornece juntamente com os mesmos uma Application Programming Interface (API) de baixo nível. Essa API é intrínseca ao hardware produzido e não segue um padrão pré-definido.
 
Por outro lado, os clientes que desenvolvem as aplicações para interagir com o Hardware, em um cenário ideal, gostariam que o mesmo pudesse ser usado de maneira transparente, ou seja, independentemente do sistema operacional, do fabricante e do modelo do aparelho este deveria funcionar do mesmo jeito. Assim a Diebold Procomp decidiu oferecer suporte a J/XFS para seus dispositivos.
 
Basicamente, o objetivo do projeto no qual eu estou participando é desenvolver as camadas necessárias para a implementação do J/XFS (mais especificamente dos Device Services) para os periféricos da Diebold Procomp. Em particular trabalhei com a impressora para terminal de caixa e o leitor de cartões e smart card para caixas eletrônicos.
 
 
 
Figura 1 - Um modelo de ATM fabricado pela Diebold Procomp
 
 
 
Figura 2 - O Leitor de Cartões Magnéticos e
Smart Card, periférico com o qual trabalho atualmente
 
 
 
 
 
 
 
 
 
 
 
    
 
 
 
 
Figura 3 - A Impressora de Terminal de caixa,
periférico com o qual trabalhei nos meses de
junho e julho desse ano
 
bullet

O Ambiente de Trabalho e a Metodologia de Desenvolvimento

A equipe do meu projeto é composta por cerca de 15 pessoas. No início do projeto foram definidas detalhadamente pelo Project Manager as atividades que deveriam ser realizadas, quanto tempo cada atividade deveria levar e quem deveria executá-la.
 
Assim sendo, foi designado um dispositivo para cada empregado, para o qual todo o ciclo de desenvolvimento deveria ser realizado, sendo ele:
 
1. Desenvolvimento da camada Java Native Interface (JNI), pois as funções de baixo nível providas pelo departamento que desenvolve o hardware (engenharia) só podem ser acessadas pela linguagem C.
2. Elaboração do "Software Requirements Document" (SDD).
3. Implementação em Java do Device Service baseado no que foi definido na SDD.
4. Elaboração do "Verification Test Plan" (VTP)
5. Elaboração do "Unit Test Description" (UTD)
6. Implementação do "Unit Test"
7. Criação do manual de referência para programadores
8. Elaboração do manual para o usuário
 
A equipe possui um líder experiente que é responsável por certificar-se de que o time está seguindo o cronograma, tirar dúvidas, etc. Quando uma atividade inesperada surge, o líder do projeto designa um membro da equipe para executá-la. Além disso, o ambiente de trabalho oferecido pela empresa incentiva e facilita a comunicação entre os desenvolvedores, fazendo com que a curva de aprendizado de cada um seja reduzida e portanto otimizando o tempo de desenvolvimento.

Topo

bullet

Cronograma e Acompanhamento de Tarefas

O acompanhamento do projeto é feito em uma reunião semanal, na qual todos os membros da equipe se reúnem com o líder do projeto e o chefe do departamento.
 
Na reunião são verificadas quais as atividades que já foram concluídas, quais estão em andamento e se as mesmas estão de acordo com o cronograma pré-estabelecido. Além disso, verifica-se também os problemas que cada desenvolvedor possa ter, como, por exemplo, se existe alguma dificuldade específica ou se alguém necessita de algum hardware especial, etc.
 
Se existe alguém que não está conseguindo acompanhar o cronograma, alguma atitude é tomada para auxiliar essa pessoa. Em casos especiais, algumas tarefas são re-designadas para outros membros do grupo que estão adiantados no cronograma.
 
Até o presente momento, participei de dois ciclos de desenvolvimento de Device Services, um para a impressora de terminal de caixa e o outro para o leitor de cartões magnéticos e smart card para caixas eletrônicos.
 
O meu primeiro ciclo de desenvolvimento não foi fechado (foi interrompido durante a elaboração do Verification Test Plan) devido a uma mudança de foco estratégica da empresa. Dessa maneira a parte de automação de terminal de caixa foi deixada em um segundo plano e a parte de automação para caixas eletrônicos ganhou prioridade. Assim sendo, desde o 29/07/2004 estou trabalhando com o leitor de cartões e o ciclo de desenvolvimento desse periférico deve ser fechado em 14/12/2004.
 
Apesar dessa mudança de foco, até agora nos dois ciclos de desenvolvimento no qual eu participei, a estimativa inicial foi sempre respeitada a risca, resultando em um desenvolvimento dentro do prazo e do orçamento estabelecidos inicialmente.

Topo

bullet

Treinamento

Assim que iniciei o estágio, tive cerca de um mês dedicado exclusivamente para treinamento, integração com a equipe e aprendizado sobre a cultura da empresa. Durante essa fase as atividades mais importantes relacionadas a informática que executei foram:

- Estudar o J/XFS a fundo:
 
No início do estágio, li toda a documentação do J/XFS, para poder me familiarizar com o seu conceito, sua arquitetura e seu uso.
 
- Aprender como fazer a comunicação entre códigos escritos em C e em Java (JNI):
 
Aprendi como "linkar" códigos em Java e em C, pois o uso desse conceito seria posteriormente utilizado para poder fazer com que o Device Service escrito em Java pudesse se comunicar com o periférico, cuja API é acessível somente em C.
 
- Familiarizar-me com o uso dos periféricos da Diebold Procomp:
 
Nessa fase me foram fornecidos os periféricos "Leitor de Código de Barras" (LCB) e o "Leitor de cartões magnéticos e smart card do tipo DIP". Tendo-os em mãos, aprendi como utilizá-los, escrevendo programas simples em C que interagiam com os dispositivos.
 
- Familiarizar-me com os padrões de codificação da empresa:
 
Foram-me mostrados arquivos fonte de programas escritos anteriormente, para que eu pudesse aprender como é o estilo de programação que a empresa usa, como por exemplo, convenções sobre nomes de variáveis, formato dos comentários, etc.

Topo

bullet

Ferramentas Utilizadas

Em cada fase do projeto, diferentes ferramentas foram utilizadas. A empresa usa como padrão o sistema operacional Windows XP e para testes no ambiente Linux é utilizada a distribuição RedHat 9.0. Para toda a codificação em Java utilizamos o ambiente de desenvolvimento Eclipse e para o desenvolvimento do JNI utilizamos o Microsoft Visual Studio. Para a elaboração de documentos foram utilizados os aplicativos do pacote Microsoft Office.
 
Para a parte mais importante, o desenvolvimento de Device Service (DS), foram utilizadas duas ferramentas fundamentais. Uma delas foi o kernel do J/XFS, também conhecido como Financial Device Interface (FDI). Nos projetos em que participei a versão usada foi a 2.1. Além disso, também utilizamos um pacote de auxílio a criação de Device Services desenvolvido pela filial espanhola da Diebold conhecido como DSDK, que, uma vez que se aprende como usá-lo, de fato facilita muito o desenvolvimento dos DS. Para testes durante o desenvolvimento, foi utilizada uma ferramenta desenvolvida pela mesma filial que criou o DSDK, chamada "Diebold DS Tester".
 

Topo

bullet

Técnicas Utilizadas

Algumas técnicas utilizadas pela empresa durante o processo de desenvolvimento de software me chamaram a atenção.
 
Uma delas foi que uma vez que cada desenvolvedor finaliza um documento ou uma fase de codificação, o material criado é enviado para todos os outros membros da equipe, para que seja revisado. Achei esse procedimento muito interessante, pois em geral o desenvolvedor já está familiarizado demais com o que ele criou, ficando  no que chamamos de "viciado no código" (ou no documento). Dessa maneira alguns erros simples podem passar desapercebidos por ele, mas serão pegos na fase de revisão e não chegarão ao produto final.
 
Uma outra coisa que me agradou foi o uso de uma ferramenta onde todos podiam reportar bugs conhecidos, seja de programas feitos no projeto, ou até mesmo do arcabouço utilizado para o desenvolvimento. Assim, uma vez que alguém se depara com um bug, todos os outros membros da equipe instantaneamente sabem que ele existe, economizando assim tempo para todos.
 
Além disso, a empresa também incentiva que seus funcionários dêem sugestões sobre tópicos dos mais diversos, desde colocar um grampeador ao lado da impressora até sugerir um novo método para o desenvolvimento de software. Isso é muito importante, pois uma constante melhoria nas mais diversas áreas é feita, auxiliando no desenvolvimento de software de qualidade e no bem-estar dos funcionários.
 
Uma técnica que me pareceu interessante e que eu sugeri como melhoria, mas que até o momento não foi implementada, seria um aplicativo na intranet da empresa onde todos os funcionários pudessem registrar suas competências nas mais variadas áreas, para que quando surja alguma atividade que necessite de conhecimento específico, a empresa saiba quem procurar para executá-la e além disso, quando algum funcionário tem alguma dúvida com relação a um tópico específico ele saberá a quem recorrer.

Topo

bullet

Minha Parte no Projeto

Como já foi mencionado anteriormente, nesse projeto fui alocado para o desenvolvimento dos Device Services para os periféricos "Leitor de cartões magnéticos e Smart Card" e "Impressora de Terminal de Caixa". Nessa seção, darei detalhes técnicos sobre o que já foi realizado nesse desenvolvimento e o resultado que obtive em cada passo. Posteriormente descreverei os testes.
 
DIP: Leitor de cartões magnéticos e Smart Card
IMP: Impressora de Terminal de Caixa
 
Atividade Descrição Tempo Resultado Obtido
JNI para a  IMP Fazer uma "ponte" entre o código em C que interage  com o dispositivo físico e as classes escritas em Java para a impressora 2 semanas 1300 linhas de código em C, 1000 linhas de código em Java
JNI para o DIP Fazer uma "ponte" entre o código em C que interage  com o dispositivo físico e as classes escritas em Java para o leitor de cartões 2 semanas 2400 linhas de código em C, 1300 linhas de código em Java
SDD para a IMP Desenvolver a SDD (Software Requirements Document) para a IMP. Esse documento define detalhadamente como o Device Service deve se comportar 4 semanas Documento com cerca de 45 páginas
SDD para o DIP Desenvolver a SDD (Software Requirements Document) para o DIP. Esse documento define detalhadamente como o Device Service deve se comportar 3 semanas Documento com cerca de 55 páginas
Device Service para a IMP Criação da camada do Device Service (DS) para a IMP 2 semanas 1900 linhas de código em Java 
Device Service para o DIP Criação da camada do Device Service (DS) para o DIP 3 semanas 3000 linhas de código em Java
VTP para o DIP Desenvolvimento do Verification Test Plan (VTP) para o DIP, que descreve em alto nível as funcionalidades do periférico que serão testadas e define as classes de teste para o JUnit 1 semana Documento com cerca de 20 páginas
UTD para o DIP Desenvolvimento do UTD (Unit Test Description) para o DIP, que descreve detalhadamente quais os testes que serão realizados e como eles serão feitos (questões de implementação, ações que serão necessárias por parte da pessoa que irá testar, etc) 5 semanas Documento com cerca de 150 páginas
Totais - 23 semanas 7200 linhas de código em Java, 3700 linhas de código em C e 270 páginas de documentação
 

Testes

Para cada fase de codificação do projeto, existem 3 níveis de testes. O primeiro nível é feito pelo programador a medida que o código vai sendo escrito, para testar se essa ou aquela parte está funcionando como planejado e etc. O segundo nível é a revisão de código, que não é exatamente um teste, mas que é igualmente útil para a detecção de erros. Basicamente, assim que uma fase do projeto é terminada, o material produzido é enviado para todos os outros membros da equipe (inclusive os documentos) para que uma revisão seja feita. A terceira parte é a execução automatizada daquilo que foi implementado em JUnit baseado no que foi escrito no VTP e na UTD.

Topo

Home | O Projeto | J/XFS | A Empresa | Bibliografia | O Curso do BCC | BCC x Estágio | Desafios | Considerações

Este site foi atualizado em 01/12/04