tcc-sissuporte-versaofinal pdf versão 1

Prévia do material em texto

UNIVERSIDADE ESTÁCIO DE SÁ
TCC EM SISTEMAS DE INFORMAÇÃO-EAD
 Professor Orientador: MSc. José Carlos Millan
 Professora Orientadora: MSc. Claudia Abreu Paes
2015
SISUPORTI – Sistema de Suporte Orientado a Tecnologia da Informação
Trabalho apresentado na disciplina de Projeto TCC
EM SISTEMAS DE INFORMAÇÃO-EAD da
Universidade Estácio de Sá, como requisito parcial
para obtenção do grau de Bacharel em Sistemas de
Informação.
Autor:
RENATO EVARISTO ALFAIA
Orientadores: 
MSc José Carlos Millan 
MSc. Claudia Abreu Paes
2015
SISSUPORTI – Sistema de Suporte Orientado a Tecnologia da Informação
RENATO EVARISTO ALFAIA
201101377704
Trabalho apresentado na disciplina de Projeto TCC
EM SISTEMAS DE INFORMAÇÃO da
Universidade Estácio de Sá, como requisito parcial
para obtenção do grau de Bacharel em Sistemas de
Informação.
Aprovado em dezembro de 2014.
BANCA EXAMINADORA
________________________________________
Prof. MSc José Carlos Millan - Orientador
Universidade Estácio de Sá
________________________________________
Prof. MSc Claudia Abreu Paes - Orientadora
Universidade Estácio de Sá
2015
Reitora
Paula Caleffi, DSc
Vice-Reitoria de Graduação
Vinícius da Silva Scarpi, DSc
Vice-Reitoria de Pós-Graduação e Pesquisa
Luciano Vicente de Medeiros, PhD
 
Vice-Reitoria de Cultura
Cipriana Nicolitt Cordeiro Paranhos, DSc
Documento elaborado por: RENATO EVARISTO ALFAIA
SISSUPORTI - Sistema de Suporte Orientado a 
Tecnologia da Informação / por RENATO EVARISTO 
ALFAIA. – Niterói, RJ: [s.n.], 2015.
nº págs f., 29 cm.
Trabalho de conclusão do curso de informática – 
Faculdade Estácio de Sá, Campus Madureira, Curso de 
Sistemas de Informação, 2015.
Orientador: MSc Jose Carlos Millan
Orientadora: MSc Claudia Abreu Paes
Unitermos: 1. Sistema. 2. Ativos de T.I. 
 
Ficha Catalográfica
VI
RESUMO
Com as novas demandas tecnológicas do Século XXI as Corporações tem sentindo
dificuldades para o gerenciamento correto de seus parques informáticos. Este fato leva a
vários problemas como perda de receita, baixa produtividade no ambiente computacional,
falta de controles de técnicos e insumos, falta de segurança de servidores, etc. Outro
problema é a falta de controle das manutenções programadas e solicitadas, a necessidade
de insumos (peças e equipamentos de TI) e as principais métricas para a avaliação do
serviço que está sendo executado.
O principal objetivo deste programa é organizar o ambiente de T.I. de uma
empresa, desde de a entrada de um Recurso Computacional em uma Rede Corporativa,
gerenciando sua manutenção, os insumos necessários para manutenção desta Estação, os
tempos de manutenção de serviços, históricos dos problemas e a resolução destes e
métricas de serviços para os gestores de T.I. tomarem decisões baseados nestes dados.
Outro diferencial será utilização plena de ferramentas e software livres, o que
barateiam muito a manutenção e o desenvolvimento do sistema.
Para isso, doravante chamaremos este sistema como SISSUPORTI – Sistema de
Suporte Orientado a Tecnologia da Informação. 
Palavras-chave:1. Sistema. 2. Suporte de T.I. 3. Segurança e Gerenciamento
de T.I .
VII
ABSTRACT
With the new technological demands of the twenty-first century corporations have
felt difficulties to the correct management of its IT parks. This leads to various problems
such as loss of revenue, low productivity computing environment, lack of controls and
technical inputs, lack of security servers, etc. Another problem is the lack of control of
scheduled and required maintenance, the need for inputs (parts and IT equipment) and key
metrics for evaluating the service being performed.
The main objective of this program is to organize the IT environment of a
company, since the entry of a Computational brought on a Corporate Network by
managing its maintenance, inputs necessary for maintaining this station, service
maintenance times, historical problems and the resolution of these metrics and services for
IT managers make decisions based on that data.
Another difference will be full use of free tools and software, which greatly
cheapen the maintenance and development of the system.
For this henceforth call this system as SISSUPORTI - Support System Oriented
Information Technology.
Keywords: 1 . System. 2. Support 3. Security and IT Management.
VIII
LISTA DE ILUSTRAÇÕES
Figura 1: Organograma da DHN Fonte: Regulamento da DHN................................................................20
Figura 2: Tela de Abertura do sistema atual Fonte: printscreen do Sistema............................................23
Figura 3: Tela pós-login do Sistema Atual Fonte: printscreen do Sistema................................................23
Figura 4: Diagrama de caso de uso RF001 Fonte: Programa Astah – elaborado pelo autor...................29
Figura 5: Diagrama de caso de uso RF002 Fonte: Programa Astah – elaborado pelo autor...................30
Figura 6: Diagrama de caso de uso RF003 Fonte: Programa Astah – elaborado pelo autor...................31
Figura 7: Diagrama de caso de uso RF004 Fonte: Programa Astah – elaborado pelo autor…………...32
Figura 8: Diagrama de caso de uso RF005 Fonte: Programa Astah – elaborado pelo autor...................33
Figura 9: Diagrama de caso de uso RF006 Fonte: Programa Astah – elaborado pelo autor...................34
Figura 10: Diagrama de caso de uso RF007 Fonte: Programa Astah – elaborado pelo autor.................35
Figura 11: Diagrama de caso de uso RF008 Fonte: Programa Astah – elaborado pelo autor.................36
Figura 12: Diagrama de caso de uso RF009 Fonte: Programa Astah – elaborado pelo autor.................37
Figura 13: Diagrama de caso de uso RF010 Fonte: Programa Astah – elaborado pelo autor.................38
Figura 14: Diagrama de caso de uso RF011 Fonte: Programa Astah – elaborado pelo autor.................39
Figura 15: Diagrama de caso de uso RF012 Fonte: Programa Astah – elaborado pelo autor.................40
8Figura 16: Diagrama de caso de uso RF013 Fonte: Programa Astah – elaborado pelo autor...............41
Figura 17: Diagrama de caso de uso RF014 Fonte: Programa Astah – elaborado pelo autor.................42
Figura 18: Diagrama de caso de uso RF015 Fonte: Programa Astah – elaborado pelo autor.................43
Figura 19: Diagrama de caso de uso RF016 Fonte: Programa Astah – elaborado pelo autor.................44
Figura 20: Diagrama de caso de uso RF017 Fonte: Programa Astah – elaborado pelo autor.................45
Figura 21: Diagrama de caso de uso RF018 Fonte: Programa Astah – elaborado pelo autor.................46
Figura 22: Diagrama de caso de uso RF019 Fonte: Programa Astah – elaborado pelo autor.................47
Figura 23: Diagrama de caso de uso RF020 Fonte: Programa Astah – elaborado pelo autor.................48
Figura 24: Diagrama de caso de uso RF021 Fonte: Programa Astah – elaborado pelo autor.................49
Figura 25: Diagrama de caso de uso RF022 Fonte: Programa Astah – elaborado pelo autor.................50
Figura 26: Diagrama de caso de uso RF023 Fonte: Programa Astah – elaborado pelo autor.................51
Figura 27: Diagrama de caso de uso RF024 Fonte: Programa Astah – elaborado pelo autor.................52
Figura 28: Diagrama de caso de uso RF025 Fonte: Programa Astah – elaborado pelo autor.................53
Figura 29: Diagrama de caso de uso RF026 Fonte: Programa Astah – elaborado pelo autor.................53
Figura 30: Diagrama de caso de uso RF027 Fonte: Programa Astah – elaborado pelo autor.................54
Figura 31: Diagrama de caso de uso RF028 Fonte: Programa Astah – elaborado pelo autor.................55
Figura 32: Diagrama de casos de usos do Sistema SISSUPORTI Fonte: Programa DBDesigner 4 –
elaborado pelo autor..............................................................................................................................56Figura 33: Diagrama de classes do Sistema SISSUPORTI Fonte: Programa BRModelo – elaborado
pelo autor................................................................................................................................................57
Figura 34: Visão Geral do Modelo Relacional do Banco de Dados do Sistema SISSUPORTI Fonte:
Programa Power Architech – elaborado pelo autor..........................................................................65
Figura 35: Diagrama Entidade-Relacionamento Fonte: Programa BRModelo – elaborado pelo autor
..................................................................................................................................................................65
IX
Figura 36: Diagrama de Sequência Usuário Normal Fonte: Programa Astah – elaborado pelo autor. .66
Figura 37: Diagrama de Sequência Usuário Técnico (Pessoa) Normal Fonte: Programa Astah –
elaborado pelo autor..............................................................................................................................67
Figura 38: Diagrama de Sequência Usuário Técnico (Pessoa/Ocorrência) Fonte: Programa Astah –
elaborado pelo autor..............................................................................................................................67
Figura 39: – Diagrama de Sequência Usuário Técnico (Pessoa/Estação de Trabalho/Inventário) –
Fonte: Programa Astah – elaborado pelo autor..................................................................................68
Figura 40: Diagrama de Estados Classe Pessoa Fonte: Programa Astah – elaborado pelo autor...........69
Figura 41: Diagrama de Estados Estação de Trabalho Fonte: Programa Astah – elaborado pelo autor
..................................................................................................................................................................69
Figura 42: Diagrama de Estados Ocorrência Fonte: Programa Astah – elaborado pelo autor...............70
Figura 43: Diagrama de Estados Inventário Fonte: Programa Astah – elaborado pelo autor................70
Figura 44: Diagrama de Atividades Cadastro de Pessoas Fonte: Programa Astah – elaborado pelo
autor........................................................................................................................................................71
Figura 45: Diagrama de Atividades Estação de Trabalho Fonte: Programa Astah – elaborado pelo 
autor........................................................................................................................................................72
Figura 46: Diagrama de Atividades Ocorrência Fonte: Programa Astah – elaborado pelo autor.........73
Figura 47: Diagrama de Atividades Cadastros Tipo de Peças Fonte: Programa Astah – elaborado pelo 
autor........................................................................................................................................................73
Figura 48: Modelo Físico dos dados Fonte: Programa Astah – elaborado pelo autor..............................74
Figura 49: Diagrama de Componentes Fonte: Programa Astah – elaborado pelo autor.........................84
Figura 50: Diagrama de Implantação Fonte: Programa Astah – elaborado pelo autor...........................85
X
LISTA DE TABELAS
Tabela 1: Diagrama de Gautt:Fonte: elaborado pelo autor........................................................................18
Tabela 2: Requisitos Funcionais Fonte: elaborado pelo autor....................................................................27
Tabela 3: Requisitos não-funcionais Fonte: elaborado pelo autor..............................................................27
Tabela 4: Classe Pessoa Fonte: Fonte: elaborado pelo autor......................................................................59
Tabela 5: Classe Usuário-Técnico Fonte: elaborado pelo autor................................................................59
Tabela 6: Classe Usuário Supervisor-Técnico Fonte: elaborado pelo autor.............................................60
Tabela 7: Classe Usuário-Gestor Fonte: elaborado pelo autor..................................................................60
Tabela 8: Classe Estação de Trabalho Fonte: elaborado pelo autor.........................................................61
Tabela 9: Classe Ocorrência Fonte: elaborado pelo autor.........................................................................62
Tabela 10: Classe Area_Ocorrência Fonte: elaborado pelo autor.............................................................62
Tabela 11: Classe Status_Ocorrencia Fonte: elaborado pelo autor...........................................................62
Tabela 12: Classe Avaliação_Ocorrência Fonte: elaborado pelo autor....................................................63
Tabela 13: Classe Estoque Fonte: elaborado pelo autor.............................................................................63
Tabela 14: Classe Peças Fonte: elaborado pelo autor..................................................................................64
Tabela 15: Classe Saída_Peças_estoque Fonte: elaborado pelo autor........................................................64
Tabela 16: Classe Entrada_Peças_estoque Fonte: elaborado pelo autor...................................................64
Tabela 17: Tabela Grupos Fonte: elaborado pelo autor..............................................................................74
Tabela 18: Tabela Pessoa Fonte: elaborado pelo autor...............................................................................75
Tabela 19: Tabela Estação de Trabalho Fonte: elaborado pelo autor.......................................................76
Tabela 20: Tabela Ocorrencia Fonte: elaborado pelo autor.......................................................................77
Tabela 21: Tabela area_ocorrencia Fonte: elaborado pelo autor..............................................................77
Tabela 22: Tabela Status ocorrênica Fonte: elaborado pelo autor...........................................................78
Tabela 23: Tabela avaliação ocorrência Fonte: elaborado pelo autor........................................................78
Tabela 24: Tabela Peças Fonte: elaborado pelo autor.................................................................................78
Tabela 25: Tabela Peças X ET Fonte: elaborado pelo autor.......................................................................79
Tabela 26: Tabela Saída estoque Fonte: elaborado pelo autor...................................................................79
Tabela 27: Tabela Entrada Peças Estoque Fonte: elaborado pelo autor...................................................80
Tabela 28: Tabela Estoque Fonte: elaborado pelo autor.............................................................................80
XI
LISTA DE ABREVIATURAS E SIGLAS
SISSUPORTI Sistema de Suporte Orientado a Tecnologia da Informação
DHN Diretoria de Hidrografia e Navegação
CLTI Centro Local de Tecnologia da Informação
CPD Centro de Processamento de Dados
MB Marinha do Brasil
HD Hard Disk
E.T. Estação de Trabalho
TRI Termo de Responsabilidade Individual
TRET Termo de Responsabilidade da Estação de Trabalho
UML Linguagem de Modelagem Unificada
DHN Diretoria de Hidrografia e Navegação
BHMN Base de Hidrografia da Marinha em Niterói
GNHO Grupamento de Navios Hidroceanográficos
CHM Centro de Hidrografia da Marinha
CAMR Centro de Sinalização e Reparos Almirante Moraes Rego
TB Terabyte
GB Gigabyte
CNPA Complexo Naval da Ponta da Armação
IP Internet Protocol
MAC-ADDRESS Media Access Control Address
GNU GNU is Not Unix
GPL General Public License 
SUSE Software und System-Entwicklung 
RF Requisito Funcional
RNF Requisito não Funcional
DHCP Dynamic Host Configuration Protocol
XII
SUMÁRIO
1. Proposta de Trabalho.............................................................................................171.1. Método de Trabalho...............................................................................................17
1.2. Previsão de Alocação de Recursos........................................................................17
1.3. Cronograma do Trabalho ......................................................................................18
2. Caracterização da Empresa e do Negócio.............................................................18
2.1. Histórico da Empresa.............................................................................................19
2.2. Atividade da Empresa............................................................................................20
2.3. Organograma.........................................................................................................20
2.4. Mercado Consumidor............................................................................................20
2.5. Concorrência..........................................................................................................21
2.6. Aspectos Tecnológicos..........................................................................................21
2.7. Condicionantes......................................................................................................21
3. O Sistema Atual.....................................................................................................21
3.1. Justificativa da Escolha da Área do Sistema.........................................................21
3.1.1. O Sistema..............................................................................................................21
3.1.2. Funcionamento do Sistema....................................................................................22
3.1.3. O ambiente do Sistema..........................................................................................22
3.1.4. A definição do escopo...........................................................................................23
3.2. Motivação para o novo sistema.............................................................................24
3.3. Situação Desejada..................................................................................................24
3.4. Problemas do sistema atual....................................................................................24
XIII
4. O sistema proposto (projeto lógico)......................................................................26
4.1. Lista de Requisitos do Sistema..............................................................................26
4.2. Atores do Sistema..................................................................................................28
4.3. Casos de Uso e suas epecificações........................................................................29
4.3.1. Caso de Uso RF001 – Realizar Login ..................................................................29
4.3.2. Caso de Uso RF002 – Realizar Logoff .................................................................30
4.3.3. Caso de Uso RF003 – Trocar senha do Usuário ...................................................31
4.3.4. Caso de Uso RF004 – Bloquear Acesso ao Sistema .............................................32
4.3.5. Caso de Uso RF005 – Desbloquear Acesso ao Sistema .......................................33
4.3.6. Caso de Uso RF006 – Cadastrar usuário ..............................................................34
4.3.7. Caso de Uso RF007 – Cadastrar Estação de Trabalho .........................................35
4.3.8. Caso de Uso RF008 – Monitorar Estação de Trabalho ........................................36
4.3.9. Caso de Uso RF009 – Inserir/Verificar Documentação .......................................34
4.3.10. Caso de Uso RF010 – Assimilar Estação de Trabalho a usuário..........................35
4.3.11. Caso de Uso RF011 – Abrir Chamados ................................................................36
4.3.12. Caso de Uso RF012 – Atender Chamados ...........................................................40
4.3.13. Caso de Uso RF013 – Movimentar Chamados......................................................41
4.3.14. Caso de Uso RF014 – Fechar Chamados/Avaliar Chamados/Arquivar Chamados ........42
4.3.15. Caso de Uso RF015 – Desassimilar Estação de Trabalho de Usuário .................43
4.3.16. Caso de Uso RF016 – Verificar Histórico ...........................................................44
4.3.17. Caso de Uso RF017 – Pesquisar Usuários ............................................................45
4.3.18. Caso de Uso RF018 – Cadastrar Peças .................................................................46
XIV
4.3.19. Caso de Uso RF019 – Liberar/Bloquear Acesso de Estação de Trabalho ............47
4.3.20. Caso de Uso RF020 – Alterar Poder de Usuário ..................................................48
4.3.21. Caso de Uso RF021 – Pesquisar Tipo e Quantidade de Peças .............................49
4.3.22. Caso de Uso RF022 – Gerar relatórios de usuários ..............................................50
4.3.23. Caso de Uso RF022 – Gerar relatórios de Estações de trabalho ..........................51
4.3.24. Caso de Uso RF024 – Gerar Relatórios de Atendimento .....................................52
4.3.25. Caso de Uso RF025 – Criar métricas de atendimento ..........................................53
4.3.26. Caso de Uso RF026 – Trilha de Auditoria ...........................................................53
4.3.27. Caso de Uso RF027 – Criar Tipos de Manutenção ..............................................54
4.3.28. Caso de Uso RF028 – Criar Areas de Manutenção ..............................................55
4.4. Diagrama de Casos de Uso ...................................................................................56
4.5. Modelo Conceitual de Classes ..............................................................................57
4.5.1. Dicionário de dados das classes do Sistema ........................................................58
4.6. Modelo Conceitual de Dados ................................................................................64
4.6.1. Visão Geral do Modelo Relacional ......................................................................65
4.6.2. Diagrama Entidade-Relacionamento ...................................................................65
4.7. Diagrama de Sequência ........................................................................................66
4.7.1. Usuário-Normal ....................................................................................................67
4.7.2 Usuário-Técnico ...................................................................................................67
4.8. Diagrama de Estados ............................................................................................68
4.8.1. Classe Pessoa.........................................................................................................66
4.8.2. Classe Estação de Trabalho ..................................................................................69
XV
4.8.3 Classe Ocorrência .................................................................................................70
4.8.4 Classe Inventário ..................................................................................................71
4.9 Diagrama de Atividades .......................................................................................71
4.9.1. Cadastro de Pessoas ..............................................................................................71
4.9.2. Cadastro de Estação de Trabalho ..........................................................................72
4.9.3 Classe Ocorrência .................................................................................................72
4.9.4 Cadastro de Tipo de Peças ....................................................................................735. O Projeto Físico ....................................................................................................73
5.1 Modelo Físico de Dados .......................................................................................73
5.1.1 Projeto de Tabelas e Arquivos .............................................................................74
5.2 Ambiente do Sistema ............................................................................................82
5.2.1 Definição do Ambiente físico ...............................................................................82
5.2.2 Justificativa da escolha da Linguagem de Programação e do SGDB ...................83
6. Arquitetura do Sistema .........................................................................................83
6.1 Diagrama de Componentes ...................................................................................83
6.2 Diagrama de Implantação .....................................................................................85
7. Conclusões ............................................................................................................86
7.1 Reflexões sobre os objetivos iniciais alcançados .................................................86
7.2 Vantagens do sistema para a empresa ..................................................................87
7.3 Tabalhos Futuros ..................................................................................................87
REFERÊNCIAS BIBLIOGRÁFICAS.................................................................................88
Anexo I – Glossário..............................................................................................................90
XVI
Anexo II – Modelo de TRET...............................................................................................96
Anexo III – Modelo de TRI..................................................................................................97
 
17
1 - Proposta de Trabalho
A proposta de desenvolvimento do SISSUPORTI utilizará as mais modernas
metodologias de desenvolvimento de Software descritas a seguir:
1.1 - Método de Trabalho
Será utilizado o ambiente virtualizado para os testes com o Sistema, para a
modelagem UML será a utilizada a ferramenta ASTAH, além disso o ambiente dos
serviços deverá ser obrigatoriamente Servidores SUSE Linux para adequação ao ambiente
da organização. Utilizaremos a Linguagem JAVA utilizando a IDE NETBEANS e o
Banco de Dados, na medida do possível, deverá ser o PostgreSQL que também possui
uma versão livre para desenvolvimento. Ainda haverá um momento de pesquisas no
momento do levantamento de requisitos para uma melhor entendimento das demandas da
empresa.
1.2 - Previsão de Alocação de Recursos
A) Pessoal
02 Professores Orientadores
01 Aluno do Curso de Sistemas de Informação 
B) Material
 Sala;
uma mesa com duas cadeiras;
Três computadores (três notebooks e um desktop);
Uma impressora;
Quadro branco com apagador e canetas;
Materiais de escritório (papel, caneta, lápis, pranchetas e etc);
Dois HDs Externos de 1 TB;
Quatro Pendrives de 16GB;
DVDs contendo os Sistemas Operacionais Linux e os programas necessários para
construção do sistema.
18
1.3 - Cronograma do Trabalho 
Fase Mês 1 Mês 2 Mês 3 Mês 4 Mês 5 Mês 6
Levantamento de
Requisitos
21
dias
Modelagem 21
dias
Desenvolvimento 105 dias
Testes e 
Correções
42 dias
Implantação 
(DHN)
28 dias
Homologação do
Usuário
28 dias
Tabela 1 – Diagrama de Gautt
O plano de execução das atividades do projeto terá sua contagem iniciada após a
alocação dos recursos necessários a sua efetivação, quais sejam: pessoal qualificado e
com dedicação exclusiva ao projeto, disponibilização do espaço físico (local isolado para
evitar que os desenvolvedores se desconcentrem), e disponibilização de equipamentos
para a equipe.
Ressalta-se que será inviável iniciar o projeto sem os recursos acima citados,
visando o não comprometimento do planejamento e da execução das atividades, evitando-
se, assim, o atraso no cronograma do plano de execução das atividades do projeto.
O cronograma do plano de execução das atividades do projeto considera que toda a
equipe trabalhará todos os dias úteis da semana durante o horário de expediente (entre
08:00hs as 17:30hs)
2 - Caracterização da Empresa e do Negócio
A empresa a ser utilizada será a Diretoria de Hidrografia e Navegação (DHN)
órgão subordinado ao Comando da Marinha (MB) que tem sede em Niterói, RJ
19
2.1 - Histórico da Empresa
A atual Diretoria de Hidrografia e Navegação (DHN) foi criada pelo Decreto
Imperial nº 6113, de 02 de fevereiro de 1876, sob a denominação de Repartição da Carta
Marítima. Em 1914 teve ampliadas suas atribuições e, em consequência disto, transferida
para a Ilha Fiscal quando deixou o casarão da rua Dom Manuel nº 5, que a abrigara por
várias décadas. Em 1923, o nome da repartição é mudado para Diretoria de Navegação da
Marinha e, em 1946 para o atual nome. Em 1983 veio para as suas atuais instalações na
Ponta da Armação. É também o órgão superior do Complexo Naval da Ponta da Armação
(CNPA) e, desde de 2011, assumiu a centralização , gerenciamento e assessoria superior
dos CPDs das Organizações Militares subordinadas que figuram no mesmo complexo
naval. 
2.2 - Atividade da Empresa
A DIRETORIA DE HIDROGRAFIA E NAVEGAÇÃO (DHN) é o órgão da
Marinha do Brasil que tem como propósitos: “apoiar a aplicação do Poder Naval, por
meio de atividades relacionadas com a hidrografia, oceanografia, cartografia,
meteorologia, navegação e sinalização náutica, garantir a qualidade das atividades de
segurança da navegação que lhe couberem na área marítima de interesse do Brasil e nas
vias navegáveis interiores e, ainda, contribuir para projetos nacionais de pesquisa em
águas jurisdicionais brasileiras e dos resultantes de compromissos internacionais.
Para o cumprimento dessas missões, a DHN atua como órgão superior das
Organizações Militares do citado complexo. São elas o Centro de Hidrografia da
Marinha (CHM), a Base de Hidrografia da Marinha em Niterói (BHMN), o Centro de
Sinalização e Reparos “Almirante Moraes Rego” (CAMR), o Grupamento de Navios
Hidroceanográficos (GNHO) e apoia também a Policlínica Naval de Niterói (PNN).
Dentro do âmbito do GNHO, ainda presta gerencia indireta aos seus Navios
Subordinados.
Desde 2011, com a criação do Centro Local de Tecnologia da Informação
(CLTI), assumiu a gerência e assessoria superior dos CPDs das Organizações Militares
acima citadas, sendo, por força de lei, responsável pela governança de TI dos citados
Órgãos.
 
20
2.3 - Organograma
Figura 1 – Organograma da Instiuição
2.4 - Mercado Consumidor
Os principais usuários do serviço serão os usuários das redes corporativas das
Organizações Militares subordinadas (na impressão de documentação relativa a sua
estação de trabalho e solicitação de serviços as mesmas), supervisores e técnicos de TI
dos CPDs (que utilizaram nas respostas as solicitações dos usuários, farão manutenções
previstas, monitoramento de serviços e inventário de TI) e Gestores de TI (que utilizaram
as métricas que programa gerará para melhor avaliação do andamento de serviços e
relatórios para gerência superior). Nada impede que o sistema seja usado no meio civil.
2.5 - Concorrência
Inicialmente, dentro do âmbito militar administrativo, o sistema não sofrerá
concorrência. Porém, se o mesmo for usado no âmbito civil, poderá sofrer concorrência
de alguns sistemas livre como OCOMON (na parte de gerenciamento de serviços) ,
CACIC (na parte de inventário de TI) .
21
2.6 - Aspectos Tecnológicos
Tendo em vista o alto grau de informatização dos processos que a DHN gerencia,
é necessário um controle bem mais apurado dos Recursos Computacionais,bem como,
um melhor gerenciamento das demandas dos setores de Informática subordinados e dos
usuários das redes corporativas, pois uma padronização de configurações, melhora de
maneira substancial a produção dos diversos setores da Instituição. Vale lembrar que as
atualizações computacionais no meio de TI são rápidas e frequentes. Por isso, se os
gestores puderem ter uma visão atualizada de seu parque informático de maneira
dinâmica e arrojada, as demandas poderão ser atendidas com mais rapidez e facilidade.
2.7 Condicionantes
A Instituição possui uma Divisão de Sistemas, o que permite um ambiente de
desenvolvimento bastante satisfatório para cumprimento das etapas para construção do
sistema. Além disso, se houver êxito na implementação do sistema, existe a possibilidade
deste ser homologado no âmbito da Organização, podendo ser utilizado por outras
Organizações da Marinha. Por ser um sistema baseado em Softwares Livres, o custo de
manutenções é reduzido pois não há a necessidade de se gastar recursos com o
licenciamento de softwares.
3 - O Sistema Atual
O sistema utilizado atualmente pelo CLTI-DHN, foi feito em PHP no ano de
2010 e implementa parte do que o sistema proposto fornecerá
3.1 - Justificativa da Escolha da Área do Sistema
3.1.1 - O Sistema
Com o amento das responsabilidades do setor é necessário que o sistema
gerenciador seja o mais preciso possível, sem incorreções nas informações prestadas e
tenha um desenho amigável para o usuário que utilizará suas funcionalidades.
22
Principalmente, pois os usuários serão de outras Organizações que tem subordinação com
a DHN. No caso de uso extra-MB este poderia ser o caso de filiais de uma Empresa. 
3.1.2 - Funcionamento do Sistema
Atualmente o sistema que é utilizado tem atendido parcialmente algumas
funções do que se necessita. É um webservice escrito em PHP que dispõe das seguintes
funcionalidades: Cadastro de Estação de Trabalho, Sistema de Manutenção,
Monitoramento de Serviços e avaliação do usuário. Porém, foi feito com uma interface
muito fraca, base em frames, que dificultam a visualização correta de algumas funções.
Não possui padrões gráficos e nem segue uma trilha correta de auditoria. 
O sistema ainda comanda um DHCP que atualiza o Endereço IP de cada
estação de maneira dinâmica, mas tal gerenciamento é indireto, ou seja, é exportado um
arquivo de configuração para o citado Servidor, o que faz que atualizações do sistema
tenham um atraso de até 3 minutos para que sejam efetivamente efetuadas.
3.1.3 - O ambiente do Sistema
O Sistema foi desenvolvido pela própria equipe do CPD, para resolver o
problema da falta de controles e métricas dos serviços realizados pelos técnicos. Havia
também a necessidade de inventariar o equipamento de informática da Instituição e , além
disso, havia necessidade de se ter registros de quando os serviços eram realizados e
manter um histórico dos atendimentos a um usuário ou estação de trabalho específica.
Devido a estas necessidades e o pouco espaço de tempo para desenvolver o
sistema, foi deixado de lado toda a parte de usabilidade e estética do projeto, o que
acarretá muitos problemas de fontes e imagens que não são padronizadas no programa.
Além de problemas na escrita do programa que, por muitas vezes, provocam travamentos
e certas solicitações do sistema simplesmente não são realizadas, obrigando os técnicos a
realizarem adições diretas no arquivo de banco de dados do sistema, o que não é prático,
tratando-se de um sistema que também é voltado a usuários que não tem vivência em
nessa área de conhecimento.
O programa não gera muitos relatórios, além dos Termos de Responsabilidade
de Usuários, o que também gera vários problemas quando se deseja relatórios de
patrimonio.
Outrossim, não podemos deixar de ressaltar, que foi uma grande inciativa, para
a organização dos principais processos de utilização computacional dentro da empresa,
23
visto que antes, não havia nenhum controle das manutenções ocorridas e nem da
quantidade e qualidade das mesmas, o que acarretava em que as decisões nesse meio
fossem baseadas por “achismos” ou preferencias dos usuários das redes corporativas, o
que dificultava , cada vez mais a organização dos recursos e a padronização das estações
de trabalho, dificultando muito a tarefa de manutenção e segurança dos ativos de TI da
empresa
Figura 2 – Tela de Abertura do sistema atual
Figura 3 – Tela pós-login do Sistema Atual
.
3.1.4 - A definição do escopo
Após a conclusão do seu desenvolvimento o sistema deverá ser capaz de:
- Cadastro de Patrimônio ;
24
- Cadastro de endereços IP
- Inventários de Recursos de TI (peças e equipamentos)
- Monitoramento de serviços (Servidores, Serviços e afins)
- Gerenciamento de Suporte com um ambiente do tipo workflow
- Avaliação dos Usuários dos Serviços
- Geração de Métricas de Serviços (Tempos de Realização dos Pedidos, Pedidos
realizados e concluídos em períodos de tempo selecionados pelo gestor e outras)
- Impressão de relatórios e documentação dos usuários
Além destes , os seguintes produtos deverão estar disponíveis:
- Documentação;
- Código Fonte;
- Sistema SISSUPORTI ; e
- Manual do Usuário.
3.2 - Motivação para o novo sistema
A principal motivação para criação do SISSUPORTI é uma padronização não só 
gráfica como processual das ações de TI, utilizando uma interface amigável e confiável 
para usuários, técnicos e gestores.
Com isso o sistema fornecerá uma visão melhorada do parque computacional da 
Instituição, gerando informações que aumentará a vantagem competitiva dos setores de 
TI, unificando os processos computacionais do Complexo.
3.3 - Situação Desejada
Com a implementação do SISSUPORTI é esperado a facilitação de alguns
processos a saber:
A) Processos a Nível de Usuário Normal
- Abertura de Chamados
- Acompanhamento de Chamados
- Histórico de Manutenções
- Avaliação de Chamados
25
- Impressão de Termo de Responsabilidade Individual
- Impressão de Termo de Responsabilidade de Estação de Trabalho
- Troca de Senhas
B) Processos a Nível de Usuários Técnicos
- Os mesmos dos usuários Normais
- Cadastro de Estações de Trabalho
- Cadastro de Inventário
- Cadastro de Equipamentos Avulsos
- Encerramento de Chamados
- Criação de Servidores para Monitoramento
- Criação de usuários para utilização do sistema
C) Processos a Nível de Usuários Supervisores Técnicos
- Os mesmos dos Usuários Normais
- Os mesmos dos Usuários Técnicos
- Criação de Métricas de Chamados
- Criação de Métricas de Monitoramento
- Criação de Métricas de Inventário
- Solicitação de Obtenção de Inventário e Equipamento
- Autorização de aumento de Poder de usuários
D) Processos a Nível de Usuários Gestores
- Os mesmos dos Usuários Normais
- Os mesmos dos Usuários Técnicos
- Os mesmos dos Usuários Supervisores Técnicos
- Trilha de auditoria
- Relatórios personalizados de Gestão de Serviços e Chamados
- Autorização de Obtenção de Inventário e Equipamentos
3.4 -Problemas do sistema atual
Seguem-se os principais problemas apresentados pelo sistema atual
26
- Falta de Padronização gráfica e estética, gerando uma usabilidade insatisfatória
de usuários que não sejam técnicos;
- A programação não foi padronizada, não seguiu nenhuma norma específica, o
que causa retrabalho quando a problemas de configuração e dá uma sensação de eterno
“protótipo”;
- Falta de trilha de auditoria, que na prática, significa que não há como saber quem
configurou ou deixou de configurar alguma seção do programa;
- Impossibilidade de impressão de relatórios de patrimônio ou pedidos
- Não há uma forma de definição de métricas e nem de como estas serão
cumpridas ou avaliadas pelos gestores.
4.0 - O sistema proposto (projeto lógico)
4.1. Lista de Requisitos do Sistema
A tabelaabaixo apresenta os requisitos funcionais do SISSUPORTI. Lembrando-
se que o processo de levantamento é evolutivo, podendo aparecer novos requisitos não
identificados no processo:
A) REQUISTOS FUNCIONAIS
IDENTIFICAÇÃO NOME
ATRIBUTOS
Beneficio Estabilidade Risco Situação
RF001 Realizar Login Crítico Alta Baixo Proposto
RF002 Realizar Logoff Critico Alta Baixo Proposto
RF003 Trocar senha do Usuário Útil Alta Baixo Proposto
RF004 Bloquear Acesso ao
Sistema
Crítico Alta Baixo Proposto
RF005 Desbloquear Acesso ao
Sistema
Crítico Alta Baixo Proposto
RF006 Cadastrar usuário Crítico Alta Baixo Proposto
RF007 Cadastrar Estação de
Trabalho
Crítico Alta Baixo Proposto
RF008 Monitorar Estação de
Trabalho
Importante Alta Baixo Proposto
27
RF009 Inserir/Verificar
Documentação
Útil Alta Baixo Proposto
RF010 Assimilar Estação de
Trabalho a usuário
Crítico Alta Baixo Proposto
RF011 Abrir Chamados Importante Alta Baixo Proposto
RF012 Atender Chamados Importante Alta Baixo Proposto
RF013 Movimentar Chamados Importante Alta Baixo Proposto
RF014 Fechar Chamados/Avaliar
Chamados/Arquivar
Chamados
Importante
Alta Baixo Proposto
RF015 Desassimilar Estação de
Trabalho de Usuário
Crítico Alta Baixo Proposto
RF016 Verificar Histórico Útil Alta Baixo Proposto
RF017 Pesquisar Usuários Útil Alta Baixo Proposto
RF018 Cadastrar Peças Crítico Alta Baixo Proposto
RF019 Liberar/Bloquear Acesso
de Estação de Trabalho
Crítico Alta Baixo Proposto
RF020 Alterar Poder de Usuário Importante Alta Baixo Proposto
RF021 Pesquisar Tipo e
Quantidade de Peças
Útil Alta Baixo Proposto
RF022 Gerar relatórios de usuários Útil Alta Baixo Proposto
RF023 Gerar relatórios de
Estações de trabalho
Útil Alta Baixo Proposto
RF024 Gerar Relatórios de
Atendimento
Útil Alta Baixo Proposto
RF025 Criar métricas de
atendimento
Importante Alta Baixo Proposto
RF026 Trilha de Auditoria Critico Alta Baixo Proposto
RF027 Criar Tipos de Manutenção Crítico Alta Baixo Proposto
RF028 Criar Areas de Manutenção Crítico Alta Baixo Proposto
Tabela 2 – Requisitos Funcionais
A próxima tabela relaciona os requisitos não-funcionais do sistema identificados
para o projeto, mostrando detalhes de cada um deles.
B) REQUISITOS NÃO FUNCIONAIS
IDENTIFICAÇÃO NOME
ATRIBUTOS
Beneficio Estabilidade Risco Situação
RNF001 Escalabilidade Útil Alta Baixo Proposto
RNF002 Manutenção Útil Alta Baixo Proposto
28
RNF003 Performance Útil Alta Baixo Proposto
Tabela 3 – Requisitos não-funcionais
4.2 . IDENTIFICAÇÃO DOS ATORES DO SISTEMA
A analise dos requisitos fornecidos para o projeto até o momento sugere a
seguinte matriz de responsabilidade:
Usuário Normal - É o usuário da rede corporativa que terá a Estação de Trabalho
vinculada ao seu login. Ele tem poderes para visualizar e imprimir os documentos
relacionados à sua conta, como Termo de Responsabilidade Individual (TRI), Termo de
Responsabilidade da Estação de Trabalho (TRET), bem como, verificar as atualizações
feitas pelos usuários de suporte em sua Estação de Trabalho, o histórico de usuários que
já tenham usado sua Estação e ainda, abrir chamados de suporte e avaliar estes chamados.
Usuário Técnico - Além de ter todas as funcionalidades de um usuário normal, é
o elemento capacitado a responder os chamados dos usuários, movimentado-os, quando
for necessário, para outras áreas e encerrando-os quando o trabalho for executado pelo
mesmo. Além disso, tem o controle do inventário de material de informático, inserindo ou
retirando insumos, para criar uma nova estação de trabalho. Podem assimilar estações de
trabalho a usuários normais e tem o serviço avaliado pelos mesmos. Além disso, tem o
poder de liberar ou bloquear uma estação de trabalho na rede corporativa in site e criam
monitoramentos de servidores. Tem poderes para criar usuários normais.
Usuário Supervisor Técnico – Estão um nível acima dos usuários Técnicos, pois
criam métricas de serviços para serem acompanhadas pelos Usuários Gestores. Além
disso, quando um usuário técnico cria uma Estação de Trabalho, é este usuário que deve
autorizar a criação da mesma, procedimento este, que deve ser feito somente quando uma
nova estação de trabalho entra em produção. Também atendem chamados se tiverem um
área associada a eles.
Usuários Gestores - É o nível administrativo do sistema. É o usuário com plenos
poderes, além de verificarem as métricas criadas pelos usuários Supervisores Técnicos.
Este usuário terá, além de todos os poderes dos usuários anteriormente citados, o poder de
criar os relatórios de gestão, para avaliação do andamento das demandas de serviços. É
este usuário, que além de ter poder de criar usuários normais, pode elevar o poder dos
usuários criando assim outros usuários técnicos, supervisores técnicos e gestores.
29
Usuários Autenticados – É um agrupamento de usuários que é composto por
todos os usuários acima citados
4.3 .Casos de Uso e suas Especificações
De acordo com os requisitos funcionais citados acima, serão definidos os casos de 
uso utilizados no sistema
4.3.1. Caso de Uso RF001 – Realizar Login
Descrição do Caso de Uso: Este caso de uso está relacionado à identificação dos
usuários cadastrados tenham acesso ao SISSUPORTI. Deve permitir aos usuários realizar
login e ter acesso as funcionalidades do sistema de acordo com seus poderes dentro do
mesmo.
O sistema deverá travar o usuário após três tentativas de login invalido,
fornecendo mensagem para entrar em contato com os administradores do sistema. A
identificação do usuário será pelo nome que melhor o identifique e sua senha.
O usuário deverá trocar sua senha a cada 90 dias e não poderá usar a ultima senha
utilizada no sistema devendo ser direcionado para a página inicial do sistema com seu
perfil logado após a execução do login, visualizando a mensagem: “Sr.XXX, Bem vindo
ao SISSUPORTI”
Neste caso específico, o ator “Usuários Cadastrados” é o universo de usuários que
estão devidamente identificados, tendo em vista que o sistema não aceita a visualização
de usuários visitantes
Atores e Casos de Uso
figura 4 – Diagrama de caso de uso RF001
30
Fluxo Básico: O preenchimento dos dados de login corretamente sem ter havido
três tentativas de erro
Fluxo alternativo: O sistema bloqueia automaticamente o usuário após três
tentativas errôneas de login. Nesse caso, deverá ser fornecida uma mensagem dizendo
para o usuário entrar em contato com a área administrativa para liberar o seu acesso.
Pré-condições: Usuário da Rede Corporativa cadastrado no sistema.
Pós-Condições: Usuários logados no sistema com seu perfil correto de acesso
4.3.2. Caso de Uso RF002 – Realizar Logoff
Descrição do Caso de Uso: Este caso de uso refere-se aos usuários cadastrados e
autenticados no sistema que desejem a saída do mesmo. Antes do usuário confirmar a
saída do SISSUPORTI, o sistema deverá enviar a mensagem “Realmente deseja continuar
com a operação” com as opções de sim ou não para que ele decida.
Atores e Casos de Uso
figura 5 – Diagrama de caso de uso RF002
Fluxo Básico: Usuários autenticados solicitam a saída do sistema ao clicar no
botão “Sair”. Logo após deverá ser mostrada uma caixa de opções informando
“Realmente desejá continuar com a operação?” com as opções de sim ou não logo abaixo.
Para sair do sistema deverá clicar “Sim” e o sistema retornará até a página inicial de login
Fluxo alternativo: O usuário decide manter-se no sistema, neste caso deverá
clicar na opção “Não” e o sistema retornará a página inicial de usuário autenticado.
Pré-condições: Usuário autenticado no sistema.
Pós-Condições: Usuários autenticados saem do sistema e o mesmo retorna a
página inicial de login.
31
4.3.3. Caso de Uso RF003 – Trocar senha do 
 Usuário
Descrição do Caso de Uso: Este caso é formulado quando o usuário após ter sido
cadastrado no sistema com uma senha padrão, deve trocar a mesma por uma senha de suaescolha. A senha do usuário deve ser composta de, pelo menos, oito caracteres, sendo
obrigatoriamente, por uma Letra maiúscula, um número e um carácter especial para
melhorar a qualidade da mesma. Deverá haver um validador de senha que classificará a
mesma em FRACA, MÉDIA e FORTE. Senhas fracas não deverão ser aceitas pelo
sistema. 
Atores e Casos de Uso
figura 6 – Diagrama de caso de uso RF003
Fluxo Básico: Por ação do usuário após de cadastrado pela primeira vez no
sistema, por ação a qualquer momento do usuário ou após 90 dias de cadastro da senha
sem mudança da mesma. Senhas fracas não serão aceitas pelo sistema
Fluxo alternativo: Se após os 90 dias ou após criação do usuário, o mesmo terá 5
dias para criação de nova senha. Ao passar por esse período, o usuário será bloqueado e
não poderá ser utilizado enquanto a senha não for alterada
32
Pré-condições: Usuários cadastrados pela primeira vez, que tenham senha por
mais de 90 dias ou usuário autenticado a qualquer momento..
Pós-Condições: Usuário autenticado muda sua senha e aumenta o tempo da
mesma por 90 dias.
4.3.4. Caso de Uso RF004 – Bloquear Acesso ao 
Sistema
Descrição do Caso de Uso: É o caso de uso que após certas condições não
permitem o acesso do usuário ao sistema. O acesso poderá ser bloqueado se o usuário
errar 3 vezes a sua senha, ou se algum usuário da área administrativa fizer este bloqueio.
Toda a vez que o usuário bloqueado tentar o acesso, o sistema deverá enviar uma tela
dizendo. “Usuário Bloqueado, por favor entre em contato com a área administrativas”. 
Todos os usuários da área administrativa podem bloquear usuários normais,
porém, dentro da área administrativa, os usuários só podem bloquear usuários da classe
inferior na seguinte sequência: Usuário Gestor bloqueia Usuário Supervisor Técnico
bloqueia Usuário Técnico bloqueia Usuário Normal
Atores e Casos de Uso
figura 7 – Diagrama de caso de uso RF004
Fluxo Básico: Usuário da Área administrativa bloqueia usuários normais através
de uma lista de usuários do sistema. Essa lista constará apenas dos usuários que tem perfil
33
de acesso menores que o seu. Em outro caso, o usuário se bloqueará automaticamente
quando errar três vezes sua senha de acesso.
Fluxo alternativo: Não há
Pré-condições: Usuário da Área Administrativa bloqueia usuário normal ou
qualquer usuário errar 3 vezes sua senha de acesso.
Pós-Condições: Tela do sistema informando ao Usuário bloqueado que ele está
bloqueado e que o mesmo deve entrar em contato com a área administrativa.
4.3.5. Caso de Uso RF005 – Desbloquear Acesso 
ao Sistema
Descrição do Caso de Uso: Este é o caso de uso que se dá após o usuário
bloqueado solicitar o desbloqueio do mesmo à área administrativa. Neste caso, algum
usuário da mesma efetuara o desbloqueio alterando a condição BLOQUEADO para
ATIVO. No caso de bloqueio de usuários da Área Administrativa, o desbloqueio só
poderá ser feito por um usuário administrativo que tenha maior poder que o mesmo. 
Atores e Casos de Uso figura 8 – Diagrama de caso de uso RF005
Fluxo Básico: Os usuários da Área Administrativa terão a sua disposição uma tela
mostrando todos os usuários que se encontram na condição BLOQUEADO. Para
desbloquear o usuário deverão mudar a sua condição para ATIVO. 
34
Fluxo alternativo: Quando o bloqueio contar com usuários da área
administrativa, somente um usuário de poder maior que o mesmo poderá desbloqueá-lo.
Nesse caso, a tela de usuários bloqueados só constarão os usuários que ele efetivamente
poderá desbloquear.
Pré-condições: Haver usuários bloqueados no sistema por erro de senha ou por
ação dos usuários administrativos.
Pós-Condições: O usuário bloqueado após ação do usuário da área administrativa 
retorna a acessar o sistema
4.3.6. Caso de Uso RF006 – Cadastrar Usuário
Descrição do Caso de Uso: A criação de usuários no sistema é feita por usuários
que tenham poder de “Usuário Técnico” para cima. Este requisito é necessário para que
os usuários da rede corporativa tenham seu primeiro contato com a área técnica.
Inicialmente só poderão ser criados usuários normais e , é poder exclusivo do usuário
gestor a elevação dos poderes destes usuários.
Atores e Casos de Uso
figura 9 – Diagrama de caso de uso RF006
Fluxo Básico: Os usuários da Área Administrativa criam os usuários normais que
terão acesso ao sistema e que terão Estações de Trabalho assimiladas a seus respectivos
nomes. Também serão usuários aptos abrirem chamados.
35
Fluxo alternativo: Não há.
Pré-condições: Solicitação de criação de um usuário.
Pós-Condições: O usuário criado pela área administrativa utiliza o sistema
normalmente
4.3.7. Caso de Uso RF007 – Cadastrar Estação 
de Trabalho
Descrição do Caso de Uso: Neste caso de uso, serão criadas as estações de
trabalho que poderão ser assimiladas a qualquer usuário. Somente os usuários da área
administrativa poderão assimilar estações de trabalho para usuários. O cadastramento da
estação de trabalho se dará pelo preenchimento da configuração da mesma. Servidores
poderão ser cadastrados neste caso de uso, sendo que o cadastro das máquinas
obrigatoriamente retirará peças do inventário de peças. O inventário de peças poderá ter
quantidade negativa das mesmas. Aqui deverão ser dados a Configuração que vira
diretamente das peças cadastradas do Inventário de Peças, número de patrimonio da
estação de trabalho e número de IP, informando o próximo número livre. Para isso,
deverá ser implementado pelo sistema um DHCP, que gerará automaticamente este
número. Porém se o usuário que estiver cadastrando a máquina desejar, poderá inserir
esse número manualmente e o sistema deverá ser capaz definir qual o próximo número IP
livre através de consulta ao DHCP.
Atores e Casos de Uso
figura 10 – Diagrama de caso de uso RF007
Fluxo Básico: Ao cadastrar a estação de trabalho os itens que serão
obrigatoriamente cadastrados são: O número IP e o número de Patrimonio. As outras
informações, apesar de importantes, poderão no primeiro momento serem omitidas
36
Fluxo alternativo: Não há
Pré-condições: Solicitação de criação de uma nova estação de trabalho
Pós-Condições: A estação de trabalho criada fica pronta para ser assimilada a um 
usuário.
4.3.8. Caso de Uso RF008 – Monitorar Estação 
de Trabalho
Descrição do Caso de Uso: Nesse caso de uso especifico, poderão ser incluídas
Estações de Trabalho ou Servidores para monitoramento, ou seja, verificação de atividade
na rede ou não. Em algumas situações, saber qual estação está ativa ou não antes da
verificação de presença de erro pelo usuário é importante para resolução dos problemas
de suporte.
Atores e Casos de Uso
figura 11 – Diagrama de caso de uso RF008
Fluxo Básico: Ao cadastrar a estação de trabalho ou na tela de pesquisa de
estações de trabalho, a mesma poderá ser marcada para monitoramento, que consistirá em
o sistema em um tempo pré-definido verificar se a estação ou servidor está ativo ou não
na rede corporativa. Haverá uma tela especifica para verificar o monitoramento de uma
ou mais estações de trabalho, conforme a necessidade do técnico. Essa constará do nome
da Estação de trabalho, sua função, seu IP e um campo que deverá alterar seu estado
37
quando máquina estiver ativa ou inativa através de um código especifico de cores e
mensagens visuais e sonoras para chamar a atenção dos operadores.
Fluxo alternativo: Não há.
Pré-condições: A estação de trabalho deverá estar cadastrada no sistema.
Pós-Condições: A estação de trabalho cadastrada e marcada para monitoramento, 
comporá uma nova tela onde estará junto com outras estações de monitoramento.
4.3.9. Caso de Uso RF009 – Inserir/Verificar 
Documentação
Descrição do Caso de Uso: Esse caso deuso é onde estarão a inserção e consulta
dos documentos atinentes ao usuário que aqui chamamos de TRI (Termo de
Responsabilidade Individual) e quando houver uma Estação de Trabalho assimilada ao
Usuário, também o TRET (Termo de Responsabilidade de Estação de Trabalho). Esses
são documentos de responsabilidade do usuário dentro da rede corporativa pela posse e
guarda do seu login e do equipamento sob sua responsabilidade.
Atores e Casos de Uso
Figura 12 – Diagrama de caso de uso RF009
Fluxo Básico: Ao cadastrar o usuário, automaticamente deve ser gerado um
modelo de TRI, com o nome e a identificação do usuário pelo sistema. Para o TRET, esse
termo é gerado após assimilação da máquina ao usuário. O sistema só concluirá que o
usuário não tem pendência de documentação após o termo assinado pelo usuário seja
38
escaneado e enviado ao sistema, o que só poderá ser feito por um Usuário Técnico ou
Superior
Fluxo alternativo: Não Há
Pré-condições: Após cadastro do usuário e assimilação de uma Estação de
Trabalho a um usuário.
Pós-Condições: Após a verificação, assinatura e envio do mesmo ao sistema o
usuário entra na condição de NORMAL e o termo poderá ser verificado e impresso pelo
usuário.
4.3.10. Caso de Uso REF010 – Assimilar de 
Trabalho a Usuário
Descrição do Caso de Uso: É o ato de oficialmente colocar a Estação de
Trabalho ou Servidor sob responsabilidade de um usuário. Este caso de uso deve ser
implementado junto com o caso de uso Inserir documentação (TRET), pois este é o
documento formal para recebimento de equipamentos.
Atores e Casos de Uso
figura 13 – Diagrama de caso de uso RF010
Fluxo Básico: Ao assimilar uma Estação de Trabalho a um usuário, o Técnico da
a responsabilidade no sistema daquele equipamento para um usuário que esteja cadastrado
no mesmo. Os TRET são gerados também nesta fase pois este é documento oficial de
recebimento do equipamento
39
Fluxo alternativo: Um usuário poderá ter mais de um equipamento, se no caso
for responsável por eles.
Pré-condições: Usuário cadastrado solicita a inserção de um equipamento.
Pós-Condições: Após a assimilação dá estação de trabalho ela passa a ser de
responsabilidade do usuário
4.3.11. Caso de Uso RF011 – Abrir Chamados
Descrição do Caso de Uso: Este caso de uso se refere ao ato de solicitar um
atendimento de suporte, seja ele relacionado a algum sistema ou a sua Estação de
Trabalho. É esta a interação que há entre os usuários normais e os usuários técnicos
dentro do sistema . Depois de abertos, os chamados são enviados as áreas de atendimento
onde os usuários técnicos poderão atendê-los ou enviá-los as áreas corretas para serem
atendidos. Todos os usuários cadastrados no sistema terão uma visão para verificar os
status dos seus chamados, quer sejam a atender, atendidos, enviados para avaliação e
fechados. Cada usuário normal só terá visão a sua trilha de chamados ou aos chamados
que sejam vinculados a sua estação de Trabalho. Neste caso, mesmos chamados de outros
usuários poderão ser vistos, pois ficarão vinculados as estações de trabalhos assimiladas a
aquele usuário, fazendo parte do histórico de manutenção daquele equipamento. Haverá
um tempo definido por métrica que será criada pelo usuário Supervisor Técnico para que
aquele chamado seja atendido.
Atores e Casos de Uso
figura 14 – Diagrama de caso de uso RF011
Fluxo Básico: O usuário abre um chamado, escolhendo o assunto pré-cadastrado 
no sistema, escreve um relato do problema e insere ou não sua estação de trabalho se ela 
fizer parte do problema citado
40
Fluxo alternativo: Um usuário pode decidir não inserir sua estação de trabalho
quando a mesma não fizer parte da resolução do problema. Neste caso, este chamado só
seria verificado no histórico do usuário.
Pré-condições: Usuário cadastrado solicita a abertura de um chamado de
manutenção
Pós-Condições: Após a abertura do chamado, ele é gravado e passa a constar na
tela de chamados não atendidos até que seja atendido ou movimentado por algum usuário
da área de manutenção.
4.3.12. Caso de Uso RF012 – Atender Chamados
Descrição do Caso de Uso: Este caso de uso se refere ao ato de um usuário da
citada área técnica atender o chamado aberto que consta como não atendido. Neste caso a
contagem de tempo de atendimento chamado zera e começa uma nova contagem para
resolução daquele problema. Esses tempos de chamados serão cadastrados e gravados
pelo sistema que gerará um relatório par os usuários gestores sobre a eficiência dos
atendimentos. Chamados não atendidos no tempo que está cadastrado no sistema, gerarão
mensagens de aviso aos Usuários Supervisores Técnicos e Usuários Gestores para que os
mesmos tomem providências quanto ao atendimento correto, dentro das métricas
estabelecidas pelo sistema
Atores e Casos de Uso
figura 15 – Diagrama de caso de uso RF012
Fluxo Básico: O usuário técnico, que estiver na área do chamado, atende o
chamado e passar a gerenciar o mesmo. Na trilha de auditoria constará que aquele
41
chamado foi atendido pela área correta e por aquele técnico no dia e na horas gravadas no
sistema.
Fluxo alternativo: Os usuários Supervisor Tecnico e Gestor tem acesso em uma
tela no sistema a todos os chamados em abertos e atendidos, podendo movimentá-los se
necessários. Eles também receberão mensagens do sistema se algum chamado não estiver
seguindo as métricas do sistema. Ou seja, quando os tempos definidos nas métricas não
forem respeitados
Pré-condições: Usuário da área técnica atende um chamado, mudando o status
dele de não atendido para Em atendimento.
Pós-Condições: Na tela “chamados do usuário”, o chamado que constava na área 
de não atendidos, passa para área de em atendimento.
4.3.13. Caso de Uso RF013 – Movimentar 
Chamados
Descrição do Caso de Uso: Seguindo a trilha de chamados, este caso de uso, faz
a movimentação de chamados entre as áreas técnicas de atendimento. Os usuários
técnicos podem movimentar chamados depois de atendidos. Os usuários Supervisor
Técnico e Gestor podem movimentar chamados que não estejam atendidos, desde que
estejam com os seus tempos definidos nas métricas estourados. 
Atores e Casos de Uso
figura 16 – Diagrama de caso de uso RF013
42
Fluxo Básico: O usuário técnico, após atender o chamado faz a sua interação e, se
necessário, movimenta o chamado para outra área de atendimento, onde o tempo definido
na métrica é zerado e se inicia na outra área de atendimento. O novo técnico deverá
atender o chamado, mas seu status continuará em atendimento.
Fluxo alternativo: Os usuários Supervisor Tecnico e Gestor tem acesso em uma
tela no sistema a todos os chamados em abertos e atendidos, podendo movimentá-los se
necessários. Eles também receberão mensagens do sistema se algum chamado não estiver
seguindo as métricas do sistema. Ou seja, quando os tempos definidos nas métricas não
forem respeitados
Pré-condições: Usuário da área técnica atende um chamado, mudando o status
dele de não atendido para Em atendimento.
Pós-Condições: Na tela “chamados do usuário”, o chamado que constava na área
de não atendidos, passa para área de em atendimento.
4.3.14. Caso de Uso REF014 – Fechar 
Chamados/Avaliar Chamados/Arquivar Chamados
Descrição do Caso de Uso: Após os usuários técnicos tomarem as ações de
atendimento e suporte, os mesmos encerrarão os chamados e os enviarão para a avaliação
dos usuários. Esta avaliação fará parte também de uma métrica a ser avaliada pelos
gestores. O chamado só será arquivado depois da avaliação do usuário. 
Atores e Casos de Uso
figura 17 – Diagrama de caso de uso RF014
43
Fluxo Básico: O usuário técnico após atender o chamado e fazer suas interações
encerra o chamado e automaticamente o sistema o envia para avaliação do serviço que
consta de satisfatórioe não satisfatório. O sistema arquivará o chamado se a avaliação
satisfatória for obtida
Fluxo alternativo: Se o usuário que abriu o chamado avaliá-lo como Não
satisfatório, o mesmo será automaticamente reaberto e reenviado para a área que o
atendeu pela ultima vez, para que o atendimento seja refeito. Os usuários supervisor
técnico e gestor serão alertados pelo sistema.
Pré-condições: o chamado atendido é encerrado pelo técnico e enviado a área de
avaliação do usuário.
Pós-Condições: Após avaliado o chamado poderá ser arquivado caso a avaliação
seja satisfatória ou voltar para atendimento caso a avaliação não seja satisfatória.
4.3.15. Caso de Uso RF015 – Desassimilar 
Estação de Trabalho de Usuário
Descrição do Caso de Uso: Este caso uso refere-se a desvincular uma estação de
trabalho a um usuário que esteja de posse da mesma. Neste caso, o usuário deixa de ser
responsabilizado pela guarda da estação de trabalho a partir daquele momento. O nome
do usuário constará no Histórico da Estação de Trabalho. O TRET da Estação de
Trabalho é encerrado e o na parte de documentação do usuário constará o TRET mas com
a inscrição ao lado ENCERRADO. A E.T não será mais mostrada na área do usuário.
Atores e Casos de Uso
figura 18 – Diagrama de caso de uso RF015
44
Fluxo Básico: O usuário técnico desassimila a E.T. do usuário, passando este fato 
a constar no histórico do usuário e da E.T. O TRET do usuário passa a constar com 
encerrado 
Fluxo alternativo: Usuário Supervisor Técnico e Gestor também contam com
essa função.
Pré-condições : Estação de Trabalho assimilada a um usuário 
Pós-Condições: Após a desassimilação, a estação de trabalho deixa de ter um
responsável. Esta ação passa a contar no histórico do usuário e da estação de trabalho. A
TRET do usuário passa a ter a inscrição ENCERRADA.
4.3.16. Caso de Uso RF016 – Histórico 
Usuário/Estação de Trabalho
Descrição do Caso de Uso: O Histórico visa manter o controle das
movimentações de estações de trabalho/usuários e vice-versa. Este caso de uso será
gerenciado pelo sistema, que gravará as assimilações e desassimilações de estação de
trabalho, bem como as alterações e bloqueios de senha do usuário 
Atores e Casos de Uso
figura 19 – Diagrama de caso de uso RF016
45
Fluxo Básico: O sistema gerencia as alterações de estações de trabalho e usuários 
e armazenam para futura consulta dos mesmos
Fluxo alternativo: Não há
Pré-condições : Alterações de Estações de Trabalhos e Usuários 
Pós-Condições: As alterações são armazenadas e mostradas aos usuários do
sistema.
4.3.17. Caso de Uso RF017 –Pesquisar Usuários
Descrição do Caso de Uso: O sistema deve propiciar uma pesquisa de usuários 
para os usuários da Área de administração para que eles possam tecer relatórios sobre os 
usuários de suas jurisdições.
Atores e Casos de Uso
figura 20 – Diagrama de caso de uso RF017
Fluxo Básico: Usuários da área técnica fazem pesquisas pelos usuários do sistema
para verem os poderes dos usuários, máquinas assimiladas, documentação, etc.
Fluxo alternativo: Não há.
Pré-condições : Solicitação de pesquisas dos usuários da área administrativa
Pós-Condições: As pesquisas retornam com as premissas colocadas pelos
usuários acima citados.
46
4.3.18. Caso de Uso RF018 – Cadastrar Peças
Descrição do Caso de Uso: O sistema deve prover um cadastro de peças que
estarão disponíveis para utilização do caso de uso, Cadastrar Estação de Trabalho. Dentro
desse escopo, o SISSUPORTI deve dar a opção para o Usuário Técnico de cadastrar uma
peça em várias quantidades, inserir mais quantidades de peças que já existirem e reduzir
dessa quantidade quando as mesmas forem utilizadas no Cadastrar Estação de Trabalho.
Atores e Casos de Uso
figura 21 – Diagrama de caso de uso RF018
Fluxo Básico: Os usuários técnicos cadastram as peças que serão utilizadas no
inventário de peças. É desse inventário que sairão as peças que irão compor os
equipamentos do Caso de Uso “Cadastrar Estação de Trabalho”.
Fluxo alternativo: Apesar da maioria das peças serem utilizadas para o
“Cadastrar Estação de Trabalho”, podem haver peças que não serão usadas por este caso,
bastando o usuário marcar a condição “Equipamento” que deverá estar disponível para o
usuário. Neste caso, a peça não ficará disponível para compor uma estação de
trabalho, podendo ser assimilada diretamente a um usuário.
47
Pré-condições : Cadastro de novas peças e equipamentos no sistema
Pós-Condições: Após o cadastro de peça, o sistema permite que a mesma se torne
disponível para o cadastrar Estação de Trabalho
4.3.19. Caso de Uso REF019 – Liberar Estação 
de Trabalho/Bloquear Estação de Trabalho
Descrição do Caso de Uso: Após o cadastramento da Estação de Trabalho no
sistema é assimilhado um IP, que é o número que permite que a E.T. acesse a Rede
Corporativa. Porém, para facilitar a verificação de conformidades, na primeira vez que a
E.T. entrar me produção, somente um usuário que seja Supervisor Técnico ou Gestor
pode liberá-la. Assim, gera a obrigatoriedade que um usuário com poder mais elevado,
verifique se o trabalho está sendo bem executado pelos Usuários Técnicos. Após esta
primeira verificação, o Usuário Técnico, consegue bloquear e liberar máquinas
normalmente. 
Atores e Casos de Uso
figura 22 – Diagrama de caso de uso RF019
48
Fluxo Básico: Após o cadastramento da Estação de trabalho pelo Usuário
Técnico, a mesma só entrará em funcionamento pela primeira vez, depois do Liberar
Estação pelo Usuário Supervisor Técnico ou pelo Usuário Gestor. Estas funções ficaram
disponíveis para o Usuário Técnico logo após a primeira liberação.
Fluxo alternativo: Se o Usuário Técnico ou Gestor bloquear a Estação, ela
voltara para área de cadastrar com um aviso ao usuário técnico, informando os motivos da
não liberação.
Pré-condições : Após Cadastrar Estação de Trabalho o Secretário-técnico solicita
liberação da máquina para a utilização da Rede Corporativa
Pós-Condições: A máquina tem acesso a Rede Operativa se os Usuários
Supervisor Técnico e Gestor a liberarem ou retornam a função Cadastrar Máquina com
aviso de não liberação, caso contrário.
4.3.20 Caso de Uso REF020 – Alterar poder de 
usuário.
Descrição do Caso de Uso: É função específica do Usuário Gestor. É a ação de
elevar o poder de um usuário qualquer até Gestor. Quando o sistema é criado o primeiro
usuário criado é o Usuário Gestor, que poderá criar usuários normais e, só depois, elevá-
los a condições de técnicos e outros do sistema
Atores e Casos de Uso
 
Figura 23 - Diagrama de caso de uso RF020
49
Fluxo Básico: Após o cadastramento de usuário, o gestor poderá aumentar ou
diminuir o poder dos usuários cadastrados.
Fluxo alternativo: Não há
Pré-condições : Usuários cadastrados no sistema
Pós-Condições: Após a alteração de poder do usuário, ele passa a ter um novo
perfil de usuário.
 4.3.21. Caso de Uso RF021 – Pesquisar Tipo e 
Quantidade de Peças.
Descrição do Caso de Uso: Este caso descreve a possibilidade de pesquisar o
tipo e as quantidades de peças cadastradas no sistema. Esta pesquisa dever ser realizada
pelos usuários da área administrativa do SISSUPORTI
Atores e Casos de Uso
figura 24 – Diagrama de caso de uso RF021
Fluxo Básico: Os usuários da área técnica realizam pesquisas pelo inventário de
peças do sistema.
Fluxo alternativo: Não há
50
Pré-condições : Usuários da área administrativa
Pós-Condições: O sistema retorna as quantidades e os tipos de peças em um
relatório especifico.
4.3.22. Caso de Uso RF022 – Gerar relatórios de 
usuários.
Descrição do Caso de Uso: Gerar relatórios dos usuários do sistema, mostrando 
seu histórico e sua trilha de auditoria.
Atores e Casos de Uso
figura 25 – Diagrama de caso de uso RF022
Fluxo Básico: Usuáriosda área administrativas fazem pesquisas sobre os
Usuários
Fluxo alternativo: Não há
Pré-condições : Usuários da área administrativa
Pós-Condições: Relatório sobre os usuários solicitados
51
4.3.23. Caso de Uso RF023 – Gerar relatórios de 
Estações de trabalho.
Descrição do Caso de Uso: Gerar relatórios das estações de trabalho cadastrada
no sistema, mostrando seus históricos e sua trilha de auditoria.
Atores e Casos de Uso
figura 26 – Diagrama de caso de uso RF023
Fluxo Básico: Gerar relatórios das estações de trabalho cadastradas no sistema,
mostrando seus históricos e sua trilha de auditoria.
Fluxo alternativo: Não há
Pré-condições : Usuários da área administrativa
Pós-Condições: Relatório sobre as estações de trabalho solicitadas.
52
4.3.24. Caso de Uso RF024 – Gerar relatórios de 
atendimento.
Descrição do Caso de Uso: Faz parte da função de Gestão do programa. Permite 
que o usuário Gestor gere e imprima relatórios das Áreas de atendimento do sistema a fim
de avaliá-los e remetê-los, se for necessário, a administração superior. O sistema deve ser 
capaz de gerar vários tipos de relatórios.
Atores e Casos de Uso
figura 27 – Diagrama de caso de uso RF024
Fluxo Básico: O usuário gestor define os parâmetros do relatório e o sistema
deverá retornar as informações relacionadas aos parâmetros informados.
Fluxo alternativo: Não há
Pré-condições : Solicitação do Usuário Gestor
Pós-Condições: Após a definição dos parâmetros do relatório, o sistema deverá
retornar uma tela com os parâmetros solicitados e fornecer a possibilidade de impressão.
4.3.25. Caso de Uso RF025 – Criar Métricas de 
Atendimento.
Descrição do Caso de Uso: É função específica do Usuário Supervisor Técnico.
Nessa função este usuário determina os tempos de execução para ação no sistema de
chamados, definindo as condições para que os atendimentos sejam definidos como dentro
da métrica ou fora dela. São essas definições que ajudam no preenchimento dos relatórios
de atendimento do usuário gestor.
53
Atores e Casos de Uso
figura 28 – Diagrama de caso de uso RF025
Fluxo Básico: O usuário Supervisor Técnico cadastra as métricas que vão ajudar
na criação dos relatórios de atendimento gerados pelo Usuário Gestor.
Fluxo alternativo: Não há
Pré-condições : Usuário Supervisor Técnico cadastra as métricas
Pós-Condições: Após a criação das métricas de atendimento, o sistema começa a
gerenciar a qualidade dos mesmos, gerando os relatórios de atendimento do Usuário
Gestor
4.3.26. Caso de Uso RF026 – Trilha de Auditoria.
Descrição do Caso de Uso: Todas as ações que forem feitas pelos usuários do
sistema devem ser registradas neste caso de uso e fazer parte de uma área do usuário que
constará todos os movimentos quer sejam de atendimentos, de mudança de senha,
mudança de E.T, etc.
Atores e Casos de Uso
figura 29 – Diagrama de caso de uso RF026
54
Fluxo Básico: A trilha de auditoria é automática e crescente, pois todas as ações
deverão ser registradas pelo sistema e visualizadas pelos usuários dentro de seus perfis de
acesso.
Fluxo alternativo: Não há
Pré-condições : Atividades do sistema
Pós-Condições: O sistema registra as atividades e os usuários visualizam de
acordo com seus perfis.
4.3.27. Caso de Uso RF027 – Cadastrar Assuntos 
de Manutenção
Descrição do Caso de Uso: Essa é ação especifica do Usuário Supervisor
Técnico, que cadastra os assuntos de manutenção que podem ser escolhidos pelos
usuários. Logo após, também deve ser cadastradas as métricas para cada assunto.
Atores e Casos de Uso
figura 30 – Diagrama de caso de uso RF027
Fluxo Básico: O usuário Supervisor Técnico faz o cadastro de assunto, que passa
a ser selecionável pelo usuário do sistema
Fluxo alternativo: Após o cadastro do assunto o Usuário Supervisor Técnico tem
a possibilidade de cadastrar a métrica de atendimento daquele assunto.
55
Pré-condições : Usuário Supervisor Técnico cadastra um novo assunto de
manutenção.
Pós-Condições: Após o cadastro do Assunto de manutenção, os usuários podem
selecionar este assunto no sistema
4.3.28. Caso de Uso RF028 – Cadastrar Áreas de 
Manutenção
Descrição do Caso de Uso: Neste caso de uso, o usuário Supervisor Técnico,
cadastra as áreas que atendem aos assuntos que foram criados no caso de uso anterior. E
logo após, insere os usuários que atendem nestas áreas de manutenção. Os usuários
inseridos nas áreas de manutenção devem ser os usuários da área administrativa do
sistema.
Atores e Casos de Uso
figura 31 – Diagrama de caso de uso RF028
Fluxo Básico: O usuário Supervisor Técnico faz o cadastro de área de
atendimento, insere os assuntos daquela área e cadastra os usuários que atendem os
chamados mesma.
Fluxo alternativo: Não há.
56
Pré-condições : Usuário Supervisor Técnico cadastra uma nova área de
manutenção.
Pós-Condições: Após o cadastro do Área de manutenção, nas aberturas de
chamados, o sistema enviara automaticamente para aquela área os assuntos de
atendimentos selecionados. 
4.4 Diagrama de Casos de Uso
Segue abaixo, o diagrama de caso de Uso do Sistema SISSUPORTI:
Figura 32 – Diagrama de casos de usos do Sistema SISSUPORTI
57
4.5 Modelo Conceitual de Classes
Segue-se abaixo o modelo conceitual de classes, baseando-se no prototipo do
SISSUPORTI. Este modelo enfatiza os dados que serão necessários a construção do
Sistema de Informação em desenvolvimento, em vez de suas funcionalidades. Dentre os
outros diagramas da UML, o de Classes é o que possui o maior número de simbolos para
sua diagramação. .
Figura 33– Diagrama de classes do Sistema SISSUPORTI
Algumas funções só serão permitidas, dependendo do nível de usuário. A camada
de segurança de usuários deverá ser implementada num primeiro momento, pois é ela que
definirá os poderes e as areas de atendimento dos usuários e das pessoas a eles
vinculados.
58
A camada de vinculação de Estações de Trabalho só pode ser feita por usuários
com poder acima de técnico.
Na camada de ocorrências, os usuários normais somente abrem chamários ados e
avaliam os mesmos após o fim do atendimento. Cabe aos usuários técnicos a
movimentação dos chamados pela areas de atendimento e encerramento dos mesmos
enviando-os para a avaliação.
Os usuários supervisores criam usuários técnicos e areas de atendimento.
Os usuários gestores criam todos os usuários e fazem o papel de usuários
administradores do sistema.
4.5.1 – Dicionário de dados das classes do Sistema
Classe Pessoa
Descrição SuperClasse que armazena os usuários que terão acesso ao sistema e os
dados das pessoas que compõem o sistema
Atributos Tamanho Formato Descrição
idPessoa - inteiro É o numero identificador da pessoa
login 30 caracter Mome de login do sistema
Depto 20 caracter Departamento do Usuário
CatFuncional 10 caracter É o posto/graduação/cat. Funcional do
usuário
bloqueio 1 boleano Identifcador de bloqueio do usuário
password 30 caracter Campo de senha do usuário
grupo 1 inteiro É o grupo que categoriza o usuário
quando este tiver mais poderes que o
padrão
email 30 caracter
(xxx@xxx.xxx
.xx)
É o correio eletrônico do usuário
Nome Completo 50 caracter Nome completo do usuário
Nome de Guerra 10 caracter Alcunha ou apelido do usuário
TRI assinado 1 boleano Campo que indica se o usuário assinou
seu Termo de Responsabilidade Inicial
TRI digitlizado 1 bollean Indica se o sistema possui a cópia
digitalizada do TRI assinado
Operações Descrição
loginsistema Loga o usuário no sistema
59
abreocorrencia Abre uma ocorrência no sistema
avaliaocorrencia Quando uma ocorrencia é encerrada, ela é enviada para avaliação do
usuário
imprimirTRI Imprime o TRI digitalizado e cadastrado no sistema, só haverá esta
opção se o campo TRI digitalizado estiver selecionado “Sim”.
verifica_andamento_ocorrencia
Quando a ocorrência estiver aberta, o usuário tem como monitorar a
ocorrencia.
Observações
Esta Superclasse representa os poderes básicos que todos os usuários do Sistema possui. 
Representa também o Objeto Usuário-Normal. Quando um usuário tiver poderes maiores 
que este usuário, receberá este poderes especificos das subclasses que a compõe.
Tabela 4 – Classe Pessoa
Classe Usuário-Tecnico
Descrição Sub-Classe de Pessoa, direitos de usuário técnico
Atributos Tamanho Formato Descrição
grupo 1 inteiro Identifica o grupo Usuário-Tecnico
Operações Descrição
atendeocorrencia Poder de atendimento de atendimento de ocorrencias.
movimentaocorrencia Poder de movimentar a ocorrencia para outra area
fechaocorrencia Poder de fechar a ocorrencia e envia-la para a avaliação do usuário
montaET Poder de movimentar peças e gerar uma estação de trabalho
assimilaET Poder de assimilar uma estação de trabalho a uma pessoa
atualizaEstoque Poder de atualizar o estoque de peças com entradas e saidas
bloqueiaET Poder de bloquear o endereço IP de uma estação de trabalho
InsereTRI Poder de inserir um TRI digitalizado a um usuário
cadastrapeças Poder de cadastrar novos tipos de peças no Estoque
insereTRET Poder de inserir um TRET digitalizado a uma Estação de Trabalho
criaUsuario Poder de criar usuários normais do sistema
Observações
Esta é uma sub-classe de pessoa e implementa os poderes de um Usuário-Técnico. Não 
será implementada no BD pois estara contida da SuperClasse Pessoa.
Tabela 5 – Classe Usuário-Técnico
Classe Usuário Supervisor-Técnico
Descrição Sub-Classe de Pessoa, direitos de usuário técnico
Atributos Tamanho Formato Descrição
grupo 1 inteiro Identifica o grupo Usuário Supervisor-
Tecnico
Operações Descrição
60
criamétricas Poder de criar métricas de atendimento e encerramento de
ocorrencias
criaaeraocorrencia Poder de criar areas de atendimento de ocorrencia
criaMonitoramento Poder de criar Estações de Trabalho que terão a atividade
monitorada pelo sistema
criaUsuarioNormal Poder de criar Usuarios normais do Sistema
criaUsuárioTécnico Poder de criação de Usuários-Técnicos
Observações
Esta é uma sub-classe de pessoa e implementa os poderes de um Usuário-Técnico. Não 
será implementada no BD pois estara contida da SuperClasse Pessoa. Como cria Usuários 
Técnicos, recebe também os poderes deste Usuário
Tabela 6 – Classe Usuário Supervisor-Técnico
Classe Usuário Gestor
Descrição Sub-Classe de Pessoa, direitos de usuário técnico
Atributos Tamanho Formato Descrição
grupo 1 inteiro Identifica o grupo Gestor
Operações Descrição
criaallusers É poder máximo do sistema. Faz o papel de usuário Administrador do
Sistema
Observações
Esta é uma sub-classe de pessoa e implementa os poderes de um Usuário-Técnico. Não 
será implementada no BD pois estara contida da SuperClasse Pessoa. É o primeiro usuário
a ser criado no sistema e terá poderes de super-usuário, assim como poder em todos os 
modulos do programa. Cria todos os tipos de usuários, inclusive outros usuários Gestores.
Tabela 7 – Classe Usuário-Gestor
Classe Estação de Trabalho
Descrição Armazena as Estações de Trabalho dos Usuários do Sistema
Atributos Tamanho Formato Descrição
idET - inteiro É o número identificador da Estação
de Trabalho
Numero-IP 15 caracter
999.999.999.999
É o número IP da Estação de
Trabalho
Endereço-Físico 17 caracter
(A9.A9.A9.A9.A9.
A9)
É o endereço físico da Estação de
Trabalho, também conhecido como
“MAC-ADDRESS”.
Num_Patr 11 caracter
(111111111-11)
É o número de Patrimonio da
Estação de Trabalho
TRET_assinado 1 boleano Campo que indica se o usuário
assinou o Termo de
Responsabilidade da Estação de
Trabalho. É também vinculado a
61
pessoa
TRET_digitalizado 1 boleano Indica se o sistema possui a cópia
digitalizada do TRET assinado
Monitora 1 boleano Define que a estação de trabalho terá
monitoramento pelo sistema. É
definido por Usuários que tenha pelo
menos o Poder de Técnico
Bloqueia 1 boleano Define que estação de trabalho será
bloqueada da rede local.
Monitor 100 caracter É o monitor da E.T. recebido pela
classe Peças
Teclado 100 caracter É o teclador da E.T. recebido pela
classe Peças
Mouse 100 caracter É o mouse da E.T. recebido pela
classe Peças
Nobreak 100 caracter É o nobreak da E.T. recebido pela
classe Peças
impressora 100 caracter É a impressora da E.T. recebido pela
classe Peças
outros 100 caracter Qualquer outro equipamento da E.T.
recebido pela classe Peças
Operações Descrição
armazenar Armazena as peças que compõe a E.T.
listar Lista as E.T. que são de responsabilidade do usuário
imprimirTRET Permite a Impressão da T.R.E.T das E.T de responsabilidade do
usuário
selecionar Seleciona a E.T
Tabela 8 – Classe Estação de Trabalho
Classe Ocorrencia
Descrição Armazena os dados de uma ocorrencia aberta pelo usuário
Atributos Tamanho Formato Descrição
Num_Ocorrencia - numero Numerador de ocorrencia
Assunto 20 caracter Assunto da Ocorrencia, recebe assuntos
da classe Area_Ocorrencias
Descrição 150 caracter Descreve a ocorrencia. Descrição do
usuário
idstatus 20 caracter É o status da Ocorrencia. Recebe os
status da classe Status_Ocorrencia
datastatus - Data-hora É data que o status foi inserido ou
alterado
area_ocorrencia 30 caracter É a area que responderá pela
62
ocorrencia. Recebe áreas da classe
Area_Ocorrencia.
idPessoa inteiro É o identificador da Pessoa que abre a
ocorrência
Operações Descrição
Movimenta_ocorrencia Movimentação das ocorrencias pelas areas de atendimento
seleciona_area Seleção da area de atendimento
altera_status Alteração do status da ocorrencia (Aberto, Em atendimento, Em
avaliação, Encerrado)
Tabela 9 – Classe Ocorrência
Classe Area_ocorrencia
Descrição Classe que armazena as areas que atendem ocorrências e os seus
operadores e as metricas de atendimento
Atributos Tamanho Formato Descrição
area_ocorrencia 30 caracter Area da Ocorrencia. Cadastrado pelo
Usuário Supervisor ou Gestor
operador 20 caracter O usuário Técnico operador da area
assunto 30 caracter Assunto da Ocorrencia
metrica_atender - tempo A metrica definida para o primeiro
atendimento. Define quanto tempo a
area tem para atender a ocorrencia
metrica_encerrar - tempo A métrica definida para area encerrar
ou alterar o status da ocorrencia
Observações
Esta classe alimenta a classe Ocorrencia com informações sobre as areas de atendimento e
suas métricas. As métricas serão calculadas pelo tempo da mudança de status.
Tabela 10 – Classe Area_Ocorrência
Classe Status_Ocorrencia
Descrição Armazena os Status das Ocorrencias desde a sua abertura até o seu
encerramento.
Atributos Tamanho Formato Descrição
idstatus - inteiro É o código identificador do status da
ocorrencia
Status_ocorrencia 20 caracter É a descrição do status da ocorrencia.
Tabela 11 – Classe Status_Ocorrencia
Classe Avaliação_ocorrencia
Descrição Classe que armazena as avaliações que as ocorrências recebem
Atributos Tamanho Formato Descrição
id_avaliacao - inteiro É o identificador da avaliação
63
datahora_abertura - Data-hora É a data/hora da abertura do chamado
metrica_atender - tempo É a metrica para o primeiro atendimento
do chamado pela area de atendimento
datahora_encerramento - Data-hora É a data/hora que o atendimento foi
encerrado e enviado para avaliação
métrica_encerra tempo É a metrica com o tempo de atendimento
que a area tem para encerrar o
atendimento
Nota 2 número Nota de 0 a 10 que usuário atribui ao
atendimento
Comentarios 150 caracter Comentários que usuário faz sobre o
atendimento
Operações Descrição
comenta_chamado
Metodo para comentário de ocorrencias. É ativado quando o
status da ocorrencia for mudado para encerrado por um usuário
técnico
contatempo
Conta os tempos desde a abertura ao encerramento das
ocorrências comparando-os com os das métricas inseridas no
sistema
Tabela 12 – Classe Avaliação_Ocorrência
Classe Estoque
Descrição Classe que armazena e controla o estoque de peças. Receb o tipo e o
nomeda peça pela Classe Peças
Atributos Tamanho Formato Descrição
idEstoque - inteiro É o identificador do Estoque
quant_inicial - número Recebe a quantidade inicial de Peças
após algum movimento das mesmas
(Entrada ou Saída) 
quant_final - número Recebe a quantidade final de Peças após
algum movimento das mesmas (Entrada
ou Saída)
Operações Descrição
atualizaestoque Um método ou trigger que deve atualizar a quantidade de peças
disponíveis nos Estoque. 
Tabela 13 – Classe Estoque
Classe Peças
Descrição Armazena os tipos de peça do sistema
Atributos Tamanho Formato Descrição
tipo_peça - inteiro Codigo do tipo de peça
nome_peça 30 caracter Nome da peça
Descrição
64
Esta classe é classe que dá o tipo e nome de peça para as classes que compõe o Estoque,
as peças são cadastradas pelos usuários técnicos.
Tabela 14 – Classe Peças
Classe Saída_Pecas_estoque
Descrição Responsavel pela saída de peças do estoque e o envio de peças a
classe Estação de Trabalho
Atributos Tamanho Formato Descrição
id_Saida_estoque - inteiro Identificador de saída de estoque
quantidade - numero Quantidade de peças que estão saindo
data_saída - Data-hora Data-Hora da saída
idET - inteiro Id da Estação de Trabalho que esta
sendo alimentada pela Peça
Operações Descrição
sai_peças_estoque Como toda peça saí para uma E.T, esta classe deve ser capaz de
reduzir do estoque a quantidade de peças.
Tabela 15 – Classe Saída_Peças_estoque
Classe Entrada_Pecas_estoque
Descrição Responsavel pela entrada de peças do estoque.
Atributos Tamanho Formato Descrição
id_entrada_estoque - inteiro É o identificador de entrada de peças
quantidade - número Quantidade de peças a serem somadas
no estoque
data_entrada - Data-hora Data-hora do evento
Nota_fiscal - número Número da Nota Fiscal
fornecedor 20 caracter Nome do fornecedor do material
Operações Descrição
entra_peças_estoque Metodo que soma peças ao Estoque. Este método deve ser capaz de
Receber a quantidade atual de peças do estoque, atualizar esta
quantidade somando a quantidade de peças que entram.
Tabela 16 – Classe Entrada_Peças_estoque
4.6 Modelo Conceitual de Dados
O modelo conceitual representa, descreve a realidade do ambiente do problema,
contituindos-se em uma visão global dos principais dados e seus relacionamentos
(estruturas de informação), completamtente independente dos aspectos de sua
implementação tecnologica.
65
4.6.1 – Visão Geral do Modelo Relacional 
Modelo Relacional é um modelo de dados, criado por Edgar Frank Codd, em 1970
e que se baseia no princípio de que os dados são armazenados em tabelas ou relações
Uma visão geral do Modelo Relacional do SISSUPORTI é apresentada na figura.
Figura 34 – Visão Geral do Modelo Relacional do Banco de Dados do Sistema SISSUPORTI
4.6.2 – Diagrama Entidade-Relacionamento
Figura 35 – Diagrama Entidade-Relacionamento
A representação do modelo relacional da base de dados foi desenvolvida usando a
ferramenta DBDesigner 4. Esta ferramenta foi adotada por apresentar uma interface
simples e ser distribuída sob a licença GNU GPL, pois uma das premissas é a utilização
somente de Software Livres para concepção do citado trabalho.
66
A representação do diagrama entidade-relacionamento foi feita pelo software
BRMODELO.
4.7 Diagrama de Sequência
 Diagramas de Sequência recebem este nome porque descrevem ao longo de uma
linha de tempo a sequência de comunicações entre objetos de um sistema. Tem também
as funções de documentar os casos de uso, mostrar como os objetos do sistema se
comunicam por meio de mensagens em ordenação temporal, validar se todas as operações
das classes foram identificadas e declaradas ou ainda validar a existência de um objeto
necessário ao funcionamento do sistema.
Segue-se abaixo os diagramas de sequência do sistema SISSUPORTI, levando em
conta as principais funções dos atores do sistema.
4.7.1 – Usuário-Normal
figura 36 – Diagrama de Sequência Usuário Normal
Neste diagrama podemos ver as principais ações dos usuários normais do sistema, 
como Login, impressão de documentos e abertura de ocorrencias.
67
4.7.2 – Usuário-Técnico
No caso do Usuário-Técnico, vamos dividir seus diagramas pelos objetos que ele
atuam, devido a complexibildade de seus casos de uso
a) Pessoa
 
Figura 37 – Diagrama de Sequência Usuário Técnico (Pessoa)
b)Pessoa/Ocorrencia
Figura 38 – Diagrama de Sequência Usuário Técnico (Pessoa/Ocorrência)
68
c) Pessoa/Estação de Trabalho/Inventário
Figura 39 – Diagrama de Sequência Usuário Técnico (Pessoa/Estação de Trabalho/Inventário)
No nosso modelo négocio, o Usuário-Técnico é ator que tem mais funções ativas
no sistema. A maioria dos casos de uso são adequados a este usuário.
O diagrama de sequência dos Usuários Supervisor Técnico e Usuário Gestor não
serão apresentados pois os seus casos de usos são mais centrados na administração de
direitos e métricas.
4.8 Diagrama de Estados
Este tipo de diagrama é utilizado para capturar o ciclo de vida das classes, pórem
também pode ser utilizado para modelar o comportamento de casos de usos, sistema ou
subsistemas
Seguem-se os diagramas das principais classes do sistema: 
69
4.8.1 – Classe Pessoa
Figura 40 – Diagrama de Estados Classe Pessoa
4.8.2 – Classe Estação de Trabalho
Figura 41 – Diagrama de Estados Estação de Trabalho
70
4.8.3 - Classe Ocorrência
Figura 42 – Diagrama de Estados Ocorrência
4.8.4 – Classe Inventário
Figura 43 – Diagrama de Estados Inventário
71
Com estes diagramas mostramos as funções mais complexas das principais classes
do Sistema.
4.9 – Diagrama de Atividades
Este diagrama representa os aspectos dinâmicos e pode ser utilizado para modelar
um sistema de informação, alguns módulos deste, uma pequena parte do código de um de
seus programas, um algoritimo ou os processos (fluxos de trabalhos) de uma organização.
Vamos modelar neste diagrama os principais modelos de negocio que são o
Cadastro de Pessoas, o Cadastro de Estação, a Abertura/Avaliação de Ocorrencias e o
Cadastro de Peças (inventário).
4.9.1 – Cadastro de Pessoas
Figura 44 – Diagrama de Atividades Cadastro de Pessoas
72
4.9.2 – Cadastro de Estação de Trabalho
Figura 45 – Diagrama de Atividades Estação de Trabalho
4.9.3 – Classe Ocorrencia
Figura 46 – Diagrama de Atividades Ocorrência
73
4.9.4 – Cadastro de Tipo de Peças
Figura 47 – Diagrama de Atividades Cadastros Tipo de Peças
5 – O Projeto Físico
5.1 – Modelo Físico de dados
O modelo físico provê um contexto para definição e registro no catálogo do Banco
de Dados dos elementos de dados que formam um “database”, por assim dizer, e fornece
aos analistas de uma aplicação a possibilidade de escolha dos caminhos e acesso às
estruturas de dados.
A seguir o modelo para implementação do Banco de Dados do SISSUPORTI,
mostrando as tabelas e suas relações:
 
74
Figura 48 – Modelo Físico dos dados
5.1.1 – Projeto de Tabelas e Arquivos
Abaixo o projeto de criação de tabelas e arquivos do sistema:
Tab_Grupo
Objetivo: Armazenar os direitos dos grupos de Usuários
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
Pk Grupo varchar 1 Não
Descricão_grupo varchar 255 Não
criar_usuario boolean 1 Não
criar_tecnico boolean 1 Não
monta_Et boolean 1 Não
Atende_ocorrencia boolean 1 Não
criar_supervisor boolean 1 Não
criar_metrica boolean 1 Não
cria_area_chamado boolean 1 Não
abre_ocorrencia boolean 1 Não
avalia_ocorrencia boolean 1 Não
insere_TRI boolean 1 Não
insere_TRET boolean 1 Não
cria_monitoramento boolean 1 Não
assimila_Et boolean 1 Não
cadastra_pecas boolean 1 Não
fecha_ocorrencia boolean 1 Não
assimila_Et boolean 1 Não
Tabela 17 – Tabela Grupos
75
Script de criação:
CREATE TABLE public.Tab_Grupo (grupo VARCHAR(1) NOT NULL,
Descricao_grupo VARCHAR NOT NULL, Criar_usuario BOOLEAN NOT NULL,
Criar_tecnico BOOLEAN NOT NULL, monta_Et BOOLEAN NOT NULL,
Atende_ocorrencia BOOLEAN NOT NULL, Criar_supervisorBOOLEAN NOT NULL,
Cria_metrica BOOLEAN NOT NULL, cria_area_chamado BOOLEAN NOT NULL,
abre_ocorrencia BOOLEAN NOT NULL, avalia_ocorrencia BOOLEAN NOT NULL,
insere_TRI BOOLEAN NOT NULL, insere_TRET BOOLEAN NOT NULL,
cria_monitoramento BOOLEAN NOT NULL, assimila_Et BOOLEAN NOT NULL,
cadastra_pecas BOOLEAN NOT NULL, fecha_ocorrencia BOOLEAN NOT NULL,
assimila_Et_1 BOOLEAN NOT NULL, CONSTRAINT grupo_pk PRIMARY KEY
(grupo)); COMMENT ON COLUMN public.Tab_Grupo.grupo IS 'Código de grupo';
Tab_Pessoa
Objetivo: Armazenar os dados das Pessoas do Sistema
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
Pk idPessoa interger - Não
Fk grupo varchar 1 Não
password varchar 30 Não
CatFuncional varchar 10 Não
bloqueio boolean 1 Não
TRI_assinado boolean 1 Não
TRI_digitalizado boolean 1 Não
Nome_Completo varchar 50 Não
Nome_de_Guerra varchar 10 Não
email varchar 30 Não
login varchar 30 Não
Depto varchar 20 Não
Tabela 18 – Tabela Pessoa
 Script de criação
CREATE TABLE public.Tab_pessoa ( idPessoa INTEGER NOT NULL,
grupo VARCHAR(1) NOT NULL, password VARCHAR(30) NOT NULL,
CatFuncional VARCHAR(10) NOT NULL, bloqueio BOOLEAN NOT NULL,
TRI_assinado BOOLEAN NOT NULL, TRI_digitalizado BOOLEAN NOT NULL,
Nome_Completo VARCHAR(50) NOT NULL, Nome_de_Guerra VARCHAR(10) NOT
NULL, email VARCHAR(30) DEFAULT fulano@dhn.mar.mil.br NOT NULL,
login VARCHAR(30) NOT NULL, Depto VARCHAR(20) NOT NULL,
CONSTRAINT idpessoa_pk PRIMARY KEY (idPessoa); COMMENT ON COLUMN
public.Tab_pessoa.grupo IS 'É o codigo do grupo de pessoas que ela pertence. O padrão
para novos usuários é 1. Existem ainda 2 - Usuário Técnico, 3 - Usuário Supervisor
Técnico e 4 - Usuário Gestor'; COMMENT ON COLUMN public.Tab_pessoa.password
IS 'Senha do Usuário para acesso ao sistema'; COMMENT ON COLUMN
public.Tab_pessoa.CatFuncional IS 'A categoria funcional é o titulo da pessoa. Como
estamos em um ambito militar, seriam os postos e graduações e, ainda, o titulo Servidor
76
Civil para civis. '; COMMENT ON COLUMN public.Tab_pessoa.bloqueio IS 'Item de
bloqueio de uma pessoa. Se estiver marcado, a pessoa perde acesso ao Sistema. O padrão
é N.'; COMMENT ON COLUMN public.Tab_pessoa.TRI_assinado IS 'Indica se o
documento "Termo de Responsabilidade Individual" foi assinado ou não. O padrão é
Y';COMMENT ON COLUMN public.Tab_pessoa.TRI_digitalizado IS 'Verifica se o
documento "Termo de Responsabidade Individual" foi digitalizado para o sistema.
';COMMENT ON COLUMN public.Tab_pessoa.Nome_Completo IS 'Nome Completo
do Usuário';COMMENT ON COLUMN public.Tab_pessoa.Nome_de_Guerra IS 'É a
"alcunha" ou "apelido" da pessoa.';COMMENT ON COLUMN public.Tab_pessoa.email
IS 'E-mail corporativo da pessoa';COMMENT ON COLUMN public.Tab_pessoa.login IS
'Nome de Login da Pessoa do Sistema'; COMMENT ON COLUMN
public.Tab_pessoa.Depto IS 'Departamento ao qual a Pessoa é subordinada';
Tab_ET
Objetivo: Armazenar os dados das Estações de Trabalho cadastradas no Sistema
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
Pk idEt interger Não
Fk idPessoa interger 1 Não
Numero_IP varchar 15 Sim
Endereco_Fisico varchar 17 Sim
Num_Patr varchar 11 Sim
TRET_assinado boolean 1 Não
TRET_digitalizado boolean 1 Não
Monitora boolean 1 Não
Bloqueia boolean 1 Não
Tabela 19 – Tabela Estação de Trabalho
Script de Criação
CREATE TABLE public.Tab_Et ( idEt INTEGER NOT NULL, idPessoa
INTEGER NOT NULL, Numero_IP VARCHAR(15) DEFAULT 999.999.999.999 NOT
NULL, Endereco_Fisico VARCHAR(17) NOT NULL, Num_Patr VARCHAR(11),
TRET_assinado BOOLEAN NOT NULL, TRET_digitalizado BOOLEAN NOT NULL,
Monitora BOOLEAN NOT NULL, Bloqueia BOOLEAN NOT NULL,
CONSTRAINT idet_pk PRIMARY KEY (idEt)); COMMENT ON COLUMN
public.Tab_Et.Endereco_Fisico IS 'MAC Adress da Estação de Trabalho'; COMMENT
ON COLUMN public.Tab_Et.Num_Patr IS 'Numero de Patrimonio da Estação de
Trabalho'; COMMENT ON COLUMN public.Tab_Et.TRET_assinado IS 'Este campo
verifica se o documento "Termo de Responsabilidade de Estação de Trabalho" foi
assinado pela Pessoa dona da Estação de Trabalho'; COMMENT ON COLUMN
public.Tab_Et.TRET_digitalizado IS 'Este campo verifica se o documento "Termo de
Respnsabilidade da Estação de Trabalho" foi digitalizado e carregado ao sistema';
COMMENT ON COLUMN public.Tab_Et.Monitora IS 'Este campo marca a ET para
monitoramento de atividade'; COMMENT ON COLUMN public.Tab_Et.Bloqueia IS
'Este campo Bloqueia a E.T. para uso da rede local (quando o sistema for utlizado junto
com um servidor DHCP)';
77
Tab_Ocorrencia
Objetivo: Armazenar os dados das Ocorrências abertas pelas Pessoas
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
Pk Num_Ocorrência numeric Não
PFk id_area_ocorrência interger 1 Não
PFk Assunto varchar 255 Não
PFk idPessoa interger - Não
PFk id_avaliacao varchar - Sim
Fk idstatus interger - Não
Descricao varchar 150 Não
Tabela 20 – Tabela Ocorrencia
Script de criação
CREATE SEQUENCE public.tab_ocorrencia_num_ocorrencia_seq;
CREATE TABLE public.Tab_Ocorrencia (Num_Ocorrencia NUMERIC NOT
NULL DEFAULT nextval('public.tab_ocorrencia_num_ocorrencia_seq'),
id_area_ocorrencia INTEGER NOT NULL, Assunto VARCHAR NOT NULL,
idPessoa INTEGER NOT NULL, id_avaliacao VARCHAR NOT NULL,
idstatus INTEGER NOT NULL, Descricao VARCHAR(150) NOT NULL,
CONSTRAINT id_ocorrencia_pk PRIMARY KEY (Num_Ocorrencia,
id_area_ocorrencia, Assunto, idPessoa, id_avaliacao)); COMMENT ON COLUMN
public.Tab_Ocorrencia.Descricao IS 'Descrição da Ocorrencia. Preenchida pelo Usuário';
Tab_area_ocorrencia
Objetivo: Armazenar os dados das areas de Ocorrências 
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
Pk id_area_ocorrência interger Não
Pk Assunto varchar 255 Não
area_ocorrencia varchar 30 Não
Operador varchar 255 Não
Metrica_atender time - Não
Metrica_encerrar time - Não
Tabela 21 – Tabela area_ocorrencia
Script de criação
CREATE TABLE public.Tab_area_ocorrencia ( id_area_ocorrencia INTEGER
NOT NULL, Assunto VARCHAR NOT NULL, area_ocorrencia VARCHAR(30) NOT
NULL, Operador VARCHAR NOT NULL, Mertica_atender TIME NOT NULL,
Metrica_encerrar TIME NOT NULL, CONSTRAINT id_area_ocorrencia_pk PRIMARY
KEY (id_area_ocorrencia, Assunto));
78
Tab_status_ocorrencia
Objetivo: Armazenar os status das Ocorrências 
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
Pk idstatus interger Não
status_ocorrencia varchar 20 Não
Tabela 22 – Tabela Status ocorrênica
Script de criação
CREATE TABLE public.Tab_status_ocorrencia ( idstatus INTEGER NOT
NULL, status_ocorrencia VARCHAR(20) NOT NULL, CONSTRAINT
id_status_ocorrencia_pk PRIMARY KEY (idstatus));
Tab_avaliacao_ocorrencia
Objetivo: Armazenar os dados das avaliações de Ocorrências 
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
Pk id_avaliacao interger Não
data_hora_abertura time Não
Comentarios varchar 255 Não
data_hora_encerramento varchar 255 Não
nota numeric 2 Não
Tabela 23 – Tabela avaliação ocorrência
Script de criação
CREATE TABLE public.Tab_avaliacao_ocorrencia (id_avaliacao VARCHAR
NOT NULL, data_hora_abertura TIME NOT NULL, Comentarios VARCHAR NOT
NULL, datahora_encerramento TIME NOT NULL, nota NUMERIC(2) NOT NULL,
CONSTRAINT id_avaliacao_ocorrencia_pk PRIMARY KEY (id_avaliacao));
Tab_Pecas
Objetivo: Armazenar os tipos de peça que compõe o Estoque e as E.T
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
Pk id_tipo_peca interger Não
nome_peca varchar 30 Não
Tabela 24 – Tabela Peças
79
Script de criação
CREATE TABLE public.Tab_Pecas ( id_tipo_peca INTEGER NOT NULL,
nome_peca VARCHAR(30) NOT NULL, CONSTRAINT tab_pecas_pk PRIMARY
KEY (id_tipo_peca));
Tab_Pecas_X_ET
Objetivo: Armazenar os dados das Ocorrências abertas pelas Pessoas
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
PFk id_tipo_peca interger Não
PFk quantidade numeric 255 Não
PFk idEt interger Não
Tabela 25– Tabela Peças X ET
Script de criação
CREATE TABLE public.Tab_Pecas_X_Et ( id_tipo_peca INTEGER NOT
NULL, quantidade NUMERIC NOT NULL, idEt INTEGER NOT NULL,
CONSTRAINT tab_pecas_x_et_pk PRIMARY KEY (id_tipo_peca, quantidade, idEt));
Tab_saida_estoque
Objetivo: Armazenar os dados de saídas de peças para E.T
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
PFk id_tipo_peca interger Não
PFk quantidade numeric 255 Não
PFk idEt interger Não
data_saida date Não
Tabela 26 – Tabela Saída estoque
Script de criação
CREATE TABLE public.Tab_saida_estoque ( id_tipo_peca INTEGER NOT
NULL, quantidade NUMERIC NOT NULL, idEt INTEGER NOT NULL,
data_saida DATE NOT NULL, CONSTRAINT tab_saida_estoque_pk PRIMARY KEY
(id_tipo_peca, quantidade, idEt) );
Tab_entrada_pecas_estoque
Objetivo: Armazenar os dados de entradas de peças para o Estoque
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
PFk id_tipo_peca interger - Não
Pk Id_entrada_estoque interger - Não
quantidade numeric - Não
80
data_entrada date - Não
Nota_fiscal numeric - Sim
Fornecedor varchar 255 Sim
Tabela 27– Tabela Entrada Peças Estoque
Script de criação
CREATE TABLE public.id_entrada ( id_entrada_estoque INTEGER NOT
NULL, id_tipo_peca INTEGER NOT NULL, quantidade NUMERIC NOT
NULL, data_entrada DATE NOT NULL, Nota_fiscal NUMERIC, fornecedor
VARCHAR(255), CONSTRAINT id_entrada_pk PRIMARY KEY
(id_entrada_estoque, id_tipo_peca));
Tab_estoque
Objetivo: Armazenar os dados de saídas de peças para E.T
Chave Nome do Campo
Tipo do 
Campo
Tamanho Nulo
Pk idEstoque interger - Não
Fk Id_tipo_peca interger - Não
quant_inicial numeric - Sim
quant_final numeric - Sim
Tabela 28– Tabela Estoque
Script de criação
CREATE TABLE public.Tab_estoque ( idEstoque INTEGER NOT NULL,
id_tipo_peca INTEGER NOT NULL, quant_inicial NUMERIC NOT NULL,
quant_final NUMERIC NOT NULL, CONSTRAINT idestoque_pk PRIMARY KEY
(idEstoque));
Outros Scripts de Criação:
ALTER TABLE public.Tab_Ocorrencia ADD CONSTRAINT
tab_status_ocorrencia_tab_ocorrencia_fk
FOREIGN KEY (idstatus)
REFERENCES public.Tab_status_ocorrencia (idstatus)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT DEFERRABLE;
ALTER TABLE public.Tab_Ocorrencia ADD CONSTRAINT
tab_avaliacao_ocorrencia_tab_ocorrencia_fk
FOREIGN KEY (id_avaliacao)
REFERENCES public.Tab_avaliacao_ocorrencia (id_avaliacao)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT DEFERRABLE;
81
ALTER TABLE public.Tab_Ocorrencia ADD CONSTRAINT
tab_area_ocorrencia_tab_ocorrencia_fk
FOREIGN KEY (id_area_ocorrencia, Assunto)
REFERENCES public.Tab_area_ocorrencia (id_area_ocorrencia, Assunto)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT DEFERRABLE;
ALTER TABLE public.Tab_saida_estoque ADD CONSTRAINT
tab_pecas_tab_saida_estoque_fk
FOREIGN KEY (id_tipo_peca)
REFERENCES public.Tab_Pecas (id_tipo_peca)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT DEFERRABLE;
ALTER TABLE public.Tab_Pecas_X_Et ADD CONSTRAINT
tab_pecas_tab_pecas_x_et_fk
FOREIGN KEY (id_tipo_peca)
REFERENCES public.Tab_Pecas (id_tipo_peca)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT DEFERRABLE;
ALTER TABLE public.Tab_estoque ADD CONSTRAINT tab_pecas_tab_estoque_fk
FOREIGN KEY (id_tipo_peca)
REFERENCES public.Tab_Pecas (id_tipo_peca)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT DEFERRABLE;
ALTER TABLE public.id_entrada ADD CONSTRAINT tab_pecas_id_entrada_fk
FOREIGN KEY (id_tipo_peca)
REFERENCES public.Tab_Pecas (id_tipo_peca)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT DEFERRABLE;
ALTER TABLE public.Tab_pessoa ADD CONSTRAINT tab_grupo_tab_pessoa_fk
FOREIGN KEY (grupo)
REFERENCES public.Tab_Grupo (grupo)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT DEFERRABLE;
ALTER TABLE public.Tab_Et ADD CONSTRAINT tab_pessoa_tab_et_fk
FOREIGN KEY (idPessoa)
REFERENCES public.Tab_pessoa (idPessoa)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT DEFERRABLE;
82
ALTER TABLE public.Tab_Ocorrencia ADD CONSTRAINT
tab_pessoa_tab_ocorrencia_fk
FOREIGN KEY (idPessoa)
REFERENCES public.Tab_pessoa (idPessoa)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT DEFERRABLE;
ALTER TABLE public.Tab_saida_estoque ADD CONSTRAINT
tab_et_tab_saida_estoque_fk
FOREIGN KEY (idEt)
REFERENCES public.Tab_Et (idEt)
ON DELETE NO ACTION
ON UPDATE NO ACTION
NOT DEFERRABLE;
ALTER TABLE public.Tab_Pecas_X_Et ADD CONSTRAINT
tab_saida_estoque_tab_pecas_x_et_fk
FOREIGN KEY (id_tipo_peca, idEt, quantidade)
REFERENCES public.Tab_saida_estoque (id_tipo_peca, idEt, quantidade)
ON DELETE CASCADE
ON UPDATE CASCADE
NOT DEFERRABLE;
5.2 – Ambiente do Sistema
5.2.1 - Definição do ambiente físico
As metodologias e tecnologias que serão utilizadas para execução das fases de
obtenção, produção e manutenção do Sistema. O ambiente para o desenvolvimento deve
contemplar os seguintes aspectos: IDE (Integrated Development Environment) de
desenvolvimento, ferramenta de versionamento, ferramenta de testes, ferramenta para
controle de mudanças, ferramenta para levantamento de requisitos e outras ferramentas de
apoio ao processo de desenvolvimento.
A arquitetura de software e os frameworks utilizados pelos desenvolvedores
devem ser mencionados, caso conhecidos.
O sistema terá seu foco principal nas redes corporativas, não havendo necessidade
de conexão com a Internet.
 A Marinha do Brasil tem documentações próprias para reger o desenvolvimento
de Sistemas e, estas devem ser consideradas quando no desenvolvimento da solução.
83
5.2.2 - Justificativa da escolha da Linguagem de
Programação e do SGBD
Como devemos seguir as regras de homologação de softwares dentro da
Organização, as seguintes tecnologias relacionadas abaixo foram padronizadas para o
Sistema. . Foram considerados para sua escolha os seguintes aspectos: abrangência de uso
na Organização, segurança, disponibilidade de técnicos no mercado para atender
possíveis necessidades de terceirização e evolução futura da ferramenta. São elas:
a) Servidor Web: Apache;
b) Servidor de Aplicação: JBOSS;
c) Linguagens de Programação: Java e PHP;
d) Sistema Operacional de Rede: Suse Linux Enterprise;
e) Banco de Dados: Oracle e PostgreSQL;
f) Ferramenta de Gestão de Conteúdo: Drupal para elaboração de sítios dinâmicos;
g) IDE para Desenvolvimento: RAD e Eclipse; e
h) Mecanismo de Autenticação: LDAP
6 - Arquitetura do Sistema
6.1 - Diagrama de Componentes
Todo o Software é constituído por arquivos físicos armazenados em meio digital
( Programas fonte ou executável, pastas, bibliotecas, tabelas, framework, etc.). É função
do Diagrama de Componentes documentar como esses arquivos estão estruturados,
organizados e se relacionam, permitindo uma melhor compreensão e facilitando a
84
reutilização. Támbém serve para modelar arquivos de processos de negócios, descrevendo
as partes que participam do mesmo e suas relações.
Abaixo modelaremos os principais processos a nível de usuário do SISSUPORTI:
Figura 49 – Diagrama de Componentes
85
6.2 - Diagrama de Implantação
Este Diagrama especifca um conjunto de construções que podem ser utilizadas
para definir a arquitetura de execução de sistemas de informação. Ele foca na arquitetura
sobre a qual o software irá ser implatado e executado em termos de hardware, software e
redes de comunicação, ou seja, quais máquinas (computadores, servidores, switches, etc),
quais programas (sistema operacional, sistema gerenciador de banco de dados, browser)
serão necessários para suportar o sistema, bem como definir como essas máquinas serão
conectadas, qual velocidade de conexão e quais os protocolos de comunicação serão
utilizados.
Abaixo segue o diagrama de Implantação do SISSUPORTI:
Figura 50– Diagrama de Implantação
86
7.0 – Conclusões
7.1 - Reflexão sobre os objetivos iniciais e os
alcançados
Durante todo o periodo de desenvolvimento deste trabalho, pudemos notar que a
modelagem de sistemas é um processoarduo e trabalhoso, porém gratificador, quando ao
final, temos um produto que está pronto para ser desenvolvido. Com todos os modelos
aqui representados, tentamos criar um caminho seguro para que um bom desenvolvedor
possa implementar todos os casos de usos levantados pela Instituição, entregando um
produto de qualidade, que siga os requisitos dos gestores, facilite o trabalho dos
supervisores e técnicos e que seja simples para que os usuários básicos possam ter suas
necessidades atendidas e documentadas, com segurança da aplicação e pontualidade.
Considerando os principais padrões de qualidade da atualidade, o SISSUPORTI,
tenta ser uma ferramenta que possa ser utilizada, de forma satisfatória dentro do Nicho
que será utilizado, dando dinanismo as decisões que devam ser tomadas, com os
indicadores que o mesmo gerar.
7.2 - Vantagens do sistema para a empresa
As vantagens serão inumeras para empresa, desde a parte economica ate a
padronização de normas de usuabilidade e reuso de código, cabe lembrar, como haviamos
dito nos primeiros capítulos desta obra, que a premissa do sistema era utilizar ferramentas
de código livre (Opensource) e GNU/Linux, em todas as fases de desenvolvimentos do
SISSUPORTI. Ou seja, os custos com licenciamento de softwares serão quase nulos,
sendo que os únicos softwares que necessitam ser licenciados são os softwares das
estações de trabalho, pois muitos usuários ainda preferem trabalhar com o sistema
WINDOWS. Por isso, foi necessário desenvolver um sistema que trabalhasse de forma
igualitária com os navegadores Internet Explorer e Mozilla Firefox, integrando
compatibilidade com esses dois navegadores.
Há de se registrar que se o sistema, quando for desenvolvido, vier a ser
homologado pelas instâncias superiores da Organização, o mesmo pode ser padronizado,
podendo ser usado em várias outras Instituições da Marinha do Brasil, elevando assim, o
nome da DHN, como Instituição desenvolvedora de bons sistemas.
87
7.3 - Trabalhos Futuros
Alguns aspectos deste trabalho podem ser melhores implantadas em trabalhos
futuros, sendo assim, serão elencados alguns projetos que podem ser melhorados:
a) Inserção de reconhecimento automático das estações de trabalho que forem
cadastradas, com a implementação de um cliente que faça o reconhecimento do Hardware
das mesmas;
b) Melhor implementação da parte de monitoramento;
c) Implementação de Ipv6 no reconhecimento das estações de trabalho, tendo em
vista, que este protocolo deve substituir em breve o Ipv4, fazendo com que DHCP fiquem
obsoletos por não ser mais necessário o compartilhamento de IPs públicos nas redes
locais;
d) Melhoria nas trilhas de auditorias do sistema;
e) Cadastros de empresas de fornecimento de peças para facilitar o cadastro das
mesmas;
f) Criação de uma camada de segurança de usuários mais implementada e melhor
elaborada, para que a mesma permita que o sistema possa autenticar usuários de LDAP;
g) Validação de dados na camada de Banco de Dados; 
h) Divisão dos Departamentos por Centro de Custos; e
i) Criar um modulo para que haja a interação entre Matriz e Filial, no caso da
Organização aqui citada, Organizações Militares Superiores e Subordinadas.
88
REFERÊNCIAS BIBLIOGRÁFICAS
ENGHOLM JÚNIOR, Hélio - Analise e Design Orientado a Objeto, São Paulo, Novatec
Editora, 2013
EVANDRO, Carlos Teruel - Arquitetura de Sistemas para WEB com Java utilizando
Design Patterns e Frameworks, Rio de Janeiro, Ciência Moderna Ltda, 2012
MORAES GÓES, Wilson – Aprenda UML por meio de estudos de caso, São Paulo,
Novatec Editora, 2014
BOOCH, Grady , RUMBAUGH, James JACOBSON, Ivar – UML, Guia do Usuário;
Tradução de Fabio Freitas da Silva e Cristina de Amorim Machado, Rio de Janeiro,
Elsevier, 2012
MACHADO, Felipe Nery Rodrigues – Projeto e Implementação de Banco de Dados, 3
edição, São Paulo, Erica, 2014
NEGUS, Cristopher et al – Linux – A Bíblia Edição Especial; Tradução de Daniela
Botelho, Rio de Janeiro, Alta Books, 2008
RIBEIRO, Uirá – Certificação Linux – 2 edição, Minar Gerais, DK Editora, 2009
ERIBERTO, João Motta Filho – Descobrindo o Linux, 3 edição, Rio de Janeiro, Novatec,
2012
MARINHA DO BRASIL – DCTIMARINST 33-01 - Verificação de Conformidade de
Sistemas Digitais (SD) na MB, 2012
MARINHA DO BRASIL – DGMM-0540 – Normas de Tecnologia da Informação da
Marinha , 1 Revisão, 2010
MARINHA DO BRASIL – Portaria 012/2013, da Diretoria de Geral de Navegação, que
aprova o Regulamento da Diretoria de Hidrografia e Navegação , Documento de 19 de
Junho de 2013
Portal DHN, Disponivel em <https://www1.mar.mil.br/dhn> Acesso em 05 de julho de
2015
89
Manual do OCOMON, Disponivel em <http://ocomonphp.sourceforge.net/> Acesso em
07 de julho de 2015
CAMARGO, Alessandra Arantes de Souza, BRITO, Douglas de Almeida – Proposta de
Modelagem de um Sistema para Biblioteca utilizando JAVA e RFID, Faculdade Tecnologica
de São José dos Campos , TCC, 2009.
90
Anexo I – Glossário
Analistas - Os profissionais da área que geram softwares (programas), que são
executados em hardwares (equipamentos) operados por usuários (indivíduos), preparados
e treinados em procedimentos operacionais padronizados, dotados de conhecimentos do
software e hardware para seu trabalho. 
Apache - O servidor Apache (ou Servidor HTTP Apache, em inglês: Apache HTTP
Server, ou simplesmente: Apache) é o mais bem sucedido servidor web livre. 
Astah - é um software para modelagem UML. É desenvolvido na plataforma Java, o que
garante sua portabilidade para qualquer plataforma que possui uma máquina virtual Java. 
CACIC - o Configurador Automático e Coletor de Informações Computacionais (Cacic)
é resultado do Consórcio de Cooperação entre a Secretaria de Logística Tecnologia da
Informação (SLTI) do Ministério do Planejamento, Orçamento e Gestão (MP) e a
Dataprev. Utilizado também pelos governos da Argentina, Venezuela e Paraguai, o Cacic
é capaz de fornecer um diagnóstico preciso do parque computacional e disponibilizar
informações como o número de equipamentos e sua distribuição nos mais diversos
órgãos, os tipos de software utilizados e licenciados, configurações de hardware, entre
outras informações. Também pode fornecer informações patrimoniais e a localização
física dos equipamentos, ampliando o controle do parque computacional e a segurança na
rede.
Desktop - Um gabinete de computador, também conhecido como case, caixa, chassis ou
torre, é o compartimento que contém a maioria dos componentes de um computador 
DHCP - Dynamic Host Configuration Protocol (Protocolo de configuração dinâmica
de host), é um protocolo de serviço TCP/IP que oferece configuração dinâmica de
terminais, com concessão de endereços IP de host, Máscara de sub-rede, Default Gateway
(Gateway Padrão), Número IP de um ou mais servidores DNS, Número IP de um ou mais
servidores WINS e Sufixos de pesquisa do DNS 
91
Drupal - é um framework modular e um sistema de gerenciamento de conteúdo (CMS)
escrito em PHP. O Drupal permite criar e organizar conteúdo, manipular a aparência,
automatizar tarefas administrativas e definir permissões e papéis para usuários e
colaboradores. 
Framework - é uma abstração que une códigos comuns entre vários projetos de software
provendo uma funcionalidade genérica. Um framework pode atingir uma funcionalidade
específica, por configuração, durante a programação de uma aplicação. Ao contrário das
bibliotecas, é o framework quem dita o fluxo de controle da aplicação, chamado de
Inversão de Controle. 
GNU/GPL - (Licença Pública Geral), GNU GPL ou simplesmente GPL, é a designação
da licença para software livre idealizada por Richard Matthew Stallman em 1989, no
âmbito do projeto GNU da Free Software Foundation (FSF). 
GNU/Linux - sistema operacionalunix-like baseado no GNU e no kernel Linux. Por ser
o sistema Linux mais tradicional, existe controvérsia quanto a sua nomenclatura, é
comum usar o nome Linux para se referir aos sistemas GNU/Linux, embora Linux seja
um termo mais amplo, que também abrange a outros sistemas como Android, WebOS,
sistemas Linux embutido entre outros. 
IDE - do inglês Integrated Development Environment ou Ambiente Integrado de
Desenvolvimento, é um programa de computador que reúne características e ferramentas
de apoio ao desenvolvimento de software com o objetivo de agilizar este processo. 
Internet Explorer - é um navegador de internet de licença proprietária produzido
inicialmente pela Microsoft 
IP - de forma genérica, é uma identificação de um dispositivo (computador, impressora,
etc) em uma rede local ou pública. Cada computador na internet possui um IP (Internet
Protocol ou Protocolo de internet) único, que é o meio em que as máquinas usam para se
comunicarem na Internet. 
Java - é uma linguagem de programação orientada a objetos desenvolvida na década de
90 por uma equipe de programadores chefiada por James Gosling, na empresa Sun
92
Microsystems. Diferentemente das linguagens convencionais, que são compiladas para
código nativo, a linguagem Java é compilada para um bytecode que é executado por uma
máquina virtual 
JBOSS - servidor de aplicação de código fonte aberto baseado na plataforma JEE e
implementado completamente na linguagem de programação Java. Em virtude disso, ele
pode ser usado em qualquer Sistema Operacional que suporte a referida linguagem. O
JBoss Application Server 7, para prover a sua inicialização, utiliza os arquivos:
standalone.bat ou standalone.sh 
LDAP - Lightweight Directory Access Protocol, ou LDAP, é um protocolo de
aplicação aberto, livre de fornecedor e padrão de indústria para acessar e manter serviços
de informação de diretório distribuído sobre uma rede de Protocolo da Internet (IP).
Serviços de diretório desempenham um papel importante no desenvolvimento de
aplicações intranet e Internet permitindo o compartilhamento de informações sobre
usuários, sistemas, redes, serviços e aplicações através da rede. 
Métricas - possibilitam realizar uma das atividades mais fundamentais do processo de
gerenciamento de projetos: o planejamento. A partir desse, pode-se identificar a
quantidade de esforço, de custo e das atividades que serão necessárias para a realização
do projeto. 
Mozilla Firefox - é um navegador livre e multi-plataforma desenvolvido pela Mozilla
Foundation (em português: Fundação Mozilla) com ajuda de centenas de colaboradores.
A intenção da fundação é desenvolver um navegador leve, seguro, intuitivo e altamente
extensível 
Netbeans - é um ambiente de desenvolvimento integrado () gratuito e de código aberto
para desenvolvedores de software nas linguagens Java, C, C++, PHP, Groovy, Ruby,
entre outras. O IDE é executado em muitas plataformas, como Windows, Linux, Solaris e
MacOS. O NetBeans IDE oferece aos desenvolvedores ferramentas necessárias para criar
aplicativos profissionais de desktop, empresariais, Web e móveis multiplataformas. 
Notebook - é um computador portátil, leve, projetado para ser transportado e utilizado em
diferentes lugares com facilidade. Geralmente, um laptop contém tela de LCD (cristal
93
líquido), teclado, mouse (geralmente um touchpad, área onde se desliza o dedo), unidade
de disco rígido, portas para conectividade via rede local ou fax/modem, gravadores de
CD/DVD. Os mais modernos não possuem mais a entrada para discos flexíveis
(disquetes), e, havendo necessidade de utilizar um desses dispositivos, conecta-se um
adaptador a uma das portas USB. 
OcoMon - surgiu em Março de 2002 como projeto pessoal do programador Franque
Custódio, tendo como características iniciais o cadastro, acompanhamento, controle e
consulta de ocorrências de suporte e tendo como primeiro usuário o Centro Universitário
La Salle (UNILASALLE). 
Opensource - O termo código aberto, ou open source em inglês, foi criado pela OSI
(Open Source Initiative) e se difere de um software livre por não respeitar as quatro
liberdades definidas pela Free Software Foundation (FSF), compartilhadas também pelo
projeto Debian, nomeadamente em "Debian Free Software Guidelines (DFSG)".
Qualquer licença de software livre é também uma licença de código aberto (Open
Source), mas o contrário nem sempre é verdade . Enquanto a FSF usa o termo "Software
Livre" envolta de um discurso baseado em questões éticas, direitos e liberdade, a OSI usa
o termo "Código Aberto" sob um ponto de vista puramente técnico, evitando
(propositadamente) questões éticas. Esta nomenclatura e este discurso foram cunhados
por Eric Raymond e outros fundadores da OSI com o objetivo de apresentar o software
livre a empresas de uma forma mais comercial evitando o discurso ético. 
Software Livre - é uma forma de manifestação de um software em que, resumidamente,
permite-se adaptações ou modificações em seu código de forma espontânea, ou seja, sem
que haja a necessidade de solicitar permissão ao seu proprietário para modificá-lo. Não
confundir com o movimento Open Source. Seus objetivos concede aos usuários a
liberdade de controle na execução e adaptação a sua computação e processamento de
dados às suas necessidades (concessão plena liberdade de controle e independência,
através da disponibilidade de código fonte para análise e alterações); bem como
permitindo-lhes a liberdade social, para ser capaz de cooperar ativamente com todos os
usuários e desenvolvedores de sua escolha. Os usuários de software livre estão livres
dessas atividades, porque eles não precisam pedir qualquer permissão, eles não estão
restritos nas atividades por meio de licenças proprietárias restritivas (por exemplo, cópia
restrita), ou requisitos de ter de concordar com as cláusulas restritivas dos outros (por
94
exemplo, acordos de não divulgação), e eles não estão restritos desde o início (por
exemplo, através deliberada a não disponibilidade de código fonte). 
Pendrive - ou Memória USB Flash Drive é um dispositivo de memória constituído por
memória flash (EEPROM), com aspecto semelhante a um isqueiro e uma ligação USB
tipo A permitindo a sua conexão a uma porta USB de um computador ou outro
equipamento com uma entrada USB. 
PHP - (um acrônimo recursivo para "PHP: Hypertext Preprocessor", originalmente
Personal Home Page) é uma linguagem interpretada livre, usada originalmente apenas
para o desenvolvimento de aplicações presentes e atuantes no lado do servidor, capazes
de gerar conteúdo dinâmico na World Wide Web 
PostgreSQL - sistema gerenciador de banco de dados objeto relacional (SGBDOR),
desenvolvido como projeto de código aberto 
Suse - é um sistema operacional baseado no Linux, desenvolvido pela comunidade
openSUSE de forma gratuita..
UML - a Linguagem de Modelagem Unificada (do inglês, UML - Unified Modeling
Language) é uma linguagem de modelagem que permite representar um sistema de forma
padronizada. 
Websevice - é uma solução utilizada na integração de sistemas e na comunicação entre
aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam
interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas
diferentes sejam compatíveis. 
Windows - uma família de sistemas operacionais criados pela Microsoft, empresa
fundada por Bill Gates e Paul Allen. Antes da versão NT, era uma interface gráfica para o
sistema operacional MS-DOS. O Windows é um produto comercial, com preços
diferenciados para cada uma de suas versões. É o sistema operacional mais utilizado em
computadores pessoais no mundo.O impacto deste sistema no mundo atual é muito
grande devido ao enorme número de cópias instaladas. Conhecimentos mínimos desse
95
sistema, do seu funcionamento, da sua história e do seu contexto são, na visão de muitos,
indispensáveis, mesmo para os leigos em informática. 
96
Anexo II – Modelo do Termo de Responsabilidade de
Estação de Trabalho
97
Anexo III – Modelo do Termo de Responsabilidade
Individual
98
	Internet Protocol
	GNU is Not Unix
	Requisito Funcional
	Requisito não Funcional
	Dynamic Host Configuration Protocol
	1 - Proposta de Trabalho
	1.1 - Método de Trabalho
	1.2 - Previsão de Alocação de Recursos
	1.3 - Cronograma do Trabalho
	Tabela 1 – Diagrama de Gautt
	O plano de execução das atividades do projeto terá sua contagem iniciada após a alocação dos recursos necessários a sua efetivação, quais sejam: pessoal qualificado e com dedicação exclusiva ao projeto, disponibilização do espaço físico (local isolado para evitar que os desenvolvedores se desconcentrem), e disponibilização de equipamentos para a equipe.
	2 - Caracterização da Empresa e do Negócio
	2.1 - Histórico da Empresa
	2.2 - Atividade da Empresa
	2.3 - Organograma
	Figura 1 – Organograma da Instiuição
	2.4 - Mercado Consumidor
	2.5 - Concorrência
	2.6 - Aspectos Tecnológicos
	2.7 Condicionantes
	3 - O Sistema Atual
	3.1 - Justificativa da Escolha da Área do Sistema
	3.1.1 - O Sistema
	3.1.2 - Funcionamento do Sistema
	3.1.3 - O ambiente do Sistema
	3.1.4 - A definição do escopo
	3.2 - Motivação para o novo sistema
	A principal motivação para criação do SISSUPORTI é uma padronização não só gráfica como processual das ações de TI, utilizando uma interface amigável e confiável para usuários, técnicos e gestores.
	3.3 - Situação Desejada
	4.0 - O sistema proposto (projeto lógico)
	4.1. Lista de Requisitos do Sistema
	Tabela 2 – Requisitos Funcionais
	A próxima tabela relaciona os requisitos não-funcionais do sistema identificados para o projeto, mostrando detalhes de cada um deles.
	Tabela 3 – Requisitos não-funcionais
	4.3 .Casos de Uso e suas Especificações
	4.4 Diagrama de Casos de Uso
	Tabela 17 – Tabela Grupos
	Tabela 18 – Tabela Pessoa
	Tabela 19 – Tabela Estação de Trabalho
	Tabela 21 – Tabela area_ocorrencia
	Tabela 22 – Tabela Status ocorrênica
	Tabela 23 – Tabela avaliação ocorrência
	Tabela 24 – Tabela Peças
	Tabela 25 – Tabela Peças X ET
	Tabela 26 – Tabela Saída estoque
	Tabela 27– Tabela Entrada Peças Estoque
	Tabela 28– Tabela Estoque
	Figura 49 – Diagrama de Componentes
	REFERÊNCIAS BIBLIOGRÁFICAS