INSTITUTO FEDERAL DO PARANÁ

CAMPUS DE TELÊMACO BORBA

TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

MATHEUS GUILHERME ROBERTO FERREIRA

SAPPHIRE: CONTROLE DE ATIVIDADE E REQUISIÇÕES DE

SERVIÇO

TRABALHO DE CONCLUSÃO DE CURSO

TELÊMACO BORBA
2022
 MATHEUS GUILHERME ROBERTO FERREIRA

SAPPHIRE: CONTROLE DE ATIVIDADE E REQUISIÇÕES DE

SERVIÇO

Trabalho de Conclusão de Curso

apresentado como requisito parcial à
obtenção do título de Tecnólogo em
Análise e desenvolvimento de sistemas,
do Instituto Federal do Paraná.

Orientadora: Prof. Suelyn Fernanda da

Silva

TELÊMACO BORBA
2022
 À minha família, por sua capacidade dе
acreditar em mim. Mãe, seu cuidado e
paciência foi o que deram, em alguns
momentos, а esperança pаrа seguir. Pai,
seu apoio significou a certeza dе qυе não
estou sozinho nessa caminhada.
 AGRADECIMENTOS

Gostaria de deixar registrado também, o meu reconhecimento à minha

família, pois acredito que sem o apoio deles seria muito difícil vencer esse desafio.
Enfim, a todos os que por algum motivo contribuíram para a realização desta
pesquisa.
Agradeço em primeiro lugar а Deus qυе iluminou о meu caminho durante
esta caminhada.
A Prof. Suelyn Fernanda da Silva pela oportunidade е apoio na elaboração
deste trabalho
Aos meus pais, pelo amor, incentivo е apoio durante este processo. Aos
meus amigos por me ajudarem nessa difícil, especialmente a Marcus Ruas e Ariel
Rimovicz.
Enfim, a todos os que por algum motivo contribuíram para a realização desta
pesquisa.
 Talvez não tenhamos conseguido fazer o
melhor, mas lutamos para que o melhor
fosse feito. Não somos o que deveríamos
ser, não somos o que iremos ser, mas
Graças a Deus, não somos o que éramos.
(KING, Martin Luther)
 RESUMO

FERREIRA, Matheus Guilherme Ferreira. SAPPHIRE: Controle de atividades e

requisições de serviço. 2022. 60 f. Trabalho de Conclusão de Curso Tecnologia
em Análise e desenvolvimento de sistemas – Instituto Federal do Paraná. Telêmaco
Borba, 2022.

Atualmente a tecnologia da informação – T.I permite que sejam realizados quase

todas as formas de negócios encontrados dentro de uma empresa, desde o trabalho
de um funcionário individual até as operações envolvendo médias e grandes
equipes. Existem diversos ramos e divisões na T.I como exemplo o setor financeiro,
sistemas, negócios, segurança da informação e infraestrutura. Assim como
construções precisam de uma base para se apoiar, a área de tecnologia também
precisa, esse alicerce é chamado de infraestrutura de T.I e reúne os componentes e
serviços que vão dar sustentação e que são necessários para o bom funcionamento
do ramos citados anteriormente deste setor e da empresa. Se a infraestrutura for
flexível, confiável e segura, certamente poderá ajudar uma empresa a cumprir suas
metas e proporcionar vantagem competitiva de mercado. Caso contrário, se a
mesma não for implementada adequadamente, as empresas poderão enfrentar
problemas de conectividade, produtividade e segurança, como interrupções do
sistema e violações. Nesta perspectiva, quando ocorre alguma falha na estrutura de
TI é necessário chamar o técnico para verificar, sendo feita essa solicitação via
sistemas de chamados, que são plataformas que concentram todas as demandas
dos clientes e colaboradores que tem o foco em tecnologia e seus derivados. Dessa
forma, a Central de atendimento organiza e distribui essas solicitações, para otimizar
esse processo e garantir que ele ocorra de forma fluida e sem erros. Assim sendo,
este trabalho propõe desenvolver um sistema, o qual ofereça vantagens como: fácil
entendimento, rápido e prático, tornar disponível informações sobre o andamento
das solicitações feitas pelos usuário, integrar os dados dos diferentes setores, entre
outras funções. Para tornar possível a construção desse projeto o processo de
engenharia de software utilizado foi o modelo espiral, já que uma de suas principais
vantagens é o constante aperfeiçoamento do software em sua fase de construção,
combinando isto com a linguagem e programação PHP codificada no programa
Visual Studio Code e o banco de dados MySQL projetado no MySQL Workbench.
Tendo como resultado um sistema rápido, fluído e intuitivo.

Palavras-chave: Gerenciamento. Controle. Sistemas. Gestão. Infraestrutura.

 ABSTRACT

FERREIRA, Matheus Guilherme Roberto. SAPPHIRE: Control of activities and

service requests. 2022. 60 f. Conclusion Work of the Technology in Systems
Analysis and Development - Federal Institute of Paraná. Telêmaco Borba, 2022.

Currently information technology - I.T allows almost all forms of business found within
a company to be carried out, from the work of an individual employee to operations
involving medium and large teams. There are several branches and divisions in IT
such as the financial sector, systems, business, information security, and
infrastructure. Just as buildings need a base to support themselves, the technology
area also needs it, this foundation is called IT infrastructure and brings together the
components and services that will support and that are necessary for the proper
functioning of the aforementioned branches of this sector, and the company. If the
infrastructure is flexible, reliable, and secure, it can certainly help a company meet its
goals and provide a competitive market advantage. Otherwise, if it is not
implemented properly, companies may face connectivity, productivity, and security
issues such as system outages and breaches. In this perspective, when there is a
failure in the I.T structure, it is necessary to call the technician to verify, and this
request is made by help desk, which are platforms that concentrate all the demands
of customers and employees that focus on technology and its derivatives. In this way,
the call center organizes and distributes these requests, to optimize this process and
ensure that it occurs smoothly and without errors. Therefore, this work proposes to
develop a system, which offers advantages such as easy understanding, fast and
practical, making available information about the progress of requests made by the
user, integrating data from different sectors, among other functions. To make the
construction of this project possible, the software engineering process used was the
spiral model, since one of its main advantages is the constant improvement of the
software in its construction phase, combining this with the PHP language and
programming code in the Visual program. Studio Code and the MySQL database
built on MySQL Workbench. Resulting in a fast, fluid, and intuitive system.

Keywords: Management. Control. Systems. Technology. Infrastructure.

 LISTA DE ILUSTRAÇÕES

Figura 1 - Modelo em cascata de processo de software 18

Figura 2 - Modelo de prototipação de processo de software 19
Figura 3 - Modelo em espiral de processo de software 20
Figura 4 - Diagrama de caso de uso - exemplo 22
Figura 5 - Diagrama de atividade - Exemplo 23
Figura 6 - SGBD - Exemplo 25
Figura 7 - Diagrama Use case - Geral 33
Figura 8 - Diagrama Use case - Ticket suporte 34
Figura 9 - Diagrama Use case - Interações do chamado 34
Figura 10 - Diagrama Use case - Gerenciar chamado 35
Figura 11 - Diagrama atividade - Login 36
Figura 12 - Diagrama atividade - Criar chamado 37
Figura 13 - Diagrama atividade - Criar atividade 38
Figura 14 - Diagrama atividade - Criar equipe 39
Figura 15 - Protótipo de tela - Login 40
Figura 16 - Tela final - Login 40
Figura 17 - Protótipo de tela - Home 41
Figura 18 - Tela final - Home 41
Figura 19 - Protótipo de tela - Criar equipe 42
Figura 20 - Tela final - Criar equipe 42
Figura 21 - Protótipo de tela - Cadastro de suporte 43
Figura 22 - Tela final - Cadastro de suporte 43
Figura 23 - Protótipo de tela - Perfil 44
Figura 24 - Tela final - Perfil 44
Figura 25 - Modelo final de banco de dados 46
 LISTA DE QUADROS

Quadro 1 - Requisitos do sistema 31

 LISTA DE ABREVIATURAS

UML      –   Linguagem Unifica de Modelagem

T.I      –   Tecnologia da Informação
SGBD – Sistema de Gerência de Banco de Dados
SSL –   Secure Sockets Layer
BD –   Banco de Dados
SQL – Linguagem de Consulta Estruturada
PHP –   PHP Hypertext Preprocessor
HTML –   HyperText Markup Language
   
 SUMÁRIO

1 INTRODUÇÃO 14
1.1 TEMA 14
1.2 PROBLEMA 15
1.3 JUSTIFICATIVA 15
1.4 OBJETIVOS A SEREM ALCANÇADOS 15
1.4.1 Objetivo geral 15
1.4.2 Objetivos específicos 15
2 DESENVOLVIMENTO 17
2.1 ENGENHARIA DE SOFTWARE 17
2.1.1 Modelo cascata 18
2.1.2 Modelo de prototipação 19
2.1.3 Modelo espiral 19
2.2 MODELAGEM DO SISTEMA 21
2.2.1 Diagrama de caso de uso 22
2.2.2 Diagrama de atividades 23
2.3 SISTEMA DE GERÊNCIA DE BANCO DE DADOS 23
2.3.1 MySQL 25
2.3.2 SQL Server 26
2.3.3 PostgreSQL 26
2.3.4 Oracle DB 27
2.4 PROGRAMAÇÃO DO SISTEMA 28
2.4.1 PHP 28
2.4.2 HTML 29
3 MATERIAL E MÉTODO 30
3.1 RESULTADOS 30
3.2 PROJETO DO SISTEMA 31
3.2.1 Levantamento de requisitos 31
3.2.2 Análise 32
3.2.2.1 Diagramação do sistema 32
3.2.3 Protótipos de tela e versões finais 39
3.2.4 Arquitetura do sistema 45
3.2.5 Linguagem de programação 45
3.2.6 Ambiente de programação 45
3.2.7 Ambiente de banco de dados 45
3.2.8 Modelo conceitual do banco de dados 46
3.2.9 Modelo físico do banco de dados 47
4 CONCLUSÃO 59
5.1 SUGESTÕES PARA IMPLEMENTAÇÕES FUTURAS 59
REFERÊNCIAS 60
 14

1 INTRODUÇÃO

Com o crescimento e desenvolvimento de novas tecnologias cria-se a

necessidade de realização de tarefas cada vez mais rápidas e simplificadas, muitas
dessas atividades são realizadas utilizando de recursos e serviços da tecnologia da
informação – T.I, como computadores, smartphones, softwares e internet.
Para que esses recursos funcionem de uma maneira correta e sempre à
disposição do usuário, é necessário que o setor de T.I encontre-se bem alicerçado
em uma base sólida, esse alicerce é chamado de infraestrutura de T.I que reúne os
componentes e serviços que vão dar sustentação e que são necessários para o bom
funcionamento do setor de tecnologia e de todos os seus recursos. Porém a área de
infraestrutura pode enfrentar alguns problemas como queda de conexão, mal
funcionamento e interrupções dos sistemas e problemas de hardware.
Nesta perspectiva, quando ocorre alguma falha na estrutura de TI é
necessário chamar o técnico para verificar, sendo feita essa solicitação via sistemas
de chamados, os quais são plataformas que concentram todas as demandas e
solicitações dos clientes e colaboradores ligadas a tecnologia e seus derivados.
Como gerir uma solicitação de serviço? É possível que seja gerenciado
usando de softwares de central de ajuda (HelpDesk) onde a central de atendimento
organiza e distribui essas solicitações, para otimizar esse processo e garantir que
ele ocorra de forma fluida e sem erros ou no bom e velho método do papel e caneta.
Por isto, este projeto teve como objetivo desenvolver um sistema de
gerenciamento e controle de atividade e requisições de serviço. Este sistema tem
como meta aumentar e agiliza o atendimento a as atividade e serviços ligados à
área de T.I e infraestrutura de T.I o qual ofereça vantagens como: fácil entendimento,
rápido e prático, tornar disponível informações sobre o andamento das solicitações
feitas pelos usuário, integrar os dados dos diferentes setores, entre outras funções.

1.1 TEMA

Site de gerenciamento e controle de chamados, é um sistema onde os

colaboradores podem utilizar para se planejar e organizar as suas tarefas para
execução.
 15

1.2 PROBLEMA

A organização e gestão de chamados é um processo complexo, no qual vão

se incorporando dificuldades, dúvidas e atrasos ao longo do caminho, levando a
uma considerável taxa de contratempos como atraso na entrega de serviços, o não
cumprimento de acordos e problemas na execução das atividades, projetos, podem
engolir os recursos pessoais de uma empresa e representam custos ocultos não
medidos no sistema de contabilidade. A questão-chave torna-se saber criar um
ambiente organizacional que suporte o controle de múltiplos chamados.

1.3 JUSTIFICATIVA

A gestão e execução de atividades e requisições de serviço são processos

complexos, os quais podem ser afetados negativamente por um escopo mal
definido, falta de planejamento, subestimar/menosprezar riscos, falhas de
comunicação, má administração do tempo, levando a uma considerável taxa de
contratempos como atraso na execução do serviço.

1.4 OBJETIVOS A SEREM ALCANÇADOS

Objetivos que este projeto visa cumprir.

1.1.1 Objetivo geral

Desenvolver uma ferramenta para controle de atividades e atendimentos no

setor de T.I infraestrutura.

1.1.2 Objetivos específicos

● Pesquisar acerca do tema;

● Realizar levantamento de requisitos;
 16

● Desenvolver uma base de dados utilizando o gerenciador open-source;

● Desenvolver o sistema utilizando a linguagem PHP.
 17

2 DESENVOLVIMENTO

Este capítulo é responsável por descrever os seguintes assuntos: Análise de

Sistemas, Engenharia de Software, Banco de Dados, Codificação Programação
Web.

2.1 ENGENHARIA DE SOFTWARE

A Engenharia de Software capacita as pessoas com a utilização de teorias,

técnicas e ferramentas da Ciência da Computação para produção e
desenvolvimento de sistemas. Por meio da análise, coleta e processamento de
dados e informações, levantamento de requisitos e ainda identificam potenciais
falhas nesses produtos e criam soluções de alta performance.
Hirama (2011, p. 02), a Engenharia de Software engloba ferramentas de
suporte a atividades de desenvolvimento de software e métodos para explicação e
realização das mesmas, contribuindo para a melhora da qualidade. Dessa forma o
desenvolvimento de software consegue alcançar produtos com maior qualidade e
produtividade.
Conhecer as melhores metodologias de desenvolvimento de software é
indispensável para que a criação de qualquer sistema seja bem-sucedida, cada
software possui as suas próprias características e precisa atender a necessidades
específicas. O sucesso de qualquer projeto e atividade voltado à elaboração de
software depende diretamente da escolha da metodologia mais adequada.   
Para garantir mais eficiência em todo o desenvolvimento, cabe ao gestor
responsável pela equipe conhecer as diferentes metodologias disponíveis e optar
por aquela que se adapte melhor a sua necessidade. É claro que cada método
possui vantagens e desvantagens, por isso é necessário conhecer bem a proposta
do projeto suas as metas, os objetivos, prazos e orçamentos envolvidos para haver
o planejamento correto e determinar qual é a abordagem mais alinhada.
 18

2.1.1 Modelo cascata

O modelo cascata descreve um método de desenvolvimento que é linear e

sequencial, na primeira vez que uma fase do desenvolvimento é completada, o
mesmo prossegue para a próxima fase e não há retorno.
A vantagem de se utilizar o modelo cascata é que ele permite controle
departamental e gerencial. Um planejamento pode ser atribuído com prazo final para
cada estágio de desenvolvimento e um produto pode prosseguir no processo de
desenvolvimento, teoricamente ser entregue no prazo. Cada fase de
desenvolvimento prossegue em uma ordem estrita, sem qualquer sobreposição ou
passos iterativos. Pressman (2021, p. 41).
Porém este modelo apresenta algumas desvantagens que são: Projetos
reais raramente são sequenciais, torna caro corrigir erros cometidos em fases
iniciais, adia a identificação de riscos, atrasa e agrupa testes de sistema, o que
dificulta a integração, Não realiza entrega parciais do produto, Não se adapta
facilmente às mudanças de requisitos.

Figura 1 - Modelo em cascata de processo de software

Fonte:
https://www.antonialucianapires.dev/posts/modelos-de-processo-de-softw
are-na-perspectiva-de-roger-pressman
 19

2.1.2 Modelo de prototipação

Este modelo é baseado na montagem de protótipos, e pode ser classificado

de acordo com uma variedade de dimensões. A abordagem da prototipação tem um
número de vantagens importante a oferecer. Primeira delas, todos o requisitos do
sistema não necessitam ser completamente determinados antecipadamente e
podem ser trocados durante o curso do projeto. Segundo, a entrega de prototipação
clara, definições de sistema entendível e especificações para o usuário final. Como
consequência segundo Pressman (2021, p. 45) o envolvimento e satisfação do
usuário final são fortemente aumentados. Finalmente, prototipação faz isso possível
para rapidamente testar o ambiente de desenvolvimento voltado para a
funcionalidade, performance, interface com banco de dados.

Figura 2 - Modelo de prototipação de processo de software

Fonte:
https://www.antonialucianapires.dev/posts/modelos-de-processo-de-softw
are-na-perspectiva-de-roger-pressman

2.1.3 Modelo espiral

O modelo espiral é um modelo de processo de software evolucionário que

une a natureza iterativa da prototipação aos aspectos sistemáticos e controlados do
 20

modelo cascata. Tem potencial para o rápido desenvolvimento de versões cada vez
mais completas do software. Esta concepção tende a criar um roteiro de atividades e
etapas para que se alcance uma maturidade do processo evolutivo de
desenvolvimento de sistemas complexos e obter, ao final, um produto em sua forma
mais completa possível.
   
Figura 3 - Modelo em espiral de processo de software

Fonte:
https://medium.com/contexto-delimitado/o-modelo-em-espiral-de-boehm-e
d1d85b7df

Segundo Silva, A (2016, p. 28), o início do processo começa com o Plano de

Requisito do Ciclo de vida e a cada contorno na espiral representa uma etapa do
processo de software. Neste modelo as ações de manutenção são implementas dá
para apontar os problemas para que ocorra sua resolução antes de passarem para a
próxima volta, ou seja, cada loop na espiral representa uma etapa do processo de
software.

Silva, A (2016, p 29), constata-se que cada ciclo espiral é dividido em quatro
áreas isso observando a Figura 2:
 21

A. Definição de software: Neste espaço são definidos os objetivos para

esta etapa do projeto.

B. Avaliação e redução de riscos: São averiguados os riscos das

decisões do estágio anterior, cada vez que passar por este setor pode
ser construído protótipos.

C. Desenvolvimento e validação: Este setor contém as atividades da

fase de desenvolvimento, como o design, a especificação, a codificação
e a verificação.

D. Planejamento: É realizada a revisão das etapas anteriores e tomada

uma decisão de ir ou não para o próximo setor. Se a decisão tomada
for positiva, será traçado o plano para este novo laço. Se a decisão for
negativa serão feitas as devidas alterações e assim reavaliados seus
novos riscos.

O modelo espiral facilita ao desenvolvedor e ao cliente entender e resolver

problemas a cada fase, pois consegue mesclar as vantagens propostas pelos de
prototipação e cascata, adicionando a isso a análise de risco.

2.2 MODELAGEM DO SISTEMA

A modelagem do sistema é o processo de desenvolvimento de modelos

abstratos de um sistema, de maneira que cada modelo apresenta uma visão
diferente do sistema e suas funções, eles ajudam a esclarecer o que o sistema
existente faz e podem ser usados como uma base discussão dos seus pontos fortes
e fracos. O que pode levar a requisitos um novo sistema. Atualmente a modelagem
de sistemas se tornou a representação de um sistema usando uma linguagem
gráfica que hoje em dia quase sempre são baseadas em notações em Unified
Modeling Language (UML).

Segundo BOOCH, RUMBAUGH, JACOBSON, (2005, p. 13) a Unified

Modelling Language – UML – ou, Linguagem Unificada de Modelagem, é uma
linguagem gráfica para visualização, especificação, construção e documentação de
artefatos de sistemas complexos de software.
 22

De acordo com Guedes (2013, p. 18), é necessário esclarecer, porém, que a

UML não é uma linguagem de programação, e sim uma linguagem de modelagem,
ou seja, uma forma de representação, o qual tem como objetivo ajudar os
engenheiros de software a delinear suas características, seus requisitos, seu
comportamento, sua estrutura lógica, a ação de seus processos e até mesmos quais
são suas necessidades físicas em relação ao equipamento sobre o qual o sistema
deverá ser incorporado.

2.2.1 Diagrama de caso de uso

O diagrama de caso de uso descreve as especificações de um caso de uso e

modelam as unidades funcionais de um sistema. Possuem a função de ajudar as
equipes de desenvolvimento a entender as necessidades de seu sistema, incluindo
as interação entre os usuários no seu interior e as diferenças entre vários casos de
uso.

Dentro deste contexto, Bezerra (2007, p. 54) afirma:

Por definição, um caso de uso (do inglês use case) é a especificação de

uma sequência completa de interações entre um sistema e um ou mais
agentes externos a esse sistema. Um caso de uso representa um relato de
uso de certa funcionalidade do sistema em questão, sem revelar a estrutura
e o comportamento internos desse sistema.

Figura 4 - Diagrama de caso de uso - exemplo

 23

Fonte: https://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso

2.2.2 Diagrama de atividades

Um diagrama de atividade é essencialmente um gráfico de fluxo, mostrando o

fluxo de controle de uma atividade para outra. Porém o que o destaca de um gráfico
de fluxo é que mostra de maneira abrangente um processo de negócio, sob a ótica
de seu funcionamento em termos de atores, fluxos de trabalho, organização e
objetos associados considerando seus métodos e operações. Além disso, um
diagrama de atividades ajuda a entender o processo de negócios ou o fluxo de
trabalho do sistema, enquanto um fluxograma ajuda a analisar e projetar um
programa.

Na perspectiva de BOOCH, RUMBAUGH, JACOBSON, (2005, p. 402) o

diagrama de atividades deve ser utilizado para fazer a modelagem de pontos
dinâmicos do sistema. Na maior parte, isso envolve a modelagem das etapas
sequenciais em um processo computacional.

Figura 5 - Diagrama de atividade - Exemplo

Fonte: http://www.theclub.com.br/restrito/revistas/201310/umld1310.aspx
 24

2.3 SISTEMA DE GERÊNCIA DE BANCO DE DADOS

Um banco de dados é um agregado organizado de informações ou dados

estruturados, armazenados eletronicamente em um sistema de computador. Date
(2003, p. 03), disse que por ser um sistema computadorizado, o banco de dados, por
si só, pode ser considerado como semelhante a um armário de arquivamento; ou
seja, ele é um depósito ou recipiente para uma coleção de arquivos de dados
computadorizados. E quem os utiliza, esse sistema tem a possibilidade de solicitar
que o sistema realize diversas operações envolvendo tais arquivos.

Um banco de dados é geralmente controlado por um sistema de

gerenciamento de banco de dados (SGBD). Os dados podem ser facilmente
acessados, gerenciados, modificados, atualizados, controlados e organizados. A
maioria dos bancos de dados usa a linguagem de consulta estruturada (SQL) para
escrever e consultar dados.

Heuser (2009, p. 29), afirma que o projeto de um banco de dados ocorre

usualmente em três etapas:

A. Modelagem conceitual, responsável por capturar formalmente os

requisitos de informação de um banco de dados;

B. Projeto lógico, que define, no nível do SGBD, as estruturas de dados

que implementaram os requisitos identificados na modelagem
conceitual;

C. Projeto físico, que estabelece parâmetros físicos de acesso ao BD,

procurando otimizar o desempenho do sistema como um todo.

De acordo com Heuser (2009, p. 23), foram criados os Sistemas de Gerência

de Banco de Dados (SGBD) para que haja um melhor gerenciamento dos mesmos,
cujos objetivos são a modularização dos mesmos. Com isso obtêm-se várias
vantagens, dentre elas, a manutenção dos programas se torna mais simples, pois
fica claro que uma separação de funções facilita a compreensão dos programas; a
eficiência dos programadores também aumenta, já que os programas são
simplificados e pois utilizam funções já construídas. Dentre os SGBDs utilizados
atualmente podem ser citados: SQL Server, Oracle, PostgreSQL e MySQL.
 25

Figura 6 - SGBD - Exemplo

Fonte: https://www.oficinadanet.com.br/post/16631-o-que-e-um-sgbd

Utilizando de um SGBD podemos fazer a modelagem do banco de dados que

é um processo crítico dentro do desenvolvimento de um sistema. Este processo
consiste em criar estruturas no sistema de armazenamento de forma a possibilitar o
encaixe e o resgate de informações em um determinado padrão.

2.3.1 MySQL

Segundo Milani (2007, p. 22), o MySQL é um servidor e gerenciador de banco

de dados (SGBD) relacional, de licença dupla (sendo uma delas de software livre).
Inicialmente ele foi criado para trabalhar com pequenas e médias aplicações, mas
hoje atende a aplicações de grande porte com a capacidade de suportar por volta de
cem milhões de registros em cada tabela e com mais vantagens do que seus
concorrentes.

Agrega todas as características que um banco de dados de grande porte

precisa. E hoje é visto e reconhecido por algumas entidades como banco de dados
open source com capacidade para concorrer com programas similares de código
fechado, tais como SQL Server (da Microsoft) e Oracle.
 26

2.3.2 SQL Server

O SQL Server da Microsoft é um sistema especializado em gerenciar

registros, funcionando como uma plataforma completa de soluções, ele permite
controlar a qualidade dos dados, desenvolver relatórios avançados e ainda é capaz
de se integrar com diversas fontes. Tudo isso por meio de um sistema voltado a
vários níveis de usuários.

Na visão de Jobstraizer (2009, p. 8), O SQL Server se tornou fundamental

graças ao seu desenvolvimento ao longo das versões. A presença dessa plataforma
é hoje, além de uma questão estratégica, uma necessidade para favorecer a
produtividade. O sistema é amplo e tem suporte para uma série de tarefas
fundamentais na análise de dados.

2.3.3 PostgreSQL

O PostgreSQL é um Sistema Gerenciador de Banco de Dados Relacional,

utilizado para armazenar informações de soluções de informática em todas as áreas
de negócios existentes, bem como administrar o acesso a estas informações. Seu
foco é permitir implementação da linguagem SQL em estruturas, garantindo um
trabalho com os padrões desse tipo de ordenação dos dados.

Com um crescimento considerável nos últimos anos, devido a sua praticidade

e pela sua alta compatibilidade com diferentes padrões de linguagem. Seu
funcionamento é desenvolvido para ser, na prática de grande suporte para que
qualquer trabalho seja feito sem maiores dificuldades, um de seus pontos principais
é sua adequação em padrões de conformidade, ajudando a construir bancos de
dados otimizados.

No entendimento de Milani (2008, p. 30) uma das suas principais

características deste SGBD é sua segurança e criptografia baseada em SSL -
Secure Sockets Layer o que permite criar conexões seguras para comunicação de
dados
 27

2.3.4 Oracle DB

Banco de Dados Oracle é um Sistema Gerenciador de Banco de Dados que

utiliza a linguagem SQL, sendo multiplataforma existe uma facilidade enorme para
ser instalado nas mais diversas plataformas, sendo compatível com BIM AIX, IBM
VMS, Windows, Linux, Unix e HP/UX.

Segundo Gonçalves (2014, p. 25) outra vantagem do Oracle é a sua

documentação. Ela é extremamente detalhada e, por isso, os desenvolvedores terão
muito mais conhecimento dos recursos disponíveis na plataforma, oferece recursos
de segurança e performance que garantem a qualidade do trabalho e a tranquilidade
dos usuários, se tornando a melhor alternativa para grandes empresas ou negócios
que possuem requisitos mais complexos.
 28

2.4 PROGRAMAÇÃO DO SISTEMA

É o processo pelo qual um programador escreve, utilizando uma linguagem

de programação, o código-fonte de um software. Esse processo é chamado de
programação de computadores e é usado para criar programas que usamos tanto
nos computadores quanto em dispositivos móveis.

Para que seja possível a programação existem as linguagens de programação

que funcionam por meio de uma série de instruções, símbolos, palavras-chave,
regras semânticas e sintáticas. Desta maneira é possível que o programador crie
programas a partir de um conjunto de ordens, ações consecutivas. 

Esse conjunto faz a ordem e controle do comportamento de um hardware ou

software. Existem diversas linguagens, pois também existem diversas formas de
transmitir um mesmo comando para alcançar um mesmo propósito, atualmente
existem várias linguagens de programação web das quais temos como exemplo:
HTML, CSS JavaScript. PHP, ASP, .NET, apesar de existir várias outras. Para
codificação de algum programa utilizando estas linguagens é necessário utilizar
alguma IDE como o Atom, Visual Studio Code, Sublime, etc.

2.4.1 PHP

De acordo com Niederauer (2005, p 21) o PHP é uma das linguagens de

programação mais utilizadas na web, utilizada por milhares de sites em todo o
planeta. O seu principal diferencial em comparação às demais linguagens é sua
possibilidade de relacionar-se com o mundo web, transformando totalmente os
websites que possuem páginas estáticas, adicionando a este conteúdo dinâmico.

Segundo Soares (2010, p 28) um dos atributos mais marcantes do PHP é sua
possibilidade de se mesclar ao HTML, tornando mais simples a geração de páginas
web dinâmicas.
 29

2.4.2 HTML

HTML é a sigla em inglês para HyperText Markup Language, que, em

português, significa linguagem para marcação de hipertexto.

De acordo com Silva. M (2015, p.) hipertexto é todo texto inserido em um

documento para a web e que tem como principal característica a possibilidade de se
interligar a outros documentos da web com uso de links, comumente presentes nas
páginas web.
 30

3 MATERIAL E MÉTODO

Tendo base o modelo espiral o trabalho foi divido em quatro etapas: Coleta de
dados, Análise dos resultados e prototipação, Desenvolvimento e Revisão do
Projeto.

Na primeira fase houve um levantamento de requisitos feito acerca do tema e

proposta do trabalho, o problema que essa proposta pretende resolver.

A segunda etapa se dará com a análise dos resultados coletados para tomar
ciência do que precisa ser feito e como ser feito, os parâmetros e métodos que a
proposta precisa cobrir para cumprir esse objetivo, escolhendo as melhores táticas e
decisões para construção projeto

Depois disso se iniciará a terceira etapa, na qual se dará a criação do

sistema, e serão utilizadas as ferramentas Atom.io para codificação será feita
utilizando PHP e mesclando com HTML, utilizando a ferramenta MySQL Workbench
6.3 CE para modelar o banco de dados em MySQL.

Na quarta e última fase será feita a revisão das etapas anteriores, corrigindo
os erros encontrados durante a fase do desenvolvimento e a finalização do sistema.

1.1 RESULTADOS

O resultado obtido com este projeto é de um sistema que proporciona uma

boa gerência e acompanhamento das requisições de serviço, visando uma melhor
experiência tanto para os colaboradores empregados na execução da tarefa quanto
para o cliente final.
 31

1.2 PROJETO DO SISTEMA

Estão contidos nesse capítulo as partes focadas na construção do trabalho,

como levantamento de requisitos, os diagramas bases do projeto e os primeiros
esboços de protótipos de tela.

1.2.1 Levantamento de requisitos

O levantamento de requisitos se deu com base na comparação entre os

sistemas existentes Wrike, Asana, ServiceNow e ServiceDesk nomes líderes de
mercado neste segmento. Com isso apontando as principais vantagens destes
sistemas que são sistemas de gerenciamento de projetos robustos, que oferecem
muita segurança e uma ótima organização de tarefas e organizações, descartando
suas desvantagens sistemas que exigem uma assinatura premium para acessar
todas as funções, totalmente em inglês e sem opção para tradução ou com tradução
muito básicas.

Combinando seus pontos positivos e descartando suas características

negativas podemos modelar os primeiros protótipos de baixa fidelidade das telas.

Quadro 1 - Requisitos do sistema

Requisitos Prioridade

O sistema deverá fazer o controle de Alta

todas as atividades e requisições
serviço.

O sistema ser 100% gratuito. Alta

O sistema deve ser intuitivo e de fácil Alta

utilização

Oferecer uma boa organização de Alta

atividade ao usuário

Fonte: Autoria própria

 32

1.2.2 Análise

Com o levantamento de requisitos feito com seus principais pontos

ressaltados, deu-se início a criação dos primeiros diagramas. Estes sendo o
diagrama de caso de uso e diagrama de atividade, ambos nos dão uma noção das
funções básicas que o sistema irá executar.

O diagrama de caso de uso resume as funcionalidades que um sistema deve

oferecer, segundo a perspectiva de diferentes usuários, os detalhes dos usuários
chamados de atores e as interações deles com o sistema. Para criar esse diagrama,
utilizamos um conjunto de símbolos e conectores especializados como includes e
extends, é uma excelente ferramenta para o levantamento dos requisitos funcionais
do sistema.

Enquanto o diagrama de caso de uso nos mostra o que o sistema pode fazer
o diagrama de atividade nos mostra o passo a passo logico para a construção da
tarefa, é essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma
atividade para outra e serão empregados para fazer a modelagem de aspectos
dinâmicos do sistema.

3.2.2.1 Diagramação do sistema

Baseados nesses conceitos, foram criados alguns diagramas de Caso de Uso

e de Atividades que elucidam algumas interações do sistema proposto que serão
apresentados a seguir.
 33

Figura 7 - Diagrama Use case - Geral

Fonte: Autoria própria

Acima na Figura 7 temos uma representação por meio do diagrama de caso

de uso do sistema como um todo, ela nos proporciona a visão geral das funções e
atores que o sistema possui, porém deixa a visão específica de certas funções para
os próximos casos de uso.
 34

Figura 8 - Diagrama Use case - Ticket suporte

Fonte: Autoria própria

No diagrama de use case na Figura 8 temos uma representação específica do

suporte ao usuário, onde ao enfrentar algum problema com o sistema o usuário
poderá entrar para solicitar ajuda, os atores envolvidos nesse caso e suas
respectivas funções e papéis na execução do mesmo.

Figura 9 - Diagrama Use case - Interações do chamado

 35

Fonte: Autoria própria

A Figura 9 nos dá uma visão específica das interações que os usuários tem
com o chamado, podendo comentar procedimentos feitos na realização do chamado
como etapas concluídas ou mesmo o fechamento do chamado.

Figura 10 - Diagrama Use case - Gerenciar chamado

Fonte: Autoria própria

Representado na Figura 10 temos os casos de uso ligados a gerencia do

chamado e a execução da tarefa, cobrindo desde a escolha de uma requisição de
serviço até a criação e designação da equipe que irá atender ao chamado e por fim
sua solução.
 36

Figura 11 - Diagrama atividade - Login

Fonte: Autoria própria

Na figura acima temos a representação da atividade de login o seu fluxo

principal e as ações tomadas caso esse fluxo não seja seguido, e as correções
necessárias para a execução de cada etapa até a sua conclusão.
 37

Figura 12 - Diagrama atividade - Criar chamado

Fonte: Autoria própria

A Figura 12 tem a representação da criação do chamado o seu fluxo principal

preenchendo corretamente os dados do formulário e o passo a passo detalhado que
é seguido para a execução desta atividade da forma correta.
 38

Figura 13 - Diagrama atividade - Criar atividade

Fonte: Autoria própria

A Figura 13 nos mostra o fluxo seguido para executar o cadastro de atividade

no sistema, o passo a passo seguido de todas as etapas necessárias para cumprir
esta atividade.
 39

Figura 14 - Diagrama atividade - Criar equipe

Fonte: Autoria própria

A Figura 14 nos mostra o fluxo seguido para executar o cadastro de equipe no

sistema, o passo a passo seguido para designar um chamado a equipe para que o
mesmo seja solucionado e após isso o cadastro das informações no banco de
dados.

1.2.3 Protótipos de tela e versões finais

Os primeiros protótipos de telas foram desenvolvidas tendo como base os

diagramas de caso de uso e de atividades, estes são os primeiros esboços seguidos
pelas versões finais as quais os usuários terão acesso

Tela inicial do sistema é a tela de login onde o usuário preencherá suas

informações e terá acesso ao sistema, caso esqueça a senha ou o usuário poderá
solicitar clicando na opção abaixo do formulário.
 40

Figura 15 - Protótipo de tela - Login

Fonte: Autoria própria

Podemos ter um comparativo entre o protótipo Figura 15 e a versão final

Figura 16 onde se manteve a ideia de uma tela dívida com metade sendo ocupada
pelo formulário de login e a outra metade por uma imagem vetorizada, a palheta de
cores manteve seu foco nos tons azuis, branco e cinza.

Figura 16 - Tela final - Login

Fonte: Autoria própria

Tendo como exemplo o supervisor após a autenticação do login será

direcionado para a tela home do sistema onde contará com o menu lateral,
 41

informações sobre todas as atividades cadastradas no sistema e um conjunto de

gráficos que auxiliam no controle de atividades e serviços.

Figura 17 - Protótipo de tela - Home

Fonte: Autoria própria

Podemos ter um comparativo entre a o protótipo Figura 17 e a versão final

Figura 18 da tela do home onde se manteve a ideia de um menu lateral e uma barra
de pesquisa superior, porém tiveram alterações nas informações exibidas nesta tela,
substituindo os gráficos por tabelas das informações cadastradas no sistema.

Figura 18 - Tela final - Home

 42

Fonte: Autoria própria

O usuário poderá criar uma equipe clicando em gerenciar equipes no menu

lateral, após isso o usuário deverá preencher os campos do nome da equipe,
escolher a tarefa designada, data de entrega do serviço solicitado e selecionar todos
os integrantes da equipe.

Figura 19 - Protótipo de tela - Criar equipe

Fonte: Autoria própria

Foi nos apresentado o protótipo de tela de criar equipe na Figura 19 e sua

versão final Figura 20 onde se manteve a ideia de padronizar o menu e ter um
formulário a esquerda onde alguns campos foram alterados para uma melhor
adequação ao banco de dados.

Figura 20 - Tela final - Criar equipe

 43

Fonte: Autoria própria

Caso o usuário tenha alguma dúvida poderá solicitar suporte clicando em

suporte ao usuário, após isso deverá preencher todos os campos do formulário,
após isso poderá cadastrar seu pedido de suporte, que será enviado para análise
onde o administrador irá atender à solicitação do usuário.

Figura 21 - Protótipo de tela - Cadastro de suporte

Fonte: Autoria própria

Podemos ter um comparativo entre a o protótipo Figura 21 e a versão final

Figura 22 da tela de cadastro de suporte onde foram trocadas apenas alguns
elementos do formulário e teve leves alterações na palheta de cores do mesmo.
 44

Figura 22 - Tela final - Cadastro de suporte

Fonte: Autoria própria

Figura 23 - Protótipo de tela - Perfil

Fonte: Autoria própria

Sobre o protótipo Figura 23 e a versão final Figura 24 podemos notar

pouquíssimas diferenças se mantendo o mesmos padrão de exibição de dados e
tendo algumas mudanças nos tons das palhetas de cores.
 45

Figura 24 - Tela final - Perfil

Fonte: Autoria própria

O usuário pode atualizar seus dados caso deseje basta clicar em perfil do
usuário, após isso será exibida uma janela com as informações do usuário, caso
deseje alterar seus dados clicar no botão, que mostrará ao usuário um formulário de
atualização, que o mesmo deverá preencher todos os campos, após isso poderá ser
realizada a atualização dos dados da conta.

1.2.4 Arquitetura do sistema

A proposta para criação desse sistema se deu com objetivo de auxiliar os

alunos que estão no processo de aprendizagem das matérias de programação.

1.2.5 Linguagem de programação

Para a codificação do projeto será utilizado a linguagem PHP, pois

atualmente é a linguagem de servidor mais popular, além de que requer menor
configuração, desta maneira existe uma economia de tempo da codificação.
 46

1.2.6 Ambiente de programação

Foram usadas as IDES, Visual Studio Code, versão 1.28 e Sublime Text 3
para codificar o sistema.

1.2.7 Ambiente de banco de dados

A ferramenta MySQLWorkbench, versão 6.3 CE foi utilizada para

modelagem do banco de dados, a qual foi realizada através da linguagem de
pesquisa declarativa padrão para banco de dados relacional, a Structured Query
Language (SQL).
 47

1.2.8 Modelo conceitual do banco de dados

Figura 25 - Modelo final de banco de dados

Fonte: Autoria própria

 48

1.2.9 Modelo físico do banco de dados

--
-- Banco de dados: `sapphire_db`
--

-- --------------------------------------------------------

--
-- Estrutura da tabela `atividade`
--

CREATE TABLE `atividade` (

`atv_id` int(11) NOT NULL,
`atv_titulo` varchar(45) NOT NULL,
`atv_num` varchar(45) NOT NULL,
`atv_resumo` varchar(45) NOT NULL,
`atv_desc` mediumtext NOT NULL,
`atv_dt_abertura` date NOT NULL,
`usuario_usu_id` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- --------------------------------------------------------

--
-- Estrutura da tabela `chamado`
--

CREATE TABLE `chamado` (

`ch_id` int(11) NOT NULL,
`ch_titulo` varchar(45) NOT NULL,
`ch_num` varchar(45) NOT NULL,
`ch_dt_abertura` date NOT NULL,
`ch_resumo` varchar(100) NOT NULL,
 49

`ch_desc` mediumtext NOT NULL,

`atividade_atv_id` int(11) NOT NULL,
`usuario_usu_id` int(11) NOT NULL,
`equipe_eq_id` int(11) DEFAULT NULL,
`tipovalidacao_tipoval_id` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- --------------------------------------------------------

--
-- Estrutura da tabela `comentario`
--

CREATE TABLE `comentario` (

`com_id` int(11) NOT NULL,
`com_desc` varchar(280) NOT NULL,
`com_dt` datetime NOT NULL,
`com_anexoimg` varchar(45) DEFAULT NULL,
`usuario_usu_id` int(11) NOT NULL,
`chamado_ch_id` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- --------------------------------------------------------

--
-- Estrutura da tabela `equipe`
--

CREATE TABLE `equipe` (

`eq_id` int(11) NOT NULL,
`eq_num` varchar(80) NOT NULL,
`eq_desc` varchar(280) NOT NULL,
`eq_dt_criacao` date NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 50

-- --------------------------------------------------------

--
-- Estrutura da tabela `membros`
--

CREATE TABLE `membros` (

`me_id` int(11) NOT NULL,
`usuario_usu_id` int(11) NOT NULL,
`equipe_eq_id` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- --------------------------------------------------------

--
-- Estrutura da tabela `suporte`
--

CREATE TABLE `suporte` (

`sup_id` int(11) NOT NULL,
`sup_numero` varchar(45) NOT NULL,
`sup_titulo` varchar(45) NOT NULL,
`sup_dt_abertura` date DEFAULT NULL,
`sup_resumo` varchar(45) NOT NULL,
`sup_desc` mediumtext NOT NULL,
`sup_anexoimg` varchar(100) DEFAULT NULL,
`tiposuporte_tiposup_id` int(11) NOT NULL,
`tipovalidacao_tipoval_id` int(11) NOT NULL,
`usuario_usu_id` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- --------------------------------------------------------
 51

--
-- Estrutura da tabela `tiposuporte`
--

CREATE TABLE `tiposuporte` (

`tiposup_id` int(11) NOT NULL,
`tiposup_titulo` varchar(45) NOT NULL,
`tiposup_desc` varchar(100) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- --------------------------------------------------------

--
-- Estrutura da tabela `tipousuario`
--

CREATE TABLE `tipousuario` (

`tipousu_id` int(11) NOT NULL,
`tipousu_titulo` varchar(45) NOT NULL,
`tipousu_desc` varchar(45) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- --------------------------------------------------------

--
-- Estrutura da tabela `tipovalidacao`
--

CREATE TABLE `tipovalidacao` (

`tipoval_id` int(11) NOT NULL,
`tipoval_titulo` varchar(100) NOT NULL,
`tipoval_desc` varchar(45) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 52

-- --------------------------------------------------------

--
-- Estrutura da tabela `usuario`
--

CREATE TABLE `usuario` (

`usu_id` int(11) NOT NULL,
`usu_nome` varchar(75) NOT NULL,
`usu_email` varchar(45) NOT NULL,
`usu_senha` varchar(45) NOT NULL,
`usu_dt_criacao` datetime NOT NULL,
`usu_image` varchar(150) DEFAULT NULL,
`usu_fone` varchar(15) NOT NULL,
`usu_cpf` varchar(15) NOT NULL,
`usu_cargo` varchar(50) NOT NULL,
`usu_empresa` varchar(45) NOT NULL,
`tipousuario_tipousu_id` int(11) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

--
-- Índices para tabelas despejadas
--

--
-- Índices para tabela `atividade`
--
ALTER TABLE `atividade`
ADD PRIMARY KEY (`atv_id`),
ADD KEY `fk_atividade_usuario_idx` (`usuario_usu_id`);

--
-- Índices para tabela `chamado`
--
 53

ALTER TABLE `chamado`

ADD PRIMARY KEY (`ch_id`),
ADD KEY `fk_chamado_atividade1_idx` (`atividade_atv_id`),
ADD KEY `fk_chamado_usuario1_idx` (`usuario_usu_id`),
ADD KEY `fk_chamado_equipe1_idx` (`equipe_eq_id`),
ADD KEY `fk_chamado_tipovalidacao1_idx` (`tipovalidacao_tipoval_id`);

--
-- Índices para tabela `comentario`
--
ALTER TABLE `comentario`
ADD PRIMARY KEY (`com_id`),
ADD KEY `fk_comentario_usuario_idx` (`usuario_usu_id`),
ADD KEY `fk_comentario_chamado_idx` (`chamado_ch_id`);

--
-- Índices para tabela `equipe`
--
ALTER TABLE `equipe`
ADD PRIMARY KEY (`eq_id`);

--
-- Índices para tabela `membros`
--
ALTER TABLE `membros`
ADD PRIMARY KEY (`me_id`),
ADD KEY `fk_membros_usuario_idx` (`usuario_usu_id`),
ADD KEY `fk_membros_equipe_idx` (`equipe_eq_id`);

--
-- Índices para tabela `suporte`
--
ALTER TABLE `suporte`
ADD PRIMARY KEY (`sup_id`),
 54

ADD KEY `fk_suporte_tiposuporte1_idx` (`tiposuporte_tiposup_id`),

ADD KEY `fk_suporte_usuario1_idx` (`usuario_usu_id`),
ADD KEY `fk_suporte_tipovalidacao` (`tipovalidacao_tipoval_id`);

--
-- Índices para tabela `tiposuporte`
--
ALTER TABLE `tiposuporte`
ADD PRIMARY KEY (`tiposup_id`);

--
-- Índices para tabela `tipousuario`
--
ALTER TABLE `tipousuario`
ADD PRIMARY KEY (`tipousu_id`);

--
-- Índices para tabela `tipovalidacao`
--
ALTER TABLE `tipovalidacao`
ADD PRIMARY KEY (`tipoval_id`);

--
-- Índices para tabela `usuario`
--
ALTER TABLE `usuario`
ADD PRIMARY KEY (`usu_id`),
ADD KEY `fk_usuario_tipousuario1_idx` (`tipousuario_tipousu_id`);

--
-- AUTO_INCREMENT de tabelas despejadas
--

--
 55

-- AUTO_INCREMENT de tabela `atividade`

--
ALTER TABLE `atividade`
MODIFY `atv_id` int(11) NOT NULL AUTO_INCREMENT;

--
-- AUTO_INCREMENT de tabela `chamado`
--
ALTER TABLE `chamado`
MODIFY `ch_id` int(11) NOT NULL AUTO_INCREMENT;

--
-- AUTO_INCREMENT de tabela `comentario`
--
ALTER TABLE `comentario`
MODIFY `com_id` int(11) NOT NULL AUTO_INCREMENT;

--
-- AUTO_INCREMENT de tabela `equipe`
--
ALTER TABLE `equipe`
MODIFY `eq_id` int(11) NOT NULL AUTO_INCREMENT;

--
-- AUTO_INCREMENT de tabela `membros`
--
ALTER TABLE `membros`
MODIFY `me_id` int(11) NOT NULL AUTO_INCREMENT;

--
-- AUTO_INCREMENT de tabela `suporte`
--
ALTER TABLE `suporte`
MODIFY `sup_id` int(11) NOT NULL AUTO_INCREMENT;
 56

--
-- AUTO_INCREMENT de tabela `tiposuporte`
--
ALTER TABLE `tiposuporte`
MODIFY `tiposup_id` int(11) NOT NULL AUTO_INCREMENT;

--
-- AUTO_INCREMENT de tabela `tipousuario`
--
ALTER TABLE `tipousuario`
MODIFY `tipousu_id` int(11) NOT NULL AUTO_INCREMENT;

--
-- AUTO_INCREMENT de tabela `tipovalidacao`
--
ALTER TABLE `tipovalidacao`
MODIFY `tipoval_id` int(11) NOT NULL AUTO_INCREMENT;

--
-- AUTO_INCREMENT de tabela `usuario`
--
ALTER TABLE `usuario`
MODIFY `usu_id` int(11) NOT NULL AUTO_INCREMENT;

--
-- Restrições para despejos de tabelas
--

--
-- Limitadores para a tabela `atividade`
--
ALTER TABLE `atividade`
 57

ADD CONSTRAINT `fk_atividade_usuario` FOREIGN KEY

(`usuario_usu_id`) REFERENCES `usuario` (`usu_id`) ON DELETE NO ACTION ON
UPDATE NO ACTION;

--
-- Limitadores para a tabela `chamado`
--
ALTER TABLE `chamado`
ADD CONSTRAINT `fk_chamado_atividade` FOREIGN KEY
(`atividade_atv_id`) REFERENCES `atividade` (`atv_id`) ON DELETE NO ACTION
ON UPDATE NO ACTION,
ADD CONSTRAINT `fk_chamado_equipe` FOREIGN KEY (`equipe_eq_id`)
REFERENCES `equipe` (`eq_id`) ON DELETE NO ACTION ON UPDATE NO
ACTION,
ADD CONSTRAINT `fk_chamado_tipovalidacao1` FOREIGN KEY
(`tipovalidacao_tipoval_id`) REFERENCES `tipovalidacao` (`tipoval_id`) ON DELETE
NO ACTION ON UPDATE NO ACTION,
ADD CONSTRAINT `fk_chamado_usuario` FOREIGN KEY
(`usuario_usu_id`) REFERENCES `usuario` (`usu_id`) ON DELETE NO ACTION ON
UPDATE NO ACTION;

--
-- Limitadores para a tabela `comentario`
--
ALTER TABLE `comentario`
ADD CONSTRAINT `fk_comentario_chamado` FOREIGN KEY
(`chamado_ch_id`) REFERENCES `chamado` (`ch_id`),
ADD CONSTRAINT `fk_comentario_usuario` FOREIGN KEY
(`usuario_usu_id`) REFERENCES `usuario` (`usu_id`) ON DELETE NO ACTION ON
UPDATE NO ACTION;

--
-- Limitadores para a tabela `membros`
--
 58

ALTER TABLE `membros`

ADD CONSTRAINT `fk_membros_equipe` FOREIGN KEY (`equipe_eq_id`)
REFERENCES `equipe` (`eq_id`) ON DELETE NO ACTION ON UPDATE NO
ACTION,
ADD CONSTRAINT `fk_membros_usuario1` FOREIGN KEY
(`usuario_usu_id`) REFERENCES `usuario` (`usu_id`) ON DELETE NO ACTION ON
UPDATE NO ACTION;

--
-- Limitadores para a tabela `suporte`
--
ALTER TABLE `suporte`
ADD CONSTRAINT `fk_suporte_tiposuporte` FOREIGN KEY
(`tiposuporte_tiposup_id`) REFERENCES `tiposuporte` (`tiposup_id`) ON DELETE
NO ACTION ON UPDATE NO ACTION,
ADD CONSTRAINT `fk_suporte_tipovalidacao` FOREIGN KEY
(`tipovalidacao_tipoval_id`) REFERENCES `tipovalidacao` (`tipoval_id`) ON DELETE
NO ACTION ON UPDATE NO ACTION,
ADD CONSTRAINT `fk_suporte_usuario` FOREIGN KEY
(`usuario_usu_id`) REFERENCES `usuario` (`usu_id`) ON DELETE NO ACTION ON
UPDATE NO ACTION;

--
-- Limitadores para a tabela `usuario`
--
ALTER TABLE `usuario`
ADD CONSTRAINT `fk_usuario_tipousuario1` FOREIGN KEY
(`tipousuario_tipousu_id`) REFERENCES `tipousuario` (`tipousu_id`) ON DELETE
NO ACTION ON UPDATE NO ACTION;
COMMIT;

/*!40101 SET
CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
 59

/*!40101 SET
CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
 60

4 CONCLUSÃO

A elaboração deste trabalho teve o intuito de facilitar a relação e a

comunicação entre colaboradores que venham trabalhar com requisições de
serviços de T.I, destacando-se como as principais dificuldades enfrentadas pelos
colaboradores, a falta de organização e comunicação com o cliente final.
O site foi projetado com o intuito de possuir uma usabilidade acessível, de
forma que os usuários não encontrem dificuldades em utilizar nenhuma das
funcionalidades para expor suas dúvidas, compartilhar experiências, ideias e
encontrando as soluções.
Conforme descrito no decorrer deste documento, todos os objetivos
específicos foram cumpridos. O levantamento de requisitos foi realizado por meio de
estudo dos dois principais sites e sistemas com temática equivalente. A partir deste
levantamento o sistema foi idealizado e então programado com utilização de
ferramentas e recursos livres e de código aberto. Ao final, o objetivo principal foi
cumprido, com o desenvolvimento de um portal para compartilhamento de dúvidas e
códigos.

1.1 SUGESTÕES PARA IMPLEMENTAÇÕES FUTURAS

Sugiro para implementações futuras um novo layout mais dinâmico, que

possibilite uma melhor interação do usuário com o sistema, além de aumentar a
chance de customização. Pensa-se também em adicionar um algoritmo de ticket de
suporte mais dinâmico, onde além de mais eficiente o usuário tem uma maneira
mais rápida de solucionar seus problemas ao utilizar o sistema.
 61

REFERÊNCIAS

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 3.

ed. Rio de Janeiro: Elsevier, 2007

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usuário. 2. ed. Rio de
Janeiro, 2005.

DATE, Christopher J. Introdução a sistemas de banco de dados. 8. ed. Rio de

Janeiro: Elsevier, 2003.

GOMES, Anabela de Jesus. Dificuldades de aprendizagem de programação de

computadores: contributos para sua compreensão e resolução. 2010. 492f.
Dissertação (Doutorado) – Doutor em Engenharia Informática – Universidade de
Coimbra, 2010.

GUEDES, Gilleanes Thorwald Araujo. UML: uma abordagem prática. 2. ed. São
Paulo: Novatec Editora, 2013.

HEUSER, Carlos Alberto. Projeto de banco de dados. 6. ed. Porto Alegre:

Bookman, 2009.

HIRAMA, Kechi. Engenharia de software: qualidade e produtividade com

tecnologia. 1. ed. Rio de Janeiro: Elsevier, 2011.

MACÊDO, Diego. Modelos de Ciclo de Vida. 2012. Disponível em:

<https://www.diegomacedo.com.br/modelos-de-ciclo-de-vida/>. Acesso em: 27 nov.
2018.

MILANI, André. MySQL: guia do programador. 1. ed. São Paulo: Novatec Editora,
2006.

MILANI, André. PostgreSQL: guia do programador. 1. ed. São Paulo: Novatec

Editora, 2008.

NIEDERAUER, Juliano. Desenvolvendo Websites com PHP. 2. ed. São Paulo:

Novatec Editora, 2011.

OTTO, Mark. Bootstrap from Twitter. 2011. Disponível em:

<https://blog.twitter.com/developer/en_us/a/2011/bootstrap-twitter.html>. Acesso em:
26 nov. 2018.
 62

SILVA, Alessandra Galvão da. A importância dos métodos ágeis na engenharia

de software – Projeto Final (Tecnólogo em Sistemas de Computação) –
Universidade Federal Fluminense, Niterói, 2016.

SILVA, Maurício Samy. Fundamentos de HTML5 e CSS3. 1. ed. São Paulo:

Novatec Editora, 2015.

GONÇALVES, Eduardo. SQL. Uma abordagem para banco de dados Oracle. 1.

ed. São Paulo: Casa do código, 2014.

SOARES, Walace. PHP 5: Conceitos, Programação e Integração com Banco de

dados. 7. ed. São Paulo: Érica Ltda, 2010.