O documento descreve um sistema para gerar indicadores de satisfação de clientes para montadoras de veículos. O sistema irá importar pesquisas de satisfação, gerar os indicadores, e disponibilizar relatórios. As tecnologias escolhidas foram Java, EJB, JPA, JSF e JBoss para aproveitar as vantagens da plataforma Java e padrões JEE.
2. QUEM SOMOS
Saulo Arruda (http://sauloarruda.eti.br)
Quase especialista em MPS pela UFLA
Gerente de Produção da Agence
Coordenador do JUG-MS
Instrutor do SENAC-MS
Desenvolvedor há 10 anos
3. QUEM SOMOS
Jefferson Moreira (http://jeffmor.com)
Quase especialista em Engenharia de Software pela
UNIDERP/Anhanguera
Desenvolvedor da Agence
Coordenador do JUG-MS
Instrutor do SENAC-MS
Desenvolvedor há 6 anos
4. POR ONDE COMEÇAR?
Qual problema será resolvido?
Quais são as restrições?
Como vamos resolver o problema?
6. O PROBLEMA
Cliente: Consultoria de Marketing
Projeto: Programa de Melhoria do Índice de
Satisfação do Cliente (ISC) para Montadoras de
Veículos
Envolvidos: Consultoria, Montadora, Clientes da
Montadora, Agence, Instituto de Pesquisa
Escopo: Desenvolvimento do Sistema para
processamento dos indicadores e exibição dos
relatórios.
7. AS RESTRIÇÕES
O sistema deve atender clientes de várias áreas, não
somente montadoras;
Hoje, existem 2 soluções implementadas que
possuem as seguintes limitações:
Problemas de performance e confiabilidade;
Flexibilidade para atender mudanças solicitadas
pelo cliente;
8. O PROCESSO
Etapas do Programa de Melhoria do Índice de
Satisfação do Cliente (ISC):
Realização de Pesquisa com os Clientes
Processamento e Geração dos Indicadores
Disponibilização dos Relatórios
Esse processo é realizado semanalmente;
Periodicamente, a consultoria compila um relatório
analítico apresentando recomendações para melhoria
do ISC
10. O SISTEMA
O Sistema a ser desenvolvido abrange apenas a
geração de indicadores e apresentação dos
relatórios;
As pesquisas serão realizadas pelo Instituto de
Pesquisa, que enviará semanalmente uma planilha
eletrônica (.xls) com os resultados;
O relatório analítico será elaborado pela consultoria
usando ferramentas de terceiros;
11. VISÃO GERAL DA
ARQUITETURA
Linguagem de Programação: Java 5
Banco de Dados: PostgreSQL 8+
Frameworks e componentes:
Objetos de Negócio: EJB 3.0
Persistência: JPA 1.1
Web: JSF 1.2 + Facelets + RichFaces
Servidor de Aplicação: JBoss 5
12. MOTIVOS DAS
DECISÕES
Por que Java?
Spring, JBoss Seam ou EJB 3?
Struts, Spring MVC ou JSF?
JBoss, Glassfish ou Websphere?
13. POR QUE JAVA?
Open Source
“Independente” de plataforma
“Excelente” API
Ecossistema amplo de Frameworks
Sistemas distribuídos “sem complicação”
E acima de tudo por conta da Plataforma Java
16. SPRING, JBOSS SEAM
OU EJB 3?
Spring
IoC, DI, Transaction API, vários frameworks
integrados, excelente API para Web e Desktop.
JBoss SEAM
DI, Bijeção, Novos Escopos e apenas para web.
EJB3 (nossa escolha)
Spring+, container de EJB, especificação JEE,
sistema distribuídos.
17. STRUTS, SPRING MVC
OU JSF?
Struts
Validadores, Anotações e Legado.
Spring MVC
Simples, Direto e Binding.
JSF (nossa escolha)
Especificação, Validadores, Conversores,
Componentes, Templates, Facelets, JSF 2.0 saindo.
18. JBOSS, GLASSFISH OU
WEBSPHERE?
GlassFish
Implementação de referência JEE, integrado com NetBeans e
dizem ser o mais rápido.
Websphere
Pago, fácil configuração e a maioria das empresas tentando
migrar para a versão 6.x
JBoss (nossa escolha)
Suporte SOA, Leve, Robusto, JMX, Equipe com Know How,
extensivo suporte AOP, representatividade no Brasil.
19. JAVA PERSISTENCE API
Substitui os Entity Beans
EJB/JPA QL
Provedores (Hibernate, Oracle Toplink, Apache JPA)
Extensões específicas de provedores (Cache,
estatísticas, JMX, Criteria)
Lazy Loading usando EJB.
Falta Criteria API (previsto para JPA 2.0)
20. POSTGRESQL
Open Source
Performance satisfatória
Ambiente Linux ou BSD (preferencialmente)
Dificuldade em Tuning (otimização)
Escalabilidade prejudicada em servidores
compartilhados
Dificuldade na Manutenção (VACUUM, ANALYZE)
21. CASOS DE USO
Importar Pesquisas
Gerar Indicadores
Conferir Indicadores
Publicar Indicadores
Manter Questionários
Consultar Acompanhamento Mensal
Consultar Dashboard
22. IMPORTAR PESQUISAS
Escopo: Sistema ISC - Processamento
Nível: Objetivo do Usuário
Ator Primário: Consultor
Pré-condições: Usuário autenticado
Garantias de Sucesso: Pesquisas importadas com
sucesso
Garantias Mínimas: Lista de erros da importação
23. IMPORTAR PESQUISAS
Cenário de Sucesso Principal:
1. O consultor seleciona a empresa, o questionário e a
planilha com as pesquisas (arquivo xls)
2. O sistema processa a planilha e importa as
pesquisas
3. O consultor confere o resultado da importação
24. IMPORTAR PESQUISAS
Extensões:
2a. O arquivo não pôde ser lido:
1. O sistema apresenta descrição do erro
2. O consultor corrige e repete o passo 1 ou
finaliza o caso de uso
2-3a. Algumas linhas do arquivo estão inválidas:
1. O continua e apresenta os erros no final
2. O consultor corrige e repete o passo 1 ou
finaliza o caso de uso
25. IMPORTAR PESQUISAS
Requisitos Especiais:
RF01. Ao importar a pesquisa é necessário
identificar a empresa para a qual foi feita;
RF02. Ao importar a pesquisa é necessário
identificar o responsável pelo atendimento;
RP01. A importação de 1.000 pesquisas não pode
demorar mais que 2 minutos;
Frequência de ocorrência: Semanalmente
33. PROBLEMAS DA
IMPLEMENTAÇÃO
Performance: O tempo de importacão de 1 pesquisa
(60 questões) é de 0,5 s. Para 1.000 pesquisas
precisamos de mais de 8 min. Os maiores
questionários tem 200 questões.
Funcionalidade: A API POI consegue ler um
arquivo de até 5 Mb (OutOfMemoryError). Um
arquivo de 1.000 pesquisas com 200 chega a 8 Mb.
34. TESTES UNITÁRIOS
Classe base (AbstractModelTestCase)
Fixtures para dados de testes usando arquivos de
Bean do Spring
Injeção de objetos usados no teste
Criação do banco de dados
Controle transacional
Simulação dos objetos do container
35. TESTES DE
INTEGRAÇÃO
Testes usando objetos remotos do container EJB
Integração de todas as funcionalidades, usando
arquivos reais enviados pelo cliente
Uso de profiler para mensurar performance
Assertions baseado em planilhas enviadas pelo cliente
36. TESTES FUNCIONAIS
Plano de testes em planilha excel
Realização dos testes no final de cada iteração
Criação de evidências de testes
Execução de testes de regressão
Automatização de testes funcionais?
Selenium/Webdriver (quem sabe no futuro)
37. TESTE DE CARGA
Teste de carga das telas de relatório
Uso de JMeter para implementação e execução
Execução remota de testes para simulação de vários
usuários (Ex.: 3 máquinas com 500 usuários cada)
Profiler para mensurar uso de processador e memória
Teste em ambiente de pré-produção com a
configuração do servidor de produção e simulação
real do número de usuários
38. OTIMIZAÇÕES
Refactoring de métodos críticos
Otimização/refactoring de consultas SQL
Otimização de índices no banco de dados
Implementação de Cache (ehcache)
Tuning do Servidor de Banco de Dados
Tuning de Servidor de Aplicação
Tuning de configurações do Sistema Operacional
45. CONCLUSÃO
Lições aprendidas
Processo de desenvolvimento:
Focado na Arquitetura;
Dirigido por Casos de Uso;
Iterativo e Incremental;
Testes antes da implantação (integração, funcional
e carga/stress)