DESENVOLVIMENTO DE UM SISTEMA PARA COLETAR FEEDBACK
DE CLIENTES DE UM EMPREENDIMENTO
Trabalho de Conclusão de Curso de Graduação, apresentado ao Curso Superior de Tecnologia em Sistemas para Internet, da Universidade Tecnológica Federal do Paraná – UTFPR, como requisito parcial para obtenção do título de Tecnólogo.
Orientador: Me. Roberto Milton Scheffel
TOLEDO 2016
equal sharing of miseries. (CHURCHILL, Winston, 1874-1965).
O vício inerente do capitalismo é a partilha desigual das bênçãos; A virtude inerente do socialismo é a partilha igual de misérias. (CHURCHILL, Winston, 1874-1965).
DALLE MOLE, Giancarlo. Desenvolvimento de um Sistema para Coletar Feedback De Clientes de um Empreendimento. 2016. 107 p. Trabalho de conclusão de curso – Tecnologia em Sistemas para Internet, Universidade Tecnológica Federal do Paraná. Toledo, 2016.
A satisfação do consumidor é muito importante para qualquer empreendimento, pois é a partir dela que um cliente demonstra sua insatisfação ou encantamento pelo produto ou serviço prestado. Contudo, mensurar o nível de satisfação não é um processo simples. Apesar de existirem muitos métodos, como os formulários de pesquisa de satisfação ou entrevistas, esses muitas vezes não são interessantes para o consumidor, pois podem ser demorados, impraticáveis ou intimidadores. Assim, esse trabalho teve como objetivo desenvolver um sistema multiplataforma capaz de coletar feedback de clientes por meio de formulários interativos. Tal coleta é realizada forma rápida e eficiente a fim de mensurar o nível de satisfação a respeito do produto ou serviço prestado, gerando relatórios sintéticos das pesquisas efetuadas. No desenvolvimento desse sistema, foi empregado o Processo Unificado como estratégia de desenvolvimento. Espera-se que, com esse trabalho, o sistema criado possa ser aplicado em ambientes reais, auxiliando os empresários a entenderem melhor seus clientes e identificarem os problemas e qualidades dos seus negócios.
Palavras-chave: Satisfação do consumidor. Feedback de clientes. Sistema multiplataforma. Processo Unificado.
DALLE MOLE, Giancarlo. System Development to Collect Customer Feedback of a Business. 2016. 107 p. Trabalho de conclusão de curso – Tecnologia em Sistemas para Internet, Universidade Tecnológica Federal do Paraná. Toledo, 2016.
Customer satisfaction is very important for any business because it is from that customers shows their dissatisfaction or glamour for the product or service. However, measure the level of satisfaction is not a simple process. Even though there are many methods, such as forms of satisfaction surveys or interviews, those methods are often not interesting for the consumer, because it can be time consuming, impractical or intimidating. Thus, this study aimed to develop a multiplatform system able to collect customer feedback through interactive surveys forms, quickly and efficiently in order to measure the level of satisfaction regarding the product or service, generating synthetic reports based on the survey’s results. In the development of this system was used the Unified Process as an development process. It is hoped that, with this work, the created system can be applied in real environments, helping businesses better understand their customers, and identify the problems and qualities of their business.
Keywords: Consumer satisfaction. Client feedback. Multiplatform system. Unified Process.
Figura 1 Empresas Ativas ... 14
Figura 2 Número de empresas que sobreviveram mais de um ano ... 15
Figura 3 Consequências de um cliente satisfeito ... 18
Figura 4 Ciclo ideal de um produto ou serviço em uma empresa ... 22
Figura 5 Diagrama de interação entre as tecnologias. ... 24
Figura 6 Exemplo de documentos armazenados no MongoDB ... 26
Figura 7 TypeScript é um supertipo do JavaScript ... 29
Figura 8 Arquitetura da plataforma Meteor. Fonte: What is Meteor.js? ... 31
Figura 9 Recursos dos dispositivos compatíveis com Phonegap. ... 34
Figura 10 Fases do Processo Unificado ... 36
Figura 11 Diagrama de casos de uso geral. ... 45
Figura 12 Diagrama geral de pacotes ... 47
Figura 13 Diagrama de casos de uso para controle de acesso e usuário ... 49
Figura 14 Diagrama de casos de uso para o pacote empresas. ... 49
Figura 15 Diagrama de casos de uso para os pacotes questionários e questões... 50
Figura 16 Diagrama de arquitetura do sistema. ... 57
Figura 17 Diagrama de classes da arquitetura de componentes proposta. ... 58
Figura 18 Diagrama de pacotes de empresas... 62
Figura 19 Diagrama de pacotes de planos de assinatura. ... 62
Figura 20 Diagrama de pacotes para usuários... 63
Figura 21 Diagrama de pacotes para questionários. ... 63
Figura 22 Diagrama de classe de entidades do pacote usuários. ... 65
Figura 23 Diagrama de classes para entidades do pacote empresa ... 67
Figura 24 Diagrama de classes para entidades do pacote questões. ... 68
Figura 25 Diagrama de classes para entidades do pacote questionários ... 70
Figura 26 Diagrama de classes para entidades para o pacote “Metas” ... 71
Figura 27 Diagrama de classes de controle para o pacote usuários. ... 73
Figura 28 Diagrama de classes de controle para o pacote questões. ... 74
Figura 29 Diagrama de sequência para o caso de uso UC1 - Registrar empresa. ... 76
Figura 30 Diagrama de sequência para o caso de uso UC2 - Cadastrar questão. ... 77
Figura 31 Diagrama de sequência para o caso de uso UC3 - Criar questionário. ... 78
Figura 32 Diagrama de sequência para o caso de uso UC4 - Gerar relatório básico 79 Figura 33 Diagrama do banco de dados do sistema ... 81
Figura 34 Página de cadastro de empresa (usuário administrador) ... 83
Figura 35 Página de cadastro da empresa (dados da empresa). ... 83
Figura 36 Página de cadastro de questões ... 85
Figura 37 Página de cadastro de questionário ... 86
Figura 38 Página de aplicação de questionário... 87
Figura 39 Relatório básico em tela (parte 1) ... 88
Figura 40 Relatório básico em tela (parte 2) ... 89
Tabela 1 - Classificação dos requisitos funcionais. ... 43
Tabela 2 - Referências cruzadas (dependências entre requisitos). ... 44
Tabela 3 - Especificação do caso de uso "Registrar empresa". ... 51
Tabela 4 - Especificação do caso de uso "Cadastrar Questão". ... 52
Tabela 5 - Especificação do caso de uso "Criar Questionário". ... 52
Tabela 6 - Especificação do caso de uso "Gerar Relatório Básico". ... 53
Tabela 7 - Resultados obtidos para testes sem cache. ... 91
API Application Programming Interface
AWS Amazon Web Services
CNPJ Cadastro Nacional de Pessoas Jurídicas
CPU Central Processing Unit
CRUD Create Retrieve Update Delete
CSS Cascading Style Sheets
CSV Comma-separated Values
CVS Concurrent Version System
DDP Distributed Data Protocol
DOM Document Object Model
EC2 Elastic Compute Cloud
ER Entity Relationship
GB Gigabyte
GEM Global Entrepreneurship Monitor
GNU Gnu is Not Unix
HDD Hard Disk Drive
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
IDE Integrated Development Environment
JSF Java Server Faces
JSON JavaScript Object Notation
JVM Java Virtual Machine (Máquina Virtual Java)
MSDN Microsoft Development Network
MVC Modelo Visão Controle
PDA Personal Digital Assistant
RAM Random Access Memory
RDB Relational Database (Banco de dados relacional) RPC Remote Procedure Call (Chamada de Procedimento
remoto)
SaaS Software as a Service (Software como um Serviço)
TI Tecnologia da Informação
TIM Telecom Italia Mobile
1 INTRODUÇÃO ... 8 1.1. DELIMITAÇÃO DO TEMA ... 8 1.2. OBJETIVOS ... 9 1.2.1. Objetivo Geral ... 9 1.2.2. Objetivos Específicos ... 10 1.3. JUSTIFICATIVA ... 10 2 REFERENCIAL TEÓRICO ... 13
2.1. CRESCIMENTO DO EMPREENDEDORISMO NO BRASIL ... 13
2.2. SATISFAÇÃO DO CONSUMIDOR ... 16
2.2.1. A Teoria e sua Importância ... 16
2.2.2. Como Medir a Satisfação do Consumidor ... 19
2.3. MARKETING DE RELACIONAMENTO ... 20
3 MATERIAIS E MÉTODOS ... 23
3.1. MATERIAIS ... 23
3.1.1. Visual Paradigm Community Edition ... 25
3.1.2. MongoDB ... 25 3.1.3. DBSchema ... 27 3.1.4. Robomongo ... 28 3.1.5. TypeScript ... 28 3.1.6. Framework Meteor... 30 3.1.7. Framework Angular ... 32 3.1.8. WebStorm ... 33 3.1.9. Adobe Phonegap ... 33 3.2. MÉTODOS ... 35
3.2.1. Processo de Desenvolvimento do Software ... 35
4 DESENVOLVIMENTO ... 37
4.1. ANALISE E LEVANTAMENTO DE REQUISITOS ... 37
4.1.1. Requisitos funcionais ... 38
4.1.2. Requisitos não funcionais ... 40
4.1.3. Classificação dos requisitos funcionais ... 43
4.1.4. Referências cruzadas (dependências entre requisitos) ... 43
4.2. PROJETO DE NEGÓCIO ... 44
4.3. PROJETO LÓGICO (ARQUITETURA DE SISTEMA) ... 54
4.3.1. Descrição da arquitetura do sistema ... 55
4.3.2. Diagramas ... 60
4.3.3. Diagramas de classe ... 64
4.3.4. Diagramas de sequência ... 75
4.3.5. Diagrama de banco de dados orientado a documento ... 80
5 RESULTADOS OBTIDOS ... 82 5.1. SISTEMA DESENVOLVIDO ... 82 5.1.1. Registro de empresa ... 82 5.1.2. Controle de acesso ... 84 5.1.3. Cadastro de questões ... 84 5.1.4. Cadastro de questionários ... 85 5.1.5. Aplicação de questionários ... 86 5.1.6. Relatórios ... 88 5.1.7. Criação de metas ... 89 5.2. TESTES ... 90
5.2.1. Testes de conexão em rede de dados móveis ... 90
6 TRABALHOS FUTUROS ... 94
7 CONSIDERAÇÕES FINAIS... 95
REFERÊNCIAS ... 97
1 INTRODUÇÃO
1.1. DELIMITAÇÃO DO TEMA
É possível perceber que empresários buscam melhorar seus negócios a partir de diversas análises e métricas. Uma das análises é a qualidade do seu serviço prestado, pois pouca qualidade não atrai clientes. Rastrear e identificar problemas nesse aspecto pode ser uma tarefa um pouco difícil para determinados modelos de negócio. Muitas vezes, tal identificação só é percebida quando o problema já está agravado e sua recuperação nesse nível é difícil.
Segundo o SEBRAE, em uma matéria publicada pelo G1 (2010), foi constatado que 60% das empresas fecham suas portas até o seu segundo ano de existência. Ao analisarmos essa pesquisa, concluímos que o número é alto e suas causas muitas vezes são a falta de conhecimento administrativo e o péssimo ou inexistente marketing de relacionamento. (G1, 2010).
De acordo TORRES e FONSECA (2012, p. 3), “O marketing de relacionamento, nos dias de hoje, é uma ferramenta imprescindível para que a organização faça frente à concorrência e adquira vantagem competitiva.”. Um dos pontos abordados no marketing de relacionamento é a satisfação do consumidor, pois um consumidor insatisfeito tende a procurar outras empresas que forneçam um serviço melhor. Para compreender os sentimentos dos clientes para com a organização é necessário utilizar métodos para mensurar esses níveis de satisfação e compreender o pensamento dos consumidores. Um desses métodos, segundo Kotler (1998, apud Pfeifer, 2006, p. 14), é a pesquisa por formulários de sugestões e reclamações, o qual é uma das formas mais comuns de pesquisa de satisfação de clientes.
Infelizmente, na maioria das vezes, as organizações não constróem formulários adequados para mensurar a satisfação de seus clientes, ou quando o
fazem, não existe incentivo para o consumidor. Outro problema é que as empresas não conseguem interpretar os dados coletados de maneira fácil, seja por falta de conhecimento ou pela não informatização do método.
Para melhorar a forma de aplicação de pesquisas por formulários de sugestões e reclamações, um dos métodos mais utilizados para mensurar a satisfação dos clientes, foi pensado em uma maneira de digitalizar isso. Assim, chegou-se à conclusão de que a melhor forma de fazer essa digitalização é a elaboração de um sistema web/mobile, capaz de coletar os dados por meio de formulários interativos e dinâmicos. Como consequência, fez-se necessário estudar métodos de construção de formulários com o objetivo de entender melhor como efetuar a correta aplicação desses e consagrar relatórios que apresentem de maneira útil os resultados coletados.
1.2. OBJETIVOS
1.2.1. Objetivo Geral
Desenvolver uma aplicação que torne interativa, rápida e conveniente a coleta de feedback de clientes de uma empresa, permitindo a geração de relatórios e gráficos para avaliar o nível de satisfação dos clientes. Desse modo, a aplicação terá por objetivo auxiliar os empresários a melhorarem seus negócios, conforme os dados de feedback coletados. Juntamente da aplicação, construir formulários que sejam coerentes e que gerem dados úteis para segmentos específicos, sendo utilizados com a aplicação e permitindo efetuar a análise dos dados coletados de forma automatizada.
1.2.2. Objetivos Específicos
Desenvolver uma aplicação multiplataforma capaz de efetuar a coleta de feedback de clientes, com a finalidade de expor os resultados obtidos para a empresa e permitir a melhora de seu negócio;
Elaborar um banco de questões, que sejam adequadas a determinados modelos de negócios. Elaborar ao menos um formulário para um segmento, de forma a validar a solução apresentada;
A partir do banco de questões, elaborar formulários padrões por segmento de negócios. Os formulários serão dinâmicos, ou seja, a próxima pergunta se dará de acordo com a resposta da pergunta atual. Isso torna a coleta de feedback mais aproveitável, pois podemos redirecionar os clientes para perguntas especificas conforme suas respostas, extraindo melhor o sentimento/opinião dele sobre o produto/serviço avaliado;
Gerar relatórios textuais e gráficos a partir do feedback coletado, os quais estarão disponíveis em todas as plataformas. Esses relatórios terão o objetivo de apresentar os pontos fortes e fracos do negócio; e
Implementar um método que permita a inclusão de questões personalizadas (visíveis apenas para a empresa que a adicionou), permitindo desse modo a criação de formulários customizados pela empresa.
1.3. JUSTIFICATIVA
Ao observar o mundo dos negócios, percebeu-se que a satisfação dos clientes é de extrema importância para as empresas crescerem e criarem produtos ou serviços de qualidade. Para que isso ocorra, é necessário que se meça constantemente o nível
de satisfação dos consumidores. Um dos métodos sugeridos por Kotler (1998, apud Pfeifer, 2006, p. 14), é o uso de formulários de reclamações/sugestões.
O método citado anteriormente para mensurar o nível de satisfação dos consumidores é um dos mais utilizados em qualquer modelo de negócio. Contudo ele ainda é aplicado da maneira tradicional que consiste em uma caixa de sugestões/reclamações e um formulário em papel que pode ser preenchido pelos consumidores. Com o método tradicional é possível apontar alguns problemas:
1. Tempo. O consumidor nem sempre possui tempo para preencher o formulário. A maioria dos formulários utilizados leva em torno de 5-10 minutos (questões objetivas), e até 15 minutos (questões dissertativas). (GHIMIRE, 2012 p. 3);
2. Visibilidade e incentivo. Muitas vezes o consumidor não sabe da existência da “caixa de sugestões” e, na maioria das vezes, não há incentivo por parte da empresa;
3. Desconhecimento do marketing de relacionamento. Muitas empresas, até mesmo as grandes, não conhecem exatamente os sentimentos dos seus clientes pelo serviço ou produto ofertado. Desse modo, acabam não tendo justificativas ou motivos para investirem melhor em seus produtos e serviços; e
4. Dificuldade na criação de formulários úteis. Muitas vezes as empresas acabam criando formulários para coleta de feedback que não são capazes de servir ao seu propósito, que é mensurar a satisfação do cliente e identificar problemas. (LETTS, 2013).
Outro motivo para a elaboração desse sistema é o crescimento dos dispositivos móveis e a facilidade trazida por eles. Muitas empresas de restaurantes e hotéis vêm informatizando seus negócios, incluindo a utilização de PDAs (Personal Digital Assistant) e tablets. Um exemplo real é o restaurante Filezão (Toledo, PR), no qual os garçons possuem tablets para anotar os pedidos. Utilizando a informatização, é possível fazer a coleta de feedback com os mesmos dispositivos móveis, de tal forma que em momentos oportunos (ex.: pagamento), o garçom peça para o cliente responder um questionário rápido de menos de um minuto, ou um questionário mais
complexo que exija mais tempo. O tempo necessário para a realização do questionário dependerá do número de questões utilizadas e a complexidade de cada questão, sendo tarefa da empresa elaborar questionários adequados ao seu negócio e a cada situação. Com isso a coleta de feedback será mais frequente e mostrará as mais diversas opiniões dos consumidores, gerando assim uma grande melhora na identificação dos pontos fortes e fracos do produto ou serviços ofertados.
Apesar de já existirem algumas aplicações com um propósito semelhante ao do sistema que será desenvolvido nesse trabalho, elas apresentam algumas falhas. Um exemplo é a aplicação LoopSurvey, disponível para Android e iOS, sendo uma das mais famosas nessa categoria, mas ainda apresentando alguns problemas:
Sua versão gratuita é limitada a apenas 7 questões. Na versão paga é 25, mas o questionário é estático, ou seja, não se desenvolve de acordo com as respostas do usuário;
Problemas de estabilidade, segundo avaliações na PlayStore1 e
experiência própria, a aplicação é instável, ocorrendo travamentos constantes;
A interface gráfica que os clientes interagem não é muito agradável e ultrapassada. Um exemplo é o método de avaliação por estrelas, composto por múltiplas opções e não apenas um slider de 0 a 5 estrelas; e
Os relatórios gerados não são muito úteis, mesmo em sua versão paga. Seus relatórios mostram apenas a porcentagem de cada resposta em cada questão, não gerando gráficos de histórico ou com possibilidade de filtros.
1 Página da aplicação na PlayStore: https://play.google.com/store/apps/details
2 REFERENCIAL TEÓRICO
Para a elaboração desse trabalho foram efetuadas pesquisas na área de empreendedorismo, satisfação do consumidor e marketing de relacionamento. Assim, foi possível compreender a importância da satisfação do consumidor, seus efeitos nos negócios e identificar uma maneira de mensurar a satisfação dos consumidores.
2.1. CRESCIMENTO DO EMPREENDEDORISMO NO BRASIL
A quantidade de empreendedores no Brasil vem crescendo nos últimos anos conforme pesquisas realizadas pela GEM (Global Entrepreneurship Monitor) em parceria com o Sebrae.
GEM “é um projeto de pesquisa que tem a finalidade de aprofundar o conhecimento sobre questões relacionadas ao empreendedorismo [... e ...] avalia o impacto da atividade empreendedora no PIB e na geração de emprego nos países” (GEM, 2002, p. 1). Segundo a pesquisa de 2002 a taxa de empreendedorismo no Brasil era de 20,9%, já em 2014 era de 34,4% e em 2015 essa taxa subiu para 39,3%. Estima-se, assim, que 52 milhões de brasileiros com idades entre 18 e 64 anos estavam envolvidos com uma atividade empreendedora (seja como criação ou manutenção do empreendimento) no ano de 2015 (GEM, 2015, p. 10).
Conforme as pesquisas GEM demonstram, a atividade empreendedora no Brasil vem crescendo a cada ano. Isso ocorre principalmente pelas políticas públicas e incentivos ao empreendedorismo que o governo brasileiro vem realizando nos últimos anos. Um dos programas que podemos citar é o programa “Empresa Fácil”, que tem por objetivo “incentivar a legalização de negócios informais e formalização de novos empreendimentos [...]” (Lei Municipal Nº 5.409/2009, Cascavel PR). Outro programa já no âmbito nacional é o “Programa Nacional de Microcrédito Produtivo e Orientado”, o qual tem o objetivo “de incentivar a geração de trabalho e renda entre os microempreendedores populares” (Lei Nº 11.110/2005, expandida em 2013). Foi
relatado ainda que os brasileiros são, em geral, “favoráveis a atividade empreendedora e possuem uma visão positiva a respeito dos indivíduos envolvidos com negócios próprios” (GEM Brasil 2015, p. 18).
Apesar dos incentivos realizados pelo governo e da visão positiva dos brasileiros em relação a atividade empreendedora, muitas empresas acabam não conseguindo sobreviver aos primeiros anos de sua criação. Outras, após um “boom” de crescimento, começam a decair, chegando ao ponto de falência ou estagnação. Muitos fatores podem ocasionar o fracasso ou estagnação de um negócio, nos quais, na maioria das vezes, estão envolvidos a redução da satisfação dos consumidores e/ou qualidade do serviço prestado.
No ano de 2010, o SEBRAE divulgou uma pesquisa na qual é constatado que 60% das empresas fechavam as portas até o seu segundo ano de existência, sendo que um dos principais motivos para o fechamento é a falta de conhecimento administrativo (G1, 2010). Já segundo o IBGE, de todas as empresas que foram criadas no ano de 2009, apenas 47,5% delas ainda estavam atuando no mercado em 2013 (FOLHA DE S. PAULO, 2015). Apesar dessa alta taxa de fechamento de empresas, o número delas vem crescendo a cada ano, conforme podemos ver na Figura 1. Consequentemente, o número de empresas que sobrevivem mais de 1 ano, também aumenta conforme a Figura 2.
Figura 1 - Empresas Ativas (por ano, em mil). Fonte: IBGE (FOLHA DE S. PAULO, 2015)
Figura 2 - Número de empresas que sobreviveram mais de um ano (por ano, em mil). Fonte: IBGE (FOLHA DE S. PAULO, 2015)
Conforme citado anteriormente, um dos pontos que levaram diversas empresas a finalizarem suas atividades é a falta de conhecimento administrativo. Esse conhecimento abrange vários tópicos, dentre os quais podemos destacar: marketing, concorrência, estratégias de mercado, marketing de relacionamento e a teoria da satisfação do consumidor. Os dois últimos citados são voltados a análise e comunicação da empresa com o seu consumidor.
A satisfação do consumidor envolve muitos fatores, como por exemplo a qualidade de serviço. Esta é algo muito importante para uma empresa, conforme Ghimire (2012, p. 1) “tanto qualidade de serviço quanto satisfação dos consumidores são importantes para o ponto de vista de marketing em termos de consumidores e vendedores”, sendo que o segundo geralmente é consequência do primeiro. Ainda segundo Gerson (1993, apud GHIMIRE, 2012, p. 7), a satisfação do consumidor é essencial e as empresas deveriam se focar-se nisso, pois em qualquer negócio que não obtenha sucesso em satisfazer o consumidor existe uma grande tendência que o consumidor possa não amparar o negócio novamente.
Quando consumidores não estão satisfeitos com o produto ou serviço, eles tendem a demonstrar o seu descontentamento com outras pessoas, amigos e/ou familiares, mais frequentemente do que se fosse em uma situação contrária. Desse modo, a empresa fornecedora acaba perdendo o cliente atual e possíveis novos clientes sem ao menos saber o motivo. Nesse ponto entra a questão do marketing de relacionamento e a medição de satisfação.
2.2. SATISFAÇÃO DO CONSUMIDOR
2.2.1. A Teoria e sua Importância
O estudo da satisfação e comportamento do consumidor teve início nas décadas de 60 e 70 na américa do norte (EVRARD, 1993, apud SOUZA, 2011). Nas últimas décadas, com o surgimento de novos empreendedores e acirramento da concorrência, o tema “satisfação do consumidor” tem se tornado bastante pesquisado e discutido, gerando um grande número de publicações realizadas (CUNHA JÚNIOR, BORGES JÚNIOR, FACHEL, 1998, p. 1).
“Satisfação consiste na sensação de prazer ou desapontamento resultantes da comparação do desempenho (ou resultado) percebido de um produto em relação às expectativas do comprador.” (KOTLER, 2000, p.58). Em outras palavras, é a correlação entre as suposições e os sentimentos do consumidor. Já, segundo SOUZA (2011, p. 4), “a satisfação é vista de uma maneira consensual como uma das chaves para o sucesso das empresas, pelo que muitas organizações procuram compreender e avaliar os seus atributos mais importantes”.
Em qualquer ramo de negócio os clientes são o ponto chave, pois um negócio sem clientes não possui razão para existir. Um produto ou serviço de má qualidade, que não satisfaça as expectativas dos consumidores, não cria empresas de sucesso. Muito pelo contrário, isso pode levar a sua extinção, principalmente nos dias atuais em que os clientes buscam qualidade naquilo que depositam seu dinheiro. Se a empresa não satisfaz o cliente, ao encontrar um concorrente que possa satisfaze-lo, é muito provável que ele mude para o concorrente, exceto em casos que a empresa conseguiu cativa-lo, conforme será apresentado na seção de “Marketing de relacionamento”.
Para Okumu (2012, p. 9) “é importante para as companhias saberem e entenderem a teoria da satisfação do consumidor a fim de melhorar e exceder as expectativas dos consumidores”. Quando as empresas começam a compreender seus clientes e as necessidades deles, elas devem dar foco total para atendê-las, prestando
atenção a cada reação do seu consumidor. Num exemplo citado por Souza (2009, p. 7), clientes que buscam variedade podem mudar de marca (fornecedor), mesmo que estejam satisfeitos com a marca atual, por quererem variedades ou inovação. Torres e Fonseca (2012, p. 8) dizem que “Os clientes são a principal razão de existência de qualquer empresa e satisfazê-los deve ser o principal foco das organizações.”.
McNeil (2006 apud OKUMU, 2012, p. 9) sugere que a satisfação do consumidor somente pode ser alcançada quando a qualidade de serviço e a qualidade do produto são de agrado ao consumidor. Se algum desses aspectos desagradar o consumidor, toda a sua satisfação estará comprometida, consequentemente comprometendo a “imagem” do produto e a credibilidade da empresa. (McNeil 2006, apud OKUMU, 2012, p. 9). A qualidade de um serviço prestado é fundamental para a satisfação do consumidor e o sucesso do negócio, pois segundo Cobra (2009 apud TORRES; FONSECA, 2012, p. 5) a satisfação de clientes por meio de um serviço de qualidade determina uma vantagem competitiva em relação aos concorrentes.
A medição da satisfação ajuda os consumidores a comunicar suas necessidades diretamente as empresas. Além disso, a satisfação é muito importante pois ela ajuda a entender as fraquezas e forças do negócio (GHIMIRE, 2012, p. 6). Desse modo, uma empresa que está atenta aos seus consumidores consegue identificar os grupos de clientes, podendo dessa maneira atendê-los de formas diferenciadas, a fim de satisfazer suas necessidades específicas. Complementando isso, Kotler (2000, p.33) diz que “o produto ou oferta alcançará êxito se proporcionar valor e satisfação ao comprador-alvo. O comprador escolhe entre diferentes ofertas com base naquilo que parece proporcionar o maior valor.”
Nesse contexto Kotler (2000, p.59), sugere que as empresas sejam centradas nos seus clientes e que a satisfação deles é, ao mesmo tempo, uma meta e uma ferramenta de marketing. Empresas que possuem clientes com altos níveis de satisfação fazem questão de se vangloriar de seus concorrentes de mercado.
Quando um cliente se satisfaz com um serviço ou produto de uma empresa, eles tendem a referencia-la para seus amigos e parentes, ajudando assim a promover o negócio fazendo assim com que a empresa consiga mais clientes (GHIMIRE, 2012, p. 7). Desse modo, podemos concluir que satisfazer um cliente ajuda a aumentar a rentabilidade do negócio.
Para demonstrar a importância desse tema, Kotler (2000, p. 70) descreve o perfil do cliente altamente satisfeito, atribuindo a ele os seguintes aspectos (ilustrado na Figura 3):
a. Permanece fiel por mais tempo;
b. Compra mais à medida que a empresa lança novos produtos ou aperfeiçoa produtos existentes;
c. Fala favoravelmente da empresa e de seus produtos;
d. Dá menos atenção a marcas e propaganda concorrentes e é menos sensível a preço;
e. Oferece ideias sobre produtos ou serviços à empresa;
f. Custa menos para ser atendido do que novos clientes, uma vez que as transações são rotineiras.
Para que os clientes possam obter o maior nível de satisfação, todos os funcionários envolvidos devem conhecer os clientes, percebendo quando eles estão satisfeitos ou não. Quando um cliente não estiver satisfeito, o funcionário deve conversar com ele e ouvir seus questionamentos, desse modo tentar fazer melhoras (RAMACHANDRAN, 2006).
Figura 3 - Consequências de um cliente satisfeito. Fonte: SOUSA, 2015 (apud Palladini, 2002)
Segundo Tronchin (2002, apud SOUZA, 2009, p. 3), a satisfação dos clientes é importante, mas não garante a fidelidade. Para Torres e Fonseca (2012, p. 9), um cliente satisfeito não significa lealdade à empresa, pois os clientes nunca estão totalmente satisfeitos e para satisfazê-los é necessário saber o que eles querem. Porém a grande maioria das pessoas não sabe o que quer. É nesse momento que entra a questão do “Marketing de Relacionamento”.
2.2.2. Como Medir a Satisfação do Consumidor
Conforme visto anteriormente, a satisfação do consumidor é considerada muito importante em qualquer negócio. Contudo, faz-se necessário medir esse nível de satisfação para que possa ser avaliado os sentimentos do consumidor em relação à empresa prestadora do serviço ou produto. Para que se possa medir com um certo nível de confiança, existem diversos métodos e ferramentas que as organizações podem utilizar. Podemos citar três dos mais conhecidos e utilizados, conforme a definição de Kotler (1998, apud Pfeifer, 2006, p. 14):
Sistema de reclamação e sugestões. Esse sistema é composto de formulários de pesquisa com questões relacionadas ao serviço ou produto promovido pela empresa, cabendo ao cliente respondê-las conforme seus sentimentos em relação a empresa e produto/serviço. No fim, cabe à empresa efetuar uma análise dos dados coletados e identificar os pontos fortes e fracos.
Levantamento do nível de satisfação dos consumidores por meio da verificação da frequência e a quantidade que os seus clientes compram (ou utilizam, no caso de um serviço). Uma súbita baixa na frequência ou no volume de compras pode significar uma baixa taxa de satisfação dos clientes, ou ainda, que um concorrente fornece um serviço/produto de melhor qualidade. Pfeifer (2006, p. 8) diz que, segundo estudos realizados, menos de 5% dos consumidores insatisfeitos tendem a realizar uma reclamação.
Contratação de pessoas para serem supostos compradores nos estabelecimentos, para posteriormente relatarem suas experiências. O método “sistema de reclamações e sugestões” é uma das ferramentas mais utilizadas em todo o mundo para coleta de feedback do consumidor a fim de medir o nível de satisfação do consumidor. Apesar desse método ser muito utilizado pelas empresas e foco de estudo em diversos trabalhos (OKUMU, 2012), é possível perceber que uma grande quantidade de pessoas acaba por evadir desses formulários, conforme cita Okumu (2012, p. 43) na conclusão do seu trabalho: “De 80 questionários 52 foram recebidos de volta. Embora o número de questionários retornando não foi bom, foi considerado adequado para que os resultados sejam razoavelmente confiáveis”.
Ainda na ferramenta de sistema de reclamações e sugestões, é possível perceber outro ponto fraco: o tempo levado para que as pessoas respondam o formulário. Conforme citado no trabalho de Ghimire (2012, p. 3), um questionário aplicado em um restaurante em Sagarmatha, possuía 17 questões, o qual teve um tempo médio para responder de 5 a 10 minutos. Esse tempo pode ser ainda maior dependendo do tipo de negócio e os tipos de perguntas que integram o questionário.
2.3. MARKETING DE RELACIONAMENTO
Segundo Torres e Fonseca (2012, p. 4), “O marketing de relacionamento busca envolver e atrair os clientes nas diversas fases de criação de valor, buscando inovação”, ou seja, é a comunicação entre a empresa e o consumidor.
O marketing de relacionamento é a tarefa de fazer com que os consumidores se tornem leais à marca. Um dos requisitos para completar essa tarefa é compreender as necessidades e desejos dos clientes. Porém, nem sempre é fácil, pois “alguns consumidores têm necessidades das quais não têm plena consciência. Ou não conseguem articular essas necessidades. Ou então empregam palavras que exigem alguma interpretação.” (KOTLER, 2000, p.43).
Para que se possa compreender as necessidades dos clientes é necessário que as empresas os conheçam, descubram o que eles pensam, tenham como foco também o cliente e não apenas o produto. “Somente empresas centradas nos clientes são verdadeiramente capazes de construir clientes, e não apenas produtos, e são hábeis em engenharia de mercados, não apenas em engenharia de produtos.” (KOTLER, 2000, p.56).
Kotler (1998, apud TORRES, FONSECA, 2012, p. 4) ainda define que existem cinco níveis de marketing de produtos (ou serviços):
Marketing básico: o vendedor vende o produto;
Marketing reativo: o vendedor vende o produto e estimula o consumidor entrar em contato em caso de dúvidas, reclamações, etc;
Marketing responsável: após a venda, o vendedor entra em contato com o cliente para verificar seu feedback;
Marketing proativo: o vendedor contata o cliente de vez em quando para dar dicas de uso do produto e/ou informar sobre novos produtos; e
Marketing de parceria: a empresa trabalha em parceria continua com o consumidor a fim de descobrir maneiras dele economizar ou utilizar de maneira mais eficiente o produto.
A Figura 4 ilustra o conceito principal dos cinco níveis de marketing, apresentando como deve ser o ciclo ideal de um produto ou serviço.
Figura 4 - Ciclo ideal de um produto ou serviço em uma empresa. Adaptado de: Wikipédia, C. (2016)
Nos dias de hoje, as organizações buscam relacionar-se com os seus clientes de forma a querer ser parte de suas famílias, tornando assim esse relacionamento a principal maneira de sobreviver no mercado. Para que isso se realize, as empresas empregam diferentes táticas, conforme diz Iamarino (2015, 3:45 min):
“Muitas empresas contam histórias de como foram fundadas ou de quais são seus ideais, para que os consumidores os considerem como amigas ou familiares. Assim são tratadas pelos clientes e pelos empregados com normas sociais e não de mercado, conquistando assim a lealdade de seus clientes e tem muito mais chances de terem pequenas falhas perdoadas ou de terem funcionários trabalhando até mais tarde”.
O marketing de relacionamento está ligado à satisfação do consumidor, conforme Torres e Fonseca (2012, p. 3) explicam: “No marketing de relacionamento, as empresas buscam satisfazer as necessidades de seus consumidores, ofertando produtos e/ou serviços de qualidade e criando valor para os clientes, buscando fidelizá-los”. Desse modo, o relacionamento entre a empresa e o consumidor é de extrema importância para obtenção do sucesso comercial.
3 MATERIAIS E MÉTODOS
Essa seção tem por finalidade apresentar os materiais e os métodos que foram utilizados para a realização desse trabalho. A subseção “materiais” especifica as tecnologias utilizadas, mais especificamente as ferramentas de desenvolvimento e modelagem, linguagens de programação e frameworks. Por fim, a subseção métodos corresponde aos procedimentos adotados para a construção do sistema, elaboração do questionário e testes de campo.
3.1. MATERIAIS
Para a elaboração do sistema foram necessárias as seguintes ferramentas: Visual Paradigm Community Edition para modelagem UML (Unified
Modeling Language) do sistema;
MongoDB. Banco de dados NoSQL orientado a documentos para armazenamento dos dados;
DbSchema Trial Version para modelagem do banco de dados; Robomongo para gerenciamento do banco de dados;
Linguagem de programação TypeScript com HTML (Hypertext Markup Language) e CSS (Cascading Style Sheets) para implementação de back-end e front-back-end;
Frameworks Meteor 1.4 e Angular 2 para construção do sistema em “tempo real”2 com o padrão de desenvolvimento MVC (Model View Controller);
2 No meio web, tempo real quer dizer comunicação imediata entre cliente e servidor,
propagação de atualizações são feitas de forma transparente para o usuário. Ver WebRTC (W3C, 2016), disponível em: https://www.w3.org/TR/webrtc/.
JetBrains WebStorm como IDE (Integrated Development Environment)
como ambiente de programação; NodeJS como servidor web;
Adobe PhoneGap para criação do aplicativo Android utilizando JavaScript, HTML e CSS;
Android Emulator para emular um dispositivo Android; GIT para controle de versão de códigos fontes; e GitKraken: Interface gráfica para o GIT.
As tecnologias citadas quando utilizadas em conjunto possibilitam a criação de aplicações web e mobile ricas, de “tempo real” e multiplataforma. A Figura 5 mostra como as tecnologias responsáveis pela execução do sistema interagem entre si.
3.1.1. Visual Paradigm Community Edition
O Visual Paradigm (VISUAL ..., W, 2016) é uma ferramenta de modelagem UML (2.0+) e banco de dados relacional completa para sistemas orientados a objetos. Ela é uma das ferramentas de modelagem mais conhecidas do mercado, sendo uma forte concorrente do Rational Software Architect Designer3
Essa ferramenta possui a versão paga (todas as funcionalidades liberadas) e a comunitária (apenas funcionalidades básicas). A versão paga é capaz de gerar código Java e C++ a partir de diagramas, gerar diagramas a partir de código, gerar SQL (Structured Query Language) para criação do banco de dados ou criar o diagrama ER (entidade-relacionamento) a partir dele. Já a versão comunitária permite apenas a modelagem dos diagramas sem geração automática de código.
Para a realização desse foi utilizada a versão comunitária, pois não há necessidade de utilização de funcionalidades avançadas que estão presentes na versão paga. A escolha dessa ferramenta se deve aos seguintes fatores:
O autor possui bastante conhecimento e fluência na utilização da ferramenta quando comparada a outras (Astah, ArgoUML, Rational Rose, etc);
Qualidade e funcionalidades da ferramenta é superior a algumas das demais ferramentas disponíveis; e
Disponibilidade para Linux.
3.1.2. MongoDB
O MongoDB é um banco de dados NoSQL orientado a documentos, gratuito e de código aberto em sua versão comunitária, sendo licenciado sob a licenças GNU
3 Para mais informações sobre o Rational Software Architect Designer, acesse:
Affero General Public License e Apache. Sua utilização para aplicações comerciais é permitida, sendo atualmente o 4º banco de dados mais utilizado do mundo (DB-ENGINES, 2016).
Por se tratar de um banco de dados NoSQL e não relacional, sua estrutura é definida por coleções (tabelas em um banco de dado relacional) e documentos (registros em um RDB). A estrutura do documento é definida utilizando JSON e esse não possui um schema fixo, podendo variar de documento para documento em uma mesma coleção, cabendo à aplicação tratar essas diferenças ou garantir um schema padrão para cada coleção.
No MongoDB podem existir relacionamentos entre coleções. Contudo, o MongoDB não garante a integridade dos dados nas relações, ou seja, a aplicação tem por obrigação manter essa integridade. Apesar de parecer um tanto quanto inconveniente, quando comparado a um banco de dados relacional, suas qualidades como performance, escalabilidade e schema dinâmico podem trazer mais benefícios do que prejuízos.
A shell do MongoDB faz uso do JavaScript para realizar as operações de banco de dados (operações CRUD), tornando assim a integração com o framework Meteor mais fácil e transparente. Além do shell, a utilização do JavaScript também é feita nos documentos, por meio do uso do JSON, conforme citado anteriormente. Um exemplo de documento pode ser visto na Figura 6:
//Coleção “editoras” {
_id: "68FWFNGRAuRt82pWy", nome: "O'Reilly Media", fundacao: 1980, localizacao: "CA" } //Coleção “livros” { _id: “54c764b051f7ea00b48309b9”, titulo: "MongoDB: The Definitive Guide", autor: [ "Kristina Chodorow", "Mike Dirolf" ], data_publicacao: ISODate("2010-09-24"), paginas: 216,
idioma: "English",
editora_id: "68FWFNGRAuRt82pWy" //Referência manual à “editora” }
Figura 6 - Exemplo de documentos armazenados no MongoDB com relacionamentos. Adaptado de:
No framework Meteor, o MongoDB é o banco de dados padrão e único suportado oficialmente4 até o momento (versão 1.3 do framework Meteor), desse
modo tornando quase que obrigatório sua utilização. Outros aspectos que foram levados em consideração para a utilização do MongoDB são:
Performance. Leitura e escrita de dados são extremamente rápidas quando comparadas a um banco relacional, podendo ser 15 vezes mais rápido que um banco relacional tradicional (Oracle) (Boicea, Radulescu e Agapin, 2012); e
Escalabilidade. O MongoDB é escalável horizontalmente, permitindo que múltiplas instâncias de um mesmo banco executem paralelamente em diferentes servidores mantendo a integridade de dados entre eles. (MONGODB, 2016);
Schema dinâmico. Com o schema dinâmico é possível efetuar alterações na estrutura das coleções/documentos sem ocorrer problemas ou necessidade de atualizações de documentos antigos.
3.1.3. DBSchema
DBSchema “é uma ferramenta orientada a diagramas para banco de dados, compatível com todos os bancos de dados relacionais, MongoDB e Cassandra” (DBSCHEMA, 2016). A ferramenta ainda permite a criação de diagramas interativos que podem ser abertos em qualquer navegador, permitido consultar a documentação de cada item no diagrama.
Essa ferramenta foi utilizada para a modelagem do schema do banco de dados. Apesar do MongoDB possuir schema fixo, isso não significa que ele não o possui.
4Pacotes e drivers de terceiros permitem a utilização de outros bancos de dados, inclusive
A escolha dessa ferramenta se deve ao fato do autor desse trabalho desconhecer a existência de outras ferramentas de modelagem de banco de dados, que deem suporte à modelagem de bancos de dados orientado a documentos. Também se deve ao fato que uma modelagem de um banco de dados é muito importante para a criação de aplicações de qualidade.
3.1.4. Robomongo
Robomongo é uma ferramenta de administração multiplataforma para o banco de dados NoSQL MongoDB. Essa ferramenta é a única que incorpora a shell do MongoDB (ROBOMONGO, 2016), garantindo assim a precisão dos comandos e consultas efetuadas.
O Robomongo foi escolhido como ferramenta para administração do banco de dados, pois além de fornecer uma shell precisa, ela é multiplataforma, código aberto e gratuita. Existem outras opções como Mongobird (licença comercial paga) e Mongoclient (licença comercial gratuita). Contudo, a simplicidade faz do Robomongo uma ótima escolha.
3.1.5. TypeScript
TypeScript é uma linguagem de programação de código aberto para desenvolvimento de aplicações JavaScript em larga escala. Criada e mantida pela Microsoft, o TypeScript foi “projetado para atender as necessidades das equipes de programação JavaScript que constroem e mantém grandes aplicações JavaScript” (MICROSOFT, capítulo 1).
A linguagem adiciona uma nova sintaxe de programação JavaScript que é compatível com a nova especificação ECMAScript 20155 (ES6). A especificação ES6
5 A especificação completa do ECMAScript 2015, está disponível em:
adiciona alguns recursos ao JavaScript comum como classes, módulos, promise (processamento assíncrono), entre outros. Contudo, por ser um padrão muito recente, muitos navegadores e plataformas não o seguem. O TypeScript nos permite escrever código que segue os mais novos padrões do ECMAScript (ES6, ES7 – Candidate –, ES8 – Draft), veja Figura 7, e gerar código JavaScript válido em padrões mais antigos, como ES5 e ES3, esse processo é chamado de transpile (transpilação – gerar código fonte a partir de outro código fonte).
Figura 7 - TypeScript é um supertipo do JavaScript Fonte: SYED, 2016
Após realizado o processo de transpilação, o código fonte final gerado é JavaScript puro que pode ser executado em qualquer plataforma (navegadores, NodeJs, etc.), com os recursos das especificações mais recentes. Para isso, o transpiler do TypeScript faz usa bibliotecas já existentes (como requireJS) e outros métodos, como geração de alguns metadados no caso dos Decorators (ES7).
Além dos recursos especificados pela ECMAScript, o TypeScript adiciona alguns itens extras em sua sintaxe: tipagem estática, classes e métodos abstratos, encapsulamento e interfaces. Essas sintaxes extras do TypeScript não são obrigatórias, pois “qualquer código JavaScript é código TypeScript”. Contudo, sua utilização traz inúmeros benefícios como melhor suporte de IDEs e códigos mais concisos e menos propícios a erros, pois toda a verificação é feita em tempo de transpilação. Desse modo, utilizar TypeScript se faz muito importante para aplicações de médio e grande porte devido aos inúmeros benefícios citados anteriormente.
3.1.6. Framework Meteor
O framework Meteor “é uma plataforma JavaScript full-stack para desenvolvimento de aplicações web e mobile modernas” (METEOR ..., Introduction, 2016). Lançado inicialmente em 2012, com um financiamento superior a US$ 20 milhões (SCHMIDT, 2015), é um dos frameworks JavaScript gratuitos e de código aberto mais populares atualmente.
O Meteor tem por base o Node.js e o padrão de arquitetura MVC, nos entregando um ambiente de desenvolvimento completo para desenvolvimento multiplataforma. Algumas características são (METEOR ..., Introduction, 2016):
Integração nativa com o MongoDB;
Propagação em “tempo real” de alterações no banco de dados para os clientes, ou seja, os dados que estão no cliente são os mesmos que estão no servidor;
Programação assíncrona garante uma boa experiência para o usuário, pois atividades que demandam tempo para processar não bloqueiam o usuário de prosseguir; e
Utiliza o processamento do cliente para renderizar as páginas, ou seja, o servidor não envia HTML pré-processado, mas dados para que o cliente os renderize.
Como citado anteriormente, uma das características do Meteor é a propagação das alterações dos dados para todos os clientes, evitando a necessidades de atualizações manuais das páginas pelo usuário. Para efetuar essa sincronização de dados e permitir a chamada de métodos do cliente para o servidor, foi desenvolvido o protocolo DDP (Distributed Data Protocol) (DDP ..., 2014). O protocolo DDP usa de WebSockets para conseguir uma “comunicação de duas vias entre um cliente executando código não confiável em um ambiente controlado e um servidor (host)” (RFC 6455, 2011).
No lado cliente, o Meteor usa de um framework front-end próprio chamado Blaze, que nos provê uma série de funcionalidades para construir uma interface reativa para interação do usuário (METEOR ..., Blaze, 2016). Contudo é possível substituí-lo por outro framework, como por exemplo o AngularJS. Além de navegadores uma aplicação escrita no Meteor, pode executar em dispositivos móveis com Android ou iOS por meio do Phonegap (será explicado mais adiante). A Figura 8 nos mostra a arquitetura da plataforma Meteor.
Figura 8 - Arquitetura da plataforma Meteor. Fonte: What is Meteor.js? (OWENS, 2014)
O principal motivo para a escolha do Meteor é sua característica de ser multiplataforma, nos permitindo criar uma única aplicação para diferentes dispositivos, incluindo dispositivos móveis (Android e IOS). Outro fator relevante é a característica de utilizarmos apenas JavaScript, HTML e CSS para desenvolver uma aplicação completa e de alto nível. E, por último, é a facilidade que temos em desenvolver uma aplicação com ele, pois além de encapsular toda a parte de rede, usuários e configurações, podemos utilizar diversas ferramentas de terceiros para auxiliar no desenvolvimento devido à compatibilidade com os pacotes do Node.js.
3.1.7. Framework Angular
O Angular é um framework front-end JavaScript e de código-aberto, desenvolvido e mantido pela Google, com sua última versão estável 1.5.8 e versão Beta 2.1.1 (GOOGLE ..., 2016). Utilizado para desenvolver interfaces gráficas ricas para sistemas web utilizando apenas JavaScript/TypeScript/Dart, HTML e CSS.
A grande característica que faz o diferencial desse framework para a programação padrão é que a aplicação como um todo possui, para o navegador, apenas uma única página. A troca do conteúdo é realizada de forma dinâmica por meio de JavaScript e o interpretador de templates do Angular efetua a tarefa de alterar o DOM e colocar o novo conteúdo em formato HTML compreendido pelo navegador.
Outra característica interessante é que o Angular trabalha com um sistema de templates, que utiliza basicamente HTML, tags customizadas e um controlador. Esse conjunto é chamado de componentes e são o ponto chave do framework, pois permitem a reutilização de código/telas e a criação de componentes customizados. Em cada componente é possível efetuar uma ligação de dados de entrada (ex.: campos de formulário) e saída (ex.: tabelas de dados), com variáveis em JavaScript. (ANGULAR, 2016).
A utilização do framework Angular em conjunto com o Meteor faz-se por meio do pacote angular-meteor (GOLDSHTEIN, 2015). Esse pacote tem por objetivo efetuar a integração entre o Angular e o Meteor, deixando sua utilização transparente para o programador. Isto é, sem a necessidade de efetuar diversas configurações manuais.
Conforme visto anteriormente, o Meteor por padrão possui o Blaze como framework front-end com possibilidade de substituição. Para tal substituição foi escolhido a versão 2 do framework do Angular, pois esse trabalha com TypeScript (veja a seção 3.1.5) e a versão 1.x está em processo de obsolescência. Como o Angular é mais conhecido e mantido por uma das maiores empresas do setor de TI (Tecnologia da Informação) do mundo (Alphabet/Google), e juntamente com suas características, a escolha desse framework ao invés do Blaze, garantirá a construção
de uma aplicação sólida e robusta além de uma melhor integração com dispositivos móveis (Phonegap/Cordova).
3.1.8. WebStorm
O WebStorm é uma IDE (do inglês Integrated Development Environment) JavaScript desenvolvida pela JetBrains. Segundo sua desenvolvedora, esta é “a IDE JavaScript mais inteligente” (JETBRAINS, 2016), com o melhor e mais completo suporte à programação em JavaScript e seus frameworks.
Algumas características dessa ferramenta (JETBRAINS, 2016): Assistente de programação inteligente;
Compatibilidade total com os frameworks Meteor e AngularJS; Integrado com controle de versão GIT; e
Depuração e testes de código de maneira fácil e eficiente.
O motivo principal para escolha dessa IDE se deve ao fator de nenhuma outra IDE multiplataforma possuí as características citadas anteriormente. Apesar de ser uma IDE principalmente paga, é possível utiliza-la gratuitamente desde que para fins acadêmicos.
3.1.9. Adobe Phonegap
O framework Adobe Phonegap é uma distribuição de código aberto do Cordova, cujo principal objetivo é permitir a criação de aplicações para dispositivos móveis utilizando apenas HTML, CSS e JavaScript. (ADOBE ..., 2016). Com ele é possível criar aplicativos para Android, iOS e Windows Phone, com apenas uma única versão do seu aplicativo sem precisar se preocupar com as características específicas de cada plataforma.
Atualmente o HTML5 permite que as aplicações acessem recursos de hardware, como por exemplo câmera e GPS, de forma direta. Contudo, em versões mais antigas dos sistemas dos dispositivos móveis não dão suporte ao acesso nativo pelo HTML5. Desse modo, o Phonegap inclui funções que permitem o acesso nativo a esses recursos (INTEL, 2012). A Figura 9 mostra os recursos de hardware dos dispositivos que funcionam com o Phonegap para 9 sistemas operacionais.
Figura 9 - Recursos dos dispositivos compatíveis com Phonegap. Fonte: Adobe Phonegap (2016)
Apesar do grande suporte à maioria dos dispositivos atuais e a possibilidade de aceleração por hardware, as aplicações desenvolvidas podem ficar mais lentas do que as nativas (DIWAKAR, 2012). Contudo, isso nem sempre ocorre, garantindo uma boa escolha para criação de aplicações multiplataforma.
Normalmente para criar uma aplicação utilizando o Phonegap é necessário instalar sua SKD6. Contudo, o framework do Meteor já efetua essa integração,
necessitando apenas ativá-la. Após ativado, conforme a documentação orienta7, a
aplicação desenvolvida no Meteor está pronta para executar no dispositivo escolhido. Desse modo, devido à excelente integração com o framework do Meteor, podemos construir uma única aplicação que seja compatível tanto com dispositivos móveis como com desktops/browsers. Com isso, reduzimos o tempo de desenvolvimento e melhoramos a manutenibilidade da aplicação desenvolvida, uma vez que possuímos apenas um único código fonte.
3.2. MÉTODOS
O objetivo dessa seção é apresentar a metodologia que foi utilizada para a realização concreta desse trabalho, apresentando de forma detalhada os procedimentos e métodos de desenvolvimento utilizados. Desse modo, permitimos uma melhor compreensão e entendimento do trabalho realizado e os passos adotados.
As principais fases no desenvolvimento desse projeto foram: revisão das tecnologias utilizadas (tutoriais e leitura de documentação), análise e levantamento de requisitos, projeto arquitetural do sistema e, por fim, sua implementação.
3.2.1. Processo de Desenvolvimento do Software
Para o desenvolvimento do sistema optou-se por utilizar o método iterativo e incremental conhecido como Processo Unificado. O Processo Unificado é um dos mais utilizados no desenvolvimento de sistemas, tendo por objetivo combater as
6 Tutorial de instalação e configuração disponível em:
http://docs.phonegap.com/getting-started/1-install-phonegap/desktop/
7 Tutorial disponível em:
fraquezas do método mais tradicional conhecido como “modelo em cascata” (WIKIPÉDIA, I. ..., 2016). A Figura 10 demonstra as fases do desenvolvimento do Processo Unificado.
Figura 10 - Fases do Processo Unificado. Fonte: PARMIGIANI JÚNIOR, Ednei (2014)
Por se tratar de um processo iterativo e incremental, o processo unificado gera, a cada iteração, um componente (parte ou módulo), que pode ser testada e implantada. Desse modo, é possível encontrar os prováveis problemas (desde bugs de código a erros de análise), permitindo uma rápida correção desses problemas sem que afetem outras partes do sistema.
4 DESENVOLVIMENTO
O desenvolvimento de um sistema é o “processo de definir, desenhar, testar e implementar um novo software ou programa” (FCA, 2007, p. 3). Assim, esta seção apresenta como o sistema proposto foi desenvolvido.
Esta seção possui três subseções: Análise e levantamento de requisitos, Projeto de Negócio e Projeto Lógico (Arquitetura de sistema). A primeira possui foco na obtenção e especificação de requisitos, regras de negócio e definições de prioridades. A segunda apresenta as funcionalidades em um alto nível (exemplo: casos de uso). A terceira e mais extensa foca a implementação, com diagramas de baixo nível que apresentarão a estrutura interna do sistema, escolhas de arquiteturas, padrões de projeto e suas motivações.
4.1. ANÁLISE E LEVANTAMENTO DE REQUISITOS
Análise e levantamento de requisitos é “o processo de estudar um procedimento ou negócio a fim de identificar suas metas e propósitos e criar sistemas e procedimentos que irão alcançá-los de forma eficiente” (MERRIAN-WEBSTER, 2016, system analisys).
No processo de análise e levantamento de requisitos foi efetuado análise com base nos mais diversos ramos de negócio, porém com foco principal em restaurantes e lojas de conveniência. Esse processo teve como o objetivo de identificar requisitos funcionais e não-funcionais de modo mais genérico, ou seja, que fossem comuns aos diversos ramos de negócio, não sendo desse modo específico a um modelo. Em seguida, os requisitos são classificados, verificados suas referências cruzadas (dependências entre requisitos) e suas prioridades.
4.1.1. Requisitos funcionais
Segundo Pressman e Maxim (2007, p. 80), requisitos funcionais são “declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais podem também estabelecer explicitamente que o sistema não deve fazer”.
A seguir encontra-se uma lista com os requisitos funcionais levantados a partir da análise do negócio.
RF1. O sistema deverá possuir um banco de questões públicas que podem ser utilizados por qualquer empresa para elaborar seus questionários. RF2. O sistema deverá permitir que cada empresa mantenha seu próprio banco de questões, as quais serão privadas e visíveis apenas para ela.
RF3. O sistema deverá permitir que cada empresa mantenha um banco de questionários.
RF4. O sistema deverá possuir uma página que mostre a lista de questões públicas e privadas disponíveis.
RF5. O sistema deverá possuir uma listagem de questionários públicos e privados disponíveis.
RF6. Deverá ser construído uma tela de execução (aplicação) de questionários, a qual tem o objetivo de realizar a aplicação de questionários e coletar as respectivas respostas para gerar relatórios. a. A tela de execução de questionários deverá ter a navegação para outras telas bloqueadas com senha, a fim de evitar que o usuário que está respondendo o questionário saia da tela.
RF7. A empresa deve realizar seu cadastro (formulário de registro) e criar um usuário administrador para a empresa.
RF8. Deverá ser possível que a empresa possa escolher e trocar o seu plano de assinatura por meio de uma tela de seleção de planos. RF9. O sistema deve permitir que a empresa efetue o cadastro de
funcionários, criando usuários que possam efetuar a aplicação dos questionários.
RF10. O sistema deverá possuir um subsistema de controle de acesso (login, autorização, usuário e auditoria).
RF11. O sistema deverá possuir um banco de questionários públicos que possam ser utilizados por qualquer empresa.
RF12. O sistema deverá manter um cadastro de categorias para questões e questionários que são visíveis e utilizáveis por todas as empresas. RF13. O sistema de deverá possuir um subsistema de roteamento de
páginas.
a. Responsável por verificar junto ao subsistema de controle de acesso se o usuário está autorizado a acessar determinada página.
b. Responsável por verificar se não existe pendências de configuração no sistema antes da empresa poder utilizar o sistema (exemplo: dados da empresa não informados, plano de assinatura não escolhido, etc).
RF14. O sistema deve gerar relatórios, quando solicitado, para os questionários respondidos.
RF15. Deverá existir um sistema de metas no qual permita as empresas definirem metas para questionários.
4.1.2. Requisitos não funcionais
Segundo Pearson requisitos não funcionais são “restrições sobre os serviços ou funções oferecidas pelo sistema. Eles incluem restrições de timing, restrições sobre o processo de desenvolvimento e padrões.” (PRESMAN; MIXIM, 2007).
A seguir encontra-se uma lista com os requisitos não-funcionais levantados a partir da análise do negócio, sendo esses divididos por regras de negócio e requisitos suplementares.
4.1.2.1. Regras de negócio
RN1. Somente usuários administradores ou gerentes podem construir ou editar questionário e questões.
RN2. Os questionários poderão ser aplicados por usuários que possuam permissão superior à de “Funcionário”.
RN3. As questões poderão ser apenas dos seguintes tipos: classificação, múltipla resposta, única resposta ou caixa de texto.
a. As questões de escolha poderão conter no máximo 7 e no mínimo 2 alternativas.
RN4. O cadastro de funcionários somente poderá ser realizado por um usuário administrador.
RN5. Questionários deverão ser dinâmicos, ou seja, a escolha da próxima pergunta poderá depender da resposta da pergunta atual.
RN6. Os questionários deverão possuir ao menos uma pergunta e não haverá limite.
RN7. A construção de questionários deverá ser validada a fim de evitar que ocorram loops infinitos durante sua aplicação.
RN8. As questões e questionários poderão ser públicas ou privada, sendo as privadas visíveis apenas para a empresa que as criou.
RN9. As questões deverão ser categorizadas e poderão possuir uma ou mais categorias. Por meios das categorias é possível separar as questões em grupos, conforme sua finalidade, melhorando as buscas posteriormente.
RN10. Questionários deverão ser categorizados com apenas uma categoria por questionário, as quais serão abrangentes com o objetivo de facilitar a busca de questionários.
RN11. As categorias de questionários e questões deverão ser pré-cadastradas e o usuário não pode adicionar suas próprias categorias ou alterar as existentes.
RN12. Relatórios podem ser gerados e visualizados por usuários com permissão igual ou superior à de gerente.
a. O relatório mais básico deve mostrar apenas as porcentagens para cada resposta; e
b. Relatórios avançados devem exibir uma melhor avaliação, exibindo pontos que podem ser melhorados.
RN13. Os planos de assinatura para utilização do sistema serão: grátis, starter, pro, ultimate.
RN14. O sistema deverá manter um log (auditoria) das atividades realizadas pelos usuários.
RN15. Os usuários do sistema possuirão os níveis de permissão:
a. Funcionário: garante a permissão de aplicar questionários; b. Gerente: garante todas as permissões de funcionário,
permissão de manutenção de questionários, questões, metas e geração de relatórios; e
c. Administrador: garante permissão todas as permissões de gerente e as permissões de efetuar manutenção de
funcionários, dados cadastrais da empresa e escolha do plano de assinatura.
RN16. As questões após utilizadas em um formulário, não poderão ter o seu tipo e o número de alternativas editados, apenas as descrições. RN17. A edição do número de questões e ordem de execução das questões
de um questionário somente poderão ser realizadas em questionários que ainda não possuem respostas coletadas.
RN18. As metas somente podem ser criadas por usuários que possuam permissão de gerente ou superior. O sistema de metas deverá possuir:
a. Data de início e fim, ou seja, o período que essa meta estará ativa;
b. Um registro de qual usuário criou a meta; e
c. Número de respostas desejadas para o questionário definido na meta.
4.1.2.2. Suplementares
SP1. O sistema construído deverá ser compatível com desktop e mobile (cross platform) a fim de garantir melhor experiência para o usuário. SP2. Todo e qualquer usuário do sistema deverá ler e aceitar os termos de
uso e a política de privacidade do sistema antes que possa usufruir do sistema.
SP3. Usabilidade: o sistema deve ser fácil e intuitivo de modo que o usuário não precise de treinamento especializado.
SP4. Relatórios gerados poderão ser exportados para planilhas CSV (Comma-separetd values).
4.1.3. Classificação dos requisitos funcionais
Nessa subseção classificamos os requisitos levantados na seção 4.1.1 em requisitos evidentes ou ocultos e se é um requisito obrigatório ou desejado. Veja Tabela 1.
Requisitos do tipo evidente são “funções efetuadas com o conhecimento do usuário“ (GOMES, 2013 slide 15). Já requisitos ocultos são “cálculos ou atualizações feitas pelo sistema sem a solicitação explícita do usuário” (GOMES, 2013 slide 15).
Requisitos obrigatórios devem estar presentes no sistema para sua implantação em produção. Requisitos desejados não precisam estar implementados no sistema para seu uso. Contudo, sua implementação garante um diferencial e melhoria na experiência.
Tabela 1 - Classificação dos requisitos funcionais.
Requisito Evidente Oculto Obrigatório Desejado
RF1 X X RF2 X X RF3 X X RF4 X X RF5 X X RF6 X X RF7 X X RF8 X X RF9 X X RF10 X X RF11 X X RF12 X X RF13 X X RF14 X X RF15 X X
4.1.4. Referências cruzadas (dependências entre requisitos)
A Tabela 2 apresenta os requisitos e suas dependências, permitindo que se identifique a ordem e as prioridades de implementação.
Tabela 2 - Referências cruzadas (dependências entre requisitos).
Requisito Dependência Regra de negócio
RF1 N/A RN8, RN9 RF2 RF7, RF10 RN3, RN8, RN16 RF3 RF7, RF10 RN1, RN5, RN6, RN7, RN8, RN10, RN17 RF4 RF1, RF2, RF10 RF5 RF3, RF10, RF11 RF6 RF3, RF10, RF11 RN2 RF7 RF8, RF10 RN13 RF8 RF10 RN13 RF9 RF7, RF10 RN4 RF10 N/A RN14, RN15 RF11 N/A RN5, RN6, RN8, RN10 RF12 N/A RN9, RF13 N/A N/A RF14 RF6 RN12 RF15 RF3
4.2. PROJETO DE NEGÓCIO
Esta seção apresenta e documenta as funcionalidades do sistema em alto nível, não apresentando seus detalhes de implementação. Aqui são apresentados alguns diagramas com notações simples que podem ser facilmente compreendidas e demonstram melhor o funcionamento lógico (processo de negócio) do sistema.
Esta seção apresenta os seguintes diagramas e descrições: Modelo conceitual, diagrama de casos de uso geral, diagramas de casos de uso por pacote, descrição de casos de uso principais e diagramas de atividades para casos de uso documentados.
4.2.1. Diagrama de casos de uso geral
Diagramas de casos de uso ilustram uma unidade de funcionalidade proporcionada pelo sistema, tendo como objetivo principal “auxiliar equipes de desenvolvimento visualizar os requisitos funcionais de um sistema, incluindo a relação
