|
|
O Projeto

INTRODUÇÃO |
CRONOGRAMA |
TREINAMENTO |
MINHA
PARTE NO PROJETO FERRAMENTAS
|
TÉCNICAS |
AMBIENTE DE TRABALHO E METODOLOGIA

 |
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
 |
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
| |
 |
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
|
 |
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
|
 |
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 |
 |
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 |
 |
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
|