TCC Exemplo Assistência Chamados

FACULDADE DE TECNOLOGIA DO IPIRANGA
CURSO DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

CAIO ZUCOLI BADARÓ
EDSON SOARES DA ROCHA
SUPORTE WEB:
Sistema de gestão de chamados oferecido como serviço
SÃO PAULO
2016
FACULDADE DE TECNOLOGIA DO IPIRANGA
CURSO DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
CAIO ZUCOLI BADARÓ
SUPORTE WEB:
Trabalho de Conclusão de Curso

apresentado à Faculdade de Tecnologia
do Ipiranga, como requisito parcial para a
obtenção do grau de Tecnólogo em
Análise e Desenvolvimento de Sistemas.
Orientador: Prof. Me. Antônio Fernando

Nunes Guardado
SÃO PAULO
2016
BADARÓ, Caio Zucoli; DA ROCHA, Edson Soares.
Sistema de gestão de chamados oferecido como serviço/Caio Zucoli
Badaró; Edson Soares da Rocha; orientador: Professor Mestre Antônio
Fernando Nunes Guardado – São Paulo, 2016
133 f.
Monografia (Graduação) – Faculdade de Tecnologia do Ipiranga
1-Sistemas 2-Desenvolvimento – BADARÓ, Caio Zucoli; DA ROCHA, Edson
Soares.
Trad II – FATEC Ipiranga
CDU: ________
CAIO ZUCOLI BADARÓ
SUPORTE WEB:
Trabalho de Conclusão de Curso

apresentado à Faculdade de Tecnologia
do Ipiranga, como requisito parcial para a
obtenção do grau de Tecnólogo em
Análise e Desenvolvimento de Sistemas.
Data de aprovação:
Banca examinadora:
_____________________________________
Prof. Me. César Torres Fernandes
Presidente da Banca
____________________________________
Prof ª Dr ª Ana Cláudia M. Tiessi G. de Oliveira
Professora Convidada
____________________________________
Prof. Me. Antônio Fernando Nunes Guardado
Professor Orientador
SÃO PAULO
2016
AGRADECIMENTOS
A todos que colaboraram e nos proporcionaram as condições necessárias para o

desenvolvimento desse trabalho, de forma direta ou indireta. Em especial ao nosso
orientador Professor Mestre Antônio Fernando Nunes Guardado e às senhoras
Jéssica Yuri Ogata e Dóris Savoldi Camargo da Rocha por todas as sugestões e
opiniões que nos forneceram ao longo do desenvolvimento desse trabalho.
“O analfabeto do século XXI não será aquele que não consegue ler e escrever, mas
aquele que não consegue aprender, desaprender e reaprender”. Alvin Toffler
RESUMO
Diante de uma tendência mundial de desenvolvimento de software, onde aplicações

são fornecidas como serviços e visando uma necessidade de mercado para
aplicações de chamados técnicos, foi proposto o desenvolvimento de uma aplicação
de chamados, que fosse fornecida como serviço e que, ao mesmo tempo,
contivesse poucos campos de preenchimento pelos usuários. Essa necessidade foi
vivenciada na prática pelos autores, através de suas experiências profissionais. Com
o objetivo de realizar todo o processo de desenvolvimento de sistemas para a
criação de uma aplicação, foi realizada uma pesquisa exploratória, a respeito dos
temas descritos para maior embasamento teórico. No desenvolvimento dessa
aplicação, foram utilizados os conceitos definidos na metodologia ágil Scrum e o
padrão de desenvolvimento de três camadas Model View Controller. Com o uso
dessas ferramentas consolidadas na engenharia de software e no mercado,
manteve-se o foco no escopo inicial de criar uma aplicação visando a melhor
usabilidade para os usuários finais do sistema.
Palavras-chave: Chamados Técnicos. Ordens de Serviço. Gestão de Chamados.

SaaS.
ABSTRACT
Before a global trend of software development, which applications are provided as

services and aiming a market need for technical support of ticket applications, it has
been proposed the development of a technical support ticket application provided as
a service and at the same time contained just a few fields that needed to be filled by
its users. This need was pratical experienced by the authors through their own
professional experiences. In order to accomplish all the system development process
in the creation of an application, it has been made an exploratory research about the
themes described for more theoretical basis. In the development of this application
were used concepts defined in the agile methodology Scrum and three layers Model
View Controller design pattern. With the use of these consolidated tools of software
engineering and the market, it has maintained its focus on the initial scope of creating
an application seeking the best usability for end users of the system.
Keywords: Technical Support Tickets. Service Order. Tickets Management. SaaS

LISTA DE FIGURAS
Figura 1 - Benchmarks de SGBDs com 1.000 registros ............................................ 20

Figura 2 - Benchmarks de SGBDs com 10.000 registros .......................................... 21
Figura 3 - Fluxo de dados de negócio ....................................................................... 32
Figura 4 - Diagrama de casos de uso ....................................................................... 33
Figura 5 - Protótipo de tela – Abrir chamado ............................................................. 35
Figura 6 – Protótipo de tela – Consultar chamados do usuário ................................. 37
Figura 7 – Protótipo de tela – Consultar todos os chamados .................................... 39
Figura 8 – Protótipo de tela – Atender chamado ....................................................... 41
Figura 9 – Protótipo de tela – Escalar chamado........................................................ 43
Figura 10 – Protótipo de tela – Aprovar soluções...................................................... 45
Figura 11 – Protótipo de tela – Gerenciar usuários ................................................... 47
Figura 12 – Protótipo de tela – Gerenciar empresa................................................... 49
Figura 13 - Diagrama de classes de negócio ............................................................ 51
Figura 14 - Diagrama de classes de Projeto ............................................................. 52
Figura 19 - Diagrama de implantação ....................................................................... 57
Figura 20 – Abrir chamado – Diagrama de Classes .................................................. 58
Figura 21 – Abrir chamado – Diagrama de Sequência .............................................. 59
Figura 22 – Atender chamado – Diagrama de Classes ............................................. 60
Figura 23 – Atender chamado – Diagrama de Sequência ......................................... 61
Figura 24 – Consultar chamados do usuário – Diagrama de Classes ....................... 62
Figura 25 – Consultar chamados do usuário – Diagrama de Sequência .................. 63
Figura 26 – Consultar todos os chamados – Diagrama de Classes .......................... 64
Figura 27 – Consultar todos os chamados – Diagrama de Sequência...................... 65
Figura 28 – Gerenciar usuários – Diagrama de Classes ........................................... 66
Figura 29 – Gerenciar usuários – Diagrama de Sequência ....................................... 67
Figura 30 – Gerenciar empresa– Diagrama de Classes ........................................... 68
Figura 31 – Gerenciar empresa – Diagrama de Sequência ...................................... 69
Figura 32 – Escalar chamado – Diagrama de Classes ............................................. 70
Figura 33 – Escalar chamado – Diagrama de Sequência ......................................... 71
Figura 34 – Aprovar ou recusar soluções – Diagrama de Classes............................ 72
Figura 35 – Aprovar ou recusar soluções – Diagrama de Sequência ....................... 73
Figura 36 – Diagrama de atividades – Fluxo completo do sistema ........................... 74
Figura 37 – Diagrama de atividades – Atender chamado ......................................... 75
Figura 38 - Diagrama de estados – Status do chamado ........................................... 76
Figura 39 - Modelo lógico da base de dados ............................................................ 77
Figura 40 - Login de acesso ...................................................................................... 78
Figura 41 - Meu perfil ................................................................................................ 79
Figura 42 - Meus chamados ...................................................................................... 80
Figura 43 - Abrir chamado ......................................................................................... 81
Figura 44 - Lista de chamados .................................................................................. 82
Figura 45 – Chamados atendidos ............................................................................. 83
Figura 46 - Usuários (Gestão) ................................................................................... 84
Figura 47 - Assuntos ................................................................................................. 85
Figura 48 - Usuários (Administração) ........................................................................ 86
Figura 49 - Gestores ................................................................................................. 87
Figura 50 - Dados da empresa .................................................................................. 88
Figura 51 - Departamentos........................................................................................ 89
Figura 52 - Prioridades de chamados ....................................................................... 90
Figura 53 - Status de chamados ............................................................................... 91
Figura 54 - Tipos de chamados ................................................................................. 92
Figura 55 – Visão geral – Estatísticas – Gráfico 1..................................................... 93
LISTA DE TABELAS
Tabela 1 – Caso de uso – Abrir chamado ................................................................. 34

Tabela 2 – Caso de uso – Consultar chamados do usuário ...................................... 36
Tabela 3 – Caso de uso – Consultar todos os chamados ......................................... 38
Tabela 4 – Caso de uso – Atender chamado ............................................................ 40
Tabela 5 – Caso de uso – Escalar chamado ............................................................. 42
Tabela 6 – Caso de uso – Aprovar ou recusar soluções ........................................... 44
Tabela 7 – Caso de uso – Gerenciar Usuários.......................................................... 46
Tabela 8 – Caso de uso – Gerenciar empresa .......................................................... 48
Tabela 9 – Entrevistados ......................................................................................... 101
Tabela 10 – Questionário ........................................................................................ 102
LISTA DE ABREVIATUAS E SIGLAS
CEETEPS Centro Estadual de Educação Tecnológica Paula Souza

CMS Content Management Sistems
DaaS Database as a Service
HTML Hypertext Markup Language
IaaS Infrastructure as a Service
IBGE Instituto Brasileiro de Geografia e Estatística
MVC Model View Controller
PaaS Platform as a Service
PHP Hypertext Preprocessor
SaaS Software as a Service
SGBD Sistema Gerenciador de Banco de Dados
SQL Structured Query language
TI Tecnologia da Informação
TIC Tecnologia da Informação e Comunicação
UNESCO United Nations Educational, Scientific and Cultural Organization
SUMÁRIO
1 INTRODUÇÃO ....................................................................................................... 13
1.1 OBJETIVOS ........................................................................................................ 14

1.2 JUSTIFICATIVA E MOTIVAÇÕES .............................................................................. 15
1.3 MÉTODOS E TECNOLOGIAS .................................................................................. 15
2 TECNOLOGIAS PARA O DESENVOLVIMENTO WEB ......................................... 16
2.1 ARQUITETURA W EB ............................................................................................ 16

2.1.1 Linguagens executadas nos servidores .................................................... 17
2.1.2 Linguagens executadas nos clientes......................................................... 17
2.1.3 PHP – Hypertext Preprocessor ................................................................. 18
2.2 BANCO DE DADOS .............................................................................................. 19
2.2.1 MySQL ...................................................................................................... 19
2.3 ARQUITETURA EM NUVEM .................................................................................... 21
2.3.1 Software como serviço .............................................................................. 22
2.4 FRAMEWORK – CODEIGNITER .............................................................................. 23
3 REQUISITOS DO SISTEMA DE SOFTWARE ....................................................... 24
3.1 IDENTIFICAÇÃO DOS REQUISITOS .......................................................................... 24

3.1.1 Requisitos Funcionais ............................................................................... 24
3.1.2 Requisitos Não-Funcionais ....................................................................... 26
3.1.3 Regras de Negócio.................................................................................... 28
3.2 MODELAGEM DOS REQUISITOS FUNCIONAIS .......................................................... 31
3.2.1 Atores ........................................................................................................ 31
3.2.2 Diagrama de Caso de Uso ........................................................................ 33
3.2.3 Especificação do Caso de Uso ................................................................. 34
4 DESENVOLVIMENTO DO PROJETO ................................................................... 50
4.1 ANÁLISE ............................................................................................................ 50

4.1.1 Diagrama de Classes de Análise (Visão de Negócio) ............................... 50
4.2 PROJETO ........................................................................................................... 52
4.2.1 Diagrama de Classes de Projeto (Visão de Projeto) ................................. 52
4.2.2 Arquitetura do Sistema .............................................................................. 56
4.2.3 Diagrama de Classes de Projeto por Caso de Uso ................................... 58
4.2.4 Diagrama de atividades............................................................................. 74
4.2.5 Diagrama de estados ................................................................................ 76
4.2.6 Modelo Lógico da Base de Dados............................................................. 76
5 RESULTADOS OBTIDOS ...................................................................................... 78
6 CONSIDERAÇÕES FINAIS ................................................................................... 99
REFERÊNCIAS ....................................................................................................... 104
APÊNDICE A – PLANO E EXECUÇÃO DE TESTES ............................................. 106
APÊNDICE B – SPRINT BACKLOG 1 .................................................................... 129
APÊNDICE C – SPRINT BACKLOG 2 .................................................................... 130
APÊNDICE D – SPRINT BACKLOG 3 .................................................................... 131
APÊNDICE E – SPRINT BACKLOG 4 .................................................................... 132
APÊNDICE F – SPRINT BACKLOG 5 .................................................................... 133

13
1 INTRODUÇÃO
Atualmente, há uma demanda crescente por produtividade no mercado

corporativo como um todo e as empresas buscam cada vez mais soluções de
Tecnologia da Informação (T. I.) que facilitem o trabalho de seus funcionários,
reduzindo esforços, tempo e que se integrem com soluções já adquiridas.
Com o grande número de aplicações e uma diversidade muito grande de
fabricantes de softwares, em poucos casos existe uma integração entre as
aplicações utilizadas e as novas aquisições.
Esse fato, por si só, justifica a necessidade de se ter um time de T. I. dentro
das empresas, pois algum setor precisar ser responsável pela aquisição e/ou
implantação de novos sistemas na empresa e pela integração desses softwares não
só com as aplicações existentes, mas, segundo Azevedo Filho e Costa (2008), com
a cultura organizacional da empresa, para que todo esforço utilizado na implantação
de um novo sistema não seja perdido em um sistema em que os funcionários não
conseguiram se adaptar e utilizar em suas rotinas.
Para reduzir os custos com as implantações de novos sistemas e soluções e
principalmente com a gestão e manutenção dessas soluções, o mercado
corporativo, em geral, tem procurado novas soluções disponibilizadas em nuvem
(RAMALHO; PRADO, 2013)
Este conceito recente vem ganhando muita força de mercado, pois reduz
custos com infraestrutura de T. I. C. e reduz a carga de trabalho e os custos com
mão-de-obra dos departamentos de T. I. nas empresas, pois esses departamentos
deixam de administrar o sistema que passa a ser disponibilizado na nuvem por um
determinado fornecedor desse serviço, mais comumente conhecido como provedor.
Além disso, esse tipo de solução tem sido disponibilizada pelas empresas que
fornecem essas aplicações como serviços, gerando assim a fidelização das
empresas clientes, receitas mensais através das assinaturas das soluções ofertadas
por um período de tempo específico e principalmente a dependência da empresa
cliente pela empresa fornecedora do serviço, devido ao elevado nível de
adaptabilidade no qual o serviço pode sofrer de acordo com as necessidades das
empresas clientes (RAMALHO; PRADO, 2013).
14
Com o crescente número de aplicações que os usuários precisam se adaptar

e utilizar em seu dia-a-dia, seja em nuvem ou não, surge também a dificuldade para
utilizar alguma aplicação e também problemas de disponibilidade para algum serviço
oferecido que nem sempre é identificada por sistemas de alertas, cabendo ao
usuário final desses serviços relatar o problema vivenciado à equipe responsável da
empresa onde atua.
Nessa situação surge o novo problema, no qual a grande maioria das
ferramentas de abertura e gestão de chamados é realizada de maneira complexa
demais para esse tipo de usuário, devido a grande quantidade de informações
solicitadas e pela forma como as interfaces são organizadas.
Dessa maneira, pretende-se com esse trabalho, desenvolver um sistema de
gestão de chamados de fácil usabilidade para os usuários finais e que possa ser
disponibilizado como um serviço na Internet. Podendo ser oferecido e utilizado por
diversas empresas simultaneamente e dispensando qualquer tipo de implantação
e/ou manutenção pelas empresas clientes.
Para que o sistema possa atender todas as empresas clientes de maneira
simultânea, é necessário oferecer interfaces exclusivas para cada uma delas. Além
disso, é extremamente necessário que a segurança das informações seja garantida,
uma vez que todos os dados dos clientes estarão unificados em uma única
aplicação e em um único banco de dados.
Por se tratar de um serviço que estará disponível na Internet, é necessário
garantir a qualidade do mesmo através da infraestrutura de T. I. que deverá manter
a aplicação funcionando 24 horas por dia sem interrupção do serviço e da qualidade
no acesso (RAMALHO; PRADO, 2013).
1.1 Objetivos
O objetivo desse Trabalho de Graduação é desenvolver um sistema web de

abertura de chamados técnicos que possa ser oferecido como serviço, utilizando
linguagem orientada a objetos e arquitetura de software Model View Controller (M. V.
C.).
15
1.2 Justificativa e motivações
O motivo principal para a escolha do desenvolvimento de um sistema de

gestão de chamados foi vivenciado na prática pelos autores e consiste na extrema
complexidade e quantidade de informações solicitadas por sistemas de gestão de
chamados existentes no mercado. Fato esse que torna os sistemas existentes muito
complexos para a utilização dos usuários finais dessas aplicações.
Por esse motivo, optou-se pelo desenvolvimento de uma aplicação de gestão
de chamados que fosse simples e intuitiva principalmente para os usuários finais e
que não contivesse informações exigidas pelo sistema que fossem desnecessárias
para determinados usuários, por isso o desenvolvimento será feito com base no
mínimo de informações que os autores julgam necessárias para o funcionamento de
um sistema com essas características.
1.3 Métodos e Tecnologias
O desenvolvimento do presente trabalho será feito utilizando-se o método ágil

Scrum, a linguagem de programação a ser utilizada e o sistema gerenciador de
banco de dados serão, respectivamente, o PHP e o MySQL. Para o
desenvolvimento da aplicação, pretende-se utilizar o padrão de desenvolvimento
orientado a objetos e arquitetura MVC. Para a pesquisa científica, pretende-se
utilizar a metodologia de pesquisa exploratória.
16
2 TECNOLOGIAS PARA O DESENVOLVIMENTO WEB
Nesse capítulo são mostrados pontos relevantes às tecnologias envolvidas no

desenvolvimento do sistema de gestão de chamados oferecido como serviço que a
final, é o produto que pretende-se adquirir ao término do presente trabalho.
2.1 Arquitetura Web
Para se desenvolver aplicações voltadas à web, faz-se necessário a existência

de uma arquitetura específica bem como sua respectiva infraestrutura. A arquitetura
web mais simplificada existente é a arquitetura local que consiste apenas de um
programa navegador executado em computadores de usuários, conhecidos como
usuários clientes.
O objetivo do navegador é exibir o conteúdo de uma página para o usuário
cliente que o está utilizando, para isso as páginas precisam utilizar uma linguagem
na qual o navegador seja capaz de interpretar e por sua vez, exibir o conteúdo
desejado para o cliente. Essa linguagem de comunicação entre o navegador e as
páginas é o Hypertext Markup Language (H. T. M. L.) (COSTA, 2007).
O H. T. M. L. é uma linguagem de marcação e não de programação, por esse
motivo, por si só ele não é capaz de executar cálculos ou operações lógicas, mas
apenas conter conteúdos estruturados e que ao serem interpretados pelo navegador
formam os conteúdos das páginas, como por exemplo imagens, tabelas e links
(COSTA, 2007).
No exemplo de arquitetura exemplificado, não há a existência de um
computador servidor, fornecendo as páginas, informações e processando os dados
recebidos e os retornando para o navegador do cliente. Nessa arquitetura as
páginas, bem como suas informações e funcionalidades podem estar armazenadas
no próprio computador do usuário cliente.
Outra arquitetura web existente e muito mais utilizada é a cliente-servidor, que
consiste em um computador (ou em alguns casos mais de um) responsável por
fornecer as páginas, conteúdos, dados e operações matemáticas e lógicas para os
navegadores clientes que interpretarão essas informações e as exibirão para os
usuários (SANTOS, 2010).
17
Nos itens 2.1.1 e 2.1.2 serão fornecidas informações a respeito dessas

arquiteturas de forma a comparar suas funcionalidades, vantagens e desvantagens.
2.1.1 Linguagens executadas nos servidores
As linguagens de programação web executadas nos servidores se baseiam na

arquitetura descrita anteriormente cliente-servidor e são popularmente conhecidas
como linguagens server-side.
Basicamente as páginas desenvolvidas com esse tipo de linguagem de
programação, são armazenadas em um servidor externo ao usuário e todo
processamento de dados como cálculos e operações lógicas são processados no
servidor onde essas páginas estão armazenadas e após sua execução, enviam
retornos ao navegador do usuário (SANTOS, 2010).
Na prática isso traz vantagens e desvantagens. Uma das vantagens é que os
servidores possuem maior capacidade de processamento e são capazes de
processar grandes volumes de informações de forma eficiente. Por mais
interessante que essa característica aparente ser, ela pode se tornar um problema
quando o volume de dados exceder a capacidade do servidor, consumindo assim
muitos recursos de redes, de processamento e prejudicando assim o acesso de
outros usuários (LINHARES, 2009).
A maior desvantagem desse tipo de linguagem são os números excessivos de
requisições feitas dos navegadores clientes para os servidores e que em sua maioria
ocorrem durante as validações efetuadas pelas páginas. Com isso há um maior
consumo do tráfego na rede e no consumo de memória e processamento dos
servidores.
2.1.2 Linguagens executadas nos clientes
Em contrapartida às linguagens de programação executadas nos servidores,

existem as que são executadas nos navegadores clientes, como é o caso do
JavaScript. São linguagens que são carregadas de um arquivo (podendo esse estar
18
armazenado no servidor ou no próprio computador do usuário) uma única vez e são

interpretadas pelo navegador que passa a ser o responsável pelo processamento
dos dados e operações realizadas (SANTOS, 2010).
Nesse cenário, o processamento deixa de ocorrer no servidor e passa a
ocorrer no computador dos clientes. Com isso há menor consumo de recursos dos
servidores devido ao baixo número de requisições. Além disso, a velocidade com
que o navegador solicita um determinado processamento a si mesmo é muito mais
rápida do que quando solicitada ao um servidor remoto.
Essas diferenças não são percebidas em sistemas de pequeno porte devido a
pouca quantidade de requisições realizadas, mas quando são utilizados em
sistemas de grande porte, essas diferenças são facilmente percebidas e a qualidade
de navegação na aplicação se torna muito ruim (SANTOS, 2010).
2.1.3 PHP – Hypertext Preprocessor
O PHP é uma linguagem de programação interpretada, gratuita, open source

e que é processada inteiramente nos servidores. Essa característica é mais
comumente conhecida como server side, como descrito anteriormente. Apesar de
todo o processamento das informações serem executadas nos servidores, o PHP é
capaz de gerar códigos HTML e JavaScript, que por sua vez são linguagens
processadas nos navegadores dos usuários clientes, ou client side.
A sintaxe do PHP lembra bastante a sintaxe de outras linguagens de
programação, como a do C e a do Perl por exemplo. Isso faz com que o PHP seja
uma linguagem de programação de fácil assimilação por programadores experientes
nessas linguagens ou em linguagens que também tenham sintaxes parecidas, como
é o caso do Java por exemplo.
Por ser uma linguagem de fácil assimilação, por ser open source e ter
bastante suporte de desenvolvedores independentes, o PHP é capaz de atender a
todos os tipos de desenvolvedores, sejam principiantes ou experientes. Além disso,
o PHP também se faz presente em diversos sistemas muito utilizados no mercado
de desenvolvimento, como por exemplo, Content Management Sistems (CMS) como
19
Joomla®, Drupal® e WordPress® até mesmo aplicações de comércio on-line como o

Magento®.
Como foi descrito, linguagens server-side como o PHP realizam muitas
requisições nos servidores, principalmente para validação de dados, tornando os
sistemas, conforme seu crescimento, ineficientes. Porém, o PHP e outras linguagens
server-side têm uma interação muito boa com diversos tipos de SGBDs, facilitando a
conexão e manipulação dos dados que serão armazenados, o que, diferentemente
das linguagens client-side, não ocorre com frequência (SANTOS, 2010).
2.2 Banco de Dados
Bancos de dados são recursos desenvolvidos para facilitar o armazenamento

e consulta de informações, eliminando os papéis e planilhas eletrônicas que antes
eram utilizados para essa finalidade e provendo segurança para as informações
armazenadas (FERREIRA; JUNIOR, 2013).
A função do banco de dados é apenas armazenar os dados fornecidos a ele,
porém essa função não é suficiente para atender as necessidades das pessoas e
empresas que fazem uso dessa tecnologia. Para essa finalidade, existem os
Sistemas Gerenciadores de Banco de Dados (S. G. B. D.), que permitem a
realização de consultas, extração de relatórios, execução de rotinas, gatilhos e
diversas outras.
O desenvolvimento do sistema objeto desse trabalho será feito com base em
um SGBD chamado MySQL.
2.2.1 MySQL
O MySQL e um SGBD relacional open source e gratuito, amplamente utilizado

no desenvolvimento web devido a sua fácil instalação nos servidores, utilização,
desempenho em sistemas de pequeno e médio porte e principalmente, devido a sua
facilidade de integração com as linguagens de programação web, como é o caso do
PHP.
Como o próprio nome indica, o MySQL é compatível com a Structured Query
Language (S. Q. L.) e além disso, possui outras funcionalidades interessantes, como
20
por exemplo o suporte a multiusuários, multitarefas e capacidade para gerenciar

bancos de dados com até 50 milhões de registros (FERREIRA; JUNIOR, 2013).
Na Figura 1 são comparados o desempenho do MySQL com relação ao de
alguns outros SGBDs disponíveis no mercado ao realizar operações envolvendo
1.000 registros nos bancos de dados.
Figura 1 - Benchmarks de SGBDs com 1.000 registros
Fonte: (FERREIRA; JUNIOR, 2013)

21
Na Figura 2, a mesma comparação é feita, porém com operações envolvendo

10.000 registros.
Figura 2 - Benchmarks de SGBDs com 10.000 registros
Fonte: (FERREIRA; JUNIOR, 2013)
Com as Figuras 1 e 2, pode-se concluir que o desempenho do MySQL é

próximo dos seus concorrentes, mesmo não sendo o melhor deles. Porém é um
SGBD bastante eficiente para a realização de consultas e até mesmo para a
inserção de quantidades pequenas de dados. Com essas características e todas as
outras apresentadas, o MySQL se mostra bastante satisfatório para atender as
necessidades do Sistema de Gestão de Chamados Oferecido como Serviço que
será desenvolvido.
2.3 Arquitetura em nuvem
A computação em nuvem é um termo utilizado para se referenciar a sistemas

computacionais disponibilizados como serviço, sendo consumidos conforme as
necessidades dos clientes, sendo pagos conforme o uso desses serviços e podendo
facilmente ser aumentado ou diminuído conforme a necessidade (RAMALHO;
PRADO, 2013). O conceito anterior, também é conhecido como escalabilidade e tem
sido muito valorizado nos sistemas principalmente por fazer uso mais racional dos
recursos computacionais e ao mesmo tempo gerar economia quando esses recursos
não estão sendo utilizados.
22
Segundo RAMALHO; PRADO (2013, p. 2)

A Computação na Nuvem (C. N.) envolve um conjunto de
serviço de naturezas distintas. Com isso, é importante
organizar e classificar esses serviços tendo como base as suas
características. Na literatura, os dois mecanismos de
classificação mais usados referem-se aos tipos de serviços
oferecidos e a maneira como a CN é disponibilizada ao usuário
final.
Dessa forma, a computação em nuvem pode ser classificada de várias formas.

Uma delas é de acordo com o serviço prestado, podendo ser classificado como
Infrastructure as a Service (IaaS) - Infra estrutura como serviço – quando a
infraestrutura física de T. I. é fornecida virtualmente como serviço; Platform as a
Service (PaaS) – Plataforma como serviço – quando a infraestrutura de apoio para o
ciclo de desenvolvimento de uma aplicação, desde o levantamento dos casos de
uso, definição da arquitetura, codificação, testes e operação até a manutenção é
oferecida como um serviço pela web; Software as a Service (SaaS) – Software como
serviço – quando as aplicações não são vendidas, mas são cobradas assinaturas
pelo uso delas na Internet; Database as a Service (DaaS) – Banco de dados como
serviço – quando o fornecimento de infra estrutura apropriada para banco de dados,
bem como o acesso a esse é fornecido pela Internet como serviço (RAMALHO;
PRADO, 2013).
2.3.1 Software como serviço
Como informado anteriormente, software como serviço é o fornecimento de

aplicações on-line de forma que os usuários da aplicação paguem taxas de
utilização do serviço como mensalidades.
Essa prática de fornecimento de software oferece várias vantagens, tanto para
os usuários dessas aplicações como também para seus desenvolvedores e
fornecedores. Dentre as vantagens para os usuários podem ser destacadas o baixo
custo da mensalidade com relação a aquisição de uma aplicação semelhante, o
suporte prestado pelo fornecedor da aplicação durante a validade do serviço e
também o fato da aplicação estar disponível para uso sempre em sua versão mais
atual.
23
Para os fornecedores de aplicações como serviços, a principal vantagem é a

aquisição de receitas mensais, pois as assinaturas normalmente são vendidas por
períodos de alguns meses. Garantindo assim o recebimento constante de
pagamento pela aplicação por parte dos usuários. Além disso, há uma economia
com custos de manutenção das aplicações, pois vários clientes usam uma mesma
aplicação desenvolvida para atendê-los de forma satisfatória. Dessa forma, os
responsáveis pela aplicação não precisam constantemente alterar uma das versões
para se adequar corretamente as necessidades de um cliente específico.
Apesar das inúmeras vantagens, também existem desvantagens no uso das
aplicações fornecidas como serviço. Um deles é o fato do usuário não ter controle e
nem saber como é a segurança da privacidade dos dados que estão sendo
armazenados nessas aplicações. Outra questão é a necessidade de se estar
conectado a todo instante em uma conexão com a Internet, o que limita o acesso a
essas aplicações em determinados momentos.
2.4 Framework – CodeIgniter
CodeIgniter é um framework para desenvolvimento de softwares web. Ele é

uma ferramenta para pessoas que criam websites utilizando PHP. Seu objetivo é
permitir desenvolver projetos muito mais rápidos do que criando e digitando códigos
desde o início, pois o mesmo disponibiliza um grande conjunto de bibliotecas para
tarefas comuns necessárias, bem como uma interface simples e estrutura lógica
para acessar essas bibliotecas. O CodeIgniter permite que o desenvolvedor
mantenha o foco em seu projeto por minimizar a quantidade de códigos necessários
para uma determinada aplicação (BRANDL, 2014).
Suas bibliotecas adicionais são carregadas dinamicamente, com base em
suas necessidades de um determinado processo, de modo que o sistema básico é
enxuto e bem rápido. O framework CodeIgniter é de uso gratuito e leve, em
contraste com muitos outros frameworks que requerem significamente mais recursos
(BRANDL, 2014). Ele utiliza a arquitetura MVC, que permite grande separação entre
a lógica e a apresentação. Isto é particularmente bom para os projetos em que os
desenvolvedores estão trabalhando com seus arquivos de modelo separados dos
códigos relacionados à lógica do sistema em pauta.
24
3 REQUISITOS DO SISTEMA DE SOFTWARE
Este capítulo tem como objetivo especificar os requisitos funcionais, não

funcionais e as regras de negócio, bem como apresentar o protótipo de telas e o
cronograma de atividades do desenvolvimento do software. O texto a seguir tem
como objetivo relembrar conceitos e padrões de especificação dos requisitos de
software.
3.1 Identificação dos requisitos
Os casos de uso devem ser identificados com um identificador único. A

numeração inicia com o identificador CSU001 e prossegue sendo incrementada à
medida que forem surgindo novos casos de uso.
3.1.1 Requisitos Funcionais
Neste item estão descritos os requisitos funcionais que especificam as ações

que um sistema deve ser capaz de executar, ou seja, os objetivos do sistema,
incluindo prioridade de impacto no negócio. A seguir são apresentados.
[RF001] – Abrir Chamado
Prioridade:  Essencial  Importante  Desejável
Descrição: Permite aos usuários abrirem um novo chamado no sistema,

devendo preencher todos os campos necessários: ‘Departamento
responsável’, ‘Assunto’, ‘Prioridade’, ‘Tipo’, ‘Título do chamado’ e ‘Descrição
do chamado’; com o objetivo de direcionar o chamado para uma área
específica de atendimento.
25
[RF002] – Consultar chamados do Usuário
Prioridade:  Essencial  Importante  Desejável
Descrição: Permite aos usuários visualizarem os seus chamados no sistema

em formato de lista.
[RF003] – Consultar todos os chamados
Descrição: Permite aos usuários do tipo ATENDENTE N1 e ATENDENTE N2

visualizarem todos os chamados do sistema.
[RF004] – Atender chamados
Descrição: Permite aos usuários do tipo ATENDENTE N1 e ATENDENTE N2

efetuarem o atendimento aos chamados.
[RF005] – Escalar chamados
Descrição: Permite aos usuários do tipo ATENDENTE N1 escalarem o

chamado para os usuários ATENDENTE N2, caso não saibam resolvê-los, ou
não tenham condições, por exemplo, por motivos de acesso ou ainda por
alguma outra situação específica de cada cliente.
[RF006] – Aprovar ou Recusar soluções
Descrição: Permite aos usuários aprovarem ou recusarem soluções

propostas pelo ATENDENTE N1 e/ou ATENDENTE N2 para resolver e
finalizar o seu chamado.
26
[RF007] – Gerenciar usuários
Prioridade:  Essencial  Importante  Desejável
Descrição: Permite aos usuários do tipo GESTOR e ADMINISTRADOR DE

EMPRESA adicionarem novos usuários, alterarem os dados e os
departamentos de usuários já existentes. E permite aos usuários do tipo
ADMINISTRADOR DE EMPRESA definir ou remover o privilégio de gestor de
um determinado usuário.
[RF008] – Gerenciar empresa
Prioridade:  Essencial  Importante  Desejável
Descrição: Permite aos usuários do tipo ADMINISTRADOR DE EMPRESA

alterar os dados cadastrais de sua empresa. Além disso, permite a criação,
edição e remoção de setores/departamentos já existentes.
3.1.2 Requisitos Não-Funcionais
Neste item são apresentados os requisitos não funcionais, que especificam

restrições sobre os serviços ou funções providas pelo sistema.
[RNF001] – Segurança
Descrição: O sistema deve dispor de interfaces de login para a autenticação

de usuários e controle de acesso a conteúdos e funcionalidades do sistema,
garantindo o acesso apenas para usuários cadastrados e de acordo com os seus
privilégios de acesso.
27
[RNF002] – Senha Criptografada
Descrição: O sistema deve prover aos usuários senha criptografada. O sistema

deve fazer uso de criptografia md5 para que a obtenção dessas senhas em formato
de texto plano não seja possível.
[RNF003] – Apresentação da Interface Gráfica
Descrição: O sistema deve fazer uso da língua portuguesa para todo e qualquer
texto apresentado. Deve ser executado em qualquer browser e ser responsivo para
poder ser utilizado em qualquer dispositivo, incluindo smartphones.
[RNF004] – Arquitetura de software
Descrição: O sistema deve empregar arquitetura de (três) camadas: apresentação,

negócios e dados.
[RNF005] – Linguagem de programação adotada
Descrição: O sistema deve utilizar a linguagem de programação PHP.
[RNF006] – Banco de Dados
Descrição: O sistema deve utilizar o sistema gerenciador de banco de dados

MySQL.
28
3.1.3 Regras de Negócio
[RN001] – Encerramento técnico dos chamados

Descrição: Para que um chamado seja encerrado, é obrigatório o
preenchimento do campo “Análise da resolução” e que ele seja aprovado pelo
usuário.
[RN002] – Resolução dos chamados

Descrição: Para resolver um chamado, é obrigatório preencher o campo
“Solução proposta”.
[RN003] – Escalamento dos chamados

Descrição: Para escalar um chamado, é obrigatório preencher o campo
“Escalar para N2”.
[RN004] – Atendimento dos chamados

Descrição: Um chamado pode ser resolvido por apenas um ATENDENTE N1
ou ATENDENTE N2 de cada vez.
[RN005] – Chamado técnico

Descrição: Um chamado possui “Setor/Departamento”, “Assunto”,
“Prioridade”, “Tipo”, “Título” e “Descrição”.
[RN006] – Abertura de chamados

Descrição: Qualquer usuário pode abrir chamados em qualquer
departamento da empresa, independente dos privilégios que o mesmo
possua.
29
[RN007] – Status de chamados

Descrição: O sistema deve permitir que os usuários personalizem os status
dos chamados da empresa a qual pertencem, entretanto, os chamados
devem ter no mínimo as seguintes opções de status: “Pendente”, “Em
atendimento”, “Resolvido”, “Escalado” ou “Finalizado”.
[RN008] – Departamentos da uma empresa

Descrição: Uma empresa cliente deverá possuir ao menos um departamento,
entretanto poderá criar vários departamentos no sistema conforme seu
interesse.
[RN009] – Assunto associado ao departamento

Descrição: Um departamento deverá possuir ao menos um assunto
cadastrado, mas poderá cadastrar diversos assuntos caso seja necessário.
[RN010] – Atendimento aos chamados

Descrição: Os atendentes poderão atender somente chamados direcionados
ao departamento ao qual pertencem.
[RN011] – Prazos de atendimento aos chamados

Descrição: Os prazos de atendimento de chamados deverão ser vinculados
às prioridades disponíveis no sistema.
[RN012] – Gestor de departamento

Descrição: Um usuário poderá ser gestor apenas do departamento ao qual
pertence.
[RN013] – Composição de um novo departamento

Descrição: Cada departamento deverá possuir ao menos um gestor, um
atendente N1 e um atendente N2.
[RN014] – Criação de novos Status para os chamados

Descrição: O sistema deverá permitir que as empresas clientes criem novos
status e alterem apenas os status criados por elas.
30
[RN015] – Remoção de dados da base do sistema

Descrição: Nenhum dado deverá ser removido da base de dados do sistema.
Informações devem ser marcadas como inativas caso sejam excluídas
através da aplicação.
[RN016] – Cadastro de empresa no sistema

Descrição: Quando uma empresa cliente for cadastrada, o sistema deverá
cadastrar automaticamente 1 usuário stakeholder da empresa, 1
departamento ao qual o usuário stakeholder da empresa estará vinculado, 1
usuário gestor, além de 3 usuários vinculados a esse departamento, sendo
que 1 será um usuário solicitante, um será um atendente N1 e um será um
atendente N2. Além disso deverá cadastrar também 3 assuntos para esse
departamento, 4 prioridades e 5 status para os chamados dessa empresa que
não poderão ser alterados pela empresa.
[RN017] – Chamados fora do prazo SLA

Descrição: Um chamado que não tenha sido atendido dentro do prazo de
SLA deverá ser exibido na lista de chamados com a coluna status em
vermelho.
[RN018] – Inativação de empresa no sistema

Descrição: Quando uma empresa for inativada, todos os departamentos e
todos os usuários dessa empresa deverão ser inativados.
[RN019] – Inativação de departamento no sistema

Descrição: Quando um departamento for inativado, todos os usuários
alocados nesse departamento deverão ser inativados.
31
3.2 Modelagem dos requisitos funcionais
Neste item são descritos os requisitos a serem atendidos funcionalmente pelo

sistema de uma forma simples, possibilitando a compreensão do comportamento do
sistema pela perspectiva do usuário. São descritos os atores e o diagrama de caso
de uso. A seguir a especificação de atores, do diagrama de caso de uso e da
especificação de caso de uso.
3.2.1 Atores
A seguir são apresentadas as especificações dos atores.
USUÁRIO SOLICITANTE: Representa pessoas físicas que têm acesso à

área reservada do sistema para uma empresa cliente que necessitem abrir
um ou mais chamados técnicos.
ATENDENTE N1: Representa funcionários de algum dos departamentos da

empresa que realizam atendimentos através dos chamados técnicos abertos
na área reservada do sistema para uma empresa cliente.
ATENDENTE N2: Idêntico ao ATENDENTE N1, porém também são os

responsáveis pelo atendimento dos chamados técnicos escalados pelos
atendentes N1.
GESTOR: Representa funcionários, ligados a uma empresa e a um

setor/departamento dessa empresa responsáveis pela gestão de usuários e
estatísticas do setor/departamento ao qual pertence.
ADMINISTRADOR DE EMPRESA: Representa uma pessoa responsável pela

gestão da empresa cliente no sistema. É o usuário responsável pela
manutenção dos dados cadastrais das empresas clientes. Além disso, é
32
responsável pela manutenção dos departamentos existentes na empresa

cliente, bem como dos usuários gestores desses setores/departamentos.
Na figura 3 é apresentado o fluxo de dados de negócio envolvendo os atores

no sistema.
Figura 3 - Fluxo de dados de negócio
Fonte: Autores (2016)

33
3.2.2 Diagrama de Caso de Uso
Na Figura 4 é apresentado o diagrama de caso de uso do sistema
Figura 4 - Diagrama de casos de uso

34
3.2.3 Especificação do Caso de Uso
Na Tabela 1, são apresentadas as especificações do caso de uso Abrir

chamado.
Tabela 1 – Caso de uso – Abrir chamado

CSU001 – Abrir chamado
Sumário: Realizar a abertura de um novo chamado
Ator Primário: Usuário
Ator Secundário:
Casos de Uso Associados: CSU001
Pré-condição:
a. O usuário deve estar identificado pelo Sistema.
Fluxo Principal:
1- O usuário preenche os dados referentes ao setor para onde o chamado será aberto.
2- O usuário seleciona o nível de prioridade para o chamado que está sendo aberto e o tipo de
chamado.
3- O usuário informa um título para o chamado, bem como uma descrição para o mesmo.
4- Ao término do preenchimento dos dados referentes às informações do chamado, o usuário
seleciona a opção enviar.
Fluxo Alternativo:
Fluxo de Exceção:
a. Se algum campo solicitado pelo sistema não foi preenchido, o sistema irá gerar uma mensagem
de erro e não irá registrar a abertura do chamado.
b. Os dados para a abertura do chamado são informados e por alguma(s) inconsistência(s) neles, o
sistema solicita ao usuário a correção dessas informações.
Pós-condições:
a. O sistema valida os dados informados e armazena o chamado no banco de dados.
b. O sistema registra a abertura do chamado e o disponibiliza para atendimento, direcionando-o
para o setor responsável informado pelo usuário que abriu o chamado.
Requisito: RF001
Regras de Negócio: RN005, RN006.

35
Na Figura 5 é apresentado o protótipo de tela do caso de uso Abrir chamado.
Figura 5 - Protótipo de tela – Abrir chamado

36
Na Tabela 2, são apresentadas as especificações do caso de uso Consultar

chamados do usuário.
Tabela 2 – Caso de uso – Consultar chamados do usuário

CSU002 – Consultar chamados do usuário
Sumário: Realizar a visualização dos chamados abertos pelos próprios usuários
Ator Secundário:
Pré-condição:
Fluxo Principal:
1- O usuário acessa essa opção no sistema e visualiza uma lista com os chamados que já foram
abertos por ele.
2- O sistema apresenta uma lista com todos os chamados abertos pelo usuário.
Fluxo Alternativo: Visualizar informações de um chamado específico
a. Com a lista de chamados do usuário disponibilizada pelo sistema, o mesmo seleciona um
chamado específico.
b. O usuário é redirecionado pelo sistema para uma página com todas as informações do chamado
selecionado.
Fluxo de Exceção:
a. Caso o usuário nunca tenha aberto um chamado, ao selecionar a opção de consultar chamados,
o sistema não exibe uma lista de chamados e envia uma mensagem para o mesmo, alertando que
não existem chamados abertos por ele.
Pós-condições:
Requisito: RF002
Regras de Negócio: RN005

37
Na Figura 6 é apresentado o protótipo de tela do caso de uso Consultar

Figura 6 – Protótipo de tela – Consultar chamados do usuário

38
Na Tabela 3, são apresentadas as especificações do caso de uso Consultar

todos os chamados.
Tabela 3 – Caso de uso – Consultar todos os chamados

CSU003 – Consultar todos os chamados
Sumário: Visualizar todos os chamados abertos para o setor/departamento do
atendente que estiver utilizando essa opção.
Ator Primário: Atendente
Ator Secundário:
Pré-condição:
b. O usuário precisa ter privilégio de atendente N1 ou atendente N2.
Fluxo Principal:
1- O atendente acessa essa opção no sistema e visualiza uma lista com os chamados existentes na
empresa.
Fluxo Alternativo: Visualizar chamado detalhado
a. Após a abertura da lista de todos os chamados da empresa, disponibilizada pelo sistema, o
atendente seleciona um chamado.
b. O sistema apresenta uma nova tela com os detalhes em relação à esse chamado.
Fluxo de Exceção:
a. Caso a empresa referente ao atendente nunca tenha aberto um chamado, ao selecionar a opção
de consultar todos os chamados, o sistema não exibe uma lista com todos os chamados e envia
uma mensagem para o mesmo alertando que não existem chamados da empresa registrados no
sistema.
Pós-condições:
a. O sistema apresenta uma lista com todos os chamados da empresa, independente do “status”
dele (aberto, fechado, solucionado, etc.).
Requisito: RF003

39
Na Figura 7 é apresentado o protótipo de tela do caso de uso Consultar todos

os chamados.
Figura 7 – Protótipo de tela – Consultar todos os chamados

40
Na Tabela 4, são apresentadas as especificações do caso de uso Atender

chamado.
Tabela 4 – Caso de uso – Atender chamado

CSU004 – Atender chamado
Sumário: Realizar o atendimento dos chamados abertos pelos usuários
Ator Secundário:
Pré-condição:
b. O usuário precisa ter privilégio de atendente N1 ou de atendente N2.
Fluxo Principal
1- O atendente seleciona o chamado que deseja prestar atendimento, buscando diretamente o
chamado pela opção de localizar chamado ou localizando o mesmo na lista com todos os
chamados.
2- Na página seguinte, o atendente visualiza o problema ou solicitação descrita pelo autor do
chamado.
3- Após a devida tratativa, o atendente preenche o campo “Solução Proposta” e seleciona o botão
“Resolver”.
Fluxo Alternativo: Não atender o chamado
a. Na tela do chamado selecionado, o atendente verifica que esse não pode ser atendido por ele no
momento.
b. O sistema mantém o chamado sem atualizações.
Fluxo de Exceção:
a. Se o atendente selecionar a opção “Resolver” com o campo “Solução Proposta” em branco, o
sistema enviará uma mensagem de erro e não permitirá o chamado ser atualizado.
Pós-condições:
a. O Sistema registra as atualizações alterando o status do chamado.
Requisito: RF004
Regras de Negócio: RN002, RN004, RN005.

41
Na Figura 8 é apresentado o protótipo de tela do caso de uso Atender

chamado.
Figura 8 – Protótipo de tela – Atender chamado

42
Na Tabela 5, são apresentadas as especificações do caso de uso Escalar

chamado.
Tabela 5 – Caso de uso – Escalar chamado

CSU005 – Escalar chamado
Sumário: Envia o chamado para que seja resolvido por um profissional mais
experiente.
Ator Secundário:
Pré-condição:
b. O usuário precisa ter privilégio de usuário atendente N1
c. O usuário precisa ter selecionado um chamado na lista de chamados abertos de seu
setor/departamento.
Fluxo Principal
1- O atendente N1 preenche o campo “Escalar para N2” e seleciona a opção “Escalar”.
Fluxo Alternativo:
Fluxo de Exceção:
a. Se o atendente selecionar a opção “Escalar” sem preencher o campo “Escalar para N2”, o
sistema não permitirá concluir a tarefa de escalar o chamado e envia uma mensagem de erro ao
mesmo.
Pós-condições:
a. O sistema automaticamente altera o status do chamado para “Escalado” e deixa de exibi-lo na
lista de chamados abertos para os usuários atendentes N1 e passa a exibir esse chamado na lista
de chamados abertos para os usuários atendentes N2 daquele setor/departamento.
Requisito: RF005
Regras de Negócio: RN003.

43
Na Figura 9 é apresentado o protótipo da tela “Atender Chamado”, no qual a

funcionalidade de “Escalar Chamado” para o nível 2 está inclusa.
Figura 9 – Protótipo de tela – Escalar chamado

44
Na Tabela 6, são apresentadas as especificações do caso de uso Aprovar ou

recusar soluções.
Tabela 6 – Caso de uso – Aprovar ou recusar soluções

CSU006 – Aprovar ou Recusar soluções
Sumário: Aceita uma solução proposta pelo atendente e finaliza o chamado, ou
recusa uma solução proposta pelo atendente e mantém o chamado
aberto para uma nova solução.
Ator Secundário:
Pré-condição:
b. O usuário deve ter um chamado aberto no qual algum atendente tenha tentado resolver
c. O usuário precisa ter selecionado um chamado na sua lista de chamados.
Fluxo Principal
1- O usuário seleciona um chamado com status “Em atendimento” na sua lista de chamados.
2- O usuário preenche o campo “Análise de resolução”, de acordo com o resultado obtido no
atendimento do chamado.
3- O usuário seleciona opção “Aprovar” e o chamado é considerado resolvido pelo sistema.
Fluxo Alternativo:
a. O usuário seleciona a opção “Recusar” e o chamado não é considerado como resolvido pelo
sistema.
Fluxo de Exceção:
a. Se o usuário selecionar a opção “Aprovar” ou “Recusar”, sem preencher o campo “Análise de
resolução”, o sistema não permite atualizar o status do chamado e envia uma mensagem de erro ao
mesmo.
Pós-condições:
a. Caso a opção desejada tenha sido “Aprovar”, o sistema automaticamente altera o status do
chamado para “Resolvido” e deixa de exibi-lo na lista de chamados abertos para os usuários
atendentes caso a solução tenha sido aprovada. Caso contrário, o chamado permanece com status
“Em atendimento” e continua a aparecer na lista de chamados abertos para os usuários atendentes.
b. Caso a opção desejada tenha sido “Recusar”, o sistema manterá o chamado com status “Em
atendimento” e continuará a aparecer na lista de chamados abertos para os usuários atendentes.
Requisitos: RF006

45
Na Figura 10 é apresentado o protótipo de tela do caso de uso Aprovar

soluções.
Figura 10 – Protótipo de tela – Aprovar soluções

46
Na Tabela 7, são apresentadas as especificações do caso de uso Gerenciar

usuários.
Tabela 7 – Caso de uso – Gerenciar Usuários
CSU007 – Gerenciar Usuários
Sumário: Faz a gerencia dos usuários solicitantes, atendentes N1 e N2 e
gestores, permitindo adicionar novos usuários ou editar usuários já
existentes de acordo com as permissões de acesso dessa
funcionalidade. Também permite aos usuários com privilégios de
Administradores de empresas atribuírem ou retirarem o privilégio de
Gestor de um determinado usuário.
Ator Primário: Gestores e Administradores de Empresa
Ator Secundário: Usuários, Atendente N1, Atendente N2 e Gestor
Pré-condição:
b. O usuário precisa ter privilégio de Gestor para gerenciar usuários comuns e usuários atendentes
N1 e N2 ou ter privilégio de Administrador de Empresa para gerenciar usuários Gestores de
departamentos.
c. O usuário a ter o privilégio de gestor alterado já deve estar cadastrado no sistema.
d. O usuário deve ter acessado essa funcionalidade no menu do sistema.
Fluxo Principal
1- O usuário deve escolher a opção desejada entre “Adicionar novo usuário” ou “Editar um usuário”.
2- Caso a opção selecionada seja “Adicionar novo usuário”, o sistema irá exibir um formulário em
branco para ser preenchido com os dados do novo usuário.
Fluxo Alternativo:
1- Caso a opção selecionada seja “Editar um usuário”, o sistema irá exibir um formulário com os
dados atuais do usuário selecionado para que os dados necessários sejam alterados.
2- Para o usuário com privilégio de Administrador de Empresa, nessa opção é possível alterar o
privilégio de um usuário solicitante ou atendente para gestor.
Fluxo de Exceção:
1- Caso algum campo obrigatório não seja preenchido o sistema emite um alerta visual ao usuário
informando a situação.
2- Caso a busca não retorne nenhum usuário o sistema emitirá um alerta visual com essa
informação.
Pós-condições:
a. O sistema disponibilizará uma nova tela confirmando a operação selecionada e a alteração será
aplicada no banco de dados do sistema.
Requisito: RF008
Regras de Negócio:

47
Na Figura 11 é apresentado o protótipo de tela do caso de uso Gerenciar

usuários.
.
Figura 11 – Protótipo de tela – Gerenciar usuários

48
Na Tabela 8, são apresentadas as especificações do caso de uso Gerenciar

empresa.
Tabela 8 – Caso de uso – Gerenciar empresa

CSU008 – Gerenciar empresa
Sumário: Permite aos usuários com privilégios de Administrador de empresa
atualizarem os dados cadastrados de suas empresas.
Ator Primário: Administrador de empresa
Ator Secundário:
Casos de Uso Associados:
Pré-condição:
b. O usuário precisa ter privilégio de Administrador de empresa.
c. O usuário precisa ter acessado essa funcionalidade no menu do sistema.
Fluxo Principal
1- O sistema irá exibir um formulário com os dados da empresa selecionada e permitirá a alteração
dos mesmos.
Fluxo Alternativo:
Fluxo de Exceção:
1- Caso algum dado obrigatório não seja informado ou seja removido o sistema irá bloquear a ação
e irá exibir um alerta visual ao usuário.
Pós-condições:
a. O sistema realiza as alterações da empresa selecionada no banco de dados.
Requisito: RF010
Regras de Negócio:

49
Na Figura 12 é apresentado o protótipo de tela do caso de uso Gerenciar

empresa.
Figura 12 – Protótipo de tela – Gerenciar empresa

50
4 DESENVOLVIMENTO DO PROJETO
Este capítulo tem como objetivo analisar, detalhar e propor uma solução geral
do sistema, sob o ponto de vista de negócio, de acordo com os requisitos levantados
e validados no item 3. Além disso, é apresentado o refinamento da proposta de
solução geral do sistema, apresentando a solução técnica, incluindo a visão de
projeto e implementação, a arquitetura e a tecnologia utilizada.
4.1 Análise
Neste item é apresentado o modelo do domínio, visão de negócio, que

representa um primeiro modelo conceitual do diagrama de classes.
4.1.1 Diagrama de Classes de Análise (Visão de Negócio)
O diagrama de classes possui todas as classes identificadas do sistema,

contém os atributos e métodos de cada classe, e os relacionamentos entre elas. Na
Figura 13 é apresentado o diagrama de classes de negócio.
51
Na Figura 13 é apresentado o diagrama de classes de negócio do sistema.
Figura 13 - Diagrama de classes de negócio
Fonte: Autores (2016).

52
4.2 Projeto
4.2.1 Diagrama de Classes de Projeto (Visão de Projeto)
O diagrama de classes possui todas as classes identificadas do sistema,

incluindo classes do framework e de arquitetura que não são relacionadas
diretamente ao negócio. Contém os atributos e métodos de cada classe, e os
relacionamentos entre elas.
Na Figura 14 é apresentado o diagrama de classes de projeto do caso de uso

Abrir chamado.
Figura 14 - Diagrama de classes de Projeto

53
Na Figura 15 é apresentado o diagrama de classes de projeto do caso de

Aprovar ou Recusar chamados.

54
Na Figura 16 é apresentado o diagrama de classes de projeto dos casos de

uso Atender e Escalar chamados.

55

uso Consultar Todos os Chamados e Chamados do Usuário.

56

uso Gerenciar Empresa e Gerenciar Usuários.
4.2.2 Arquitetura do Sistema
A infraestrutura necessária para o funcionamento do sistema é a de cliente-

servidor para ambiente web. Dessa forma é necessário um servidor de aplicação
para instalação de aplicações web que pode ser ou não compartilhado com o
servidor de banco de dados. Um servidor de banco de dados ou o próprio servidor
de aplicação com um SGBD instalado e um navegador web para acesso dos
usuários conforme ilustrado na figura 19.
57
Na Figura 19 é apresentado o diagrama de implantação do sistema.
Figura 19 - Diagrama de implantação

58
4.2.3 Diagrama de Classes de Projeto por Caso de Uso
4.2.3.1 Abrir chamado
4.2.3.1.1 Diagrama de classes
Na Figura 20 é apresentado o diagrama de classes do caso de uso Abrir

chamado.
Figura 20 – Abrir chamado – Diagrama de Classes

59
4.2.3.1.2 Diagrama de sequência
Na Figura 21 é apresentado o diagrama de sequência do caso de uso Abrir

chamado.
Figura 21 – Abrir chamado – Diagrama de Sequência

60
4.2.3.2 Atender chamado
Na Figura 22 é apresentado o diagrama de classes do caso de uso Atender

chamado.
Figura 22 – Atender chamado – Diagrama de Classes

61
Na Figura 23 é apresentado o diagrama de sequência do caso de uso Atender

chamado.
Figura 23 – Atender chamado – Diagrama de Sequência

62
4.2.3.3 Consultar chamados do usuário
Na Figura 24 é apresentado o diagrama de classes do caso de uso Consultar

Figura 24 – Consultar chamados do usuário – Diagrama de Classes

63
Na Figura 25 é apresentado o diagrama de sequência do caso de uso

Consultar chamados do usuário.
Figura 25 – Consultar chamados do usuário – Diagrama de Sequência

64
4.2.3.4 Consultar Todos os chamados
Na Figura 26 é apresentado o diagrama de classes do caso de uso Consultar

todos os chamados.
Figura 26 – Consultar todos os chamados – Diagrama de Classes

65

Consultar todos os chamados.
Figura 27 – Consultar todos os chamados – Diagrama de Sequência

66
4.2.3.5 Gerenciar usuários
Na Figura 28 é apresentado o diagrama de classes do caso de uso Gerenciar

usuários.
Figura 28 – Gerenciar usuários – Diagrama de Classes

67

Gerenciar usuários.
Figura 29 – Gerenciar usuários – Diagrama de Sequência

68
4.2.3.6 Gerenciar empresa
Na Figura 30 é apresentado o diagrama de classes do caso de uso Gerenciar

empresa.
Figura 30 – Gerenciar empresa– Diagrama de Classes

69

Gerenciar empresa.
Figura 31 – Gerenciar empresa – Diagrama de Sequência

70
4.2.3.7 Escalar chamado
Na Figura 32 é apresentado o diagrama de classes do caso de uso Escalar

chamado.
Figura 32 – Escalar chamado – Diagrama de Classes

71
Na Figura 33 é apresentado o diagrama de sequência do caso de uso Escalar

chamado.
Figura 33 – Escalar chamado – Diagrama de Sequência

72
4.2.3.8 Aprovar ou recusar soluções
Na Figura 34 é apresentado o diagrama de classes do caso de uso Aprovar ou

recusar soluções.
Figura 34 – Aprovar ou recusar soluções – Diagrama de Classes

73
Na Figura 35 é apresentado o diagrama de sequência do caso de uso Aprovar

ou recusar soluções.
Figura 35 – Aprovar ou recusar soluções – Diagrama de Sequência

74
4.2.4 Diagrama de atividades
4.2.4.1 Fluxo completo do sistema
Na Figura 36 é apresentado o diagrama de atividades do sistema.
Figura 36 – Diagrama de atividades – Fluxo completo do sistema

75
4.2.4.2 Atender chamado
Na Figura 37 é apresentado o diagrama de atividades do caso de uso Atender

Chamado.
Figura 37 – Diagrama de atividades – Atender chamado

76
4.2.5 Diagrama de estados
4.2.5.1 Status do chamado
Na Figura 38 é apresentado o diagrama de estados dos chamados
Figura 38 - Diagrama de estados – Status do chamado
4.2.6 Modelo Lógico da Base de Dados
Neste item é apresentado o modelo lógico da base de dados.

77
Na Figura 39 é apresentado o Modelo lógico da base de dados do sistema
Figura 39 - Modelo lógico da base de dados

78
5 RESULTADOS OBTIDOS
Como produto final do presente trabalho, foi obtido um sistema de gestão de

chamados responsivo capaz de ser disponibilizado como serviço na nuvem, com 18
macro funcionalidades de gestão de chamados técnicos. Abaixo são apresentadas
imagens das funcionalidades disponíveis da aplicação, conforme descritas nos
capítulos anteriores:
Na Figura 40 é apresentada a página Acessar da aplicação, que é
responsável pela autenticação dos usuários no sistema.
Figura 40 - Login de acesso

79
Na Figura 41 é exibida a página Meu Perfil, na qual permite todos os usuários

registrados no sistema alterarem alguns dados cadastrais tais como Nome,
Sobrenome, Telefone, Celular e Senha e também permite a visualização de
informações sobre seu próprio perfil, mas que não podem ser alteradas por ele, tais
como Privilégio, Endereço de Email e Departamento.
Figura 41 - Meu perfil

80
Na Figura 42 é exibida a página Meus Chamados. Essa é a página inicial da

aplicação após o procedimento de login para todos os usuários registrados na
aplicação. Nessa página é possível visualizar todos os chamados que o usuário
abriu no sistema e também filtrá-los, para exibir apenas os chamados abertos,
encerrados ou voltar a exibir todos os chamados criados.
Figura 42 - Meus chamados

81
Na figura 43 é exibida a tela Abrir Chamado, que permite a todos os usuários

registrados no sistema realizarem a abertura de um novo chamado.
Figura 43 - Abrir chamado

82
Na Figura 44 é exibida a tela Lista de chamados. Essa é uma tela disponível

apenas para usuários Atendente N1 e Atendente N2. Nessa tela, são exibidos todos
os chamados abertos referentes ao departamento ao qual o usuário logado
(atendente) pertence. Assim como na tela Meus Chamados, também é possível
aplicar filtros para listar apenas chamados abertos ou encerrados ou mesmo voltar a
exibir a lista completa de chamados do departamento da empresa. Essa tela
diferencia a exibição dos chamados conforme o nível dos atendentes. Se um
Atendente N1 acessar essa tela ele não irá visualizar chamados escalados. O
oposto acontece quando um atendente N2 acessá-la.
Figura 44 - Lista de chamados

83
Na Figura 45 é representa a tela Chamados atendidos que, assim como a

tela Lista de Chamados, só é exibida aos atendentes N1 e atendente N2. Nessa tela
são listados apenas os chamados que o atendente respondeu. Para os atendentes
N1, caso um chamado atendido seja escalado, ele não mais será exibido nessa
página, pois a partir desse momento o atendente N1 deixará de ser responsável pelo
chamado escalado que passará a ser listado apenas aos atendentes N2.
Figura 45 – Chamados atendidos

84
Na Figura 46 exibe a página Usuários disponível para usuários Gestores e

Administradores das empresas. Para usuários gestores, essa página exibe apenas
os usuários Solicitantes, Atendentes N1 e Atendentes N2 do departamento ao qual o
gestor pertença (e no qual é gestor). Para usuários Administradores das empresas,
todos os usuários da empresa são listados. É através dessa página que gestores e
administradores das empresas podem alterar dados cadastrais dos usuários ou
mesmo inativá-los e ativá-los novamente.
Também é possível cadastrar novos usuários no sistema. Nesse caso, os
gestores somente poderão cadastrar usuários em seu próprio departamento e só
conseguirão atribuir os privilégios de Solicitante, Atendente N1 e Atendente N2.
Figura 46 - Usuários (Gestão)

85
Na Figura 47 é exibida a página de Assuntos que é disponibilizada apenas

aos usuários com privilégio de Gestor. Nessa página são gerenciados os assuntos
do departamento ao qual o gestor pertence e que serão listados durante a abertura
de chamados desse departamento.
Figura 47 - Assuntos

86
Na Figura 48 é exibida a página Usuários na visão de um usuário

Administrador de empresas. Essa página é disponibilizada aos usuários Gestores e
Administradores de Empresas e lista os usuários da empresa de acordo com o
privilégio do usuário que está acessando essa funcionalidade conforme descrito
anteriormente ao longo da explicação da Figura 46.
Figura 48 - Usuários (Administração)

87
Na Figura 49 é exibida a página Administração de gestores. Essa página

fornece aos usuários com privilégio de administrador de empresa uma maneira
simplificada de gerenciar quais usuários possuem o privilégio de gestor do
departamento ao qual pertencem. Na tabela que é exibida nessa página, são
listados todos os usuários com privilégio gestor e o departamento ao qual
pertencem. O privilégio de gestor de um usuário específico pode ser revogado
através do botão revogar do usuário desejado.
Quando um departamento é selecionado nessa página, todos os usuários (que
não possuem privilégio de gestor) desse departamento são listados no campo
Usuário. Após selecionar um deles, é disponibilizado o botão Definir Gestor.
Clicando nesse botão, o privilégio de gestor será atribuído ao usuário selecionado e
uma mensagem de confirmação será exibida.
Figura 49 - Gestores

88
Na Figura 50 é exibida a tela Administração da empresa, que pode ser

acessada pelos usuários do tipo Administrador de empresa e permite que os dados
cadastrais da empresa sejam atualizados.
Figura 50 - Dados da empresa

89
Na Figura 51 é exibida a tela Departamentos, que pode ser acessada por

usuários do tipo Administrador de empresa e permite que seja feita a gestão dos
departamentos da empresa.
Figura 51 - Departamentos

90
A tela Prioridade, exibida na Figura 52, permite aos usuários do tipo

Administrador de empresa gerenciarem as prioridades dos chamados e o tempo de
primeiro atendimento que cada uma delas possuirá.
Figura 52 - Prioridades de chamados

91
Na Figura 53 exibe a página Status, que permite aos usuários do tipo

Administrador de empresa gerenciarem quais os status que poderão ser atribuídos
aos chamados, bem como qual será o status padrão para diversas situações.
Figura 53 - Status de chamados

92
A página Tipos de chamados, exibida na Figura 54, permite aos usuários do

tipo Administrador de empresa gerenciarem os tipos que cada chamado criado no
sistema poderá ter.
Figura 54 - Tipos de chamados

93
A página Estatísticas, exibe informações do sistema relativas aos dados de

cada empresa, tais como total de chamados abertos e encerrados na empresa, total
de cada tipo de usuário, tempo médio de atendimento dos chamados por
departamento e diversas outras.
Na Figura 55 é exibido o gráfico 1 da página Estatísticas, que exibe total de
chamados abertos e encerrados.
Figura 55 – Visão geral – Estatísticas – Gráfico 1

94

chamados atendidos e não atendidos.
Na Figura 57 é exibido o gráfico 3 da página Estatísticas, que exibe total de usuários

de cada privilégio disponível no sistema.

95
Na Figura 58 é exibido o gráfico 4 da página Estatísticas, que exibe a média do

tempo de atendimento dos chamados (finalizados) de cada departamento nos 3
últimos meses.

96
Na Figura 59 é exibido o gráfico 5 da página Estatísticas, que exibe a média do

tempo para primeiro atendimento dos chamados de cada departamento nos 3
últimos meses.

chamados atendidos do mês agrupados pelos tipos cadastrados pela empresa.

97

chamados não atendidos do mês agrupados pelos tipos cadastrados pela empresa.

chamados atendidos do mês agrupados pelas prioridades cadastradas pela
empresa.

98

chamados não atendidos do mês agrupados pelas prioridades cadastradas pela
empresa.

99
6 CONSIDERAÇÕES FINAIS
A aplicação feita ao longo desse trabalho começou a ser desenvolvida sob a

arquitetura MVC, sem a utilização de frameworks. Esse modelo de desenvolvimento,
no qual é necessário desenvolver todas as funcionalidades propostas no sistema e
além delas toda a integração entre classes model, view e controllers se mostrou
demasiadamente complexo. Observando essa situação, foi feito o uso do framework
CodeIgniter que possui a interação entre essas classes implementado
automaticamente, permitindo que o tempo de desenvolvimento fosse melhor
dedicado às funcionalidades da aplicação.
O desenvolvimento da aplicação foi realizado em computadores diferentes e a
princípio, para que a aplicação pudesse ser testada, foi necessária a instalação do
programa Apache com módulo de integração do PHP e do SGBD MySQL em todos
os computadores utilizados para o desenvolvimento do sistema.
Nesse cenário, qualquer atualização ocorrida em um dos computadores
utilizados para o desenvolvimento, precisaria ser replicada manualmente para os
outros ambientes de desenvolvimento.
Para automatizar essa tarefa, fez-se uso da plataforma Docker, no qual
consiste em uma maneira de virtualizar aplicações através de containers. Para isso,
o Docker foi instalado em todos os ambientes de desenvolvimento. Em seguida o
Apache e o MySQL foram configurados para operar sobre essa nova plataforma.
A utilização do Docker possibilitou a criação de imagens do Apache e do
MySQL que puderam ser reutilizadas nos diversos ambientes de desenvolvimento.
Com isso, a cada nova alteração no ambiente, uma nova imagem foi gerada e
reutilizada nos outros ambientes, economizando o tempo de replicar as alterações
de ambiente nos outros computadores utilizados no desenvolvimento.
Ainda com o objetivo de facilitar o processo de desenvolvimento da aplicação
e proporcionar condições para que esse processo pudesse ter sido realizado em
múltiplos computadores, optou-se pela utilização do sistema de versionamento de
código Git combinado com o serviço GitHub no qual, juntos, possibilitaram que o
código da aplicação fosse armazenado na nuvem, juntamente com o histórico de
todas as alterações implementadas, e principalmente que fosse recuperado a
100
qualquer momento, em qualquer um dos dispositivos utilizados no desenvolvimento

da aplicação.
A utilização do Git e do GitHub, além de facilitarem o desenvolvimento,
agilizaram o processo de transferência do código fonte da aplicação em
desenvolvimento para o servidor utilizado como ambiente de produção, eliminando
com isso, a utilização de softwares específicos para transferência de arquivos.
Com relação ao escopo, no projeto inicial desse sistema não havia sido
previsto o desenvolvimento de algumas funcionalidades parametrizáveis pelas
empresas cadastradas no sistema, tais como a gestão de prioridades, status de
chamados e algumas outras. A necessidade de tais funcionalidades foi percebida ao
longo da implementação da aplicação.
Apesar de tais funcionalidades não terem sido previstas e também pelo grande
valor que elas viriam a agregar à aplicação, tornando-se diferenciais do sistema com
relação a outras aplicações disponíveis no mercado, foi decidido incluí-las no
desenvolvimento do sistema pelos motivos apresentados e também pelo fato da
metodologia Scrum ser flexível com relação à possibilidade de alterações de escopo
durante o desenvolvimento, na medida em que se perceberam tais necessidades de
melhoria e aperfeiçoamento no decorrer da implementação e testes do sistema.
O desenvolvimento da aplicação foi bem-sucedido, pois atingiu os objetivos
iniciais propostos de ser uma aplicação simplificada para os usuários finais, ser de
fácil customização para as empresas e possuir uma interface responsiva, permitindo
a utilização de todas as funcionalidades do sistema em praticamente qualquer
dispositivo e tamanho de tela, bastando para isso possuir acesso à Internet e um
dispositivo com um browser instalado e atualizado.
As funcionalidades implementadas até o momento, permitem que o sistema
seja disponibilizado para uso. Porém é preciso sempre buscar por maneiras de
melhorar o que já foi implementado para se manter cada vez mais competitivo.
Com isso, foram identificadas possíveis novas funcionalidades, que podem
tornar o sistema mais competitivo no mercado e facilitar a sua possível futura
disponibilização para comercialização no modelo Software as a Service. Como por
exemplo funcionalidades para anexar arquivos durante a abertura de chamados,
enviar e-mails de alerta para chamados recém-criados e SLAs próximos do
vencimento, funcionalidades de Single Sign-On (SSO) com redes sociais e módulos
de cobrança. Além disso, também é interessante implementar um terceiro nível de
101
atendimento que seja opcional para as empresas, mantendo a missão do sistema de

ser flexível e se adaptar sempre às necessidades de negócio das empresas clientes.
Pelos motivos apresentados, é possível identificar que o desenvolvimento
desse trabalho proporcionou a vivência tanto com tecnologias já consagradas no
mercado de T.I. quanto com novas plataformas, como é o caso do Docker, que
apesar de ser bastante robusto e proporcionar o desacoplamento entre as
aplicações instaladas nos servidores de produção e desenvolvimento ainda não é
muito utilizado e nem mesmo conhecido. Isso também se aplica ao Git, GitHub e
Frameworks de forma geral, nos quais muitas empresas ainda não os utilizam e que
poderiam, com a utilização dos mesmos, aumentar sua produtividade, minimizar
erros e custos.
Para avaliar de forma simplificada o atendimento da aplicação aos objetivos
propostos, um questionário a respeito da interface do sistema, de suas
funcionalidades e a respeito da opinião pessoal de usuários foi aplicado a algumas
pessoas que utilizam sistemas semelhantes em seu cotidiano.
Tais usuários são especificados e identificados na Tabela 9 através dos
números de 1 a 4.
Tabela 9 – Entrevistados
Profissionais entrevistados
Nome Profissão
1 Dóris Savoldi Camargo Analista Contábil
2 Gerson Sérvulo Marcolino Analista de Suporte
3 Jéssica Yuri Ogata Analista de Sistemas
4 Richard Liberato de Souza Analista de Infraestrutura
A Tabela 10 exibe algumas perguntas relacionadas ao sistema, as possíveis

respostas que poderiam ser escolhidas pelas pessoas a quem o questionário foi
aplicado e a resposta escolhida por cada um dos usuários, representada por um X
na linha correspondente da tabela ao número atribuído a cada usuário.
102
Tabela 10 – Questionário
Qual o nível, na sua opinião, com relação a clareza dos objetivos das
funcionalidades disponíveis no sistema?
Entendo, com
Entendo Entendo, mas
bastante
perfeitamente com algum Não entendi
dificuldade, a
todos os esforço, alguns os objetivos
maioria dos
objetivos das dos objetivos das telas
objetivos das
telas das telas
telas
1 X
2 X
3 X
4 X
Qual o nível, na sua opinião, com relação ao grau de customização do
sistema para o uso do mesmo no seu cotidiano?
Muito Razoavelmente Muito pouco

Customizável
customizável customizável customizável
1 X
2 X
3 X
4 X
Qual o nível, na sua opinião, com relação ao grau de clareza das
informações que devem ser inseridas nos campos do sistema
Entendo, com
Entendo, mas
Entendo bastante
com algum Não entendi
perfeitamente dificuldade,
esforço, quais quais dados
quais dados quais dados
dados devem devem ser
devem ser devem ser
ser informados informados
informados em informados na
na maioria dos nos campos
todos os campos maioria dos
campos do do sistema
do sistema campos do
sistema
sistema
1 X
2 X
3 X
4 X
Você usaria esse sistema nas suas atividades cotidianas, como por
exemplo no seu trabalho?
Sim Não
1 X
2 X
3 X
4 X

103
Com relação às Tabelas 9 e 10, e apesar da amostra de entrevistados ser

pequena, é possível perceber que a maioria deles considerou o sistema
customizável ou muito customizável, consideraram também que as telas do sistema
conseguiram, razoavelmente em alguns casos, transmitir ao usuário o objetivo de
suas funcionalidades. Além disso, 100% da amostra de entrevistados informou que
utilizaria esse sistema em seu cotidiano.
Com isso, é possível concluir que os usuários consideram o sistema
relativamente fácil de se utilizar, e mesmo não possuindo algumas funcionalidades
descritas anteriormente como melhorias futuras, o sistema possui funcionalidades
suficientes para uso.
104
REFERÊNCIAS
BRANDL, Georg. CodeIgniter at a Glance, 2014. Disponível em:
<https:// codeigniter.com/user_guide/overview/at_a_glance.html />. Acesso em: 17
de abr. 2016.
COSTA, Carlos J. Desenvolvimento para Web, 2007. Disponível em:

<https://books.google.com.br/books?hl=pt-BR&lr=&id=Jn6dTDF-
wcsC&oi=fnd&pg=PT3&dq=programa%C3%A7%C3%A3o+web+tipos&ots=wLcMSJ-
4-g&sig=Vo1Ty5DWXPmMGG-
0QpWcN94Tku0#v=onepage&q=programa%C3%A7%C3%A3o%20web%20tipos&f=
false>. Acesso em: 02 de nov. 2015.
ESTUDO ADMINISTRAÇÃO. Como fazer citação de site e artigo da internet.

Disponível em: <http://www.estudoadministracao.com.br/ler/16-11-2014-como-fazer-
citacoes-internet/>. Acesso em: 14 de out. 2015.
FERREIRA, Erick Rodrigues; JUNIOR, Sérgio M. Trad. Análise de desempenho de

Banco de Dados, 2013. Disponível em:
<http://www.unipac.br/site/bb/bb_tcc_res.php?id=373>. Acesso em: 02 de nov. 2015.
FILHO, Edilson de Azevedo; COSTA, Maria Claudia Lara. Estudo de caso

Ocomon: o uso de um sistema de controle de chamados Opensource para a
área de Suporte Técnico. In: Simpósio de Excelência em Gestão e Tecnologia,
2008, Rio de Janeiro.
LINHARES, Hellston. Conceitos gerais sobre client-side e server-side, 2009.

Disponível em: <http://brasilphp.blogspot.com.br/2009/03/conceitos-gerais-sobre-
client-side-e.html>. Acesso em: 07 de nov. 2015.
RAMALHO, Neilson Carlos Leite; PRADO, Edmir Parada Vasques. Características

dos Serviços de Computação em Nuvem Usados por Organizações Brasileiras,
2013. Disponível em:<http://www.lbd.dcc.ufmg.br/colecoes/sbsi/2013/0060.pdf>.
Acesso em 14 de out. 2015.
105
SANTOS, Richard. Client-Side e Server-Side, 2010. Disponível em:

<https://richardoliveira.wordpress.com/2010/03/22/client-side-e-server-side/>. Acesso
em: 07 de nov. 2015.
106
APÊNDICE A – PLANO E EXECUÇÃO DE TESTES
1.1 Introdução
1.1.1 Finalidade
Este Plano de Teste referente ao Sistema de Chamados Oferecido como

Serviço atende aos seguintes objetivos:
1. Identifica os itens que devem ser inspecionados pelos testes.

2. Identifica a motivação e as ideias subjacentes às áreas de teste a serem
abrangidas.
3. Descreve a abordagem de teste que será usada.
4. Identifica os recursos necessários e fornece uma estimativa dos esforços de
teste.
5. Lista os elementos liberados do projeto de teste.
1.1.2 Escopo
Este plano de teste abordará testes de sistema caixa preta (manual), seguindo a
estratégia de teste de classes de equivalência apenas para os requisitos funcionais
considerados essenciais e com maior fator de risco (impacto) do Sistema de Gestão
de Chamados oferecido como serviço.
1.2 Missão de avaliação e motivação dos testes
Esta atividade tem como missão avaliar no presente momento o maior número
de erros possível e verificar a conformidade com a especificação (requisitos e
design), avaliando também os riscos da qualidade perceptível.
1.2.1 Motivadores dos testes
Os testes a serem realizados têm como motivadores os requisitos funcionais

do projeto, descritos pelos casos de uso implementados até esta interação.
107
1.3 Itens-alvo dos testes
A tabela abaixo determina a probabilidade de falhas ocorrem nos requisitos

funcionais e o impacto que essas falhas causarão no funcionamento do
sistema como um todo. Para isso, a probabilidade de falha e o impacto de falha
são determinados por números de 1 a 3. Sendo que 1 representa a menor
importância e 3 a maior importância.
Em seguida, multiplica-se a probabilidade de falha pelo impacto da falha,

obtendo-se o fator de risco impacto, conforme a tabela abaixo:
108
Probabilidade de Impacto da falha Fator de Risco

Requisito funcional
falha (A) (B) Impacto (A x B)
Abrir Chamado 3 3 9
Consultar chamados
2 2 4
do Usuário
Consultar todos os
2 2 4
chamados
Atender chamados 2 3 6
Escalar chamados 3 2 6
Aprovar ou Recusar
3 2 6
soluções
Gerenciar usuários 1 3 3
Gerenciar empresa 1 2 2
Abaixo foi feita a tabela de análise de perfil operacional conforme o uso dos
requisitos funcionais de acordo com cada ator do sistema.
Requisito Atendente Atendente
Solicitante Gestor Administrador
funcional N1 N2
Abrir
80% 20% 20% 30% 15%
Chamado
Consultar
chamados 10% 5% 10% 10% 5%
do Usuário
Consultar
todos os - 30% 30% - -
chamados
Atender
- 25% 30% - -
chamados
Escalar
- 10% - - -
chamados
Aprovar ou
Recusar 10% 10% 10% - -
soluções
Gerenciar
- - - 60% 20%
usuários
Gerenciar
- - - - 60%
empresa
109
Com base no fator de risco impacto calculado e na tabela de análise de perfil

operacional, os testes dos requisitos funcionais foram priorizados conforme a tabela
abaixo:
Requisito Fator de Risco Ordem de

funcional Impacto (A x B) prioridade
Abrir Chamado 9 1º
Consultar 4 5º
chamados do
Usuário
Consultar todos 4 6º
os chamados
Atender 6 2º
chamados
Escalar 6 3º
chamados
Aprovar ou 6 4º
Recusar
soluções
Gerenciar 3 7º
usuários
Gerenciar 2 8º
empresa
O Fator de Risco (Impacto) de um item-alvo refere-se, numa escala crescente de 1 a

9, ao impacto que será causado no negócio caso o item não funcione
adequadamente.
110
1.4 Resumo dos testes planejados
1.4.1 Resumo das Inclusões dos Testes
O principal teste planejado é:

 Teste de sistema caixa preta (manual) do caso de uso “Abrir chamado”
seguindo a estratégia de teste de classes de equivalência dos requisitos
funcionais de maior fator de risco (impacto) e maior utilização pelos
usuários solicitantes.
Outros testes planejados:
 Teste de sistema caixa preta (manual) dos casos de uso com prioridade
“Importante”, seguindo a estratégia de teste de classes de equivalência,
testando apenas as classes válidas dos fluxos básicos.
1.4.2 Resumo dos Outros Candidatos a Possível Inclusão
A seguir temos um resumo de áreas de teste cuja avaliação e investigação

poderão ser úteis, mas que ainda não foram suficientemente pesquisadas:
 Testes de Performance;
 Testes de Stress.
1.4.3 Resumo das Exclusões dos Testes
A seguir temos um resumo de nível superior dos possíveis testes que poderiam
ter sido conduzidos, mas que foram excluídos deste plano de testes devido à
falta de recursos humanos suficientes e pela indisponibilidade de horários
disponíveis:
 Gerenciar usuários;
 Gerenciar empresa.
111
1.5 Necessidades Ambientais
1.5.1 Hardwares básico do sistema
Os conjuntos de tabelas a seguir apresentam os recursos do sistema

necessários ao esforço de teste descrito neste Plano de Teste.
Recursos do Sistema
Recurso Quantidade Nome e Tipo
Servidor de Banco de Dados 1 Servidor para instalar o
MySql
Rede ou Sub-rede 1 Servidor acessível na
Internet através da porta 80
Servidor Apache 1 Servidor para instalar o
Apache (obs: pode ser o
mesmo equipamento do
servidor de banco de
dados)
PCs de Teste 1 Estação de trabalho com
navegador e acesso à
Internet
112
1.5.2 Elementos de software básicos do ambiente de teste
Nome do Elemento de Software Versão Tipo e Outras

Observações
Windows 10 Latest Sistema Operacional
Google Chrome Latest Navegador da Internet
MySQL Server 5.7 Servidor de banco de
dados
Apache Latest Servidor web
MS Excel 2016 Planilha eletrônica para
os formulários dos testes
e o Log de Testes deste
Plano de Testes
113
1.6 Responsabilidades, perfil da equipe e necessidades de treinamento
1.6.1 Pessoas e papéis

114
1.7 Riscos, dependências, suposições e restrições
O risco mais evidente na execução deste Plano de Teste é a falta de recursos

humanos para o desenvolvimento e execução de testes, uma vez que esses
mesmos recursos estão alocados no desenvolvimento das funcionalidades da
aplicação e, concomitantemente, realizam a elaboração e execução de testes
conforme a disponibilidade de horários.
115
2 ROTEIRO DE TESTES
Campo Classes válidas Classes inválidas

Departamento Departamento Opção “Selecionar
selecionado departamento”
Assunto Assunto selecionado Opção “Selecionar
assunto”
Prioridade Prioridade selecionada Opção “Selecionar
prioridade”
Tipo Tipo selecionado Opção “Selecionar tipo”
Título Conjunto de caracteres - Conjunto de caracteres
com 5 à 25 caracteres com 4 ou menos
caracteres;
- Conjunto de caracteres
com 26 ou mais
caracteres.
Descrição Conjunto de caracteres - Conjunto de caracteres
com 20 à 2000 caracteres com 19 ou menos
caracteres;
- Conjunto de caracteres
com 2001 ou mais
caracteres.
116
ID CSU001_AbrirChamado_CT001FB01
Objetivo Permitir ao usuário a abertura de um novo chamado.
Pré-Condição O usuário deve estar identificado pelo sistema.
Data de realização 18/05/2016
Procedimentos Resultados esperados
Selecionar o menu
"Chamados" Exibe opções adicionais
Selecionar a opção "Abrir
chamado" Exibe tela para preenchimento dos dados referentes ao chamado
Selecionar o campo
“Departamento
responsável” Nenhuma operação é executada
Selecionar o campo
“Assunto” Nenhuma operação é executada
Selecionar o campo
“Prioridade” Nenhuma operação é executada
Selecionar o campo “Tipo” Nenhuma operação é executada
Preencher o campo “Título
do chamado” com 5 à 25
caracteres Nenhuma operação é executada
Preencher o campo
“Descrição do chamado”
com 20 à 2000 caracteres Nenhuma operação é executada
Clicar no botão “Criar
Chamado” Cadastra um novo chamado com os dados informados.
RESULTADO DO TESTE SUCESSO.
ID CSU001_AbrirChamado_CT002FA01
Selecionar o menu
Não selecionar o campo
“Departamento
Selecionar o campo
Selecionar o campo
Preencher o campo
Mensagem de erro informando que existe campo obrigatório não
Clicar no botão “Criar selecionado e não cadastra o novo chamado com os demais dados
Chamado” informados.
117
Selecionar o menu
Selecionar o campo
“Departamento
Selecionar o campo
do chamado” com menos
de 5 caracteres Nenhuma operação é executada
Preencher o campo
“Descrição do chamado” Nenhuma operação é executada
Selecionar o menu
Selecionar o campo
“Departamento
Selecionar o campo
Preencher o campo
118
Selecionar o menu
Selecionar o campo
“Departamento
Selecionar o campo
Selecionar o campo
“Tipo” Nenhuma operação é executada
Preencher o campo
119
Selecionar o menu
Selecionar o campo
“Departamento
Selecionar o campo
Selecionar o campo
do chamado” com menos
de 5 caracteres Nenhuma operação é executada
Preencher o campo
Mensagem de erro informando que o título está inválido, solicita a
Clicar no botão “Criar correção do mesmo e não cadastra o novo chamado com os demais
Chamado” dados informados.
120
Selecionar o menu
Selecionar o campo
“Departamento
Selecionar o campo
Selecionar o campo
do chamado” com mais de
25 caracteres Nenhuma operação é executada
Preencher o campo
Mensagem de erro informando que o título está inválido, solicita a
Clicar no botão “Criar correção do mesmo e não cadastra o novo chamado com os demais
121
Selecionar o menu
Selecionar o campo
“Departamento
Selecionar o campo
Selecionar o campo
Preencher o campo
com menos de 20
Mensagem de erro informando que a descrição está inválida, solicita a
Clicar no botão “Criar correção da mesma e não cadastra o novo chamado com os demais
122
Selecionar o menu
Selecionar o campo
“Departamento
Selecionar o campo
Selecionar o campo
Preencher o campo
com mais de 2000
Mensagem de erro informando que a descrição está inválida, solicita a
Clicar no botão “Criar correção da mesma e não cadastra o novo chamado com os demais
123
ID CSU002_ConsultarChamadosUsuario_CT001FB01
Objetivo Permitir ao usuário visualizar os chamados abertos por ele.
Selecionar o menu
Selecionar a opção "Meus
chamados" Exibe tela com todos os chamados abertos pelo usuário
ID CSU003_ConsultarTodosChamados_CT001FB01
Permitir ao usuário atendente visualizar todos os chamados abertos
para o setor/departamento do atendente que estiver utilizando essa
Objetivo opção.
O usuário deve estar identificado pelo sistema e precisa ter privilégio de
Pré-Condição atendente N1 ou atendente N2.
Selecionar o menu
"Atendimento" Exibe opções adicionais
Selecionar a opção "Lista
de chamados" Exibe tela com uma lista de todos os chamados existentes na empresa
ID CSU004_AtenderChamado_CT001FB01
Permitir ao usuário atendente realizar o atendimento dos chamados
Objetivo abertos pelos usuários.
Pré-Condição atendente N1 ou atendente N2.
Selecionar o menu
de chamados" Exibe tela com todos os chamados abertos pelo usuário
Selecionar o botão
“Visualizar” Exibe os detalhes do chamado aberto no sistema
Preencher o campo
“Resposta” com 20 à 2000
Selecionar o botão “Salvar” Cadastra a solução proposta pelo atendente no chamado
124
ID CSU005_EscalarChamado_CT001FB01
Permitir ao usuário atendente N1 enviar o chamado para que seja
Objetivo resolvido por um profissional mais experiente (atendente N2).
Pré-Condição atendente N1.
Selecionar o menu
de chamados" Exibe tela com todos os chamados abertos pelo usuário
Selecionar o botão
Selecionar o status
“Escalado para nível 2” Nenhuma operação é executada
Preencher o campo
“Resposta” com 20 à 2000
Selecionar o botão “Salvar” Cadastra a solução proposta pelo atendente no chamado
ID CSU006_AprovarRecusarSolucao_CT001FB01
Permitir ao usuário aceitar uma solução proposta pelo atendente e
finaliza o chamado, ou recusar uma solução proposta pelo usuário e
Objetivo mantém o chamado aberto para uma nova solução.
O usuário deve estar identificado pelo sistema, deve ter um chamado
aberto que algum atendente tenha tentado resolver e precisa ter
Pré-Condição selecionado o chamado na sua lista de chamados.
Selecionar o menu
Selecionar a opção "Meus
chamados" Exibe tela com todos os chamados abertos pelo usuário
Selecionar o botão
Selecionar o status
“Resolvido” para aprovar ou
“Recusado pelo usuário”
para recusar a solução Nenhuma operação é executada
Preencher o campo
“Análise de resolução” com
20 à 2000 caracteres Nenhuma operação é executada
Cadastra o registro do usuário aprovando ou recusando a solução
Selecionar o botão “Salvar” proposta pelo atendente no sistema.
125
ID CSU007_GerenciarUsuarios_CT001FB01
Permitir ao usuário gestor fazer a gerencia dos usuários solicitantes,
atendentes N1 e N2 e gestores, permitindo adicionar novos usuários ou
editar usuários já existentes de acordo com as permissões de acesso
dessa funcionalidade. Também permite aos usuários com privilégios de
administradores de empresas atribuírem ou retirarem o privilégio de
Objetivo Gestor de um determinado usuário.
O usuário deve estar identificado pelo sistema, deve ter privilégio de
gestor para gerenciar usuários comuns e usuários atendentes N1 e N2,
privilégio de administrador de empresa para administrar usuários
gestores, o usuário a ter o privilégio de gestor já deve estar cadastrado
no sistema e o usuário deve ter acessado essa funcionalidade no menu
Pré-Condição sistema.
Selecionar o menu
"Gestão" ou
“Administração” Exibe opções adicionais
Selecionar a opção Exibe tela com todos os usuários disponíveis para o gestor ou
"Usuários" administrador
Selecionar o botão “Novo
Usuário” Exibe uma nova tela para o cadastro de um novo usuário
Preencher o campo “Nome” Nenhuma operação é executada
Preencher o campo
“Sobrenome” Nenhuma operação é executada
Preencher o campo
“Telefone” Nenhuma operação é executada
Preencher o campo
“Telefone” Nenhuma operação é executada
Selecionar o campo
“Privilégio” Nenhuma operação é executada
Preencher o campo
“Endereço de e-mail” no
formato correto de e-mail
(*@*.*) e com 125
caracteres, no máximo Nenhuma operação é executada
Preencher o campo
“Senha” (acessando como
Administrador, pois no
acesso como gestor é
definida a senha padrão
‘Mudar123’) Nenhuma operação é executada
Selecionar o botão “Incluir Cadastra o registro de um novo usuário no sistema.
126
ID CSU008_GerenciarEmpresa_CT001FB01
Permitir ao usuário administrador de empresa atualizar os dados da
Objetivo empresa no sistema.
O usuário deve estar identificado pelo sistema, deve ter privilégio de
Pré-Condição administrador de empresa.
Selecionar o menu
"Administração" Exibe opções adicionais
Selecionar a opção "Dados
da empresa" Exibe tela com todos os chamados abertos pelo usuário
Preencher o campo “País”
com até 45 caracteres Exibe os detalhes do chamado aberto no sistema
Preencher o campo
“Estado” com até 45
Preencher o campo
“Cidade” com até 45
Selecionar o botão
“Atualizar dados” Atualização dos dados referentes à empresa no sistema.
127
ANEXO A – PRODUCT BACKLOG

Product
Backlog
ID Nome Importância Estimativa Como Demonstrar Notas

1 Abrir 80 7 Logar-se como usuário padrão, Não haverá
chamado selecionar a opção “abrir exclusão de dados,
chamado” no menu principal o status dos
“chamados”. Preencher os chamados será
dados disponíveis no formulário controlado pela
que será exibido e clicar no tabela tcc_status,
botão “criar chamado” logo nenhum
chamado poderá
ser excluído
2 Consultar 65 5 Logar-se como usuário padrão,
chamados selecionar a opção “meus
do usuário chamados” no menu principal
“chamados”.
3 Consultar 70 5 Logar-se como usuário
todos os atendente, selecionar a opção
chamados “lista de chamados” no menu
principal “atendimento”.
4 Atender 50 4 Logar-se como usuário Ao clicar no botão
chamados atendente, selecionar a opção atender, o sistema
“lista de chamados” no menu deve alterar o
principal “Atendimento”. status do chamado
Escolher um chamado exibido selecionado para
na lista e clicar no botão “Em atendimento”.
“atender”. Preencher o
formulário que será exibido e
clicar no botão “resolver”.
5 Escalar 20 2 Logar-se como usuário Ao clicar no botão
chamados atendente, selecionar a opção atender, o sistema
“lista de chamados” no menu deve alterar o
principal “Atendimento”. status do chamado
Escolher um chamado exibido selecionado para
na lista e clicar no botão “Escalado”.
“atender”. Preencher o campo
“escalar para N2” e clicar no
botão “escalar”.
6 Aprovar ou 20 2 Logar-se como usuário padrão, Ao clicar no botão
recusar selecionar a opção “Meus atender, o sistema
soluções chamados” no menu principal deve alterar o
“chamados”. Escolher e status do chamado
selecionar um dos chamados selecionado para
exibidos na lista. Preencher o “Finalizado”.
campo “Análise de resolução” e
clicar no botão “aprovar”
7 Gerenciar 40 5 Logar-se como usuário gestor,
usuários selecionar a opção “Usuários”
no menu principal “Gestão”.
Preencher os dados do
clicar no botão “incluir” para
cadastrar novos usuários no
sistema. Ou selecionar um
usuário na lista que será
128
exibida e no formulário que

será exibido alterar os dados
cadastrais do usuário
selecionado.
8 Gerenciar 20 3 Logar-se como usuário
empresa administrador, selecionar a
opção “Gestores” no menu
principal “Administração”.
Preencher os dados do
clicar no botão “Atualizar
dados”.
129
APÊNDICE B – SPRINT BACKLOG 1

Sprint
Backlog
Product ID Dia Dia
ID Tarefa Tarefa Responsável Estimativa Status Dia 1 2 3
Montar
Diagrama de
8 1 sequência Edson 1 Concluído 100%
Criar método
8 2 para CRUD Caio 3 Não Iniciado
Definir
8 3 Interface Caio 1 Concluído 100%
Implementar Em
8 4 Requisito Caio 2 atendimento 50%
Verificar
8 5 estrutura BD Edson 1 Concluído 100%
8 6 Testar e validar Edson 1 Não Iniciado
Montar
Diagrama de
Criar método
7 8 para CRUD Caio 3 Não Iniciado
Definir
7 9 Interface Caio 1 Concluído 100%
Implementar
7 10 Requisito Caio 2 Não Iniciado
Verificar
7 12 Testar e validar Edson 1 Não Iniciado
130
APÊNDICE C – SPRINT BACKLOG 2

Sprint
Backlog
Product ID Dia Dia
ID Tarefa Tarefa Responsável Estimativa Status Dia 1 2 3
Montar
Diagrama de
Criar método Não
1 14 para CRUD Caio 3 Iniciado
1 15 Definir Interface Caio 1 Concluído 100%
Implementar Não
1 16 Requisito Caio 3 Iniciado
Verificar
Não
1 18 Testar e validar Edson 1 Iniciado
131
APÊNDICE D – SPRINT BACKLOG 3

Sprint
Backlog
ID Dia
Product ID Tarefa Tarefa Responsável Estimativa Status Dia 1 2
Montar Diagrama
6 19 de sequência Edson 1 Concluído 100%
Criar método para Não
6 20 CRUD Caio 2 Iniciado
Implementar Não
Verificar estrutura
6 23 BD Edson 1 Concluído 100%
Não
132
APÊNDICE E – SPRINT BACKLOG 4

Sprint
Backlog
ID Dia
Montar Diagrama
Implementar Não
Verificar estrutura
Não
Montar Diagrama
Implementar Não
Verificar estrutura
Não
133
APÊNDICE F – SPRINT BACKLOG 5

Sprint
Backlog
ID Dia
Montar Diagrama
Implementar Não
Verificar estrutura
Não
Montar Diagrama
Implementar Não
Verificar estrutura
Não

TCC Exemplo Assistência Chamados

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC Exemplo Assistência Chamados

Enviado por

Direitos autorais:

Formatos disponíveis

FACULDADE DE TECNOLOGIA DO IPIRANGA

CURSO DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Trabalho de Conclusão de Curso

Orientador: Prof. Me. Antônio Fernando

Trabalho de Conclusão de Curso

A todos que colaboraram e nos proporcionaram as condições necessárias para o

Diante de uma tendência mundial de desenvolvimento de software, onde aplicações

Palavras-chave: Chamados Técnicos. Ordens de Serviço. Gestão de Chamados.

Before a global trend of software development, which applications are provided as

Keywords: Technical Support Tickets. Service Order. Tickets Management. SaaS

Figura 1 - Benchmarks de SGBDs com 1.000 registros ............................................ 20

Tabela 1 – Caso de uso – Abrir chamado ................................................................. 34

CEETEPS Centro Estadual de Educação Tecnológica Paula Souza

1.1 OBJETIVOS ........................................................................................................ 14

2 TECNOLOGIAS PARA O DESENVOLVIMENTO WEB ......................................... 16

2.1 ARQUITETURA W EB ............................................................................................ 16

3 REQUISITOS DO SISTEMA DE SOFTWARE ....................................................... 24

3.1 IDENTIFICAÇÃO DOS REQUISITOS .......................................................................... 24

4 DESENVOLVIMENTO DO PROJETO ................................................................... 50

4.1 ANÁLISE ............................................................................................................ 50

5 RESULTADOS OBTIDOS ...................................................................................... 78

6 CONSIDERAÇÕES FINAIS ................................................................................... 99

REFERÊNCIAS ....................................................................................................... 104

APÊNDICE A – PLANO E EXECUÇÃO DE TESTES ............................................. 106

APÊNDICE B – SPRINT BACKLOG 1 .................................................................... 129

APÊNDICE C – SPRINT BACKLOG 2 .................................................................... 130

APÊNDICE D – SPRINT BACKLOG 3 .................................................................... 131

APÊNDICE E – SPRINT BACKLOG 4 .................................................................... 132

APÊNDICE F – SPRINT BACKLOG 5 .................................................................... 133

Atualmente, há uma demanda crescente por produtividade no mercado

Com o crescente número de aplicações que os usuários precisam se adaptar

O objetivo desse Trabalho de Graduação é desenvolver um sistema web de

1.2 Justificativa e motivações

O motivo principal para a escolha do desenvolvimento de um sistema de

1.3 Métodos e Tecnologias

O desenvolvimento do presente trabalho será feito utilizando-se o método ágil

2 TECNOLOGIAS PARA O DESENVOLVIMENTO WEB

Nesse capítulo são mostrados pontos relevantes às tecnologias envolvidas no

2.1 Arquitetura Web

Para se desenvolver aplicações voltadas à web, faz-se necessário a existência

Nos itens 2.1.1 e 2.1.2 serão fornecidas informações a respeito dessas

2.1.1 Linguagens executadas nos servidores

As linguagens de programação web executadas nos servidores se baseiam na

2.1.2 Linguagens executadas nos clientes

Em contrapartida às linguagens de programação executadas nos servidores,

armazenado no servidor ou no próprio computador do usuário) uma única vez e são

2.1.3 PHP – Hypertext Preprocessor

O PHP é uma linguagem de programação interpretada, gratuita, open source

Joomla®, Drupal® e WordPress® até mesmo aplicações de comércio on-line como o

2.2 Banco de Dados

Bancos de dados são recursos desenvolvidos para facilitar o armazenamento

O MySQL e um SGBD relacional open source e gratuito, amplamente utilizado

por exemplo o suporte a multiusuários, multitarefas e capacidade para gerenciar

Figura 1 - Benchmarks de SGBDs com 1.000 registros

Fonte: (FERREIRA; JUNIOR, 2013)

Na Figura 2, a mesma comparação é feita, porém com operações envolvendo

Figura 2 - Benchmarks de SGBDs com 10.000 registros

Fonte: (FERREIRA; JUNIOR, 2013)

Com as Figuras 1 e 2, pode-se concluir que o desempenho do MySQL é

2.3 Arquitetura em nuvem

A computação em nuvem é um termo utilizado para se referenciar a sistemas

Segundo RAMALHO; PRADO (2013, p. 2)

Dessa forma, a computação em nuvem pode ser classificada de várias formas.

2.3.1 Software como serviço