Apresentação dos conceitos web 2.0 e ria, aplicados ao desenvolvimento de um protótipo de sistema para suporte a clientes

ESCOLA SUPERIOR DE CRICIÚMA – ESUCRI

CURSO DE SISTEMAS DE INFORMAÇÃO

CÁSSIO GHISLANDI CÚNICOMATEUS MONTEDO ALBÔNICO

RICARDO DE SOUZA POSSAMAI DELLA

APRESENTAÇÃO DOS CONCEITOS WEB 2.0 E RIA, APLICADOS

AO DESENVOLVIMENTO DE UM PROTÓTIPO DE SISTEMA PARA

SUPORTE A CLIENTES

Criciúma (SC), novembro/2009





SUPORTE A CLIENTES

Trabalho de Conclusão de Curso apresentado como requisito parcial para a obtenção do título de Bacharel em Sistemas de Informação da Escola Superior de Criciúma, ESUCRI.

Orientadora: Profª. Muriel de Fátima Bernhardt Rocha

Criciúma (SC), novembro/2009





SUPORTE A CLIENTES

Trabalho de Conclusão de Curso aprovado pela Banca Examinadora para obtenção do título de Bacharel em Sistemas de Informação da Escola Superior de Criciúma, ESUCRI.

Criciúma, 18 de novembro de 2009.

BANCA EXAMINADORA:

_____________________________________

Profª. Muriel de Fátima Bernhardt Rocha. MSc – Orientadora

______________________________________

Profª. Andréia Ana Bernardini. MSc

______________________________________

Profª. Marta Adriana da Silva Cristiano. MSc

AGRADECIMENTOS

Primeiramente gostaríamos de agradecer a Deus por nos ter dado a

oportunidade de estarmos aqui e permitir que possamos finalizar mais uma etapa de

nossas vidas.

Agradecemos também à nossa orientadora Muriel, por ter nos dado o auxílio

necessário ao desenvolvimento deste trabalho, sendo muito mais do que uma

simples orientadora, uma grande amiga que iremos considerar para o resto de

nossas vidas.

À nossa coordenadora Andréia, que presenciou todo o nosso crescimento

nestes quatro anos, nos apoiando desde o início e sempre estando à disposição

para quaisquer assuntos.

A todos os professores, por compartilhar uma parte do grande conhecimento

que detêm, por solucionar nossas dúvidas e por se transformarem em grandes

amigos. Agradecemos especialmente aos professores que compõem nossa banca

avaliadora, por ter aceitado o desafio de avaliar nosso trabalho.

À ESUCRI, por nos fornecer toda a estrutura necessária para que o ensino

nos fosse fornecido da melhor forma possível.

Aos nossos colegas de turma, por nossas amizades e momentos

inesquecíveis que passamos.

Agradecemos também ao Fernando dos Santos Garcia, por nos auxiliar no

desenvolvimento do protótipo, com toda sua experiência no desenvolvimento de

sistemas.

CÁSSIO GHISLANDI CÚNICO, MATEUS MONTEDO ALBÔNICO E


Agradeço a meus pais, Herval e Edilene, por todo o apoio e atenção

prestados para minha saúde, formação e educação, e por terem me moldado para

ser a pessoa que sou hoje.

À minha noiva, Juliana, por estar sempre do meu lado, me apoiando e me

dando forças para superar todos os desafios que a vida nos oferece.

Aos meus amigos Mateus e Ricardo, por serem verdadeiros amigos,

principalmente nas horas que mais precisei deles, e por termos formado, com

certeza, uma ótima equipe.

Aos demais amigos e colegas de trabalho, pelos conselhos e apoio

prestados.

CÁSSIO GHISLANDI CÚNICO

......Agradeço aos meus pais, Antônio e Vera, por tudo que fizeram na minha

vida, pois sem eles não estaria aqui vencendo mais essa etapa.

A minha namorada, Mirian, por estar do meu lado em todos os momentos,

sendo bons ou ruins, me apoiando e me dando carinho, ainda pela sua paciência

comigo, principalmente no último semestre.

Ao meu padrinho Oscar, por sempre me dar conselhos, me ajudando muito

nas muitas decisões que tive de tomar, sendo um segundo pai pra mim.

Agradeço também ao meu Avô Edson e minha madrinha Dolores que já não

estão mais entre nós, mais me apoiaram muito para chegar até aqui, e sei que

estariam orgulhosos por me ver superando mais esse desafio em minha vida.

Aos meus grandes amigos Cássio e Ricardo, pois sem eles essa etapa seria

mais difícil, a confiança que os dois depositaram em mim, a grande equipe que

formamos nesses quatro anos de curso, e com certeza serão meus amigos para o

resto de minha vida.

MATEUS MONTEDO ALBÔNICO

Agradeço a meus pais, Donato Possamai Della e Marisa de Souza Possamai

Della por toda dedicação, carinho e confiança em mim depositada.

Agradeço também ao Rogério e Rita, meus padrinhos, que me apoiaram em

muitos momentos.

Agradeço ao Cássio e Mateus, meus colegas de desenvolvimento, que ao

longo deste trabalho se transformaram em verdadeiros amigos e juntos

conseguimos vencer esse desafio.


SUMÁRIO

LISTA DE ILUSTRAÇÕES...........................................................................................7

LISTA DE QUADROS..................................................................................................9

ABREVIATURAS.......................................................................................................10

RESUMO...................................................................................................................12

1 INTRODUÇÃO..................................................................................................13

1.1 MOTIVAÇÃO..........................................................................................13

1.2 OBJETIVOS............................................................................................14

1.2.1 OBJETIVO GERAL.....................................................................14

1.2.2 OBJETIVOS ESPECÍFICOS......................................................14

1.3 ORGANIZAÇÃO.....................................................................................14

2 ATENDIMENTO AO CLIENTE..........................................................................16

2.1 FORMAS DE ATENDIMENTO AO CLIENTE.........................................17

2.1.1 HELP DESK................................................................................18

2.1.2 FAQ – QUESTÕES FREQUENTEMENTE PERGUNTADAS.....21

2.1.3 SUPORTE ON-LINE...................................................................23

3 TECNOLOGIAS APLICADAS NO ATENDIMENTO A CLIENTES....................26

3.1 WEB 2.0..................................................................................................27

3.1.1 REFERENCIAL HISTÓRICO......................................................27

3.1.2 DEFINIÇÃO E CARACTERÍSTICAS..........................................28

3.1.3 EVOLUÇÃO................................................................................31

3.2 RIA - RICH INTERNET APPLICATION..................................................33

4 TECNOLOGIAS RELACIONADAS...................................................................38

4.1 LINGUAGENS DE PROGRAMAÇÃO.....................................................38

4.1.1 JAVA...........................................................................................39

4.1.2 XML............................................................................................40

4.1.3 MXML.........................................................................................41

4.1.4 ACTION SCRIPT 3.0..................................................................42

4.2 FERRAMENTAS.....................................................................................45

4.2.1 ECLIPSE GANYMEDE...............................................................46

4.2.2 FLEX...........................................................................................47

4.2.3 ADOBE FLEX BUILDER 3.0.......................................................52

4.2.4 BLAZEDS...................................................................................53

4.3 BANCO DE DADOS...............................................................................54

4.3.1 MYSQL.......................................................................................55

5 PROTÓTIPO DE UMA SOLUÇÃO DE SUPORTE ON-LINE BASEADA EM

WEB 2.0 E RIA..........................................................................................................57

5.1 ESTUDO PRELIMINAR..........................................................................57

5.2 ANÁLISE DE REQUISITOS....................................................................61

5.2.1 LEVANTAMENTO DE REQUISITOS.........................................61

5.2.2 ORGANIZAÇÃO DOS REQUISITOS.........................................63

5.3 DESIGN DA SOLUÇÃO..........................................................................68

5.3.1 MODELO CONCEITUAL............................................................68

5.3.2 PROJETO DE BANCO DE DADOS...........................................70

5.4 APRESENTAÇÃO DO PROTÓTIPO......................................................72

5.4.1 TIPO DE USUÁRIO: MASTER...................................................88

5.4.2 TIPO DE USUÁRIO: ADMINISTRADOR CLIENTE....................88

5.4.3 TIPO DE USUÁRIO: FUNCIONÁRIO.........................................92

5.4.4 TIPO DE USUÁRIO: USUÁRIO..................................................93

6 CONSIDERAÇÕES FINAIS..............................................................................96

6.1 CONCLUSÕES.......................................................................................96

6.2 RECOMENDAÇÕES PARA TRABALHOS FUTUROS...........................97

REFERÊNCIAS.........................................................................................................98

LISTA DE ILUSTRAÇÕES

Ilustração 1: Processo de Solicitação de Serviço......................................................19

Ilustração 2: Mapa da Web 2.0..................................................................................29

Ilustração 3: Distribuição do processamento entre servidor e cliente na RIA............34

Ilustração 4: Modelo de interação da RIA..................................................................35

Ilustração 5: Exemplo de código em MXML..............................................................42

Ilustração 6: Exemplo de código em ActionScript 3.0................................................44

Ilustração 7: Comunicação aplicação/servidor via HTTP/XML..................................50

Ilustração 8: Desempenho do protocolo AMF (cinco mil linhas de código)...............51

Ilustração 9: Redução de camadas de abstração do AMF........................................53

Ilustração 10: Diagrama de Componentes................................................................61

Ilustração 11: Diagrama de Casos de Uso................................................................66

Ilustração 12: Diagrama de Classes..........................................................................69

Ilustração 13: Modelo ER...........................................................................................71

Ilustração 14: Login do Sistema.................................................................................72

Ilustração 15: Tela principal.......................................................................................73

Ilustração 16: Cadastro da Empresa Prestadora.......................................................74

Ilustração 17: Cadastro de Cidades...........................................................................75

Ilustração 18: Cadastro de Setores...........................................................................76

Ilustração 19: Cadastro de Sistemas.........................................................................77

Ilustração 20: Cadastro de Clientes...........................................................................78

Ilustração 21: Consulta de Cidades...........................................................................79

Ilustração 22: Cadastro de Usuários..........................................................................80

Ilustração 23: Consulta de Clientes...........................................................................81

Ilustração 24: Consulta de Setores............................................................................82

Ilustração 25: Cadastro de Solicitações.....................................................................83

Ilustração 26: Consulta de Solicitações.....................................................................84

Ilustração 27: Respostas da Solicitação....................................................................85

Ilustração 28: Trâmites..............................................................................................86

Ilustração 29: Trâmites..............................................................................................87

Ilustração 30: Detalhes do Trâmite............................................................................87

Ilustração 31: Contato................................................................................................88

Ilustração 32: Tela Principal (Administrador Cliente).................................................89

Ilustração 33: Cadastro de Usuários (Administrador Cliente)....................................90

Ilustração 34: Consulta de Solicitações (Administrador Cliente)...............................91

Ilustração 35: Respostas da Solicitação (Administrador Cliente)..............................92

Ilustração 36: Tela Principal (Funcionário)................................................................93

Ilustração 37: Tela Principal (Usuário).......................................................................94

Ilustração 38: Consulta de Solicitações (Usuário).....................................................95

LISTA DE QUADROS

Quadro 1: Prioridade dos Chamados........................................................................20

Quadro 2: Comparativo inicial entre Web 1.0 e Web 2.0...........................................31

Quadro 3: Aspectos da web tradicional resolvidos pela RIA.....................................36

Quadro 4: Comparativo entre as sintaxes Java 5 e Action Script 3.0........................43

Quadro 5: Requisitos funcionais do protótipo............................................................62

Quadro 6: Requisitos não-funcionais do protótipo.....................................................63

Quadro 7: Caso de uso RF6......................................................................................64



Quadro 10: Regra de Negócio RN7.1........................................................................67




ABREVIATURAS

AIR - Adobe Integrated Runtime

AIX - Advanced IBM UNIX

AMF - Action Message Format

API – Application Program Interface

CEP - Código de Endereçamento Postal

CNPJ – Cadastro Nacional de Pessoas Físicas

DOM - Document Object Model

ER - Entidade Relacionamento

FAQ – Frequently Asked Questions

GML - Generalized Markup Language

GNU - GNU is Not Unix

GPL - General Public License

IBM - International Business Machines

IDE - Integrated Development Environment

IE - Internet Explorer

ISAM - Indexed Sequential Access Method

ISO - International Standards Organization

HTML - HyperText Markup Language

HTTP - HyperText Transfer Protocol

JDK - Java Development Kit

JMS - Java Message Service

JSON - JavaScript Object Notation

LGPL - Lesser General Public License

MXML - Macromedia Flex Markup Language

PHP - Hipertext Pré-Processo

RF – Requisito Funcional

RIA – Rich Internet Application

RNF – Requisito Não Funcional

RPC - Remote Procedure Call

RSS - Really Simple Syndication

SDK - Software Development Kit

SGBD - Sistema de Gerenciamento de Banco de Dados

SGML - Standard Generalized Markup Language

SO – Sistemas Operacionais

SOAP - Simple Object Accesss Protocol

SQL - Structured Query Language

TP - Transaction Processing

UF - Unidade Federativa

UML - Unified Modeling Language

XML - eXtensible Markup Language

RESUMO

A qualidade no atendimento a clientes vem sendo a cada dia mais exigida, independentemente do porte da empresa que presta este serviço. As empresas precisam se adequar aos novos padrões exigidos para o atendimento, buscando novas tecnologias para realizá-lo. Nos últimos tempos surgiram os conceitos de Web 2.0 e RIA, os quais se apresentaram como novas alternativas para as mais diversas soluções para as empresas, inclusive a interação com o cliente, apresentando uma interface amigável e facilitando a prestação de serviços pela web. Este trabalho apresenta o estudo destas tecnologias e seu emprego no desenvolvimento de um protótipo para o atendimento a clientes.

Palavras-chave: Atendimento a clientes, Web 2.0, RIA.

13

1 INTRODUÇÃO

O perfil dos clientes está em constante mudança, exigindo cada dia mais que

sejam disponibilizados melhores produtos e prestação de serviços de forma rápida e

melhor qualificada. Com isto, existe uma revolução constante nas formas como as

empresas tratam seus clientes, desde propagandas até o atendimento pós-venda,

onde dúvidas e solicitações dos clientes necessitam ser esclarecidas de forma

rápida e prática.

Um dos métodos mais utilizados recentemente pelas empresas para

conquistar e manter a fidelidade de seus clientes é o bom atendimento de suporte

aos produtos. Com isto, surgiram diversas formas de atendimento, destacando-se o

Help Desk, o FAQ (Frequently Asked Questions) e Suporte On-line. Neste âmbito, os

sistemas para prestação de suporte on-line são os que mais se destacaram, pois

oferecem vantagens e facilidades para as empresas prestadoras de serviços, quanto

ao gerenciamento das solicitações, e para os clientes, quanto a resoluções de

solicitações.

Com a evolução das tecnologias, surgiram alguns conceitos de grande

utilidade, como Web 2.0 e RIA (Rich Internet Application) e ferramentas com suporte

a estes, como o Adobe Flex, os quais permitem que sejam desenvolvidos sistemas

muito mais ricos em interface e funcionalidades para a internet, podendo ser

comparados com os sistemas desktop. Os sistemas desenvolvidos em Flex podem

ser mais rápidos e fáceis de manusear, oferecendo uma interface mais limpa e

design mais arrojado.

1.1 MOTIVAÇÃO

A área de desenvolvimento de software está em constante crescimento.

Porém, os investimentos tecnológicos para o planejamento e o desenvolvimento dos

produtos que são comercializados por estas empresas, normalmente são superiores

aos investimentos para o suporte destes produtos. Estas empresas estão focadas no

desenvolvimento de sistemas para atender especificamente as necessidades dos

clientes, podendo pecar nos sistemas que são utilizados para prestar suporte aos

mesmos.

Para que seja disponibilizado um atendimento apropriado aos clientes, que

atenda suas dúvidas ou solicitações de alteração, podem ser utilizados sistemas de

14

suporte on-line, que auxiliem a área de suporte da empresa desenvolvedora,

visando melhorar a comunicação entre ambas as partes, possibilitando uma

comunicação versátil, com maior custo-benefício.

A utilização do sistema de suporte on-line fornece maior agilidade no

atendimento, trazendo maior confiabilidade ao cliente. Da mesma forma, melhora o

gerenciamento de todo o atendimento, efetua o controle do fluxo de informações e

produz rapidez no retorno ao cliente, por parte da empresa, sendo estas as

vantagens as quais se pretende apresentar com este trabalho.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Este trabalho de conclusão de curso tem como objetivo geral apresentar os

conceitos de suporte on-line ao cliente, Web 2.0 e RIA, desenvolvendo um protótipo

de software que empregue estes conceitos, de maneira a facilitar o procedimento de

solicitações de suporte, por parte dos clientes, e o gerenciamento do fluxo destas,

por parte da empresa.

1.2.2 Objetivos Específicos

Os objetivos específicos são:

Identificar e apresentar conceitos e características que envolvem o atendimento

ao cliente;

Apresentar as características da Web 2.0 e RIA;

Apresentar um estudo sobre a tecnologia Flex (Action Script 3.0) e ferramentas

que auxiliam no desenvolvimento do software;

Realizar o levantamento e análise de requisitos pertinentes ao desenvolvimento

de um protótipo de sistema de informação baseado nos conceitos supracitados;

Desenvolver o protótipo tendo como cenário de aplicação uma empresa

desenvolvedora de software, utilizando as ferramentas apresentadas.

1.3 ORGANIZAÇÃO

O presente trabalho está organizado em seis capítulos.

O segundo capítulo faz a explanação do atendimento ao cliente, os

princípios de atendimento e as necessidades do mesmo. Este capítulo também

15

descreve as principais formas de atendimento ao cliente.

No terceiro capítulo são demonstrados os conceitos utilizados no protótipo,

sendo estes Web 2.0 e RIA, que fornecem uma visão atualizada no que se diz

respeito a desenvolvimento de sistemas on-line.

As tecnologias utilizadas para o desenvolvimento do protótipo são descritas

no quarto capítulo. São explanadas as linguagens de programação, as ferramentas

para desenvolvimento, o banco de dados e a ferramenta para a troca de

informações entre estas tecnologias, explicando o porquê de sua utilização.

O quinto capítulo apresenta o protótipo como uma solução ao atendimento a

clientes e o porquê da diferença deste em relação aos outros sistemas de

atendimento on-line. O capítulo contém também o levantamento e a análise dos

requisitos para o desenvolvimento do protótipo, juntamente com as informações

pertinentes ao seu desenvolvimento.

O sexto capítulo fornece as considerações finais do trabalho e

recomendações futuras para o seu aperfeiçoamento.

16

2 ATENDIMENTO AO CLIENTE

Neste capítulo será explicado o que é atendimento ao cliente, suas

necessidades. Conterá também as principais formas de atendimento ao cliente.

De acordo com Hargreaves, Zuanetti e Lee (2005), no passado os clientes

aceitavam quaisquer produtos de baixa qualidade ou atendimentos inadequados.

Porém, este paradigma mudou e o perfil dos clientes hoje é outro. Estes estão muito

mais exigentes, comparando preços, exigindo qualidade no atendimento e na

prestação de serviços, tendo maior consciência de seus direitos de consumidor.

Para Desatnick e Detzel (1995), as empresas se preocupam

demasiadamente em conquistar novos clientes e acabam esquecendo de manter

contato com os clientes que já estão fidelizados, considerando que, para conquistar

novos clientes, a empresa tem um custo cinco vezes maior em relação a manter os

clientes já fidelizados. Ocorre que muitas empresas falham neste ponto, tendo a

ideia de que, quanto maior sua gama de clientes conquistados, maior é sua

abrangência no mercado. Com o passar do tempo, em média um a cada quatro

clientes fica insatisfeito com a empresa. Com isto, esses clientes encontram em

outras empresas a oportunidade de negociar produtos ou serviços similares, de um

modo que lhes traga maior benefício em relação ao atendimento (PERFORMANCE

RESEARCH ASSOCIATES, 2008).

Hargreaves, Zuanetti e Lee (2005) confirmam que, quanto maior o

conhecimento que as empresas têm do desejo de seus clientes e o respeito por

seus direitos, mais aptas estarão para satisfazê-los.

Os mesmos autores ainda relatam que o conhecimento acerca dos desejos

dos clientes pode ser feito de duas maneiras: de forma geral ou individual. Na

primeira, são analisados padrões e motivações de consumo, podendo ser feitos por

pesquisas de mercado, questionários, caixas de sugestões e demais formas de

contato coletivas. Normalmente esta forma é utilizada por grandes empresas, por

possuírem maior clientela. Na segunda, é feito o atendimento individual pelos

profissionais que têm contato direto com o cliente, tendo uma melhor noção das

expectativas e necessidades dos mesmos. Geralmente é utilizada em médias ou

pequenas empresas, por possuírem uma clientela menor.

Assim sendo, o foco principal do atendimento ao cliente é a satisfação do

mesmo que, conforme Kotler (1998, p. 53), “é o sentimento de prazer ou de

17

desapontamento resultante da comparação do desempenho esperado pelo produto

(ou resultado) em relação às expectativas da pessoa”.

É importante ainda salientar que os clientes não diferenciam os funcionários

e a empresa na hora do atendimento. Os clientes não têm interesse em saber como

é o processo da empresa por trás do atendimento, necessitando somente do

resultado do atendimento, sendo que o restante é considerado como problema dos

funcionários e, consequentemente, da empresa (PERFORMANCE RESEARCH

ASSOCIATES, 2008).

Segundo Hargreaves, Zuanetti e Lee (2005), os laços entre as empresas e o

consumidor vêm estreitando-se no decorrer dos últimos anos, seja por meio de seu

serviço de atendimento, com reclamações e demandas, ou por meio de pesquisas

de opinião. Isto faz com que a empresa conheça as opiniões e desejos dos

consumidores, possibilitando assim que inovem seus produtos ou serviços e possam

planejar sua atuação no mercado. Estas opiniões, no entanto, não podem ser

superestimadas, pois o cliente não é capaz de prever suas próprias necessidades.

Ainda conforme Hargreaves, Zuanetti e Lee (2005), o cliente deve ser bem

tratado, para que o mesmo volte a buscar os serviços da empresa e que este se

torne um exemplar de satisfação, divulgando o produto e o atendimento fornecidos.

Fidelidade do cliente significa até que ponto um cliente continuará com uma empresa ou marca específica. Na verdade, conquistar um novo cliente custa à empresa de cinco a oito vezes mais que manter o cliente já existente. Além disso, a fidelidade do cliente fortalece a posição de mercado da empresa – afinal, consumidores fiéis ficam longe da concorrência. (TURBAN; KING, 2004, p. 121).

O tamanho da empresa e seu ramo de produção não são mais importantes

que a atenção e os serviços prestados ao cliente. “Hoje os serviços constituem o

padrão pelo qual os clientes medem o desempenho de uma organização”

(DESATNICK; DETZEL, 1995, p. 4).

Esta afirmação destaca um dos objetivos deste trabalho, o qual busca

implementar padrões de atendimento ao cliente em um sistema de suporte on-line,

para construir a fidelidade e a satisfação do cliente.

2.1 FORMAS DE ATENDIMENTO AO CLIENTE

De acordo com Performance Research Associates (2008), os pesquisadores

perceberam que um bom atendimento ao cliente reduz consideravelmente os gastos

com marketing, pois os clientes “escolhiam com o coração” quando eram bem

18

tratados e tinham seus problemas resolvidos.

Um atendimento bem sucedido está relacionado, entre outros fatores, à

confiança e responsabilidade de cumprir um serviço prometido, à empatia e

dedicação para entender como cada cliente gostaria de ser tratado e à segurança

em passar as informações necessárias e corretas com profissionalismo. Também é

interessante tornar o serviço tangível, para que o cliente possa julgá-lo e superar as

expectativas com a pró atividade de quem está lhe auxiliando, estabelecer e cumprir

prazos com rapidez na resposta e saber identificar os clientes internos e externos da

organização, personalizando o atendimento de acordo com cada caso.

(PERFORMANCE RESEARCH ASSOCIATES, 2008).

Gestão, pelo conceito semântico do dicionário, significa “Ato de gerir, direção, administração”. É importante administrar o processo de atendimento, gerenciando-o pró ativamente; isso significa na forma mais elementar de raciocínio que é necessário fazer algo sobre os registros dos contatos dos clientes. A questão primordial é: fazer o quê e como (STATDLOBER, 2006, p. 5).

Nesta seção serão apresentadas as formas de atendimento ao cliente mais

citadas nas referências pesquisadas, sendo estas, Help Desk, FAQ e Suporte On-

line, detalhando suas características, o modo como são efetuadas e quais questões

podem ser melhoradas.

2.1.1 Help Desk

A expressão Help Desk é antiga. Desde os tempos dos mainframes, passando pela difusão da micro-informática e o consequente alastramento de recursos computacionais por todas as áreas da empresa, sempre existiu o conceito de Help Desk ou, ao menos, centro de suporte técnico. Para lá as pessoas ligavam com dúvidas de uso (COHEN, 2008, p. 19).

Quando se fala em esclarecimento de dúvidas por telefone, é comum haver

confusão entre os termos Help Desk e Call Center, sendo que este último

compreende um conjunto de agentes (também chamados de operadores) que

interagem com os clientes somente para o fornecimento de serviços via telefone

(RIJO, 2006).

Segundo Cohen (2008), existem várias diferenças entre o Call Center e o

Help Desk. Uma delas é que, no Call Center, a solicitação dura somente o tempo

referente à ligação recebida pelo técnico. Já no Help Desk pode-se, além disso,

serem direcionadas solicitações para um segundo nível, sendo este um fornecedor,

19

uma empresa terceirizada ou quaisquer outros indivíduos. Neste serviço a

solicitação tem um tempo de duração relativamente maior para ser concluído.

Ainda, Cohen (2008) diz que o Call Center trata de solicitações que já

tiveram seus problemas descobertos, desenvolvendo suas atividades através de

roteiros e scripts. O Help Desk, além de trabalhar desta forma, enfrenta desafios que

não estão previstos. Suas atividades são muito mais complexas, tendo que, na

maioria das vezes, analisar o problema, encontrar a solução para o mesmo e

trabalhar sob pressão exercida pelo cliente.

Atualmente o termo Help Desk está sendo trocado por Service Desk, pois os

técnicos do atendimento estão tendo responsabilidades que antigamente não tinham

em suas atividades. Estes técnicos passaram a realizar serviços que exigem

deslocamento até o usuário para a correção de algum problema ou também fornecer

suporte ao mesmo, realizando assim o serviço (COHEN, 2008).

Para Cohen (2008), existem duas expressões de interesse no Help Desk,

uma é “cliente”, que se refere à pessoa negociante do serviço e a outra é “usuário”,

que corresponde à pessoa que utiliza do serviço prestado pelo Help Desk, sendo

esta a pessoa que tem maior contato com o suporte. Assim, deve-se considerar a

existência de todo um processo numa solicitação de serviço, desde seu início até a

entrega do resultado esperado pelo cliente.

A Ilustração 1 apresenta um diagrama representativo do processo de uma

solicitação de serviço.

Ilustração 1: Processo de Solicitação de Serviço.

Fonte: STATDLOBER (2006, p.6).

O processamento ou as atividades demonstradas na Ilustração 1

20

representam tudo o que ocorre entre a entrada e saída de uma solicitação. Portanto

isso significa que uma solicitação de um cliente até a resposta ao mesmo, passa por

todas essas etapas (STATDLOBER, 2006).

Para Pohlmann (2006), as solicitações ou incidentes relacionados a Help

Desk e Service Desk também podem ser denominados como “chamados”.

Outro aspecto levantado por Statdlober (2006) diz que um processo de

atendimento apresenta sempre as seguintes partes do chamado:

Solicitação ou necessidade inicial do cliente ou usuário;

O processamento da solicitação;

A resposta do Help Desk;

Se houver, o envio de mercadoria, assistência técnica, etc.;

Os elementos de controle do processo, como regras e os requisitos definidos

pelo cliente ou usuário, e o Help Desk.

Conforme Cohen (2008) existe uma tabela básica para que as empresas

possam administrar seus chamados, facilitando, desta forma, a organização da sua

equipe e permitindo ao usuário visualizar o tempo para que seu chamado seja

analisado e resolvido. O Quadro 1 mostra as prioridades dos chamados.

Quadro 1: Prioridade dos Chamados.

Prioridade Componente Tempo de solução

Crítica Crítico parado 15 mim

Urgente Crítico degradado 2 horas

Média Não-crítico 8 horas

Baixa Outras solicitações/questões 12 horasFonte: COHEN (2008, p. 31).

Uma das ferramentas que pode auxiliar o gerenciamento dos chamados é

um software especializado para Help Desk que, segundo Aurélio (2009), é um

aplicativo responsável por coordenar e automatizar muitas das atividades rotineiras

em um ambiente de suporte. Este software tem como sua principal característica

gerenciar telefonemas, bases de conhecimento, chamados, resoluções de

problemas e sistemas para auto-atendimento dos usuários. Este software deve ser

compartilhado entre todos os níveis de atendimento, compreendendo desde o

atendimento direto ao usuário, até os responsáveis pelos pedidos que serão

21

posteriormente verificados.

O mesmo autor elenca como principais benefícios de um sistema

especializado em controle de solicitações de Help Desk:

Oferecer um canal de comunicação direto e permanente entre a

empresa e seus clientes;

Permitir prestar atendimentos uniformes e sistemáticos;

A solicitação não necessariamente necessita da presença do

solucionador;

Os problemas podem ser melhor gerenciados, de acordo com a

urgência e prioridade dos mesmos;

Registrar um histórico de questionamento e soluções já fornecidos;

Permitir maior flexibilidade na resolução de dúvidas básicas;

O atendimento é feito com maior rapidez e maior eficiência;

Fazer com que a equipe profissional fique mais motivada;

Maior comprometimento com os objetivos;

Permitir a implementação de melhorias contínuas para o processo;

Pode fornecer informações estatísticas para a tomada de decisões.

2.1.2 FAQ – Questões Frequentemente Perguntadas

Conforme Dornelles (2001), FAQ deriva da abreviatura da expressão inglesa

Frequently Asked Questions, que traduzida literalmente significa “Questões

Frequentemente Perguntadas”. Para Kuester (2004, p. 27), “o mecanismo de FAQ é

muito utilizado em páginas Web que prestem algum tipo de serviço”.

As ferramentas FAQ são documentos com o objetivo de responder às

perguntas realizadas com maior frequência pelos usuários, permitindo que os

mesmos tenham o esclarecimento rápido e objetivo de suas dúvidas, diminuindo o

número de perguntas semelhantes (BAZZANELLA, 2007); (SILVA, 2004).

O conhecimento tácito representa as experiências concretas adquiridas por

cada indivíduo, singularmente. O FAQ é uma das formas possíveis de se expor e

transmitir este tipo de conhecimento aos outros usuários, assim sendo, o objetivo do

FAQ não é retirar a atribuição da empresa de prestar suporte, mas sim facilitar o

trabalho da mesma (BORTOLON; WANGENHEIM; DOMINGOS, 2001);

(DORNELLES, 2001).

Teixeira (2005) menciona que o objetivo do serviço FAQ é fornecer uma

22

quantidade definida de perguntas e respostas para o esclarecimento de dúvidas

sobre um determinado assunto. Desta forma, o controle das perguntas e respostas

contidas no FAQ deve permitir ao seu administrador criá-las, alterá-las, excluí-las e

disponibilizá-las para consulta dos usuários (ISHY; TURINE, 2004).

Segundo Kuester (2004) e Dornelles (2001), a elaboração correta de uma

página FAQ pode diminuir o tempo de consulta dos usuários, solucionando suas

dúvidas satisfatoriamente. Antes da criação da página de FAQ, há a necessidade de

se coletar as perguntas frequentemente feitas pelos usuários, as quais, na ausência

da página de FAQ, seriam feitas ao suporte da empresa. Depois de selecionadas,

devem ser respondidas de maneira correta e em uma linguagem acessível a

quaisquer tipos de usuários que venham a utilizar o sistema.

Para Bortolon, Wangenheim e Domingos (2001), uma das características

essenciais para a melhor utilização de um sistema FAQ é a possibilidade que o

sistema oferece para gerenciar o conhecimento contido em seus documentos.

As questões podem ser inseridas constantemente, utilizando de meios de

coleta, como o e-mail de serviço ou com a percepção das dúvidas constantes sobre

o mesmo assunto no atendimento pessoal (KUESTER, 2004).

O mesmo autor ainda sugere que as perguntas podem estar organizadas em

ordem alfabética ou agrupadas por temas. De acordo com a quantidade de questões

existentes, pode haver a necessidade da implementação de algum mecanismo de

consultas às perguntas, podendo ser feito por índices, com divisões por assunto, ou

por termo livre, no qual o usuário digita as palavras que deseja buscar. Isto fornece

ao usuário maior rapidez na recuperação da questão desejada, não sendo

necessário varrer todas as questões até encontrar uma dúvida similar.

De acordo com Silva (2004), deve ser feita a leitura do FAQ pelos usuários,

antes de se efetuar quaisquer perguntas, pois sua função é exatamente reunir as

informações básicas sobre um assunto, para que as perguntas já respondidas não

sejam repetidas.

Os mecanismos FAQ oferecem vantagens no que se refere ao atendimento,

porém apresentam algumas desvantagens que tornam seu uso pouco difundido.

Um sistema FAQ só tem um funcionamento adequado quando a dúvida do

usuário é básica, referente a um domínio do conhecimento pequeno. É muito

complicado para o administrador do serviço prever todas as variações de perguntas

que podem ser feitas pelo usuário (TEIXEIRA, 2005).

23

Para Teixeira (2005), em grande parte dos casos existe um grande volume

de informação, tornando o FAQ ineficiente. Além disso, o sistema FAQ é estático,

restrito às buscas e requer a leitura de uma infinidade de perguntas antes de

encontrar a resposta desejada, sendo que nem sempre esta resposta existe.

Diante das restrições existentes nos sistemas FAQ, há a possibilidade da

utilização de sistemas que prestam suporte on-line, os quais têm maior abrangência

na resolução de dúvidas e solicitações.

2.1.3 Suporte On-Line

Segundo Ghisleri (2002), caso um cliente não tenha conseguido solucionar

suas dúvidas ou problemas por meio do FAQ, deve existir um canal de comunicação

direto e eficaz com a empresa, onde solicitações cadastradas pelo cliente possam

ser respondidas rapidamente.

Conforme Oliveira e Silveira (2009), a partir do final da década de 1970, com

a inclusão dos computadores para uso comercial, as equipes de suporte não

conseguiam mais atender à demanda de pedidos dos usuários. Com isto, surgiu a

necessidade da criação de sistemas de ajuda, que pudessem atender a estas

solicitações.

A área de desenvolvimento de sistemas vem se expandindo

consideravelmente, acirrando a concorrência entre as empresas deste mercado. Por

este motivo, os diferenciais oferecidos nos sistemas e a relação das empresas com

seus clientes são de fundamental importância na escolha de um produto ou serviço

(OLIVEIRA; ABDALA, 2003).

Para Francisco (2009), as empresas encontram como um de seus desafios,

o desenvolvimento de ferramentas para auxiliar a comunicação entre seus

colaboradores e que disseminem as informações a todos os níveis organizacionais.

Estas devem possibilitar a transmissão das informações para as pessoas corretas.

Para Oliveira e Abdala (2003), um importante diferencial que surgiu com a

evolução dos sistemas foram os canais com o cliente, possibilitando a resolução de

seus problemas e necessidades, contribuindo também com a redução de custos

operacionais, agilizando as atividades.

Segundo Oliveira (2009), os principais objetivos dos sistemas de

gerenciamento de chamados são auxiliar a comunicação com o cliente, aumentar a

transparência do atendimento, organizar o fluxo de trabalho entre cliente e empresa

24

e garantir a entrega e o aceite formal, por parte do cliente, das alterações

solicitadas.

Para Ghisleri (2002), o atendimento dos clientes por meio da internet

proporciona maior agilidade no decorrer dos processos, garantindo maior qualidade

à empresa e oferecendo baixos custos para sua manutenção. O uso destes recursos

é uma forma de proporcionar um avanço em relação às concorrentes, sendo que a

utilização da tecnologia correta pode oferecer muitos resultados e benefícios para

um bom relacionamento com o cliente.

Em atendimentos feitos por meio de sistemas on-line, o cliente é mais

exigente que em um atendimento pessoal ou via telefone, pois esse tem a visão de

que o computador é mais rápido e por isso conseguirão resolver seus problemas

com mais agilidade e descomplicação (PERFORMANCE RESEARCH

ASSOCIATES, 2008). Exatamente por conta desta visão dos clientes, de acordo

com Performance Research Associates (2008), para um atendimento feito via

internet ser bem sucedido, o site deve seguir algumas regras básicas, como número

de telefone visível, facilidade em encontrar as informações desejadas, listas de

perguntas mais freqüentes (FAQ) e utilizar padrões de respostas.

Ghisleri (2002) comenta que a utilização dos computadores com seus

sistemas de informação contribuiu para a eficácia dos processos e a redução de

custos, pois o computador é capaz de realizar as três principais tarefas para garantir

a qualidade do atendimento ao cliente e dos serviços prestados:

O controle da eficácia dos processos e a verificação das melhorias

necessárias, para contribuir no relacionamento com os clientes;

O armazenamento de informações sobre características e

disponibilidades de produtos e serviços para acesso dos atendentes e, em

alguns casos, dos próprios clientes, aumentando o dinamismo do processo;

As diversas linhas de comunicação oferecidas pelos computadores,

como correio eletrônico, permitem uma aproximação virtual entre a empresa e

seu cliente, reduzindo o tempo gasto com uma transação ou atendimento.

Para Numara Software (2007), a grande maioria das interações de negócios

são baseadas em serviços eficientes para gerenciamento da tecnologia da

informação, pois as soluções desenvolvidas para a garantia do bom funcionamento

da central de atendimento são de fundamental importância para o sucesso da

empresa.

25

“A automação do fluxo de trabalho é essencial para assegurar que os

incidentes, problemas e alterações sejam encaminhados, transferidos e

solucionados de maneira eficiente e correta” (NUMARA SOFTWARE, 2007, p. 6).

26

3 TECNOLOGIAS APLICADAS NO ATENDIMENTO A CLIENTES

É notável a constante busca das empresas por novos métodos de

comunicação e interação com seus clientes. Neste âmbito, a internet apresenta-se

como a melhor forma para esse tipo de comunicação. Com o constante

desenvolvimento de tecnologias capazes de tornar o uso dos sistemas on-line tão

simples e dinâmicos quanto às aplicações desktop, pode-se observar, a cada dia, o

crescente aumento de softwares completos atuando na web (ROLIM; ARAÚJO;

TOZZI, 2006). Por esta razão, neste capítulo são demonstradas as tecnologias Web

2.0 e RIA, aplicáveis nos mais variados tipos de solução em sistemas de informação,

incluindo os sistemas de atendimento ao cliente, tema de interesse neste trabalho.

A internet é hoje uma das principais fontes de informações sobre produtos e empresas. Potenciais clientes, consumidores, consultores, representantes, distribuidores, concorrentes, parceiros, potenciais parceiros, estudantes, empregados e candidatos a emprego, em qualquer parte do mundo e a qualquer instante todos utilizam a internet como ferramenta de pesquisa (MERINO, 2006, p. 1).

A quantidade de usuários da internet vem aumentando a cada dia, pois os

usuários perceberam que a rede permite que encontrem as informações desejadas

ou interajam com as empresas, efetuando contatos diretos e tendo retornos

imediatos, além de fornecer maior conhecimento da marca da empresa, seus

produtos e seus serviços. Por esta razão, as empresas estão investindo no

desenvolvimento de websites, para utilizá-los como canal de comunicação e

interação com os clientes (MERINO, 2006).

De acordo com Salatiel (2007), a primeira geração da web correspondia a

um modelo de produção da comunicação em massa, com portais e sites

funcionando como emissores de informação, porém disponibilizava poucos

mecanismos para interação do usuário com a empresa.

O mesmo autor completa dizendo que, na primeira versão da web, o

conteúdo da internet era produzido em sites, por meio do código HTML (HyperText

Markup Language), sendo enviado a um servidor, de onde os arquivos eram

distribuídos na rede. Para estas tarefas, necessitava-se dominar linguagens de

programação para desenvolver os sites. Com a Web 2.0, os serviços passaram a ser

administrados e o conteúdo passou a ser gerado dinamicamente, em páginas

construídas baseadas no processo comunicativo entre o usuário e o receptor.

Com a evolução da web, os serviços oferecidos pela rede estão se tornando

27

cada vez mais rápidos, cômodos e fáceis de usar, tornando-se cada vez mais

democratizados, sendo tão integrados à vida diária das pessoas que os usuários

nem percebem que usam a web para realizar tais serviços, seja para o trabalho ou

para o lazer (ANTUNES, 2009).

A nova geração da web representa uma forma diferente de relacionamento

entre as pessoas, gerando novos comportamentos, construindo novas formas de

socialização. O seu foco é o usuário, produtor de informações, qualquer usuário

pode produzir, publicar e compartilhar conteúdo (ANTUNES, 2009).

Com os avanços tecnológicos recentes, houve uma potencialização da participação dos usuários no que diz respeito à criação, compartilhamento e difusão de arquivos na internet. Cada vez mais os sites passam a se fundamentar em dados recolhidos e postados (disponibilizados online) pelos próprios internautas (BRESSAN, 2007, p. 1).

Neste contexto, o surgimento da Web 2.0 representa um novo conceito em

prestação de serviços pela internet, permitindo maior interatividade e colaboração de

seus usuários.

3.1 WEB 2.0

3.1.1 Referencial Histórico

O ponto crucial para o início da revolução da web ocorreu em 2001, por

decorrência do estouro da “onda ponto-com”. Muitas pessoas acreditavam que a

web havia sido supervalorizada, quando, na verdade, as ondas e as consequentes

crises econômicas parecem ser uma característica comum para qualquer revolução

tecnológica. Estas crises normalmente marcam o momento em que uma nova

tecnologia ascendente está preparada para assumir seu lugar no cenário

econômico. As histórias confirmadas do sucesso da nova web mostram sua força e

começam a desvendar o que separa uma da outra (O'REILLY, 2005).

O termo Web 2.0 teve origem em outubro de 2004, durante um

brainstorming realizado em uma conferência entre as empresas O’Reilly Media e

MediaLive International, ambas produtoras de eventos e conferências relacionados à

tecnologia da informação. Os principais objetivos abordados neste evento foram

analisar as novas características da rede, reconhecer tendências e prever as

possíveis inovações do mundo virtual para os próximos anos (PREUSS, 2007);

(BRESSAN, 2007).

28

Neste evento, Dale Dougherty, vice-presidente da O’Reilly Media e um dos

pioneiros da web, observou que, ao contrário de ter sido descontinuada, a web tinha

mais força do que nunca, com novos sites e aplicações sendo criados com incrível

regularidade. Com isto, passou-se a considerar um novo conceito de internet, o qual

repercutiu nos eventos dos anos posteriores, sendo discutido também em 2005 e

2006. A expressão foi se tornando popular e nomeou uma série de conferências

sobre o tema, chamando a atenção de jornalistas, empresas de softwares, usuários

de todo o mundo, quando o termo se reforçou e foi adotado por grandes empresas,

como Microsoft e Google (PREUSS, 2007); (BRESSAN, 2007); (O'REILLY, 2005).

3.1.2 Definição e Características

O'Reilly (2005) enfatiza que a Web 2.0 pode ser vista como um conjunto de

princípios e práticas que unem um verdadeiro sistema solar de sites, demonstrando

alguns ou todos esses princípios, tendo distâncias variadas com relação ao núcleo

deste sistema. Com base nestes fatores, surgiu o mapa da Web 2.0, que foi

desenvolvido no mesmo brainstorming onde foi criado o conceito. É uma obra que

ainda está em andamento, mas demonstra muitas das idéias que irradiam a partir do

núcleo da Web 2.0, conforme demonstrado na Ilustração 2.

29

Ilustração 2: Mapa da Web 2.0.

Fonte: Adaptado de MEIRELLER; MOURA (2007, p. 13).

Meireller e Moura (2007) apontam que este mapa apresenta três pontos

principais referentes ao núcleo do conceito de Web 2.0:

O posicionamento estratégico da Web 2.0 como plataforma,

implementando novas tecnologias e correspondendo às atitudes do usuário

frente a elas;

O novo posicionamento do usuário quanto à tecnologia, o qual

começa a controlar seus próprios dados;

As características do novo conceito, como o surgimento de aplicativos

oferecendo serviços on-line, ambiente estruturado baseado em uma arquitetura

que compreende a participação do usuário, boa relação custo-benefício,

aplicativos sendo algo a mais que simples ferramentas de concatenação de

inteligência coletiva.

Na visão de Platt (2007), Web 2.0 é uma nova plataforma com aplicações e

dispositivos interconectados, ricos em interface e com opções ajustáveis. Este novo

conceito, ao contrário da versão anterior da web, permite que usuários comuns

30

também sejam criadores da nova internet, trocando experiências e criatividades com

maior facilidade.

Entre os novos conceitos que surgiram com a Web 2.0, destacou-se também

a folksonomia, a qual, de acordo com Pereira (2006b), é uma forma de criar uma

relação entre as coisas, descentralizando as informações, diferentemente de uma

forma hierárquica.

Ao contrário da taxonomia, que se baseia na organização das informações

por especialistas através de um vocabulário controlado, a folksonomia representa

uma classificação social de “baixo para cima”. As tags (etiquetas) permitem que as

informações sejam indexadas a partir de livres associações e não mais a partir de

um vocabulário controlado, como na taxonomia (AQUINO, 2007).

Para Meireller e Moura (2007), os sistemas de buscas baseados em

folksonomia permitem apontar tendências de comportamento dos usuários e, com

isso, novos serviços podem ser implementados.

Estas novas invenções tecnológicas tocaram profundamente os métodos de

pesquisa de informações na documentação dos sites, que antes eram feitas de

forma restrita, trazendo outras formas de construção investigatória na web,

originando novos conceitos ou dando novo significado a conceitos antigos. Neste

meio, os próprios usuários participam efetivamente da classificação das informações

através de tags, podendo influenciar naquilo que é apresentado como mais

importante, tanto para ele como para outros usuários com os mesmos interesses

(NASCIMENTO, 2008).

"A Web 2.0 tem repercussões sociais importantes, que potencializam

processos de trabalho coletivo, de troca afetiva, de produção e circulação de

informações, de construção social de conhecimento apoiada pela informática"

(PRIMO, 2007).

O suporte é a segunda área mais conhecida para o uso das técnicas da Web 2.0. Primeiramente, as organizações usam as técnicas de mensagens instantâneas e de bate-papo para suporte em tempo real para os produtos. Depois, o uso de captura de imagem e vídeo para comunicação e resolução de problemas. O uso de especialistas de produtos baseados em comunidade e grupos de discussão de auto-ajuda é a terceira e mais importante área: a auto-ajuda tem funcionado muito bem em comunidades e é um meio de fornecer suporte de alta qualidade e de custo muito baixo. Contudo, como acontece com a maioria dos sistemas baseados em sociedade, a mecânica real desses grupos de auto-ajuda não é simples e exige raciocínio e especialização (PLATT, 2007).

31

Para Cabrera (2006a), com a Web 2.0 não existirá mais um choque entre

uma plataforma e um aplicativo, mas sim um choque entre plataformas, cada uma

com suas características, onde monopólio sobre os sistemas operacionais deixará

de existir. Esse conceito tende a quebrar os paradigmas dos aplicativos

dependentes de plataformas e dos sistemas operacionais, pois a web oferece uma

gama de aplicações que não dependem das APIs (Application Program Interface)

dos sistemas operacionais.

3.1.3 Evolução

Para O'Reilly (2005), o princípio central por trás do sucesso das grandes

empresas nascidas na era da Web 1.0, que sobreviveram para liderar a era Web

2.0, é que as mesmas abraçaram o poder da web para aproveitar a inteligência

coletiva. O autor continua dizendo que existe muita discordância quanto ao que

significa Web 2.0, com algumas pessoas condenando este termo como sendo um

chavão de marketing sem sentido e outras aceitando como a nova sabedoria

convencional. Para isto, inicialmente foi criado um quadro comparativo entre as duas

gerações da web, demonstrado no Quadro 2:

Quadro 2: Comparativo inicial entre Web 1.0 e Web 2.0.

Web 1.0 Web 2.0

DoubleClick Google AdSense

Ofoto Flickr

Akamai BitTorrent

mp3.com Napster

Britannica Online Wikipedia

Sites pessoais Blogging

Especulação de nomes de domínio Motor de busca otimizada

Visualização de páginas Custo por clique

Captura de tela Serviços web

Editorial Participação

Conteúdo de sistemas de gestão Wikis

Diretórios (taxonomia) Tagging (folksonomia)Fonte: O’REILLY (2005, p. 1).

Primo (2007) salienta que, na primeira geração da web, os sites eram

32

manuseados como unidades isoladas, sendo que nesta segunda geração são

tratados como uma estrutura integrada de funcionalidades e conteúdo.

O autor acrescenta que Web 2.0 não é apenas uma combinação de técnicas

informáticas, mas corresponde também a um período tecnológico, a um conjunto de

novas estratégias mercadológicas e a processos de comunicação, mediados pelo

computador.

A Web 2.0 é a segunda geração da internet. Esta nova geração permite um

ambiente mais dinâmico para os usuários, onde estes possam colaborar para

ampliar os conteúdos, tendo como foco principal possibilitar ao usuário ter na

internet uma plataforma de aplicações, que possibilite a troca de arquivos,

informações, e-mail, mídias, entre outros conteúdos oferecidos pela web, sem que

sejam necessárias ferramentas específicas instaladas em seu computador.

(ENTENDA, 2006); (PREUSS, 2007).

Muitos consideram toda a divulgação em torno da Web 2.0 um golpe de marketing. Como o universo digital sempre apresentou interatividade, o reforço desta característica seria um movimento natural e, por isso, não daria à tendência o título de "a segunda geração". Polêmicas à parte, o número de sites e serviços que exploram esta tendência vem crescendo e ganhando cada vez mais adeptos (ENTENDA, 2006).

Um dos aspectos mais comentados na era Web 2.0 é o crescimento da

utilização dos blogs. Páginas pessoais, diários pessoais e colunas de opiniões são

conhecidas desde o início da internet. Neste âmbito, um blog é basicamente uma

página pessoal em formato de diário. Ocorre que, com o emprego de novas

tecnologias, a organização cronológica de um blog “parece uma diferença trivial,

mas conduz uma cadeia completamente diferente de distribuição, de publicidade e

de valor” (O'REILLY, 2005, p. 3).

O autor complementa dizendo que, para o sucesso dos blogs, uma das

tecnologias que fez diferença foi o RSS (Really Simple Syndication), o qual

possibilita que as pessoas não simplesmente acessem uma página, mas que

registrem uma assinatura, recebendo uma notificação cada vez que a página é

alterada. Esta característica é chamada de “rede incrementável” ou “rede viva”.

Estes novos modelos de sites, os quais geram conteúdo dinamicamente,

substituíram as páginas estáticas, sendo que não somente as páginas são

dinâmicas, mas também os links. Estes links encaminham o usuário a outros blogs,

que também estão em constante mudança, tendo, portanto, muito mais relevância

que, por exemplo, um favorito ou um link para uma única página.

33

O’Reilly (2005) finaliza dizendo que “quanto mais forem os usuários que se

utilizam de um serviço oferecido, este fica automaticamente melhor”.

3.2 RIA - RICH INTERNET APPLICATION

“RIA (Rich Internet Application, ou em português, Aplicação de Internet Rica)

é um novo tipo de aplicação web cujo objetivo é incrementar e melhorar as opções e

capacidades das aplicações web tradicionais” (CABRERA, 2006b, p. 5).

Com a evolução da internet, os usuários finais estão reservando mais de seus

investimentos em tecnologias. Para fornecer verdadeiramente algum valor aos

usuários, muitas empresas foram forçadas a reavaliar seus modelos de aplicações

para internet, tornando-as mais ricas, criando modelos que combinam o poder de

mídia rica do desktop com o conteúdo rico da web. As empresas também estão

antecipando crescimento no uso de serviços web, visando um mercado onde os

aplicativos precisam compartilhar funcionalidade e dados entre vários tipos de

dispositivos de clientes (ALLAIRE, 2002).

As terminologias de aplicações desktop e web, e tudo que está relacionado a

elas, ainda são confusas e de difícil discernimento, permitindo uma ampla gama de

definições. Existem várias denominações para as tecnologias que processam uma

parte de suas informações em um servidor e outra parte em uma máquina cliente.

Estas tecnologias diferem-se principalmente na quantidade de atividades realizadas

do lado do servidor e do cliente (MORITZ, 2008).

O autor complementa informando que os principais termos utilizados para

nomear estas tecnologias são: Aplicações Desktop, Rich Client ou Fat Client,

Aplicações de Internet Habilitadas, Smart Client, Thin Client, Aplicações Web, Web

2.0 e websites, sendo que RIA é um termo usado para muitas dessas. Na Ilustração

3, são listadas e ordenadas essas diferentes tecnologias, onde o eixo vertical

categoriza a quantidade de processamento feito do lado do servidor e do cliente, e o

eixo horizontal classifica as tecnologias como mais relacionadas a desktop ou a web.

34

Ilustração 3: Distribuição do processamento entre servidor e cliente na RIA.

Fonte: Adaptado de MORITZ (2008, p. 6).

A aplicação RIA fica responsável pelo processamento necessário para a

interface com o usuário, sendo executada no navegador ou outro dispositivo,

enquanto que a transformação e persistência dos dados ficam a cargo do servidor

de aplicativos (RIBES, 2006).

Neste contexto, Cabrera (2006b) e Kiso (2009) reforçam que uma aplicação

baseada em RIA combina a melhor funcionalidade e interface das aplicações

desktop com a abrangência, flexibilidade e baixo custo das aplicações web,

somando-se também o melhor da interatividade e comunicação multimídia, criando

assim uma única e integrada experiência, rica em conteúdo. A Ilustração 4

demonstra esta combinação de características.

35

Ilustração 4: Modelo de interação da RIA.

Fonte: MEIRELLER; MOURA (2007, p. 13).

O conceito RIA é a mais nova forma de desenvolver aplicações de modo

totalmente web, utilizando componentes ricos em interface. Assim, o desenvolvedor

pode utilizar diversos recursos para a aplicação, como transições, efeitos, arrastar,

soltar, entre outros. Esses recursos são utilizados de forma simples, ao contrário do

modelo “HTML + JavaScript”, onde é preciso muito tempo de programação para

chegar ao mesmo resultado das funcionalidades RIA (Schimitz, 2008).

As principais características da RIA, segundo Cabrera (2006b), são:

O uso de novos e mais avançados componentes gráficos;

Aplicações interativas com o usuário, com recursos de áudio, vídeo e gráficos;

A maioria das tecnologias RIA são baseadas em linguagens de programação

que utilizam XML (eXtensible Markup Language), tanto para a interface como

para a transação de dados;

Os servidores onde são executadas essas aplicações são bastante variados,

porém os predominantes são os servidores baseados em Java;

Diminui o consumo de banda utilizado pela aplicação e permite ajustar as

informações para que se reduza a quantidade de transações, através do

protocolo HTTP (HyperText Transfer Protocol). Com isso, irá reduzir o consumo

de memória no servidor onde está hospedada a aplicação;

O modelo de solicitação e resposta não é utilizado, pois o usuário se comunica

36

com a aplicação e a mesma se comunica com o servidor quando necessário;

A possibilidade de execução da aplicação RIA em múltiplas plataformas e

dispositivos de hardware distintos;

Completa separação da camada de apresentação com a camada de negócio;

A transição de estados da aplicação através de objetos.

Segundo Kiso (2009) o objetivo da RIA é fazer uma aplicação mais rápida e

com visual mais dinâmico, oferecendo diversos benefícios, podendo-se citar como

principais:

Interfaces mais rápidas e práticas, possuindo também validações e formatações

em tempo real, sem a interferência do usuário;

O conforto de trabalhar on-line e off-line;

Manutenção e atualização instantânea da aplicação, por ser um ambiente web;

Possuir o melhor das comunicações, o áudio e vídeo.

Ribes (2006) salienta que RIA é um conceito e não uma ferramenta para

desenvolvimento em si, sendo que existem inúmeras opções para o

desenvolvimento das aplicações baseadas neste conceito.

As aplicações RIA resolvem vários aspectos que eram deficientes na web

tradicional, os quais são demonstrados no Quadro 3 (MORITZ, 2008).

Quadro 3: Aspectos da web tradicional resolvidos pela RIA.

Deficiências da Web tradicional Solução fornecida pela RIA

Fraco desempenho, pedido-resposta de renderização do modelo e falta de armazenamento do lado do cliente

Proporcionar eficiência, tempo de execução de alto desempenho, conteúdo e comunicação

Dividida em muitas tecnologias, com pouca interação entre as mesmas

Integrar conteúdo, comunicações e interfaces em um ambiente comum

Falta de orientação a objetos de design, para aplicações em larga escala

Fornecer modelos de objetos poderosos e extensíveis para a interatividade

Faltam componentes e ferramentas fáceis para desenvolvimento orientado de aplicações ricas

Permitir o desenvolvimento rápido de aplicações através de componentes e reutilização

Separação clara entre a lógica de apresentação, a interface do usuário e da aplicação da lógica

Permitir o uso de internet e serviços de dados fornecidos por servidores de aplicações

Falta de suporte simultâneo on-line e off-line

Abraçar os clientes conectados e desconectados

Fonte: MORITZ (2008, p. 20).

37

Cabrera (2006b) reforça que as aplicações RIA evitam vários problemas que

hoje o usuário possui com as interfaces limitadas, como pouca interatividade da

aplicação com o usuário, onde o mesmo não possui uma visão geral do sistema.

Com tudo isso o resultado final de uma aplicação feita com o conceito RIA é um bom

relacionamento com o cliente, com visitas mais frequentes e redução das chamadas

para o suporte da empresa.

38

4 TECNOLOGIAS RELACIONADAS

Serão apresentadas neste capítulo algumas tecnologias relacionadas aos

conceitos de Web 2.0 e RIA, tais como algumas linguagens de programação, o

framework Flex, que se trata de uma nova ferramenta baseada em RIA, as

ferramentas IDE (Integrated Development Environment), que auxiliam no

desenvolvimento, o servidor web JBoss 4.0.2, a ferramenta BlazeDs, que faz a

comunicação entre Java e Action Script para um melhor desempenho, e, por fim, o

banco de dados utilizado para guardar todas as informações do protótipo.

Estas tecnologias são aqui apresentadas por serem as utilizadas no processo

de desenvolvimento de um protótipo de sistema de informação que servirá como

forma de demonstração dos benefícios proporcionados pelas tecnologias baseadas

em RIA. A descrição do protótipo, bem como seu processo de desenvolvimento,

serão apresentados em detalhes no próximo capítulo.

4.1 LINGUAGENS DE PROGRAMAÇÃO

Conforme Varejão (2004), as linguagens de programação são as ferramentas

que os profissionais da computação utilizam para desenvolver programas, ou seja,

escrever as instruções que o computador deve seguir para realizar os processos

desejados. As linguagens de programação são ferramentas fundamentais em sua

especialidade e seu estudo aprofundado oferece diversos benefícios, podendo-se

citar:

Uma maior compreensão dos conceitos da linguagem pode mudar a forma

escolhida para resolver problemas, por disporem de métodos possivelmente não

conhecidos pelo desenvolvedor;

Possibilita ao programador um maior entendimento das funcionalidades e

implementações da linguagem de programação, melhorando o desempenho e a

qualidade dos programas;

Auxilia na escolha da linguagem de programação a ser utilizada para o

desenvolvimento de um projeto, pelo conhecimento dos recursos oferecidos por

cada linguagem e como estes recursos são implementados;

Fornece maior habilidade para o conhecimento e aprendizagem de novas

linguagens;

Oferece maior habilidade para efetuar o projeto e criação de novas linguagens.

39

“O objetivo das linguagens de programação é tornar mais efetivo o processo

de desenvolvimento de software”, porém, é importante frisar que este processo visa

tornar a geração e manutenção dos softwares mais produtiva e garantir que sejam

mantidos seus padrões de qualidade (VAREJÃO, 2004, p. 3).

4.1.1 Java

A linguagem Java é uma linguagem orientada a objetos, onde os programas

são desenvolvidos através da utilização de classes. A partir da definição das classes

do projeto, pode ser criada uma infinidade de objetos, sendo estes denominados

como instâncias da classe. Esta linguagem enfatiza arquiteturas cliente-servidor e

programação concorrente (ARNOLD; GOLING; HOLMES, 2007); (PEREIRA,

2006a).

Para Oliveira (1996) e Pereira (2006a), o Java se tornou muito popular por

permitir a criação de qualquer tipo de aplicativo, por possibilitar a construção de

applets, isto é, aplicativos pequenos que podem ser inseridos em uma página HTML,

efetuando processos que os comandos desta linguagem não oferecem, e

principalmente por permitir a manipulação via internet de uma forma incrivelmente

rápida. Java não é apenas mais uma linguagem de programação, mais sim um

conjunto de produtos baseados no poder das redes computacionais.

Pereira (2006a) cita ainda que a tecnologia Java é utilizada atualmente em

larga escala, interessando a programadores e arquitetos de soluções diversas,

mesmo que não trabalhem diretamente com a mesma, pois, em um futuro próximo,

uma grande parte das aplicações web e sistemas distribuídos serão escritos nesta

linguagem. Pelo fato da internet ser a maior rede de computadores, muitas

empresas estão desenvolvendo seus novos sistemas na plataforma web, a fim de

agilizar seus processos ou até mesmo manter uma comunicação mais adequada

com seus clientes.

Segundo Abinader e Lins (2006), nos últimos anos houve um crescente

surgimento e evolução de tecnologias para aplicações na internet, sendo que a

orientação a objetos marcou o início de novos modelos de projeto e programação de

softwares. Estas tecnologias estão se tornando cada vez mais sofisticadas, usuais e

elegantes. Com a grande procura e utilização de serviços web, percebeu-se que

esses recursos poderiam ser utilizados também em larga escala.

Pereira (2006a) sugere que Java é uma escolha inteligente para desenvolver

40

aplicações web, sendo que, se for estudada com maior atenção, podem ser

alcançados melhores resultados.

4.1.2 XML

Conforme Deitel et al (2003), no final dos anos 1960, a IBM (International

Business Machines) estava enfrentando problemas com as documentações e

comunicação entre os computadores. Isso era causado pela ausência de um formato

único de documentos que pudesse ser manipulado independente de plataforma. Por

volta de 1969, a equipe de pesquisadores da IBM desenvolveu uma linguagem de

marcação, a GML (Generalized Markup Language), que servia para estruturar

documentos legais. Enfim, em 1986, abriram-se as portas para um desenvolvimento

adicional, surgindo então a SGML (Standard Generalized Markup Language), que

rapidamente se tornou padrão de negócio e intercâmbio pelo mundo.

De acordo com Walsh (1998) a SGML é definida pela norma ISO

(International Standards Organization) 8879:1986, sendo considerada um padrão

independente para manter repositórios de documentação estruturada. Contudo por

razões técnicas, não é bem adaptada para servir documentos através da web. Este

fato é também abordado por Bender Jr. (2001), quando diz que a SGML

apresentava a desvantagem de ser uma linguagem complexa, mas que possuía

atrativos relevantes. Isso fez com que a XML (eXtensible Markup Language)

nascesse, como um subconjunto da SGML, e se tornasse a linguagem de marcação

mais tradicional do gênero. Isso porque, de acordo com Walsh (1998), qualquer

sistema SGML é capaz de ler documentos XML, entretanto, a compreensão desses

documentos não requer um sistema com todas as particularidades de SGML.

XML é a primeira linguagem que torna os arquivos manipuláveis tanto pelo

homem como pelo computador, isso porque o texto é marcado por tags editáveis,

tornando-a mais poderosa que a HTML. XML representa uma marcação inteligente

onde as pessoas podem visualizar os documentos e ao mesmo tempo

computadores podem processá-los (DEITEL et al, 2003).

Conforme Silva Filho (2004), projetos desenvolvidos em XML têm como

objetivo prover o suporte a SGML e HTML, facilitando a implementação. Embora

seja uma linguagem simples, XML pode descrever rotinas complexas de estrutura de

dados.

Para Bender Jr. (2001), a linguagem XML poderia ser considerada a

41

substituta da HTML, mas ao contrário do que se pensa a XML é uma aliada, dando à

HTML um papel de auxiliar no desenvolvimento de Web sites. Segundo Deitel et al

(2003), XML nasceu com o intuito de diminuir as limitações de formatação da HTML,

pois a falta de extensibilidade desta acarretava em definições ambíguas ou até

equivocadas.

Assim “Uma das principais diferenças entre o HTML e o XML é que o HTML é

usado para a formatação e exibição de informações, enquanto o XML é usado para

descrever e armazenar essas informações” (SILVA, 2001, p. 18). Diferente da

HTML, que usa tags fixas, a XML permite a construção de tags específicas

resultando em uma solução que satisfaça as mais variadas demandas (SILVA

FILHO, 2004).

Para Walsh (1998), a XML não especifica um conjunto de marcas ou

semânticas, mas especifica sim uma forma ou meta-linguagem para descrever a

linguagem de marcação. Em outras palavras, a XML é um mecanismo de definição

de tags que cria uma relação entre elas. Se não existir uma definição de tags, não

haverá uma semântica concebida, semântica esta que é especificada pela aplicação

que a processa ou pela folha de estilos.

Por estas razões, XML pode ser considerada uma fábrica de outras

linguagens de programação, onde é possível construir uma nova linguagem

específica baseada em XML. Com isso pode-se obter um rápido aprendizado, pois

como a linguagem XML é a base, será necessário somente aprender novas tags e

atributos. A vantagem fica por conta de que a mesma ferramenta básica pode

processar essas linguagens (DAUM; MERTEN, 2002).

4.1.3 MXML

Ghiorzi (2008) trata de MXML (Macromedia Flex Markup Language) como

sendo uma linguagem baseada em XML que é composta por várias marcações que,

juntas, compõem a aplicação. É mais completa que a linguagem HTML, por possuir

uma maior quantidade de componentes, e ainda possui componentes mais

interessantes, como menus e elementos de controle de dados mais complexos que

as simples tabelas HTML. A MXML, além de facilitar a publicação de interfaces,

também pode ser usada nas camadas lógicas, como por exemplo, fazendo

chamadas a funções para controle de dados ou integração com outras linguagens

de programação.

42

Conforme Schimitz (2008) a MXML é uma linguagem de marcação de texto

usada principalmente para inserir componentes visuais na aplicação. Isso acontece

como na linguagem HTML, onde se usam tags para criar uma página web. A

linguagem MXML possui diversos componentes que podem ser inseridos no projeto,

porém precisam ser observadas algumas regras da linguagem XML, como:

As tags devem estar em forma hierárquica;

As tags devem possuir o fechamento;

As tags únicas devem possuir fechamento.

A Ilustração 5 apresenta um exemplo de um código em MXML:

Ilustração 5: Exemplo de código em MXML.

Fonte: Dos autores.

Fraga (2009) diz que um código MXML, ao ser compilado, passa por um

parser e é convertido em Action Script (abordada em detalhes na próxima seção

deste documento). Após esta conversão, o compilador transforma as classes Action

Script, em um arquivo no formato “.swf”.

A diferença básica entre a publicação MXML e a publicação HTML é que a

primeira é “renderizada” pelo Flash Player, em contrapartida da “renderização” pelo

browser no HTML. Isso permite uma gama de possibilidades em relação à

apresentação da interface, que pode conter animações, efeitos de transição, efeitos

gráficos, vídeos e sons nativamente, sendo muito mais poderosa e amigável ao

usuário do que a publicação baseada em páginas HTML (COENRAETS, 2003).

4.1.4 Action Script 3.0

Action Script 3.0 é uma linguagem de programação originada da linguagem

C, sendo consequentemente muito semelhante às linguagens PHP (Hipertext Pré-

Processor) e Java. É orientada a objetos, com poucas características de linguagens

estruturais, sendo utilizada para a publicação de aplicações em Flash, que

43

correspondem a todos os tipos de aplicações que são executados no Flash Player,

podendo ser desenvolvidas em ambiente Flash ou Flex. As interfaces desenvolvidas

nestas linguagens são compiladas em ferramentas que são executadas na máquina

virtual do Flash Player (extensão “.swf”). Trata-se de uma implementação do padrão

ECMAScript (padronização internacional para a linguagem de programação em

scripts). Sua sintaxe é muito semelhante ao JavaScript, porém também é muito

conhecida por ser baseada em classes, herança e interfaces, tornando-se uma

linguagem mais próxima do Java. O Quadro 4 demonstra algumas comparações

entre as sintaxes das linguagens Java 5 e Action Script 3.0. (GHIORZI, 2008);

(FRAGA, 2009); (SCHIMITZ, 2008).

Quadro 4: Comparativo entre as sintaxes Java 5 e Action Script 3.0.

Action Script 3.0 Java 5

Empacotamento de classes

.swc .jar

Herança Class Cliente extends Pessoa(...)

Class Cliente extends Pessoa(...)

Declaração de constantes

Const NU_MAX:int = 999; final NU_MAX:int = 999;

Operador de checagem de tipo de objeto

If (meuObj is String) {} If (meuObj instanceof String) {}

Tipos primitivos Boolean, int, uint, Number, String

byte, short, int, long, float, double, Boolean, char

Arrays var array:Array = new Array();

var array:Array = [];

int Array[];

array = new int[4];

Packages package com.xyz{

class MinhaClasse{…}

package com.xyz{

class MinhaClasse{…}

Níveis de acesso public, private, protected, internal(default)

public, private, protected(default)

Impressão no Console

trace();

*somente no modo de debug

System.out, println(), printf()

Imports import com.abc.*;

import com.abc.MinhaClasse;

import com.abc.*;

import com.abc.MinhaClasse;

Tratamento de Exceptions

try, catch, throw, finally try, catch, throw, finally, throws.

Fonte: FRAGA (2009, p. 22).

Schimitz (2008), salienta que o Action Script 3.0 foi totalmente refeito em

44

relação ao Action Script 2.0 do Adobe Flash. O objetivo desta mudança foi fornecer

ao Adobe Flex 3.0 características de uma linguagem profissional, com técnicas de

programação mais avançadas.

O mesmo autor menciona que o Action Script 3.0 engloba muitos recursos,

como por exemplo:

A verificação de dados em tempo de real;

A implementação efetiva de um sistema de herança baseado em classes e não

em protótipos;

Suporte para “package”, “namespace” e expressões regulares;

Revisão completa da API do Flash;

Gerenciamento dos eventos feito com a especificação “DOM (Document Object

Model) event handling”;

Integração mais eficiente com XML do que nas versões anteriores e

Conformidade total com o padrão ECMAScript.

O autor complementa dizendo que os processos de desenvolvimento de

aplicativos em Flex sempre possuem padrões. Ao iniciar uma aplicação, desenha-se

a mesma utilizando o modo Design. Após montar o layout da aplicação, utiliza-se, no

mesmo arquivo mxml, o código Action Script 3.0, que é inserido entre as tags

<mx:Script> e </mx:Script>. A Ilustração 6 demonstra um exemplo de código em

ActionScript 3.0:

Ilustração 6: Exemplo de código em ActionScript 3.0.

45

Fonte: Dos autores.

Para o desenvolvimento em Flex, o Action Script 3.0 é utilizado para escrever

scripts que ajudam na interface, como eventos e validações. Para aplicações que

exigem uma organização mais elaborada, o Action Script 3.0 é utilizado para criar as

camadas posteriores à view1, como controller2, command3, entre outras. O Action

Script 3.0 também pode ser usado para a criação de componentes customizados,

podendo-se citar o Flex SDK (Software Development Kit) como exemplo, pois ao

abrir o código fonte, percebe-se que o mesmo contém códigos em Action Script 3.0

puro (FRAGA, 2009).

4.2 FERRAMENTAS

O termo programação não é referente somente ao ato de escrever códigos-

fonte, pois engloba também a documentação deste código, a realização de testes, o

projeto do software e demais tarefas que se revezam durante o período de

desenvolvimento de um sistema. Por causa deste revezamento de tarefas, cada

uma com seu ambiente de trabalho específico, demanda-se tempo, pois o

desenvolvedor precisa se adaptar a cada nova interface e gerenciar a integração

entre todas as interfaces utilizadas no projeto (VASCONCELOS; HERBSTER;

FECHINE, 2005).

O termo IDE significa Ambiente Integrado de Desenvolvimento (do inglês

Integrated Development Environment). Este ambiente reúne diversas ferramentas e

características especializadas no apoio ao desenvolvimento de um sistema, para

agilização do processo de desenvolvimento. Em geral, estes ambientes contam com

uma técnica que oferece maior rapidez e facilidade no desenvolvimento de

softwares, permitindo um melhor aproveitamento. Os ambientes IDE são integrados,

pois envolvem, no mínimo, um editor, um compilador e um depurador (FERREIRA,

2009, SEBESTA, 200 apud CHAVES; SILVA, 2008).

Para Rodrigues (2007), o ambiente IDE tem como principal função auxiliar

na programação e agilizar o desenvolvimento de softwares. Geralmente são

compostos por editores de código, compiladores, emuladores e ferramentas

similares. As ferramentas IDE integram várias ferramentas em um único ambiente, a

1 View corresponde a camada de apresentação (FRANCO, 2009, p. 6).2 Controller é a camada responsável por delegar as requisições vindas da camada de visão (View) (FRANCO, 2009, p. 6).3 Command é a camada que através de ações, executa o processo lógico vindo da camada Controller (SORROCHE; LOPES, 2002, p. 6).

46

fim de facilitar o trabalho de desenvolvimento e aumentar a produtividade

(VASCONCELOS; HERBSTER; FECHINE, 2005).

A utilização do IDE mais adequado para o desenvolvimento de um software

tem grande importância para o sucesso do mesmo, principalmente no

desenvolvimento de aplicações com foco em sistemas web, pois estes normalmente

apresentam maior complexidade que os demais sistemas. Neste âmbito, os IDE

mais conhecidos e utilizados são Eclipse, Visual Studio e Carbide (RODRIGUES,

2007); (CHAVES; SILVA, 2008).

Conforme Barros (2006), o desenvolvimento de sistemas utilizando-se as

linguagens mais populares, como o Java, necessita de ambientes IDE complexos e

sofisticados para lidar com a complexidade e tamanho dos sistemas desenvolvidos.

De acordo com Chaves e Silva (2008), para o desenvolvimento de sistemas

web confiáveis e de alta qualidade, é de fundamental importância a utilização de

linguagens de programação e ferramentas de desenvolvimento adequadas, pois,

segundo Ferreira (2009), auxiliam na economia de tempo, além de tornar o

desenvolvimento de um software mais fácil e divertido.

4.2.1 Eclipse Ganymede

O Eclipse consiste de um IDE gratuito, genérico e de código aberto,

desenvolvido em Java, utilizado para o desenvolvimento de aplicações, tendo como

foco principal o desenvolvimento para a linguagem Java, podendo ser utilizado

também para outras plataformas, tais como C/C++, Cobol, Eiffel, PHP e UML

(Unified Modeling Language). (MARINHO, 2009); (ISCTE, 2009); (GRUPO DE

USUÁRIOS JAVA, 2009); (BARROS, 2006).

Conforme Lozano (2003), o Eclipse inseriu um novo paradigma nos

ambientes IDE, sendo focado no suporte às metodologias ágeis, ao invés de focar

em recursos visuais.

De acordo com Tellarin (2004), o Eclipse é uma proposta de empresas que

apóiam a utilização de arquiteturas de código aberto para a criação de ambientes

IDE, permitindo que a indústria de softwares desenvolva novos programas,

ferramentas e aplicativos, de uma forma padronizada e otimizada.

A responsabilidade pela continuidade de manutenção e desenvolvimento

desta ferramenta ficou com o consórcio de empresas denominado Eclipse.org,

criado pela IBM, após a empresa gastar US$ 40 milhões de dólares para o

47

desenvolvimento e licenciamento da plataforma. A IBM foi responsável pelo início do

desenvolvimento do Eclipse, que perdurou até o ano de 2004, quando o Eclipse foi

disponibilizado como um projeto de código livre (MARINHO, 2009); (ECLIPSE

FOUNDATION, 2009).

O Eclipse possui código fonte aberto, fornecendo flexibilidade aos

desenvolvedores, e tem seu objetivo focado na interação de componentes.

Enquanto grande parte dos ambientes IDE permite a criação de novas

funcionalidades somente por seus parceiros, o Eclipse com uma plataforma baseada

em plugins, permite que qualquer programador desenvolva novas funcionalidades,

agregando-as às existentes neste IDE, além de oferecer a visualização de forma

rápida de todos os arquivos contidos no projeto que está sendo desenvolvido

(ISCTE, 2009); (AGUIAR; MERIZE; SIQUEIRA, 2007); (LIMA et al, 2005).

Segundo Tellarin (2004), esta ferramenta fornece uma estrutura flexível e

exemplos de construção de código, facilitando a criação e utilização de suas

ferramentas. O Eclipse é utilizado em grande escala para o desenvolvimento de

aplicações em diversos sistemas operacionais, tais como Solaris, AIX (Advanced

IBM UNIX), HP-UX e Linux.

Lima et al (2005) informa que, pelo fato do Eclipse ser uma interface IDE, ele

fornece várias vantagens, podendo-se citar como principais:

A visualização de forma clara de todos os arquivos do projeto;

Oferece ferramentas para gerenciar trabalho coletivo;

Permite efetuar a compilação do projeto em tempo real;

Possibilita a geração automática do código.

Lozano (2003) afirma que, pelo fato de ser uma ferramenta livre, o Eclipse

oferece maior confiabilidade no desenvolvimento de novas ferramentas. Este fator,

aliado às facilidades para a utilização da linguagem Java, contribuiu para o

crescimento explosivo do Eclipse entre empresas e universidades.

4.2.2 Flex

O Flex é um framework de desenvolvimento de aplicações RIA, contendo diversos tipos de componentes visuais e uma poderosa linguagem de programação chamada Action Script 3.0. Com esse conjunto, o Flex torna-se uma ferramenta essencial para a criação de software para a Web, utilizando o conceito de RIA (SCHIMITZ, 2008, p.1).

O Flex nasceu da necessidade de um ambiente de programação com mais

48

características das aplicações web, que permitisse uma fácil criação e manipulação

de interfaces e códigos, e que ainda utilizasse o Flash Player (suas características

de animação, multimídia, etc.) em sua execução, sem que o desenvolvedor

precisasse necessariamente ter conhecimento das técnicas de animação em Flash.

Com o Flex, o desenvolvedor pode elaborar aplicações para a web muito parecidas

com o HTML, pelo fato de que essa nova linguagem foi desenvolvida baseada na

linguagem de marcação, que utiliza os conceitos da XML, a qual é chamada de

MXML (apresentada em detalhes na seção 41.3 deste trabalho). Desta forma é

muito mais fácil criar interfaces em Flex do que no ambiente Flash, que requer um

conhecimento de desenho vetorial e criação de componentes (GHIORZI, 2008).

O mesmo autor menciona ainda que, com o surgimento do Flex, a Adobe4

(criadora do sistema), entrou para o mundo das criações de aplicações RIA. Estas

aplicações podem ser compiladas em tempo de execução, no momento em que o

desenvolvedor solicita ao servidor, permitindo que a interface possa ser gerada no

mesmo momento. Assim, o Flex entrou na “concorrência” com outras tecnologias

dinâmicas da web, tais como HTML/JavaScript.

O Flex é composto por várias classes de Action Script 3.0, formando com isso

um framework com o objetivo de construir interfaces ricas, baseado na plataforma

Adobe Flash. Uma interface construída em Flex pode ser executada tanto no

browser, através do Adobe Flash Player, como no desktop, utilizando o AIR (Adobe

Integrated Runtime) (FRAGA, 2009).

Schimitz (2008) cita que a tecnologia Flex é divida em quatro produtos, sendo

estes:

Adobe Flex 2 SDK;

Adobe Flex Builder 3.0;

Adobe Flex Data Services 3;

Adobe Flex Charting 3.

Para Fraga (2009) é necessário utilizar o Adobe Flex SDK, pois o mesmo é

um conjunto de ferramentas de compilação construídas em Java (como o javac do

JDK - Java Development Kit), sendo distribuída para a comunidade como um

produto open source. Essa ferramenta possui componentes visuais, formatadores,

validadores e componentes de efeitos visuais e sonoros, indispensáveis para

aplicações em Flex.

4 A Macromedia foi comprada pela Adobe em 2005 (ADOBE SYSTEMS INCORPORATED, 2009b).

49

Fraga (2009) cita que o Flex possui vários meios de comunicação que atuam

entre a view e o back-end, permitindo a construção de uma view independente de

qualquer linguagem server-side (que atua ao lado do servidor). O Flex é apenas um

consumidor de serviços, que não necessita saber qual a origem dos dados, mas sim

qual interface foi utilizada. Quando se desenvolve uma aplicação em Flex,

normalmente utiliza-se de:

MXML para a inserção de componentes visuais e objetos de interfaceamento,

como: <mx:WebService/>, <mx:HttpService/> e <mx:RemoteObject/>;

Action Script para os componentes que auxiliam a view e para a construção de

componentes customizados.

O mesmo autor ainda menciona que um dos diferenciais do Flex em relação

às demais tecnologias é seu poderoso suporte a multimídia. Inicialmente, o Flex era

compostos por APIs (pacotes) para trabalhar com webcam, microfone, som e vídeo.

Um grande exemplo da API multimídia do Flex/Flash é o site YouTube.com de

propriedade da empresa Google.

O framework Flex foi desenvolvido para atender uma boa parte das

linguagens de programação e meios de comunicação presentes atualmente.

Normalmente encontram-se dois tipos de comunicação em uma aplicação web: a

comunicação HTTP (request e response) e Web Services5. O componente

HTTPService do Flex faz as solicitações ao back-end como se fosse uma página

HTML comum, com a diferença de que as suas chamadas são assíncronas e todo o

retorno precisa estar numa estrutura comum, tais como um arquivo XML, uma

estrutura em array, um objeto, etc. Além destes meios, o Flex traz como inovação

um componente de interfaceamento chamado RemoteObject. Este componente

acessa os serviços utilizando o protocolo AMF (Action Message Format), sendo este

um formato binário com compactação baseado em SOAP (Simple Object Accesss

Protocol), que é um protocolo de acesso a objetos, servindo para a troca de

informações ou dados através de objetos criados em várias linguagens de

programação, executado sobre o protocolo HTTP, através de chamadas RPC

(Remote Procedure Call). O RPC é um meio de comunicação que possibilita a troca

de objetos entre o back-end e a interface em Flex (SHREVE, 2005); (FRAGA, 2009).

Scoz (2007) mostra através da Ilustração 7, como é a comunicação da

5 Web Services ou serviços web, são utilizados para a troca de informações da aplicação e o servidor, porém utilizando arquivos XML para fazer tal serviço (SHREVE, 2005).

50

aplicação com o servidor web e o navegador através do HTTP/XML, onde os

mesmos são requisitados para mandar e receber as informações necessárias da

aplicação.

Ilustração 7: Comunicação aplicação/servidor via HTTP/XML.

Fonte: Adaptado de SCOZ (2007, p. 23). mostra um gráfico do desempenho

do protocolo AMF em relação ao HTML, XML, SOAP, JSON (JavaScript Object

Notation), Dojo e Paged, considerando uma amostra de cinco mil linhas de código.

O resultado do gráfico mostra que a velocidade de transferência de dados usando o

protocolo AMF foi maior que a dos outros, proporcionando à aplicação um

desempenho maior.

Ilustração 8: Desempenho do protocolo AMF (cinco mil linhas de código).

51

Fonte: WARD (2007).

Segundo Adobe Systems Incorporated (2006), as vantagens oferecidas pelo

Flex em relação ao desenvolvimento em HTML é o que faz com que o mesmo se

destaque no desenvolvimento de aplicações RIA, podendo-se citar:

Utilização de padrões: o Flex compila seus projetos em Flash, eliminando o

problema de falta de padronização que acontece no desenvolvimento de

aplicações em linguagens nativas dos navegadores, como o JavaScript. O Flash

permite também que a aplicação seja rodada em múltiplas plataformas, como

Linux, Mac, ou Windows;

Problemas de layout: utilizando o MXML para a definição da interface, não

ocorrem os problemas que frequentemente acontecem com o HTML, como a

falta de padronização na interpretação das tags por diferentes navegadores;

52

Suporte a várias mídias: o Flex tem suporte nativo a áudio, imagem e vídeo, sem

a necessidade de componentes adicionais para isso;

Desempenho: os aplicativos são arquivos binários, assim como nas aplicações

desktop, tornando a execução do código mais rápida, quando comparada às

linguagens interpretadas em tempo real, que são utilizadas atualmente.

Fain, Rasputnis e Tartakovsky (2006), acrescentam ainda como vantagens:

O tamanho do plugin necessário é pequeno;

As aplicações podem ser executadas fora dos navegadores, quando feitas para

este fim;

Oferece integração com todos os tipos de mídias de áudio e vídeo;

Oferece programação baseada em componentes, eliminando assim a

programação de baixo nível.

Cabe mencionar que neste trabalho serão apresentados somente o Adobe

Flex Builder 3.0 e o Adobe Flex 2 SDK, pois somente estas ferramentas serão

utilizadas para a elaboração do protótipo. O Adobe Flex Builder 3.0 será

apresentado na próxima seção.

4.2.3 Adobe Flex Builder 3.0

Conforme Fraga (2009) para acelerar o desenvolvimento das aplicações, a

Adobe fornece o Adobe Flex Builder, um IDE construído conforme a plataforma

Eclipse, possuindo os mesmos recursos desta ferramenta. O Adobe Flex Builder 3.0

é uma ferramenta de qualidade para o desenvolvimento em Flex, podendo ser

instalada como plugin no Eclipse, sendo desta forma possível a utilização das

linguagens Java e Flex, simultaneamente, sem que seja necessária a troca de IDEs

para desenvolvimento.

Para Schimitz (2008) o Adobe Flex Builder 3.0 é uma IDE que oferece

poderosos recursos para desenvolvimento de software em Flex, que se divide em

dois módulos:

Standard: contém a IDE completa, com os componentes necessários para o

desenvolvimento de aplicativos;

Profissional: esta ferramenta contém todos os recursos presentes no módulo

Standard e mais a opção de criação de gráficos e novas ferramentas para

gerenciamento de desempenho das aplicações criadas.

53

O funcionamento do Adobe Flex Builder é muito semelhante ao Adobe

Flash6, gerando um arquivo com a extenção “swf” (SCHIMITZ, 2008).

4.2.4 BlazeDs

BlazeDS é um servidor baseado em Java Web, caracterizado por utilizar a

tecnologia de mensagens remotas, que transfere dados em tempo real do Java para

o Adobe Flex. Além disso, o BlazeDS utiliza o protocolo AMF da Adobe, em formato

binário, aumentando sua velocidade para carregar os dados da aplicação, podendo

ser 10 vezes mais rápido que o formato XML (Fraga, 2008).

A utilização de tecnologias de comunicação remota e mensagens sobre

HTTP, pelo AMF, oferece benefícios de desempenho, assim como a simplicidade de

não ter de lidar com uma camada adicional de abstração de dados, conforme

apresentado na Ilustração 9 (WARD; TIWARI, 2008).

Ilustração 9: Redução de camadas de abstração do AMF.

Fonte: WARD; TIWARI (2008).

Os mesmos autores complementam dizendo que os desenvolvedores

podem utilizar o sistema de mensagens do BlazeDS para enviar mensagens

facilmente, a partir do cliente para o servidor ou do servidor para o cliente, podendo

ser ligado a outros sistemas de mensagens como JMS (Java Message Service) ou

ActiveMQ.

Fraga (2008), registra que o BlazeDS é uma tecnologia server-side, através

6 O Adobe Flash (antes Macromedia Flash) é uma ferramenta de animação que existe no mundo inteiro. Atualmente a maioria dos sites utiliza algum recurso em Flash, e mais de 98% dos navegadores possuem o plugin do Flash para poderem executar as animações (SCHIMITZ, 2008).

54

da qual o usuário poderá utilizar tanto o Remoting7 como o Messaging8, para fazer a

troca de informações entre o Java e o Flex/Flash, possibilitando a utilização de

vários canais de conexão.

O BlazeDS permite que os desenvolvedores conectem ao back-end dados distribuídos e enviem dados em tempo real para aplicativos Adobe Flex e Adobe AIR para a obtenção de melhores experiências de RIA. Disponível anteriormente apenas como parte do software Adobe LiveCycle® Data Services ES, as tecnologias incluídas no BlazeDS e a especificação de protocolo Message Format (AMF) estão recebendo a colaboração do código aberto de acordo com a LGPL (Lesser General Public License) (ADOBE SYSTEMS INCORPORATED, 2009c).

O BlazeDS funciona com uma ampla gama de servidores baseados em

aplicativos Java, podendo-se citar Tomcat, WebSphere, WebLogic, ColdFusion e

JBoss, este último utilizado no presente trabalho. Além disso, o BlazeDS pode ser

facilmente utilizado em aplicações Flex para a web (executadas no Flash Player) ou

na área de trabalho (na execução com o Adobe AIR) (WARD; TIWARI, 2008).

Conforme Zaninetti (2008), o BlazeDs permite que os desenvolvedores

adicionem conectividade de dados, de forma produtiva, às suas aplicações RIA. A

combinação do BlazeDs com o Flex ajuda a reduzir o tempo gasto pelos

desenvolvedores na construção de aplicações em RIA com maior complexidade e

inovação.

4.3 BANCO DE DADOS

Segundo Date (2003), banco de dados é um sistema computadorizado cuja

função é basicamente manter, alterar e inserir registros. Além disso, um sistema de

banco de dados permite a busca e manutenção dos dados quando houver uma

solicitação.

Date (2003), ainda afirma que, entre o sistema físico de armazenamento de

dados e os usuários, existe uma camada de software denominada SGBD (Sistema

de Gerenciamento de Banco de Dados), cuja função é gerenciar todas as

requisições dos usuários ao banco de dados e principalmente isolá-los do

detalhamento no nível de hardware. O SGBD é considerado o componente mais

importante, mas não único dentro de um sistema, juntamente com outro componente

chamado TP (Transaction Processing) que é responsável pela transação e

solicitação dos registros armazenados.

7 Remoting é um arquivo XML, utilizado para fazer troca de informações (FRAGA, 2008).8 Messaging se refere à troca de mensagens entre o servidor e a aplicação (ADOBE SYSTEMS INCORPORATED, 2009a).

55

Para Tonsig (2006), inicialmente o armazenamento de dados era feito por

arquivos seqüenciais indexados (ISAM - Indexed Sequential Access Method). Mais

tarde, nos anos 1960, os Bancos de Dados começaram a utilizar modelos

hierárquicos e, somente na década de 1970 surgiram os Bancos de dados

relacionais. Então nos anos 1980 surge a linguagem estruturada de consulta

denominada SQL (Structured Query Language).

A linguagem SQL foi desenvolvida originalmente pela IBM no início da

década de 1970, logo depois, em 1986 foi então publicado o primeiro padrão para o

SQL. A maioria dos sistemas de banco de dados utiliza o padrão SQL-92, embora

nenhum inclua todos os padrões existentes (DATE, 2003).

Em termos gerais, o uso dos Bancos de Dados apresenta uma série de

vantagens, tais como (TONSING, 2006):

Independência de Dados: os sistemas utilizam o banco de dados

separadamente da aplicação;

Integridade, consistência e compartilhamento de dados: os dados permanecem

íntegros e, sem esforço, são verificados para maior segurança sem a

necessidade de uma aplicação;

Redundância de dados minimizada: através de ligações por chaves

estrangeiras, um banco de dados reduz consideravelmente os dados que

poderiam ser facilmente duplicados;

Utilização de padrões: no caso de uma aplicação, todos os códigos poderão ser

padronizados, havendo somente um código para tratar procedimentos.

4.3.1 MySql

O MySQL foi criado a partir do mSQL que utilizava rotinas rápidas e de baixo

nível (ISAM). Após alguns testes, constatou-se que o mSQL não era rápido e nem

flexível. Com isso houve a necessidade de uma nova interface SQL, mas que fosse

facilmente suportada para códigos de terceiros que eram escritos em mSQL. Desta

forma, foi utilizada a mesma interface API do mSQL para a criação do MySQL.

Desde o início da década de 1980, quando o código foi criado no formato de tabelas

ISAM, o MySQL vem se aprimorando e disponibilizando novas versões com

correções e melhorias. Desta forma a cada lançamento os problemas de

portabilidades foram diminuindo, mesmo com os novos recursos adicionados, assim

tornando o MySQL mais estável (SUM MICROSYSTEMS, 2009).

56

Segundo Rangel (2004), o MySQL é o SGBD de código aberto mais usado

no mundo. Dentre suas vantagens estão o fácil manuseio e o fato de ser gratuito. O

MySQL possui versões para vários SO (Sistemas Operacionais) sendo mais comum

utilizá-lo no Windows e principalmente no Linux. Também possui várias APIs para

diversas linguagens de programação, sendo mais comumente usado em sistemas

web. A partir da versão 5.x, o MySQL se tornou um SGBD cliente/servidor completo,

utilizando o suporte a transações, Procedures, Cursores, Views, Triggers, Foreing

Keys e Constraints.

Conforme Suehring (2002), as vantagens de se utilizar o MySQL são:

Aplicações web: essas aplicações geralmente apresentam mais leituras que

gravações, sendo que o MySQL atende as demandas de velocidade da internet

superando outros SGBD;

Aplicações de nível corporativo: o MySQL oferece suporte às corporações

através da MySQL AB que inclui um conjunto de recursos e aplicações de nível

corporativo;

Suporte a código fonte aberto: o MySQL AB disponibiliza o código fonte para

ampliação;

Sobrecarga baixa: em máquinas com hardware de menor poder de

processamento, o MySQL responde de maneira satisfatória;

Tamanho grande de tabelas disponível: as tabelas do MySQL suportam grandes

lotes de dados chegando em até 8 terabytes por tabela;

Estabilidade: o MySQL está em constante desenvolvimento, fazendo com que

em cada versão lançada sejam corrigidos problemas e adicionados novos

recursos.

Para Suehring (2002), não é necessário comprar uma licença de MySQL,

pois seu servidor é coberto sob licença GNU (acrônimo recursivo de GNU is Not

Unix) GPL (General Public License). Entretanto, pode-se fazer uma cópia desse

servidor para desenvolvimento interno, Web comercial, ou outras aplicações.

Também é disponibilizado o código fonte para criar uma nova aplicação

personalizada ou para torná-la proprietária, isso atendendo as normas GNU.

57

5 PROTÓTIPO DE UMA SOLUÇÃO DE SUPORTE ON-LINE

BASEADA EM WEB 2.0 E RIA

O presente capítulo consiste da apresentação do protótipo de uma solução

em sistemas de informação que visa o suporte on-line, utilizando para este fim os

conceitos de Web 2.0 e RIA (apresentados em detalhe no capítulo 3 deste

documento). O processo metodológico adotado para o desenvolvimento do presente

protótipo é baseada nas seguintes fases: (1) estudo preliminar, contendo a

identificação do problema e a descrição geral da solução; (2) análise de requisitos,

fase em que é realizado o levantamento e análise de requisitos funcionais, não

funcionais, casos de uso e regras de negócio, e a partir do qual são gerados o

diagrama de casos de uso e dos componentes; (3) design ou projeto de software,

fase que define a solução propriamente dita, contendo a apresentação do diagrama

de classes e do modelo de dados elaborados para o protótipo; (4) implementação,

que envolve o desenvolvimento propriamente dito, na linguagem de programação

determinada (capítulo 4) e a apresentação da interface do protótipo.

5.1 ESTUDO PRELIMINAR

Conforme apresentado anteriormente no capítulo 2 deste documento,

qualquer cliente necessita ser bem atendido. Para isso, as empresas que irão

prestar serviços aos seus clientes necessitam de uma ferramenta para auxiliá-las no

atendimento aos mesmos.

Porém, somente a utilização de uma ferramenta não é o suficiente para

satisfazer um cliente, pois o processo de atendimento deve ser muito bem elaborado

a fim de facilitar a vida dos usuários que estão sendo atendidos, como também do

funcionário da empresa que forneceu o software e que está prestando o serviço de

suporte. É importante aqui mencionar que, quando se trata de um sistema de

suporte on-line, dois principais atores emergem: cliente e usuário. Existem algumas

diferenças entre um cliente e um usuário, onde o cliente geralmente é a empresa

que constata a prestação de serviços, e que paga pela mesma. Já o usuário é o

indivíduo que utiliza o sistema diariamente, devendo saber como funciona seus

processos e, provavelmente, quem entrará em contato com a empresa prestadora

de serviços em caso de dúvidas.

Com a evolução da tecnologia, a qual culminou com a criação de novas

58

ferramentas para a prestação de serviços ou suporte, na maioria das vezes os

funcionários de empresas prestadoras de serviços não necessitam mais se deslocar

até o cliente para prestar suporte. A ferramenta mais comum para esta finalidade é

um software de suporte on-line, onde os clientes podem efetuar solicitações, sanar

suas dúvidas ou informar problemas com os produtos de software da empresa.

O processo principal de um sistema de suporte on-line, de acordo com os

sistemas conhecidos pelos autores até a data de realização deste trabalho, é

realizado através de solicitações causadas por necessidades dos clientes e que são

reportadas à empresa que forneceu um produto e/ou serviço.

Assim sendo, cliente, representado por um de seus usuários, acessa o

sistema e efetua o cadastro de uma solicitação, que poderá ser uma melhoria aos

produtos, uma exigência legal, um serviço, um erro ou dúvidas sobre os sistemas,

para que seja resolvida ou respondida pela empresa prestadora de serviços,

responsável pelo sistema.

Uma vez cadastrada, a solicitação é recebida por um funcionário da empresa

prestadora de serviços, o qual primeiramente identifica a solicitação com o status

“Em análise” e efetua a análise desta. Nesta etapa, o funcionário verifica sua

procedência, pois, caso a solicitação não seja considerada válida, esta será

tramitada como “Reprovada”, finalizando-a. Caso seja realmente válida, o

funcionário tramita a solicitação como “Aprovada” e informa sua prioridade, de

acordo com a urgência necessária para sua resolução ou resposta, e, dependendo

do caso, a solicitação pode ser encaminhada para o funcionário ou setor

responsável por sua resolução, tramitando-a como “Encaminhada”.

Uma solicitação com prioridade baixa ou muito baixa e que possa aguardar

prazos maiores para ser disponibilizada, pode ser tramitada como “Aguardando

implementação futura”, sendo retomada quando necessário.

Após o processo de análise, se a solicitação necessita ser implementada nos

sistemas que a empresa prestadora de serviços oferece, inicia-se o processo de

desenvolvimento da solicitação, no qual são realizadas várias tramitações para

atribuição da solicitação a diferentes funcionários ou setores da empresa, como, por

exemplo, o setor de suporte atribuir a solicitação para o setor de desenvolvimento,

para esclarecer dúvidas sobre uma determinada rotina ou processo, ou até mesmo o

setor de testes encaminhar a solicitação novamente ao desenvolvimento, após

encontrar algo de errado na implementação dos mesmos.

59

Ao iniciar efetivamente o processo de desenvolvimento, o funcionário tramita

a solicitação como “Em desenvolvimento” e, assim que conclui este processo,

encaminha a solicitação ao usuário ou setor responsável por efetuar os testes,

podendo ser este o próprio funcionário que atendeu a solicitação. Ao iniciar os

testes, o funcionário responsável tramita a solicitação como “Em testes”,

permanecendo a solicitação com este status até a conclusão dos testes. Concluindo

os testes e confirmando que a implementação foi realizada sem erros, a solicitação é

tramitada como “Desenvolvida”, aguardando ser liberada ao cliente solicitante. Caso

contrário, sendo encontrados erros, a solicitação é tramitada como “Encaminhada”

para o desenvolvedor que a implementou, sendo repetido o fluxo até a

implementação ser realizada com êxito.

Após o cliente confirmar a resolução de suas dúvidas ou após liberar uma

solicitação desenvolvida, a mesma é tramitada como “Concluída”, sendo que, após

inserido este trâmite, nenhuma nova movimentação pode ser feita na solicitação.

A qualquer momento em que surjam dúvidas dos funcionários que necessitem

de esclarecimento do cliente, ou ao ser passada uma resposta ao cliente, referente

às suas dúvidas, o funcionário tramita a solicitação como “Aguardando cliente”,

sendo esta a única situação que permite ao cliente inserir uma tramitação na

solicitação. O trâmite inserido pelo cliente terá sempre o status “Solicitação

respondida”.

Os trâmites “Aguardando cliente”, “Encaminhada” e “Concluída” podem ser

inseridos a qualquer momento, por possuírem caráter esporádico.

Solicitações com os status “Concluída” ou “Reprovada” não podem sofrer

novas alterações ou tramitações.

Considerando a experiência dos três autores deste trabalho na realização de

suporte on-line, constatou-se que muitos softwares deste tipo, não satisfazem a

necessidade do cliente, pelo fato de que, usualmente, seus fornecedores ou

criadores não pensarem em facilitar a execução dos processos pelos clientes ou, até

mesmo, por não seguirem padrões para o desenvolvimento das telas. Da mesma

forma, as interfaces não são atraentes para a utilização dos usuários, sendo pobres

em recursos visuais e ergonomicamente mal projetados.

É comum nos sistemas de suporte atualmente disponíveis, ocorrerem

problemas por motivos de falhas em seu desenvolvimento e principalmente em seu

projeto. Pode-se citar, como exemplos, layout não amigável e de difícil utilização

60

para o usuário, não incentivando o uso do sistema, falta de integração entre os

diversos setores da empresa, para a resolução da solicitação, normalmente

apresentando um sistema externo (entre empresa e suporte) e interno (entre

setores). Conforme já apresentado nos capítulos anteriores, os sistemas de

atendimento oferecidos por uma empresa influenciam diretamente na relação com

seus clientes, sendo de vital importância sua qualidade tanto no projeto quando no

desenvolvimento.

Com tudo isso, percebeu-se que é viável desenvolver um protótipo para

satisfazer as necessidades citadas. Para isso, serão utilizados os conceitos de Web

2.0 e RIA (citadas no capítulo 3), por se tratarem de tecnologias recentes e por

possuírem características capazes de produzir uma solução que se adapte às

necessidades do cliente e da empresa, como interatividade, interface amigável e de

fácil entendimento e rapidez nos processos.

As principais características do protótipo serão a facilidade do usuário em

cadastrar suas solicitações, podendo acompanhar o andamento das mesmas, e

controlar suas tramitações. A interface será muito parecida com uma aplicação

desktop, porém sendo uma aplicação web. Esta observação é importante, pois nas

aplicações desktop o usuário tem a sua disposição uma interface mais intuitiva sem

links, e ainda com seus processos mais explícitos, facilitando a navegação e

tornando a aplicação mais limpa. O uso de recursos Web 2.0 e RIA permite ainda a

aplicação de alguns efeitos (tais como movimentação de telas e opções)

proporcionando um diferencial dentre as aplicações de suporte on-line.

Finalmente, no tocante às tecnologias utilizadas, estas se relacionam da

seguinte forma: (1) o Java se comunica com o banco de dados MySQL, onde faz as

gravações e leituras dos dados; (2) a ferramenta BlazeDs proporciona a

comunicação entre as tecnologias Java e Flex, uma vez que sem esta ferramenta as

mesmas não conseguiriam se comunicar para fazer a troca de informações; (3) a

aplicação é enviada para o servidor JBoss 4.2; (4) o JBoss 4.2 exibe a aplicação no

browser para a visualização do usuário.

Conforme Guedes (2004), o diagrama de componentes está diretamente

ligado à linguagem de programação que será utilizada em um projeto. Este diagrama

representa os componentes que irão fazer parte do sistema e determina como estes

estarão estruturados e interagirão para que o sistema funcione de maneira

adequada. A Ilustração 10 demonstra como será estruturado o protótipo proposto

61

em relação aos componentes tecnológicos mencionados.

Ilustração 10: Diagrama de Componentes.

Fonte: Dos autores.

5.2 ANÁLISE DE REQUISITOS

5.2.1 Levantamento de requisitos

O desenvolvimento de software é uma atividade complexa. Essa complexidade corresponde à sobreposição das complexidades relativas ao desenvolvimento dos seus diversos componentes: software, hardware, procedimentos etc (BEZERRA, 2007, p. 21).

62

Wazlawick (2004) afirma que, devido a esta complexidade, em um primeiro

momento, não é possível identificar todos os detalhes e características do sistema.

No início do processo de análise dos requisitos não são analisados detalhes, mas

sim é visto o sistema como um todo. Esta fase deve ser rápida e genérica, sendo

feita em extensão e não em profundidade. O analista deve ter conhecimento da

abrangência do que o sistema deve fazer, porém não detalhando como o mesmo irá

fazer.

O autor ainda menciona que a fase do levantamento de requisitos, faz com

que o analista produza alguns documentos como:

A visão geral do sistema, onde são descritas as principais idéias do cliente sobre

o sistema;

Os requisitos funcionais e não funcionais, os quais relatam todos os processos

que o sistema deve fazer e sob quais condições irá fazer.

Segundo Wazlawick (2004) e Bezerra (2007), os requisitos podem ser

classificados em duas categorias:

Os requisitos funcionais correspondem às funcionalidades que o sistema deve

conter;

Os requisitos não-funcionais são características de qualidade e restrições

inseridas no sistema, que estejam relacionadas com as suas funcionalidades.

Em complemento, de acordo com Blaschek (2002) requisito funcional

representa uma funcionalidade de um produto, ou como irá funcionar o mesmo. Já

os requisitos não funcionais são as qualidades ou as propriedades de um produto.

Os requisitos funcionais (RF) e não funcionais (RNF) do protótipo são apresentados

no Quadro 5 e Quadro 6.

Quadro 5: Requisitos funcionais do protótipo.

RF1 Cadastro da Empresa Prestadora de Serviços

Descrição: o sistema deverá conter um cadastro da empresa prestadora de serviços, onde o usuário Master irá cadastrar os dados da mesma.

RF2 Cadastro de Clientes

Descrição: o sistema deverá conter um cadastro de clientes, onde o usuário Master irá cadastrar as empresas, suas clientes.

RF3 Cadastro de Usuários

Descrição: o sistema deverá conter um cadastro de usuários, onde o usuário Master e o administrador do cliente irão cadastrar os usuários do sistema. Obs.: o usuário Master cadastra também os administradores dos clientes.

RF4 Cadastro de Setores

63

RF1 Cadastro da Empresa Prestadora de Serviços

Descrição: o sistema deverá conter um cadastro de setores, onde o usuário Master irá cadastrar os setores existentes na empresa.

RF5 Cadastro de Sistemas

Descrição: o sistema deverá conter um cadastro de sistemas, onde o usuário Master irá cadastrar os sistemas que a empresa desenvolve.

RF6 Cadastro de Solicitações

Descrição: o sistema deverá conter um cadastro de solicitações, onde os usuários clientes irão cadastrar as solicitações para a empresa prestadora de serviços.

RF7 Inclusão de Trâmites nas Solicitações

Descrição: o sistema deverá conter uma opção de inclusão de trâmites nas solicitações, onde os usuários podem inserir mais informações sobre sua solicitação ou verificar o andamento da mesma. Um trâmite pode ser respondido ao próprio cliente ou encaminhado a outros setores.

RF8 Consultar Solicitações

Descrição: o sistema deverá conter uma consulta das solicitações cadastradas, onde os usuários irão visualizar as mesmas, podendo tramitá-las.

RF9 Atualização de Solicitação

Descrição: o sistema irá atualizar a solicitação após o usuário efetuar algum trâmite na mesma.

Fonte: Dos autores.

Quadro 6: Requisitos não-funcionais do protótipo.

Nome Descrição Categoria

RNF1 Controle de permissões

As permissões serão atribuídas aos usuários conforme seu tipo, o qual será informado no cadastro de usuários.

Segurança

RNF2 Portabilidade de plataformas

O sistema deverá ser compatível com os browsers (Internet Explorer [IE], FireFox, Chrome), e as plataformas Linux, Solaris, Windows e Mac.

Portabilidade

RNF3 Layout amigável O sistema deve ser amigável ao usuário, sendo de fácil entendimento e navegação. (menus e ícones amigáveis).

Usabilidade

Fonte: Dos autores.

5.2.2 Organização dos requisitos

5.2.2.1 Atores

Conforme Bezerra (2007) qualquer elemento externo ao sistema que

interage com o mesmo é denominado ator. O termo externo significa, nesta

64

definição, que os atores não fazem parte do sistema. Os atores trocam informações

com o sistema, que as envia para o processamento ou recebe as informações

processadas pelo sistema.

Os atores do protótipo proposto são:

Usuário empresa: são os funcionários da empresa prestadora de serviço, onde

os mesmos irão tramitar as solicitações cadastradas.

Usuário clientes: são os usuários (funcionários dos clientes) que irão cadastrar

as solicitações e receber o suporte das mesmas.

5.2.2.2 Casos de uso

Por definição, um caso de uso (do inglês use case) é a especificação de uma sequência, completa de interações entre o sistema e um ou mais agentes externos a esse sistema. Um caso de uso representa um relato de uso de certa funcionalidade do sistema em questão, sem revelar a estrutura e o comportamento internos desse sistema. Essa última característica é importante, porque sua existência implica que o modelo de caso de uso é um modelo com uma perspectiva externa do sistema (BEZERRA, 2007, p. 55).

Conforme Macoratti (2004), quando se tem um novo sistema, pode-se

utilizar uma técnica chamada caso de uso, onde se modela a descrição desse

sistema. Estes casos de uso têm por objetivo:

Determinar e descrever os requisitos funcionais do sistema;

Fornecer uma descrição do que o sistema deve fazer.

Dentre os requisitos funcionais levantados, alguns foram identificados como

compondo os casos de uso do protótipo, sendo eles: RF6 (Cadastro de

Solicitações), RF7 (Inclusão de Trâmites das Solicitações) e RF9 (Atualização de

Solicitação).

O Quadro 7 apresenta a expansão do caso de uso RF6 – Cadastro de

Solicitações.

Quadro 7: Caso de uso RF6.

Caso de uso RF6 Cadastro de SolicitaçõesAtores UsuáriosInteressados Administradores, UsuáriosRequisitos correlacionados

RF3, RF4, RF7

Fluxo principal 1. O usuário cliente acessa o sistema.2. O usuário cliente clica na opção Cadastro de

Solicitações.3. O usuário cliente informa o tipo de solicitação,

65

podendo ser uma notificação de erro, melhoria no sistema, exigência legal, solicitação de serviços ou dúvidas.

4. O usuário informa sobre qual produto se refere sua solicitação.

5. O usuário informa a descrição da sua solicitação.6. O usuário do cliente clica no botão gravar para

gravar a solicitação.Fonte: Dos autores

O Quadro 8 apresenta a expansão do caso de uso RF7 – Inclusão de

Trâmites das Solicitações.


Caso de uso RF7 Inclusão de Tramites das SolicitaçõesAtores UsuáriosInteressados Administradores, UsuáriosRequisitos correlacionados

RF3, RF4, RF6

Fluxo principal 7. O usuário acessa o sistema8. O usuário clica na opção Inclusão de Trâmites

das Solicitações9. O usuário responde a solicitação que está em

aberto10.O usuário clica no botão gravar para efetuar a

tramitação.Fonte: Dos autores.

O Quadro 9 apresenta a expansão do caso de uso RF9 – Atualização de

Solicitação.


Caso de uso RF9 Atualização de SolicitaçãoAtores Não se aplicaInteressados Administradores, UsuáriosRequisitos correlacionados

RF6, RF7

Fluxo principal 1. O usuário faz algum tramite em uma solicitação

2. O sistema atualiza a solicitação.Fonte: Dos autores.

A Ilustração 11 apresenta o diagrama UML de casos de uso:

66

Ilustração 11: Diagrama de Casos de Uso.

Fonte: Dos autores.

O diagrama de casos de uso elaborado demonstra as interações dos autores

com os casos de uso e entre os casos de uso. Neste diagrama, o ator Usuário

Cliente pode cadastrar solicitações e, em alguns casos, também tramitá-las. O ator

Usuário Empresa pode somente tramitar as solicitações que foram cadastradas pelo

ator Usuário Cliente. Sempre que um dos atores incluir um trâmite em uma

solicitação, será executado um processo que automaticamente atualizará o status da

solicitação, justificando o uso da associação do tipo include.

5.2.2.3 Conceitos

Dentre os requisitos funcionais levantados, os conceitos são aqueles que

sofrerão operações de manutenção ou cadastro, isto é, inclusão, alteração e

exclusão de dados. Essas operações são relativamente simples e elementares, não

sendo consideradas, por esta razão como casos de uso, pois não é necessário

estudar seu processo iterativo, que representa uma única etapa (WAZLAWICK,

2004). Os conceitos do protótipo são:

67

RF1 Cadastro da Empresa Prestadora de Serviços;

RF2 Cadastro de Clientes;

RF3 Cadastro de Usuários;

RF4 Cadastro de Setores;

RF5 Cadastro de Sistemas.

5.2.2.4 Consultas e relatórios

Conforme Wazlawick (2004), consultas e relatórios são as informações que

serão exibidas ao usuário num padrão pré-definido, não consistindo em casos de

uso, pois o resultado será sempre o mesmo, variando apenas os parâmetros e

informações exibidas. A consulta que será oferecida pelo protótipo é:

RF8 Consultar Solicitações.

5.2.2.5 Regras de negócio

Para Bezerra (2007), regras de negócio são políticas, restrições ou

condições que devem ser avaliadas ao executar os processos de uma organização,

pois elas apresentam a maneira como a organização funciona. Cada organização

pode ter um número variado de regras de negócio, as quais são identificadas no

levantamento de requisitos.

Segundo Salgado (2001), regras de negócio são sentenças que restringem

algum aspecto do negócio. Essas regras definem como os processos devem ser

executados.

O Quadro 10 contém a regra de negócio RN7.1 implementada para a

execução do caso de uso RF7.

Quadro 10: Regra de Negócio RN7.1.

Nome RN7.1 Exceção na inclusão de trâmites na solicitaçãoDescrição Os usuários do tipo “Administrador Cliente” e “Usuário”, somente

poderão incluir trâmites quando a solicitação estiver com o status “Aguardando Cliente”.

Fonte Os autoresHistórico 27 de agosto de 2009

Fonte: Dos autores.




68

Nome RN7.2 Status da solicitaçãoDescrição Após ter sido inserido um trâmite com o status “Concluída” ou

“Reprovada”, não podem ser inseridos novos trâmites na solicitação.Fonte Os autoresHistórico 27 de agosto de 2009

Fonte: Dos autores.




Nome RN6.1 Exceção no cadastro de solicitaçõesDescrição Quando o usuário cadastrar uma solicitação, o sistema

automaticamente fará um relacionamento entre a solicitação e o cliente do usuário.

Fonte Os autoresHistórico 27 de agosto de 2009

Fonte: Dos autores.

O Quadro 13 contém a regra de negócio RN6.2 implementada como regra

para a execução do caso de uso RF6.


Nome RN6.2 Status “Não Analisada”Descrição Após o cadastro das solicitações, o status inicial sempre será “Não

Analisada”. Fonte Os autoresHistórico 27 de agosto de 2009

Fonte: Dos autores.

5.3 DESIGN DA SOLUÇÃO

A fase de design (ou projeto) é caracterizada por apresentar as interações

entre os processos do sistema, a composição do seu banco de dados e como é

demonstrada a parte visual do protótipo.

5.3.1 Modelo Conceitual

O Modelo Conceitual deve descrever a informação que o sistema vai gerenciar. Trata-se de um artefato do domínio do problema e não do domínio da solução. O modelo conceitual procura mostrar quais são os elementos de informação tratados pelo sistema, para que mais adiante se possa mostrar ainda como essa informação é transformada pelo sistema a partir das diferentes requisições do usuário (operações de sistema) (WAZLAWICK, 2004, p. 102).

A Ilustração 12 apresenta o diagrama de classes do protótipo:

69

Ilustração 12: Diagrama de Classes.

Fonte: Dos autores.

70

5.3.2 Projeto de Banco de Dados

Conforme Silberschatz, Korth e Sudarshan (2006), o modelo ER (Entidade

Relacionamento) representa uma estrutura lógica de um banco de dados, tendo

como objetivo facilitar seu projeto, pois é útil na especificação dos processos de uma

empresa real para uma modelagem de um esquema conceitual.

Ao se utilizar a Modelagem Conceitual de Dados com a técnica de Entidades e Relacionamentos, obteremos resultados e esquemas puramente conceituais sobre a essência de um sistema, ou melhor, sobre o negócio para o qual estamos desenvolvendo um projeto, não representando-se procedimentos ou fluxo de dados existentes (MACHADO; ABREU, 1996, p. 29).

O Modelo ER utilizado como base no desenvolvimento do protótipo

apresentado está demonstrado na Ilustração 13.

71

Ilustração 13: Modelo ER.

Fonte: Dos autores.

72

5.4 APRESENTAÇÃO DO PROTÓTIPO

Nesta seção serão apresentadas as interfaces que compõem o protótipo de

suporte on-line baseado em Web 2.0 e RIA, bem como a descrição detalhada de seu

funcionamento. Pretende-se com isso salientar os benefícios oferecidos não

somente pela solução implementada, mas pela adoção dos conceitos abordados

neste trabalho.

Em relação às interfaces apresentadas nesta seção, cabe frisar que o

protótipo foi desenvolvido baseado em permissões por tipo de usuário, tipo este

informado no próprio cadastro do usuário. A tela inicial para cada um destes tipos é

diferente, apresentando somente as opções que aquele usuário tem permissão.

As ilustrações apresentadas na sequência representam todas as telas do

protótipo. Já as seções 5.4.1, 5.4.2, 5.4.3 e 5.4.4, apresentarão as definições dos

tipos de usuários e as particularidades do sistema, em relação ao acesso de cada

um desses.

A Ilustração 14 representa a tela de login do sistema, onde o usuário irá

informar seu nome de usuário e senha cadastrados para o acesso. Na sequência o

usuário irá clicar no botão Entrar, para acessar o sistema, ou clicar no botão

Cancelar, para limpar os dados informados. Se o indivíduo não estiver cadastrado

no sistema como usuário, deverá contatar o administrador do cliente, para efetuar o

cadastro.

Ilustração 14: Login do Sistema.

Fonte: Dos autores.

A Ilustração 15 representa a tela inicial do protótipo, com todas as opções

disponíveis. Na parte superior da tela é exibida uma barra com as seguintes

informações: o nome do software (Sistema de Suporte On-line), juntamente com o

73

nome da empresa cadastrada (o cliente que adquiriu o software), o usuário

conectado, a data atual, a hora atual e um botão para desconectar do sistema. Na

área central da tela inicial são apresentadas as opções disponíveis no sistema,

sendo estas:

Cadastro da Empresa Prestadora;

Cadastro de Cidades;

Cadastro de Setores;

Cadastro de Sistemas;

Cadastro de Clientes;

Cadastro de Usuários;

Cadastro de Solicitações;

Consulta das Solicitações;

Contato.

Ilustração 15: Tela principal.

Fonte: Dos autores.

A Ilustração 16 representa o cadastro da empresa prestadora, onde o

usuário irá cadastrar a empresa que irá prestar os serviços. O usuário deverá

informar a razão social da empresa (campo obrigatório)9, telefone (campo

obrigatório), e-mail (campo obrigatório) e endereço, clicando no botão Salvar, para

9 Os campos obrigatórios, quando não preenchidos ou não validados, ficam com as bordas em vermelho. Por decorrência de uma limitação no componente de validação, em alguns casos os campos já ficam com as bordas em vermelho ao abrir a tela, em outros casos somente após o campo ser validado ou ainda quando o registro é gravado ou inserido um novo registro (OS AUTORES).

74

guardar as informações. Após o usuário clicar em Salvar, o sistema

automaticamente irá atualizar o nome da empresa na barra superior da tela inicial.

Ilustração 16: Cadastro da Empresa Prestadora.

Fonte: Dos autores.

A Ilustração 17 representa o cadastro de cidades. Quando a tela é aberta,

automaticamente será criado um novo registro, em branco, sem a necessidade de o

usuário clicar no botão “Novo” para isto. O usuário deverá informar o nome da

cidade (campo obrigatório) e a UF (Unidade Federativa) (campo obrigatório),

clicando no botão “Salvar” para guardar as informações. Após esse processo, a

cidade cadastrada será visualizada em uma lista contida na parte inferior da tela,

juntamente com as demais cidades cadastradas; o sistema automaticamente criará

um novo registro em branco. O usuário poderá selecionar algum registro da lista,

clicando sobre o mesmo. Desta forma o sistema irá preencher os campos do

cadastro com as informações daquele registro. Com isso, o usuário poderá alterar as

informações daquela cidade. O usuário poderá clicar no botão “Novo”, para inserir

um novo registro, ou clicar no botão “Excluir”, para excluir o registro selecionado.

Ilustração 17: Cadastro de Cidades.

75

Fonte: Dos autores.

A Ilustração 18 representa o cadastro de setores, onde o usuário irá

cadastrar os setores da empresa prestadora de serviço. Quando a tela é aberta,

automaticamente será criado um novo registro, em branco, sem a necessidade de o

usuário clicar no botão “Novo” para isto. O usuário deverá informar o nome do setor

(campo obrigatório), clicando no botão “Salvar” para guardar as informações. Após

esse processo, o setor cadastrado será visualizado em uma lista contida na parte

inferior da tela, juntamente com os demais setores cadastrados, e o sistema

automaticamente criará um novo registro em branco. O usuário poderá selecionar

algum registro da lista, clicando sobre o mesmo. Desta forma, o sistema irá

preencher os campos do cadastro com as informações daquele registro. Com isso, o

usuário poderá alterar as informações daquele setor. O usuário poderá clicar no

botão “Novo”, para inserir um novo registro, ou clicar no botão “Excluir”, para excluir

o registro selecionado.

Ilustração 18: Cadastro de Setores.

76

Fonte: Dos autores.

A Ilustração 19 representa o cadastro de sistemas, onde o usuário irá

cadastrar os sistemas oferecidos pela empresa prestadora de serviços. Quando a

tela é aberta, automaticamente será criado um novo registro, em branco, sem a

necessidade de o usuário clicar no botão “Novo” para isto. O usuário deverá informar

o nome do sistema (campo obrigatório), clicando no botão “Salvar” para guardar as

informações. Após esse processo, o setor cadastrado será visualizado em uma lista

contida na parte inferior da tela, juntamente com os demais sistemas cadastrados;

um novo registro em branco será criado automaticamente. O usuário poderá

selecionar algum registro da lista, clicando sobre o mesmo. Desta forma, o sistema

irá preencher os campos do cadastro com as informações daquele registro. Com

isso, o usuário poderá alterar as informações daquele sistema. O usuário poderá

clicar no botão “Novo”, para inserir um novo registro, ou clicar no botão “Excluir”,

para excluir o registro selecionado.

Ilustração 19: Cadastro de Sistemas.

77

Fonte: Dos autores.

A Ilustração 20 representa o cadastro de clientes, onde o usuário irá

cadastrar os clientes da empresa. Quando a tela é aberta, automaticamente será

criado um novo registro, em branco, sem a necessidade de o usuário clicar no botão

“Novo” para isto. O usuário deverá informar a razão social do cliente (campo

obrigatório), o CNPJ (Cadastro Nacional de Pessoa Jurídica) (campo obrigatório), o

telefone (campo obrigatório), o fax, o endereço (campo obrigatório), o bairro (campo

obrigatório), o CEP (Código de Endereçamento Postal) (campo obrigatório), o

complemento, o email (campo obrigatório), a cidade (campo obrigatório). Para tanto,

ao lado do campo cidade existe um botão que permite acesso ao formulário de

consultada às cidades cadastradas, além de dois campos que representam o nome

da cidade e seu estado. Para guardar essas informações, o usuário deve clicar no

botão “Salvar”. Após esse processo, o cliente cadastrado será visualizado em uma

lista situada na parte inferior da tela, juntamente com os demais clientes

cadastrados; o sistema automaticamente criará um novo registro em branco. O

usuário poderá selecionar algum registro da lista, clicando sobre o mesmo. Desta

forma o sistema irá preencher os campos do cadastro com as informações daquele

registro. Com isso, o usuário poderá alterar as informações daquele cliente. O

usuário poderá clicar no botão “Novo”, para inserir um novo registro, ou clicar no

78

botão “Excluir”, para excluir o registro selecionado.

Ilustração 20: Cadastro de Clientes.

Fonte: Dos autores.

A Ilustração 21 representa a consulta de cidades, a qual permite ao usuário

consultar as cidades cadastradas. Nesta consulta o usuário seleciona a opção de

busca (por código ou nome), sendo por código ou nome, e informa o dado que

deseja buscar no campo ao lado, clicando no botão “Buscar” para listar as cidades

contidas na seleção. Caso não sejam informados dados e o botão “Buscar” seja

pressionado, serão listadas todas as cidades. Para selecionar uma cidade, deve-se

clicar sobre o registro desejado na lista de cidades consultadas. Com isto, o código,

o nome e a unidade federativa serão automaticamente transferidos para o cadastro

de clientes, o qual acessou esta consulta.

79

Ilustração 21: Consulta de Cidades.

Fonte: Dos autores.

A Ilustração 22 representa o cadastro de usuários, onde os que estão

conectados irão cadastrar aqueles que poderão acessar o sistema. Quando a tela é

aberta, automaticamente será criado um novo registro, em branco, sem a

necessidade de o usuário clicar no botão “Novo” para isto. Os usuários deverão

informar o nome do indivíduo (campo obrigatório), o nome de usuário (campo

obrigatório), a senha (campo obrigatório), o tipo (Master, Administrador Cliente,

Funcionário, Usuário) (campo obrigatório), o cliente e o setor. Para que se possa

informar o cliente ao qual pertence o usuário que está sendo cadastrado deve-se

clicar no botão de consulta apresentado ao lado do campo “Cliente”. O clique neste

botão permite acesso ao formulário onde podem ser consultados os clientes

cadastrados. Para que se possa informar o setor, deve-se seguir o mesmo

procedimento, clicando agora no botão que se encontra ao lado do campo “Setor”,

possibilitando assim consulta aos setores cadastrados. Finalmente, deve-se clicar no

botão “Salvar” para guardar as informações. Após esse processo, o usuário

cadastrado será visualizado em uma lista contida na parte inferior da tela,

juntamente com os demais usuários cadastrados, e o sistema automaticamente

criará um novo registro em branco. O usuário poderá selecionar algum registro da

lista, clicando sobre o mesmo. Desta forma o sistema irá preencher os campos do

80

cadastro com as informações daquele registro. Com isso, o usuário poderá alterar as

informações daquele usuário. O usuário poderá clicar no botão “Novo”, para inserir

um novo registro, ou clicar no botão “Excluir”, para excluir o registro selecionado.

Ilustração 22: Cadastro de Usuários.

Fonte: Dos autores.

A Ilustração 23 representa a consulta de clientes cadastrados. Para ter

acesso aos resultados desta consulta o usuário deve selecionar a opção de busca

(por código ou razão), e informar o dado que deseja buscar no campo ao lado,

clicando no botão “Buscar” para listar os clientes contidos na seleção. Caso não

sejam informados dados e o botão “Buscar” seja pressionado, serão listados todos

os clientes. Para selecionar um cliente, deve-se clicar sobre o registro desejado na

lista de clientes consultados. Com isto, o código e a razão social serão

automaticamente transferidos para o cadastro de usuários, o qual acessou esta

consulta.

81

Ilustração 23: Consulta de Clientes.

Fonte: Dos autores.

A Ilustração 24 representa a consulta de setores cadastrados. O usuário irá

selecionar se deseja consultar o setor por código ou nome, informando tal dado no

campo ao lado, clicando então no botão “Buscar”. É possível também pressionar o

botão de busca sem a necessidade de preencher o campo de informação, assim o

sistema apresentará todos os setores cadastrados na lista situada na parte inferior

do formulário. Os registros da lista podem ser selecionados efetuando-se um clique

sobre o mesmo quando desejado.

82

Ilustração 24: Consulta de Setores.

Fonte: Dos autores.

A Ilustração 25 representa o cadastro de solicitações, onde o usuário irá

cadastrar as solicitações que deseja fazer à empresa prestadora de serviços.

Quando a tela é aberta, automaticamente será criado um novo registro, em branco.

O usuário deverá informar o tipo de solicitação (Notificação de Erro, Melhoria,

Solicitação de Serviço, Exigência Legal e Dúvidas) (campo obrigatório), a prioridade

de sua solicitação (Muito Alta, Alta, Média, Baixa e Muito Baixa) (campo obrigatório),

o sistema para qual está cadastrando a solicitação, (que deverá ser previamente

cadastrado para ser listado) (campo obrigatório), o assunto da solicitação (campo

obrigatório) e a descrição da solicitação (campo obrigatório), clicando no botão

“Salvar” para guardar as informações. Após esse processo, o sistema

automaticamente criará um novo registro, em branco. O cadastro que está sendo

efetuado pode ser cancelado, clicando-se no botão “Cancelar”, o qual limpará os

dados de todos os campos da tela. O usuário poderá consultar as solicitações

cadastradas através do botão “Consultar Solicitações”, o qual mostrará uma tela

específica para consulta.

83

Ilustração 25: Cadastro de Solicitações.

Fonte: Dos autores.

A Ilustração 26 representa a consulta de solicitações cadastradas, onde os

usuários poderão efetuar filtros e buscar as solicitações que foram cadastradas.

Cabe salientar que os usuários Master têm acesso a qualquer solicitação

cadastrada, independente de qual cliente ou usuário a cadastrou. Para efetuar a

consulta das solicitações, o usuário necessita preencher os seguintes campos: o tipo

da solicitação, a prioridade, o sistema, o usuário, o cliente e a data de cadastro.

Clicando no botão “Buscar”, o sistema apresentará as solicitações cadastradas

respeitando o filtro informado pelo usuário. O usuário poderá clicar na solicitação

para qual deseja visualizar as respostas, tendo então acesso à tela de Respostas da

Solicitação.

84

Ilustração 26: Consulta de Solicitações.

Fonte: Dos autores.

A Ilustração 27 representa os dados da solicitação cadastrada, juntamente

com suas respostas. Os usuários do tipo Master e Funcionário poderão alterar a

prioridade e o tipo da solicitação, devendo clicar no botão “Salvar” para efetuar a

atualização desta. O botão “Tramitar” abrirá a tela de “Trâmites”, onde usuário

poderá incluir novas respostas à solicitação. No quadro inferior desta tela é

apresentada uma lista com todos os trâmites já cadastrados para aquela solicitação.

Ao clicar em um destes trâmites, será apresentada uma tela com os detalhes

daquele trâmite.

85

Ilustração 27: Respostas da Solicitação.

Fonte: Dos autores.

A Ilustração 28 representa a tela de Trâmites, a qual permite ao usuário

responder a solicitação. No canto superior direito da tela é demonstrado o status

atual da solicitação e, logo abaixo deste, é demonstrada a lista dos novos status

possíveis de serem informados para a solicitação, sendo que a lista apresenta

opções diferenciadas, de acordo com o status atual. Após informar o novo status,

existe um campo para se informar a descrição para aquela resposta. Existe também

a opção “Mostrar tramitação ao cliente”, a qual, se marcada, não permitirá que

usuários do cliente visualizem o texto da resposta. Esta opção, portanto, tem o

intuito de tornar interna uma resposta que não deva ser de conhecimento do cliente.

Caso seja selecionado o status de “Encaminhada”, aparecerão dois novos campos

para se informar o funcionário e/ou setor ao qual será encaminhada a solicitação. O

usuário poderá clicar no botão “Confirmar”, para inserir o novo trâmite à solicitação

ou clicar no botão “Cancelar”, para limpar os dados.

86

Ilustração 28: Trâmites.

Fonte: Dos autores.

A Ilustração 29 representa a tela de Trâmites, que será apresentada quando

o status atual estiver como “Aguardando “Cliente”. Ao confirmar este trâmite, a nova

resposta será inserida com o status de “Solicitação Respondida”.

87

Ilustração 29: Trâmites.

Fonte: Dos autores.

A Ilustração 30 representa os detalhes do trâmite selecionado, onde o

usuário irá visualizar as informações complementares pertinentes ao mesmo.

Ilustração 30: Detalhes do Trâmite.

Fonte: Dos autores.

A Ilustração 31 representa o contato da empresa prestadora de serviço,

onde serão mostrados alguns dados básicos para o cliente poder se comunicar com

a empresa que está prestando o serviço a ele.

88

Ilustração 31: Contato.

Fonte: Dos autores.

5.4.1 Tipo de Usuário: Master

O usuário Master representa o controlador geral do protótipo,

correspondendo ao responsável pela empresa prestadora de serviços. Esse usuário

ficará encarregado de fazer os primeiros cadastros do protótipo, como cadastro da

empresa prestadora, usuários, sistemas, setores e cidades.

Os usuários do tipo Master têm permissão de acesso total ao protótipo,

sendo possível que acessem quaisquer cadastros ou consultas e efetuem quaisquer

operações. A tela inicial para este tipo de usuário contém todas as opções existentes

no sistema, sendo idêntica àquela apresentada na Ilustração 15, demonstrada na

seção anterior. As demais telas do protótipo também não oferecem particularidades

para este tipo de usuário, não havendo necessidade de demonstrá-las novamente,

por não sofrerem alterações.

5.4.2 Tipo de Usuário: Administrador Cliente

O usuário do tipo Administrador Cliente representa a pessoa responsável

pela manutenção do protótipo no cliente da empresa prestadora de serviços. Este

tipo de usuário possuirá permissão de acesso somente às opções onde realmente

será necessária a manutenção de informações do cliente. As próximas ilustrações

descrevem as opções onde este usuário terá permissão de acesso.

A Ilustração 32 representa a tela inicial do protótipo para o tipo de usuário

Administrador Cliente. Esta tela conterá as mesmas informações na parte superior

89

(já apresentadas na Ilustração 15), porém somente conterá as seguintes opções

disponíveis:



Consulta de Solicitações;

Contato.

Ilustração 32: Tela Principal (Administrador Cliente).

Fonte: Dos autores.

A Ilustração 33 representa o cadastro de usuário na visão do usuário

Administrador Cliente, que conterá os mesmo campos e funcionalidades

apresentados na Ilustração 22, porém com as seguintes restrições:

A lista dos usuários cadastrados apresentará somente aqueles que foram

cadastrados para o cliente do usuário conectado;

O campo “Cliente” encontra-se desabilitado, informando o cliente do usuário

conectado;

O campo “Setor” encontra-se desabilitado, pois o setor não serve para os

usuários do cliente e sim para os funcionários da empresa prestadora de

serviço.

90

Ilustração 33: Cadastro de Usuários (Administrador Cliente).

Fonte: Dos autores.

O cadastro de Solicitações, Trâmites, Detalhes do Trâmite e o Contato são

iguais às interfaces do usuário Master, não havendo portanto, a necessidade de

descrever e ilustrar essas opções.

A Ilustração 34 representa a consulta de solicitações, cuja aparência é

mesma disponibilizada para o usuário Master, porém com as seguintes limitações:

este usuário poderá consultar somente as solicitações cadastradas por sua

empresa; e o campo Cliente apresentará as informações do cliente que o usuário

representa, sendo mantido desabilitado.

91

Ilustração 34: Consulta de Solicitações (Administrador Cliente).

Fonte: Dos autores.

A Ilustração 35 representa a tela de Respostas da Solicitação, na visão do

usuário do tipo Administrador Cliente. Os únicos diferenciais desta tela para a dos

usuários do tipo Master e Funcionário é que o usuário Administrador Cliente não

poderá alterar o tipo da solicitação, a sua prioridade, e poderá tramitar somente

quando o status estiver “Aguardando Cliente”.

92

Ilustração 35: Respostas da Solicitação (Administrador Cliente).

Fonte: Dos autores.

5.4.3 Tipo de Usuário: Funcionário

O usuário do tipo Funcionário representa o funcionário da empresa

prestadora de serviços que irá prestar os serviços aos clientes. Este usuário poderá

dar manutenção às opções que interessam diretamente à empresa prestadora de

serviços, conforme descrição das opções de acesso deste usuário conforme segue.

A Ilustração 36 representa a tela inicial do protótipo para o tipo de usuário

Funcionário, que conterá as mesmas informações na parte superior presentes na

Ilustração 15, porém, somente conterá as seguintes opções disponíveis:

Cadastro de Clientes;




Contato

93

Ilustração 36: Tela Principal (Funcionário).

Fonte: Dos autores.

Todas as opções disponíveis para este tipo de usuário serão iguais em

relação às interfaces do usuário Master, não havendo portanto, a necessidade de

descrever e ilustrar essas opções novamente.

5.4.4 Tipo de Usuário: Usuário

O usuário do tipo Usuário representa o usuário final do protótipo. É este tipo

de usuário quem irá cadastrar as solicitações para tirar dúvidas, pedir melhorias ou

encaminhar erros nos produtos da empresa prestadora de serviço. Esse usuário terá

acesso somente à parte de solicitações, foco principal do protótipo.

A Ilustração 37 representa a tela inicial do protótipo para o tipo de Usuário,

que conterá as mesmas informações na parte superior (conforme Ilustração 15),

porém somente conterá as seguintes opções disponíveis:



Contato.

94

Ilustração 37: Tela Principal (Usuário).

Fonte: Dos autores.

O cadastro de Solicitações e o Contato serão iguais em relação à interface

disponível para o usuário Master, não havendo portando a necessidade de

descrever e ilustrar essas opções novamente. As telas de Trâmites e Detalhes do

Trâmite serão iguais em relação à interface e ao acesso disponível para o usuário

Administrador Cliente.

A Ilustração 38 representa a consulta de solicitações, que contém a mesma

aparência da tela disponibilizada para o usuário do tipo Master, porém com algumas

limitações: este usuário poderá consultar somente as solicitações cadastradas por

ele; o campo “Usuário” apresentará as informações do usuário que está acessando

o sistema, sendo mantido desabilitado; o mesmo ocorrerá para o campo “Cliente”.

95

Ilustração 38: Consulta de Solicitações (Usuário).

Fonte: Dos autores.

96

6 CONSIDERAÇÕES FINAIS

Neste capítulo serão apresentadas as conclusões e recomendações para

trabalhos futuros.

6.1 CONCLUSÕES

Para prestar um bom atendimento aos clientes, de modo que satisfaçam

suas necessidades e os padrões exigidos, deve-se pensar principalmente em

agilidade e eficácia deste serviço. A evolução das tecnologias disponíveis permite

que sejam desenvolvidas ferramentas para auxílio ao atendimento, oferecendo

vantagens para o cliente e para a empresa que presta este serviço. A análise das

informações necessárias para o desenvolvimento destas ferramentas precisa ser

feita minuciosamente, para possibilitar que o sistema englobe a maior parte das

necessidades do atendimento, tendo sempre o seu foco principal na satisfação dos

clientes.

Com a constante evolução das tecnologias para o desenvolvimento web,

surgiram dois novos conceitos, Web 2.0 e RIA, cuja característica principal reside na

capacidade de se implementar interfaces ricas em detalhes, proporcionando uma

maior interação do usuário com a aplicação. Com o conceito RIA surgiu um novo

framework para o desenvolvimento de aplicações web chamado de Adobe Flex. Esta

ferramenta foi muito útil para atingir o objetivo principal deste trabalho: satisfazer o

cliente em relação ao protótipo, pois o Flex possui efeitos que podem ser explorados

para produzir uma interface mais amigável ao usuário, além de proporcionar ao

desenvolvedor uma maior facilidade na construção do protótipo.

Para demonstrar a relação entre estas novas tecnologias e o atendimento

adequado aos clientes, neste trabalho foi desenvolvido e exposto um protótipo

englobando estes dois conceitos. Este protótipo disponibiliza processos simples de

serem utilizados e entendidos, utilizando regras que facilitam seu manuseio, para

simplificar e agilizar ao máximo a eficácia do atendimento.

A elaboração deste trabalho proporcionou maior conhecimento e experiência

sobre o atendimento a clientes e como suprir suas necessidades, sendo

fundamental a prestação de um serviço de qualidade. Também foi possível observar

as novas tecnologias emergentes para desenvolvimento, as quais já estão no

mercado atual e que se encontram em constante evolução. Estas tecnologias

97

auxiliam na interação entre empresa e cliente, pois oferecem diversos meios e

alternativas para a realização do atendimento, e facilitam a circulação de

informações entre os mesmos.

6.2 RECOMENDAÇÕES PARA TRABALHOS FUTUROS

A partir do trabalho exposto surgiram algumas propostas para melhoria do

mesmo, apresentadas como especificações para trabalhos futuros:

Desenvolver relatórios gerenciais;

Desenvolver uma rotina para cadastro e consulta de FAQ;

Implementar consultas que utilizem a folksonomia;

Implantar efetivamente este software em uma empresa;

Adicionar novas rotinas de gerenciamento de atendimento.

98

REFERÊNCIAS

ABINADER, Jorge Abílio; LINS, Rafael Dueire. Web Services em Java. Rio de Janeiro, Brasport, 2006.

ADOBE SYSTEMS INCORPORATED. FLEX 2 technical white paper. [S.l.], 2006.Disponível em:<http://www.adobe.com/products/flex/whitepapers/pdfs/flex2wp_technicaloverview.pdf>. Acesso em: 08 ago. 2009.

______. Using Flex Messaging. 2009a. Disponível em: < http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00001168.html>. Acesso em: 22 ago. 2009.

______. Adobe finaliza aquisição da Macromedia. 2009b. Disponível em: < http://www.adobe.com/br/aboutadobe/acquisition.html>. Acesso em: 21 ago. 2009.

______. Perguntas Frequentes. 2009c. Disponível em: < http://www.adobe.com/br/products/flex/faq/>. Acesso em: 18 set. 2009.

AGUIAR, Leandro P. de; MERIZE, Giorgio S. C.; SIQUEIRA, Frank A. PEP: Plugin Eclipse para programação em par distribuída. 2007. Disponível em: <http://www.inf.ufsc.br/~frank/papers/WDDS07-LeandroGiorgio.pdf>. Acesso em: 06 jun. 2009.

ALLAIRE, James. Macromedia Flash MX: A next-generation rich client. 2002. Disponível em: <http://www.adobe.com/devnet/flash/whitepapers/richclient.pdf> Acessado em: 02 set. 2009

ANTUNES, João Carlos. Web 2.0. 2009. Disponível em: <http://www.crie.min-edu.pt/files/@crie/1223032832_04_b_SACAUSEFIV_21a24.pdf >. Acesso em: 08 ago. 2009.

AQUINO, Maria Clara. A potencialização da memória coletiva através do hipertexto na Web 2.0. In: XXX Congresso Brasileiro de Ciências da Comunicação. 29 ago. 2007, Santos. Porto Alegre, UFRGS, 2007. p. 1-16. Disponível em: < http://www.miniweb.com.br/ciencias/Artigos/pot_memoria.pdf>. Acesso em: 01 set. 2009

ARNOLD, Ken; GOSLING, James; HOLMES, David. A linguagem de programação Java. 4. ed. Porto Alegre, Bookman, 2007.

AURÉLIO, Marco. O que você sabe sobre software de HelpDesk. 2009. Disponível em: <http://www.malima.com.br/article_read.asp?id=137>. Acesso em: 01 jun. 2009.

BARROS, João Paulo. O IDE baseado em Eclipse. 2006. Disponível em: <http://www.estig.ipbeja.pt/~jpb/textos/eclipse.pdf>. Acesso em: 06 jun. 2009.

BAZZANELLA, Rafahela Garcia. FAQ: Frequently Asked Questions (Perguntas

99

Freqüentes). 2007. Disponível em: <http://ftp.interlegis.gov.br/interlegis/produtos/saap/versao2.0/docs/Relatorio1-3-FAQ.pdf>. Acesso em: 23 maio 2009.

BENDER JR, Mílton. Desenvolvendo sites com XML. Florianópolis: Advanced Books, 2001.

BEZERRA, Eduardo. Princípios de análise e projetos de sistemas com UML. 2 ed. Rio de Janeiro: Elsevier, 2007.

BLASCHEK, José Roberto. Gerência de requisitos: o principal problema dos projetos de software. 2002. Disponível em: < http://www.bfpug.com.br/islig-rio/Downloads/Ger%C3%AAncia%20de%20Requisitos-o%20Principal%20Problema%20dos%20Projetos%20de%20SW.pdf>. Acesso em: 26 ago. 2009.

BORTOLON, André; WANGENHEIM, Christiane Gresse von; DOMINGOS, Marlon. Uma abordagem híbrida para o gerenciamento de documentos FAQ em português. In: Congresso Brasileiro de Computação. 2001, Itajaí.

BRESSAN, Renato Teixeira. YouTube: intervenções e ativismos. In Anais do XII Congresso da Comunicação na Região Sudeste/ V Encontro Regional de Comunicação. Juiz de Fora. 2007.

CABRERA, Erko Bridee de Almeida. Web 2.0: Fundamentando o conhecimento. 2006a. Disponível em: <https://portaljava.dev.java.net/files/documents/353/36085/Web2_fundamentando_conhecimento.pdf>. Acesso em: 23 maio 2009.

CABRERA, Erko Bridee de Almeida. RIA: Aplicação de internet rica. 2006b. Disponível em: <https://portaljava.dev.java.net/files/documents/353/36084/RIAconceitos.pdf>. Acesso em: 23 maio 2009.

CHAVES, Aline Martins; SILVA, Gabriela da. Proposta de uma arquitetura de software e funcionalidades para implementação de um ambiente integrado de desenvolvimento para a linguagem PHP. 2008. Disponível em: <http://www.cefetbambui.edu.br/str/artigos_aprovados/informatica/68-CO-5.pdf >. Acesso em: 05 jun. 2009.

COENRAETS, C. An overview of MXML: The Flex markup language. Adobe - Developer Center. 2003. Disponível em <http://www.adobe.com/devnet/flex/articles/paradigm.html> Acesso em: 08 ago. 2009.

COHEN, Roberto. Implantação de Help Desk e Service Desk. São Paulo: Novatec, 2008.

DATE, C. J., Introdução a sistemas de banco de dados. Rio de Janeiro, Campus, 2003.

100

DAUM, Berthold; MERTEN, Udo, Arquitetura de sistemas com XML. Rio de Janeiro, Campus, 2002.

DEITEL, Morris. et al. XML: como programar. São Paulo: Bookman, 2001.

DESATNICK, Robert L.; DETZEL, Denis H. Gerenciar bem é manter o cliente. São Paulo: Pioneira, 1995.

DORNELLES, Ramão Jorge. A utilização de tecnologias de internet na educação à distância: o caso de uma disciplina de graduação da Escola de Administração da Universidade Federal Do Rio Grande Do Sul. 94 f. (Dissertação). Programa de Pós-Graduação em Administração, UFRGS. Porto Alegre: 2001. Disponível em: <http://www.lume.ufrgs.br/bitstream/handle/10183/2585/000322602.pdf?sequence=1> . Acesso em: 01 set. 2009.

ECLIPSE FOUNDATION. Eclipse. 2009. Disponível em: <http://www.eclipse.org/>. Acesso em: 06 jun. 2009.

ENTENDA o que é Web 2.0. FolhaOnline. Informática. São Paulo, 06/2006. Disponível em: <http://www1.folha.uol.com.br/folha/informatica/ult124u20173.shtml>. Acesso em: 23 maio 2009.

FAIN, Yakov; RASPUTNIS, Victor; TARTAKOVSKY, Anatole. Rich InternetApplication with Adobe Flex and Java. [S.l.], 2006. Disponível em: <http://java.syscon.com/read/210991_1.htm>. Acesso em: 08 ago. 2009.

FERREIRA, Lourenzo. Uma IDE para Drupal: NetBeans. 2009. Disponível em: < http://lourenzo.blog.br/2009/04/ide-drupal-netbeans.html>. Acesso em: 06 jun. 2009.

FRAGA, Rodrigo Pereira. Integrando Adobe Flex + BlazeDS + SpringFramework + Hibernate: Uma Solução OpenSource para Sistemas Web, 2008. Disponível em: < http://blog.digows.com/integrando-adobe-flex-blazeds-springframework-hibernate-uma-soluo-opensource-para-sistemas-web-parte-1/>. Acesso em: 22 ago. 2009.

FRAGA, Rodrigo Pereira. Interfaces de qualidade com Adobe Flex. Java Magazine. Ano VII, p. 20-29, abril/2009.

FRANCISCO, André Luís Medeiros de. et al. WorkFlow: Ferramenta para Gerenciamento de Solicitações e Aquisição do Conhecimento. 2009. Disponível em: <http://telemedicina.unifesp.br/pub/SBIS/CBIS2004/trabalhos/arquivos/688.pdf>. Acesso em: 31 maio 2009.

FRANCO, Carlos Eduardo G. Curso básico de e-Gen Developer. 2009. Disponível em: < http://javafree.uol.com.br/dependencias/tutoriais/egen/e-GenBasicoV01.pdf>. Acesso em: 15 set. 2009.

FOCUS NETWORKS. Guia web 2.0. Disponível em <http://www.focusnetworks.com.br/guias/focusnetworks_guia_web2.pdf>. Acesso em: 05 ago. 2009.

101

GHIORZI, Pedro Germani. Adaptação do método OOHDM para publicação de aplicações hipermídia em Flex. Junho de 2008. 132 f. (Monografia) UFSC, Curso de Ciências da Computação. Florianópolis: 2008. Disponível em: <http://projetos.inf.ufsc.br/arquivos_projetos/projeto_845/TCC%20Pedro%20germani%20Ghiorzi%20-%20Rascunho%20Relat%F3rio%20Final.pdf >. Acesso em: 22 ago. 2009.

GHISLERI, Amauri Sant’ Anna. Sistema seguro de atendimento ao cliente: Garantia da Qualidade de Serviço. 122 f. (Dissertação) UFSC, Programa de pós-graduação em Ciência da Computação. Florianópolis, 2002. Disponível em: < http://www.tede.ufsc.br/teses/PGCC0309.pdf >. Acesso em: 22 ago. 2009.

GRUPO DE USUÁRIOS JAVA. Criando sua primeira aplicação JAVA com o Eclipse. 2009. Disponível em: <http://www.guj.com.br/content/articles/eclipse/eclipse-2.1.pdf>. Acesso em: 06 jun. 2009.

GUEDES, Gilleanes T. A. UML: uma abordagem prática. São Paulo: Novatec, 2004.

HARGREAVES, Lourdes; ZUANETTI, Rose; LEE, Renato. Qualidade em prestação de serviços. 2. ed. Rio de Janeiro: Senac Nacional, 2005.

ISCTE. Guia de instalação do Eclipse. 2009. Disponível em: <http://ip.dcti.iscte.pt/files/praticas/p1/Intro%20ao%20Eclipse%20...%20e%20JDK.pdf>. Acesso em: 06 jun. 2009.

ISHY, Érika; TURINE, Marcelo Augusto Santos. Gestão de FAQ em ambientes de EAD utilizando a ferramenta baseada em componentes InstantFAQ. 2004. Disponível em: <http://www.iadis.net/dl/final_uploads/200405L042.pdf>. Acesso em: 23 maio 2009.

KISO, Rafael. Visões de negócio. 2009. Disponível em: <http://www.focusnetworks.com.br/banco_arquivos/%7B4CA6E61D-3081-436C-8DCB-9CB4ECA6145A%7D_RIA.pdf>. Acesso em: 23 maio 2009.

KOTLER, Philip. Administração de Marketing: análise, planejamento, implementação e controle. 5. ed. São Paulo: Atlas, 1998.

KUESTER, Hadra Mônica. A biblioteca como provedora de apoio informacional aos cursos de educação à distância no sistema bimodal. 53 f. (Monografia) UDESC. Florianópolis: 2004. Disponível em: <http://www.pergamum.udesc.br/dados-bu/000000/000000000000/0000001F.pdf>. Acesso em: 23 maio 2009.

LIMA, Lucas Albertins de. et al. Eclipse Tools - Ferramenta para auxílio à composição dinâmica de software. 2005. Disponível em: <http://www.dsc.ufcg.edu.br/~pet/atividades/Artigos/ARTIGO_ECLIPSETOOLS.pdf>. Acesso em: 06 jun. 2009.

LOZANO, Fernando. Eclipse: no mundo Open Source. 2003. Disponível em:

102

<http://www.lozano.eti.br/palestras/eclipse-oss.pdf>. Acesso em: 06 jun. 2009.

MACHADO, Felipe Nery Rodrigues; ABREU, Maurício Pereira de. Projeto de banco de dados: uma visão prática. 5 ed. São Paulo: Érica, 1996.

MACORATTI, José Carlos. Modelando sistemas em UML: casos de uso. 2004. Disponível em: < http://imasters.uol.com.br/artigo/2753?cn=2753&cc=145>. Acesso em: 26 ago. 2009.

MARINHO, Euler Horta. Introdução à plataforma Eclipse. 2009. Disponível em: <http://eulerhm.googlepages.com/1-TutorialbsicodoEclipse.pdf>. Acesso em: 06 jun. 2009.

MEIRELLER, Junia Cristina J. P.; MOURA, Mônica. Web 2.0: novos paradigmas projetuais e informacionais. 2007. Disponível em: <http://www.infodesign.org.br/conteudo/artigos/34/ing/versao_final.pdf>. Acesso em: 09 ago. 2009.

MERINO, Danilo W. Internet: canal de comunicação com o consumidor. 2006. Disponível em:<http://www.relacionamentodigital.com/Internet-canal-de-comunicacao-com-o-consumidor>. Acesso em: 08 ago. 2009.

MORITZ, Florian. Rich Internet Applications (RIA): A Convergence of User Interface Paradigms of Web and Desktop Exemplified by JavaFX. 2008. Disponível em: <http://www.flomedia.de/diploma/documents/DiplomaThesisFlorianMoritz.pdf>. Acesso em: 29 ago. 2009.

NASCIMENTO, Geysa Flávia Câmara de Lima. Folksonomia como estratégia de indexação dos bibliotecários no del.icio.us.. 104 f. (Dissertação) Universidade Federal da Paraíba. João Pessoa: 2008. Disponível em: < http://dci2.ccsa.ufpb.br:8080/jspui/bitstream/123456789/173/1/geysaflavia_dissertacao.pdf >. Acesso em: 22 ago. 2009.

NUMARA SOFTWARE. FootPrints 8: a solução de gerenciamento de centrais de atendimento com produtividade inigualável. 2007. Disponível em: <http://www.numarasoftware.com/pdf3/FP_MainBrochure_POB.pdf>. Acesso em: 01 jun. 2009.

OLIVEIRA, Adelize Generini de. Java: a linguagem de programação da internet. Florianópolis: Bookstore, 1996.

OLIVEIRA, Fábio Braga de. Sistema de controle de chamados Símula: Manual do Cliente. 2009. Disponível em: <http://189.111.177.147:8080/jtrac/resources/ManualDoUsuario.pdf>. Acesso em: 31 maio 2009.

OLIVEIRA, Michelle Rodrigues; SILVEIRA, Milene Selbach. Algumas considerações sobre a construção do conteúdo de sistemas de ajuda online para software educacional. 2009. Disponível em:

103

<http://200.169.53.89/download/CD%20congressos/2007/SBIE2007/fscommand/Poster/34526.pdf>. Acesso em: 31 maio 2009. Esta na citação Oliveira e Silveira é assim?

OLIVEIRA, Mirian; ABDALA, Elisabeth Avila. Tecnologias da internet: Casos práticos em empresas. EDIPUCRS, 2003.

O'REILLY, Tim. What is Web 2.0. 2005. Disponível em: <http://oreilly.com/pub/a/web2/archive/what-is-web-20.html?page=1>. Acesso em: 23 ago. 2009.

PEREIRA, Rafael. Guia de Java na Web. Rio de Janeiro: Ciência Moderna, 2006a.

PEREIRA, Henrique Costa. Folksonomia e a maneira com que nós colocamos ordem nas coisas. 2006b. Disponível em <http://revolucao.etc.br/archives/folksonomia-e-a-maneira-com-que-nos-colocamos-ordem-nas-coisas/>. Acesso em: 07 jun. 2009.

Performance Research Associates. Atendimento Nota 10. Rio de Janeiro, 2008.

PLATT, Michael. Web 2.0 na empresa. 2007. Disponível em: <http://msdn.microsoft.com/pt-br/library/bb735306.aspx>. Acesso em: 23 maio 2009.

POHLMANN, Christopher Rosa. Service Desk - nível de maturidade na gestão de serviços de TI: um estudo de caso em uma instituição de ensino superior. 13 nov 2006. 98 f. (Monografia) Universidade do Vale do Rio dos Sinos - Unisinos. São Leopoldo: 2006. Disponível em: < http://www.unisinos.br/inf/files/melhores_tccs/2006_2/tcc_christopherrosapohlmann.pdf >. Acesso em: 22 ago. 2009.

PREUSS, Julio. Entenda a Web 2.0. UOL. Internet. 01/2007. Disponível em: <http://wnews.uol.com.br/site/noticias/materia_especial.php?id_secao=17&id_conteudo=352>. Acesso em: 23 maio 2009.

PRIMO, Alex. O aspecto relacional das interações na Web 2.0. 2007. Disponível em: <http://www6.ufrgs.br/limc/PDFs/web2.pdf>. Acesso em: 26 ago. 2009.

RANGEL, Alexandre, MySQL: Projeto, modelagem e desenvolvimento de banco de dados. Rio de Janeiro, Alta Books, 2004.

RIBES, Marcos Lemke. Interfaces amigáveis na web utilizando XML. 2006. Disponível em: <http://guaiba.ulbra.tche.br/pesquisas/2006/artigos/sistemas/186.pdf>. Acesso em: 09 ago. 2009.

RIJO, Rui. et al. Call Center e Contact Center: Perspectivação histórica e enquadramento conceptual. 2006. Disponível em: <http://www.iadis.net/dl/final_uploads/200607C074.pdf>. Acesso em: 01 ago. 2009.

RODRIGUES, Diego Mendes. Programando para Symbian OS: Preparando o

104

ambiente de desenvolvimento. 2007. Disponível em: <http://www.drsolutions.com.br/exemplos/Programando_Symbian_Aula_1.pdf>. Acesso em: 05 jun. 2009.

ROLIM, Carlos Roberto; ARAÚJO, Ênnyo José Barros de; TOZZI, Juliano César. Construindo aplicações web dinâmicas e otimizadas utilizando Ajax: a caminho da Web 2.0. 2006. Disponível em: <http://www.unibratec.com.br/jornadacientifica/diretorio/NOVOCON.pdf>. Acesso em: 09 ago. 2009.

SALATIEL, José Renato. Estudo Sobre Comunicação em Web 2.0: Mídias Modulares. In: XXX Congresso Brasileiro de Ciências da Comunicação. 29 ago. 2007, Santos. Guarujá: Unaerp, 2007. p. 1-9.

SALGADO, Candido. Análise e Projeto OO com UML. 2001. Disponível em: < http://www.ucb.br/prg/professores/candidog/aps2/licoes/Modneg06UCB.PDF>. Acesso em: 26 ago. 2009.

SCHIMITZ, Daniel Pace. Adobe Flex Builder 3.0: conceitos e exemplos. Rio de Janeiro, Brasport, 2008.

SCOZ, Michel. Sistema de gerenciamento de conteúdo de páginas web utilizando Flex. Julho de 2007. 79 f. (Monografia) FURB, Curso de Ciências da Computação. Blumenau: 2007. Disponível em: < http://www.inf.furb.br/~pericas/orientacoes/GerenciaPaginaFlex2007.pdf >. Acesso em: 22 ago. 2009.

SHREVE, Justin G. O básico de Web Services, 2005. Disponível em: < https://developer.mozilla.org/pt/O_b%C3%A1sico_de_Web_Services>. Acesso em: 22 ago. 2009.

SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S., Sistema de banco de dados. Rio de Janeiro, Elsevier, 2006.

SILVA, Cáren Cristiane Gomes da. Marketing de serviços: a satisfação dos usuários da internet. 63 f. (Monografia) Especialização em Gestão de Marketing, Universidade Cândido Mendes. Rio de Janeiro: 2004. Disponível em: < http://www.vezdomestre.edu.br/monopdf/24/C%C3%81REN%20CRISTIANE%20GOMES%20DA%20SILVA.pdf >. Acesso em: 22 ago. 2009.

SILVA, Osmar J. XML Aplicações Práticas. São Paulo, Érica, 2001.

SILVA FILHO, Antonio Mendes da. Programando com XML. Rio de Janeiro, Campus, 2004.

SORROCHE, Rogério; LOPES, Maurício Capobianco. Uso de design patterns e J2EE: um estudo de caso. 2002. Disponível em: < http://arquivosweb.lncc.br/pdfs/128-vf.pdf>. Acesso em: 15 set. 2009.

STATDLOBER, Juliano. Help-Desk e SAC com qualidade. Rio de Janeiro:

105

Brasport, 2006.

SUEHRING, Steve. MySQL: a Bíblia, Rio de Janeiro, Campus, 2002.

SUM MICROSYSTEMS, INC. História do MySQL, 2009. Disponível em: < http://dev.mysql.com/doc/refman/4.1/pt/history.html >. Acesso em: 15 ago. 2009.

TEIXEIRA, Sérgio. Chatterbots: uma proposta para a construção de bases de conhecimento. 07 jul 2005. Tese. Universidade Federal do Espírito Santo. Vitória: 2005. Disponível em: < http://www.multicast.com.br/sergio/tuxbot-dissertacao-mestrado-sergio-teixeira.pdf >. Acesso em: 22 ago. 2009.

TELLARIN. Eclipse Day no SERPRO. 2004. Disponível em: <http://www.sounerd.com.br/index.php/Noticias/144.pdf>. Acesso em: 06 jun. 2009.

TONSIG, Sérgio Luiz. MySQL: aprendendo na prática. Rio de Janeiro, Ciência Moderna, 2006.

TURBAN, Efraim; KING, David. Comércio eletrônico: estratégia e gestão. São Paulo, 2004. VAREJÃO, Flávio Miguel. Linguagem de programação: conceitos e técnicas. Rio de Janeiro, Elsevier, 2004.

VASCONCELOS, Larissa Lucena; HERBSTER, Raul Fernandes; FECHINE, Joseana Macêdo. Desenvolvimento de IDE para plataforma OMAP. 2005. Disponível em: <http://www.dsc.ufcg.edu.br/~pet/atividades/Artigos/ARTIGO_IDE-OMAP.pdf>. Acesso em: 06 jun. 2009.

WALSH, Norman. A technical introduction to XML. 1998. Disponível em: < http://www.xml.com/pub/a/98/10/guide0.html?page=2 >. Acesso em: 23 ago 2009.

WARD, James. Census - RIA Data Loading Benchmarks. 2007. Disponível em: < http://www.jamesward.com/census/>. Acesso em: 13 ago. 2009.

WARD, James; TIWARI, Shashank. Building Web and Desktop Applications with BlazeDS and AMF. 2008. Disponível em: <http://www.infoq.com/articles/blazeds-intro> Acessado em: 19 set. 2009

WAZLAWICK, Raul Sidnei. Análise e projeto de sistemas de informação orientados a objetos. Rio de Janeiro: Elsevier, 2004.

ZANINETTI, Gabriela. Adobe anuncia tecnologias open source para RIAs Corporativas. 2008. Disponível em: < http://www.adobe.com/br/aboutadobe/pressroom/pr/jan2008/PR_BlazeDS.pdf>. Acesso em: 18 set. 2009.

Technology

Apresentação dos conceitos web 2.0 e ria, aplicados ao desenvolvimento de um protótipo de sistema para suporte a clientes